The diff is the unit of trust.
Judge the patch against the contract.
A generated summary is an index into the work, not proof that the change is correct. Read the diff against the specification and architecture contract. Begin with the public behavior, then inspect the less visible decisions that can create expensive integration problems.
Inspect the expanded surface
Look for new dependencies, exports, configuration, and database changes. Each addition creates an obligation beyond the immediate task. Check whether a local helper already solves the same problem. Unrelated formatting can obscure review; keep your attention on changed behavior and request a focused follow-up when the patch is hard to assess.
Write findings that can be reproduced
Give the triggering input, affected call path, and expected result. Distinguish a demonstrated bug from a design concern that needs a decision. A useful finding lets the author make one correction and verify it. After that correction, review the actual follow-up diff; a response saying fixed is not the same as evidence.
- SCOPE
- Does every changed file serve the requirement?
- CONTRACT
- Do callers retain compatible behavior?
- PROOF
- Can the claimed result be inspected or reproduced?
WORKING REQUEST / SPEC 05
Review this diff for concrete regressions. Prioritize public behavior and boundary violations. For each finding, state a trigger and source reference. Name remaining uncertainty and unexecuted checks.
A passing check does not justify an unrelated interface or dependency change.