The decision loop carries one real fork out of a coding session and brings the operator's answer back to the work that raised it. The coding CLI authors the question. ROOK records and transports it. The operator supplies the judgment.
The loop uses a bounded card rather than leaving an open prompt waiting in a terminal. That card can appear on a desktop or phone surface because the authoritative event remains in the on-device record.
[Visual 1.3 — A clockwise ring labelled "Agent → card → operator → answer → agent". The coding CLI authors a card containing one fork. The card crosses to an operator holding a phone. A selected option becomes a recorded answer whose arrow points back to the same card, then wakes a fresh CLI session beside the original work thread. The driver is shown outside the ring as transport, with the caption "carries events; supplies no judgment".]
From session to card
When the coding CLI reaches a decision it should not make alone, it writes a short explanation of the situation. It adds two or three concrete options, the consequence of each and a recommendation. The resulting card is recorded and shown on the answer surfaces.
If the card blocks the current thread, that thread parks. Other runnable work can still move through the work loop. The machine becomes idle only when there is no queued work to run and the remaining live threads are parked.
From answer to fresh context
The operator chooses an option and may add a note. ROOK records the answer against the card that asked for it. That binding matters: an answer is not a free-floating instruction that can drift into another decision.
The recorded answer wakes a fresh coding session. That session receives the card, the answer and the documented thread state, then applies the judgment with new context rather than relying on a paused process.
Limits
ROOK transports the decision but does not improve it, reinterpret it or choose on the operator's behalf. A blocking card may leave no other runnable work. A recorded answer also does not prove that the resulting implementation will succeed; it provides the missing intent so the coding CLI can continue and record what happens next.
Next
Look more closely at the unit that crosses the loop in Decision cards.