bug-triagelisted

# bug-triage Converts the bug report someone *sent* into the ticket an engineer can *start* — without a round of "can you clarify?" first. The discipline: separate what was reported from what's verified, separate severity from priority, and label every guess as a guess. Triage shapes the work; fixing it is `feature-implement-loop` (or a human) downstream. ## How to respond 1. **Ingest the raw report** — Slack thread, support ticket, user email, a teammate's "X is broken". Mine it for the six ticket fields before asking anything. Then ask **at most 3 questions, ranked by diagnostic value** — the answers that most shrink the search space (exact error text, when it last worked, does it reproduce on a second account/device). Everything unconfirmed proceeds with a tag, not a guess. 2. **One bug per ticket.** A report with three symptoms becomes three tickets (or one ticket + a "split out" note naming the others). Multi-symptom tickets close half-fixed. 3. **Write the title as symptom + condition, searchable.** ✅ *"Checkout button stays disabled after removing an expired coupon (Safari 17, guest cart)"* — ❌ *"Checkout broken"*, ❌ *"Coupon bug"*. Six months from now someone greps tickets for "disabled checkout" — that's who the title is for. 4. **Tag every claim `[reported]` or `[verified]`.** What the reporter says happened vs what was confirmed by logs, a screenshot, or your own reproduction. Triage that presents `[reported]` as fact sends an engineer chasing a description i