System reference
System reference
The authoritative description of how the coding planner works, in seven parts: concepts, the leaf route, containers, the driver and its hosts, doctrine, what is not built, and configuration.
This reference describes how the coding planner works. It is written for someone who has not read the code and was not present for any of the sessions that built it. Every term is defined where it first appears.
The coding planner is a machine for carrying coding work from a rough intention through to finished code sitting on a branch you trust. Today a person can drive it step by step. The design goal is that a person does not have to: you hand it work and find the work done. That goal is why almost every decision in this reference leans the way it does, and it is worth stating plainly before the mechanism, because the mechanism only makes sense in its light. A checkpoint that a human must clear is fine when a human is watching. When nobody is watching, a checkpoint that cannot prove its own answer is either a stall or a lie.
The parts
| Part | What it covers |
|---|---|
| Part 1: The concepts | How work is broken into campaigns, containers and leaves; the two entry doors; the three routes; commands, floors and gates; refuse against escalate; worktrees; wave and deep modes; how work lands. |
| Part 2: The leaf route | The four steps where code is written: generate-spec, implement, review (Gate B) and deliver (Gate C). |
| Part 3: Containers | The root's design steps, the fan-out, delegate, integrate, and the coverage ledger that carries each promised scenario to a test. |
| Part 4: The driver and its hosts | The stateless driver, its six refusals, the one-fix review loop, claims and parking, the interactive and headless hosts, and the autonomy dial. |
| Part 5: Doctrine | The standing rules: the single writer, guards against floors against gates, the deny primitive, channel discipline, revision-bound approvals, evidence, supersession, state and log. |
| Part 6: What is not built | What the system does not yet do, stated plainly. |
| Configuration | Every setting the planner reads, with its home, scope, writer, default and reader. |
For a single screen of the same facts written for an agent, read the agent reference.
Where the rest lives
The guides present this material by reader task: what the skill does, how the harness runs, and what remains to build, with a detailed pipeline map and a reference for the entry boundary. The incident records describe the two failures that started the rebuild. The lab's dated decision and build records, and the superseded documents from the diagnosis that preceded the rebuild, are kept in its own repository and are not published.
File, script and command names in this reference (for example .claude/scripts/pipeline-transition.sh) are paths inside the lab's repository. They name the documented interface; the repository itself is private.