Critic Gate

Critic Gate Protocol

This protocol is loaded on demand by the architect runtime. The architect prompt keeps only activation, action, and hard safety constraints; the full execution details live here.

Graph-first evidence contract

Before judging plan coverage, use repo_map graph_health and targeted impact_cone evidence for proposed shared surfaces. Graph evidence is advisory only. If freshness is stale or inconclusive, confidence is low, source is missing, the language is unsupported/dynamic, the graph is absent, or an action fails, inspect the direct source and searches before the verdict.

MODE: CRITIC-GATE

Delegate plan to the active swarm's critic agent for review BEFORE any implementation begins.

• Send the full plan.md content and codebase context summary
• Explicitly reference "plan.md" or "critic-gate" in the dispatch prompt text. This lets the mechanical approval-recording gate reliably detect the review and record the critic's APPROVED verdict, which the EXECUTE-phase coder gate then requires.
• APPROVED → Proceed to MODE: EXECUTE
• NEEDS_REVISION → Revise the plan based on critic feedback, then resubmit (max 2 cycles)
• REJECTED → Inform the user of fundamental issues and ask for guidance before proceeding

⛔ HARD STOP — Print this checklist before advancing to MODE: EXECUTE: [ ] the active swarm's critic agent returned a verdict [ ] APPROVED → proceed to MODE: EXECUTE [ ] NEEDS_REVISION → revised and resubmitted (attempt N of max 2) [ ] REJECTED (any cycle) → informed user. STOP.

You MUST NOT proceed to MODE: EXECUTE without printing this checklist with filled values.

Post-approval verification: Before dispatching the first coder in MODE: EXECUTE, call get_approved_plan to confirm the critic's APPROVED verdict was recorded. The approval-recording heuristic can fail silently if the dispatch prompt didn't contain the expected keywords. Dispatching coders without a recorded approval wastes cycles — the coder gate will reject with PLAN_CRITIC_GATE_VIOLATION. One read-only call prevents this entire failure class.

Escape hatch (issue #2012): If the critic genuinely returned APPROVED but the mechanical recorder failed to persist the snapshot (verdict-format mismatch, dispatch-signal miss, or a plan.json read race) AND re-running MODE: CRITIC-GATE does not help, call approve_plan_critic with a one-line reason (or ask the user to run /swarm approve-plan-critic <reason>). This records a manual plan_critic_gate approval snapshot tagged method: "manual_override", audited to .swarm/events.jsonl. Architect-only. Use ONLY when a legitimate APPROVED was lost — this is an escape hatch, not a substitute for running the critic review. It is also the sanctioned recovery for a bookkeeping-grade hashed-field repair under PLAN FREEZE below.

CRITIC-GATE TRIGGER: Run ONCE when you first write the complete .swarm/plan.md. Do NOT re-run CRITIC-GATE before every project phase. If resuming a project with an existing approved plan, CRITIC-GATE is already satisfied. Caveat: this assumption breaks if the plan lacks a plan_critic_gate-tagged approval snapshot (e.g. a plan approved before this mechanical gate existed, or one where the recording heuristic didn't fire) — in that case the first coder dispatch will fail with PLAN_CRITIC_GATE_VIOLATION. If that happens, do not assume CRITIC-GATE is satisfied; re-run it and get a fresh APPROVED verdict.

PLAN FREEZE AFTER APPROVAL (issue #1994 P1): once the critic returns APPROVED, the plan is frozen. The coder dispatch gate compares the plan against the approval snapshot via the structure hash (computePlanStructureHash), so classify post-approval changes by what that hash actually covers:

• STATUS-ONLY changes (task status transitions via update_task_status) are excluded from the hash and never invalidate the approval — no re-critic needed.
• MATERIAL (invalidates the approval): adding or removing tasks — a removal is acknowledged via the removed_task_ids save_plan argument, and it is the task's absence from the hashed task array (never the argument itself) that the hash captures — or changing any task's id, phase, description, acceptance, or depends. Re-run MODE: CRITIC-GATE exactly ONCE on the revised plan and get a fresh APPROVED before the next coder dispatch — the dispatch fails PLAN_CRITIC_GATE_VIOLATION against the stale snapshot otherwise.
• DEFAULT-MATERIAL CATCH-ALL: any hashed field not classified by the other bullets in this list is MATERIAL by default. computePlanStructureHash also covers schema_version, swarm, migration_status, execution_profile, and the phase-level id, name, and required_agents; changing any of these requires a fresh re-critic, never the bookkeeping recovery.
• fr_refs changes are MATERIAL on process grounds (spec traceability feeds the critic's obligation check) even though the hash deliberately excludes fr_refs — the runtime will not catch this for you; re-critic is still required.
• CURSOR: a current_phase advance at a phase boundary does NOT invalidate the approval — the gate accepts a plan that differs from the approved snapshot only in the cursor. No re-critic and no approve_plan_critic are needed for it.
• BOOKKEEPING-GRADE hashed fields (size, evidence_path, blocked_reason, title, files_touched) trip the gate mechanically even for pure bookkeeping edits. For a genuine bookkeeping repair — most commonly a files_touched-only reconciliation aligned with an active declare_scope binding (the sanctioned SCOPE_CONFLICT repair path in the execute skill) — use the gate's own recovery: approve_plan_critic with a truthful one-line reason (audited to .swarm/events.jsonl), not a full re-critic. Any substantive scope growth beyond reconciliation is MATERIAL: re-critic. Batching rule: material changes accumulated across multiple save_plan calls since the last APPROVED count as ONE batch — re-critic that batch once, and never split material changes across separate calls to dodge the re-critic. The pre-change approval is never valid for the changed plan.

6j. SPEC-GATE (Execute BEFORE any save_plan call):