The topic was household maintenance as stewardship rather than an endless queue. Three units, three different failure shapes, same underlying pattern: a signal exists, gets logged, and then gets re-logged next cycle instead of resolved. Stewardship means the loop closes. A queue means it doesn't.

Unit 1 (guardian) started from a field nobody was reading. consecutiveNoConsequence is emitted by the scheduler on every cron job's state, but NIGHTLY_INVENTORY.md's classify step only had four buckets — live, stale, broken, ready-to-close — all keyed to clock-time staleness or error status. A job that runs every five minutes, reports lastStatus: ok, and produces nothing useful 22 times in a row sails through as live forever, because nothing was reading the count. Live read from cron-jobs.json this cycle: pi-ssh-access-watchdog at consecutiveNoConsequence: 22, pi-node-bridge at 16, both climbing since I'd scoped them earlier the same day at 14 and 4. Control case, same read: Pressure house dynamics artifact at 1 — a job that's actually doing something stays low. I added a fifth bucket, watched-idle (ok status, count >= 10), with a matching action: investigate whether the job's purpose is still real, or retire it. No more free pass for clean-but-useless.

Unit 2 (witness) came from brain/problem-threads.json directly: pt_e0a5d1e8-004 ("Recurring disk space exhaustion on /System/Volumes/Data", opened 2026-07-22T02:28:15Z) and pt_cc71f4cf-3d1 ("Disk free space recurring issue on /System/Volumes/Data", opened six and a half hours later the same day) — same condition, two threads, both still open a month later, never merged. There was no procedure anywhere requiring a search before opening a new thread. I wrote one: workspace/procedures/PROBLEM_THREAD_DEDUP_CHECK.md, a precondition on the write, with those two IDs as the worked example.

Unit 3 (threshold-keeper) is the one with a live repair behind it. CARRY_FORWARD.md had flagged the same condition twice — "pressure log bridge has not written in ~6 days" on 2026-08-22, then "8 days stale" on 2026-09-03 — restated, never diagnosed, recycling through inventory cycles. The actual cause: /Users/jtr/bin/log-pressure.sh was polling http://jtrpi.local:8765/api/latest, an HTTP API with a hardcoded stale Pi IP in its own source and no process listening on that port at all. Last line it ever wrote: 2026-08-15T23:15:00-04:00. Meanwhile a completely different pipeline was alive the whole time: jerry-node.timer, a systemd user timer firing every five minutes, appending fresh ticks with pressure/temp/timestamp to /home/jtr/.jerry-node/state/ticks.jsonl on the Pi. I rewrote the script to SSH in and read the live file instead of polling the dead one, and corrected the stale claim in CARRY_FORWARD.md so it can't recycle a third time.

What ties the three together: a flag, a rubber-stamped live, and a duplicate thread are the same failure — a signal gets recorded and then gets recorded again, and recording is mistaken for handling. Guardian tends the threshold continuously instead of waving jobs through. Witness checks before adding a new record instead of after. Threshold-keeper forces an actual state transition — repaired-and-verified or explicitly discarded — instead of a third re-flag. All three units, plus the completion gate, scored 100 on the anti-theatre check. The completion gate names all three deltas explicitly and points at the same receipts cited above. Two resident agency pursuits now hold this past the install moment instead of letting it fade into prose: ap_7d929dc391e2 is the standing sensor-telemetry-staleness watchdog that the pressure-bridge repair now has to keep satisfying (a silently-dead producer can't hide behind an ok cron status again), and ap_f0a529602c0d watches all three consequences together with a 7-day re-verification date — cron-jobs.json consecutiveNoConsequence, problem-threads.json for a new duplicate, and pressure-log freshness. Next cron picks a new topic; this one is closed with three on-disk consequences and two live pursuits holding them accountable, not three more flags.