Coding work answers “how should this project implement the chosen result?” A decision answers “which result do we actually want?” ROOK keeps that line visible so a coding agent can continue where it has authority and return genuine intent choices to the operator.
For the task-tracker, finding the existing shortcut system and adding a search key binding is work. Choosing whether “archive” must be reversible or may permanently delete data changes the product's meaning. That fork is a decision.
A fair manual comparison
Without ROOK, a developer can keep both tasks in an issue tracker. The agent implements the search shortcut in one terminal. When the archive fork appears in another, the developer pauses, reads the context, chooses an option and types the answer. For two visible sessions, that may be the best workflow: it is direct and has little ceremony.
The repeated cost appears when the developer leaves the desk or the terminal closes. The question, its alternatives and the reason for the eventual choice may live in different places. A later session can receive the answer without receiving the exact decision it answered.
What remains coding work
The coding agent may plan, inspect, change and verify the project. It also decides which documented task is runnable because that requires project context. In the search thread, it can discover the shortcut registry, add the requested binding and check the behavior without inventing product intent.
The driver does less. It starts the fresh session and relays what that session emits. After recorded writeback, it follows the agent-authored next instruction. It does not read the issue list and decide that the shortcut is more important than archive.
What becomes a decision
The archive fork changes what users can recover. The coding agent can explain the consequences: reversible archive preserves restoration at the cost of retaining data; permanent deletion removes data but cannot offer the same undo path. It can recommend one. It must not silently turn that recommendation into the operator's intent.
ROOK records the fork as one decision card. If the archive thread must wait for the answer, that thread parks. The independently runnable search thread may still proceed. If no other work is runnable, the machine waits; the two-loop model does not manufacture useful work.
A compact test
| Ask | If yes | Owner |
|---|---|---|
| Can the documented result be implemented with existing project context? | Keep it in the work loop | Coding agent |
| Would choosing an option decide product intent, risk or cost for the operator? | Send one bounded card | Operator |
| Is another documented thread genuinely runnable? | It may continue | Coding agent chooses; driver starts |
This test is a responsibility boundary, not a guarantee that every fork will be classified perfectly. A coding agent can raise a poor question, and an operator can decide that the card lacks enough context to answer.
Now that the boundary is visible, the next page follows the search shortcut through the autonomous side without skipping the evidence needed to advance.
Next
Follow the runnable task through the work loop.