The archive question was a genuine product decision, and it was going to take you a few hours to get to. The keyboard shortcut for search had nothing to do with it. Park-and-proceed is the rule that keeps the first from stopping the second.
Two words first, because the rest of the page leans on them. A thread is one path of work with its own next step. The queue is the set of tasks that can still be worked.
One thread waits, the queue continues
Parking keeps the unresolved decision attached to the thread that raised it. The alternative is worse in both directions: guess an answer and the archive behavior is now whatever the model preferred, or hold a terminal session open for hours and the machine does nothing while it waits.
Meanwhile the coding agent picks the next runnable task, which is how the search shortcut got worked at all. The driver does not rank the queue or judge which thread matters more; it starts the fresh session carrying whatever was selected. When your answer is recorded, a later session can pick the archive thread back up with the question, the choice and the thread's documented state.
A fair manual comparison
Working by hand, you would do roughly this: notice the archive question, decide not to answer it right now, switch to the search shortcut, and come back later. Context-switching is a skill you already have, and for two threads it costs you very little.
The difference is who holds the switch. Manually, the archive thread pauses because you stopped typing, and it resumes because you remembered. Its state lives in your head and in whatever note you left. With ROOK the pause is a recorded property of the thread, so the work in between does not depend on your attention and the return does not depend on your memory.
When proceeding stops
Proceed is conditional, and it is worth being blunt about the conditions.
- If another task is genuinely runnable, work continues.
- If nothing runnable remains — the queue is empty and every thread has parked, finished or blocked — the machine goes idle.
- If your answer never comes, the archive thread stays parked. Nothing times out into a guess.
| Park and proceed gives | It does not give |
|---|---|
| One decision that blocks one thread, not the project | Continuous activity |
| A recorded pause that survives fresh sessions | Any promise that other work is waiting |
| Your answer returned to the thread that asked | Any way for the driver to answer or bypass the card |
| Work you did not have to supervise | Any guarantee the chosen option succeeds |
The parked card stays a real request for judgment. Recording your answer makes the handoff durable; it does not make the decision good, and it does not mean a failure later will recover on its own.
You have now seen the whole loop on one machine. The remaining question is a physical one: which machine is doing this work, and what exactly is your phone doing in the picture?
Next
See where work and its authoritative record live: devices.