code-review-and-qualitylisted

# Code Review & Quality ## Core Principle **Bloat is the default failure mode.** Code grows; review subtracts. The goal is a tight, minimal change that solves the stated problem, nothing more. A review that lists nits without identifying deletion candidates has missed the point. ## When to Use / NOT - **Use when:** reviewing code or PRs before merge, after subagent work, or when a review is requested. - **NOT when:** style-only review, run the linter instead (see Anti-Patterns). ## Two Review Modes ### 1. Standard Review Before merge. Findings tagged `[blocker]`, `[should-fix]`, `[nit]`, `[question]`. For `[blocker]`, name the violated invariant and the smallest fix. For `[should-fix]`, name why it matters and the cost of leaving it. ### 2. Bloat Review For AI-generated code, after a refactor, or when scope may have crept. Output a **delete-list** tagged `[delete]`, `[simplify]`, `[keep-with-reason]`. Default for any line that does not serve the stated problem is `[delete]`. ## Workflow 1. **Scope check**, diff match stated problem? Outside is `[blocker]` (split) or `[delete]`. 2. **Iron-law scan**, domain-relevant iron law followed? (TDD: failing test first. Effect: typed errors. UI: design taste. Performance: profile first.) 3. **Read for deletion**, "If I delete this, what breaks?" If nothing, it's bloat. 4. **Verify behavior**, test pass? Path exercised? `[question]` if unsure. 5. **Mark dead**, unused exports, dead branches, ownerless TODOs, restating comments