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 `static-review` Review Record, a design critique, or technical feedback on work in progress — pasted inline, in a file or notes at a given path, or already in the conversation — plus the codebase it concerns; if none is given, ask which feedback to work through. **Boundary**: evaluates incoming feedback; does not perform agreement, implement blindly, apply the changes itself, or produce a fixed artifact or Disposition Record — it decides which claims survive verification, then routes the next workflow. ## 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 r