receiving-code-reviewlisted

# Receiving code review **Trigger.** A reviewer — human or agent — has left comments on your change: inline notes, a change request, a design objection, or a question you are not sure how to answer. > **Reference material** (comment triage table with worked replies, handling > a reviewer who is wrong, scope-creep boundaries, and review of > agent-authored changes): see `reference.md` in this directory. ## The rule > **Every comment gets a decision and a reply. Disagreement is fine; silence > is not.** Two symmetrical failures, and the second is the one people underestimate: - **Reflexive compliance.** Making every requested change without evaluating it. Reviewers are frequently right and occasionally wrong, and a change you made without agreeing with it is a change nobody understands. Worse, "done" on a request you misread produces a defect with a reviewer's name on it. - **Reflexive defence.** Explaining why each comment is unnecessary. This converts review into negotiation and costs you the thing review is for. The correct posture is neither: **evaluate, decide, and say what you decided.** ## Triage every comment Classify before responding. The category determines the reply. | Category | What it is | Response | | --- | --- | --- | | **Defect** | The code is wrong; reviewer showed how | Fix, verify, reply with the evidence | | **Risk** | Not wrong today, fragile tomorrow | Fix, or record why the risk is accepted | | **Design** | A different approach is pref