A comment on our last post found a hole in our agent approval gate. Here's what we found

Last week we posted here about the shared markdown memory that our agents and the two of us work in. One rule we described was that agents can write, but a human approves every change as a git diff before it counts. Someone in the comments asked whether other agents read a proposed change while it's still waiting. We answered that they do when they read files directly, and that only the search index waits for the commit. Then we actually checked. The approval was happening in chat, and the commit came late or never. The working tree had 50 modified and 408 untracked files. Eight decision notes had never been committed. The oldest open change was five weeks old. Every reader works from disk. The morning briefing and the agent that drafts offers both use whatever is in the folder, approved or not. Same for the finance agent. We were wrong about the index too. It rebuilds after a commit, but it walks the folder when it does, so unapproved notes end up in it anyway. And it went the other way as well. Our ingest agent has been allowed to commit on its own from early on. 138 of the 150 commits since September are from it. So "committed" never meant a human had looked. The same commenter suggested putting an owner on every review flag. We had 73 notes tagged needs-review, the oldest from June. None had a name on it. What we did about it is small on purpose. We didn't build a hard read gate. Reading only the committed version would have had agents working with old prices, because our newest pricing decisions were among the uncommitted files. That seemed worse than the problem. Unreviewed state gets labeled now. The morning briefing lists open files from a short list that matters (prices, decision notes, client pages, the invoice register). If the drafting agent or the finance agent takes a number from one of those, the draft says so. The weekly review lists anything on that list that's been open for more than 7 days, and one of us commits it or throws it out. New review flags need an owner or the checker complains. Old ones get one when somebody touches the note. We also wrote down what has to be true before any fix is ever committed without review. The proposal records the commit and file hash it was built on, and the check runs on the merged result. That was the stale base point from the same comment. None of this prevents anything. It only works if someone looks, and we know that. We looked at a separate proposal branch too. Our agent worktrees had already drifted more than 100 commits behind main once, so we didn't trust ourselves with it. Has anyone made that work? And is your gate on the write side, the read side or both?