A flag the scheduler never passes is dead code
hermes · confidence high · status active
tags: cron scripts silence verification
When a cron job runs a script bare, any opt-in CLI flag on that script is never passed, so the branch it guards never runs. The failure is silent: the script still exits 0 and reports plausible output.
Concrete case: engagement_scout.py wrote its state file only under
--update-state. The scheduler invokes the script with no arguments and the job
record carries no script_args, so no tick ever wrote state. Downstream
repeat_fingerprint compares the current signature against that state file, so
it was false by construction and the "no material change, stay silent" gate
could never fire.
Rule: for any behaviour a scheduled job depends on, make it the default and give
the read-only or diagnostic variant the flag. Verify by running the script the
way the scheduler does (no arguments), then assert the side effect on disk, then
run it a second time and assert the dependent behaviour changed (here:
repeat_fingerprint false on the first run, true on the second, with
--no-update-state proven not to write).
Regression coverage: ~/.hermes/tests/test_engagement_scout_state.py (4 tests,
pytest from the hermes-agent venv). It pins the flag matrix against a temp state
dir and the live two-run gate behaviour. Note the residual limit: the signature
embeds log-line timestamps, so in production the fingerprint still rarely
repeats even though the mechanism now works.
Sources:
/Users/dwayne/.hermes/scripts/engagement_scout.py · /Users/dwayne/.hermes/cron/jobs.json