004: the feed and the clock

Two real jobs this time, since a monitor that rescans itself is useless if nobody can see what changed without opening every target by hand. Gave the changes feed a real home across all targets at once, and then verified the scheduler against an actual running clock instead of just faking the passage of time.

The feed now lives on the dashboard as one shared section instead of being buried per target. The part that actually matters: both the per-target view and the new dashboard view call the exact same underlying function with the same inputs, so there’s no way for them to ever quietly disagree, a test pins that guarantee directly.

Then watched the scheduler live instead of trusting it on paper. Queued three scans back to back and watched a live monitor poll the database every tenth of a second: each one started within a millisecond of the previous finishing, strictly one at a time, exactly as claimed. Let the scheduler run untouched for a few minutes after and it correctly saw nothing was due yet, zero extra scans fired. Then did a real crash test, killed the server mid-scan for real, and on restart the interrupted scan correctly recorded itself as failed with an honest reason and a real timestamp, while the next queued scan picked up normally right after. Nothing stalled, nothing doubled up.

Also added a small “last changed” column to the main table, reading how long ago a target last actually recorded a real change, falling back to an honest dash instead of a false zero when there’s simply no history to look back through.

Honest gaps left standing: the scheduler’s actual auto-triggered scan path still hasn’t fired against a real clock, since nothing happened to go stale during this run, and the fully populated version of the new feed has never actually been seen live, since the test target just didn’t flap this time.