The driver runs the session lifecycle; it does not understand the project. It starts a fresh coding session, carries its output through the loop, waits for recorded writeback and then starts the next session. The coding CLI remains the only brain.
[Visual 4.1 — A straight lifecycle rail runs from "start fresh session" to "relay output", then "wait for recorded writeback", and finally "start next session". Above the rail, a separate coding CLI box sends down two labelled items: "chosen work" and "authored result". No arrow travels from the driver back into those choices. A caption reads: "the driver advances lifecycle; the CLI supplies judgment".]
Mechanical by design
The coding CLI reasons about the codebase, chooses runnable work, writes code and authors decision cards. The driver does none of those jobs. It does not interpret output, rank options, rewrite a recommendation or invent the next task.
That separation prevents a context-poor second interpreter from changing the meaning of the coding session. The comms layer, server and screens follow the same rule: they drive, persist, render or converse, but they do not become another reasoning component.
The record tells the driver when a step has actually advanced. A successful process exit is not enough on its own; the lifecycle moves after the CLI-authored transition is written to the warehouse.
Limits
Mechanical does not mean reliable under every failure. Proof-of-record is the design rule for advancing state, not a promise of crash immunity or automatic retry convergence.
The driver also does not make the project autonomous by itself. If the coding CLI needs operator judgment, the thread parks on a card. If no other work is runnable, the machine waits. Keeping the driver non-thinking preserves the boundary; it cannot manufacture useful work when none is ready.
Next
See the boundary that controls continuation: the autonomy gate.