The task queue + verify gate

A queued task can carry a Verify command — e.g. "go build" or "go test" — set on a task in an audit run’s task graph (the adversarial pool’s shards, or a gate’s checkout-and-check task). A task with a non-empty Verify is gated: complete_task refuses to close it until a matching passing run is on record. Tasks with no Verify command are trusted on the agent’s own completion report — for genuinely unverifiable work, like a design write-up or a research summary.

Tasks are pulled from the queue in dependency order: a task with unmet dependencies, or one already under an active claim by another agent, is never handed out twice.

How the gate checks

complete_task, when the task has a Verify string, looks for any recorded execution on the mission whose command contains that string and exited 0. If none exists, completion is refused with an explanation and a suggested action: run the command, fix the failures, then complete.

report_execution is how runs get recorded

Agents don’t complete tasks and hope — they run the verify command themselves and call the report_execution tool with the command, exit code, and pass/fail flag. That both feeds the live activity view and durably records the run, keyed to the agent’s currently-claimed mission. Only after a passing report_execution for the gating command can complete_task succeed. A failing run instead leaves the task in the queue with the failure captured as a finding, which the run’s own retry/reshard logic acts on — not a silent retry.

Supersede inherits the gate

When a task is replaced, the replacement inherits the old task’s Verify string whenever the new spec doesn’t set its own — so re-planning around a stale task never accidentally drops its verification requirement.