The work loop takes one runnable task through a fresh coding session and into a recorded result. The coding agent chooses and authors the work. The driver starts the session, waits for durable writeback and follows the next recorded instruction.
Use the search-shortcut thread as the example. Its intended result is already documented, so it can continue while the separate archive thread waits for the operator's product choice.
One pass through the task
- The coding agent reads the documented queue and identifies the search shortcut as runnable.
- It authors the instruction for a fresh session.
- The driver starts that session and relays its output.
- The session inspects the existing shortcut path, makes the change and runs the relevant checks.
- The session records what happened and the recommended next instruction.
- Only after that writeback does the driver follow the recorded continuation.
The next instruction may name more work or may lead to a decision card. Either way, it comes from the coding agent with project context, not from the driver interpreting a terminal transcript.
Why use a fresh session
In a normal terminal workflow, keeping one long conversation alive is convenient. The session remembers what it just read, and the developer can correct it in place. For a short task, this may be simpler than introducing another record.
The weakness appears across handoffs. A closed process does not tell a later session which checks ran, what remained open or what should happen next. ROOK reconstructs the work from documented project state and recorded events instead of treating hidden conversation memory as the handoff.
Proof before progress
ROOK is designed around proof-of-record: a state advances when the on-device record captures the writeback, not merely because a command returned a successful exit code. If the session exits before that event exists, the driver does not invent a result or silently move to the next task.
That rule makes the visible boundary inspectable. It does not prove the change is correct beyond the checks that actually ran, and it does not promise that every crash or retry resolves without operator intervention.
What the driver does—and does not do
| Driver does | Driver does not |
|---|---|
| Start the agent-authored session | Choose the search task |
| Relay output | Judge whether the shortcut is correct |
| Wait for recorded writeback | Summarize a missing result |
| Follow the recorded instruction | Rank the remaining queue |
The work loop now has a durable result for the shortcut. The archive thread still needs a different round trip: one real choice must leave the coding session and return to the exact work that raised it.
Next
Follow that round trip through the decision loop.