sdd-review

name	sdd-review
description	Independently audit whether an implementation satisfies its approved SDD specification, design, tasks, and acceptance criteria before merge or release. Use for read-only evidence-based verification, regression review, security checks, and spec-to-code reconciliation.
metadata	{"version":"3.0","tags":["sdd","review","verification","regression","security"]}
license	MIT

Independent SDD Review

Act as a skeptical reviewer. Do not trust summaries, checkboxes, generated tests, or a green build without inspecting the evidence. Do not modify files, artifacts, branches, or configuration.

Inputs and boundaries

Read the active spec.md, design.md, tasks.md, verification.md if present, repository instructions, actual git diff/status, changed files, and relevant tests. If an artifact is missing, treat that as a finding unless the chosen SDD level explicitly permits it.

Preserve the exact checkout state. Run read-only commands and validation only. Do not create commits, rewrite specifications, mark tasks complete, or repair findings.

Review procedure

1. Establish scope from the approved artifacts, baseline, diff, and ownership.
2. Build a matrix using stable requirement and acceptance IDs; flag orphan code, orphan tasks, and uncovered requirements.
3. Check acceptance criteria, happy paths, edge cases, failures, authorization, data isolation, migrations, compatibility, accessibility, performance, observability, and rollback where applicable.
4. Inspect whether tests assert required behavior and would fail if the implementation were removed or bypassed.
5. Run canonical tests, type checks, linters, builds, integration/smoke checks, and security checks appropriate to the repository. Label each result as static, test, live, or manual evidence.
6. Search changed files for TODOs, stubs, placeholders, debug code, credentials, unsafe logging, and accidental scope expansion.
7. Compare implementation against the approved design and classify every discrepancy.
8. Perform a convergence check across spec, design, tasks, verification, implementation, and tests; report intentional deviations separately from drift.

Do not infer success from exit code alone: distinguish static/build evidence from live-provider, browser, persistence, migration, or end-to-end evidence.

Output

## Review summary
| Dimension | Status | Evidence |
|---|---|---|
| Completeness | PASS/FAIL | ... |
| Correctness | PASS/FAIL | ... |
| Coherence | PASS/FAIL | ... |

## Requirement coverage
| Requirement | Implementation | Validation | Status |
|---|---|---|---|

## Findings
### [CRITICAL|HIGH|MEDIUM|LOW] title
- Artifact reference:
- File/symbol/line:
- Evidence:
- Remediation:

## Validation run
- Command: result and limitations

## Evidence limits
- `static`: inspection, types, lint, or build; does not prove runtime behavior.
- `test`: automated test evidence and its scope.
- `live`: observed service, provider, browser, or persistence behavior.
- `manual`: human or environment-dependent verification.

## Remaining uncertainty
- ...

VERDICT: APPROVED | CHANGES_REQUIRED | MANUAL_VERIFICATION_REQUIRED

Use APPROVED only when required behavior has concrete evidence. Use MANUAL_VERIFICATION_REQUIRED when evidence depends on unavailable credentials, services, browsers, devices, or human judgment. Use CHANGES_REQUIRED for defects, missing evidence, or unresolved contradictions.