PR Review

Review the production contract, not just the patch. Decide what must change, what must stay true, and who owns both. Stay read-only unless authorized.

Identify the reviewed change

Read repository rules. Identify the patch, snapshot, or checkout; prefer the exact head SHA and state any mismatch. Gather available PR/Issue links, +A/-D, files, production/test split, CI, mergeability, and review state. Never mix versions. Name gaps, which do not block analysis.

Check the problem first

Ask first:

What problem does this PR solve? How does it solve it? Is the problem defined correctly? Do the problem definition and solution follow first principles and Occam's razor?

Seek a report, reproduction, log, or failing check; an Issue is optional. A new test proves neither demand nor prior failure. Call the problem demonstrated, plausible but unverified, disproved, or mismatched. Compare its scenario and expected result with PR coverage; do not accept a different scenario or unknown value.

Follow the real code path

Turn the problem and solution into a falsifiable production contract: supported entry, changed result, preserved results, and responsible owner. Trace the shortest supported path that could prove the solution wrong before adjacent risks. Compare old and new behavior at the actual producer-consumer boundary, beyond helpers and fixtures.