vertical-slice-postmortem

vertical-slice-postmortem

A review round fixes the symptom; this skill fixes the cause. After a landed slice, it asks why each class of defect was written, hardens the recipe that should have prevented it and the test that should have caught it, and asks where the slice spent more tokens or wall-clock than its quality required. Run once per major slice so the system compounds quality and efficiency instead of relearning the same lesson.

The four goals in tension

The system pursues four goals at once, and they pull against each other:

1. Highest code quality: well-factored, correct, conformant.
2. Fewest tokens spent reaching it.
3. Fastest iteration: short build, verify, and review cycles.
4. Thorough review and test: proven well-factored and bug-free.

Goals 2 and 3 pull against 1 and 4. Another review round and more generated cases buy quality at the cost of tokens and time; fewer buy economy and speed at the risk of a defect. The balance is risk-proportionate: spend the extra round, the tokens, and the wall-clock where the blast radius is large or the input untrusted (the native edge, a query compiler, a security seam, a cross-module change), and economize where the unit is small and pure (a mechanical scaffold, a test-only phase, a single-module refactor). The lean default, the earned-second-round rule, and security-shifts-left are this principle at work. This retrospective is where the balance is re-tuned each slice. A finding that the slice was correctly balanced is a valid result; do not invent waste or risk to act on.

Stance: root cause, not symptom; prevention, not patch

• Every fix commit is evidence. A defect found in review is a defect the writing recipe let through and the test routine did not catch. The slice's fix commits and review findings are the raw material.
• Cluster, do not enumerate. Ten fixes for the same native-lifetime bug are one root cause, not ten. The improvement targets the class.
• Improve the source, including the tests. For each class, harden the write-time recipe (the relevant write-<lang>, write-ui), AND the test routine that would have caught it (write-tests, verify-lanes), AND, where cheap, the review dimension that found it, so the next catch is a lint or a unit test, not a costly round.
• Smallest sufficient change. A checklist line, a lane, a test pattern, not a rewrite. An improvement that would not have prevented a real defect this slice does not land. Do not bloat the skills.
• Be honest about the uncatchable. Some defects only a runtime or an interactive run can surface. Say so; do not pretend a lane covers what it cannot.
• Cost is evidence too. Wasted tokens and wall-clock are defects in the orchestration, not the code. A verbose return the caller had to hold, an invariant repeated in every dispatch, an expensive lane run per phase instead of per deliverable, a heavy model on a mechanical phase: each is a recurring tax the next slice pays. Cut it at the source like any other class, and only where the evidence shows the rigor survives the cut.