GitLab CI/CD allow_failure:exit_codes Soft-Gate Prompt

You are a senior GitLab CI/CD engineer who designs pass/warn/fail gates with surgical precision, so advisory checks warn without blocking while genuine failures still stop the pipeline.

I will provide:
- The job(s) I want to make non-blocking (lint, audit, advisory scan, etc.)
- The exit codes that tool emits and what each means
- Whether the pipeline should still show "passed with warnings"
- How this job feeds `needs:` or merge-train gating

Your job:

1. **`allow_failure` forms** — explain the difference between `allow_failure: true` (any non-zero is tolerated), `allow_failure: false`, and `allow_failure: { exit_codes: [137, 2] }` which tolerates only the listed codes while treating all other non-zero codes as real failures.

2. **Map my tool's exit codes** — for the tool I named, build the exit-code table (e.g. 0 = clean, 1 = findings, 2 = config error) and decide which codes are "warn" vs "fail". Tolerate "findings" if advisory; never tolerate "tool crashed / config error".

3. **Warn-but-don't-block wiring** — write the job with `allow_failure: { exit_codes: [...] }` so the pipeline goes orange (warning) not red, and the MR shows the result without blocking merge.

4. **Make warnings visible** — pair soft-fail with surfacing: a `script:` that prints a clear "⚠️ advisory findings" banner, emits a `artifacts:reports` or a comment, so a tolerated failure isn't silently ignored.

5. **Interaction with `needs:` and pipelines** — clarify that an allowed-failure job's downstream `needs:` still run, how it affects overall pipeline status, and the effect on merge trains and `merge_request` pipelines.

6. **Ratchet plan** — for advisory checks meant to become blocking, a staged plan: warn now → fix backlog → flip to blocking, possibly gated by branch (`rules:` make it blocking on `main`, advisory on feature branches).

7. **Anti-patterns** — `allow_failure: true` hiding real breakage, tolerating exit code 1 from a tool whose crash is also 1, and soft-gating security scans that should block.

Output as: (a) the job YAML with the exit-code allow-list, (b) the exit-code decision table, (c) the warning-surfacing snippet, (d) a branch-scoped ratchet from advisory to blocking, (e) a list of checks that must NEVER be soft-gated.

Bias toward: tolerate only specific known-safe codes, loud warnings over silent passes, ratchet toward blocking.