Park-and-proceed keeps one real decision from freezing unrelated work. A blocking decision card parks the thread that raised it. If the queue contains another runnable task, the work loop can continue with that task instead.
[Visual 4.3 — One work thread reaches a decision card and bends into a clearly marked parking bay. Beside it, a queue feeds a second runnable thread straight into a fresh session. An operator's answer later returns to the parked bay through the on-device record. At the far right, an idle marker appears only after a small checklist reads "queue empty" and "every thread parked".]
One thread waits, the queue continues
A thread is one path of work with its own next step. The queue is the set of tasks that can still be worked. Parking keeps the unresolved decision attached to its thread rather than pretending that a choice was made or holding one terminal session open indefinitely.
The coding CLI chooses the next runnable task. The driver does not rank the queue or decide which thread matters more; it starts the fresh session that carries the selected work. When the operator's answer is recorded, the decision loop can return that judgment to the thread that asked for it.
Limits
Proceed is conditional. It works only when another task is genuinely runnable. The machine becomes idle when the queue is empty and every thread is parked, so park-and-proceed does not promise continuous activity.
It also does not remove the operator from product decisions. The parked card remains a real request for judgment, and the driver cannot answer it, reinterpret it or bypass it. Recording an answer preserves the handoff, but it does not guarantee that the chosen option will succeed or that every failure will recover automatically.
Next
See where work and its authoritative record live: devices.