The Do-Not-Touch List
This morning’s review digest said Projects reviewed: 21, and for the first time three of the names on it were repositories I worry about. All three came back clean.
Before this morning there were sixty-five of those digests, starting on 24 August. Between them they hold 343 reviews of nineteen repositories. None of the 343 is of the ten I would most want a second pair of eyes on.
Where the sweep got its list
Every morning a timer asks a second model family to read what changed in my repositories over the last day. To know which repositories exist, it asked the fleet: the roster of projects my build agents are allowed to work in. It was a careful list, and pointing the reviewer at it felt like reuse.
The roster answers one question: where may an autonomous agent write? Some repositories are kept off it deliberately, and they are the ones where a careless write costs the most. Two services that anyone on the internet can reach. The login gate every one of my private services trusts. A library service that opens files downloaded from strangers. The irrigation, climate and energy planners, which can be asked to move real equipment. A paper-trading experiment. A launch kit whose one important command cannot be taken back. The supervisor that keeps the agents running, which no agent may edit.
Keeping agents out of those is the safety measure. The reviewer is not an agent of that kind. It runs in a read-only sandbox and could never have written to any of them. It inherited a rule about writing that it had no means of breaking, and applied to reading, the rule ran backwards: the more a repository could hurt me, the less often anything looked at it. For sixty-five sweeps, less often meant never.
A second list
The fix is a second file, ten entries, each with the reason it is there. “Home HVAC automation that can actuate; safety-critical.” “Fleet supervision no agent may modify, changed only by the operator.” The sweep merges it with the fleet roster, and a listed repository that has gone missing is reported as a failed row instead of quietly dropped, so lost coverage makes noise.
The first sweep to use it, at 08:02 this morning, also reviewed the change itself, and returned one finding, rated high. The new code decides a path is a repository because a .git entry exists there. If that entry is damaged, the next step, git log, fails, and a failed git log is read as “no recent commits”. The repository leaves the sweep without a word: a quiet omission inside the patch that made omissions loud.
What clean covered
Further down the same digest, three of the ten appeared.
Each report opens with its scope. The first internet-facing service: files changed: 3. It tracks 177 files. The login gate: files changed: 4, out of 32. The third: 13 out of 268. The reviewer has a read-only shell and can open whatever it likes for context, but what it is asked to judge is the change. clean is a true statement about a diff. It is easy to read as a statement about a repository that has never been read whole.
Seven of the ten had no row at all. That was not an error. The sweep reviews repositories with commits in the last twenty-four hours, and those seven had none. The climate scheduler and the energy planner were last committed on 10 July, six weeks before the first sweep existed.
A review built on diffs reads whatever moves. I keep these repositories still on purpose. Code that runs a pump or holds the login for everything else should change rarely, and only when I mean it to. That stillness is a safety policy too, and it points the reviewer away as firmly as the roster did.
The second list got them past the do-not-touch rule. Nothing gets them past the do-not-change one. The climate scheduler’s newest commit is still from 10 July, and the morning after somebody edits it, the sweep will review the edit.