| name | rpi-verify |
| description | Verify an implementation against its design and spec across completeness, correctness, and coherence — produce a severity-classified review. Use when user says 'verify the implementation', 'check the implementation matches the design', or 'review what I just shipped'. |
Verify Implementation
Goal
Validate that an implementation matches its design artifacts across three dimensions: completeness, correctness, and coherence. Produce a severity-classified verification report in .rpi/reviews/. This command is purely advisory — it never blocks anything.
If no path provided, auto-detect from recent git changes. If artifacts found, announce what you're verifying.
Invariants
- Resolve the artifact chain from the provided or detected artifact — read all linked files (plan → design → research)
- Search for prior verify-reports covering the same area; use them as historical context, not as a new spec source
- Check
.rpi/specs/ for relevant specs and get the list of changed files
- Read actual implementation files — never trust summaries or checkboxes
- Completeness: check all plan phases/tasks done, tests exist, all planned files created/modified, scan for TODO/FIXME/HACK markers
- Correctness: extract scenarios from linked specs using the verify spec tool, then verify each scenario against actual code and tests with pass/fail per scenario and file:line references; check API contracts match design, flag silent deviations
- Coherence: verify naming conventions, error handling, code organization follow existing patterns; check for unnecessary dependencies
- Classify each finding as: blocker (must fix), warning (should fix), or note (consider fixing)
- Grounding gate: after drafting findings, run the grounding pass only when the draft has at least one blocker OR more than 3 total findings; otherwise skip grounding and present the review without verdicts
- Grounding invocation: pass the drafted finding list (each with its dimension, severity, claim text, and cited anchor) to the read-only
rpi-ground subagent — it adjudicates the existing findings against repo state, it does not re-derive them
- Verdict application: the blocking set presented to the user is the post-grounding set — a finding keeps blocker severity only if
rpi-ground marks it Verified with a citable anchor; Weakened findings are demoted out of the blocking set with a caveat; Falsified findings are excluded (dropped, or struck-through for transparency)
- Grounding annotation: each surviving finding shows its verdict (Verified | Weakened | Falsified) and a one-line evidence pointer; the summary reports before/after counts (e.g. "3 blockers → 2 Verified, 1 Falsified (dropped)")
- Graceful degradation: if the
rpi-ground subagent is unavailable (e.g. opencode / agents-only targets), present the drafted findings with no grounding annotation and an explicit "grounding skipped (subagent unavailable)" note — never a half-annotated review
- Scaffold a verification report, fill in findings grouped by dimension and severity
- Present summary: overall status, counts by severity, report path; list the post-grounding blockers directly
Principles
- Be specific — every finding includes a file:line reference
- Severity matters — distinguish genuine blockers from style nits
- Scale effort — small implementations get lighter verification; large ones get thorough checks
- Re-runnable — each run produces a new report file
Recommended model: premium tier, high effort — adversarial conformance checking, where false negatives are costly (the verify subagent itself is pinned to premium). Advisory; see docs/model-routing.md.
