An Honest Ledger for a Borrowed Skeleton

Part 9 put PREVC next to its ancestors and found it honestly derivative — a phase structure assembled from parts that worked for decades, re-shaped around an implementer that no longer checks in. That leaves this series one obligation, and it is the one every series on this blog ends with: the retrospective on the thing itself. Not a summary — a ledger. What was borrowed, what was added, what the additions cost, what I can actually evidence, and what I would change. A workflow whose final chapter is a victory lap is a workflow nobody has run hard enough.

What was borrowed, said one more time

The credit from part 1, restated at the close because attribution that only appears once is attribution designed to be missed. The five phases — Planning, Review, Execution, Validation, Confirmation — and the scale-adaptive QUICK/SMALL/MEDIUM/LARGE routing come from dotcontext, formerly ai-coders-context, an MIT-licensed open-source agent-harness framework by Vinicius Lana of AI Coders Academy. The project has kept moving since I adapted it — upstream has since renamed the phases themselves — so the credit is to the project as I found and adapted it, not a claim about what it ships today. If the skeleton interests you, read theirs; it is alive and mine is a fork of an idea, not of the code.

Everything else this series described — the clarity/completion/complexity scores, the Code-Review-Simplify loop, the four breakout constraints, the hallucination taxonomy, the traceability treatment of Validation, the retrospective question tables, the limitations-and-imposed-constraints release documents, the methodology mappings — is my extension layer. Which means every weakness in what follows is mine to own, and there are real ones.

What the extensions buy, and the bill

The additions share one design intent: replace the checking that used to live in conversation with checking that lives in structure. The scores direct human attention before execution; the loop catches defects at package scale; the constraints stop the loop gaming itself; the matrix catches gaps at build scale; Confirmation stops the lessons evaporating. Where the skeleton says have gates, the extensions try to say here is what each gate inspects.

The bill is equally concrete, and I will itemise it rather than gesture at it.

Human hours at the gates. Review done properly is the most cognitively expensive hour of the cycle — part 3 argued it should be — and Validation's matrix is honest work even at spot-check depth. The workflow deliberately spends senior attention where an unstructured run spends none, and that is a cost you feel weekly even when it pays.

A documentation habit that must not rot. Confirmation's outputs are only worth writing if the next cycle's Planning actually reads them. The failure mode is a folder of retrospectives nobody feeds back — all of the ceremony, none of the circle. The design answer is that observations become harness artefacts rather than prose, but the design answer is not self-executing; a person keeps that promise or nobody does.

Self-graded metrics. The plan-readiness scores are produced by the same agent that produced the plan. They direct attention usefully — that is all I have ever claimed for them — but an agent can be confidently wrong about its own clarity in exactly the way it is confidently wrong about anything else. The scores are a searchlight, not an instrument reading, and anyone who starts gating mechanically on score thresholds has built a dial that the dial's owner can turn.

Process gravity. Any named workflow accretes ritual. The five phases were designed to bend to scale, but I have watched — in myself — the temptation to run the full ceremony because the ceremony feels like diligence. Diligence is what the work needed; the ceremony is what it got.

The gap I cannot paper over

Now the largest entry, and the reason this part exists. The workflow as this series describes it outruns the runs I can document. The pieces are practised: agent-generated breakdowns graded and reviewed, the inner loop with its exits, traceability passes at varying depth, release notes that name imposed constraints. The examples in this series — Rosterly, Ledgerline, Meterline, Relayline — are invented on purpose, built to teach each mechanism cleanly; the style of this blog is to say so plainly. What does not yet exist is a written, first-person account of one real piece of work travelling through all five phases, with the plan's actual scores, the loop counts as they fell, the gaps the matrix actually caught, and the retrospective as written that day.

That is not a small omission and I will not dress it as one. A workflow document describes intent; a lived run is evidence, and evidence is where descriptions go to get corrected. Every framework in part 9's table earned its shape from decades of documented runs; PREVC, as adapted here, has a described shape and an undocumented practice, and the honest register for that situation is the one I have tried to hold throughout — this is the design and its reasoning, never this is proven. The obvious repair is also the plan: the next substantial piece of work I ship goes through the full cycle with the ledger kept open, and publishes as a case study, numbers and embarrassments included. Until that post exists, treat this series as a well-reasoned proposal from the field, not a report of results.

When not to run five phases

The retrospective question I can answer with confidence, because the failure it prevents is one I have seen repeatedly, is when not to use this. The routing exists for a reason, and the reason is that process maximalism kills process.

A one-line fix does not want Planning; it wants QUICK — execute, then verify. A well-understood small feature wants SMALL: a plan and a verification, no formal Review gate. The full five phases are priced for work that is large enough to have a real plan, entangled enough that a human should challenge the plan, and consequential enough that its constraints will bind future cycles. Two rules of thumb from the series bear repeating at the close: Validation is the phase that never gets dropped, because a change too small to verify is how small changes cause large incidents; and the commonest routing failure is not choosing the wrong process but never explicitly choosing at all — MEDIUM work waved through on a QUICK ticket. If you adopt one sentence from ten parts, adopt the routing question: is this a tweak, a feature, or a product? — asked out loud, before the agent starts.

What I would do differently

Four entries, in the order I would act on them.

First, I would document a lived run before writing the reference version. The description-first order felt rigorous and produced the gap above; a case study first would have made every part of this series shorter and truer, and some of it different in ways I cannot yet know.

Second, I would start the metrics simpler. Three scores per plan is a satisfying design and probably more precision than the mechanism needs — the honest kernel is one question, where is this plan weakest?, and a single weakest-point annotation might buy most of the attention-directing value at a third of the apparatus. The three-score version should have been earned from evidence that one score was not enough.

Third, I would build the Confirmation templates on day one. The retrospective tables and constraint documents arrived last in my adaptation, which means early cycles leaked exactly the lessons the late phases exist to keep. The circle should have been closed before it was drawn.

Fourth, I would track upstream deliberately. The ancestor project renamed its phases while this series was being planned; an adaptation that never looks back at its source drifts into claiming originality by forgetfulness, which is the failure the crediting discipline exists to prevent. A once-a-quarter read of dotcontext's docs is cheap insurance on the ledger staying true.

Closing the circle

The series itself ends the way its subject does: output feeding back to input. If you arrived here without the beginning, the case for gates — and the forty quiet minutes that motivate everything — is where it starts: why agents need gates. The skeleton is borrowed and credited; the extensions are mine and priced; the evidence is owed and named. That is the ledger, and it balances only if I keep writing in it.