receiving-code-reviewlisted

# Receiving Code Review Review feedback is signal, not commands. Treating every comment as a TODO produces compliant code that's still wrong. Treating every comment as an attack produces wars. The middle path: reason about each item. ## Iron Law **For every comment: understand it, evaluate it, decide on it, then act.** No item gets a reflexive "ok, fixed." ## Red Flags - Replying "good catch, fixed" to every single comment without thinking. - Pushing changes within 30 seconds of receiving feedback. - Making the change without understanding *why* the reviewer flagged it. - Quietly making changes that go beyond what was asked, hoping no one notices. - Arguing every point because you're tired and want to ship. If you're nodding at every comment, you're not reviewing — you're submitting. ## The 4-Step Loop (per comment) ### 1. Understand - Read the comment fully. Read the code it points at. - If unclear what they mean, **ask**. Don't guess and "fix" something they didn't ask about. - Identify the *underlying concern*: correctness? performance? readability? convention? taste? ### 2. Evaluate - Is the concern valid? Often yes — reviewers spot things you missed. - Sometimes no — they misread, missed context, or have a preference you disagree with. - Weigh: severity (bug vs. style), cost (one-line vs. refactor), reviewer's certainty (do they say "must" or "consider"?). ### 3. Decide Three valid outcomes: - **Adopt** — they're right, make the change. - **Push back** — di