code-review-guidelisted

# Code Review Guide ## Overview A code review is a structured inspection that produces a scored assessment with specific, actionable findings. Every finding must reference a concrete location, describe the problem, explain the impact, and suggest a fix. Reviews are objective. They evaluate code against documented project standards, not personal preferences. If a standard does not exist for something, it is not a finding. **Precision mandate**: Every finding must name a specific file, line number, and exact violation. If a finding could apply to any codebase, it is too vague to report. ## When NOT to Use Skip for self-review during implementation — this is for the formal review phase. ## Time Budget - **Quick review** (1-3 files): 2-3 minutes - **Full review** (5+ files): 5-10 minutes ## The Iron Law ``` EVERY VALID FINDING MUST BE REPORTED — NO FILTERING, NO MERCY ``` An unreported finding is a silently disabled quality gate. If the code violates a documented standard, report it — regardless of origin, perceived severity, or whether the developer "probably knows." The tendency to filter findings by perceived importance, origin ("pre-existing"), or social comfort ("it's minor") directly undermines the review's value. Users rely on the review to catch what they missed. A finding omitted because it seemed small is a finding the developer never gets to evaluate. The reviewer's job is detection, not triage — the developer decides what to fix. ## The Process ### Step