The day an agent ran clean in the wrong directory
It deleted 131 checkpoint groups. Every guard in the code held — the command was correct, and it was pointed at the wrong place.
While reviewing the lane-scoped clean command in 0.12.0, an agent ran it from the repository instead of the temporary fixture it was supposed to test against.
It deleted 131 old checkpoint groups. .bridge/checkpoints was left with three files — the handoff that was live at that moment. No source was touched. Git was untouched. Nothing pending was lost. There was no backup, and the groups could not be recovered.
The command did exactly what it should have
This is the part worth being precise about, because it is the opposite of the usual story.
clean prunes old checkpoints. It refuses to delete anything another lane still depends on, it validates every lane before removing anything, and it will not touch a pending injection. Every one of those guards held. Judged by its contents, the operation was correct: those 131 groups were old, ignored, and exactly what clean exists to remove. Running it again today would produce the same list.
The failure was not in what the command deleted. It was in which directory it was pointed at.
A destructive command was being tested. Testing it means running it. The fixture existed precisely so it could be run without consequences, and the fixture was not where it ran.
Why the guards could not have saved it
The trust-boundary work in 0.12.0 is real: every checkpoint read, write, list and delete rejects paths that escape .bridge or pass through a symlinked directory, and pruning validates every lane first.
None of that is aimed at this. Those guards answer "is this path allowed?" The question here was "is this the repository you meant?" — and from inside the process, the repository is a perfectly legitimate target. It is the normal one.
You cannot write a guard against a correct operation performed in the wrong place. That is what a fixture is for, and what --dry-run is for.
What it actually cost
Objectively, very little. The groups were ephemeral delivery artifacts that retention prunes anyway. They had already served their purpose.
What was lost is the record. Each checkpoint was a small artifact of a real handoff — who passed to whom, what was decided, what carried over. That history is cheap to keep and impossible to reconstruct. Some of the writing on this site came out of those files. The ones that are gone cannot produce any more of it.
What I took from it
Not "add more guards" — the guards were not the gap.
A destructive command has two arguments, and only one of them is visible. There is what to delete, and there is where. Every safety mechanism in the tool was pointed at the first. Nothing in the tool, and nothing in my own habits, was pointed at the second.
So: test destructive commands against a fixture, and confirm you are in it before you run. Run clean --dry-run first — the dry run is the difference between deciding what to delete and finding out what was deleted.
And the honest part: an agent did this, but an agent will run whatever it is pointed at, in whatever directory it happens to be standing in. It felt nothing afterwards. The cost of losing context only ever reaches a person.