Constant HELM_CHART_API_VERSION 

pub const HELM_CHART_API_VERSION: &'static str;

Canonical Helm 3 Chart.yaml apiVersion every rendered lareira-<nome> chart declares. Re-export of the lifted caixa_core::HELM_CHART_API_VERSION so the Helm-side chart-schema apiVersion — the discriminator the Helm binary’s chart-schema parser (helm dependency build, helm lint, helm template) consults to select the schema that reads the rendered Chart.yaml — lives in exactly one place across every caixa renderer. The single production-code call site consuming it is [build_chart_yaml]’s api_version field assignment; a drifted local pub const HELM_CHART_API_VERSION: &str = "…" at this crate (or any sibling per-chart-schema renderer the absorption roadmap acknowledges — the future per-Aplicacao library chart, the future per-cluster snapshot chart) would silently reroute the rendered Chart.yaml through a stale chart-schema parser at helm template time far from the rebrand commit’s source, so the equality + &'static static-data identity pin (helm_chart_api_version_re_export_points_at_caixa_core_canonical) closes the drift footgun at caixa-helm build time. Same shape as the DEFAULT_LIBRARY_NAME / KUBE_KEY_SPEC re-exports on the sibling canonical-Helm-load-bearing-string / canonical-K8s-CR-key axes. Canonical Helm 3 Chart.yaml apiVersion every caixa-helm-rendered lareira-<nome> chart declares at its top-level apiVersion axis. The Helm 3 chart-schema resolution contract keys off this exact "v2" value: helm dependency build, helm lint, and helm template all parse the chart under the Helm 3 v2 schema (which requires ChartYaml::description and permits dependencies: at the top level); drift to the legacy Helm 2 "v1" (the pre-Helm-3 chart schema every upstream Helm-3-migration doc names) silently reroutes the rendered Chart.yaml through the Helm 2 parser, where the top-level dependencies: block is unknown and the chart’s dep on the pleme-computeunit library chart never resolves — helm dependency build reports “no requirements found” and every downstream helm template / helm install on the rendered chart emits an empty release (no ComputeUnit / Service / ScaledObject resources land) far from the source caixa.lisp / the renderer’s build_chart_yaml call site.

The single source of truth the caixa-helm’s build_chart_yaml Chart.yaml apiVersion axis reaches for (caixa-helm/src/lib.rs:298). Peer with the FLUX_HELMRELEASE_API_VERSION (55f0fd9) / FLUX_GITREPOSITORY_API_VERSION (dbbcf29) / FLUX_KUSTOMIZATION_API_VERSION (d2dd1b1) / GATEWAY_API_API_VERSION (3c6cfc3) / CILIUM_API_VERSION (279d611) lifts on the sibling cluster-side-CRD-apiVersion surface — those pin the K8s apiserver-side (apiVersion, kind) RESTMapper contract, this one pins the Helm-side chart-schema-parser contract that gates every rendered lareira-<nome> chart’s dependency resolution before any K8s resource lands. Both axes are load-bearing schema-version discriminators drift-prone by construction across renderer forks.

A future Helm 4 chart-schema promotion (the upstream Helm roadmap names a "v3" apiVersion once the Helm 3 LTS branch closes) is a coordinated migration alongside the upstream Helm chart-schema deprecation cycle, not an incidental edit — pinning it here means the migration lands as one edit at the const + a re-run of the pin tests rather than a per-renderer sweep with no single source of truth to consult. Same “the typed constant lives in one place” discipline the DEFAULT_LIBRARY_NAME (41438dc) / LAREIRA_CHART_NAME_PREFIX / FLUX_HELMRELEASE_API_VERSION (55f0fd9) lifts apply on the peer canonical-Helm-load-bearing-string and cluster-side-CRD-apiVersion axes.