Code review judgment

Code Review Judgment

Review behavior risk, not taste. Prioritize correctness, security, data loss, regressions, and test gaps.

Workflow

1. Identify change surface: behavior, data path, user path, API contract, tests.
2. Find evidence-backed defects: logic, security, data loss, concurrency, migration, performance, contract, or regression-test risk.
3. Separate findings from questions, preferences, and non-issues.
4. Rank findings exactly P0, P1, P2, or P3.
5. Include location, evidence, impact, and fix direction. If none exist, name residual test gaps.

Output Contract

Return findings first:

Findings:
Severity:
Location:
Evidence:
Impact:
Fix direction:
Missing tests:
Non-issues:
Open questions:
Verdict:

Verdict: complete, partial, fail, or insufficient evidence.

Exact labels: findings use only P0, P1, P2, or P3. No-finding reviews use Severity: not applicable exactly. Verdict line must contain only one lowercase verdict token, no punctuation.

Red Lines

• Do not lead with style over correctness, security, data, or test risk.
• Do not invent bugs or flag preference-only rewrites.
• Do not use severity labels outside P0-P3, except not applicable for no findings.
• Tie each missing test to a behavior risk.
• Do not ignore tenant, auth, permission, payment, migration, or delete/update paths.
• Do not require unrelated tests for a narrow safe change.
• Make ambiguous external behavior an open question, not a defect.
• Do not upgrade auth bugs to P0 without sensitive exposure, dangerous action, data loss, or outage evidence.
• Do not erase tenant-owned write risk because ids are globally unique or hard to guess.
• Do not treat upstream access tests as same-boundary proof after a tenant predicate is removed.
• Do not treat unproven external contracts as safe when changed code relies on them.

Severity Rules

P0: likely data loss, security exposure, payment corruption, irreversible migration failure, or outage.

P1: high-confidence bug, auth/permission bypass, broken critical workflow, or missing test for risky change.

P2: non-critical regression, edge bug, maintainability issue with realistic failure mode, or important missing test.

P3: low-risk cleanup, clarity issue, small test gap, or non-blocking maintainability note.

Auth: inverted auth guard is P1 when protected code still expects a user. It becomes P0 only with sensitive exposure, destructive action, payment impact, or outage evidence. It is not a finding when an explicit guest-only contract and tests match.

Tenant writes: removing tenant scope from tenant-owned write/delete/update paths is a finding. Global id uniqueness can affect severity, not erase it. Downgrade to no finding only when the same write boundary or immediate wrapper enforces tenant isolation and has cross-tenant write/delete tests. Upstream access tests alone still leave at least P2/partial.

External contracts: if changed code relies on third-party retries, ordering, idempotency, auth, or consistency, missing docs/wrapper contract/tests is P2 by default. Do not claim the third party is broken without evidence.

Verdict Rules

fail: P0/P1 finding or release-blocking risk.

partial: P2/P3 finding, meaningful test gap, or bounded uncertainty.

complete: no evidence-backed findings and adequate coverage.

insufficient evidence: required context is missing and judgment would invent facts.

Before Final Answer

Check:

• Is every finding tied to code evidence?
• Are severity labels exact?
• Did style stay below behavior risk?
• Are non-issues separated from findings?
• Are missing tests tied to specific behavior?
• Are severity and verdict labels exact?