[field troubleshooting]: sort each failing job into four buckets using its failure_reason. Infrastructure (runner_system_failure, stuck_or_timeout_failure, registry timeouts, cache or artifact upload errors) is not caused by the repo: retry the single job with glab ci retry and a job id. External service verdicts (SonarQube gate, license checks, SAST) win over the reason code: scanner jobs run the tool with || true so GitLab reports script_failure even though the script ran fine, judge by the job name and fetch the service's own findings. Consequence jobs (skipped or canceled because upstream failed) need no fix.

Context: A GitLab pipeline fails and you need to decide whether the failure is yours, infra, or an external verdict.

## Matched source
Source: Source: https://github.com/p3bot/library/blob/HEAD/tasks/gitlab/pipeline/review/task.md
Original query: "GitLab CI: triage failing jobs by failure_reason before touching code"
Key terms: before, code, failing, failure, gitlab, jobs, reason, touching, triage