Name guardrails as guardrails, not fixes
Triaging an incomplete feature where a recurring user pain forces a partial mitigation in lieu of the architectural fix
Shipped a small PR that filtered unactionable group-chat outbound rows out of the triage UI, called it 'the fix' in commit messages and PR descriptions, queued the wider issue (multi-attribution / group fan-out — a real architectural feature that would actually let those messages live on every participant's record) as a separate open ticket. User correctly pushed back: hiding is not solving. The PR is a guardrail against the symptom (a resolve action that writes the wrong link), not a solution to the underlying gap (the data model has no way to express 'this message belongs to N people' so it gets stuck in triage). Calling the guardrail a fix deflects future investment from the open architectural issue and creates a false sense of resolution. When a 'fix' just makes a class of broken row invisible, name it as a filter or guard, link it to the open underlying issue, and don't bump the underlying issue's priority back down because the symptom is hidden.
When the proper fix for a recurring user pain is parked in an open backlog issue but you ship a smaller mitigation today, three things: (1) name the mitigation honestly in commits and PR descriptions ('filter,' 'guard,' 'hazard mitigation' — not 'fix'); (2) link it explicitly to the underlying open issue so future readers see the gap is still open; (3) treat repeated incidents that the mitigation papers over as signal to RERANK the underlying issue, not as evidence the mitigation is sufficient.