02 / 08
The undo feature could destroy the backup.
Found before a line of code was written. One feature, two screens and a button.
npx halfcycle Save a backup, update the search index, commit, all as one step. If the index step failed, the backup was discarded and the new content had already been written. The feature that exists to protect your work eats it, on the error path only.
Would a code review have caught it?
Almost certainly not. It needs one step to fail at one exact moment. This is the one that reaches a customer.
Restoring an earlier version of a document means two things have to happen together. The current version is saved as a backup, and the old version is written back in its place. The design put a third step between them: rebuilding the search index, inside the same database transaction, after the new content had been written and before the commit.
That ordering has a failure mode that only shows itself when something goes wrong. If the index rebuild fails, the transaction rolls back, and the rollback throws away the backup. But the storage layer underneath has already accepted the new content, and a rollback does not reach it. The document now holds the restored version, and the version it replaced is gone with no copy anywhere.
So the undo feature would have destroyed the thing it exists to protect. Not every time. Only on the error path, and only when the failure landed in that one window.
This is the one on the list that would have reached a customer. An ordinary test suite never fails the index step at exactly that moment, and a code review reads the path the diff shows, which is the one where everything works. You would hear about it from somebody who lost a document, long after the change went out, with nobody able to say when it broke.
Read the other seven, or the same argument in general terms: why an agent reviewing its own work is not enough.