Search /
Docs › Agents › Spec Reviewer

Spec Reviewer

Answers one narrow, easily-dodged question: does this code do what the plan said, no more and no less?

Overview

This is not a code quality reviewer — code-reviewer, silent-bug-detector and the domain auditors handle that, and duplicating them wastes a review slot.

The most expensive research bugs aren't bad code. They're correct code that implements something other than what was approved. You approved a design at Gate 2; every silent drift away from it is a decision made without you, which is precisely what Propel exists to stop.

PropertyDetails
ToolsRead, Grep, Glob (read-only)
Auto-DispatchYes — immediately after the implementer, before the domain auditors
InputThe plan entry, the implementer's report, and the changed files

The Six Checks

  1. Completeness. For every requirement in the plan, find the implementing code. A requirement with no code is a finding — even if the implementer's report claims it was done. It checks the code, not the report.
  2. Scope creep. For every change in the diff, find the requirement that asked for it. Scope creep inside an approved task is how a reviewed diff becomes an unreviewed one.
  3. Declared deviations. Is the justification sound — and is this a decision you should have been asked about rather than told about? A deviation that changes what the experiment measures is always your call, no matter how well justified.
  4. Undeclared deviations. The dangerous ones. It compares the diff against the plan itself, independently of what the implementer said.
  5. Verification honesty. Did the implementer actually run the specified step, and does the reported output show what it claims? "Tests pass" with no output isn't evidence. Output from a different command isn't either.
  6. Constraint violations. The plan lists what must not change. Every item, checked against the diff.

Output

VERDICT       MATCHES SPEC | DEVIATES | INCOMPLETE
REQUIREMENTS  each one ✓ satisfied at file:line, or ✗ no code found
SCOPE         changes with no corresponding requirement
DEVIATIONS    declared (justification sound / unsound / your call)
              undeclared (what the plan said vs. what the code does)
CONSTRAINTS   each one, with evidence
VERIFICATION  ran as specified / ran something else / not run
FOR THE HUMAN the deviations that are research decisions, not
              implementation details — they belong at Gate 3

That last section is the one that matters most. It separates "the implementer chose a different variable name" from "the implementer changed what this measures" — and only the second kind needs you.