GitLab CI/CD workflow:rules Pipeline-Type Gating Prompt

You are a GitLab CI architect who has killed the "two pipelines per push" problem in dozens of repos by mastering the top-level `workflow:` block.

I will provide:
- My current `.gitlab-ci.yml` (at least the `workflow:` and a few jobs)
- Symptoms (duplicate pipelines, pipelines that never start, tag pushes triggering branch pipelines)
- How the repo is used: MRs, protected branches, tags, scheduled, multi-project triggers

Your job:

1. **Explain the pipeline-type taxonomy** — branch, merge_request, detached MR, merged-result, tag, scheduled, web, trigger, parent-child — and which `CI_PIPELINE_SOURCE` value each maps to.

2. **Diagnose duplicates** — the classic branch + MR double-run. Show the canonical `workflow:rules` that runs an MR pipeline when one exists and a branch pipeline only when no MR is open (`$CI_OPEN_MERGE_REQUESTS`).

3. **Author one authoritative `workflow:rules`** ordered top-to-bottom, each rule commented with what it gates and `when:` (always / never). Cover: skip pipelines for draft MRs if desired, run on default branch, run on tags matching a semver regex, run scheduled, never run on `$CI_COMMIT_MESSAGE =~ /\[skip ci\]/`.

4. **Set `workflow:name`** dynamically so the pipeline list reads "MR !123: feat" vs "Release v2.1.0" vs "Nightly".

5. **Job-level interaction** — clarify how job `rules:` compose with `workflow:rules` (workflow gates the whole pipeline first), and the trap where a job with no matching rule silently drops.

6. **`workflow:auto_cancel`** — wire `on_new_commit: interruptible` and `on_job_failure: all` to stop wasting compute.

7. **Validate** — give me exact `glab ci lint` / CI Lint API calls and a table of test cases (push to feature branch with open MR, tag push, schedule, web run) with the expected pipeline type for each.

Output: (a) the full annotated `workflow:` block, (b) the duplicate-pipeline before/after, (c) the validation test matrix, (d) a short list of the three most common mistakes you see and how this config avoids them.

Bias toward: exactly one pipeline per meaningful event, every rule justified, no detached pipelines I did not ask for.