magnus919_agent-skills/spec-driven-development/references/phase-gate-methodology.md

Phase Gate Methodology

The four gates that enforce quality at each SDD phase transition. Every gate asks the same question: "Is the artifact for this phase complete, correct, and unambiguous enough for the next phase to proceed safely?"

The Four Gates

SPECIFY → [GATE 1] → DECOMPOSE → [GATE 2] → IMPLEMENT → [GATE 3] → VERIFY → [GATE 4] → DELIVER
  Spec Review       Plan Review      Impl Review          Acceptance Review

Gate 1: Spec Review

Reviews: SPEC.md Question: Is the spec complete, unambiguous, and testable enough for work decomposition?

Checklist:

• Every acceptance criterion is testable (binary PASS/FAIL)
• Edge cases are explicitly enumerated, not implied
• Non-functional requirements have measurable thresholds
• Scope boundary is clear (explicit in-scope AND out-of-scope)
• Data contracts and interface definitions are sufficiently precise
• No section leaves room for the agent to make an unguided assumption
• Assumptions and open questions are documented

Gate 2: Plan Review

Reviews: TASK-PLAN.md Question: Does every spec requirement map to a task? Are dependencies real?

Checklist:

• Every specification requirement maps to at least one task
• Dependencies are real and spec-derived (not invented)
• Each task is independently implementable and verifiable
• Task sizes are appropriate for a single implementation session (30-120 min)
• The implementation handoff (CLAUDE.md, .cursorrules, AGENTS.md) accurately represents the spec and plan
• No task exceeds the scope of any single spec section

Gate 3: Implementation Review

Reviews: Implementation output (code, config, docs) against TASK-PLAN.md Question: Does the implementation satisfy all acceptance criteria for completed tasks?

This is NOT a general code review. It does not assess code style, test coverage, or architectural elegance. It checks only spec compliance.

Checklist:

• All task acceptance criteria are satisfied
• Any deviations from the spec are documented (not silently introduced)
• Implementation produces correct results for all specified inputs
• Error states are handled per the spec
• Interface contracts are honored (return types, error formats, status codes)

Gate 4: Acceptance Review

Reviews: VERIFICATION.md Question: Is the overall compliance score sufficient for delivery?

Checklist:

• All spec ACs are accounted for in the verification matrix
• BLOCKING failures are resolved (none remain open)
• CRITICAL failures have documented remediation plans or exceptions
• Compliance score meets the project threshold (typically >90%)
• Any exceptions are documented with owner and due date

Gate Decision Format

Every gate produces one of three verdicts:

Verdict	Meaning	What happens next
APPROVED	Artifact passes all criteria. Next phase may proceed.	Deliver artifact to next phase
CONDITIONS	Artifact passes subject to specific remediations that don't require full re-review	Deliver artifact + conditions list; next phase may proceed while conditions are resolved
REJECTED	Artifact fails one or more criteria. Current phase must produce a revised artifact.	Return artifact to current phase; no downstream work starts

Finding Severity

Severity	Definition	Disposition
BLOCKING	Issue makes the next phase impossible or produces guaranteed-defective output	Gate cannot pass
CRITICAL	Issue significantly impacts quality but next phase can proceed with documented exception	Gate passes with conditions
MINOR	Issue should be fixed but doesn't block the phase	Gate can pass with remediation plan
INFO	Observation or suggestion, no correctness impact	Informational

Escalation

When the reviewer and artifact author disagree on a finding:

1. Document the disagreement — what the artifact says, what the reviewer found, why the author disagrees
2. Escalate to the human orchestrator if the finding is BLOCKING or CRITICAL
3. MINOR and INFO disagreements are resolved by the reviewer's determination — the gate is not delayed for editorial preferences

The Gate Philosophy

In SDD, quality is not enforced by code review — that's too late. Quality is enforced by the phase gate. A defect caught at Gate 1 (spec review) costs minutes to fix. The same defect caught at Gate 4 (acceptance review) costs hours — the implementation may need to be discarded and rewritten against a corrected spec.

This is the fundamental insight: shift quality left. The cheapest defect is the one caught before a single line of code is written.