Autonomy in ROOK means that runnable coding work can continue without an operator watching the terminal. It does not mean removing judgment. When the coding CLI reaches a real decision, that decision returns to the operator as a card.
[Visual 4 — A horizontal work path moves through several fresh coding sessions without an operator beside it. At the first real fork, the path reaches a clear boundary labelled "decision needed". One branch rises to an operator and a decision card, while a second runnable thread continues along the lower path. A caption reads: "work continues until judgment is required".]
Bounded continuation
The coding CLI remains the only component allowed to interpret the project. It chooses and authors the work. A non-thinking driver handles lifecycle: it starts fresh sessions and moves forward after their writeback is recorded. The driver does not rank tasks, invent priorities or summarize the CLI into a new meaning.
If one thread needs a decision, a blocking card parks that thread. Other runnable work can proceed. The operator can answer from a surface, and the recorded answer gives a later session the judgment it needs to continue the parked work.
The three pages in this section explain the boundary from different angles: the mechanical driver, the outcomes allowed at the autonomy gate, and park-and-proceed when only one thread is blocked.
Limits
Autonomy is a workflow shape, not a productivity or outcome guarantee. The coding CLI can still make a poor choice, a session can fail, and a project may have no other runnable task. The machine becomes idle when the queue is empty and every thread is parked.
Proof-of-record is also a design boundary rather than crash immunity. ROOK advances from recorded writeback; that does not promise that every retry converges without intervention.
Next
Meet the mechanical part of the loop: the non-thinking driver.