| name | code-review-policy |
| description | Pre-delivery self-review gate and prioritized review dimensions (security, correctness, data integrity, reuse, performance, readability) with change-quality criteria. Use BEFORE declaring any code change complete, and when asked to review a diff, PR, or branch. |
Code Review Policy (Self-Review & Quality Gate)
Activation Scope
- Apply before delivering any code change, and whenever the user asks to review a diff, PR, or branch.
- Owns the self-review gate and review dimensions. Commit/PR mechanics live in git-policy; bug-hunting methodology lives in debugging-policy.
Core Principle
- Review your own change before presenting it as done. The diff is the deliverable; read it as a reviewer would.
- Optimize the review for the reader: small, focused, and easy to reason about.
- Report findings honestly, including ones you chose not to fix and why.
Pre-Delivery Self-Review (Mandatory)
Before declaring a change complete, verify:
- The change does exactly what was asked - no more, no less.
- The full diff was re-read; no debug code, stray logs, commented-out blocks, or TODOs left behind.
- Only relevant files are touched; unrelated changes are removed.
- No secrets, credentials, or sensitive data are included.
- Existing patterns, naming, and structure are followed (per core-engineering-policy).
- Tests exist and pass for the changed behavior (per testing-policy).
Review Dimensions
Evaluate every change across these dimensions, in priority order:
- Security: untrusted input, injection, authz/authn, secret exposure, least privilege.
- Correctness: logic, edge cases, error/failure paths, concurrency, off-by-one, null handling.
- Data integrity: transactions, consistency, and the database-expert rules when persistence is involved.
- Reuse & architecture: duplication, single responsibility, fit with existing modules.
- Performance & scalability: N+1 queries, unnecessary work in hot paths, allocation in loops.
- Readability & maintainability: clear naming, reasonable function size, self-documenting code.
- Style: formatting and conventions (lowest priority).
Finding Quality
- Be specific: point to the exact location and explain the concrete impact, not vague concerns.
- Separate must-fix (correctness, security) from nice-to-have (style, minor refactor).
- Prefer high-confidence findings; flag uncertain ones explicitly as uncertain.
- Suggest a concrete fix or direction, not just a complaint.
- Do not invent issues to appear thorough; "no issues found" is a valid result.
Change Quality Gate
A change should not be delivered if it:
- Introduces a security or data-integrity risk.
- Breaks or skips tests, or ships untested critical behavior.
- Duplicates logic that already exists, or stores duplicated/derivable data without justification.
- Mixes unrelated concerns in one change.
- Leaves the codebase less consistent than it found it.
