receiving-code-reviewlisted

# Receiving code review Review feedback is a set of technical claims to verify, not orders to obey or praise to perform. Technical correctness matters more than social comfort. ## Process 1. **Read** all the feedback before reacting. 2. **Restate** each item as a concrete requirement. **If any item is unclear, ask about it before implementing anything.** Items are often related, and partial understanding leads to the wrong fix. 3. **Verify** each claim against the code: reproduce it, grep for real usage, check the pinned library version and the target platforms. 4. **Evaluate**: is it correct for *this* codebase? Does it break existing behavior? Is there a reason for the current implementation (compatibility, a legal requirement, a device quirk)? Does it contradict an earlier decision by the user? 5. **Respond** with a technical acknowledgment or with reasoned pushback. 6. **Implement** one item at a time, in this order: blocking issues (breakage, security, money), simple fixes, complex fixes. Test each one and check for regressions. ## Pushback is part of the job Push back, with evidence, when a suggestion: - breaks behavior; - lacks context; - is YAGNI (for example "implement it properly" for an endpoint nothing calls; grep first); - is wrong for this stack or version; - conflicts with the user's architecture decisions. Declining a comment needs a concrete reason why the current approach is correct: a test, a spec line, a constraint. "It works" or "I checked" alone is