Some coding work needs project context; some choices need human intent. ROOK gives them separate paths. The work loop carries tasks a coding agent can act on, while the decision loop carries a real fork to the operator and returns the recorded answer.
In the task-tracker app, the search-shortcut thread remains runnable. The archive thread reaches a choice between reversible archive and permanent deletion. The two loops let those states coexist without asking a mechanical driver to decide which product behavior the operator wants.
Scroll sideways for the rest of the diagram
The map is literal about responsibility. The coding agent reads the project, chooses runnable work and authors decisions. The driver supplies lifecycle: it starts fresh sessions, relays their output and follows recorded instructions after writeback. It never enters the decision junction.
The work loop
The work loop turns a documented task into a recorded result. For the search shortcut, a fresh session can read the requested key binding, inspect the project, implement it, run the relevant checks and record what happened. A later session does not need the old terminal conversation to stay alive.
Without ROOK, you can do the same work in a terminal and leave a note for yourself. That is simpler when one person is watching one short task. ROOK earns its extra record-keeping when fresh sessions and independent threads recur and the handoff itself needs to survive.
The decision loop
The archive task cannot move responsibly until the product choice is known. The coding agent writes one card explaining the situation, the reversible and permanent options, the consequence of each and its recommendation. The operator answers; ROOK records that answer against the originating card; and a fresh session receives it with the archive thread's documented state.
The card moves the interrupt away from the terminal. It does not improve the decision, fill in a missing option or authorize the driver to reinterpret the answer.
Where the loops meet
| Moment | Who owns it | What becomes durable |
|---|---|---|
| Choose runnable work | Coding agent | The instruction for the session |
| Start and carry the session | Driver | No new judgment |
| Raise the archive fork | Coding agent | One decision card |
| Choose reversible or permanent | Operator | One answer bound to that card |
| Apply the answer | Fresh coding session | The result and next instruction |
ROOK is designed around proof-of-record: work advances after its writeback is recorded, not merely because a process exited successfully. This boundary ties the loops to visible events, but it is not a promise that every crash is harmless or every retry converges.
What this section contains
- Work and decisions draws the responsibility line at the archive fork.
- The work loop follows the search shortcut through a fresh session and recorded close.
- The decision loop follows the archive card out to the operator and back.
The next page starts at the hardest classification: is this still coding work, or has it become a decision only the operator can own?
Next
Continue with work and decisions.