08 / 08
The summary described a plan already thrown out.
Found before a line of code was written. One feature, two screens and a button.
npx halfcycle Three rounds of review had replaced that design. The one-line summary at the top, which is the first thing anybody reads, was never updated.
Would a code review have caught it?
No. Nobody goes back and re-reads a summary line. The next person builds from it.
The plans for this feature lived in a set of documents, and at the top of the set sat an index: one line per feature, saying what it was and how it would be done. That line is the first thing anybody reads, including whoever picks the work up next and any tool that turns a plan into a list of tasks.
Over three rounds of review, the design for restoring a document changed a great deal. The detailed plan was rewritten each time. The one-line summary in the index was not. It still described the first design, the one the reviews had thrown out.
Nobody re-reads a summary line, and that is the whole problem. It looks authoritative, it sits at the top, and once somebody has read it they never think to check it again. The next person would have built to it, which means building the version that had already been rejected.
The same feature showed why this kind of slip is common. Several of the later problems were introduced by the fixes for earlier ones. A fix gets written when its author is most confident and least suspicious, and that is exactly when a stale sentence somewhere else goes unnoticed. The method now requires every fix to list the other documents that still repeat the old idea, and summary lines are written once a plan is final, never while it is a draft.
Read the other seven, or the same argument in general terms: why an agent reviewing its own work is not enough.