docs: define code queue commander workflow

docs/reference/code-queue-supervision.md

@@ -56,6 +56,19 @@ For broad CI/CD migration waves, use a fixed supervision cadence unless an incid
 
 When a task leaves `running` or `judging`, treat the result as unread work until the final response and judge record have been inspected. Only then should the supervisor decide whether to refill the concurrency window.
 
+## Supervisor Workflow
+
+For each active task, evaluate four things in order:
+
+1. completion quality: did it actually satisfy the task's acceptance boundary;
+2. completion state: is it terminal, retryable, or still making progress;
+3. self-blocking risk: is the task stuck on a problem it cannot solve alone;
+4. next action: accept, continue, replace with a narrower task, or raise an infrastructure issue.
+
+If the blocker is a reusable infrastructure problem, do not keep re-running the business task blindly. First record the infrastructure defect in an issue, then fix the infrastructure manually if Code Queue cannot move past it, and only then resume the delivery wave.
+
+The supervisor should prefer read-only analysis and new narrowly scoped tasks over local implementation takeover. Manual work is reserved for infrastructure blockers, live recovery, and other cases where the queue cannot safely unblock itself.
+
 ## Intervention Rules
 
 Intervene only when there is a clear reason.