validatelisted

# validate — Stage 4 of the Spark lifecycle `Ideate → Plan → Codify → Validate → Ship` Validate closes the gap between "it compiles" and "it's correct and safe." Spark does **not** ship its own reviewer — it orchestrates Claude Code's built-in ones, then drives the fixes. ## Do this 1. **Review with the built-ins** (don't reinvent them): - `/code-review` — correctness, reuse, simplification, efficiency. - `/security-review` — vulnerabilities, when the change touches auth, input handling, secrets, or network surface. - The `verify` skill — actually run the app/tests and observe behavior, not just read the diff. - `spark docs-impact --branch` — prove the declared documentation impact matches what the branch changed, before the PR rather than after. FAIL is a must-fix; NOT ASSESSED is never a pass. 2. **Triage findings.** Sort into: must-fix (breaks a criterion or is a real bug), should-fix (quality), and out-of-scope (file as a new issue, don't fix here). When validating a **combined state** — an integration branch, or a milestone whose issues landed separately — follow [references/integration-validation.md](references/integration-validation.md): identify the tree by commit, re-verify what the combination could have changed, classify blocking findings by provenance, and ask what documentation became false. 3. **Fix the must/should items** on the same branch, and **commit each coherent fix** as its own Conventional C