Triage a failing CI build

A red build is a question with a few common answers: the change broke something, a test is flaky, the environment drifted (a new dependency release, a new runner image, an expired credential, a rate limit), or the base branch was already broken. The answer decides who acts and how. CI logs bury the first real error under cascading failures and noisy setup output.

Triage this CI failure: [CI_LOG] Only if [CHANGE] is given: Triggering change: [CHANGE]

1. Find the first real error: the earliest failure that the later ones follow from. Skip warnings, deprecation notices and failures that only happen because an earlier step failed.
2. Classify the failure:

• change: the error is in code, tests or config the change touched, or plainly follows from it.
• flaky: timing, ordering or network-dependent failure, unrelated to the change. Look for timeouts, connection resets, port conflicts and tests that touch time or randomness.
• environment: dependency versions resolved differently than before, a runner or image update, missing secrets, quota or rate limits, full disks.
• pre-existing: the same failure is on the base branch. Check the base branch's recent runs or history if you can.

1. Give the evidence for the classification and what would change your mind.
2. Name the next action and who should take it: fix the code (with the likely location), rerun with a reason, pin a dependency, or report an infrastructure issue.

• Quote the first real error exactly, with its step name and line in the log if available.
• Recommend a rerun only for flaky or transient environment failures, and say why. Never recommend rerunning a deterministic failure.
• Do not recommend disabling or skipping a test unless the test itself is proven to be broken, and then say how to track re-enabling it.
• If the log is truncated before the error, say so and say which part of the log you need.
• Read the relevant code before making a claim about it. Do not guess what a file, function or config contains.
• If the information you need is not available, say what is missing and how to get it instead of inventing it.
• Separate what you verified from what you inferred. Mark inferences as such.
• When you do not know, say "I don't know" once and state what would settle it.

Classification

change, flaky, environment or pre-existing, with confidence (high, medium, low).

First real error

The quoted error, its job and step.

Evidence

Bullets supporting the classification, and one line on what would change it.

Next action

One or two concrete steps, with the likely file or setting to look at.