Crate caixa_flux 

caixa-flux — typed renderer that emits the FluxCD-side fragments a caixa Servico needs in the cluster’s GitOps tree.

Same naming convention as [caixa_helm] (renders per-program Helm charts) and [caixa_flake] (renders flake.nix): caixa-<target> = “Rust crate that takes a typed Caixa and emits the canonical source for <target>”.

Two paths, two surfaces

Per theory/META-FRAMEWORK.md §I, two equally-canonical ways exist to deploy a caixa Servico:

1. Aggregator path (programs_yaml_entry) — the cluster has exactly one lareira-fleet-programs HelmRelease whose values contain a programs: array. Adding a Servico = adding one entry to that array. Higher leverage — one HelmRelease handles the whole fleet’s worth of caixas, fewer reconciler events, simpler cluster surface. This is what feira deploy uses by default.

2. Bundle path (cluster_bundle) — emit a fresh GitRepository

   • HelmRelease + Kustomization trio for the caixa’s own per- program chart (rendered by caixa-helm). Used for one-off / isolated services where the aggregator overhead is undesirable (e.g. alpha workloads with non-standard images, breakglass tooling).

V0 contract

use caixa_core::Caixa;
use caixa_flux::programs_yaml_entry;

let caixa = Caixa::from_lisp(src)?;
let cu_yaml: serde_yaml::Value =
    serde_yaml::from_str(std::fs::read_to_string("servicos/hello-rio.computeunit.yaml")?)?;
let entry: serde_yaml::Value = programs_yaml_entry(&caixa, &cu_yaml)?;
// → { name: hello-rio, namespace: tatara-system, module: { source: ... }, ... }

What this is NOT

• Not a Flux CLI wrapper — bytes only.
• Not the operator deploy bundle — that lives in pleme-io/caixa/operator-flux/.
• Not an installer — feira deploy orchestrates the I/O of writing to a GitOps repo + opening a PR.

Structs

ClusterBundleOpts

Inputs for cluster_bundle.

Enums

Error

Errors caixa-flux can raise.

GitRefSpec

Constants

CLUSTER_BUNDLE_LAREIRA_ENABLED_DEFAULT

Canonical substrate-side default for the HelmRelease.spec.values.<library>.enabled child-chart-enablement toggle scalar every cluster_bundle-emitted helmrelease.yaml document seeds under its per-{library_name} values-overlay wrap to force-on the paired caixa_core::DEFAULT_LIBRARY_NAME child chart at the per-cluster HelmRelease-side apply step — re-export of the canonical caixa_core::CLUSTER_BUNDLE_LAREIRA_ENABLED_DEFAULT so the substrate-side child-chart-enablement-toggle scalar-value default lives in exactly one place across every caixa renderer. Pairs with the sibling caixa_core::HELM_VALUES_KEY_ENABLED leaf-scalar-key half of the (leaf-key, scalar-value) per-values-overlay child-chart-enablement-toggle declaration pair.

COMPUTEUNIT_MODULE_KEY_SOURCE

Local re-export of the canonical caixa_core::COMPUTEUNIT_MODULE_KEY_SOURCE — the wasm.pleme.io/v1alpha1/ComputeUnit CRD nested spec.module.source per-CR wasm-component-reference leaf-scalar sub-block key every rendered programs[] entry carries under the parent COMPUTEUNIT_SPEC_KEY_MODULE block to name the exact OCI / git / file wasm-component artifact the M2.5 wasm-engine instantiator loads at Servico bring-up. Three per-module.source drift-detection navigators in this crate’s test module (programs_yaml_entry_round_trips’s per-entry .get(COMPUTEUNIT_SPEC_KEY_MODULE).and_then(|m| m.get(…)) present-check + upsert_into_programs_yaml’s cross-upsert readback + upsert_into_helmrelease_programs’s peer HelmRelease-wrapped spec.values.programs[] cross-upsert readback) now consult the same &'static str — extends the discipline the peer COMPUTEUNIT_SPEC_KEY_MODULE / COMPUTEUNIT_SPEC_KEY_TRIGGER / COMPUTEUNIT_SPEC_KEY_CAPABILITIES top-level-spec.* re-exports establish one level deeper onto the nested spec.module.* leaf-scalar-axis. See caixa_core::COMPUTEUNIT_MODULE_KEY_SOURCE for the full lift rationale. Canonical wasm.pleme.io/v1alpha1/ComputeUnit CRD spec.module.source per-CR wasm-component-reference leaf-scalar sub-block key — the nested spec.module.* child every rendered ComputeUnit YAML carries to name the exact wasm-component artifact the M2.5 wasm-engine instantiator loads at Servico bring-up. Peer of the parent COMPUTEUNIT_SPEC_KEY_MODULE on the same ComputeUnit CRD per-spec.module.* sub-block surface — COMPUTEUNIT_SPEC_KEY_MODULE names the top-level per-CR module- reference block; this constant names the block’s leaf reference- value axis. Every rendered programs[] entry the lareira-fleet-programs library chart consumes carries the module.source: oci://ghcr.io/pleme-io/<caixa>:<versao> (or module.source: file://... for locally-mounted wasm bundles; module.source: github:<owner>/<repo> for git-hosted sources) as its per-Servico wasm-artifact reference; every spec.module.source readback across the [caixa_flux::programs_yaml_entry] round-trip pins + the [caixa_flux::upsert_into_programs_yaml] / [caixa_flux::upsert_into_helmrelease_programs] cross-upsert navigators resolves the same &'static str.

COMPUTEUNIT_SPEC_KEY_CAPABILITIES

Local re-export of the canonical caixa_core::COMPUTEUNIT_SPEC_KEY_CAPABILITIES — the wasm.pleme.io/v1alpha1/ComputeUnit CRD per-CR WASI-capability-list spec.capabilities sub-block key every rendered programs[] entry splices verbatim from the upstream ComputeUnit YAML’s spec.capabilities. Peer of COMPUTEUNIT_SPEC_KEY_MODULE and COMPUTEUNIT_SPEC_KEY_TRIGGER on the same ComputeUnit CRD per-spec.* sub-block axis — completes the substrate-side ComputeUnit-CRD per-spec.* sub-block re-export triple in this crate. See caixa_core::COMPUTEUNIT_SPEC_KEY_CAPABILITIES for the full lift rationale. Canonical wasm.pleme.io/v1alpha1/ComputeUnit CRD spec.capabilities per-CR WASI-capability-list sub-block key — the top-level spec.* child every rendered ComputeUnit YAML carries to declare the wasm-component-capability tokens the M2.5 wasm-engine instantiator binds at Servico bring-up (http-in:0.0.0.0:8080 for the HTTP incoming-handler, env for read-only environment access, sock-* for TCP outbound, and the sibling WASI-preview-2 preview- interfaces per the WIT Component Model). Peer of COMPUTEUNIT_SPEC_KEY_MODULE and COMPUTEUNIT_SPEC_KEY_TRIGGER on the same ComputeUnit CRD per-spec.* sub-block surface — completes the substrate-side ComputeUnit-CRD per-spec.* sub-block re-export triple every rendered ComputeUnit YAML declares as its top-level (module, trigger, capabilities) axis. Same lift trajectory as the sibling COMPUTEUNIT_SPEC_KEY_MODULE axis — three verbatim inline test-side literals (one caixa-flux drift- detection navigator + two caixa-helm per-values drift-detection navigators, one under the canonical wrap-key + one under the library-name-override wrap-key) collapsed onto the same &'static str so any future rebrand (the substrate moving the capability-list axis to caps: for terse-schema parity with the WASI-preview-2 upstream naming, splitting into capabilities.wasi.* / capabilities.pleme.* runtime-vs-substrate discriminators, or the M4 WIT Component Model materializer moving to a typed imports: / exports: split) reaches every consumer by construction. See COMPUTEUNIT_SPEC_KEY_MODULE for the full lift rationale.

COMPUTEUNIT_SPEC_KEY_MODULE

Local re-export of the canonical caixa_core::COMPUTEUNIT_SPEC_KEY_MODULE — the wasm.pleme.io/v1alpha1/ComputeUnit CRD per-CR wasm-module-reference spec.module sub-block key every rendered programs[] entry splices verbatim from the upstream ComputeUnit YAML’s spec.module (per the docstring on programs_yaml_entry above), so the lareira-fleet-programs library chart’s per-Servico module-source axis binds to the exact source the caixa.lisp’s :servicos fixture pins. Four per-entry drift-detection navigators in this crate’s test module (the programs_yaml_entry_round_trips per-key pair + the upsert_helmrelease_replaces_existing / upsert_into_programs_yaml per-module.source navigators) now consult the same &'static str as the peer caixa-helm per-values navigators’ module-source axis. Same re-export shape as the peer FLEET_PROGRAMS_KEY_NAME / KUBE_KEY_NAMESPACE surfaces on the sibling canonical-fleet-programs-schema-key / canonical-K8s-CR-key axes — extends the discipline the M2-typed- slot / fleet-programs schema / K8s-CR key re-export families establish onto the substrate-side ComputeUnit-CRD per-spec.* sub-block axis. See caixa_core::COMPUTEUNIT_SPEC_KEY_MODULE for the full lift rationale. Canonical wasm.pleme.io/v1alpha1/ComputeUnit CRD spec.module per-CR wasm-module-reference sub-block key — the top-level spec.* child every rendered ComputeUnit YAML carries to name the wasm component (module.source: oci://... for OCI-hosted binaries, module.source: file://... for locally-mounted wasm bundles) the M2.5 wasm-engine instantiator loads at Servico bring-up. The single source of truth every downstream consumer that reads or emits the per-CR module sub-block reaches for:

COMPUTEUNIT_SPEC_KEY_TRIGGER

Local re-export of the canonical caixa_core::COMPUTEUNIT_SPEC_KEY_TRIGGER — the wasm.pleme.io/v1alpha1/ComputeUnit CRD per-CR invocation-shape spec.trigger sub-block key every rendered programs[] entry splices verbatim from the upstream ComputeUnit YAML’s spec.trigger. Peer of COMPUTEUNIT_SPEC_KEY_MODULE on the same ComputeUnit CRD per-spec.* sub-block axis. See caixa_core::COMPUTEUNIT_SPEC_KEY_TRIGGER for the full lift rationale. Canonical wasm.pleme.io/v1alpha1/ComputeUnit CRD spec.trigger per-CR invocation-trigger sub-block key — the top-level spec.* child every rendered ComputeUnit YAML carries to name how the wasm component is invoked (trigger.service.{port, paths} for HTTP-triggered Servicos, trigger.subscription.{subject} for the future NATS-triggered Servicos the M4 :contratos typed-mesh pubsub axis will emit). Peer of COMPUTEUNIT_SPEC_KEY_MODULE on the same ComputeUnit CRD per-spec.* sub-block surface — COMPUTEUNIT_SPEC_KEY_MODULE names the per-CR wasm-binary reference axis, this constant names the per-CR invocation-shape axis every downstream trigger consumer (the pleme-computeunit library chart’s per-Servico trigger.service.port / trigger.service.paths / trigger.service.breathability values- block routing, the future M4 pubsub-subscription binding, the caixa-mesh CiliumNetworkPolicy L4-port fallback that reads the destination Servico’s per-trigger.service.port axis via a future resolver round-trip) reaches for. Same lift trajectory as the sibling COMPUTEUNIT_SPEC_KEY_MODULE axis — three verbatim inline test-side literals (one caixa-flux drift-detection navigator

DEFAULT_FLUX_CHART_SOURCE_SUBPATH

Canonical Flux v2 HelmRelease.spec.chart.spec.chart per-CR chart- directory-in-GitRepository-source sub-path default the substrate seeds into every per-caixa helmrelease.yaml document. Re-export of the canonical caixa_core::DEFAULT_FLUX_CHART_SOURCE_SUBPATH so the Flux v2 helm-controller-side per-CR chart-directory-in-git-source default scalar-value lives in exactly one place across every caixa renderer — ClusterBundleOpts::for_caixa’s per-caixa default seed (the sole production-code site the prior inline "chart".into() scalar-value literal sat at, seeding the ClusterBundleOpts::chart_path field that cluster_bundle’s helmrelease.yaml format-string template threads through its FLUX_HELMCHART_TEMPLATE_KEY_CHART- keyed spec.chart.spec.chart axis verbatim) now consults the same &'static str, so a future substrate-side chart-directory-in-git- source rebrand ("chart" → "charts" once a per-caixa multi-chart layout lands and the substrate publishes N sibling lareira-<nome>/ charts under one git repository, "chart" → "helm" on a cross- language convention alignment with sibling wasm-runtime substrates, "chart" → "deploy" on a per-caixa-deploy-directory naming migration) is a one-line edit on the canonical caixa_core::DEFAULT_FLUX_CHART_SOURCE_SUBPATH declaration, not a coordinated rewrite across the ClusterBundleOpts default seed and every future per-target renderer the substrate adds. Pairs with the sibling FLUX_HELMCHART_TEMPLATE_KEY_CHART re-export on the same per-CR spec.chart.spec.chart scalar-axis — the key half of the per- CR scalar-key/scalar-value pair lives at FLUX_HELMCHART_TEMPLATE_KEY_CHART, the value half’s substrate-side default seed lives here. Same shape as the sibling caixa_core::DEFAULT_NAMESPACE / caixa_core::DEFAULT_LIBRARY_NAME / caixa_core::DEFAULT_FLUX_SYSTEM_NAMESPACE / caixa_core::DEFAULT_FLUX_RECONCILE_INTERVAL / caixa_core::DEFAULT_FLUX_KUSTOMIZATION_TIMEOUT / caixa_core::DEFAULT_PUBLISH_TAG_PREFIX re-exports on the peer canonical-substrate-default-load-bearing-scalar surface. Canonical Flux v2 HelmRelease.spec.chart.spec.chart per-CR chart- directory-in-GitRepository-source sub-path scalar every caixa-flux-emitted helmrelease.yaml document declares as the default chart-directory-in-git-source pointer when the per-caixa ClusterBundleOpts::for_caixa seed doesn’t carry an operator- pinned override. The Flux v2 source-controller resolves the pointer relative to the paired FLUX_KIND_GIT_REPOSITORY the sibling FLUX_KEY_SOURCE_REF-keyed sourceRef: block names — the substrate’s canonical contract with every caixa Servico’s git repository is that the per-caixa lareira-<nome> chart the peer caixa-helm renderer emits lives at the ./chart/ sub-tree of the repository root, so the helm-controller’s per-CR chart-open loop keys off this exact scalar to locate the HELM_CHART_YAML_FILENAME + HELM_VALUES_YAML_FILENAME pair the per-caixa rendered chart declares. Every rendered per-caixa HelmRelease CR consults the same &'static str at seed time so a future substrate-side chart-directory-in-git-source rebrand ("chart" → "charts" once a per-caixa multi-chart layout lands and the substrate publishes N sibling lareira-<nome>/ charts under one git repository, "chart" → "helm" on a cross-language convention alignment with sibling wasm-runtime substrates, "chart" → "deploy" on a per-caixa-deploy-directory naming migration) is a one-line edit on this canonical declaration, not a coordinated rewrite across the ClusterBundleOpts default seed and every future per-target renderer the substrate adds.

DEFAULT_FLUX_KUSTOMIZATION_TIMEOUT

Canonical Flux v2 Kustomization.spec.timeout per-CR reconcile wall-clock cap default the substrate seeds into every per-caixa kustomization.yaml document. Re-export of the canonical caixa_core::DEFAULT_FLUX_KUSTOMIZATION_TIMEOUT so the Flux v2 kustomize-controller-side per-CR reconcile-ceiling default scalar- value lives in exactly one place across every caixa renderer — cluster_bundle’s kustomization.yaml format-string template’s sole production-code emit site (the prior inline timeout: 5m scalar-value literal under the top-level spec position, keyed by the sibling FLUX_KUSTOMIZATION_KEY_TIMEOUT leaf-scalar-key) now consumes the same &'static str at emit time through one {timeout_default} named-arg interpolation, so a future substrate-side reconcile-ceiling migration ("5m" → "3m" on faster per-caixa idempotency-checkpoint cadence, "5m" → "10m" on larger per-caixa manifest sets — coordinated with the sibling DEFAULT_FLUX_RECONCILE_INTERVAL reconcile-poll cadence tuning cycle) is a one-line edit on the canonical caixa_core::DEFAULT_FLUX_KUSTOMIZATION_TIMEOUT declaration, not a coordinated rewrite across the emit site + every future per-CR reconcile-cap consumer the substrate adds. Pairs with the sibling FLUX_KUSTOMIZATION_KEY_TIMEOUT re-export on the same per-CR spec.timeout scalar-axis — the key half of the per-CR scalar- key/scalar-value pair lives at FLUX_KUSTOMIZATION_KEY_TIMEOUT, the value half’s substrate-side default seed lives here. Same shape as the sibling DEFAULT_FLUX_RECONCILE_INTERVAL (908180f) / FLUX_HELMRELEASE_REMEDIATION_RETRIES_DEFAULT (30dcdae) re- exports on the peer canonical-substrate-default-load-bearing- scalar surface. Canonical Flux v2 Kustomization.spec.timeout per-CR reconcile wall-clock cap default the substrate seeds into every per-caixa kustomization.yaml document. Every rendered per-caixa Flux v2 Kustomization CR consults the same &'static str at emit time so a future substrate-side reconcile-ceiling migration ("5m" → "3m" on faster per-caixa idempotency-checkpoint cadence once the sibling FLUX_HELMRELEASE_REMEDIATION_RETRIES_DEFAULT retry-ceiling tightens, "5m" → "10m" on larger per-caixa manifest sets where the upstream Flux v2 kustomize-controller-side per-CR reconcile duration outgrows the substrate’s default ceiling — coordinated with the sibling DEFAULT_FLUX_RECONCILE_INTERVAL reconcile-poll cadence tuning cycle) is a one-line edit on this canonical declaration, not a coordinated rewrite across the cluster_bundle kustomization.yaml template + every future per-target renderer the substrate adds.

DEFAULT_FLUX_RECONCILE_INTERVAL

Canonical Flux v2 spec.interval reconcile-poll cadence default the substrate seeds into every per-caixa cluster_bundle CR triplet. Re-export of the canonical caixa_core::DEFAULT_FLUX_RECONCILE_INTERVAL so the Flux v2 controller-side reconcile-cadence default scalar-value string lives in exactly one place across every caixa renderer — ClusterBundleOpts::for_caixa’s per-caixa default seed (the sole production-code site the prior inline "10m" scalar-value literal sat at, seeding the ClusterBundleOpts::interval field that cluster_bundle’s three per-CR format-string templates thread through their FLUX_KEY_INTERVAL-keyed spec.interval axis verbatim) now consults the same &'static str, so a future substrate- side reconcile-cadence migration ("10m" → "5m" on lower-latency- poll optimizations, "10m" → "15m" on cost-optimized clusters where per-CR source-controller poll cost outweighs reconcile-freshness gains — coordinated with the upstream Flux v2 project’s per-controller tuning cycle) is a one-line edit on the canonical caixa_core::DEFAULT_FLUX_RECONCILE_INTERVAL declaration, not a coordinated rewrite across the ClusterBundleOpts default seed and every future per-target renderer the substrate adds. Pairs with the sibling FLUX_KEY_INTERVAL re-export on the same per-CR spec.interval scalar-axis — the key half of the per-CR scalar-key/ scalar-value pair lives at FLUX_KEY_INTERVAL, the value half’s substrate-side default seed lives here. Same shape as the sibling caixa_core::DEFAULT_NAMESPACE / caixa_core::DEFAULT_LIBRARY_NAME / caixa_core::DEFAULT_FLUX_SYSTEM_NAMESPACE / caixa_core::DEFAULT_PUBLISH_TAG_PREFIX re-exports on the peer canonical-substrate-default-load-bearing-scalar surface. Canonical Flux v2 spec.interval reconcile-poll cadence duration scalar every caixa-flux-emitted Flux v2 CR (the per-caixa cluster_bundle triplet’s GitRepository + HelmRelease + Kustomization) declares as its default reconcile-schedule when the per-caixa ClusterBundleOpts::for_caixa seed doesn’t carry an operator-pinned override. Every rendered per-caixa Flux v2 CR consults the same &'static str at seed time so a future substrate-side reconcile-cadence migration ("10m" → "5m" once the Flux v2 source- controller / helm-controller / kustomize-controller trio ships lower- latency-poll optimizations that make per-CR cluster load safe at a faster cadence, "10m" → "15m" on cost-optimized clusters where the per-CR source-controller poll cost outweighs the reconcile-freshness gain) is a one-line edit on this canonical declaration, not a coordinated rewrite across the ClusterBundleOpts default seed and every future per-target renderer the substrate adds.

DEFAULT_FLUX_SYSTEM_NAMESPACE

Canonical FluxCD installation namespace — re-export of the lifted caixa_core::DEFAULT_FLUX_SYSTEM_NAMESPACE so the load-bearing string lives in exactly one place across every consumer of the rendered kustomization.yaml’s metadata.namespace and spec.sourceRef.name axes. Both axes are the same conceptual “Flux installation namespace” the flux bootstrap pipeline names; until this lift landed they sat as two inline flux-system literals inside cluster_bundle’s kustomization.yaml format-string template, and any future per-edition Flux-installation-namespace rebrand on one without a coordinated edit on the other would have silently emitted a Kustomization outside the bootstrap controller’s watch window or a dangling sourceRef. Same shape as the caixa_core::DEFAULT_NAMESPACE (a085b26) / caixa_core::DEFAULT_LIBRARY_NAME (41438dc) / caixa_core::DEFAULT_PUBLISH_TAG_PREFIX (0a6a602) lifts on the peer canonical-load-bearing-string surface. Canonical FluxCD installation namespace every caixa-flux Kustomization document apply-targets. The single source of truth both axes of the rendered kustomization.yaml document reach for:

DEFAULT_LIBRARY_NAME

Canonical Helm library-chart name every lareira-<nome> chart depends on — re-export of the lifted caixa_core::DEFAULT_LIBRARY_NAME so the load-bearing string lives in exactly one place across every caixa renderer. The wrap key the cluster_bundle helmrelease.yaml template uses under spec.values.<library>: to thread the per-cluster overrides through to the rendered chart’s dep block must match the peer caixa-helm chart’s dependencies[0].name axis exactly (Helm’s per-dep alias convention scopes values under the dep’s name: when no alias: is set), and both axes now consult the same &'static str. Same shape as the caixa_core::DEFAULT_NAMESPACE (a085b26) / caixa_core::DEFAULT_SERVICO_PORT (1e22add) lifts on the peer canonical-K8s-axis-constant surface. Canonical Helm library-chart name every lareira-<nome> chart depends on — the pleme-computeunit library chart in pleme-io/helmworks/charts/pleme-computeunit that owns the K8s resource templates (ComputeUnit + Service + ScaledObject + ConfigMap) every per-Servico chart consumes via Helm’s per-dep alias convention (when no alias: is set on a dependency, values are scoped under the dependency’s name:).

DEFAULT_NAMESPACE

Default cluster-wide namespace for caixa Servicos when the computeunit doesn’t pin its own. Re-export of the canonical caixa_core::DEFAULT_NAMESPACE so the namespace string lives in exactly one place across every renderer — caixa-flux’s programs.yaml / GitRepository / HelmRelease / Kustomization emitters and caixa-mesh’s programs fan-out / CiliumNetworkPolicy / Gateway / HTTPRoute emitters now consult the same &'static str, so a future per-cluster-namespace rebrand is a one-line edit on the canonical caixa_core::DEFAULT_NAMESPACE declaration, not a coordinated rewrite across this crate, caixa-mesh, and every future per-target renderer the substrate adds. Default cluster-wide K8s namespace every caixa renderer emits objects into when the source caixa doesn’t pin its own. The single source of truth both caixa-flux’s programs.yaml / GitRepository / HelmRelease / Kustomization emitters and caixa-mesh’s programs fan-out / CiliumNetworkPolicy / Gateway / HTTPRoute emitters consult — re-exported by each renderer’s lib as pub use caixa_core::DEFAULT_NAMESPACE, so a future per-cluster-namespace rebrand (e.g. moving to pleme-system once tatara-system outlives its scoping intent) is a one-line edit here, not a coordinated rewrite across every renderer crate’s metadata.namespace slot.

FLEET_PROGRAMS_KEY_NAME

Local re-export of caixa_core::FLEET_PROGRAMS_KEY_NAME — the canonical lareira-fleet-programs values-schema per-entry name discriminator key (name: — the exact YAML key the fleet-programs library chart’s range .Values.programs step reads per-entry to key each rendered ComputeUnit CR’s metadata.name off). Peer of the sibling FLEET_PROGRAMS_KEY_PROGRAMS top-level array-key re-export on the same fleet-programs schema — that one carries the programs: array key both writer verbs upsert into, this one carries the per-entry name-axis both writer verbs walk that array by (and both emit-side entry builders — this crate’s programs_yaml_entry and the peer [caixa_mesh::programs_for_aplicacao] — write the per-entry name-axis at).

FLEET_PROGRAMS_KEY_PROGRAMS

Local re-export of caixa_core::FLEET_PROGRAMS_KEY_PROGRAMS — the canonical lareira-fleet-programs values-schema array key (programs: — the exact YAML key the fleet-programs library chart reads under .Values.programs[] to iterate one ComputeUnit CR per entry). This crate’s two writer-side upsert paths (upsert_into_helmrelease_programs on the aggregator-HelmRelease shape, upsert_into_programs_yaml on the bare-values.yaml shape) both anchor on this key when walking the entry sequence to match-by-name-and-replace-or-append. Re-exported here so the two production sites’ values_map.entry(Value::String(<key>.into())) / programs_yaml.get(<key>) navigation reads from the same &'static str as every peer consumer (and every future fleet- programs schema-key consumer — the M4 app-operator per-Aplicacao reconciler, the future feira app deploy --apply writer-side aggregator merge). Same re-export shape as the peer KUBE_KEY_NAMESPACE / KUBE_KEY_METADATA / KUBE_KEY_SPEC / KUBE_KEY_KIND / KUBE_KEY_API_VERSION surfaces on the sibling K8s-CR canonical-key axes — extends the discipline the K8s-CR key re-export quintet establishes onto the canonical fleet-programs schema top-level axis. Canonical lareira-fleet-programs values-schema key naming the per-caixa entry sequence — the exact YAML key the fleet-programs library chart’s values.yaml reads as programs: (a sequence of per-Servico entries the chart’s range iterates over to emit one ComputeUnit CR per entry). Two production consumers in [caixa_flux] carry this key on the same fleet-programs schema axis:

FLUX_GITREPOSITORY_API_VERSION

Canonical FluxCD GitRepository CRD apiVersion — re-export of the lifted caixa_core::FLUX_GITREPOSITORY_API_VERSION so the load-bearing string lives in exactly one place across the rendered Flux bundle’s gitrepository.yaml document apiVersion axis. Until this lift landed the axis sat as an inline source.toolkit.fluxcd.io/v1 literal at line 436 of this crate’s cluster_bundle format-string template, and any future per-Flux-v3-migration version bump on this axis without a coordinated edit on the sibling FLUX_HELMRELEASE_API_VERSION axis would have silently routed the rendered GitRepository outside the Flux v2 source-controller’s Watches (controller-side: never reconciled, the dependent HelmRelease’s chart: sourceRef dangles, every per-Servico apply silently comes up with the prior reconciled state). Same shape as the FLUX_HELMRELEASE_API_VERSION (55f0fd9) / caixa_core::DEFAULT_FLUX_SYSTEM_NAMESPACE (7197d38) lifts on the sibling Flux-v2-load-bearing-string axis. Canonical FluxCD GitRepository CRD apiVersion every caixa-flux gitrepository.yaml document emits. The Flux v2 source-controller watches resources at this exact group/version (source.toolkit.fluxcd.io/v1); drift to a stale v1beta1 / v1beta2 (the pre-GA Flux v2 source-controller betas every upstream Flux GA- migration doc names) silently routes the rendered GitRepository outside the controller’s Watches and breaks at apply time with a non-self-locating “no kind ‘GitRepository’ is registered for version ‘source.toolkit.fluxcd.io/v1beta2’” error far from the source caixa.lisp / the renderer’s format-string template.

FLUX_GITREPOSITORY_KEY_REF

Canonical Flux v2 per-GitRepository spec.ref ref-selection discriminated-union parent container-axis key every cluster_bundle-rendered gitrepository.yaml document mounts its per-shape {tag, branch, commit} sub-selector arm under. Re-export of the canonical caixa_core::FLUX_GITREPOSITORY_KEY_REF so the container-axis byte-string lives in exactly one place across every consumer: the writer-side 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 .get("ref") sub-selector traversal (the sole test-side reader site the prior inline "ref" literal sat at) both now navigate through the same &'static str. Nests one level above the sibling FLUX_GITREPOSITORY_REF_KEY_TAG / FLUX_GITREPOSITORY_REF_KEY_BRANCH / FLUX_GITREPOSITORY_REF_KEY_COMMIT per-shape arm sub-selector triple it wraps — the parent container-axis KEY now moves through one lifted const alongside its already-lifted per-shape arm sub-selector-KEY triple, so a future Flux v3 sub-schema rebrand (an upstream fluxcd/flux2 rename of the ref-selection container-axis from spec.ref to spec.gitRef / spec.source.ref) lands as one const edit coordinated with the sibling per-shape arm lifts. See the caixa-core docstring for the full lift rationale. 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.

FLUX_GITREPOSITORY_KEY_URL

Canonical Flux v2 per-GitRepository spec.url remote-repo-URL leaf-scalar-axis key every cluster_bundle-rendered gitrepository.yaml document declares. Re-export of the canonical caixa_core::FLUX_GITREPOSITORY_KEY_URL so the byte-string lives in exactly one place: the writer-side cluster_bundle gitrepo template composer’s url: sub-key (the sole production emission site the prior inline "url:" literal sat at). Sibling to the already-lifted FLUX_GITREPOSITORY_KEY_REF on the peer per-CR spec.ref container-axis surface — these two constants together with the reconcile-cadence FLUX_KEY_INTERVAL enumerate the canonical GitRepository.spec.* per-CR sub-block key surface caixa-flux emits today. See the caixa-core docstring for the full lift rationale. Canonical Flux v2 GitRepository.spec.url per-CR remote-repo-URL leaf-scalar-axis key every caixa-flux-rendered gitrepository.yaml document declares. The FluxCD source-controller reads spec.url as the git remote URL it clones per-reconcile — the authoritative remote the per-Servico artifact archive is sourced from at every reconcile cycle. A drifted key (e.g. "URL", "gitUrl", "repo", "repository") at the writer site would silently emit a GitRepository whose CRD schema validator drops the URL field as unknown, and the per-Servico artifact would never populate — the downstream HelmRelease.spec.chart.spec.sourceRef reference dangles with an empty artifact at admission, every rendered HelmRelease / Kustomization bundle document downstream silently no-ops at reconcile time with no field naming the URL-key-drift root cause.

FLUX_GITREPOSITORY_REF_KEY_BRANCH

Canonical Flux v2 per-GitRepository spec.ref.branch git-branch- selector scalar-axis key — peer of FLUX_GITREPOSITORY_REF_KEY_TAG on the branch-arm of the GitRefSpec discriminated-union. Re-export of caixa_core::FLUX_GITREPOSITORY_REF_KEY_BRANCH; see FLUX_GITREPOSITORY_REF_KEY_TAG for the full lift rationale. Canonical Flux v2 per-GitRepository spec.ref.branch git-branch-selector scalar-axis key every caixa-flux-emitted gitrepository.yaml document declares when the per-Servico bundle’s git_ref is a branch-shaped selector. Peer of FLUX_GITREPOSITORY_REF_KEY_TAG / FLUX_GITREPOSITORY_REF_KEY_COMMIT on the sibling per-shape arms of the FluxCD source-controller GitRepository.spec.ref ref-selection discriminated-union axis; see FLUX_GITREPOSITORY_REF_KEY_TAG for the full lift rationale.

FLUX_GITREPOSITORY_REF_KEY_COMMIT

Canonical Flux v2 per-GitRepository spec.ref.commit git-commit- selector scalar-axis key — peer of FLUX_GITREPOSITORY_REF_KEY_TAG on the commit-arm of the GitRefSpec discriminated-union. Re-export of caixa_core::FLUX_GITREPOSITORY_REF_KEY_COMMIT; see FLUX_GITREPOSITORY_REF_KEY_TAG for the full lift rationale. Canonical Flux v2 per-GitRepository spec.ref.commit git-commit-selector scalar-axis key every caixa-flux-emitted gitrepository.yaml document declares when the per-Servico bundle’s git_ref is a commit-shaped selector. Peer of FLUX_GITREPOSITORY_REF_KEY_TAG / FLUX_GITREPOSITORY_REF_KEY_BRANCH on the sibling per-shape arms of the FluxCD source-controller GitRepository.spec.ref ref-selection discriminated-union axis; see FLUX_GITREPOSITORY_REF_KEY_TAG for the full lift rationale.

FLUX_GITREPOSITORY_REF_KEY_TAG

Canonical Flux v2 per-GitRepository spec.ref.tag git-tag- selector scalar-axis key every cluster_bundle-rendered gitrepository.yaml document declares on the tag-arm of the GitRefSpec discriminated-union. Re-export of the canonical caixa_core::FLUX_GITREPOSITORY_REF_KEY_TAG so the sub-selector byte-string lives in exactly one place: the two consumer sites (the YAML emit-side gitref_field composer and the human-readable tag_human narrator prose) both now read through the lifted GitRefSpec::ref_field_name dispatch that maps the tag-arm of the discriminated-union onto this canonical scalar. Pairs with FLUX_GITREPOSITORY_REF_KEY_BRANCH + FLUX_GITREPOSITORY_REF_KEY_COMMIT on the sibling per-shape arms of the same FluxCD source-controller GitRepository.spec.ref discriminated-union axis — three consts, one per arm, one canonical dispatch. See the caixa-core docstring for the full lift rationale. Canonical Flux v2 per-GitRepository spec.ref.tag git-tag-selector scalar-axis key every caixa-flux-emitted gitrepository.yaml document declares when the per-Servico bundle’s git_ref is a tag-shaped selector. Peer of FLUX_GITREPOSITORY_REF_KEY_BRANCH / FLUX_GITREPOSITORY_REF_KEY_COMMIT on the sibling per-shape arms of the FluxCD source-controller GitRepository.spec.ref ref-selection discriminated-union axis — the three-way sub-selector key set the Flux v2 source-controller reads to bind the per-CR git-source clone refspec from the (tag | branch | commit) input triple. A drifted value at any of the three keys ("Tag" / "gitTag" / "tagName" at this arm, "Branch" / "gitBranch" at the sibling arm, "Commit" / "sha" / "revision" at the third arm) silently dangles the whole spec.ref sub-block at the FluxCD source-controller’s CRD registration; the per-Servico clone never resolves at reconcile time and the sibling HelmRelease.spec.chart.spec.sourceRef reference dangles at admission with no field naming the sub-selector-key-drift root cause. Changing this value is a coordinated Flux v3 migration alongside the upstream fluxcd/flux2 deprecation cycle, not an incidental edit.

FLUX_GITREPOSITORY_YAML_FILENAME

Canonical Flux v2 per-cluster-bundle GitRepository document filename every cluster_bundle-rendered BundleFile carries at its per-file path axis — re-export of the lifted caixa_core::FLUX_GITREPOSITORY_YAML_FILENAME so the fixed filename the cluster-side FluxCD source-controller looks up when it opens the per-Servico bundle directory lives in exactly one place across every caixa renderer. Pairs with the sibling FLUX_HELMRELEASE_YAML_FILENAME + FLUX_KUSTOMIZATION_YAML_FILENAME re-exports to close the per-bundle (gitrepository, helmrelease, kustomization) filename axis triple every rendered cluster bundle carries — the single source of truth all nine consumers reach for (one production cluster_bundle BundleFile assembly’s GitRepository document path axis plus eight test-side round-trip navigators that reach into the rendered bundle by the same filename to pin per-CR body-axis emission) now consult the same &'static str. Pin the equality + &'static static-data identity so any local re-introduction of a sibling pub const FLUX_GITREPOSITORY_YAML_FILENAME: &str = "…" at this crate is a build-time test failure naming the offending drift, not a silent FluxCD source-controller “no GitRepository document found under this bundle” reroute at cluster-side reconcile time far from the drift site. Peer to the sibling FLUX_HELMRELEASE_YAML_FILENAME (ba7b0b2) re-export — extends the canonical-Flux-v2-bundle-filename lifted-const discipline from the middle coordinate of the filename triple onto its first coordinate. Canonical Flux v2 per-cluster-bundle GitRepository document filename every caixa-flux-rendered cluster_bundle carries at the per-Servico bundle’s rendered file collection — the fixed filename the sibling helmrelease.yaml + kustomization.yaml documents key against when the cluster-side FluxCD source-controller reconciles the per-Servico Git-source poll cycle, and the exact filename every downstream consumer that reaches into the rendered bundle by document name looks up.

FLUX_HELMCHART_TEMPLATE_KEY_CHART

Canonical Flux v2 HelmChartTemplate.spec.chart per-CR chart-NAME- reference leaf-scalar-axis key every caixa-flux-emitted HelmRelease document nests inside the parent FLUX_KEY_CHART container-axis (a nested KUBE_KEY_SPEC axis inside that container hosts this leaf plus its sibling FLUX_KEY_SOURCE_REF per-CR source-reference triple). Re-export of the canonical caixa_core::FLUX_HELMCHART_TEMPLATE_KEY_CHART so the load- bearing Flux-v2-helm-controller-side per-HelmChartTemplate chart- NAME reference leaf-scalar-axis key lives in exactly one place across every caixa renderer — the sweep converts this crate’s one production-code call site (the cluster_bundle helmrelease.yaml format-string template’s baked chart: {chart_path} leaf-scalar- axis interpolation the peer sibling lifted FLUX_KEY_SOURCE_REF source-reference triple’s per-CR source-artifact publishes) onto the re-export.

FLUX_HELMRELEASE_API_VERSION

Canonical FluxCD HelmRelease CRD apiVersion — re-export of the lifted caixa_core::FLUX_HELMRELEASE_API_VERSION so the load-bearing string lives in exactly one place across the rendered Flux bundle’s helmrelease.yaml document apiVersion axis + the rendered kustomization.yaml document’s spec.healthChecks[].apiVersion axis. Both axes are the same conceptual “Flux v2 HelmRelease CRD group/ version” load-bearing string and must move together on any future upstream Flux v3 migration; until this lift landed they sat as four inline helm.toolkit.fluxcd.io/v2 literals (two render-side at lines 455, 504 + two test-fixture-side at lines 928, 970), and any future per-Flux-v3-migration version bump on one without a coordinated edit on the other would have silently routed the rendered HelmRelease outside the controller’s Watches (controller-side: never reconciled, every dependent chart frozen at last-applied state) or made the Kustomization’s health-check dangle (apply-side: the per-resource health-gate never resolves, the parent Kustomization sits perpetually in Reconciling). Same shape as the caixa_core::DEFAULT_FLUX_SYSTEM_NAMESPACE (7197d38) lift on the sibling Flux-installation-namespace axis. 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.

FLUX_HELMRELEASE_CREATE_NAMESPACE_DEFAULT

Canonical Flux v2 HelmRelease.spec.install.createNamespace install-path- only per-CR namespace-seeder-toggle scalar-value default the substrate seeds into every per-caixa helmrelease.yaml document at the paired FLUX_HELMRELEASE_KEY_CREATE_NAMESPACE leaf-scalar-key axis. Re- export of the canonical caixa_core::FLUX_HELMRELEASE_CREATE_NAMESPACE_DEFAULT so the Flux v2 helm-controller-side per-CR install-path per-CR namespace-seeder- toggle scalar-value default lives in exactly one place across every caixa renderer — cluster_bundle’s helmrelease.yaml format- string template’s per-CR install-path namespace-seeder-toggle scalar under the FLUX_HELMRELEASE_KEY_INSTALL-keyed sub-block (the sole production-code site the prior inline createNamespace: true scalar- value literal sat at, alongside the FLUX_HELMRELEASE_KEY_CREATE_NAMESPACE- keyed leaf-scalar-key half of the same (leaf-key, scalar-value) pair) now threads the same bool through a {create_namespace_default} named-arg interpolation, so a future substrate-side toggle migration (true → false on hardened per-cluster classes where namespace provisioning is an out-of-band operator gate; a per-caixa opt-out slot the ABSORPTION-ROADMAP.md M4 typed-slot trajectory adds once the substrate grows a :install :create-namespace author-side toggle) is a one-line edit on the canonical caixa_core::FLUX_HELMRELEASE_CREATE_NAMESPACE_DEFAULT declaration, not a coordinated rewrite across the emit site + every future per- target renderer the substrate adds. Pairs with the sibling FLUX_HELMRELEASE_KEY_CREATE_NAMESPACE re-export on the same per-CR spec.install.createNamespace scalar-axis — the key half of the per-CR scalar-key/scalar-value pair lives at FLUX_HELMRELEASE_KEY_CREATE_NAMESPACE, the value half’s substrate- side default seed lives here. Peer with the sibling FLUX_HELMRELEASE_REMEDIATE_LAST_FAILURE_DEFAULT mirror-symmetric upgrade-path-only scalar-value default + the sibling FLUX_KUSTOMIZATION_PRUNE_DEFAULT (ea857d8) scalar-value default on the peer canonical-Flux-v2-per-CR-substrate-default surface — the three defaults name the substrate’s canonical (install-path namespace-seeder) / (upgrade-path post-retry-exhaustion rollback) / (garbage-collection-toggle) toggle triple across the per-caixa HelmRelease and Kustomization co-resident CRs. All three are substrate-side policy choices the operator inherits when the per- caixa ClusterBundleOpts doesn’t pin an override, and all three must move together on any coordinated substrate-side Flux v2 per-CR tuning-cycle promotion. Until this lift landed the axis carried an inline true scalar-value literal at the sole production-code call site plus the sibling test-fixture navigation site ([cluster_bundle_helmrelease_install_create_namespace_pins_lifted_true] pin’s assert!(create_namespace) predicate) — two occurrences of the same load-bearing Flux-v2-per-CR-install-path-namespace-seeder- toggle-scalar-value convention, drift-prone by construction ahead of the third occurrence the M4 mesh.pleme.io/v1alpha1/Aplicacao CR materializer’s per-Aplicacao HelmRelease synthesis will surface. Same shape as the sibling caixa_core::DEFAULT_NAMESPACE / caixa_core::DEFAULT_LIBRARY_NAME / caixa_core::DEFAULT_FLUX_SYSTEM_NAMESPACE / caixa_core::DEFAULT_FLUX_RECONCILE_INTERVAL / caixa_core::DEFAULT_FLUX_KUSTOMIZATION_TIMEOUT / caixa_core::DEFAULT_PUBLISH_TAG_PREFIX / caixa_core::FLUX_HELMRELEASE_REMEDIATION_RETRIES_DEFAULT / caixa_core::FLUX_KUSTOMIZATION_PRUNE_DEFAULT / caixa_core::FLUX_HELMRELEASE_REMEDIATE_LAST_FAILURE_DEFAULT re-exports on the peer canonical-substrate-default-load-bearing- scalar surface. Canonical Flux v2 HelmRelease.spec.install.createNamespace install-path- only per-CR namespace-seeder-toggle scalar-value default the substrate seeds into every per-caixa helmrelease.yaml document at the paired FLUX_HELMRELEASE_KEY_CREATE_NAMESPACE leaf-scalar-key axis. Pairs with the sibling FLUX_HELMRELEASE_KEY_CREATE_NAMESPACE (ba9ab8b) leaf-scalar-key half of the same (leaf-key, scalar-value) per-CR install-path per-CR namespace-seeder-toggle declaration pair — the Flux v2 helm-controller’s per-CR install-path pre-apply loop reads the scalar under that exact leaf key to decide whether to first materialize the target namespace before the first-time chart apply, so drift on either axis is equally load-bearing (a rebrand on this canonical scalar-value default that failed to reach every renderer’s emit site would silently split the substrate’s chosen first-apply namespace-seeder semantic between the operator-facing canonical default and every per-caixa HelmRelease document’s per-CR install- path namespace-seeder-toggle, with no field naming the semantic-drift root cause far from the source caixa.lisp / the renderer’s format- string template).

FLUX_HELMRELEASE_KEY_CREATE_NAMESPACE

Canonical Flux v2 HelmRelease.spec.install.createNamespace install-path- only per-CR namespace-seeder-toggle leaf-scalar-key — re-export of the canonical caixa_core::FLUX_HELMRELEASE_KEY_CREATE_NAMESPACE so the Flux v2 helm-controller-side install-path per-CR namespace-seeder-toggle leaf-scalar-key lives in exactly one place across every caixa renderer. Peer to the sibling FLUX_HELMRELEASE_KEY_REMEDIATE_LAST_FAILURE (96581b7) upgrade-path-only per-CR remediation-toggle leaf-scalar-key at the mirror-symmetric parent-container-axis-key position — closes the spec.{install.createNamespace, upgrade.remediation.remediateLastFailure} per-path per-CR phase-specific toggle leaf-scalar-key pair the substrate seeds into every emitted per-caixa HelmRelease CR. One production emit site (this crate’s cluster_bundle helmrelease.yaml format-string template’s install-path namespace-seeder-toggle leaf under the sibling FLUX_HELMRELEASE_KEY_INSTALL-container-keyed sub-block, threading the same &'static str through a new {create_namespace_key} named- arg interpolation) plus one test-fixture navigation site in mod tests (the install-path [cluster_bundle_helmrelease_install_create_namespace_pins_lifted_true] pin’s .get(FLUX_HELMRELEASE_KEY_CREATE_NAMESPACE) probe) now consult the same &'static str. Until this lift landed the axis carried the load-bearing createNamespace bytes inline at the one production emit site; a future hypothetical Flux v3 rename (createTargetNamespace / seedNamespace / provisionNamespace) on the production-emit site without a coordinated edit on every per-renderer consumer the absorption roadmap surfaces (the M4 mesh.pleme.io/v1alpha1/Aplicacao CR materializer’s per-Aplicacao HelmRelease synthesis) would have silently dropped the substrate’s chosen first-apply namespace-seeder semantic from every emitted per-caixa HelmRelease document — the helm-controller would then refuse every first-time per-caixa chart apply against a fresh cluster whose target namespace has not been pre-provisioned by an out-of-band pipeline the substrate’s “no per- caixa Servico apply is blocked on manual namespace preprovisioning” MESH-COMPOSITION.md §V install-path-fluency guarantee mandates, with no diagnostic naming the seeder-toggle-drift root cause far from the source caixa.lisp / the renderer’s format-string template. Same shape as the sibling FLUX_HELMRELEASE_KEY_REMEDIATE_LAST_FAILURE (96581b7) upgrade-path-only per-CR remediation-toggle leaf-scalar-key + FLUX_HELMRELEASE_KEY_RETRIES (a12f9fc) leaf-scalar-key + peer FLUX_HELMRELEASE_KEY_REMEDIATION (6fe4e7e) sub-container-axis-key + FLUX_HELMRELEASE_KEY_INSTALL / FLUX_HELMRELEASE_KEY_UPGRADE (7767c26) parent-container-axis-key pair lifts on the peer per-CR HelmRelease-spec surface — extends the discipline from the sibling upgrade-path-only per-CR remediation-toggle onto the mirror install- path-only per-CR namespace-seeder-toggle at the spec.install.* position mirroring the peer’s spec.upgrade.remediation.* position. Canonical Flux v2 HelmRelease.spec.install.createNamespace install-path- only per-CR namespace-seeder-toggle leaf-scalar-key every caixa-flux- emitted helmrelease.yaml document seeds to true under the sibling FLUX_HELMRELEASE_KEY_INSTALL per-CR install-path phase-discriminator parent-container-axis-key. Peer to the sibling FLUX_HELMRELEASE_KEY_REMEDIATE_LAST_FAILURE upgrade-path-only per-CR remediation-toggle leaf-scalar-key at the co-resident per-CR install/ upgrade phase-discriminator parent-container position — closes the spec.{install.createNamespace, upgrade.remediation.remediateLastFailure} per-path per-CR phase-specific toggle leaf-scalar-key pair the substrate seeds into every emitted per-caixa HelmRelease CR: createNamespace gates the “the Flux v2 helm-controller creates the target namespace itself if the emitted HelmRelease.metadata.namespace (or its spec.targetNamespace override) does not already exist” install-path pre-apply seeder pipeline, while remediateLastFailure gates the upgrade-path post-retry-exhaustion rollback pipeline. The Flux v2 helm- controller-side per-CR install-path pre-apply loop keys off this exact leaf to decide whether to first materialize the target namespace or refuse the first-time chart apply when the target namespace does not yet exist (false); drift on this axis silently drops the substrate’s chosen first-apply namespace-seeder semantic from every emitted per- caixa HelmRelease document (the helm-controller then refuses every first-time per-caixa chart apply against a fresh cluster whose target namespace has not been pre-provisioned by an out-of-band pipeline — the substrate’s “no per-caixa Servico apply is blocked on manual namespace preprovisioning” MESH-COMPOSITION.md §V install-path-fluency guarantee silently regresses, with no diagnostic naming the seeder- toggle-drift root cause far from the source caixa.lisp / the renderer’s format-string template).

FLUX_HELMRELEASE_KEY_INSTALL

Canonical Flux v2 HelmRelease.spec.install per-CR helm-action-phase discriminator parent-container-axis-key — re-export of the canonical caixa_core::FLUX_HELMRELEASE_KEY_INSTALL so the Flux v2 helm- controller-side per-CR install-path phase-discriminator parent- container-axis-key lives in exactly one place across every caixa renderer. Pairs with the sibling FLUX_HELMRELEASE_KEY_UPGRADE per-CR helm-action-phase discriminator parent-container-axis-key on the peer per-CR upgrade-path phase. Peer to the sibling FLUX_HELMRELEASE_KEY_REMEDIATION (6fe4e7e) sub-container-axis-key hosted beneath both parent-container-axis-keys + FLUX_HELMRELEASE_KEY_RETRIES (a12f9fc) leaf-scalar-key + FLUX_HELMRELEASE_REMEDIATION_RETRIES_DEFAULT (30dcdae) scalar- value halves of the same (parent-container-key, sub-container-key, leaf-key, scalar-value) per-path retry-cap declaration quartet — closes the parent-container-axis-key axis on the same per-path retry- cap declaration quartet, so all four halves now live in one place. One production emit site (this crate’s cluster_bundle helmrelease.yaml format-string template’s install-path sub-block- header, threading the same &'static str through a new {install_key} named-arg interpolation) plus one test-fixture navigation site in mod tests (the install-path [cluster_bundle_helmrelease_install_remediation_retries_pins_lifted_default] pin’s .get(FLUX_HELMRELEASE_KEY_INSTALL) probe) now consult the same &'static str. Until this lift landed the axis carried two inline install literals across the one production emit site and the one test-fixture navigation site; a future hypothetical Flux v3 rename (initialize / apply / create / first-run) on the production-emit site without a coordinated edit on the sibling navigation site would have silently stripped the whole install-path per-CR phase block from the emitted HelmRelease CR, letting the helm-controller fall back to the Flux v2 upstream defaults for the whole install-path phase surface (the createNamespace: true seeder never fires, the per-CR retry-cap ceiling silently drops off the emitted document) rather than the substrate’s chosen per-CR install- path knob-set with no diagnostic naming the phase-discriminator-drift root cause. Same shape as the sibling FLUX_HELMRELEASE_KEY_REMEDIATION (6fe4e7e) sub-container-axis-key + FLUX_HELMRELEASE_KEY_RETRIES (a12f9fc) leaf-scalar-key + the peer FLUX_KEY_SOURCE_REF (236ef01) / FLUX_KEY_CHART / FLUX_KEY_VALUES / FLUX_KEY_INTERVAL / FLUX_KEY_HEALTH_CHECKS container-axis-key lifts on the peer per- CR container-axis-key surface — extends the discipline from the sub- container-axis-key one level up onto the parent-container-axis-key hosting it, so the four-level nested spec.install.remediation .retries declaration now resolves through four lifted &'static str / u32 values. Canonical Flux v2 HelmRelease.spec.install per-CR helm-action-phase discriminator parent-container-axis-key every caixa-flux-emitted helmrelease.yaml document nests the sibling FLUX_HELMRELEASE_KEY_REMEDIATION (6fe4e7e) sub-container-axis-key under, at the first-time chart apply per-CR phase the Flux v2 helm- controller reconciles when the emitted HelmRelease CR first lands in the cluster. Pairs with the sibling FLUX_HELMRELEASE_KEY_UPGRADE per-CR helm-action-phase discriminator parent-container-axis-key on the peer per-CR upgrade-path phase the helm-controller reconciles on every subsequent per-version chart re-apply the same CR gates. The Flux v2 helm-controller-side per-CR phase-dispatch loop keys off this exact parent-container-axis-key to select the install-path per-CR action pipeline (createNamespace seeder, first-time chart values merge, spec.install.remediation.retries retry-cap ceiling under the nested FLUX_HELMRELEASE_KEY_REMEDIATION sub-container), so drift on this axis is exactly as load-bearing as drift on the nested FLUX_HELMRELEASE_KEY_REMEDIATION sub-container-axis-key it hosts (a "initialize" / "apply" / "create" / "first-run" typo at the production-code call site silently strips the entire install-path per-CR phase block from the emitted per-CR document — the helm- controller then falls back to the Flux v2 upstream defaults for the whole install-path phase surface rather than the substrate’s chosen per-CR install-path knob-set — createNamespace never fires, the per-CR retry-cap ceiling silently drops off the emitted document, with no diagnostic naming the phase-discriminator-drift root cause far from the source caixa.lisp / the renderer’s format-string template).

FLUX_HELMRELEASE_KEY_REMEDIATE_LAST_FAILURE

Canonical Flux v2 HelmRelease.spec.upgrade.remediation.remediateLastFailure upgrade-path-only per-CR remediation-toggle leaf-scalar-key — re-export of the canonical caixa_core::FLUX_HELMRELEASE_KEY_REMEDIATE_LAST_FAILURE so the Flux v2 helm-controller-side upgrade-path per-CR remediation- toggle leaf-scalar-key lives in exactly one place across every caixa renderer. Sibling to the peer FLUX_HELMRELEASE_KEY_RETRIES per-CR retry-cap leaf-scalar-key at the same per-CR upgrade-path per-CR remediation sub-container position — closes the spec.upgrade.remediation.{retries, remediateLastFailure} per-path remediation-block leaf-scalar-key pair the substrate seeds into every emitted per-caixa HelmRelease CR on the upgrade-path per-CR remediation block. One production emit site (this crate’s cluster_bundle helmrelease.yaml format-string template’s upgrade-path remediation-toggle leaf under the sibling FLUX_HELMRELEASE_KEY_REMEDIATION-container-keyed sub-block, threading the same &'static str through a new {remediate_last_failure_key} named-arg interpolation) plus one test- fixture navigation site in mod tests (the upgrade-path [cluster_bundle_helmrelease_upgrade_remediation_remediate_last_failure_pins_lifted_true] pin’s .get(FLUX_HELMRELEASE_KEY_REMEDIATE_LAST_FAILURE) probe) now consult the same &'static str. Until this lift landed the axis carried the load-bearing remediateLastFailure bytes inline at the one production emit site; a future hypothetical Flux v3 rename (rollbackOnFailure / remediateOnFailure / recoverLastFailure) on the production-emit site without a coordinated edit on every per-renderer consumer the absorption roadmap surfaces (the M4 mesh.pleme.io/v1alpha1/Aplicacao CR materializer’s per-Aplicacao HelmRelease synthesis) would have silently dropped the substrate’s chosen post-retry-exhaustion rollback semantic from every emitted per-caixa HelmRelease document — the helm-controller would then leave every terminally-failed upgrade in the failed state without rolling back to the prior last-known-good release the substrate’s “no chart apply leaves a per-caixa CR in a stalled, unremediated state” MESH-COMPOSITION.md §V guarantee mandates, with no diagnostic naming the remediation-toggle-drift root cause far from the source caixa.lisp / the renderer’s format-string template. Same shape as the sibling FLUX_HELMRELEASE_KEY_RETRIES (a12f9fc) leaf-scalar- key + the peer FLUX_HELMRELEASE_KEY_REMEDIATION (6fe4e7e) sub- container-axis-key + FLUX_HELMRELEASE_KEY_INSTALL / FLUX_HELMRELEASE_KEY_UPGRADE (7767c26) parent-container-axis-key pair lifts on the peer per-CR remediation-surface leaf-scalar-key / container-axis-key surface — extends the discipline from the sibling retry-cap leaf-scalar-key onto the co-resident remediation-toggle leaf-scalar-key at the same spec.upgrade.remediation.* position. Canonical Flux v2 HelmRelease.spec.upgrade.remediation.remediateLastFailure upgrade-path-only per-CR remediation-toggle leaf-scalar-key every caixa-flux-emitted helmrelease.yaml document seeds to true under the sibling FLUX_HELMRELEASE_KEY_UPGRADE per-CR upgrade-path phase- discriminator parent-container-axis-key’s nested FLUX_HELMRELEASE_KEY_REMEDIATION sub-container-axis-key. Sibling to the peer FLUX_HELMRELEASE_KEY_RETRIES retry-cap leaf-scalar-key at the same per-CR upgrade-path per-CR remediation sub-container position — closes the spec.upgrade.remediation.{retries, remediateLastFailure} per-path remediation-block leaf-scalar-key pair the substrate seeds into every emitted per-caixa HelmRelease CR on the upgrade-path per-CR remediation block, with retries capping the per-version chart re-apply retry-count and remediateLastFailure gating the “the Flux v2 helm- controller must actively remediate — roll back to the prior success — when the final per-version chart re-apply attempt still fails” post- retry-exhaustion behavior. The Flux v2 helm-controller-side per-CR upgrade-path remediation loop keys off this exact leaf to decide whether to leave a failed upgrade in place (false) or trigger the prior-release rollback pipeline (true); drift on this axis silently drops the substrate’s chosen post-retry-exhaustion rollback semantic from every emitted per-caixa HelmRelease document (the helm- controller then leaves every terminally-failed upgrade in the failed state without rolling back to the prior last-known-good release the substrate’s “no chart apply leaves a per-caixa CR in a stalled, unremediated state” MESH-COMPOSITION.md §V guarantee mandates — with no diagnostic naming the remediation-toggle-drift root cause far from the source caixa.lisp / the renderer’s format-string template).

FLUX_HELMRELEASE_KEY_REMEDIATION

Canonical Flux v2 HelmRelease.spec.{install,upgrade}.remediation sub-container-axis-key — re-export of the canonical caixa_core::FLUX_HELMRELEASE_KEY_REMEDIATION so the Flux v2 helm-controller-side per-CR remediation sub-container-axis-key lives in exactly one place across every caixa renderer. Peer to the sibling FLUX_HELMRELEASE_KEY_RETRIES (a12f9fc) leaf-scalar-key half + the sibling FLUX_HELMRELEASE_REMEDIATION_RETRIES_DEFAULT (30dcdae) scalar-value half of the same (container-axis-key, leaf-scalar-key, scalar-value) per-path retry- cap declaration triple — closes the parent-container-axis-key axis on the same per-path retry-cap declaration, so all three halves now live in one place. Two production emit sites (this crate’s cluster_bundle helmrelease.yaml format-string template’s install-path remediation sub-block-header + the sibling upgrade-path remediation sub-block-header, both threading the same &'static str through a {remediation_key} named-arg interpolation) plus two test- fixture navigation sites in mod tests (the install-path [cluster_bundle_helmrelease_install_remediation_retries_pins_lifted_default] pin’s .get(FLUX_HELMRELEASE_KEY_REMEDIATION) probe + the sibling upgrade-path [cluster_bundle_helmrelease_upgrade_remediation_retries_pins_lifted_default] pin’s peer probe) now consult the same &'static str. Until this lift landed the axis carried four inline remediation literals across the two production emit sites and the two test-fixture navigation sites; a future hypothetical Flux v3 rename (recovery / retryPolicy / errorHandling) on any production-emit site without a coordinated edit on the sibling navigation sites would have silently stripped the whole per-path remediation sub-block from the emitted HelmRelease CR, letting the helm-controller fall back to the Flux v2 upstream defaults for the whole remediation surface rather than the substrate’s chosen ceiling with no diagnostic naming the sub-container-key-drift root cause. Same shape as the sibling FLUX_HELMRELEASE_KEY_RETRIES (a12f9fc) leaf-scalar-key half plus the peer FLUX_KEY_SOURCE_REF (236ef01) / FLUX_KEY_CHART / FLUX_KEY_VALUES / FLUX_KEY_INTERVAL / FLUX_KEY_HEALTH_CHECKS container-axis-key lifts on the peer per- CR container-axis-key surface — extends the discipline from the leaf-scalar-key at the bottom of the two-level nested per-path retry-cap declaration onto the sub-container-axis-key one level up. Canonical Flux v2 HelmRelease.spec.{install,upgrade}.remediation sub-container-axis-key every caixa-flux-emitted helmrelease.yaml document nests the sibling FLUX_HELMRELEASE_KEY_RETRIES retry-cap leaf-scalar-key under, at both the install-path + upgrade-path per-CR remediation blocks. The parent-container-axis-key half of the same (container-axis-key, leaf-scalar-key, scalar-value) per-path retry-cap declaration triple the sibling FLUX_HELMRELEASE_REMEDIATION_RETRIES_DEFAULT (30dcdae) scalar-value

FLUX_HELMRELEASE_KEY_RETRIES

Canonical Flux v2 HelmRelease.spec.{install,upgrade}.remediation.retries leaf scalar-key — re-export of the canonical caixa_core::FLUX_HELMRELEASE_KEY_RETRIES so the Flux v2 helm-controller-side per-CR remediation-retries leaf-scalar-key lives in exactly one place across every caixa renderer. Peer to the sibling FLUX_HELMRELEASE_REMEDIATION_RETRIES_DEFAULT (30dcdae) scalar- value half of the same (leaf-key, scalar-value) per-path retry-cap declaration pair — extends the drift-closing discipline the scalar- value lift established from the value the leaf holds onto the leaf- key itself. Two production emit sites (this crate’s cluster_bundle helmrelease.yaml format-string template’s install-path retry-cap leaf under the FLUX_HELMRELEASE_REMEDIATION_RETRIES_DEFAULT-valued sub-block + the sibling upgrade-path retry-cap leaf under the same scalar-value, both threading the same &'static str through a {retries_key} named-arg interpolation) plus two test-fixture navigation sites in mod tests (the install-path [cluster_bundle_helmrelease_install_remediation_retries_pins_lifted_default] pin’s .get("retries") probe + the sibling upgrade-path [cluster_bundle_helmrelease_upgrade_remediation_retries_pins_lifted_default] pin’s peer probe) now consult the same &'static str. Until this lift landed the axis carried four inline retries literals across the two production emit sites and the two test-fixture navigation sites; a future hypothetical Flux v3 rename (attempts / maxRetries / retryCount) on any production-emit site without a coordinated edit on the sibling navigation sites would have silently stripped the retry-cap declaration from the emitted remediation: sub-block, letting the helm-controller fall back to the Flux v2 upstream default rather than the substrate’s chosen ceiling with no diagnostic naming the leaf-key-drift root cause. Same shape as the sibling FLUX_KEY_SOURCE_REF (236ef01) / FLUX_KEY_CHART / FLUX_KEY_VALUES / FLUX_KEY_INTERVAL / FLUX_KEY_HEALTH_CHECKS lifts on the peer per-CR container-axis- key surface — extends the discipline from the container-axis keys that nest per-CR sub-blocks onto a leaf-scalar-key at the bottom of a two-level nested per-path retry-cap declaration. Canonical Flux v2 HelmRelease.spec.{install,upgrade}.remediation.retries leaf scalar-key every caixa-flux-emitted helmrelease.yaml document carries at both its install-path + upgrade-path per-CR remediation blocks. Peer to the sibling FLUX_HELMRELEASE_REMEDIATION_RETRIES_DEFAULT (30dcdae) scalar-value half of the same (leaf-key, scalar-value) per-path retry-cap declaration pair — the Flux v2 helm-controller’s per-CR remediation loop reads the scalar under this exact leaf key, so drift on either axis is equally load-bearing (a typo on the leaf-key silently strips the retry-cap declaration from the emitted remediation: sub-block — the helm-controller then falls back to the Flux v2 upstream default rather than the substrate’s chosen ceiling — with no diagnostic naming the leaf-key-drift root cause far from the source caixa.lisp / the renderer’s format-string template).

FLUX_HELMRELEASE_KEY_UPGRADE

Canonical Flux v2 HelmRelease.spec.upgrade per-CR helm-action-phase discriminator parent-container-axis-key — re-export of the canonical caixa_core::FLUX_HELMRELEASE_KEY_UPGRADE so the Flux v2 helm- controller-side per-CR upgrade-path phase-discriminator parent- container-axis-key lives in exactly one place across every caixa renderer. Pairs with the sibling FLUX_HELMRELEASE_KEY_INSTALL per-CR helm-action-phase discriminator parent-container-axis-key on the peer per-CR install-path phase. Peer to the sibling FLUX_HELMRELEASE_KEY_REMEDIATION (6fe4e7e) sub-container-axis-key hosted beneath both parent-container-axis-keys. One production emit site (this crate’s cluster_bundle helmrelease.yaml format- string template’s upgrade-path sub-block-header, threading the same &'static str through a new {upgrade_key} named-arg interpolation) plus one test-fixture navigation site in mod tests (the upgrade- path [cluster_bundle_helmrelease_upgrade_remediation_retries_pins_lifted_default] pin’s .get(FLUX_HELMRELEASE_KEY_UPGRADE) probe) now consult the same &'static str. Until this lift landed the axis carried two inline upgrade literals across the one production emit site and the one test-fixture navigation site; a future hypothetical Flux v3 rename (reapply / reconcile / update / promote) on the production-emit site without a coordinated edit on the sibling navigation site would have silently stripped the whole upgrade-path per-CR phase block from the emitted HelmRelease CR, letting the helm-controller fall back to the Flux v2 upstream defaults for the whole upgrade-path phase surface (the substrate’s remediateLastFailure: true toggle never fires, the per-CR retry- cap ceiling silently drops off the emitted document) rather than the substrate’s chosen per-CR upgrade-path knob-set with no diagnostic naming the phase-discriminator-drift root cause. Same shape as the sibling FLUX_HELMRELEASE_KEY_INSTALL parent-container-axis-key on the peer per-CR install-path phase — pairs with the install-path re-export to close the per-CR helm-action-phase discriminator parent-container-axis-key pair across both per-CR phases the helm- controller reconciles between. Canonical Flux v2 HelmRelease.spec.upgrade per-CR helm-action-phase discriminator parent-container-axis-key every caixa-flux-emitted helmrelease.yaml document nests the sibling FLUX_HELMRELEASE_KEY_REMEDIATION (6fe4e7e) sub-container-axis-key under, at every subsequent per-version chart re-apply per-CR phase the Flux v2 helm-controller reconciles after the initial install-path phase completes. Pairs with the sibling FLUX_HELMRELEASE_KEY_INSTALL per-CR helm-action-phase discriminator parent-container-axis-key on the peer per-CR install-path phase the helm-controller reconciles at first-time chart apply. The Flux v2 helm-controller-side per-CR phase-dispatch loop keys off this exact parent-container-axis-key to select the upgrade-path per-CR action pipeline (remediateLastFailure toggle the substrate pins to true on the upgrade-path per-CR sibling axis, the per-CR retry-cap ceiling under the nested FLUX_HELMRELEASE_KEY_REMEDIATION sub-container), so drift on this axis is exactly as load-bearing as drift on the nested FLUX_HELMRELEASE_KEY_REMEDIATION sub-container-axis-key it hosts (a "reapply" / "reconcile" / "update" / "promote" typo at the production-code call site silently strips the entire upgrade- path per-CR phase block from the emitted per-CR document — the helm- controller then falls back to the Flux v2 upstream defaults for the whole upgrade-path phase surface rather than the substrate’s chosen per-CR upgrade-path knob-set — remediateLastFailure never fires, the per-CR retry-cap ceiling silently drops off the emitted document, with no diagnostic naming the phase-discriminator-drift root cause far from the source caixa.lisp / the renderer’s format-string template).

FLUX_HELMRELEASE_REMEDIATE_LAST_FAILURE_DEFAULT

Canonical Flux v2 HelmRelease.spec.upgrade.remediation.remediateLastFailure upgrade-path-only per-CR remediation-toggle scalar-value default the substrate seeds into every per-caixa helmrelease.yaml document at the paired FLUX_HELMRELEASE_KEY_REMEDIATE_LAST_FAILURE leaf-scalar-key axis. Re-export of the canonical caixa_core::FLUX_HELMRELEASE_REMEDIATE_LAST_FAILURE_DEFAULT so the Flux v2 helm-controller-side per-CR upgrade-path per-CR post-retry- exhaustion-rollback-toggle scalar-value default lives in exactly one place across every caixa renderer — cluster_bundle’s helmrelease.yaml format-string template’s per-CR upgrade-path remediation-toggle scalar under the FLUX_HELMRELEASE_KEY_UPGRADE- keyed sub-block (the sole production-code site the prior inline remediateLastFailure: true scalar-value literal sat at, alongside the FLUX_HELMRELEASE_KEY_REMEDIATE_LAST_FAILURE-keyed leaf-scalar-key half of the same (leaf-key, scalar-value) pair) now threads the same bool through a {remediate_last_failure_default} named-arg interpolation, so a future substrate-side toggle migration (true → false on a per-cluster class where terminally-failed upgrades must escalate to operator-attention rather than mask under an auto-rollback pipeline; a per-caixa opt-out slot the ABSORPTION-ROADMAP.md M4 typed- slot trajectory adds once the substrate grows a :upgrade :remediate-last-failure author-side toggle) is a one-line edit on the canonical caixa_core::FLUX_HELMRELEASE_REMEDIATE_LAST_FAILURE_DEFAULT declaration, not a coordinated rewrite across the emit site + every future per-target renderer the substrate adds. Pairs with the sibling FLUX_HELMRELEASE_KEY_REMEDIATE_LAST_FAILURE re-export on the same per-CR spec.upgrade.remediation.remediateLastFailure scalar-axis — the key half of the per-CR scalar-key/scalar-value pair lives at FLUX_HELMRELEASE_KEY_REMEDIATE_LAST_FAILURE, the value half’s substrate-side default seed lives here. Same shape as the sibling FLUX_KUSTOMIZATION_PRUNE_DEFAULT (ea857d8) scalar-value default re-export on the peer per-CR Kustomization garbage-collection-toggle axis — that default names whether the per-CR Kustomization reconcile loop sweeps orphaned resources at all, and this default names whether the per-CR HelmRelease upgrade-path remediation loop rolls back to the prior last-known-good release once the retry-cap ceiling is exhausted. Both are substrate-side policy choices the operator inherits when the per-caixa ClusterBundleOpts doesn’t pin an override, and both must move together on any coordinated substrate- side Flux v2 per-CR tuning-cycle promotion. Until this lift landed the axis carried an inline true scalar-value literal at the sole production-code call site plus the sibling test-fixture navigation site ([cluster_bundle_helmrelease_upgrade_remediation_remediate_last_failure_pins_lifted_true] pin’s assert!(remediate_last_failure) predicate) — two occurrences of the same load-bearing Flux-v2-per-CR-upgrade-path-remediation- toggle-scalar-value convention, drift-prone by construction ahead of the third occurrence the M4 mesh.pleme.io/v1alpha1/Aplicacao CR materializer’s per-Aplicacao HelmRelease synthesis will surface. Same shape as the sibling caixa_core::DEFAULT_NAMESPACE / caixa_core::DEFAULT_LIBRARY_NAME / caixa_core::DEFAULT_FLUX_SYSTEM_NAMESPACE / caixa_core::DEFAULT_FLUX_RECONCILE_INTERVAL / caixa_core::DEFAULT_FLUX_KUSTOMIZATION_TIMEOUT / caixa_core::DEFAULT_PUBLISH_TAG_PREFIX / caixa_core::FLUX_HELMRELEASE_REMEDIATION_RETRIES_DEFAULT / caixa_core::FLUX_KUSTOMIZATION_PRUNE_DEFAULT re-exports on the peer canonical-substrate-default-load-bearing-scalar surface. Canonical Flux v2 HelmRelease.spec.upgrade.remediation.remediateLastFailure upgrade-path-only per-CR remediation-toggle scalar-value default the substrate seeds into every per-caixa helmrelease.yaml document at the paired FLUX_HELMRELEASE_KEY_REMEDIATE_LAST_FAILURE leaf-scalar-key axis. Pairs with the sibling FLUX_HELMRELEASE_KEY_REMEDIATE_LAST_FAILURE (96581b7) leaf-scalar-key half of the same (leaf-key, scalar-value) per-CR upgrade-path per-CR post-retry-exhaustion-rollback-toggle declaration pair — the Flux v2 helm-controller’s per-CR upgrade-path remediation loop reads the scalar under that exact leaf key to decide whether to trigger the prior-release rollback pipeline once the paired FLUX_HELMRELEASE_KEY_RETRIES retry-cap ceiling has been exhausted, so drift on either axis is equally load-bearing (a rebrand on this canonical scalar-value default that failed to reach every renderer’s emit site would silently split the substrate’s chosen post-retry- exhaustion rollback semantic between the operator-facing canonical default and every per-caixa HelmRelease document’s per-CR upgrade- path remediation-toggle, with no field naming the semantic-drift root cause far from the source caixa.lisp / the renderer’s format-string template).

FLUX_HELMRELEASE_REMEDIATION_RETRIES_DEFAULT

Canonical Flux v2 HelmRelease.spec.{install,upgrade}.remediation.retries bounded retry-count default the substrate seeds into every per-caixa helmrelease.yaml document. Re-export of the canonical caixa_core::FLUX_HELMRELEASE_REMEDIATION_RETRIES_DEFAULT so the Flux v2 helm-controller-side remediation-retries default scalar-value lives in exactly one place across every caixa renderer — cluster_bundle’s helmrelease.yaml format-string template’s two production-code retry-cap sites (the prior inline retries: 3 scalar-value literal under the install.remediation sub-block + the second inline retries: 3 scalar-value literal under the upgrade.remediation sub-block) now both consume the same u32 at emit time through one {retries_default} named-arg interpolation, so a future substrate-side retry-ceiling migration (3 → 5 once per- caixa idempotency invariants tighten, 3 → 1 on hardened per-caixa pipelines where a failed apply should escalate to operator-attention rather than mask under further retries — coordinated with the upstream Flux v2 project’s per-controller tuning cycle) is a one-line edit on the canonical caixa_core::FLUX_HELMRELEASE_REMEDIATION_RETRIES_DEFAULT declaration, not a coordinated rewrite across the two per-CR remediation-retries sites. Before this lift the two axes carried independently-inlined retries: 3 literals in the sibling install.remediation.retries / upgrade.remediation.retries positions of the cluster_bundle helmrelease.yaml format-string template — any future retry-ceiling migration on one axis without a coordinated edit on the other would have silently split the substrate’s canonical retry-ceiling between the install-path (first- time chart applies) and the upgrade-path (every subsequent per- caixa-version re-apply the same HelmRelease gates), with no field naming the ceiling-drift root cause. Pairs with the sibling DEFAULT_FLUX_RECONCILE_INTERVAL re-export on the same canonical- Flux-v2-per-CR-substrate-default surface — the reconcile-poll cadence default names how often the helm-controller re-evaluates per-CR desired state, and this retry-cap names how many times a per- evaluation Helm action is allowed to fail-and-retry before it stops. Same shape as the sibling caixa_core::DEFAULT_NAMESPACE / caixa_core::DEFAULT_LIBRARY_NAME / caixa_core::DEFAULT_FLUX_SYSTEM_NAMESPACE / caixa_core::DEFAULT_FLUX_RECONCILE_INTERVAL / caixa_core::DEFAULT_PUBLISH_TAG_PREFIX re-exports on the peer canonical-substrate-default-load-bearing-scalar surface. Canonical Flux v2 HelmRelease.spec.{install,upgrade}.remediation.retries bounded retry-count scalar every caixa-flux-emitted helmrelease.yaml document declares under both the install-path and the upgrade-path remediation blocks. The Flux v2 helm-controller per-CR Install / Upgrade action reconciler consumes this scalar as the ceiling on the number of times it will re-attempt a failed Helm install or Helm upgrade before it marks the HelmRelease Ready: False and stops retrying — the substrate’s canonical “how many times we let Flux re-try a chart apply before it stops” contract with the helm-controller-side per-CR remediation loop.

FLUX_HELMRELEASE_YAML_FILENAME

Canonical Flux v2 per-cluster-bundle HelmRelease document filename every cluster_bundle-rendered BundleFile carries at its per-file path axis — re-export of the lifted caixa_core::FLUX_HELMRELEASE_YAML_FILENAME so the fixed filename the cluster-side FluxCD kustomize-controller looks up when it opens the per-Servico bundle directory lives in exactly one place across every caixa renderer. The single source of truth all thirteen consumers reach for — one production cluster_bundle BundleFile assembly’s HelmRelease document path axis plus a dozen test-side round-trip navigators that reach into the rendered bundle by the same filename to pin per-CR body-axis emission — now consult the same &'static str. Pin the equality + &'static static-data identity so any local re-introduction of a sibling pub const FLUX_HELMRELEASE_YAML_FILENAME: &str = "…" at this crate is a build-time test failure naming the offending drift, not a silent FluxCD kustomize-controller “no HelmRelease document found under this bundle” reroute at cluster-side reconcile time far from the drift site. Peer to the HELM_CHART_YAML_FILENAME (caixa_core::HELM_CHART_YAML_FILENAME, c2c99b0) / HELM_VALUES_YAML_FILENAME (caixa_core::HELM_VALUES_YAML_FILENAME, 9a980ba) re-exports on the sibling Helm-chart-directory filename surfaces — pivots the canonical-filename single-sourcing discipline from the per-Helm-chart-directory metadata / values file axes onto the sibling per-Flux-v2-bundle HelmRelease document filename axis this crate’s cluster_bundle renders. Canonical Flux v2 per-cluster-bundle HelmRelease document filename every caixa-flux-rendered cluster_bundle carries at the per-Servico bundle’s rendered file collection — the fixed filename the sibling gitrepository.yaml + kustomization.yaml bundle documents key against when the cluster-side FluxCD controllers reconcile the per-Servico release cycle, and the exact filename every downstream consumer that reaches into the rendered bundle by document name looks up.

FLUX_KEY_CHART

Canonical Flux v2 per-HelmRelease inline-chart-template container- axis key every caixa-flux-emitted HelmRelease document nests its per-CR chart-template block under (spec.chart on HelmRelease). Re- export of the canonical caixa_core::FLUX_KEY_CHART so the load- bearing Flux-v2-helm-controller-side per-HelmRelease chart-template container-axis key lives in exactly one place across every caixa renderer — the sweep converts this crate’s one production-code call site (the cluster_bundle helmrelease.yaml format-string template’s baked chart:\n container-axis key nesting the HelmChartTemplate sub-document whose peer sibling lifted FLUX_KEY_SOURCE_REF source-reference container-axis + inner chart-name-scalar reach through) plus the two test-fixture .get("chart") navigation sites in mod tests that probe the emitted spec.chart.spec.sourceRef.kind pin onto the re-export. A future Flux v3 rebrand of the per-HelmRelease chart-template container-axis key (a hypothetical upstream fluxcd/flux2 rename from chart to Chart / chartTemplate / helmChart / chartRef, coordinated with the upstream project’s per-version deprecation cycle) now lands at one const rather than scattered across the one emit-side format-string template + two test-fixture probe sites. Same “the typed constant lives in one place” discipline the peer FLUX_KEY_SOURCE_REF + FLUX_KEY_VALUES re-exports enforce on the sibling Flux v2 per-HelmRelease body-key surfaces — completes the triplet of Flux v2 per-HelmRelease spec.* body-key constants (spec.chart + spec.chart.spec.sourceRef + spec.values) the cluster_bundle renderer threads through its helmrelease.yaml format-string template. Canonical Flux v2 per-HelmRelease inline-chart-template container-axis key every caixa-flux-emitted HelmRelease document nests its per-CR chart-template block under (spec.chart on HelmRelease) — the Flux v2 CRD schema places the HelmChartTemplate sub-document (whose nested spec.chart string names the referenced chart, spec.sourceRef names the source-of-truth (kind, name, namespace) triple, and spec.interval names the per-CR reconcile cadence) under this single container key, so drift on the container axis silently dangles the whole chart-template block the Flux v2 helm-controller’s per-CR reconcile loop reads to source the referenced chart at Helm-render time (a "Chart" / "chartTemplate" / "helmChart" / "chartRef" typo at either the emit-side format-string template or a downstream test- fixture probe silently dangles the HelmRelease.spec.chart chart- template resolution at the Flux v2 helm-controller’s CRD registration; the referenced chart never resolves, and the per-Servico workload freezes at apply time with no field naming the container-axis-drift root cause).

FLUX_KEY_HEALTH_CHECKS

Canonical Flux v2 per-Kustomization health-gate reference-list container-axis key every caixa-flux-emitted kustomization.yaml document mounts its per-sibling-HelmRelease health-probe list under (spec.healthChecks on Kustomization). Re-export of the canonical caixa_core::FLUX_KEY_HEALTH_CHECKS so the load-bearing Flux-v2- kustomize-controller-side per-Kustomization health-gate reference- list container-axis key lives in exactly one place across every caixa renderer — the sweep converts this crate’s one production-code call site (the cluster_bundle kustomization.yaml format-string template’s baked healthChecks:\n container-axis key nesting the per-entry []NamespacedObjectKindReference list whose peer sibling lifted FLUX_HELMRELEASE_API_VERSION per-entry apiVersion axis + FLUX_KIND_HELM_RELEASE per-entry kind axis the health-gate references) plus the three test-fixture .get("healthChecks") navigation sites in mod tests that probe the emitted per-entry apiVersion + kind pin onto the re-export. A future Flux v3 rebrand of the per-Kustomization health-gate reference-list container-axis key (a hypothetical upstream fluxcd/flux2 rename from healthChecks to HealthChecks / healthchecks / healthcheck / health_checks / probes, coordinated with the upstream project’s per-version deprecation cycle) now lands at one const rather than scattered across the one emit-side format-string template + three test-fixture probe sites. Same “the typed constant lives in one place” discipline the peer FLUX_KEY_SOURCE_REF + FLUX_KEY_CHART + FLUX_KEY_VALUES re-exports enforce on the sibling Flux v2 per-HelmRelease + per-Kustomization body-key surfaces — completes the quartet of Flux v2 spec.* body-key constants (spec.chart + spec.chart.spec.sourceRef

FLUX_KEY_INTERVAL

Canonical Flux v2 per-CR reconcile-poll cadence scalar-axis key every caixa-flux-emitted Flux document (GitRepository, HelmRelease, Kustomization) declares its per-CR spec.interval reconcile cadence under. Re-export of the canonical caixa_core::FLUX_KEY_INTERVAL so the load-bearing Flux-v2-controller-triplet-side per-CR reconcile-poll cadence scalar-axis key lives in exactly one place across every caixa renderer — the sweep converts this crate’s three production-code call sites (the cluster_bundle gitrepository.yaml + helmrelease.yaml

FLUX_KEY_SOURCE_REF

Canonical Flux v2 per-HelmRelease/Kustomization source-reference container-axis key every caixa-flux-emitted bundle document mounts its per-CR source-of-truth (kind, name, namespace) reference triple under (spec.chart.spec.sourceRef on HelmRelease, spec.sourceRef on Kustomization). Re-export of the canonical caixa_core::FLUX_KEY_SOURCE_REF so the load-bearing Flux-v2-source- controller-side per-CR source-reference container-axis key lives in exactly one place across every caixa renderer — the sweep converts this crate’s two production emit sites (the cluster_bundle helmrelease.yaml format-string template’s baked spec.chart.spec.sourceRef:\n sub-block header + the sibling kustomization.yaml format-string template’s baked spec.sourceRef:\n sub-block header, both now threaded through a {source_ref_key} named-arg interpolation on the lifted const, closing the last two open production sites for this axis) plus the five test-fixture .get("sourceRef") navigation sites in mod tests (the helmrelease.yaml spec.chart.spec.sourceRef.kind pin, the kustomization.yaml spec.sourceRef.name + spec.sourceRef.kind pins under the paired DEFAULT_FLUX_SYSTEM_NAMESPACE + FLUX_KIND_GIT_REPOSITORY canonical-string axes, and the two cross-axis triplet pins that traverse both bundle documents to pin the sibling GitRepository-kind axis triplet against one canonical string) onto the re-export. A future Flux v3 rebrand of the per-CR source-reference container-axis key (a hypothetical upstream fluxcd/flux2 rename from sourceRef to source / sourceReference / sourceOf, coordinated with the upstream project’s per-version deprecation cycle) now lands at one const rather than scattered across the two per-CR format-string templates

FLUX_KEY_VALUES

Canonical Flux v2 per-HelmRelease values-override block-body-axis key every caixa-flux-emitted HelmRelease document nests its per- cluster value overrides under (spec.values on HelmRelease). Re- export of the canonical caixa_core::FLUX_KEY_VALUES so the load- bearing Flux-v2-helm-controller-side per-HelmRelease values- override block-body-axis key lives in exactly one place across every caixa renderer — the sweep converts this crate’s one production-code call site (the cluster_bundle helmrelease.yaml format-string template’s baked values:\n key beside the sibling lifted DEFAULT_LIBRARY_NAME wrap key + HELM_VALUES_KEY_ENABLED enable-toggle) plus the upsert_into_helmrelease_programs upsert-path’s spec.values.programs[] write-side navigation onto the re-export, and threads three test-fixture .get("values") block- body-axis probe sites in mod tests through the same const. A future Flux v3 rebrand of the per-HelmRelease values-override block-body-axis key (a hypothetical upstream fluxcd/flux2 rename from values to Values / chartValues / overrides, coordinated with the upstream project’s per-version deprecation cycle) now lands at one const rather than scattered across the one emit-side format- string template + one upsert-side write-side navigation + three test-fixture probe sites. Same “the typed constant lives in one place” discipline the peer FLUX_KEY_SOURCE_REF + FLUX_KIND_GIT_REPOSITORY / FLUX_KIND_HELM_RELEASE / FLUX_KIND_KUSTOMIZATION + FLUX_HELMRELEASE_API_VERSION / FLUX_GITREPOSITORY_API_VERSION / FLUX_KUSTOMIZATION_API_VERSION re-exports enforce on the sibling canonical-Flux-v2-load-bearing- string surfaces. Canonical Flux v2 per-HelmRelease values-override block-body-axis key every caixa-flux-emitted HelmRelease document nests its per-cluster value overrides under (spec.values on HelmRelease) — the Flux v2 CRD schema places the arbitrary per-cluster-override YAML body under this single key, so drift on the block-body-axis silently dangles the per-cluster override the helm-controller’s per-CR reconcile loop merges into the referenced chart’s values.yaml at Helm-render time (a "Values" / "vals" / "chartValues" / "overrides" typo at either the emit-side format-string template, the upsert_into_helmrelease_programs upsert-path’s spec.values.programs[] write, or a downstream test-fixture probe silently routes the per-cluster overrides nowhere; the workload silently comes up with the referenced chart’s admission- time defaults, far from the source caixa.lisp / the renderer’s format-string template).

FLUX_KIND_GIT_REPOSITORY

Canonical FluxCD GitRepository CRD kind discriminator — re-export of the lifted caixa_core::FLUX_KIND_GIT_REPOSITORY so the load- bearing string lives in exactly one place across the three rendered Flux bundle axes that name the same K8s CRD discriminator:

FLUX_KIND_HELM_RELEASE

Canonical FluxCD HelmRelease CRD kind discriminator — re-export of the lifted caixa_core::FLUX_KIND_HELM_RELEASE so the load- bearing string lives in exactly one place across the two rendered Flux bundle axes that name the same K8s CRD discriminator:

FLUX_KIND_KUSTOMIZATION

Canonical FluxCD Kustomization CRD kind discriminator — re-export of the lifted caixa_core::FLUX_KIND_KUSTOMIZATION so the load- bearing string lives in exactly one place across the rendered Flux bundle’s Kustomization-naming axis:

FLUX_KUSTOMIZATION_API_VERSION

Canonical FluxCD Kustomization CRD apiVersion — re-export of the lifted caixa_core::FLUX_KUSTOMIZATION_API_VERSION so the load- bearing string lives in exactly one place across the rendered Flux bundle’s kustomization.yaml document apiVersion axis. 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) re-exports — every per-controller CRD-group/version is now a typed substrate-side &'static str consumed through one pub use caixa_core::FLUX_* re-export.

FLUX_KUSTOMIZATION_KEY_PATH

Canonical Flux v2 Kustomization.spec.path per-CR source-sub-tree leaf-scalar-key — re-export of the canonical caixa_core::FLUX_KUSTOMIZATION_KEY_PATH so the Flux v2 kustomize- controller-side per-CR source-sub-tree leaf-scalar-key lives in exactly one place across every caixa renderer. Peer to the sibling co-resident FLUX_KUSTOMIZATION_KEY_PRUNE (8ec7917) per-CR garbage-collection-toggle leaf-scalar-key on the same top-level spec position of the emitted per-caixa Kustomization CR — extends the per-Kustomization-CR-spec leaf-scalar-key discipline from the co-resident garbage-collection-toggle axis onto the co-resident source-sub-tree axis at the mirror-symmetric top-level spec.path position. One production emit site (this crate’s cluster_bundle kustomization.yaml format-string template’s per-CR source-sub-tree leaf under the top-level spec position, threading the same &'static str through a new {path_key} named-arg interpolation) plus one test-fixture navigation site in mod tests (the per-CR [cluster_bundle_kustomization_path_pins_lifted_sub_tree] pin’s .get(FLUX_KUSTOMIZATION_KEY_PATH) probe) now consult the same &'static str. Until this lift landed the axis carried the load- bearing path bytes inline at the one production emit site; a future hypothetical Flux v3 rename (sourcePath / manifestsPath / sourceRoot) on the production-emit site without a coordinated edit on every per-renderer consumer the absorption roadmap surfaces (the M4 mesh.pleme.io/v1alpha1/Aplicacao CR materializer’s per- Aplicacao Kustomization synthesis) would have silently unbound every emitted per-caixa Kustomization from its paired per-caixa sub-tree of the pleme-io k8s repository — the Flux v2 kustomize- controller would then either reconcile the whole GitRepository root (defaulting to ./ when the CR omits the leaf, pulling every unrelated cluster’s manifests through the wrong per-caixa Kustomization) or refuse to reconcile at all (parking the CR at BuildFailed naming the missing sub-tree far from the source caixa.lisp / the renderer’s format-string template). Canonical Flux v2 Kustomization.spec.path per-CR source-sub-tree leaf-scalar-key every caixa-flux-emitted kustomization.yaml document seeds under its top-level spec position to name the sub- tree of the paired FLUX_GITREPOSITORY_YAML_FILENAME GitRepository the Flux v2 kustomize-controller-side per-CR reconcile loop pulls the desired-state manifest set from at reconcile time. Drift on this leaf silently unbinds every per-caixa Kustomization from its paired per-caixa sub-tree of the pleme-io k8s repository — the kustomize-controller then either reconciles the whole GitRepository root (when the CR omits the leaf, the controller defaults to ./, pulling every unrelated cluster’s manifests through the wrong per-caixa Kustomization) or refuses to reconcile at all (when the leaf points at a path the GitRepository doesn’t carry, the CR sits perpetually at BuildFailed naming the missing sub-tree far from the source caixa.lisp / the renderer’s format-string template).

FLUX_KUSTOMIZATION_KEY_PRUNE

Canonical Flux v2 Kustomization.spec.prune per-CR garbage-collection- toggle leaf-scalar-key — re-export of the canonical caixa_core::FLUX_KUSTOMIZATION_KEY_PRUNE so the Flux v2 kustomize- controller-side per-CR garbage-collection-toggle leaf-scalar-key lives in exactly one place across every caixa renderer. Peer to the sibling FLUX_HELMRELEASE_KEY_CREATE_NAMESPACE (ba9ab8b) install-path-only per-CR namespace-seeder-toggle leaf-scalar-key on the co-resident per-caixa HelmRelease CR — extends the per-CR-toggle leaf-scalar-key discipline from the co-resident per-caixa HelmRelease CR spec surface onto the co-resident per-caixa Kustomization CR spec surface at the mirror-symmetric top-level spec.prune position. One production emit site (this crate’s cluster_bundle kustomization.yaml format- string template’s per-CR garbage-collection-toggle leaf under the top-level spec position, threading the same &'static str through a new {prune_key} named-arg interpolation) plus one test-fixture navigation site in mod tests (the per-CR [cluster_bundle_kustomization_prune_pins_lifted_true] pin’s .get(FLUX_KUSTOMIZATION_KEY_PRUNE) probe) now consult the same &'static str. Until this lift landed the axis carried the load- bearing prune bytes inline at the one production emit site; a future hypothetical Flux v3 rename (garbageCollect / sweep / pruneOrphaned / deleteOrphans) on the production-emit site without a coordinated edit on every per-renderer consumer the absorption roadmap surfaces (the M4 mesh.pleme.io/v1alpha1/Aplicacao CR materializer’s per-Aplicacao Kustomization synthesis) would have silently dropped the substrate’s chosen sweep-what-you-removed semantic from every emitted per-caixa Kustomization document — the kustomize-controller would then leave every per-caixa resource the source manifest set previously reconciled but no longer carries dangling in the cluster the substrate’s “the cluster’s per-caixa live state converges to the caixa’s tatara-lisp source-of-truth on every reconcile — resources the source no longer carries are swept by the kustomize-controller, not left dangling” CAIXA-SDLC.md §V author-to- live-convergence guarantee mandates, with no diagnostic naming the toggle-drift root cause far from the source caixa.lisp / the renderer’s format-string template. Same shape as the sibling FLUX_HELMRELEASE_KEY_CREATE_NAMESPACE (ba9ab8b) install-path-only per-CR namespace-seeder-toggle leaf-scalar-key + FLUX_HELMRELEASE_KEY_REMEDIATE_LAST_FAILURE (96581b7) upgrade- path-only per-CR remediation-toggle leaf-scalar-key + FLUX_HELMRELEASE_KEY_RETRIES (a12f9fc) leaf-scalar-key + peer FLUX_HELMRELEASE_KEY_REMEDIATION (6fe4e7e) sub-container-axis-key

FLUX_KUSTOMIZATION_KEY_TIMEOUT

Canonical Flux v2 Kustomization.spec.timeout per-CR reconcile wall-clock cap leaf-scalar-key — re-export of the canonical caixa_core::FLUX_KUSTOMIZATION_KEY_TIMEOUT so the Flux v2 kustomize-controller-side per-CR reconcile wall-clock cap leaf- scalar-key lives in exactly one place across every caixa renderer. Peer to the co-resident FLUX_KUSTOMIZATION_KEY_PATH (613d7ed) per-CR source-sub-tree leaf-scalar-key and FLUX_KUSTOMIZATION_KEY_PRUNE (8ec7917) per-CR garbage-collection-toggle leaf-scalar-key on the same top- level spec position of the emitted per-caixa Kustomization CR — extends the per-Kustomization-CR-spec leaf-scalar-key discipline from the co-resident source-sub-tree and garbage- collection-toggle axes onto the co-resident reconcile wall-clock cap axis at the mirror-symmetric top-level spec.timeout position. One production emit site (this crate’s cluster_bundle kustomization.yaml format-string template’s per-CR reconcile wall-clock cap leaf under the top-level spec position, threading the same &'static str through a new {timeout_key} named-arg interpolation) plus one test-fixture navigation site in mod tests (the per-CR [cluster_bundle_kustomization_timeout_pins_lifted_default] pin’s .get(FLUX_KUSTOMIZATION_KEY_TIMEOUT) probe) now consult the same &'static str. Until this lift landed the axis carried the load- bearing timeout bytes inline at the one production emit site; a future hypothetical Flux v3 rename (deadline / reconcileTimeout / maxDuration) on the production-emit site without a coordinated edit on every per-renderer consumer the absorption roadmap surfaces (the M4 mesh.pleme.io/v1alpha1/Aplicacao CR materializer’s per-Aplicacao Kustomization synthesis) would have silently stripped the substrate’s chosen reconcile-ceiling declaration from every emitted per-caixa Kustomization document — the Flux v2 kustomize-controller would then fall back to the upstream Flux v2 controller-side default cap, letting a persistently-failing per-caixa manifest apply consume kustomize- controller reconcile-loop cycles past the substrate’s chosen ceiling with no field naming the leaf-key-drift root cause far from the source caixa.lisp / the renderer’s format-string template. Pairs with the sibling DEFAULT_FLUX_KUSTOMIZATION_TIMEOUT scalar-value half of the same (leaf-key, scalar-value) per-path reconcile-ceiling- declaration pair. Same shape as the sibling FLUX_KUSTOMIZATION_KEY_PATH (613d7ed) / FLUX_KUSTOMIZATION_KEY_PRUNE (8ec7917) / FLUX_HELMRELEASE_KEY_REMEDIATE_LAST_FAILURE (96581b7) / FLUX_HELMRELEASE_KEY_CREATE_NAMESPACE (ba9ab8b) leaf-scalar- key re-exports on the peer per-Flux-v2-CR-spec-leaf-scalar-key surface. Canonical Flux v2 Kustomization.spec.timeout per-CR reconcile wall- clock cap leaf-scalar-key every caixa-flux-emitted kustomization.yaml document seeds under its top-level spec position to name the ceiling on how long the Flux v2 kustomize- controller-side per-CR reconcile loop is allowed to spend applying the paired FLUX_KUSTOMIZATION_KEY_PATH-scoped sub-tree of the paired FLUX_GITREPOSITORY_YAML_FILENAME GitRepository before it marks the Kustomization Ready: False and stops retrying — the substrate’s canonical “how long we let a per-caixa manifest-set reconcile run before Flux gives up” contract with the kustomize- controller’s per-CR reconcile loop. Drift on this leaf silently strips the substrate’s chosen reconcile-ceiling from every emitted per-caixa Kustomization document — the kustomize-controller then falls back to the upstream Flux v2 controller-side default cap (which the upstream project ships at a value tuned for the average upstream Flux-managed manifest set, not the substrate’s per-caixa idempotency-checkpoint cadence the sibling FLUX_HELMRELEASE_REMEDIATION_RETRIES_DEFAULT retry-ceiling and DEFAULT_FLUX_RECONCILE_INTERVAL reconcile-poll cadence are jointly tuned against), letting a persistently-failing per-caixa manifest apply consume kustomize-controller reconcile-loop cycles past the substrate’s chosen ceiling with no field naming the timeout-drift root cause.

FLUX_KUSTOMIZATION_PRUNE_DEFAULT

Canonical Flux v2 Kustomization.spec.prune per-CR garbage-collection- toggle scalar-value default the substrate seeds into every per-caixa kustomization.yaml document at the paired FLUX_KUSTOMIZATION_KEY_PRUNE leaf-scalar-key axis. Re-export of the canonical caixa_core::FLUX_KUSTOMIZATION_PRUNE_DEFAULT so the Flux v2 kustomize-controller-side per-CR garbage-collection-toggle scalar-value default lives in exactly one place across every caixa renderer — cluster_bundle’s kustomization.yaml format-string template’s per-CR garbage-collection-toggle scalar under the top-level spec position (the sole production-code site the prior inline prune: true scalar-value literal sat at, alongside the FLUX_KUSTOMIZATION_KEY_PRUNE-keyed leaf-scalar-key half of the same (leaf-key, scalar-value) pair) now threads the same bool through a {prune_default} named-arg interpolation, so a future substrate-side toggle migration (true → false on a cluster class where a human is expected to prune orphaned resources by hand once per-cluster policy grows an “operator-driven cleanup” mode; a per- caixa opt-out slot the ABSORPTION-ROADMAP.md M4 typed-slot trajectory adds once the substrate grows a :kustomization :prune author-side toggle) is a one-line edit on the canonical caixa_core::FLUX_KUSTOMIZATION_PRUNE_DEFAULT declaration, not a coordinated rewrite across the emit site + every future per-target renderer the substrate adds. Pairs with the sibling FLUX_KUSTOMIZATION_KEY_PRUNE re-export on the same per-CR spec.prune scalar-axis — the key half of the per-CR scalar-key / scalar-value pair lives at FLUX_KUSTOMIZATION_KEY_PRUNE, the value half’s substrate-side default seed lives here. Same shape as the sibling FLUX_HELMRELEASE_REMEDIATION_RETRIES_DEFAULT (30dcdae) scalar-value default re-export on the peer per-CR HelmRelease remediation retry-cap axis — that default names the per-path per-CR remediation retry ceiling, and this default names whether the per-CR reconcile loop sweeps orphaned resources at all. Both are substrate-side policy choices the operator inherits when the per- caixa ClusterBundleOpts doesn’t pin an override, and both must move together on any coordinated substrate-side Flux v2 per-CR tuning-cycle promotion. Until this lift landed the axis carried an inline true scalar-value literal at the sole production-code call site plus the sibling test-fixture navigation site ([cluster_bundle_kustomization_prune_pins_lifted_true] pin’s assert!(prune) predicate) — two occurrences of the same load- bearing Flux-v2-per-CR-garbage-collection-toggle-scalar-value convention, drift-prone by construction ahead of the third occurrence the M4 mesh.pleme.io/v1alpha1/Aplicacao CR materializer’s per-Aplicacao Kustomization synthesis will surface. Same shape as the sibling caixa_core::DEFAULT_NAMESPACE / caixa_core::DEFAULT_LIBRARY_NAME / caixa_core::DEFAULT_FLUX_SYSTEM_NAMESPACE / caixa_core::DEFAULT_FLUX_RECONCILE_INTERVAL / caixa_core::DEFAULT_FLUX_KUSTOMIZATION_TIMEOUT / caixa_core::DEFAULT_PUBLISH_TAG_PREFIX / caixa_core::FLUX_HELMRELEASE_REMEDIATION_RETRIES_DEFAULT re-exports on the peer canonical-substrate-default-load-bearing- scalar surface. Canonical Flux v2 Kustomization.spec.prune per-CR garbage-collection- toggle scalar-value default the substrate seeds into every per-caixa kustomization.yaml document at the paired FLUX_KUSTOMIZATION_KEY_PRUNE leaf-scalar-key axis. Pairs with the sibling FLUX_KUSTOMIZATION_KEY_PRUNE (8ec7917) leaf-scalar-key half of the same (leaf-key, scalar-value) per-CR garbage-collection- toggle declaration pair — the Flux v2 kustomize-controller’s per-CR reconcile loop reads the scalar under that exact leaf key, so drift on either axis is equally load-bearing (a rebrand on this canonical scalar-value default that failed to reach every renderer’s emit site would silently split the substrate’s chosen sweep-what-you-removed semantic between the operator-facing canonical default and every per-caixa Kustomization document’s per-CR garbage-collection-toggle, with no field naming the semantic-drift root cause far from the source caixa.lisp / the renderer’s format-string template).

FLUX_KUSTOMIZATION_YAML_FILENAME

Canonical Flux v2 per-cluster-bundle Kustomization document filename every cluster_bundle-rendered BundleFile carries at its per-file path axis — re-export of the lifted caixa_core::FLUX_KUSTOMIZATION_YAML_FILENAME so the fixed filename the cluster-side FluxCD kustomize-controller looks up when it opens the per-Servico bundle directory lives in exactly one place across every caixa renderer. Pairs with the sibling FLUX_GITREPOSITORY_YAML_FILENAME + FLUX_HELMRELEASE_YAML_FILENAME re-exports to close the per-bundle (gitrepository, helmrelease, kustomization) filename axis triple every rendered cluster bundle carries — the single source of truth all sixteen consumers reach for (one production cluster_bundle BundleFile assembly’s Kustomization document path axis plus fifteen test-side round-trip navigators that reach into the rendered bundle by the same filename to pin per-CR body-axis emission) now consult the same &'static str. Pin the equality + &'static static-data identity so any local re-introduction of a sibling pub const FLUX_KUSTOMIZATION_YAML_FILENAME: &str = "…" at this crate is a build-time test failure naming the offending drift, not a silent FluxCD kustomize-controller “no Kustomization document found under this bundle” reroute at cluster-side reconcile time far from the drift site. Peer to the sibling FLUX_HELMRELEASE_YAML_FILENAME (ba7b0b2) + FLUX_GITREPOSITORY_YAML_FILENAME (this commit) re-exports — closes the canonical-Flux-v2-bundle-filename lifted-const discipline on the third coordinate of the filename triple. Canonical Flux v2 per-cluster-bundle Kustomization document filename every caixa-flux-rendered cluster_bundle carries at the per-Servico bundle’s rendered file collection — the fixed filename the sibling gitrepository.yaml + helmrelease.yaml documents key against when the cluster-side FluxCD kustomize-controller reconciles the per-Servico apply cycle, and the exact filename every downstream consumer that reaches into the rendered bundle by document name looks up.

HELM_VALUES_KEY_ENABLED

Canonical pleme-computeunit library-chart values-block enable-toggle key — re-export of the lifted caixa_core::HELM_VALUES_KEY_ENABLED so the values-block enable-toggle every rendered HelmRelease / upstream values.yaml carries under its DEFAULT_LIBRARY_NAME wrap key lives in exactly one place across every caixa renderer. The single production-code call site consuming it is cluster_bundle’s helmrelease.yaml format-string template (formerly an inline enabled: true\n literal at caixa-flux/src/lib.rs:844); the peer test-side round-trip navigator (cluster_bundle_helmrelease_wraps_library_values_under_lifted_default_library_name) also consults the re-export so a rebrand of the library-chart’s per- values enable-toggle axis lands at one const and reaches every consumer by construction. A drifted local pub const HELM_VALUES_KEY_ENABLED: &str = "…" (or any sibling per- renderer variant that inlined a stale "enabled" / "enable" / "disabled" literal) would silently emit a HelmRelease whose per- cluster override lands under one key while [caixa_helm::build_values_yaml]’s default-off toggle inside the rendered values.yaml lands under another — Helm’s per-values merge treats them as sibling scalars, the enable-toggle the library chart’s own template consults never sees the flip, and the workload silently comes up with the library chart’s admission-time defaults instead of the per-cluster override the operator set. Same shape as the DEFAULT_LIBRARY_NAME / KUBE_KEY_SPEC / FLUX_HELMRELEASE_API_VERSION re-exports on the sibling canonical-Helm-load-bearing-string / canonical-K8s-CR-body-key / canonical-Flux-CRD-apiVersion axes. Canonical pleme-computeunit library-chart values-block enable-toggle key — the enabled: <bool> axis every lareira-<nome> chart’s values block carries under its DEFAULT_LIBRARY_NAME wrap key, and every caixa-flux-rendered HelmRelease spec.values.<library>.enabled per-cluster override targets. The single source of truth all four downstream consumers reach for:

KUBE_KEY_API_VERSION

Canonical K8s CR top-level apiVersion key. Re-export of the canonical caixa_core::KUBE_KEY_API_VERSION so the per-CR- group/version-axis discriminator key lives in exactly one place across every caixa renderer — caixa-flux’s cluster_bundle drift-detection pins that traverse the rendered gitrepository.yaml / helmrelease.yaml / kustomization.yaml documents to assert the top-level apiVersion axis + the kustomization.yaml’s nested spec.healthChecks[].apiVersion axis bind to the lifted FLUX_GITREPOSITORY_API_VERSION / FLUX_HELMRELEASE_API_VERSION / FLUX_KUSTOMIZATION_API_VERSION controller-triplet CRD-group/versions now consult the same &'static str as the sibling KUBE_KEY_SPEC / KUBE_KEY_METADATA / KUBE_KEY_KIND re-exports on the peer K8s-CR top-level axes. The prior inline "apiVersion" literals at every drift-detection cross-axis-pin call site in this crate would have let a typo on any one site (e.g. "ApiVersion", "api_version", "apiversion", "apiVer") silently miss the per-CR apiVersion-axis retrieval — the equality assertion would then compare None against Some("source.toolkit.fluxcd.io/v1") / Some("helm.toolkit.fluxcd.io/v2") / Some("kustomize.toolkit.fluxcd.io/v1") rather than the expected controller-triplet CRD-group/version, masking the sibling FLUX_*_API_VERSION re-export drift the pin was meant to catch under a .expect("… present") panic on the missing .and_then chain. The lift routes every K8s-CR top-level-apiVersion-axis retrieval through the same &'static str so drift between any two sites becomes a single-edit fix at the caixa-core const definition, extending the discipline the sibling KUBE_KEY_SPEC / KUBE_KEY_METADATA / KUBE_KEY_KIND re-exports establish onto the last of the four K8s-CR top-level axes (apiVersion, kind, metadata, spec) every rendered Flux v2 bundle document declares — completes the per-K8s-CR top-level (apiVersion, kind, metadata, spec) axis re-export quartet across this crate. Canonical K8s API key naming the resource’s API-version selector (e.g. cilium.io/v2, gateway.networking.k8s.io/v1, wasm.pleme.io/v1alpha1). Lifted to a const so a future API-server rename or a multi-version-skew migration is a one-line edit, not a search-and-replace across every per-target renderer.

KUBE_KEY_KIND

Canonical K8s CR top-level kind key. Re-export of the canonical caixa_core::KUBE_KEY_KIND so the per-CR-kind-axis discriminator key lives in exactly one place across every caixa renderer — caixa-flux’s cluster_bundle drift-detection pins that traverse the rendered gitrepository.yaml / helmrelease.yaml / kustomization.yaml documents to assert the top-level kind + nested sourceRef.kind / healthChecks[].kind axes bind to the lifted FLUX_KIND_GIT_REPOSITORY / FLUX_KIND_HELM_RELEASE / FLUX_KIND_KUSTOMIZATION discriminators now consult the same &'static str as the peer caixa-mesh renderer’s KUBE_KEY_KIND re-export (615a13d). The prior inline "kind" literals at every drift-detection cross-axis-pin call site in this crate would have let a typo on any one site (e.g. "Kind", "kinds", "knid") silently miss the per-CR kind-axis retrieval — the equality assertion would then compare None against Some("GitRepository") / Some("HelmRelease") / Some("Kustomization") rather than the expected discriminator, masking the sibling FLUX_KIND_* re-export drift the pin was meant to catch under a .expect("… present") panic on the missing .and_then chain. The lift routes every K8s-CR- top-level-kind-axis retrieval through the same &'static str so drift between any two sites becomes a single-edit fix at the caixa-core const definition. Same shape as the KUBE_KEY_SPEC + KUBE_KEY_METADATA re-exports on the sibling K8s-CR top-level-spec / top-level-metadata axes — completes the per-K8s-CR top-level (spec, metadata, kind) axis re-export triple every rendered Flux bundle document navigates. Canonical K8s API key naming the resource’s kind discriminator (e.g. CiliumNetworkPolicy, Gateway, HTTPRoute, ComputeUnit).

KUBE_KEY_METADATA

Canonical K8s CR top-level metadata key. Re-export of the canonical caixa_core::KUBE_KEY_METADATA so the per-kind metadata block key lives in exactly one place across every caixa renderer — caixa-flux’s programs_yaml_entry (the upstream ComputeUnit YAML’s metadata.namespace axis the rendered programs.yaml entry’s namespace field reads from) now consults the same &'static str as the peer caixa-mesh renderer’s KUBE_KEY_METADATA re-export. The prior inline "metadata" literals at the production-code + drift-detection call sites would have let a typo on one site (e.g. "Metadata", "meta-data", "medadata") silently miss the ComputeUnit’s metadata.namespace lookup and fall back to DEFAULT_NAMESPACE even when the ComputeUnit YAML pinned a distinct target namespace; the lift routes every K8s-CR-top-level- metadata-axis retrieval through the same &'static str so drift between any two sites becomes a single-edit fix at the caixa-core const definition. Same shape as the KUBE_KEY_SPEC re-export on the sibling K8s-CR top-level-spec-axis. Canonical K8s API key naming the resource’s metadata block.

KUBE_KEY_NAME

Canonical K8s CR metadata.name key. Re-export of the canonical caixa_core::KUBE_KEY_NAME so the per-CR name-axis key lives in exactly one place across every caixa renderer. Each of the three cluster_bundle format-string templates’ six name: YAML label positions — gitrepository.yaml top-level metadata.name, helmrelease.yaml top-level metadata.name + nested spec.chart.spec.sourceRef.name, kustomization.yaml top-level metadata.name + nested spec.sourceRef.name + nested spec.healthChecks[].name — thread this &'static str through named-arg interpolation instead of the prior six inline name: label literals.

KUBE_KEY_NAMESPACE

Canonical K8s CR metadata.namespace key. Re-export of the canonical caixa_core::KUBE_KEY_NAMESPACE so the per-CR namespace-axis key lives in exactly one place across every caixa renderer — caixa-flux’s programs_yaml_entry threads the ComputeUnit YAML’s metadata.namespace retrieval and the emitted programs:[] entry’s isomorphic namespace: field (the lareira-fleet-programs chart’s per-Servico namespace axis, populated verbatim from the ComputeUnit’s metadata.namespace per the docstring on programs_yaml_entry above) through this key, cluster_bundle’s rendered kustomization.yaml drift-detection pin traverses the emitted document’s metadata.namespace axis to assert it binds to the lifted DEFAULT_FLUX_SYSTEM_NAMESPACE (the bootstrap kustomize- controller’s watch window) through this same key, and each of the three cluster_bundle format-string templates’ five namespace: YAML label positions — gitrepository.yaml top-level metadata.namespace, helmrelease.yaml top-level metadata.namespace + nested spec.chart.spec.sourceRef.namespace, kustomization.yaml top-level metadata.namespace + nested spec.healthChecks[].namespace — thread this &'static str through named-arg interpolation instead of the prior five inline namespace: label literals.

KUBE_KEY_SPEC

Canonical K8s CR top-level spec key. Re-export of the canonical caixa_core::KUBE_KEY_SPEC so the per-kind body key lives in exactly one place across every caixa renderer — caixa-flux’s programs_yaml_entry (the upstream ComputeUnit YAML’s spec.* axis the rendered programs.yaml entry splices from), upsert_into_helmrelease_programs (the canonical spec.values.programs[] path the lareira-fleet-programs HelmRelease keys the per-Servico entry list under), and each of the three cluster_bundle format-string templates’ four spec: YAML label positions (gitrepository.yaml top-level + helmrelease.yaml top-level + helmrelease.yaml spec.chart.spec nested + kustomization.yaml top-level) all consult the same &'static str as the peer caixa-mesh / caixa-helm renderers’ KUBE_KEY_SPEC re-exports. The prior inline "spec" literals at the production-code call sites would have let a typo on one site (e.g. "Spec", "specs", "spec_") silently emit a programs.yaml entry that no lareira-fleet-programs schema validator recognizes; the Error::MissingField("spec") paths now thread the same &'static str through the diagnostic surface so the error message stays byte-identical to the key it failed to find. Same shape as the FLUX_HELMRELEASE_API_VERSION / DEFAULT_LIBRARY_NAME re-exports on the sibling canonical-Flux-load-bearing-string axes. Peer with the sibling KUBE_KEY_METADATA / KUBE_KEY_KIND / KUBE_KEY_API_VERSION re-exports on the other three canonical K8s-CR top-level block-scope label axes the cluster_bundle format-string templates thread through named-arg interpolation. Canonical K8s API key naming the resource’s per-kind body (sibling to KUBE_KEY_METADATA at the K8s CR top level). Every typed substrate renderer that materializes a CR populates spec.* from the source caixa.lisp — caixa-mesh’s cilium_network_policies per-(:de, :para) CiliumNetworkPolicy emitter (the policy’s endpointSelector / ingress block lives under spec), caixa-mesh’s gateway_routes Gateway + HTTPRoute emitter (the listeners / rules / parentRefs block lives under spec), caixa-flux’s programs_yaml_entry + upsert_into_helmrelease_programs (the fleet HelmRelease’s spec.values.programs[] axis), caixa-helm’s values.yaml builder (the upstream ComputeUnit YAML’s spec.* axis the rendered lareira-<nome> chart re-routes through the library alias). Spelled exactly as the K8s apiserver expects (the canonical OpenAPI v3 schema property name K8s machinery validates against on every CR registration), so the rendered YAML round-trips through every K8s schema parser without per-renderer string drift. Lifted on the trajectory the peer KUBE_KEY_API_VERSION / KUBE_KEY_KIND / KUBE_KEY_METADATA / KUBE_KEY_NAME / KUBE_KEY_NAMESPACE / KUBE_KEY_LABELS / KUBE_KEY_MATCH_LABELS canonical-K8s- API-key constants establish.

Functions

cluster_bundle

Cluster bundle: the FluxCD trio for a standalone caixa deploy.

flux_kustomization_source_subtree

Canonical substrate-side per-cluster / per-caixa Kustomization.spec.path source-sub-tree scalar composer — re-export of the canonical caixa_core::flux_kustomization_source_subtree so the ./clusters/<cluster>/services/<nome> GitRepository-relative directory-tree seed every emitted per-caixa kustomization.yaml document mounts under its lifted FLUX_KUSTOMIZATION_KEY_PATH leaf-scalar-key lives at one composer across every caixa renderer.

programs_yaml_entry

Render a single programs:[] array entry for the cluster’s lareira-fleet-programs HelmRelease values.

servico_spec_and_m2_overlay_entries

Local re-export of the canonical caixa_core::servico_spec_and_m2_overlay_entries — the composed per-Servico value-block splice helper this crate’s programs_yaml_entry and the peer [caixa_helm::build_values_yaml] both now route their two-step spec.* field-splice + M2 typed-slot overlay through. The single production-code call site consuming it is programs_yaml_entry’s inner splice loop (formerly two hand- written for-loops chained around string_keyed_entries + servico_m2_overlay); re-exported so the shared composition contract lives in exactly one place across both per-Servico renderers — a future author reading caixa_flux::programs_yaml_entry finds the composition helper immediately without an extra use caixa_core::… line, and a rebrand of the composition axis (e.g. a swap of the or_insert precedence rule) reaches both renderers through one canonical &'static function pointer. Same shape as the peer render-side helper re-exports on the sibling canonical-composed-primitive axes. Compose the canonical per-Servico value-block splice every per-Servico renderer applies to the target values / entry mapping — the two-step sequence [caixa_helm::build_values_yaml] and [caixa_flux::programs_yaml_entry] both re-derived inline before this lift:

upsert_into_helmrelease_programs

Insert/upsert an entry into a programs: array nested under the canonical fleet-manifest path: spec.values.programs[] in a HelmRelease document. The pleme-io convention puts the fleet’s program list inside a HelmRelease (consumed by lareira-fleet-programs), not at the top level. Same upsert semantics as upsert_into_programs_yaml — match by name, replace in place, otherwise append.

upsert_into_programs_yaml

Insert/upsert an entry into a programs: array of an existing values.yaml structure.

Type Aliases

BundleFile

One file of the cluster bundle — (path, contents) pair every cluster_bundle-rendered Flux v2 CR YAML document lands at.