Coldstart is in final cutover and has not been released. The behavior on this page runs in the development build; there is no release you can install today.
A close is where a session's work either becomes a recorded result or stops being claimed as one. It happens in a fixed order: walk the checks the plan named, then hand a short composed record to the one tool allowed to write the project's live files, then let that tool run its own checks before anything is written.
The order is the point. Verification comes before recording, and recording is refused while a check is red.
[Visual 2.3 — The work-loop chain with the Close block enlarged. Inside it, a vertical check roster of five rows, each with a tick, a cross or a dash, feeding rightward into a single short record line drawn as one dotted entry. A gate symbol sits between the roster and the record line, labelled "a red check stops here". Below the gate, a small branch runs downward to a box labelled "checkpoint written: what is red, and the repair", tagged "no completion is recorded". To the right of the record line, a thin arrow continues into the Pointer block, which stays outlined.]
The problem it solves
The most common way for agent-assisted work to go wrong is not a bad edit. It is a confident report. A session that ends with a summary of what it did will describe intentions, and intentions read exactly like results.
Two things separate them. The first is a check list written before the work started, so it cannot be quietly shaped to fit what happened. The second is a rule that a failed check stops the close rather than being noted inside it.
What it does during a real session
It walks the plan's check list item by item. Each item is named as passed, not run, or failed. "Not run" is a real answer with its own consequences; it is not rounded up to passed.
A failed critical check ends the close. The choice is to fix it in this session or to mark the session blocked. Writing "done" over a red check is the specific outcome the whole stage exists to prevent.
It composes one short record. What was done, what comes next, the plan card it refers to, the files the next session should read, and any blockers. Every one of those fields has a length cap. The record is one line in the project's progress file, not a narrative of the session.
It hands that record to a single writer. One tool owns every write to the live files. Before writing anything that means completion, that tool refreshes the generated views of the project and runs the whole check roster itself, and refuses on a tree it finds unclean. A refusal names the defect. The correct response is to fix what it named and re-run, never to hand-edit a machine-written file until it passes.
A red gate still leaves something behind. Refusing used to mean nothing at all was written, which left a project with a red check and no record of why. Now a refused close first writes a minimal checkpoint: the blockers naming what is red, the next action naming the repair, and the section marked blocked. Nothing that means completion goes with it, so a retry after the repair advances the work exactly once.
Then it records, rolls and clears. The session record is prepended and older entries move to a monthly history file, the resume pointer is rewritten whole, and the session's local trace is cleared. The absence of that trace is how the next start knows the last session ended cleanly.
It surfaces the queue, and does not act on it. Open items recorded against places this session actually touched are printed at the end. Printing them is deliberate: draining them is a decision for you, on a visit you were already making.
The three answers a close can give
A close ends in one of three states, and they are kept distinct rather than blended into a percentage.
Written. The checks were walked, the gate was clean, and the record and pointer moved.
Refused. Something in the tree or the input is a defect. Either a check is red, in which case a checkpoint records the blocker, or the input itself is wrong, in which case nothing is written at all. Both are recoverable and both name what to fix.
Broken. The harness itself failed. That is reported as its own outcome rather than dressed up as a refusal, because the response is different: stop, and say so.
When to use it, and when not
Close a session when its outcome is either established or established as blocked. Both are results. A blocked close is more useful to the next session than an optimistic one, because it hands over an accurate reason rather than a plan that will not work.
Do not close to tidy up mid-session. The close rewrites the pointer and clears the trace; running it because the terminal is getting long produces a handoff that describes an unfinished state as a finished one.
Do not close to make a red check go away. The gate is not a formality to be worked around, and the supported repair is always to fix the tree rather than the record of it.
Limits
The gate checks the tree, not the work. It can confirm that the project's own checks are green and that its files are in the shape the product expects. It cannot confirm that the feature is correct, that the checks were the right ones, or that a passing check tests what its name suggests.
The walk depends on the plan. A check list written vaguely produces a vague close, which is why the planning pass refuses to scaffold "test it works".
The record is short by design, and short records lose detail. What crosses to the next session is a line and a pointer, not the reasoning behind them. Anything that must survive belongs in the project's durable record, written deliberately, which is a later section's subject.
Next
What the close leaves behind for the next session is one small file: the resume pointer.
How current this page is
Checked on 10 August 2026 against the product's current close behavior and its recorded release state. It describes what the close enforces, not evidence that closed sessions produce better code. To ask whether a claim here still holds, or to report one that does not, write to [email protected].