Coldstart 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.
The export session can reason through ordinary serializer work with project facts and general skill. Some actions are different: publishing a deploy, changing the schema, or committing a secret should not depend on the model remembering the right sentence at the right time.
Coldstart places selected rules at named moments in the session. A lifecycle event is one of those moments, such as the instant before a tool call runs. Code attached there can ask a human, deny a narrow violation, or say nothing because no represented rule matched.
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 ordinary alternative
You can put every rule in a prompt, checklist, or project instruction file. That is often right for guidance that needs context: which columns to export, how to name them, and which test best explains the behavior. The reader or model may skip it, so it is the wrong only home for a selected rule whose absence at a specific moment would itself be a defect.
Coldstart separates two responsibilities:
- Human or model judgment decides which contextual guidance is useful.
- Lifecycle code runs at a declared moment whether or not the conversation remembered it.
- Read when the reader or model selects it
- Right for guidance that needs context: which columns to export, how to name them
- Skipping it may be a judgment call rather than a defect
- Nothing marks the moment it was skipped
- Runs when its registered moment fires, whatever the conversation remembered
- Three observable outcomes on a pending call: continue, ask, deny
- Costs a clear trigger, failure posture, evidence and a test that catches it breaking
- Does not establish that the represented list is complete or the rule wise
When its registered event fires, lifecycle code makes the represented behavior independent of conversational selection. It does not establish that the registered path fired in this session, that the represented list is complete, or that the rule is wise.
One export, three outcomes
| Pending action | Observable outcome | Who decides next |
|---|---|---|
| Edit the ordinary CSV serializer | No floor rule matches; the call continues silently | The coding session |
| Deploy the export to production | The call pauses and asks | A human |
| Commit a protected environment file | The call is denied | The rule already records this narrow refusal |
Silence is not approval. It says only that no represented rule matched the pending call. A novel or poorly expressed consequential action can still pass unnoticed.
Why not automate every useful rule
Every unconditional stop has a permanent cost. If it fires on routine work, people learn to approve it by reflex. Each entry also needs a clear trigger, failure posture, observable evidence, and a test that can catch it breaking. Most advice belongs in routed guidance or prose because skipping it may be a judgment call rather than a defect.
The next pages separate the three floor outcomes, the four lifecycle moments, and the choice among checks, lifecycle code, routed guidance, and prose. They explain where a chosen rule can live, not whether every chosen rule is correct.
Next
Start with the gate before a pending action: the risk floor.