gitops-promotionlisted

# Purpose Define and enforce the GitOps promotion flow for the project's Wave B deployment model, where a pull-based controller (Flux or ArgoCD) reconciles the cluster from the version-pinning repo's desired state (project.json → repos; referenced below as `<versions-repo>`). Covers the boundary between Wave A (GitLab-native imperative deploy) and Wave B (GitOps pull-based), promotion sequencing, rollback via Git, and verification gates. # When to use this skill (triggers) - Configuring or reviewing the GitOps promotion flow after a pull-based controller is deployed - Updating `<versions-repo>` desired-state files for candidate, current, or previous digests - Designing the verify-then-promote gate in a GitOps workflow - Rolling back a deployment by updating desired state to a previous digest - Determining whether a task belongs in Wave A (imperative) or Wave B (GitOps) Only activate if a GitOps controller (Flux v2 or ArgoCD) is confirmed deployed in the target cluster. # When NOT to use this skill (anti-triggers) - Wave A imperative deployments where GitLab CI runs `helm upgrade` directly -- use `gitlab-ci-cd` - CI pipeline structure (stages, rules, artifacts) -- use `gitlab-ci-cd` even in Wave B (CI still builds/scans/publishes) - Helm chart template authoring or values configuration -- use `helm-chart-expert` - GCP authentication for image push or secret access -- use `gcp-cicd-auth` - No GitOps controller is deployed yet -- this skill produces guidance that cannot be