Constant DEFAULT_FLUX_SYSTEM_NAMESPACE 

pub const DEFAULT_FLUX_SYSTEM_NAMESPACE: &str = "flux-system";

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:

• metadata.namespace — the namespace the Kustomization resource itself lives in (the FluxCD kustomize-controller watches this namespace by default; a drifted value sits outside the controller’s watch window and is never reconciled);
• spec.sourceRef.name — the GitRepository the bootstrap pipeline created at flux bootstrap time and the per-Servico Kustomization transitively threads its path: ./clusters/<cluster>/services/<name> reference through. The canonical FluxCD bootstrap convention names this GitRepository after the installation namespace (the flux-system namespace contains a GitRepository/flux-system pointing at the operator’s source-of-truth repo); both axes are the same conceptual “Flux installation namespace” load-bearing string and must move together on any future rebrand.

Until this lift landed both axes carried inline flux-system literals inside [cluster_bundle]’s kustomization.yaml format-string template (caixa-flux/src/lib.rs:477, 483) — two production-code consumers of the same load-bearing FluxCD-installation-namespace convention, drift-prone by construction. A future per-cluster Flux installation rebrand (the operator moving the bootstrap controllers to a different installation namespace, e.g. flux-pleme to match the per-tenant scoping convention once flux-system outlives its scoping intent; or any per-edition rebrand the FluxCD upgrade docs name) on one axis without a coordinated edit on the other would have silently emitted a Kustomization whose metadata.namespace sat outside the kustomize-controller watch window (controller-side: never reconciled, every HelmRelease / GitRepository it gates frozen at last-applied state) or whose spec.sourceRef.name pointed at a GitRepository that doesn’t exist in the rebranded namespace (apply-side: the reference dangles, the dependent chart never pulls). The apply-time symptom (the Servico’s HelmRelease is created but never reconciled, or never reaches its chart source) is invisible at admission and surfaces only as “the cluster says the resources are applied but nothing changed”, typically far from the rebrand commit’s source.

Lifting it to caixa-core’s render-constants block alongside the peer DEFAULT_NAMESPACE (a085b26, the workload-side tatara-system namespace every emitted resource lives in) makes the installation-namespace axis discipline structural: both kustomization axes consult the same &'static str, and every future renderer that reaches for the canonical Flux installation namespace (the future M4 mesh.pleme.io/v1alpha1/Aplicacao CR materializer’s per-Aplicacao Kustomization, the future per-edge Kustomization the operator emits for the CiliumClusterwideEnvoyConfig pipeline, the future caixa-otel collector-pipeline Kustomization) inherits the same value by construction with no opportunity for per-renderer drift. Same “the typed constant lives in one place” discipline the DEFAULT_NAMESPACE (a085b26) / DEFAULT_LIBRARY_NAME (41438dc) / crate::DEFAULT_SERVICO_PORT (1e22add) / crate::DEFAULT_PUBLISH_TAG_PREFIX (0a6a602) lifts apply on the peer canonical-load-bearing-string surface.

The value is a valid DNS-1123 label (the K8s apiserver-side floor every metadata.namespace rule enforces): lowercase ASCII alphanumeric with - separators, no leading / trailing hyphen, length within the DNS_1123_LABEL_MAX_LEN (63-byte) cap. A future rebrand on this lift cannot silently land a value the apiserver refuses, by construction: the [default_flux_system_namespace_is_a_valid_dns_1123_label] pin trips at caixa-core build time on any drift past the typed floor.