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.
Ask a coding agent how to do something and you get an answer. You get one whether or not a real method exists, because a confident guess and a genuine method read exactly the same on screen. This section is about that difference, and about a session being able to say it has nothing on file.
Your order app now has a durable record of its CSV-export work. A fresh coding session can find the approved fields and the authorization check, but that does not mean every reusable instruction should arrive with them. The session needs a small way to discover relevant guidance, then enough depth for this task and no more.
Coldstart separates short descriptions that are always present from instruction bodies that stay
on disk until selected. Think of a library desk: the catalogue is on the desk, the books are on the
shelves, and an honest NO-MATCH means the catalogue found no entry for this request — which is a
statement about the catalogue, not proof that no useful method exists.
The three pages
| # | Concept | What it covers |
|---|---|---|
| 4.1 | The resident floor | What is always loaded, why it is descriptions rather than instructions, and the one thing that is actually capped |
| 4.2 | Routed capability | How a request finds a method, and what the product returns when the library has nothing |
| 4.3 | Depth on demand | Why guidance is split into single-concept files, and how their cost is declared rather than assumed |
The choice without Coldstart
Without a routing layer, you can keep a short project instruction file and open specialist notes by hand. For a small app or a one-off export, that is often enough. The friction appears when the library grows: load everything and unrelated advice competes with the task; rely on memory and a useful method may sit unread.
Coldstart keeps only the catalogue descriptions in every session. That always-present set is the resident floor. Longer methods and explanations remain dormant until a description or query selects them.
What happens for the CSV request
The session asks for a reusable method to extend an existing CSV export without exposing a new
field. At the reviewed product boundary, the result is NO-MATCH with no near miss. There is no
CSV-export method in the declared catalogue.
That miss does not block the work. The session still has its project facts, the coding model's general ability, and the ordinary option of reading the relevant code and writing a local checklist. The receipt prevents one narrower failure: pretending that a nearby or plausible-sounding library entry is a method the product actually has.
The three parts
- The resident floor explains the short descriptions already present when the session opens.
- Routed capability explains how a request can select a reusable method or return an honest miss.
- Depth on demand explains why longer guidance is split so one relevant lesson can be opened without opening its whole family.
These parts make guidance reachable. They do not establish that a selected method is correct, the best available, or likely to improve the work. A manual checklist remains the simpler choice when the same specialized need has not started recurring.
The next section covers a different problem. Guidance may be skipped; a rule that must run at a particular moment needs a boundary carried by code.
Next
Start with the part that is always there: the resident floor.