code-review-policylisted

# 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: 1. The change does exactly what was asked - no more, no less. 2. The full diff was re-read; no debug code, stray logs, commented-out blocks, or TODOs left behind. 3. Only relevant files are touched; unrelated changes are removed. 4. No secrets, credentials, or sensitive data are included. 5. Existing patterns, naming, and structure are followed (per core-engineering-policy). 6. Tests exist and pass for the changed behavior (per testing-policy). --- ## Review Dimensions Evaluate every change across these dimensions, in priority order: 1. Security: untrusted input, injection, authz/authn, secret exposure, least privilege. 2. Correctness: logic, edge cases, error/failure paths, concurrency, off-by-one, null handling. 3. Data integrity: transactions, consistency, and the database-expert ru