Constant FLUX_HELMRELEASE_API_VERSION 

pub const FLUX_HELMRELEASE_API_VERSION: &str = "helm.toolkit.fluxcd.io/v2";

Canonical FluxCD HelmRelease CRD apiVersion every caixa-flux helmrelease.yaml document emits. The Flux v2 helm-controller watches resources at this exact group/version (helm.toolkit.fluxcd.io/v2); drift to a stale v2beta1 / v2beta2 (the pre-GA Flux v2 betas every upstream Flux GA-migration doc names) silently routes the rendered HelmRelease outside the controller’s Watches and breaks at apply time with a non-self-locating “no kind ‘HelmRelease’ is registered for version ‘helm.toolkit.fluxcd.io/v2beta2’” error far from the source caixa.lisp / the renderer’s format-string template.

The single source of truth both axes of the rendered Flux bundle reach for:

• helmrelease.yaml apiVersion — the top-level CRD-group/version the rendered document declares (caixa-flux/src/lib.rs:455 — the helmrelease format-string template);
• kustomization.yaml spec.healthChecks[] per-entry apiVersion — the same Flux-v2 HelmRelease reference the parent Kustomization gates its health-check on (caixa-flux/src/lib.rs:504 — the kustomization format-string template). The Flux v2 contract pairs a HelmRelease document with its sibling Kustomization’s healthChecks[].apiVersion axis: both must name the same Flux v2 HelmRelease CRD group/version for the Kustomization’s per-resource health-gate to bind to the rendered HelmRelease; a future Flux v3 promotion (the upstream Flux roadmap names a per-CRD-group / per- v3 version migration once the Flux v2 LTS branch closes) on one axis without a coordinated edit on the other would have silently emitted a Kustomization whose healthChecks[].apiVersion pointed at an obsolete CRD group/version (apply-side: the health check never resolves, the parent Kustomization sits perpetually in Reconciling).

Until this lift landed both axes carried inline helm.toolkit.fluxcd.io/v2 literals inside [cluster_bundle]’s helmrelease.yaml + kustomization.yaml format-string templates and a matching pair inside the in-file upsert_into_helmrelease_programs test fixtures (caixa-flux/src/lib.rs:928, 970) — four occurrences of the same load-bearing FluxCD-CRD-group/version convention, drift-prone by construction. The PRIME DIRECTIVE duplication-budget rule (THEORY.md §I.3.5: “every recurring shape becomes a generator before it becomes a pattern; every pattern becomes a library before it becomes duplicated code. The duplication budget is zero.”) promotes the constant to a typed substrate-side &'static str on the same trajectory the DEFAULT_FLUX_SYSTEM_NAMESPACE (7197d38) lift established on the sibling Flux-installation-namespace axis. The two render-side consumers now thread the same &'static str through their format-string templates so a future Flux v3 promotion lands in one place; the test fixtures keep the value as a literal because they exercise serde_yaml::from_str on a static YAML document — the build-time pin [default_flux_helmrelease_api_version_matches_caixa_flux_test_fixtures] trips if the literals ever drift past the typed const.

Same “the typed constant lives in one place” discipline the DEFAULT_NAMESPACE (a085b26) / DEFAULT_LIBRARY_NAME (41438dc) / crate::DEFAULT_SERVICO_PORT (1e22add) / crate::DEFAULT_PUBLISH_TAG_PREFIX (0a6a602) / DEFAULT_FLUX_SYSTEM_NAMESPACE (7197d38) lifts apply on the peer canonical-load-bearing-string surface.