receiving-code-reviewlisted

# Receiving Code Review Feedback is suggestions to evaluate, not orders to follow. **Verify before implementing, ask before assuming** — technical correctness over social comfort. Verify against the codebase the same way `[[verification-loop]]` gates deploys: evidence before action. ## Response pattern 1. Read the full feedback without reacting. 2. Restate each item in your own words — or ask if unclear. 3. Verify against codebase reality; evaluate if it's sound for THIS stack. 4. Acknowledge technically, or push back with reasoning. 5. Implement one item at a time, testing each. ## No performative agreement - Never "You're absolutely right!" / "Great point!" / "Thanks for catching that!" — any gratitude or praise. - Never "Let me implement that" before verifying. - Instead: restate the requirement, ask, push back, or just start working. The code shows you heard it. - Catch yourself typing "Thanks" or "You're right" → delete it, state the fix. ## Unclear feedback → stop - If ANY item is unclear, implement NOTHING yet — items may be related; partial understanding ships the wrong fix. - Ask only about the unclear ones: "Understand 1,2,3,6. Need clarification on 4 and 5 before proceeding." ## Source-specific - **From your partner** — trusted; implement after understanding, ask if scope unclear, skip to action. - **From external reviewers** — skeptical but careful. Before implementing, check: correct for THIS codebase? breaks existing behavior? reason the current code ex