dev-code-reviewlisted

# Dev Code Review ## Review Contract Review the diff (base..head), never the file in isolation. Every finding cites file:line and states impact. No style nit without a rule or linter backing it. Severity: - **Critical** — correctness, data loss, security, concurrency hazards. Must fix before merge - **Important** — design debt, missing tests for changed behavior, performance. Fix before proceeding - **Minor** — nits. Note only, no gate ## Judgment Rules - Review against requirements first — elegant code solving the wrong problem is Critical - Missing or unwatched-fail tests for changed behavior = Important - Flag shared-state and concurrency changes explicitly even when they look correct - Group multiple symptoms under one root cause — one fix, one thread - Write what's good too. One line. Reinforcing correct patterns is part of the review ## Output Contract ``` # Code Review — {PR or branch} ## Verdict — approve / request changes, 2-line rationale ## Critical — file:line, impact, fix direction (each) ## Important ## Minor ## What's good — one line ``` ## Receiving Feedback Protocol Read fully → restate the requirement in your own words → verify against the codebase → implement one item at a time, each with a test. No "you're absolutely right" before verification. If feedback is technically wrong for this codebase, push back with reasoning — blind implementation is worse than disagreement.