principle-code-reviewlisted

# Code Review Principles for high-signal code review. For tool-specific mechanics (diff-size routing, suggestion-block format, GitHub workflow), see the `reviewer` agent. ## Four-Axis Review Lens Every review covers four axes: - **Correctness** — off-by-ones, null paths, concurrency races, lost errors, unhandled edge cases. - **Security** — injection, auth/authz gaps, secrets in code, unsafe deserialization, SSRF, missing input validation at trust boundaries. - **Design integrity** — SOLID violations, leaky abstractions, tight coupling, circular deps, domain logic bleeding into infrastructure. *For complexity / duplication / length, prefer Quality-stage output over subjective comments — see `workflow-development`.* - **Tests** — missing coverage on new branches, brittle tests, tests that mirror implementation rather than behavior. ## What's Not a Finding Do not surface these: - Formatting, import order, quote style — owned by the linter, not the reviewer. - Stylistic preferences with no behavioral impact. - Speculative "could be" comments without a concrete failure mode. These erode review signal. If your only comment is a style preference, stay silent. ## Confidence-Based Filtering Before surfacing a finding, apply this filter: 1. **Name the failure scenario.** What breaks, under what inputs, in what deployment context? If you cannot articulate it, the finding is speculative — drop it. 2. **One strong comment over five weak ones.** Ten medium-confidence findings