Coldstart is in final cutover and has not been released. This section describes how the development build behaves; there is no release you can install today, so read it as a description of the method rather than instructions you can follow tonight.
Everything in the previous section is something a session consults. Guidance is found, loaded and applied because something decided it was relevant. That is the right shape for most instructions and the wrong shape for a few.
This section is about the few. A rule that only holds when the model remembers it is not a rule; it is a strong suggestion with good intentions behind it. The test that separates the two is short: if the session skips this behaviour at the moment it matters, is that a defect or a judgment call? If it is a defect, prose cannot be the only thing carrying it.
[Visual 5 — One wide frame in three bands. The top band is a horizontal session timeline running left to right, with four solid marks on it labelled "session opens", "before a tool call", "before the window is compacted" and "at the stop", and a caption beneath reading "code runs here whether or not the conversation mentions it". The middle band sits under the second mark and shows one pending tool call entering a narrow gate, with three exits drawn as distinctly different shapes: a question-mark card labelled "ask — a human decides", a solid barred card labelled "deny — this does not happen here", and a plain open arrow continuing rightward labelled "silence — no rule matched, which is not approval". The bottom band is a row of four equal-sized boxes with no arrow between them, labelled "deterministic check", "lifecycle hook", "routed guidance" and "prose", and beneath the row one question in a bracket: "if this is skipped at the relevant moment, is that a defect?" A caption under the whole frame reads "three bands, three questions: when it fires, what it answers, and where it should live". Each page in this section enlarges one band.]
The three pages
| # | Concept | What it covers |
|---|---|---|
| 5.1 | The risk floor | The closed list of actions that stop, the three answers a pending call can get, and why silence is the interesting one |
| 5.2 | Hook timing | The four moments code runs regardless of the conversation, what each can and cannot do, and how a broken one is meant to fail |
| 5.3 | Where a rule belongs | Four mechanisms for carrying a rule, and the fit test that chooses between them |
The division this section is built on
There are two ways a behaviour can happen in a session, and they are not interchangeable.
Selection is the model's job. It reads what is available, decides something is relevant, and loads it. That is the whole of the previous section, and it is correct for anything with a genuine "is this relevant right now?" question inside it. It carries no guarantee that anything fires.
Activation is code's job. A closed set of behaviours run every time their moment occurs, regardless of what the conversation decided. Here "the model chose to skip it" is not a valid outcome; it is a bug report.
The two compose rather than compete. Code guarantees that something happens at all; judgment picks what is worth doing. A design that tries to put everything on the first is a maintenance tax with no end, and a design that puts everything on the second is a set of promises nothing keeps.
Why the closed list has to stay short
Both mechanisms in this section are closed lists that grow only by an explicit human act, and the reason is not tidiness.
A stop that fires often stops being read. Once a prompt appears on routine work, the approval becomes a keystroke, and a mechanism whose whole value is that a human looked at it has been trained into a reflex. That is not a hypothetical: the product's own list carries an exemption written after one class of matches fired on nearly every call in a project whose subject matter happened to be the thing being guarded. The noise was recorded, at the time, as the thing that kills a floor.
So each entry costs something permanent. It needs a matcher, a failure posture, a way of proving it fired, and a test that can fail. A behaviour that is merely useful does not earn that; it belongs in guidance, where being skipped is allowed.
What this section does not cover
It does not cover whether a rule is a good rule. Everything here is about making a chosen rule hold at a chosen moment. Nothing checks that stopping on a given action is wise, or that the list contains the right entries for your work.
It also does not cover what happens after the plan turns out to be wrong. A boundary holds a session inside its shape; it says nothing about changing that shape deliberately. That is section 6.
Next
Start with the list that actually stops things: the risk floor.
How current this page is
Checked on 10 August 2026 against the product's floor matcher, its registered hooks and its recorded release state. It describes where rules are enforced, not evidence that enforcing them there produces better work. To ask whether a claim here still holds, or to report one that does not, write to [email protected].