Coldstart is in final cutover and has not been released. The behavior on this page runs in the development build; there is no release you can install today.
You have a rule you want to hold. "Never commit a secret." "Deploys need a human." "Use the client wrapper, not raw fetch." "Explain why this table has two timestamps."
There are four places that rule can live, and the wrong choice does not usually produce a loud failure. It produces a rule that is quietly inert, or one that is so loud it gets switched off.
[Visual 5.3 — The bottom band of the section frame, enlarged. Four boxes of identical size in one row, evenly spaced, with no arrows and nothing connecting them: the row has no direction. Each box carries a name and the same three labelled rows beneath it — "when it runs", "what it can decide", "how it fails when wrong". Box 1, "a checked assertion": after the fact, on demand · a condition derivable from what is on disk · reports a defect that already happened. Box 2, "a lifecycle hook": at one event, every time · this one pending call, from its own text · noise, then a reflex click. Box 3, "routed guidance": when something judges it relevant · a whole method, with context · silently not loaded. Box 4, "prose": when it is read · nothing; it explains · skipped at the moment it mattered. Beneath the row, spanning all four, one question in a bracket: "if this is skipped at the relevant moment, is that a defect or a judgment call?" A caption reads "four homes, not four rungs — the row is deliberately drawn flat".]
The four homes
| Mechanism | When it runs | What it can decide | How it fails when wrong |
|---|---|---|---|
| A checked assertion | After the fact, whenever the checks are run | Anything derivable from the state of the tree | Tells you about a defect that already landed |
| A lifecycle hook | At one event, every time, regardless of the conversation | Only what is visible in the one pending call | Fires on ordinary work until the prompt is answered by reflex |
| Routed guidance | When something judges it relevant to the request | A complete method, with all the context it needs | Is never loaded, and nothing reports that it was not |
| Prose | When someone reads it | Nothing — it explains and justifies | Is skipped at exactly the moment it mattered |
Read the columns rather than the order. These differ in when they get a chance to act and in what they can see at that moment, and those two properties are what should choose between them.
The fit test
Two questions, in this order.
If this is skipped at the relevant moment, is that a defect? If yes, prose and routing cannot be the only things carrying it, because both are allowed to be skipped and neither reports it. If no — if there is a real "is this relevant right now?" judgment inside the rule — then a mechanism that fires unconditionally is buying noise and maintenance in exchange for a guarantee nobody wanted.
Can the condition be decided from what the mechanism can actually see? A hook sees one pending call and its own text: it can recognise the shape of a command, not the wisdom of running it. A check sees the whole tree at rest: it can compare a generated file against its source, and it cannot intervene while the mistake is being made. If the condition needs judgment, context, or knowledge of what you are trying to achieve, then the answer to the first question was probably no.
Why this is not a ranking
It is tempting to read the four as a strength ordering and to treat moving a rule "up" it as hardening. That reading is wrong in both directions, and both directions have costs.
A deployment checklist is excellent routed guidance. Different stacks need genuinely different procedures, and the material is long, contextual and worth reading. Turning it into something that fires on every deploy-shaped command would not make it stronger; it would make it a prompt that appears when you are busy, and prompts that appear when you are busy get dismissed. Meanwhile the one part of it that really cannot be optional — that a production deploy stops for a human — is a single recognisable condition, which is exactly what the least optional mechanism is good at.
In the other direction, a pattern that recognises a deploy command cannot decide whether releasing right now is a good idea, and dressing that judgment in machinery does not create it. A rule pushed into a mechanism that cannot see enough to evaluate it becomes a rule that either fires on everything or on nothing.
There is also a real per-entry cost on the enforcing side. Each one needs a matcher, a decision about how it should behave when it breaks, a way to prove it fired, a test that can actually fail, and work on every platform it has to run on. That cost is worth paying for a short list and ruinous for a long one, which is why the lists in this product are closed and why adding to one is a deliberate act rather than a convenience.
They compose
The clearest example in the product is the planning-session contract, and it uses all four at once.
Prose explains why a planning pass writes plans and not code — the reasoning, which no mechanism can carry. Routed guidance holds the method for running such a pass, loaded when a request looks like planning. A hook refuses the off-surface write at the moment it is attempted, because a planning session that quietly starts writing code has produced exactly the outcome the contract exists to prevent. And a check runs the hook against synthetic calls to confirm it still refuses what it should and still permits what it should, because a guarantee whose only failure mode is silence needs something that can notice the silence.
None of those four replaces another. Remove the prose and the rule is arbitrary. Remove the guidance and the method is folklore. Remove the hook and the rule is advice. Remove the check and the hook can stop working without anyone finding out.
Limits
The fit test is a judgment, and nothing enforces it. There is no mechanism that catches a rule filed in the wrong home; the symptom is what you notice — a guard that everyone has learned to click through, or a convention that gets violated in every third session and is re-explained every time.
Nor does putting a rule in the least optional home make it true. It makes it fire. Whether the rule was worth having is a separate question this page has nothing to say about, and the mechanisms described here are indifferent to the answer.
Next
That is what holds a session steady. The next question is what to do when the plan itself turns out to be wrong: why iteration breaks the first-build magic.
How current this page is
Checked on 10 August 2026 against the product's check roster, its registered hooks, its mode-contract probe and its recorded release state. It describes how the four mechanisms are chosen between, not evidence that the choices made were the right ones. To ask whether a claim here still holds, or to report one that does not, write to [email protected].