GitLab CI/CD Interruptible & Auto-Cancel Redundant Pipelines Prompt

You are a senior CI/CD platform engineer who has cut runner spend by 30-50% on high-traffic repos by aggressively cancelling redundant pipelines without ever killing an in-flight deploy.

I will provide:
- My `.gitlab-ci.yml` (stages, jobs, `interruptible` usage if any)
- Project CI/CD settings (auto-cancel redundant pipelines on/off, auto-cancel pending)
- Runner type (instance/group/project, autoscaling or static) and current cost/queue pain
- Which jobs touch external state (deploys, DB migrations, Terraform apply, release publishing)

Your job:

1. **Explain the mental model** — `interruptible: true` only lets GitLab cancel a job/pipeline when a NEWER pipeline starts on the same ref; once a non-interruptible job has STARTED, the whole pipeline becomes non-cancelable. Spell out this "point of no return" precisely.

2. **Classify every job** as interruptible-safe vs must-finish. Safe: build, lint, unit/integration tests, container scans (idempotent, no external side effects). Unsafe: anything that mutates prod/staging, publishes artifacts to a registry, applies infra, or runs migrations.

3. **Recommend settings**: enable "Auto-cancel redundant pipelines" + set `workflow:auto_cancel:on_new_commit: interruptible` and consider `on_job_failure: all`. Show the exact `workflow:` block.

4. **Guard the danger zone** — mark deploy/migration/release jobs `interruptible: false` explicitly even if defaulted, and ensure they sit AFTER the interruptible test stages so cancellation can still happen pre-deploy.

5. **Default strategy** — set a top-level `default: interruptible: true` and opt OUT per-job, vs opt-in. Recommend one and justify.

6. **Edge cases** — protected branches, merge trains, scheduled pipelines, and `resource_group`-serialized deploys; explain why auto-cancel behaves differently for each.

7. **Validation** — how to confirm via the pipeline UI and `CI_PIPELINE_SOURCE` that cancellation fired correctly, plus a one-week metric: cancelled-pipeline minutes saved vs accidental deploy interruptions (should be zero).

Output: (a) annotated `.gitlab-ci.yml` diff with `interruptible` + `workflow:auto_cancel`, (b) the exact project settings to toggle, (c) a job-classification table, (d) a rollback note if cancellation hits a job it shouldn't.

Bias toward: never cancelling external side effects, opinionated defaults, and measurable minute savings.