Constant FLUX_GITREPOSITORY_KEY_REF 

pub const FLUX_GITREPOSITORY_KEY_REF: &str = "ref";

Canonical Flux v2 per-GitRepository spec.ref ref-selection discriminated-union parent container-axis key every caixa-flux- emitted gitrepository.yaml document mounts its per-shape {tag, branch, commit} sub-selector arm under. Nests one level above the sibling FLUX_GITREPOSITORY_REF_KEY_TAG / FLUX_GITREPOSITORY_REF_KEY_BRANCH / FLUX_GITREPOSITORY_REF_KEY_COMMIT triple it wraps — the K8s Flux v2 source.toolkit.fluxcd.io/v1 GitRepository CRD schema pins the per-CR ref-selection through this spec.ref container- axis, and every rendered spec.ref.{tag,branch,commit} arm the [caixa_flux::GitRefSpec] discriminated-union emits nests beneath this exact key.

The FluxCD source-controller’s per-CR RESTMapper reads spec.ref to source the per-Servico git clone refspec (the container-axis carrying the three-way {tag, branch, commit} arm the controller dispatches on), so drift on the container- axis KEY is exactly as load-bearing as drift on the sibling per- shape sub-selector KEY the arms decode through: a "Ref" / "gitRef" / "revision" / "source" typo at the writer site silently emits a GitRepository whose ref-selection container- axis the CRD schema validator drops as unknown, and the sibling HelmRelease.spec.chart.spec.sourceRef reference dangles at admission with the per-Servico clone never resolving at reconcile time — apply-side: the Flux v2 source-controller’s per-CR reconcile loop no-ops entirely (no clone, no artifact, no checksum), the sibling HelmRelease’s per-chart resolve step finds the empty artifact, and every rendered HelmRelease / Kustomization bundle document downstream of this GitRepository silently no-ops at the FluxCD apply chain with no field naming the container-axis-drift root cause.

The single source of truth every Flux-v2-per-GitRepository- spec.ref-container-axis-naming reaches for — the two per-render consumer sites the crate::render-side lift closes:

• the rendered gitrepository.yaml document’s per-GitRepository spec.ref YAML block-body axis (caixa-flux’s cluster_bundle gitrepo template composer’s ref: sub-block header — the sole production emission site the prior inline "ref:" literal sat at);
• the peer test-fixture navigation site (caixa-flux’s cluster_bundle_gitrepository_ref_* per-arm round-trip pin’s .get("ref") sub-selector traversal step — the sole test-side reader site the prior inline "ref" literal sat at).

Changing this value is a coordinated Flux v3 migration alongside the upstream fluxcd/flux2 deprecation cycle, not an incidental edit — pinning it here means the migration lands as one edit at the const plus a re-run of the pin tests rather than a per- renderer sweep with no single source of truth to consult.

The PRIME DIRECTIVE duplication-budget rule (THEORY.md §I.3.5) promotes the parent-container-axis byte-string to a typed substrate-side &'static str on the same trajectory the sibling per-shape arm sub-selector-key FLUX_GITREPOSITORY_REF_KEY_TAG (7d40380) / FLUX_GITREPOSITORY_REF_KEY_BRANCH (7d40380) / FLUX_GITREPOSITORY_REF_KEY_COMMIT (7d40380) triple lifts established on the sibling per-shape arm surface — nests the parent container-axis KEY above the already-lifted per-shape arm sub-selector-KEY triple, so the whole per-GitRepository spec.ref sub-schema (parent container-axis KEY + per-shape arm sub-selector-KEY triple + per-arm value) now navigates through four caixa-core &'static strs in coordination, and any future Flux v2 sub-schema rebrand (an upstream fluxcd/flux2 v3 rename of the ref-selection container-axis from spec.ref to spec.gitRef / spec.source.ref) lands at one const edit coordinated with the sibling per-shape arm lifts.