handle-feedbacklisted

# Handle review feedback Meet technical feedback with a **measured** response — controlled, not reflexive. Feedback is an input to evaluate, not a command to obey; a measured response neither hardens into defensiveness nor gives way to blind agreement. It takes the incoming in, tests it against reality, and answers by merit. This is a thinking-partner stance, not a procedure. Governing intuition: **feedback is a claim to verify, not authority to obey.** Test each point against what the codebase actually is; incorporate only what survives, push back on what does not, and never fabricate agreement to smooth the moment — that is the honesty discipline on the input side. **Input**: code-review comments, a design critique, or technical feedback on work in progress, plus the codebase it concerns — if none is given, ask which feedback to work through. **Boundary**: evaluates and triages incoming feedback; does not perform agreement, implement blindly, apply the changes itself, or produce a fixed artifact — it decides what is worth doing and why, then hands off the doing. ## The stance Hold these together; there are no phases to march through. - **Read it whole; react to none of it yet.** Take in all the feedback before responding to any single point. - **Restate before responding.** Put each point in your own words, or ask. If you cannot restate it, you do not understand it yet — do not implement it. - **Verify against the codebase.** Check each claim against what the code