Trust the side-effect, never the triggerReview

Every incident in this curriculum is one rule wearing different clothes: a job that RAN is not a job that WORKED. Verify the side-effect, never the trigger — and as a weekly operator, make the fleet witness itself.

Automation-hygiene rule 1: verify the side-effect, not the trigger. `last_fired_at` and `exit 0` only prove the runner STARTED — they say nothing about whether the work landed. The only proof is querying the downstream system: did the file appear, did the cloud doc show up in the listing, did the Things task get created, did the DB row change. Two RemoteTrigger failures in May both trusted `last_fired_at` and were both silently dead; every lesson since has been a variation on that mistake.

See the rule repeated across this week. The reMarkable poller confirms against the CLOUD listing, never against 'the bridge returned' — because a 429-throttled fetch can return without pulling anything (Monday). The JobHunt wrapper ends with `exit $VRC`, the verify leg's code, not the LLM leg's — because a briefing that didn't reach the device is a failed morning no matter how well the model ran (Wednesday). The event feed records what actually happened so the dashboard shows history, not hope (Saturday). And Mission Control reconciles the health check against the alert ledger so a false-green can't hide (the 8-20 lesson). One principle, four surfaces.

The operator's move now is to make the fleet witness itself. Every unattended job needs a SEPARATE check that asks 'did this job's artifact appear in the last N hours?' and fires a 🚨 Things task when it didn't — the dead-man's-switch pattern from 7-29. The job reporting its own success is the thing you can't trust; a second, independent witness checking the side-effect is what turns a silent death into a notification you'll actually read.

Worked example

Audit one job against the rule: what proves it worked, and does anything check that?

# Pick a live job and see what it claims:
launchctl list | grep -i zorc

# Then ask: does the health check look for the ARTIFACT, or just trust the run?
grep -nE 'artifact|fresh|exists|alert-state' /Users/tom/Claude/PDB/scripts/job_health_check.py | head -20

• The launchctl list shows each job's last exit status — a 0 here is the trigger, not the side-effect; don't let it end the inquiry.
• The grep shows whether job_health_check.py verifies a downstream artifact (and whether it reads alert-state.json) — a check that only trusts the run is a false-green waiting to happen.

Gotchas

• A freshness window wide enough to swallow a total failure is worse than no check — it launders a dead job into a pass (the 8-20 false-green); size the window to the cadence.
• A health check that never reads the alert ledger can disagree with it and still show green — reconcile the two, or the monitor lies to you.
• The job can't be its own witness — if the process that's supposed to run is the same process that reports it ran, a total no-show reports nothing at all.