bug-triagelisted

# Bug Triage ## Purpose Triage decides what gets fixed and in what order. Done badly, engineering time goes to whoever complained most recently, data-loss bugs sit behind cosmetic ones, and a backlog grows until nobody reads it. Triage is a decision process, not a labelling exercise. Every report leaves it with an outcome: fix now, fix later, or will not fix — the last being a legitimate and necessary decision. ## When to use - Processing incoming bug reports. - Preparing a release and deciding what blocks it. - A backlog has grown to the point where nobody triages it any more. - Deciding whether a specific report is worth engineering time. - Setting up a defect process for a team. ## When NOT to use - Diagnosing a specific defect. Use `root-cause-debugging`. Triage decides whether and when to investigate; it does not investigate. - Verifying a fix. Use `testing-strategy` and the `qa` agent. - Live incident response. Contain first, triage afterwards. ## Required context | Fact | Why it matters | |---|---| | The report, with reproduction steps | An unreproducible report cannot be fixed or verified | | Environment: platform, version, build | Determines who is affected | | Frequency and reach | Distinguishes an edge case from a widespread failure | | Whether it is a regression | Regressions rank higher: it worked, and shipping it back is worse | | Whether a workaround exists | Changes urgency, not severity | | Release stage | The bar for accepting a change rises near