A prepared session assumes the plan is right. Sooner or later it is not. What should happen when the current plan becomes wrong halfway through?
Take the session adding CSV export to the small order app. The plan assumes the existing list query is the right source. Halfway through, validation shows that the query returns display-shaped rows: totals are formatted, notes are truncated, and the customer label is not a stable identifier. The approved export needs raw accounting values and stable IDs. The plan's central assumption is wrong.
The agent should not quietly pick a new data model, but the whole session does not have to freeze either. It can finish CSV escaping and authorization checks while the product choice waits for a human. Once the human chooses a dedicated export read model, the live plan is rewritten, an adjacent migration of historical data is queued, and the residue of the rejected path is inspected. An adapter created only in this session can be removed once its deadness is established. An older export file with uncertain consumers stays for human review.
Replace the live plan cleanly, account for displaced work, and subtract only what evidence and ownership make safe to remove.
Classify the contradiction before acting
A plan is a prepared hypothesis, not a command to ignore new evidence. When a load-bearing assumption fails, Coldstart's design asks two questions in order. This classifier is part of the product's design rather than something the installed harness prints at you: it is a discipline you and the agent follow, and the three labels below are how the design names its outcomes.
Does this require human judgment?
yes -> CHECKPOINT
no -> Is it inside the active scope?
yes -> ADAPT
no -> QUEUEThe order matters. A consequential product choice does not become ordinary technical work just because the relevant files are already in scope. In the export example, choosing between presentation rows and a dedicated raw-data model changes what the data means, what permissions need reviewing, and possibly performance. So it is a checkpoint: the agent records the question and what depends on it, then brings it to the human.
Adapting is for an obvious, non-judgment correction inside the owned unit, such as updating a plan after finding that a component moved without changing behaviour. Queueing is for valid, non-judgment work outside the current unit, such as a migration of historical records that deserves its own risk and verification surface.
These labels are only useful if they preserve responsibility. Calling every surprise an adaptation dissolves the prepared boundary. Calling every surprise a checkpoint turns the human back into a continuous supervisor. The classifier separates a decision about intent from a decision about scope.
Park the decision, not automatically the whole project
A checkpoint stops dependent work. It does not necessarily stop independent work. While the data-model question waits, the session can test CSV quoting, verify the endpoint's authorization boundary, or measure expected row counts. What it may not do is privately assume one answer and build a large branch behind the parked decision.
The test is dependency, not convenience. If a step would be thrown away under one plausible human answer, that step is gated. When no meaningful independent work is left, the checkpoint becomes a blocker and the pointer has to say so. If useful independent work remains, the session can continue without guessing.
This is what makes course correction compatible with bounded autonomy. The human keeps the consequential choice; the agent keeps momentum only where the answer cannot invalidate the work. A later session can resume accurately because the decision, its dependent work, and any blocker are written into durable state instead of being remembered from chat.
Replace current truth instead of stacking stories
After the human approves the dedicated export read model, the live plan should contain that plan and only that plan. Do not leave the obsolete checklist beside it with strikethroughs. Do not append a second block and leave the next session to infer which one governs.
A clean replacement has four parts:
- Rewrite the active steps around the dedicated read model.
- Repoint the next action and the reading list at the new evidence.
- Record a short outcome saying why the assumption changed.
- Put the load-bearing product rationale in its durable decision home.
History is not destroyed by this. Version control preserves the exact old wording and the transition. The point is to move history off the current-control surface, so that the active plan is allowed to mean the current plan.
That distinction matters most across sessions. A small pointer locates the active plan; the plan names the current evidence; the evidence constrains the work. Appending an incompatible plan breaks the chain. Rewriting it leaves one honest route for a fresh session.
Account for every displaced piece of work
Changing the plan creates an inventory problem. Some work belongs in the replacement plan, some is real but adjacent, and some exists only because of the abandoned approach. None of it should be left as an informal promise in chat.
In the example, backfilling historical customer IDs is a migration. It matters, but it is not the same unit as building the export path for records that already have complete data. The session puts it in the durable open queue, keyed to the export area, for an explicit decision later.
A location key improves reachability. It does not prove identity or provenance. The project's own history contains a concrete warning: two old queue labels were later reused for unrelated defects. A later reader cannot safely treat a short label alone as permanent identity. The subject, the owning location, and the committed evidence still matter.
The queue is also not a knowledge warehouse. A lasting product reason belongs in its decision card. The queue holds open action, and completed lines leave it with version control as the archive. Nothing currently proves that every location-keyed item drains automatically, so a queued item is an honest disposition rather than a promise that the system will finish it on its own.
Prove deadness, then ask whether the deletion is yours to make
The residue of a pivot should not be kept forever just because deleting it feels risky. Nor should a clean text search become permission to erase anything that looks unused. Coldstart separates two questions: does the evidence support deadness, and does this session own the deletion judgment?
The deadness gate asks for all three of these:
- No live references are found.
- The candidate is not an entry point such as a route, command, hook, public export, fixture, or test.
- The candidate is not reached dynamically through configuration, registration, reflection, or a string key.
Failing to establish any part means "not proven dead". Even when all three pass, provenance still controls the action. The presentation-row adapter was created in this session, solely for the rejected approach. It is current-session exhaust, so the session may remove it, record the deletion, and rely on version control as the recovery net.
An older export module that predates the pivot is different. It may have an external batch consumer that the repository cannot reveal. Editing a file, or being the one to find it, does not grant ownership over its history. It stays, and it reaches a human together with the evidence and the unresolved entry-point question.
Structural tools support this judgment without replacing it. Scans for broken references can find named broken relationships, and generated maps can be rebuilt from surviving sources. Those checks cover the forms they enumerate. They are not a complete call graph, a provenance system, or an automatic garbage collector.
One boundary is worth stating exactly, because it is the difference between a design and a guarantee. The cleanup step in the shipped product reports and proposes. It does not apply the provenance rule for you and then delete something. The gate above is the standard the proposal is judged against, and a human still approves the subtraction.
The example from start to finish
The session begins with one prepared outcome: an authorized account manager can download the orders visible under the existing filters. Implementation starts against the existing list query. Validation then exposes the wrong data-shaping assumption.
The session classifies the product choice as a checkpoint and asks whether the export should mirror screen rows or use a dedicated read model. It parks all data-path work but continues the independent escaping and authorization checks. The human chooses raw approved fields and stable identifiers.
The agent now replaces the old steps in place, repoints the reading list, records the rejected assumption, and saves the rationale with the export-field decision. It does not keep both plans in the live file.
The choice exposes the migration of historical IDs. Because that work is adjacent rather than required for the current endpoint, it is queued rather than absorbed as silent scope growth. The session records its subject and location without treating a short queue label as durable identity.
Then comes subtraction. The adapter created in this session has no references, no entry-point role, and no dynamic registration. Its provenance is clear, so it is removed. The older export module has no obvious references but uncertain provenance and a possible external consumer, so it is retained for human judgment.
Finally the session regenerates the affected maps, checks the selected references, and verifies the new read model, the approved fields, authorization, and escaping. Its handoff can be precise:
current plan: dedicated export read model
queued: historical customer-ID migration
removed: session-created adapter, after deadness and provenance checks
retained: older export candidate; external entry point unresolved
verified: approved fields, authorization, escaping, maps, selected referencesThe project changed direction without creating two live plans, hiding displaced work, or claiming more certainty about deletion than the evidence supports.
What this does not claim
Location and reference evidence are deliberately narrow. A queue location does not establish stable item identity, and the reused labels in the project's own history are evidence against assuming it does. A clean search cannot rule out arbitrary entry points, dynamic dispatch, configuration, or external consumers. Map and reference checks can prove selected structural relationships at a named boundary. They cannot prove that a deletion is semantically safe. Old or foreign material therefore keeps a human provenance gate. The current evidence also does not establish that this discipline improves productivity, speed, code quality, or user outcomes.
Next
That is the whole discipline. Whether it is worth its cost on your project is a separate question. Continue with Proof, cost, and the fit decision.
How current this page is
To ask whether a claim on this page still holds, or to report one that does not, write to [email protected]. The date above is when the page was last checked against the product, not when it was written.