The work loop turns one CLI-chosen task into a recorded result and a next step. The coding CLI decides what to do. The driver supplies lifecycle: it starts a fresh session, waits for that session's recorded writeback, then follows the next instruction the CLI authored.
Fresh sessions do not depend on a terminal conversation staying alive. They reconstruct their work from the project documents and the on-device record.
[Visual 1.2 — A left-to-right chain labelled "Driver → session → record → next task". The driver starts a fresh session but has no decision controls. Inside the session, the coding CLI reads the documented task, works and writes a recommended next command. The result enters the warehouse as recorded writeback. Only then does an arrow return to the driver and continue toward the next CLI-chosen task. A red stop mark sits on a shortcut from process exit to next task.]
One pass through the loop
Suppose the documented queue contains a small implementation task. The coding CLI selects it as runnable and authors the instruction that starts its session. The driver launches that fresh session and waits. The session reads the task, changes the project, verifies its result and writes back what happened together with its recommended next command.
The CLI may recommend another work session, or it may emit a decision card. In either case, the choice comes from the CLI's project context. The driver only carries it out.
Proof before progress
ROOK is designed around proof-of-record: a state advances when the warehouse records the writeback, not merely because a command returned a successful exit code. If a process exits without that record, the driver does not treat the session as finished and move on.
This keeps the visible state tied to an explicit event. It also gives a later fresh session something durable to read instead of asking it to recover an earlier process's hidden memory.
What the loop does not promise
Proof-of-record is a design boundary, not a claim that every crash is harmless or every retry converges. The loop can also stop when the coding CLI has no runnable task, or park one thread when a blocking decision is open. Most importantly, the driver never interprets, ranks, summarizes or invents work; doing so would create a second, context-poor brain.
Next
See how a real fork leaves work and returns as an answer in the decision loop.