receiving-code-review

# 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](references/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.