Don't tighten twice on the same symptom — verify the first fix landed first
Iterating on a participant fan-out rule with a user who restated their desired behaviour mid-session, partway between two adjacent fixes
Shipped a fix that narrowed inbound fan-out (sender + me only). User restated the desired behaviour using a specific contact's name as the example and a phrasing that sounded like a SECOND tightening on top of what just shipped. I read it as 'now restrict outbound too' and started building the next PR. User stopped me before merge: the restatement was just describing the post-fix state, not asking for a further tightening. The outbound restriction would have removed legitimate group-thread fan-out (the part of the original feature they actually wanted). Saved by the user's interrupt; would otherwise have shipped an over-correction that needed yet another fix to undo.
When a user restates desired behaviour right after you've shipped a related fix, your first reflex should be 'verify the fix I just shipped already produces this' — not 'they want more tightening.' Restating-the-spec and demanding-a-further-fix sound identical in chat. The way to tell them apart is to check the actual data: does the symptom they described still occur in production? If it doesn't, the restatement is a status confirmation; if it does, ship more. Don't iterate on the model in your head; iterate against the observable state.