execute-loop

Execute loop

Follow the required coordinator cycle after every request, answer, agent result and wakeup, and before waiting. Pending questions must actually be asked; available capacity must take authorized work. A status report is not completion of this cycle.

Apply the runtime adapter for native delegation, model settings, instruction files and missing capabilities. Never assume a Claude-specific tool exists in Codex.

The coordinator delegates implementation, investigation, and verification. Run database ensure, finish pending migration reconciliation, then read the profile and current task records (coordinator-kit:coordination-state); project topology, authorization, and model choices override defaults. A repository push may itself deploy or publish: use the recorded trigger map, never infer permission from a branch or host name.

Dispatch and delivery

1. Select an authorized, unblocked task by recorded queue order, priority and dependencies. Define and queue new requests through coordinator-kit:backlog-discipline; do not preempt active work without an explicit reprioritization or applicable incident policy. Preserve the founder's original request alongside acceptance criteria. Before implementing an old ticket, have the agent cheaply test its premise: already fixed, wrong cause, and not reproducible are useful findings, not invitations to invent a change. Correct stale records at their source.
2. Claim a lane before dispatch. Record task/agent id, repository and checkout, branch, owned paths, external resources, stage, model, start time, expected duration, and report path. Give the agent a bounded brief using coordinator-kit:agent-brief-hygiene.
3. Select and record the verification policy before dispatch. Routine work uses builder acceptance and affected checks, with the required suite once at the final push gate; high-risk work adds independent adversarial verification and failure-mechanism checks. An authorized urgent TEST revert can use that policy's narrow gate. Existing project requirements and release authority still apply.
4. A failed independent verification gets a fresh fixer with the exact gap and on-disk evidence. Allow at most two fix/re-verify cycles on the same gap after the initial failure; if the second cycle also fails (third failure overall), escalate via coordinator-kit:escalation. A new agent does not reset the counter. Do not resume a large completed transcript merely to continue work; a status-only probe to a still-running agent is different.
5. Establish the push gate below, then commit/push only what the project's authorization permits. An assigned agent may snapshot its own work before verification when local commits are authorized; otherwise preserve a patch. This does not expand the coordinator's product-commit exception, authorize a push, or allow sweeping another agent's changes into the snapshot.
6. Check the actual post-push outcome. Record built, verified, pushed, on-test, on-prod, and awaiting-user-validation separately; a server half without its required client is not a completed user goal. Dispatch a deployed-flow check when the criteria require one. When release approval is the only remaining step, set awaiting_release with target/evidence and queue its linked decision immediately. For user-initiated next actions, keep the current state plus that flag and await the user's initiation without proposing a release question.
7. Persist the result, release the lane when no writer/test/mutation process still owns it, and immediately run the required cycle: present the next question and dispatch the next authorized unblocked task independently. Do not ask whether to continue approved work or wait for all lanes.