ci-triage

# Diagnose a failing CI run The goal is one sentence a human can act on: **which job failed, on what, and whether it is this PR's fault.** A screenshot of red checks is not a diagnosis. ## 1. Find the first failure, not the loudest one List the run's jobs and take the earliest failing one. Later jobs usually fail *because* an earlier one did, and their logs are longer and more alarming — which is why people diagnose the wrong job. Within that job, find the **first** error, not the last. Build tooling prints a summary at the end that names the last thing to fail; the first error is what actually broke. Skip past the noise that always appears in failing logs: deprecation warnings, peer dependency notices, cache misses. None of them fail a build on their own. ## 2. Classify before investigating Read the first error and put it in one of four buckets. They have different fixes and mixing them up wastes the most time. | Bucket | Signal | What to do | | --- | --- | --- | | **Real failure** | Assertion, type error, or compile error naming code this PR touched | Report the file and line | | **Environment** | Network timeout, registry 5xx, disk full, runner image change | Re-run; if it persists, it is infrastructure | | **Flake** | Timing, ordering, or concurrency; passes on re-run | See step 4 — do not stop at "re-run passed" | | **Pre-existing** | Fails identically on the base branch | Not this PR's problem; say so explicitly | Check pre-existing early. Fetch the most recent...