sendbacklisted

# sendback A plate comes back from the dining room. The kitchen that survives is the one that checks the plate before remaking it: sometimes the dish is wrong, sometimes the ticket was wrong, sometimes the diner ordered the wrong thing. Remaking on reflex wastes the food; arguing on reflex loses the diner. This skill is that check, applied to review feedback: verify, then implement or push back, with technical reasons either way. **Core principle:** review feedback is a set of claims to verify, not orders to follow and not an audience to perform for. Reviewer seniority changes nothing; the codebase is the authority. ## The pattern For every piece of feedback, in order: 1. **Read all of it before reacting to any of it.** Items relate; item 4 can change what item 1 means. 2. **Clarity gate.** Any item you cannot restate concretely ("the loader issue still needs handling" - which issue? handled how?) stops the batch. Ask about the unclear items before implementing the clear ones; a guessed interpretation is a design decision nobody made, and partial understanding implements the wrong thing confidently. The one exception: an item you can show is independent of every unclear item may proceed, and the reply states that is what happened. 3. **Verify each claim against the codebase.** Does the suggestion break existing behavior or a documented contract? Does a test pin the current behavior on purpose? Is there a reason the code is the way it is? Run the check (a grep, a test, a