Coldstart is in final cutover and has not been released. This section describes the method and development build at the source revision named above; there is no release you can install today.
A plan is a prepared account of what the work is expected to be. It is useful because it makes an outcome, a boundary and a verification path visible before implementation starts. It is not useful if it becomes a reason to ignore evidence that arrived after it was written.
This section begins at that moment: a load-bearing assumption turns out to be wrong, a better local route appears, or valid adjacent work surfaces outside the active unit. Coldstart's answer is not "follow the plan anyway" and it is not "rewrite everything while the context is warm." It is a small sequence: classify the change, preserve the work that still has an owner, replace current truth cleanly, then inspect what the rejected path left behind.
[Visual 6 — One wide frame read from top to bottom. Top band: a card labelled "new evidence contradicts the plan" enters a two-question gate. The first question is "does this need a human judgment?" Its yes branch ends at a parked card labelled "checkpoint". Its no branch reaches "is it inside the active scope?" and splits into "adapt" and "queue". The three exits are equal-sized and have no implied ranking. Middle band: one queue item with five visible fields, "identifier", "severity", "action", "optional evidence" and "owning location", sits outside the active-session box. Two return paths reach it later, labelled "next visit to that location" and "section close". Bottom band: one subtraction candidate passes three separate gates labelled "zero live references", "not an entry point" and "not dynamically reached", then reaches a provenance fork. "Created by this session's rejected path" leads to "remove and record"; "older or foreign" leads to "human decision". A caption beneath reads "change has three jobs: classify the seam, keep open work reachable, and prove what can leave". Each page in this section enlarges one band.]
The three pages
| # | Concept | What it covers |
|---|---|---|
| 6.1 | Divergence | The fixed-order classifier, why a checkpoint parks a decision rather than automatically halting the project, and how the live plan is replaced |
| 6.2 | The open-work queue | How valid work outside the active unit gets an owning location and returns on a relevant visit or at close |
| 6.3 | Safe subtraction | The three deadness checks, the provenance fork, and the boundary between a proposal and permission to delete |
One change, three different responsibilities
The first responsibility is deciding who owns the seam. Some surprises are technical corrections inside the unit already approved. Some are useful work outside it. Some change the meaning, risk or direction of the work and need the person steering the project. Treating all three alike either lets scope spread silently or makes the human answer routine implementation questions all day.
The second responsibility is keeping displaced work reachable without treating it as current scope. A queue item is not a casual reminder at the foot of a chat. It has a short action and a location that owns it, so the work can return when the project next enters that area. Completed items leave the open queue; version control keeps the history. That makes the file a view of work that is still open, not a diary of everything that ever happened.
The third responsibility is subtraction. A rejected approach can leave adapters, scaffolding, references or draft structure behind. Keeping all of it forever makes every later session pay for a decision the project already rejected. Deleting it merely because it looks unused is worse. The method therefore separates evidence of deadness from authority to act on that evidence.
These responsibilities form a sequence, but their outputs stay distinct. A consequential decision is a checkpoint, not a queue item. A queue item is open action, not a permanent product fact. A clean reference search is evidence about one candidate, not a general permission to tidy the area.
The order protects the expensive seam
The divergence gate asks about human judgment before it asks about scope. That ordering is the centre of the method.
If scope came first, a consequential product choice inside the current files could be labelled an adaptation and disappear into implementation. In a small orders application, discovering that the planned export source contains display-shaped rows is not merely a path correction. Choosing raw fields, stable identifiers and the authorization boundary changes what the export means. It needs a human call even if every relevant file was already named by the plan.
Once judgment is ruled out, scope is the cheaper question. An obvious correction inside the active unit can be made and recorded. Valid adjacent work can be queued. A mistake between those two can be repaired without having made an unapproved product decision.
Change does not make the session unbounded
Classification exists to preserve the active unit, not to create an exception to it. An adaptation does not mean "anything discovered while working is now in scope." It means the correction needs no new human decision and still serves the approved outcome. A queue does not mean "probably later." It means the work is real, not owned by this unit, and has a durable place from which to return.
A checkpoint behaves differently again. The question is parked, its dependent steps stop, and independent work may continue. The project halts only when every meaningful remaining step depends on a parked answer. Continuing by guessing is not independent work; it is building behind an unmade decision and hoping the answer later agrees.
After the answer, the live plan is rewritten rather than surrounded with abandoned alternatives. The next action and reading list move with it, the session records the change, and a load-bearing rationale gets a durable decision home. Version control keeps the old plan. The current file is allowed to mean current truth.
The queue and the sweep close different leaks
Course correction can leak in two directions.
Work that still matters can vanish because it no longer belongs to the revised session. The queue closes that leak by giving the action an owner and a return path. Material that no longer matters can remain because deletion feels harder to justify than addition. Safe subtraction closes that leak with evidence and provenance.
Neither mechanism promises perfect automation. A location key makes an item findable; it does not prove the item will complete itself. Three deadness checks reduce uncertainty; they cannot reveal an external consumer the repository does not contain. The current cleanup entrance reflects those limits: it runs checks, reads the queue, groups findings and proposes repairs. Structural deletion still belongs to the human unless the rejected material is provably this session's own exhaust.
What this section does not claim
The classifier is a discipline, not an oracle. It cannot mechanically recognise every judgment seam, and a plan can still be revised badly after the right branch is chosen. The queue proves that an action has a named home, not that it is important, current or guaranteed to be done. A clean search proves only what the search can see. Dynamic dispatch, configuration, external entry points and older ownership can all keep apparently unused material live.
This section also does not establish that the method improves speed, code quality or project outcomes. It describes the product's change-handling contract and its limits.
Next
Begin at the moment reality departs from the plan: divergence.
How current this page is
Checked on 10 August 2026 against the pinned product revision's iteration design, live open queue, cleanup instruction and cleanup design. The product has moved since that pin; sections 1 to 5 use the same revision, so this section keeps it rather than mixing source snapshots mid-handbook. To ask whether a claim here still holds, or to report one that does not, write to [email protected].