Constant FLUX_KUSTOMIZATION_API_VERSION 

pub const FLUX_KUSTOMIZATION_API_VERSION: &str = "kustomize.toolkit.fluxcd.io/v1";

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

The single source of truth the kustomization.yaml apiVersion axis reaches for (caixa-flux/src/lib.rs:531 — the kustomization format-string template). Completes the Flux v2 controller triplet (source-controller + helm-controller + kustomize-controller) lift alongside the sibling FLUX_GITREPOSITORY_API_VERSION (8a6c8a3) and FLUX_HELMRELEASE_API_VERSION (55f0fd9) — every per- controller CRD-group/version is now a typed substrate-side &'static str consumed through one pub use caixa_core::FLUX_* re-export at the renderer site. The three controllers share the canonical .toolkit.fluxcd.io root (asserted by [tests::flux_controller_triplet_api_versions_share_toolkit_fluxcd_io_root]), so a future Flux v3 promotion that forks any controller out of the toolkit group surfaces here as a coordinated cross-axis edit-point across all three constants.

The rendered Kustomization’s metadata.namespace (the Flux installation namespace, DEFAULT_FLUX_SYSTEM_NAMESPACE — 7197d38) and spec.sourceRef.kind: GitRepository (referenced through FLUX_GITREPOSITORY_API_VERSION) and spec.healthChecks[].apiVersion (the rendered HelmRelease’s CRD-group/version, FLUX_HELMRELEASE_API_VERSION) all share the cluster-side contract with the upstream Flux v2 controller triplet: a coordinated edit on any one of these four constants must move alongside the sibling axes, and the lift makes that movement a typed substrate-side edit-point rather than a distributed-across-format-string-template-literals refactor.

Until this lift landed the axis carried an inline kustomize.toolkit.fluxcd.io/v1 literal inside [cluster_bundle]’s kustomization.yaml format-string template — one occurrence today, promoted to a typed substrate-side &'static str on the same trajectory the FLUX_GITREPOSITORY_API_VERSION (8a6c8a3) / FLUX_HELMRELEASE_API_VERSION (55f0fd9) / DEFAULT_FLUX_SYSTEM_NAMESPACE (7197d38) lifts established on the sibling Flux-v2-load-bearing-string surface. The render-side consumer now threads the same &'static str through its format-string template so a future Flux v3 promotion lands in one place; every future renderer that reaches for the canonical Flux v2 Kustomization apiVersion (the future M4 mesh.pleme.io/v1alpha1/Aplicacao CR materializer’s per-Aplicacao Kustomization, a future per-edge Kustomization the operator emits for the CiliumClusterwideEnvoyConfig pipeline, a future caixa-otel collector-pipeline Kustomization) inherits the same value by construction with no opportunity for per-renderer drift.

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) / FLUX_HELMRELEASE_API_VERSION (55f0fd9) / FLUX_GITREPOSITORY_API_VERSION (8a6c8a3) lifts apply on the peer canonical-load-bearing-string surface.