[raymondginger2018-sudo]

Summary

Add core.schedule.monitor — a hash-suppressed change detection utility (P4). Before each scheduled LLM tick, run a script or fetch a URL; SHA-256 the output and compare against the last known hash. When nothing changed, skip the LLM call entirely (silent tick). When something changed, inject a unified diff + current output for the next LLM turn.

Design

• Byte-exact SHA-256 hashing (no normalisation) — even whitespace changes are detected.
• Source failure (non-zero exit, URL timeout) is treated as ERROR, not as a change; stored hash is preserved.
• First run records a baseline and returns changed=True.
• Diff is capped at 4K chars, current output at 8K (avoids flooding the LLM with the change itself).
• SQLite persistence (MonitorStore) with WAL mode and upsert semantics.
• Single-fetch architecture: monitor_gate() runs the monitored source exactly once per tick.

Tests

11 tests covering: byte-exact hashing, diff generation and truncation, baseline/change/no-change cases, source failure preservation, MonitorStore persistence (upsert + restart), and monitor_gate high-level flow (persists new hash after change, keeps old hash on source failure).

Motivation

This is the maintainable version of a pattern derived from Hermes cron/monitor.py: one focused feature, no orphan modules, no speculative wiring into unproven consumers.

[Zongwei9888]

Merged into main as 21ebc57, with a repair on our side. Thank you @raymondginger2018-sudo — byte-exact hashing, "source failure is an error, not a change", the single-fetch design and the SQLite upsert store are all as you built them, and the 11 tests pass.

What I changed before merging, mostly so the module has boundaries consistent with the rest of the runtime and a way to actually be used:

• URLs pass the same public-host policy as the web tools (validate_public_url): no loopback/private addresses, http(s) only. A monitor that fetches an internal endpoint is refused with a clear error rather than silently allowed.
• Scripts pass the destructive-command screen before they run. They are operator configuration, but the screen is cheap and consistent with the bash tool.
• The state store defaults to <deepcode home>/state/monitor.sqlite3 (user-private, like the rest of the state) instead of monitor_state.db in the current directory; MonitorStore() now works without arguments and the CLI's --db is optional.
• A documented entry point. The headless guide now has a "Change-gated schedules" section showing python -m core.schedule.monitor --json in front of deepcode exec in a cron entry, so the gate can be used today without changes to the Automation schema. Wiring it into Automations themselves would need a monitor_script/monitor_url field on the definition; if you would like to propose that as a follow-up, it would be welcome.