code-review

# Code Review ## Two-Stage Review **Stage 1 — Spec compliance** (do this FIRST): verify the changes implement what was intended. Check against the PR description, issue, or task spec. Identify missing requirements, unnecessary additions, and interpretation gaps. If the implementation is wrong, stop here — reviewing code quality on the wrong feature wastes effort. **Stage 2 — Code quality**: only after Stage 1 passes, review for correctness, maintainability, security, and performance. ## Review Process 1. **Context** — read the PR description, linked issue, or task spec. Run the project's test/lint suite if available (`npm run test`, `make check`, etc.) to catch automated failures before manual review. 2. **Structural scan** — architecture, file organization, API surface changes. Flag breaking changes. 3. **Line-by-line** — correctness, edge cases, error handling, naming, readability. Use question-based feedback ("What happens if `input` is empty here?") instead of declarative statements to encourage author thinking. 4. **Security** — input validation, auth checks, secrets exposure, injection vectors (SQL, XSS, command). Flag race conditions (TOCTOU, check-then-act). 5. **Removal candidates** — identify dead code, unused imports, feature-flagged code that can be cleaned up. Distinguish safe-to-delete (no references) from defer-with-plan (needs migration). 6. **Summary** — present findings grouped by severity, then ask user how to proceed. Do NOT auto-implement fixes. ## ...