Skip to content

fix(hands): make the autonomous tick honour update_frequency - #19

Merged
Nideesh1 merged 2 commits into
mainfrom
fix/hand-tick-honors-update-frequency
Jul 31, 2026
Merged

Nideesh1 merged 2 commits into
mainfrom
fix/hand-tick-honors-update-frequency

Conversation

@Nideesh1

Copy link
Copy Markdown

update_frequency is a selectable setting on the collector hand, but nothing ever read it.

activate_hand built the agent's ScheduleMode from def.agent.check_interval_secs.unwrap_or(3600), so every activated hand self-prompted once an hour regardless of what the user picked. Confirmed on a live deployment:

Starting continuous background loop agent=underground interval_secs=3600
Starting continuous background loop agent=remote-jobs  interval_secs=3600

Both instances are configured every_6h.

Why it matters

An instance set to every_6h was waking 24 times a day instead of 4. And both collectors also have cron schedules pointed at the same agents, so each sweep ran twice — once on the tick, once on the schedule — against a metered LLM API and search engines that rate-limit. The setting shown in the UI was decorative.

Change

Resolve the tick interval in order:

  1. the instance's own update_frequency, so the UI value is the value that runs
  2. the hand's declared check_interval_secs
  3. DEFAULT_HAND_TICK_SECS (3600)

Adds manual (aliases off / never / none) returning None, which leaves the agent Reactive so it runs only when messaged or when its cron fires. That is the correct setting for both current collector instances, and it is now a visible option in the collector's settings rather than something only reachable by editing state.

An unrecognised value falls through to the declared default rather than returning None — a typo in a settings option should not silently leave an autonomous hand inert, which is far harder to notice than one that ticks too often.

Tests

  • test_hand_tick_uses_configured_update_frequency — each option maps to its interval
  • test_configured_frequency_beats_hand_declared_interval — the setting wins, i.e. the actual bug
  • test_manual_frequency_disables_the_tick — incl. aliases and surrounding whitespace/case
  • test_hand_tick_falls_back_when_unconfigured — hand value, then default
  • test_unknown_frequency_falls_back_rather_than_disabling — typos do not disable a hand

Verification

Not compiled locally — the only available host is a k8s control-plane node where cargo has previously OOM-killed kube-apiserver. Relying on CI. HAND.toml was parsed to confirm it still loads and now offers [manual, hourly, every_6h, daily, weekly].

Requires a rebuild + deploy to take effect: HAND.toml is include_str!'d into the binary.

🤖 Generated with Claude Code

scaling-workflow-systems and others added 2 commits July 31, 2026 19:54
`update_frequency` is a selectable setting on the collector hand, but nothing
ever read it. `activate_hand` built the agent's `ScheduleMode` from
`def.agent.check_interval_secs.unwrap_or(3600)`, so every activated hand
self-prompted once an hour no matter what the user picked.

The effect on a live deployment: an instance configured `every_6h` woke up 24
times a day instead of 4. Worse, both collector instances also have their own
cron schedules pointed at the same agents, so each sweep ran twice — once on
the tick, once on the schedule — against a metered LLM API and rate-limited
search engines. The setting shown in the UI was decorative.

Resolve the interval from the instance's own config first, then the hand's
declared value, then the default. Add `manual` (aliases `off`/`never`/`none`)
which returns `None` and leaves the agent Reactive, so an instance driven by
its own schedule does not also sweep on a timer. That is the correct setting
for both current collector instances.

An unrecognised value falls through to the declared default rather than
returning `None`: a typo in a settings option should not silently leave an
autonomous hand inert, which is a much harder failure to notice than one that
ticks too often.

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
@Nideesh1
Nideesh1 marked this pull request as ready for review July 31, 2026 20:20
@Nideesh1
Nideesh1 merged commit 2698505 into main Jul 31, 2026
10 of 11 checks passed
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

2 participants