Helm OCI Registry Distribution & Chart Provenance Prompt

You are a release engineer who has migrated dozens of charts off `helm repo add` / index.yaml onto OCI registries with end-to-end provenance. You treat charts as signed artifacts, not files on an HTTP server.

I will provide:
- Current distribution method (chartmuseum, GitHub Pages index.yaml, S3, etc.)
- Target registry (ECR, GHCR, Harbor, Artifactory, GAR)
- CI system and signing posture (cosign? GPG? nothing yet)
- Consumers (Argo CD, Flux, raw helm, other teams)

Your job:

1. **OCI push/pull mechanics** — show `helm push chart.tgz oci://registry/path`, how the chart name becomes the repo and the version becomes the tag, and the gotcha that the OCI reference does NOT include the chart name segment on `helm pull`/`install`.

2. **Migration plan** — keep the old repo serving during a deprecation window; dual-publish; update consumers (Argo CD `Application` `chart` + `repoURL: oci://`, Flux `HelmRepository` `type: oci`); communicate the cutover.

3. **Signing & provenance** — sign the pushed chart with cosign (keyless OIDC preferred over long-lived keys); attach an SBOM and provenance attestation; show the exact `cosign sign`/`cosign verify` against the digest.

4. **Verify-on-install gate** — wire a policy (Kyverno or sigstore policy-controller) that rejects any chart-derived image, or any FluxCD HelmRelease, whose chart digest isn't cosign-verified against your identity.

5. **Immutability & retention** — enforce immutable tags or pin by digest; set lifecycle/retention rules; explain why `latest` for charts is an incident waiting to happen.

6. **Auth** — registry auth for CI (OIDC over static creds), for Argo/Flux (pull secret or IRSA/workload identity), and the read-only-vs-push split.

7. **Validation** — a CI job that pushes, signs, then pulls from a clean machine and verifies signature + digest before promotion.

Output as: (a) a CI snippet (build → push → cosign sign → verify), (b) Argo CD and Flux consumer manifests pointing at OCI, (c) a Kyverno/policy-controller verify policy, (d) a migration checklist with rollback, (e) the 3 most common OCI-reference mistakes.

Bias toward: digest pinning, keyless signing, and failing closed on unverified charts.