This handbook describes a pinned review of Coldstart in active development. It explains the operating model and its limits; it is not an installation offer.
The first version of an app is often easy to explain to a coding agent: the goal is fresh, the project is small and there is little history to reconcile. Iteration changes the job. Each round adds decisions, exceptions, rejected approaches and handoffs. A small request can stay small in code while becoming expensive to understand safely.
Picture a small order-management app, a year in. The orders table has gained fields nobody planned for, an authorization model now decides who may see which orders, a caching idea was considered and rejected, and an old handoff still says that idea is next. Now a manager asks to download the orders on screen as a spreadsheet. The next session has to work out which customer fields may leave the app at all, apply the authorization boundary, preserve the rejected decision and notice the stale handoff before it changes anything.
Without Coldstart, a careful operator can still do this well: open the recent files, search notes, paste a handoff and ask the agent to restate the task. For a one-off project, that may be enough. The friction appears when the same reconstruction repeats, when two summaries disagree or when an important decision survives only in an old conversation.
Coldstart is an operating discipline for that repeated pressure. It gives one session a stated scope, stores durable facts in owned files, invokes selected checks at named moments and leaves a short saved address for the next session. The files and automatic checks wrapped around the work are the harness. They make the route and the evidence inspectable; they do not make the model smarter or guarantee a better result.
This handbook follows the export change through nine sections. You can read in order or start at the failure you already recognize. Each section landing states the section's claim, and its child pages take one part of that claim further without changing the vocabulary.
Choose where to start
How to use the map
If you want the complete operating loop, begin with Commands and continue in sidebar order.
If you arrived with a specific failure, start at its row. A blind session belongs in The work loop or Memory. Overloaded instructions belong in Guidance. A forgotten checkpoint belongs in Boundaries. A plan invalidated by new evidence belongs in Change. A green check whose meaning is unclear belongs in Upkeep.
The last row is not an appendix. Fit and limits governs every earlier section. A mechanism is useful only if it addresses a real recurring cost, and a claim is honest only while its evidence supports the exact sentence being said.
What this handbook does not promise
The pinned review supports descriptions of named mechanisms and selected exercised cases. It does not establish improvements in productivity or code quality, the disappearance of drift, a complete journey on every named coding agent, or a verified way to reconcile an existing project corpus. Section 9 keeps those boundaries beside the fit decision rather than hiding them in fine print.
Every page here is checked against that one pinned revision. The product has moved since the pin; the handbook keeps one shared evidence boundary instead of mixing revisions, so a page describes the build that was read rather than the build as it stands today.
Start reading
Begin with the commands. They show where planning, inspection, work, close and harness upkeep sit around one real session.