ROOK separates work from judgment. The work loop carries coding forward in fresh sessions. The decision loop carries a real fork to the operator and returns a recorded answer. They meet at one crossing point: the coding CLI authors a decision card, and a later session receives the answer.
That separation lets runnable work continue without turning the mechanical driver into a second brain. The coding CLI still chooses and authors the work. The driver starts sessions, relays their output and waits for recorded writeback.
[Visual 1 — Two rings with one crossing point. The left ring is labelled "work loop" and runs clockwise through CLI chooses runnable work, driver starts a fresh session, CLI authors the result, and recorded writeback. The right ring is labelled "decision loop" and runs clockwise through CLI authors one card, operator answers, answer is recorded, and a fresh session receives it. The rings touch only between the card and the recorded answer. A note below the crossing reads: "judgment crosses here; the driver does not supply it".]
One crossing point
The loops can move independently. A session that reaches a genuine decision can leave one work thread waiting on a card. If other work is runnable, the coding CLI can choose it and the work loop can continue. When the operator's answer is recorded, a fresh session can apply it to the thread that asked.
The record is what joins those moments. Neither loop depends on keeping one hidden conversation or terminal process alive between them.
What this section contains
| Page | Question it answers |
|---|---|
| Work and decisions | Which parts belong to autonomous work, and which still require a person? |
| The work loop | How does one chosen task become a recorded result and a next step? |
| The decision loop | How does one card reach the operator and return to the work that raised it? |
The landing gives the complete shape. The three concept pages enlarge one part at a time.
Limits
The separation does not mean that every blocked project always has other work available. It does not let the driver decide what is runnable, rank priorities or author a result. Recorded writeback is a design boundary for advancing the loop, not a promise that every crash or retry converges without intervention.
Next
Continue with work and decisions.