Checkpoint

Checkpointing

A verdict with evidence, not a status update. This is the mechanism that answers the question the whole pipeline exists for: is what is being built still the thing that was asked for?

Nobody notices drift from inside a task. Every task can be correct, verified and on time while the sum of them quietly becomes a different product. Only a scheduled diff against the charter catches that, and only if it is adversarial (P-32): the question is "what would have to be true for this to have gone wrong, and is it?" — never "does this look about right", which it always will.

1. Does what exists satisfy the charter?

Walk every charter goal down the chain and record what you find at each step. Do not skip a goal because you remember it being handled.

G-n  →  the R-n that satisfy it
     →  the tasks that discharged those
     →  the acceptance evidence ACTUALLY RECORDED in their reports

A goal you cannot walk down that chain is the finding, and it does not matter how confident anyone is that the work was done. "Discharged" means the acceptance criterion was run and its output is in the record (P-5).

python3 "${CLAUDE_PLUGIN_ROOT}/scripts/check_trace.py" .
python3 "${CLAUDE_PLUGIN_ROOT}/scripts/check_refs.py" .

Then go past what the scripts can see: read the acceptance criteria and ask whether what was built actually satisfies them, rather than whether a command exited zero. A test can pass and still not test the requirement.

And ask the question no script can: do the requirements under this goal cover it, or merely exist under it? A goal that quantifies — "any failure", "every field", "all responses" — answered by requirements that enumerate two cases is a goal that will keep producing surprises, one per missed member. The trace is clean and the goal is half built. When you find one, the finding is not the missing case; it is the requirement's shape, and the fix is to restate it as a rule with the cases as its tests.

2. What diverged, and did anyone decide it?

Divergence recorded as a D-n is normal and healthy — plans meet reality. Divergence nobody recorded is what this exists to catch.

Read the diff since the last checkpoint against the plan that was approved:

• something built that no requirement asked for → scope creep, or a requirement nobody wrote down
• something in a requirement that quietly did not get built
• a decision visible in the code that is in no D-n
• a task whose scope grew

For each: decided, or drifted? Say which, with the path and line.

3. What proceeded without the client?

Every REVERSIBLE question the loop settled on its own recommendation (P-27) — from the board's Decided without the client table and the record.

List each with what was decided and whether it is still cheap to reverse. That last column is the one that matters: a reversible decision stops being reversible once six tasks are built on it, and this is the last moment it is free.

This section is why the autonomy is honest. If it is empty because nothing timed out, say so. If it is long, that is a signal the escalation window is too short or the client is not reading their batches — and that is worth saying too.

3b. Was the priority order honoured?

If the charter names one (P-20b), every decision that traded one priority for another should cite it and say which was sacrificed. Read them. A sequence of individually reasonable trades in the same direction is how a project ends up fast and unsafe with nobody having decided that — no single decision looks wrong, and the drift is only visible in aggregate, which is here.

Anything that sacrificed the highest priority should have been a CHARTER question and stopped for the client. If one did not, that is the finding.

3c. Has the verification layer ever rejected anything?

Every check in this pipeline ships a negative control, because a check that has never failed has not been shown to work (P-35). The verification layer is held to no such standard, and it is the layer everything else rests on.

Count it:

grep -coE "verify [A-Za-z0-9-]+ PASS" devteam/RECORD.md
grep -coE "verify [A-Za-z0-9-]+ FAIL" devteam/RECORD.md

A project whose verify step has never returned FAIL is indistinguishable from a project with a rubber stamp, and you cannot tell which one you have by reading the verdicts — only by counting them. On the project where this was first measured the answer was nine verdicts, seven PASS and two FAIL, both on the same task. That does not prove no verifier ever waved something through; it proves the layer can reject, which is the whole of what a negative control establishes anywhere else.

Report the ratio in the checkpoint whatever it is. Zero FAILs is not a finding on a small project — it is a question about whether the bar has been tested, and the answer may honestly be "not yet". Treat it as one number that must be looked at, not as a threshold to pass.

This step can only count what the briefs asked for, and that is not a caveat — it is the thing most likely to make it lie. A clean §3c produced by verifier briefs that never invited disclosure looks exactly like a clean §3c produced by verifiers with nothing to disclose. The count is not a measurement of the verification layer; it is a measurement of the layer as the briefs shaped it. So read one dispatch before you believe the number, and if the briefs did not ask for gaps as a result, say so here instead of reporting a ratio.

Then ask what the verifiers could not do. A verifier that quietly downgrades an independent rebuild to an independent reading and reports PASS is indistinguishable from one that rebuilt, and nothing downstream can tell them apart. The mitigation is in the dispatch, not here: a verifier brief asks for "anything you could not reproduce" as a result rather than as an apology, and says plainly that a disclosed gap is worth more than an undisclosed workaround. Read the record for those disclosures and list them. A gap you can see is not the risk; its invisibility would have been.

What stays unknowable by construction is whether a verifier had a gap it did not disclose. The only mitigation for that is the two independent layers, and an undisclosed gap would have to be common to both.

3d. What did the manager's own rotation cost?

Only when a rotation has happened since the last checkpoint (run §7b). Two numbers, both from commands, both filed under ## Rotation:

• the manager's own reading, from its own transcript:

  python3 "${CLAUDE_PLUGIN_ROOT}/scripts/session_cost.py" --json
  

  This is the manager's meter and it is not the workers'. The harness writes a budget.json per sandbox; those are what the workers spent. A dispatching project spends the quota twice and the two are metered differently — report both, never one as the other, and never their sum as a single figure. A manager session begins at a rotation, so its whole-session figure is its figure since the last rotation and there is no window to subtract.

• the questions asked at the handoff — the count of record defect: lines the incoming session logged under the day's RECORD.md entry (resume §0). Zero is a claim about the record, not an absence of data, and it earns more suspicion than a large number does: a successor that asked nothing either inherited an unusually complete record or did not drive.

Neither number decides anything yet, and one rotation cannot tell you whether the cadence is right. They accumulate for §4.

4. Is the plan still right?

• requirements that turned out wrong — and whether anyone said so

• tasks that were mis-sized — estimate against measured (P-41). A task that cost triple is a finding about the plan, not just a number

• dependencies that actually bound, versus what the graph predicted

• findings that recurred across more than one task — the same mistake twice is a process problem, not two accidents

• currency rows now stale (P-37)

• the rotation cadence, once three rotations exist — read the pairs of numbers in the filed ## Rotation sections (§3d) against each other. A manager reading that barely moved between rotations says the cadence is tighter than it needs to be; a handoff that took many questions says the record is thin, which is a defect in the record and not an argument about the interval. Fewer than three rotations and there is nothing to read — say that, rather than fitting a line to two points.

  The target is one compaction per manager, and it is a client-stated budget, not a derived one. One compaction costs little; after two, enough useful context is gone that the session re-reads the source anyway, which is the cost the rotation was meant to avoid, paid twice. Rotating before the first is usually spending a rotation for nothing.

  And judge the cadence on cost as well as on context, because the two come apart. Usage scales with context size times request count, so a manager's cost grows superlinearly in its own length — measured on a real account, 52% of a week's usage came from sessions running 8+ hours. A manager can therefore be worth rotating while its context is still healthy, and a cadence argued only from compaction risk will rotate too late

5. The verdict

Be willing to write DRIFTED. A checkpoint that has never returned anything but ON-COURSE is a checkpoint nobody should trust — it has not been shown to be capable of failing, which is the same standard the checks are held to (P-35).

6. File it

devteam/checkpoints/C-n-<date>.md, from ${CLAUDE_PLUGIN_ROOT}/templates/checkpoints/CHECKPOINT.md. Commit it, and add checkpoint C-n <verdict> to RECORD.md.

Never edit a filed checkpoint. A checkpoint that could be revised in the light of later events is not evidence of anything — it is a description of what was believed after the fact. If it was wrong, the next one says so.

The final checkpoint (GATE 4)

Four rules on how this document is written, before anything about what it contains. GATE 4 requires five count-and-enumeration pairs in one document — every done-means with its evidence, every requirement discharged or struck, every decision the client never reviewed, cost against estimate, and what is knowingly left undone. That is the shape of the worst writing failure this project has recorded, five times over, in the document written last — by whoever has just spent a run cataloguing that failure and is therefore most likely to believe they are immune to it.

The backwards pass has a mechanical half now, and it runs before the reading half. check_trace's amendment-omits-condition diffs the charter's current done-means and constraint rows against the latest amendment's Re-affirmed. enumeration (P-48), so "an amendment forgot a condition" is answered by a script rather than by this document noticing. Run it first and paste the output. What it cannot answer is whether a condition re-affirmed as holds actually still holds — that is the reading half, and it is the questions below. The check exists because a project learns forward only: three amendments in a row once left a done-means condition undischargeable, and every one of them was correct about what it changed.

1. Every count is produced by a command run at the moment of writing, with the command named beside the number. Never a figure carried down from earlier in the record: every one of those was true when it was written.
2. Every enumeration is read off the same output as its count. One run, one command, one sitting. A total and its members are two claims, and the second is the one nobody re-derives — because the first one's provenance launders it.
3. No completeness claim unless the full set is printed above it. "And nothing else" is a statement about a set, writable only by somebody who has just read the set.
4. Name the commit this was written against, and re-run the checks at signing with their output pasted rather than summarised.

None of these asks you to be careful, and that is the point. They ask for a command on the same line as its number — which is visible in the finished document whether or not you were careful, so a reader can check compliance without re-running anything. That is the only property that survives the fact that attention does not: five times here somebody committed a failure in the same artifact where they had just documented it.

They are written down rather than remembered because a mechanism that depends on an agent recalling it at the moment of writing is not a mechanism.

Walk the run's lessons backwards over the documents written before them. This is the only moment every requirement, goal and criterion is read at once, and it is the last one — there will not be another pass over the artifacts this project wrote early.

A project learns forward only. Three measured instances of the same gap: a charter signed before a template gained a row never acquires it; a manifest written for one purpose is never re-read for another; and a lesson about how to write an acceptance criterion is applied to every subsequent criterion and never backwards over the ones already in the file. Documents get written once and improved only where somebody happens to be standing.

Most of that cannot be checked — telling a criterion that names a method from one that names a property is the semantic reading this project refuses everywhere. The measured case: a requirement whose acceptance said parse with ast, collect the roots, assert each is standard library. A test doing exactly that over six of the seven shipped modules satisfies every word of it and reports green. A criterion that names a method cannot detect under-application of that method.

So this is not a check, it is a reading, and these are the questions worth spending it on:

• Which acceptance criteria describe a practice rather than an obligation to demonstrate? The good form is not "the tests are marked" but "every unmarked case appears in the guard's input set or carries a named exclusion."
• Which documents predate a decision that would have changed them, and were never revisited because nothing pointed at them?
• Which artifacts were written before the rule they should follow existed? The first requirements in a project are always the least informed, and nothing in the loop ever goes back.

At delivery, the same procedure plus:

• every DM-n from the charter's "Done means", each with its evidence
• every requirement discharged or explicitly struck with a decision
• the complete list of decisions the client never reviewed
• total cost against the original estimate
• what is knowingly left undone, and why

Then the client chooses one of three, and they are different things:

• accept — the cycle is closed and the project is done;
• amend — findings come back as new requirements under the same goals, which is a charter amendment (P-2) and not a bug list;
• iterate — the goals held, and using the thing taught something the specification could not. /devteam:iterate opens the next cycle carrying the charter, decisions, record and audits forward.

Offer the third explicitly. A client who is not told iteration exists will either ask for a bug fix that is really a redesign, or start again from an empty directory and throw away every decision this cycle recorded — and the second cycle's whole advantage is that the first one's reasoning is still on disk.