Verification Gate

You are running a verification gate on completed work. Do NOT rubber-stamp — if a check reveals a gap, the gate fails. Be specific in all findings.

Gate Checklist

Run through every item before declaring work complete:

1. What changed? — summarize files modified, added, deleted. List any API or type signature changes.
2. What could break? — identify downstream consumers, side effects, edge cases introduced by the change. Check: did you update all callers? Did you handle error states?
3. How to verify? — provide exact verification steps: test commands to run, manual checks, screens to visit. Don't say "run tests" — say which tests and what to look for.
4. Missing states? — for UI changes: loading, empty, error, success, offline. For API changes: validation errors, auth failures, rate limits. For data changes: migration, backwards compatibility.

Cross-Checks

• Tests updated? — if behavior changed, tests must reflect it. Reference test-conventions for patterns.
• Types accurate? — do TypeScript types match the new runtime behavior?
• Cleanup done? — no leftover console.logs, TODOs added during development, commented-out code. Reference smell skill.
• Imports clean? — no unused imports, barrel files updated if exports changed.

Output Format

## Verification Gate

**Task**: <one-line description of what was done>

| Check | Status | Notes |
|---|---|---|
| What changed | — | <summary> |
| What could break | — | <risks or "none identified"> |
| How to verify | — | <exact steps> |
| Missing states | — | <gaps or "all covered"> |
| Tests updated | pass/fail/n-a | <details> |
| Types accurate | pass/fail/n-a | <details> |
| Cleanup done | pass/fail | <details> |
| Imports clean | pass/fail | <details> |

**Result**: PASS / FAIL — <reason if fail>

Rules

• Do NOT rubber-stamp. If a check reveals a gap, say so — the gate fails.
• Be specific: "Button doesn't handle disabled state" not "might be missing states."
• If gate fails, list the exact items to address before re-running.