Add two-pipeline routing to SDLC skill

Document Pipeline A (user-facing, full UAT→QA→CTO) and Pipeline B
(infrastructure-only, skip UAT, QA→CTO) based on changed file types.

Co-Authored-By: Paperclip <noreply@paperclip.ing>

skills/sdlc/SKILL.md

@@ -103,9 +103,6 @@ CEO creates daily automated report of SLA status and escalates immediately when
 
 ## Pipeline
 
-**Two pipelines based on change type:**
-
-### Pipeline A: Plugin/Feature Changes (User-Facing Code)
 ```
 CI:    Engineer opens PR → CI runs (lint, types, unit tests)
 UAT:   Pixel Patty validates E2E in headlamp-dev
@@ -114,34 +111,17 @@ CTO:   Null Pointer Nancy reviews architecture and security
 Merge: Countess von Containerheim merges after all approvals
 ```
 
-**Applies to:** Changes in `headlamp-*-plugin/` repos (plugin code, features, bug fixes)
-
-### Pipeline B: Infrastructure Changes (No UI Impact)
-```
-CI:    Engineer opens PR → CI runs (lint, types, unit tests)
-QA:    Regression Regina reviews code and correctness (no E2E needed)
-CTO:   Null Pointer Nancy reviews architecture and security
-Merge: Countess von Containerheim merges after all approvals
-```
-
-**Applies to:** Changes in `.github/workflows/`, `infra/`, `org/` repos, and template repos (CI workflows, kustomize configs, RBAC manifests, deployment scripts)
-
-**Rule:** If the PR contains ONLY infrastructure changes (no plugin code changes), use Pipeline B and skip UAT. Patty's time is reserved for user-facing feature testing.
-
-**Detection:** If `git diff` shows changes only in `.github/`, `infra/`, `org/`, or deployment files → Pipeline B. If any `headlamp-*-plugin/` code changed → Pipeline A.
-
 ### Stage 1 — Engineer Opens PR
 
 1. Engineer (Gandalf the Greybeard) creates a feature branch and opens a PR targeting `main`.
 2. CI runs automatically: lint, type checks, unit tests.
 3. CI must pass before any reviewer spends tokens. If CI fails, the engineer fixes it.
 
-### Stage 2 — UAT Review (Pipeline A Only)
+### Stage 2 — UAT Review
 
-4. **Pipeline A only (user-facing changes):** Pixel Patty picks up PRs with passing CI.
+4. Pixel Patty picks up PRs with passing CI.
-5. **Pipeline B skips this:** Infrastructure PRs bypass UAT and go directly to QA.
+5. Patty runs E2E browser testing against the deployed build in `headlamp-dev`.
-6. Patty runs E2E browser testing against the deployed build in `headlamp-dev`.
+6. Pass → hands off to QA. Fail → goes directly to engineer.
-7. Pass → hands off to QA. Fail → goes directly to engineer.
 
 ### Stage 3 — QA Review
 
@@ -160,6 +140,19 @@ Merge: Countess von Containerheim merges after all approvals
 13. Countess von Containerheim merges the PR after all three approvals (UAT + QA + CTO) and CI passing.
 14. Reject → returns to CTO → engineer.
 
+### Pipeline Routing
+
+PRs are classified into two pipelines based on changed files:
+
+| Pipeline | Trigger | Stages |
+|----------|---------|--------|
+| **A — User-facing** | PR changes any plugin runtime files (`src/`, `package.json`, `pnpm-lock.yaml`, `tsconfig.json`, `artifacthub-pkg.yml`) | CI → UAT → QA → CTO → CEO merge |
+| **B — Infrastructure** | PR changes ONLY infrastructure files (`.github/`, `*.md`, `.eslintrc*`, `.prettierrc*`, `renovate.json*`, `.gitignore`, `.editorconfig`, `LICENSE`) | CI → QA → CTO → CEO merge (skip UAT) |
+
+**Default is Pipeline A** — if any changed file does not match the infrastructure-only list, the full pipeline applies.
+
+Pipeline B requires **2 approving GitHub reviews** (QA + CTO) instead of 3. The `dual-approval-check` workflow enforces this gate.
+
 ### Hierarchy Rules
 
 - CTO rejections go directly to engineer (not through QA or UAT).