# The spec-compliance gate.

Stage 1 of the two-stage code review answers one question: does the diff match the promise? A read-only reviewer compares your working tree against the task’s Success Criteria — and the protocol can’t advance until it passes.

## How the sentinel works

The `spec-compliance-reviewer` agent audits the git diff against the `## Success Criteria` section and returns a pass/fail verdict. On pass, the orchestrator records the literal sentinel `SPEC_REVIEW: PASSED` in the audit log.

`require_spec_review_passed` runs as both an entry reminder and a hard exit block. Because it’s a stop-on-failure post-function, advancing without the sentinel is impossible by construction — not discouraged, blocked.

## Why two stages

Each catches a different failure. Spec compliance catches well-written code that drifted from the spec. Code-quality review (Claude plus any AI providers, in parallel) catches correctness and security bugs. Either alone misses the other class.

The advance summary is itself gated: it must carry verification evidence — a fenced output block, `N/N passed`, `exit 0` — or the escape hatch `no-verification-applicable: <reason>`. Prose like “looks good” is rejected. See the [task protocol](https://team.management/protocols/task.md).