The autonomy gate is the boundary between three public outcomes: continue runnable work, park one thread for an operator's decision, or become idle because nothing can proceed. It controls continuation; it does not decide what the project should do.
[Visual 4.2 — One gate has three clearly labelled positions. Green, "proceed", permits a fresh session for runnable work. Amber, "park this thread", sends one blocking decision card to the operator while another queue path remains open. Grey, "idle", appears only where the queue is empty and every thread is parked. A coding CLI stands before the gate as the source of judgment; the driver stands after it as lifecycle only.]
What each position permits
Proceed means selected work can enter a fresh coding session. The coding CLI supplies the work and authors the result. The non-thinking driver only advances the session lifecycle after recorded writeback.
Park this thread means the coding CLI has reached a real decision. A blocking card preserves that thread's decision boundary while other runnable work can continue.
Idle is the honest stopping state. ROOK reaches it when the queue is empty and every thread is parked. The driver does not invent a task merely to keep the machine busy.
Limits
These positions describe the approved public behavior, not ROOK's internal gate configuration or device defaults. The gate is not a scheduler, a reviewer or a second model. It cannot tell whether a task is wise, rank competing work or guarantee a successful outcome.
The parked path also depends on real queue state. If one thread blocks and nothing else is runnable, there is no continuation to manufacture; the machine waits for an answer or new work.
Next
Follow the middle path in detail: park and proceed.