Receiving Code Review

Treat feedback as evidence to investigate, not as an attack to win or a list to obey blindly.

Classify each finding

• Defect: violates the request, contract, safety, or compatibility.
• Missing proof: behavior may be correct but the evidence is insufficient.
• Clarification: intent or ownership is unclear.
• Preference: stylistic and not worth changing unless it reduces risk.
• Out of scope: real issue for a separate owner or change.

For a defect, reproduce the failure or inspect the real code path before editing. For a disputed finding, state the invariant and the evidence that supports the decision. Do not dismiss a comment because the suite is green.

Fix loop

1. Record the finding and its scope classification.
2. Add a failing regression test or a direct falsifying check when practical.
3. Make the smallest correction at the owning boundary.
4. Run focused checks, then the relevant broader checks.
5. Re-read the changed diff and reply with the exact evidence.
6. Request re-review for changed contracts or previously disputed findings.

Do not bundle unrelated cleanup or change the product contract to silence a reviewer. Use finding-log.md for multiple comments.

Completion condition

Every in-scope finding is fixed, verified, or explicitly accepted with a reason; out-of-scope work is recorded for follow-up; and the re-review boundary is clear.