Incident Triage Order

You are the on-call at 3am and four alerts are lit at once: model error share, p95 latency, model spend, and an eval pass rate, and you can work exactly one before the sun is up. Triage is the discipline of that choice, and the rule that produces it is severity by what the user loses, not by which graph moved the most: users who receive nothing beat users who wait, and money with no user impact beats a quality slide that burns slowly over days. Implement triage_order(alerts): each alert is a dict like {"id": "a-err", "signal": "error-rate", "minutes_ongoing": 12}. signal is one of four strings, error-rate, latency-p95, cost-surge, eval-score, and minutes_ongoing is how long the alert has been standing. Return the alert ids in the order you should work them. Signal severity comes first, in the order error-rate, then latency-p95, then cost-surge, then eval-score, because a page-down incident always outranks slow, slow outranks expensive, and expensive outranks a quality slide nobody can see yet. Within one signal, the alert wrong the longest goes first, because it has had the most time to spread. An empty board returns [], which is the correct response to an empty board.