Divergence

A prepared plan is a hypothesis about the work. Divergence is the moment new evidence contradicts something load-bearing in that hypothesis: the data source has different semantics, the safe route needs a product choice, a named file moved, or an adjacent defect appears while the session is open.

The important question is not whether the plan changed. Plans should change when their evidence changes. The important question is who owns the decision and whether the resulting work belongs in the active unit.

[Visual 6.1 — The top band of the section frame, enlarged. A card on the left reads "divergence: new evidence does not fit the active plan". It enters question 1, "does resolving this need the human's judgment?" The yes branch rises to a parked card labelled "CHECKPOINT: record the question and what it gates; keep working only around it". The no branch continues to question 2, "is the correction inside the active section's scope?" Its yes branch ends at "ADAPT: make the correction and name it in the session outcome". Its no branch ends at "QUEUE: write one owned open action and continue". Beneath the gate, the fixed order is repeated as a short rule: "judgment before scope". No branch is coloured as success or failure. A caption reads "three dispositions, chosen by two questions in one order".]

The classifier

Coldstart asks two questions in a fixed order:

Does resolving this need the human's judgment?
  yes -> CHECKPOINT
  no  -> Is it inside the active section's scope?
           yes -> ADAPT
           no  -> QUEUE

The first question is about authority. It catches a fork whose answer changes intent, product meaning, risk, public behaviour or another choice only the person steering the project can make. The second is about ownership. It separates a technical correction that still serves the approved unit from valid work that needs a different unit.

This order is deliberate because the two mistakes have different costs. Misclassifying a human decision as ordinary work can let a session build an entire branch behind an assumption nobody approved. Misclassifying non-judgment work as in scope or out of scope is usually visible and cheap to correct. The gate checks the expensive seam first.

Checkpoint: the decision stays human

A checkpoint is exactly a divergence whose resolution needs human judgment. It is not every surprise and it is not a synonym for blocker.

Consider a session adding CSV export to an orders application. The plan assumes the existing list query is the correct source. Validation shows that it returns display-shaped rows: values are formatted, notes are shortened, and the customer label is not a stable identifier. The requested export needs approved raw values and stable IDs.

Choosing between reproducing the screen rows and building a dedicated export read model changes what the exported data means. It may also change the authorization review and performance shape. That is a checkpoint even if the relevant query is already inside the planned files. The agent records the question and what depends on it, then leaves the choice to the human.

The checkpoint parks the decision, not automatically the whole project. CSV escaping, authorization assertions or representative fixtures may be independent of the read-model choice. They can continue. Work that assumes one answer cannot. The safety rule is simple: work around a parked decision, never on top of a guessed answer.

Only when every meaningful remaining step depends on parked decisions does the project halt. At that point the questions are surfaced as a batch, with their dependent work named. If the session ends first, the open decisions become the first thing the resume pointer reports, rather than a memory trapped in the old conversation.

Adapt: correct the route without changing the outcome

An adaptation needs no human judgment and stays inside the active scope. It might correct a file path after a component moved, replace a local implementation detail with the codebase's established pattern, or revise a step whose assumption was plainly disproved without changing the product call.

The session makes the correction and names it in its outcome. It does not ask for approval merely because reality was more detailed than the plan.

That branch is narrow. "I found it while working" does not make a change an adaptation. A new feature, a broader user-visible behaviour or a different risk boundary still needs classification. The test is whether the correction serves the approved outcome without adding a decision seam, not whether it feels convenient to finish now.

Queue: keep adjacent work without absorbing it

A queue item also needs no human judgment, but it falls outside the active unit. In the export example, a historical-ID migration may be valid work after the dedicated read model is chosen. If the current endpoint can serve records that already have stable IDs, the migration is adjacent work with its own data risk and verification needs. Quietly adding it would turn one session into two.

Queueing preserves the action without changing the session. The item gets a short description and an owning location, then the current work continues. It is not a lower-priority checkpoint: no decision is waiting inside it. It is also not a promise of automatic completion. The next page describes what the queue can and cannot guarantee.

Replacing the plan after the branch is chosen

Once a checkpoint is answered, or an adaptation is established, the active plan needs one current story. Coldstart's design uses four bounded moves:

1. Rewrite the affected plan block in place around the new route.
2. Repoint the next action and, if the working slice moved, its reading list.
3. Record the change in the session outcome.
4. Put a load-bearing rationale in the feature's durable decision home.

The rejected block is not left beside the replacement with strikethroughs, and a second plan is not appended underneath it. Version control already preserves the exact old wording and the diff. The live plan's job is to tell the next session what governs now.

This is more than document tidiness. A resume pointer locates the active plan, the plan locates the current evidence, and that evidence constrains implementation. Two incompatible plan blocks break the chain at its centre. Replacing the block preserves one route from a fresh start to current truth.

The change also opens a subtraction question

Rewriting the plan closes the document half of a pivot. It does not automatically close the code or content half. A rejected approach may have left an adapter, a temporary projection, a draft page or scaffolding behind.

That material is not deleted as part of classification. It becomes a candidate for the evidence and provenance test in safe subtraction. Keeping the jobs separate is important: recognising that the plan changed is not proof that every artifact associated with the old plan is dead.

What this page does not claim

The gate does not mechanically detect every divergence, and its labels do not make a poor decision good. A session can fail to notice that an assumption was load-bearing, call a product choice a technical detail, or claim work is independent when it is not. The classifier makes responsibility explicit once the seam is seen; it does not guarantee the seam will be seen.

Nor does a checkpoint make a human answer safe. It establishes who decides, not what they should decide. Verification still has to represent the chosen behaviour after the plan moves.

Next

Follow the branch that preserves real work outside the session: the open-work queue.

How current this page is

Checked on 10 August 2026 against the iteration design at the pinned product revision. It describes the divergence design and the method's limits, not evidence that the classifier improves project outcomes. To ask whether a claim here still holds, or to report one that does not, write to [email protected].