Module render 

Render-side helpers shared by every per-Servico renderer ([caixa-helm], [caixa-flux]) — the canonical place for “if the M2 typed slot is non-empty, emit its camelCase YAML fragment under the agreed key” patterns to live exactly once.

Until this module landed both renderers carried an inline ~20-line block per render entry-point that:

1. Checked caixa.limits.is_some() && !limits.is_empty().
2. Called serde_yaml::to_value(limits).unwrap_or(Value::Null) — silently swallowing every serialization error as a null-shaped fragment that would render as limits: null in the values block, indistinguishable from “the author omitted the slot” downstream.
3. Inserted under the camelCase key "limits" with or_insert semantics so explicit spec.* fields from the ComputeUnit YAML take precedence over the manifest-derived overlay.
4. Repeated the same shape for :behavior → "behavior" and :upgrade-from → "upgradeFrom".

That’s the duplication budget violated three ways: same emptiness check, same camelCase key, same precedence rule, written twice verbatim. THEORY.md §I.3.5 (“Generation first, composition second, hand-authoring last; the duplication budget is zero”) promotes that to a build-time concern: every recurring shape lives in a typed helper before its third occurrence — and PRIME DIRECTIVE work is exactly that lift.

servico_m2_overlay is that helper. Renderers iterate the map it returns and merge each (key, value) pair into their target with their own map type’s entry().or_insert() (so spec.* precedence is preserved by construction).

Structs

CiDecomposeFailure

Typed :ci-decompose-failure view: the canonical surface every per-Acao consumer raises when canteiro_types::decompose refuses the caixa’s declared :ci run (a duplicate node name, a dependency on an undeclared node, a dependency cycle — every failure mode the sibling canteiro_types::DecomposeError enumerates). Carries the offending caixa’s :nome alongside the borrowed canteiro_types::DecomposeError source so the diagnostic reads caixa "<nome>": :ci decompose failed: <source> — naming which caixa.lisp needs author attention, not just the axis the consumer rejected.

KindMismatch

Typed kind-mismatch view: the canonical surface every per-kind caixa-<target> renderer raises when it’s handed a Caixa whose :kind doesn’t match the kind that renderer is targeting. Carries the offending caixa’s :nome alongside the expected/actual kinds, so the diagnostic reads caixa "<nome>": expected :kind <expected>, got <actual> — naming which caixa needs author attention, not just which kind the renderer rejected.

MissingCiSlot

Typed :ci-slot-absence view: the canonical surface every per-Acao consumer raises when it’s handed a :kind Acao Caixa whose :ci slot is absent. Carries the offending caixa’s :nome so the diagnostic reads caixa "<nome>": :kind Acao requires a :ci slot — naming which caixa.lisp needs author attention, not just the axis the consumer rejected.

RenderedFile

One rendered artifact — a (path, contents) pair every per-target caixa-<target> renderer emits at every leaf of its output tree. Carries the sandboxed relative path the substrate writes the artifact under (relative to the renderer-chosen output root — the per-chart directory for caixa-helm’s lareira-<nome> chart tree, the per-caixa ./clusters/<cluster>/services/<nome>/ sub-tree for caixa-flux’s cluster_bundle Flux v2 CR trio) alongside the pre-serialized byte contents the substrate writes to it.

ServicoCountMismatch

Typed :servicos-count-mismatch view: the canonical surface every per-Servico caixa-<target> renderer raises when it’s handed a Caixa whose :servicos list doesn’t carry exactly one entry — the V0 contract every Servico-kind caixa satisfies (caixa-helm’s render_chart_for_servico, caixa-flux’s programs_yaml_entry, the future per-Servico OCI/wasm packager). Carries the offending caixa’s :nome alongside the actual count, so the diagnostic reads caixa "<nome>": :servicos must declare exactly one entry for V0 (got <count>) — naming which caixa.lisp needs author attention, not just the count the renderer rejected.

Enums

PathShapeViolation

Tagged reason a caixa-author-supplied path can fail the sandboxed-relative shape gate every callback / script path must pass for the layout checker’s root.join(p) to stay inside the caixa root.

RenderError

Errors the render helpers can raise.

Constants

CAIXA_KEY_DEPS

Canonical JSON/YAML top-level key for crate::Caixa’s runtime deps axis — the runtime-closure dependency list every build the caixa participates in reaches (peer of the dev-only :deps-dev list CAIXA_KEY_DEPS_DEV pins). The Rust field is single-word deps; the #[serde(rename_all = "camelCase")] attribute on crate::Caixa is a no-op on this axis (no _ to transform), so the emitted JSON key equals the source-side field name byte-for-byte and equals this constant’s value.

CAIXA_KEY_DEPS_DEV

Canonical camelCase JSON/YAML top-level key for crate::Caixa’s deps_dev axis — the dev-only dependency list that the M0 base package model already exposes (peer of the runtime :deps list, but excluded from published lacres and consumer builds). The Rust field is snake_case deps_dev; the #[serde(rename_all = "camelCase")] attribute on crate::Caixa maps it to the camelCase JSON key "depsDev" this constant pins.

CAIXA_KIND_LABEL_ACAO

Canonical human-readable label the crate::CaixaKind::Acao arm surfaces under crate::CaixaKind::as_str and (routed through it) std::fmt::Display. Sixth peer of CAIXA_KIND_LABEL_BIBLIOTECA / CAIXA_KIND_LABEL_BINARIO / CAIXA_KIND_LABEL_SERVICO / CAIXA_KIND_LABEL_SUPERVISOR / CAIXA_KIND_LABEL_APLICACAO on the same closed crate::CaixaKind enum surface; see CAIXA_KIND_LABEL_BIBLIOTECA for the shared lift rationale.

CAIXA_KIND_LABEL_APLICACAO

Canonical human-readable label the M3 crate::CaixaKind::Aplicacao arm surfaces under crate::CaixaKind::as_str and (routed through it) std::fmt::Display. Peer of CAIXA_KIND_LABEL_BIBLIOTECA / CAIXA_KIND_LABEL_BINARIO / CAIXA_KIND_LABEL_SERVICO / CAIXA_KIND_LABEL_SUPERVISOR on the same closed crate::CaixaKind enum surface; see CAIXA_KIND_LABEL_BIBLIOTECA for the shared lift rationale.

CAIXA_KIND_LABEL_BIBLIOTECA

Canonical human-readable label the M0 crate::CaixaKind::Biblioteca arm surfaces under crate::CaixaKind::as_str and (routed through it) std::fmt::Display — the byte-string every future diagnostic / graph / audit consumer that formats a :kind variant as user-facing text lands on (the future wasm-operator’s per-caixa startup log line naming the loaded caixa’s typed shape, the future feira app graph per-member kind column, the future M4 wasm.pleme.io/v1alpha1/ComputeUnit / mesh.pleme.io/v1alpha1/* CR materializer’s admission-webhook rejection body naming which typed kind the offending manifest carries). Peer of the sibling four CAIXA_KIND_LABEL_BINARIO / CAIXA_KIND_LABEL_SERVICO / CAIXA_KIND_LABEL_SUPERVISOR / CAIXA_KIND_LABEL_APLICACAO consts on the same closed crate::CaixaKind enum surface — together the pentad names every author-reachable arm of the substrate’s most fundamental typed axis (what a caixa produces), mirroring the closed-enum-scalar-value trajectory the sibling OTP-shaped SUPERVISOR_ESTRATEGIA_ONE_FOR_ONE etc. (09ffb2d) and SUPERVISOR_CHILD_RESTART_PERMANENT etc. (ccdf955) and the M3 M3_PLACEMENT_ESTRATEGIA_SINGLE_NODE etc. (3f0e21c) established on the sibling closed-set typed-enum discriminator axes.

CAIXA_KIND_LABEL_BINARIO

Canonical human-readable label the M0 crate::CaixaKind::Binario arm surfaces under crate::CaixaKind::as_str and (routed through it) std::fmt::Display. Peer of CAIXA_KIND_LABEL_BIBLIOTECA / CAIXA_KIND_LABEL_SERVICO / CAIXA_KIND_LABEL_SUPERVISOR / CAIXA_KIND_LABEL_APLICACAO on the same closed crate::CaixaKind enum surface; see CAIXA_KIND_LABEL_BIBLIOTECA for the shared lift rationale.

CAIXA_KIND_LABEL_SERVICO

Canonical human-readable label the M0 crate::CaixaKind::Servico arm surfaces under crate::CaixaKind::as_str and (routed through it) std::fmt::Display. Peer of CAIXA_KIND_LABEL_BIBLIOTECA / CAIXA_KIND_LABEL_BINARIO / CAIXA_KIND_LABEL_SUPERVISOR / CAIXA_KIND_LABEL_APLICACAO on the same closed crate::CaixaKind enum surface; see CAIXA_KIND_LABEL_BIBLIOTECA for the shared lift rationale.

CAIXA_KIND_LABEL_SUPERVISOR

Canonical human-readable label the M2 crate::CaixaKind::Supervisor arm surfaces under crate::CaixaKind::as_str and (routed through it) std::fmt::Display. Peer of CAIXA_KIND_LABEL_BIBLIOTECA / CAIXA_KIND_LABEL_BINARIO / CAIXA_KIND_LABEL_SERVICO / CAIXA_KIND_LABEL_APLICACAO on the same closed crate::CaixaKind enum surface; see CAIXA_KIND_LABEL_BIBLIOTECA for the shared lift rationale.

CAIXA_KIND_WIRE_ACAO

Canonical PascalCase wire byte-string the crate::CaixaKind::Acao arm serializes as under the un-renamed #[derive(Serialize)] on crate::CaixaKind. Sixth peer of CAIXA_KIND_WIRE_BIBLIOTECA / CAIXA_KIND_WIRE_BINARIO / CAIXA_KIND_WIRE_SERVICO / CAIXA_KIND_WIRE_SUPERVISOR / CAIXA_KIND_WIRE_APLICACAO on the same closed crate::CaixaKind enum surface; see the sibling CAIXA_KIND_WIRE_BIBLIOTECA docstring for the shared lift rationale.

CAIXA_KIND_WIRE_APLICACAO

Canonical PascalCase wire byte-string the crate::CaixaKind::Aplicacao arm serializes as under the un-renamed #[derive(Serialize)] on crate::CaixaKind. Peer of CAIXA_KIND_WIRE_BIBLIOTECA on the same closed crate::CaixaKind enum surface; see the sibling CAIXA_KIND_WIRE_BIBLIOTECA docstring for the shared lift rationale.

CAIXA_KIND_WIRE_BIBLIOTECA

Canonical PascalCase wire byte-string the crate::CaixaKind::Biblioteca arm serializes as under the un-renamed #[derive(Serialize)] on crate::CaixaKind — the exact byte-shape every wire surface that carries a Caixa’s :kind outside the caixa-core boundary consumes (the [caixa_crd::caixa_cr::CaixaSpec] kind: field the K8s Caixa CR persists between apply and reconcile passes, the tatara-lisp author-surface :kind Biblioteca symbol the sexp parser binds into the typed crate::CaixaKind enum, the future M4 mesh.pleme.io/v1alpha1/Caixa CR materializer’s per-CR admission- webhook wire binding).

CAIXA_KIND_WIRE_BINARIO

Canonical PascalCase wire byte-string the crate::CaixaKind::Binario arm serializes as under the un-renamed #[derive(Serialize)] on crate::CaixaKind. Peer of CAIXA_KIND_WIRE_BIBLIOTECA on the same closed crate::CaixaKind enum surface; see the sibling CAIXA_KIND_WIRE_BIBLIOTECA docstring for the shared lift rationale.

CAIXA_KIND_WIRE_SERVICO

Canonical PascalCase wire byte-string the crate::CaixaKind::Servico arm serializes as under the un-renamed #[derive(Serialize)] on crate::CaixaKind. Peer of CAIXA_KIND_WIRE_BIBLIOTECA on the same closed crate::CaixaKind enum surface; see the sibling CAIXA_KIND_WIRE_BIBLIOTECA docstring for the shared lift rationale.

CAIXA_KIND_WIRE_SUPERVISOR

Canonical PascalCase wire byte-string the crate::CaixaKind::Supervisor arm serializes as under the un-renamed #[derive(Serialize)] on crate::CaixaKind. Peer of CAIXA_KIND_WIRE_BIBLIOTECA on the same closed crate::CaixaKind enum surface; see the sibling CAIXA_KIND_WIRE_BIBLIOTECA docstring for the shared lift rationale.

CARGO_FEATURE_NAME_MAX_LEN

Practical cap on a :caracteristicas (Cargo-feature-name-shaped) entry, in bytes. Cargo itself enforces no length cap on feature names — its restricted_names::validate_feature_name accepts any length — but every realistic feature in the Cargo ecosystem is well under this bound (derive 6, serde_json 10, the __private_… doubled-underscore convention rarely exceeds 32). 64 bytes is the substrate’s catch-the-paste-from-binary cap on the peer trajectory is_dns_1123_label (63), is_wit_world_ref (128), is_nats_subject (256), is_wasi_keyvalue_slot (512), is_git_ref_name (255), is_git_oid (40/64), is_git_repo_url (2048) carry: an axis-appropriate ceiling above every legitimate authoring shape, tight enough to surface the “paste-from-binary” / “multi-line blob landed in a single-token slot” footgun at validate time.

CHART_DESCRIPTION_MAX_LEN

Maximum byte length of a chart-description-shaped string. The 512-byte cap is the axis-appropriate ceiling for the free-form prose summary the :descricao axis carries: every realistic chart description in the wild ("Canonical Rust→wasm32-wasip2 caixa Servico.", "Checkout flow.", "AWS provider caixa for tatara-lisp") sits well under 256 bytes, and the 512-byte cap surfaces the “paste-from-doc multi-paragraph blob landed in the :descricao slot” footgun at validate time. Peer with WASI_KV_SLOT_MAX_LEN (512) on the sibling longer-than- identifier axis; tighter than GIT_REPO_URL_MAX_LEN (2048) which carries a different axis-class ceiling, and looser than SPDX_EXPRESSION_MAX_LEN (256) which is the canonical short-identifier-class axis.

CHART_KEYWORD_MAX_LEN

Maximum byte length of a chart-keyword-shaped string. The 20-byte cap matches Cargo’s [package] keywords rule (https://doc.rust-lang.org/cargo/reference/manifest.html#the-keywords-field: “Each keyword should be ASCII text, start with a letter, and only contain letters, numbers, _ or -. Keywords are case-insensitive and limited to a maximum length of 20 characters.”) — the same parser crates.io routes its keywords: array entries through at publish time. Tighter than every peer length cap on the typed Caixa surface (CHART_MAINTAINER_NAME_MAX_LEN 128 on the sibling chart-metadata Vec<String> axis, CARGO_FEATURE_NAME_MAX_LEN 64 on the sibling :caracteristicas per-entry axis, CHART_DESCRIPTION_MAX_LEN 512 on the free-form-prose axis); the search-tag class is the tightest short-identifier shape on the typed surface — every realistic :etiquetas entry in the wild ("iac", "aws", "pangea", "hello-world", "tatara-lisp", "caixa-servico", "infrastructure", "pangea-native") sits well under 20 bytes, and the 20-byte cap surfaces the “paste-from-doc multi-tag blob landed in a single :etiquetas entry” footgun ("web-service web app", "mesh,http,grpc") at validate time.

CHART_MAINTAINER_NAME_MAX_LEN

Maximum byte length of a chart-maintainer-name-shaped string. The 128-byte cap is the axis-appropriate ceiling for the per-entry identifier the :autores Vec axis carries: every realistic Helm chart maintainer name in the wild ("pleme-io", "Pleme Contributors", "alice <alice@example.com>", "François Dupont") sits well under 64 bytes, and the 128-byte cap surfaces the “paste-from-doc multi-paragraph blob landed in a single :autores entry” footgun at validate time. Tighter than CHART_DESCRIPTION_MAX_LEN (512) on the sibling free-form-prose axis where multi-sentence summaries are the canonical shape; peer with WIT_IDENT_MAX_LEN (128) on the sibling short-identifier-class axis.

CILIUM_API_VERSION

Canonical Cilium CRD apiVersion every caixa-mesh-emitted CiliumNetworkPolicy document declares. The Cilium control plane’s upstream-shipped CRD bundle registers CiliumNetworkPolicy, CiliumClusterwideNetworkPolicy, CiliumEndpoint, CiliumIdentity, CiliumNode, CiliumLocalRedirectPolicy, and the rest of the per-conformance Cilium CRD set at this exact group/version (cilium.io/v2); drift to a stale v2alpha1 (the historical pre-stable Cilium-CRD-group/version label upstream Cilium-CRD docs reference for in-flight per-CRD-version migration) silently routes the rendered CiliumNetworkPolicy outside the cluster’s Cilium-operator-side CRD-version registration and breaks at apply time with a non-self-locating “no kind ‘CiliumNetworkPolicy’ is registered for version ‘cilium.io/v2alpha1’” error far from the source caixa.lisp / the renderer’s kube_resource_skeleton call site.

CILIUM_AUTH_MODE_DISABLED

Canonical Cilium CiliumNetworkPolicy MutualAuthenticationMode OpenAPI schema enum’s disabled per-ingress[].authentication.mode mTLS-skipped scalar-value every cilium_network_policies-emitted CNP document declares under its per-rule mutual-auth-mode-discriminator leaf axis when the typed :politicas :mtls-required tristate is the explicit Some(false) opt-out arm (an author who named the axis and asked for the mTLS handshake to be skipped on this Aplicacao’s edges — e.g. a debug or legacy-bridge Aplicacao that needs to talk to non-mesh peers, distinct from the None slot-absent arm the renderer maps to omit-the-block-entirely). Peer to the sibling CILIUM_AUTH_MODE_REQUIRED mTLS-mandatory scalar-value the Some(true) affirmative arm emits under the same tristate branch — the Cilium CNP MutualAuthenticationMode OpenAPI schema enum admits the two arms as a matched author-reachable pair.

CILIUM_AUTH_MODE_REQUIRED

Canonical Cilium CiliumNetworkPolicy MutualAuthenticationMode OpenAPI schema enum’s required per-ingress[].authentication.mode mTLS-mandatory scalar-value every cilium_network_policies-emitted CNP document declares under its per-rule mutual-auth-mode-discriminator leaf axis when the typed :politicas :mtls-required tristate is Some(true). Pairs with the sibling CILIUM_KEY_MODE (4289dfb) per-authn-block mode-discriminator leaf-axis key the value nests directly under, and the sibling CILIUM_AUTH_MODE_DISABLED scalar-value the Some(false) opt-out arm of the same tristate emits — the Cilium CNP MutualAuthenticationMode OpenAPI schema enum admits the closed set {"required", "disabled", "test-always- fail"} verbatim (the test-always-fail arm is an infrastructure-side debugging surface, not an author-reachable slot), so drift on the mTLS- mandatory scalar-value is exactly as load-bearing as drift on the sibling per-authn-block mode-discriminator leaf axis it nests under (a "Required" / "REQUIRED" / "mandatory" / "mtls-required" typo at either the production-code call site or a downstream probe lands outside the Cilium CNP MutualAuthenticationMode OpenAPI schema enum’s admitted set, surfacing apply-side as a Cilium-agent per-rule mutual-auth-block schema- validator drop far from the source caixa.lisp / the renderer’s single_field_overlay(mtls_required, CILIUM_KEY_MODE, …) call site — the rendered per-(:de, :para) CiliumNetworkPolicy object never enforces per-edge SPIFFE-identity-bound mutual-auth at the Cilium data-plane’s per- rule handshake gate and every intra-mesh :contratos flow the CNP was authored to protect with per-edge mTLS silently bypasses the handshake at the Cilium data-plane’s default-authentication mode with no field naming the mTLS-mandatory-scalar-value-drift root cause).

CILIUM_KEY_AUTHENTICATION

Canonical Cilium CiliumNetworkPolicy per-ingress-rule mutual-auth policy body-axis key every cilium_network_policies-emitted CNP document mounts its per-rule mTLS enforcement block under (spec.ingress[].authentication). Sibling to CILIUM_KEY_FROM_ENDPOINTS (ecfa557) + CILIUM_KEY_TO_PORTS (c8d9cbf) at the per-ingress-rule body level — the Cilium CNP schema places the per-rule mutual-auth mode ({mode: required | disabled}) at the ingress-rule axis alongside the identity-source (fromEndpoints) and port-set (toPorts) axes, so drift on the authentication axis is exactly as load-bearing as drift on the sibling per-ingress-rule-body axes it pairs with (the Cilium-operator-side CRD schema validator drops any per-ingress[] entry whose mutual-auth axis carries an unrecognized key — a "auth" / "mutualAuth" / "mtls" typo silently emits a CNP whose per-(:de, :para) per-rule mTLS block the Cilium operator’s per-CNP mutual-auth SPIFFE-handshake pipeline no-ops entirely: the ingress rule falls back to the cluster-default authentication mode (typically "disabled" — no mutual-auth enforcement), and every intra-mesh :contratos flow the CNP was authored to protect with per-edge mTLS silently bypasses the SPIFFE-identity-bound mutual-auth handshake with no field naming the mutual-auth-axis-drift root cause).

CILIUM_KEY_ENDPOINT_SELECTOR

Canonical Cilium CiliumNetworkPolicy destination-identity selector- axis key every cilium_network_policies-emitted CNP document mounts its L3-target LabelSelector under (spec.endpointSelector). Pairs with the sibling CILIUM_KEY_TO_PORTS (c8d9cbf) — the Cilium CNP schema pins the destination workload through the endpointSelector axis and the admitted L4 port set through the toPorts axis, so drift on the destination-identity axis is exactly as load-bearing as drift on the port-set-container axis it accompanies (the Cilium- operator-side CRD schema validator drops any spec block whose destination-identity axis carries an unrecognized key — an "endpointselector" / "endpointSelectors" / "endpoints" typo silently emits a CNP whose L3-target selector the Cilium operator’s per-CNP identity-resolution pass no-ops entirely: the policy binds against no destination pods and every intra-mesh :contratos flow the CNP was authored to allow drops at the eBPF data plane’s default-deny gate with no field naming the destination-identity- axis-drift root cause).

CILIUM_KEY_FROM_ENDPOINTS

Canonical Cilium CiliumNetworkPolicy per-ingress-rule identity- source selector-list axis key every cilium_network_policies-emitted CNP document mounts its permitted-source LabelSelector list under (spec.ingress[].fromEndpoints[]). Pairs with the sibling CILIUM_KEY_ENDPOINT_SELECTOR (7088789) — the Cilium CNP schema pins the destination workload identity through the per-CNP-body endpointSelector axis and the admitted source workload identities through the per-ingress-rule fromEndpoints[] axis, so drift on the identity-source axis is exactly as load-bearing as drift on the destination-identity axis it accompanies (the Cilium-operator-side CRD schema validator drops any per-ingress-rule block whose identity-source axis carries an unrecognized key — a "fromendpoints" / "fromEndPoint" / "sourceEndpoints" typo silently emits a CNP whose per-(:de, :para) ingress-rule identity- source list the Cilium operator’s per-CNP identity-resolution pass no-ops entirely: the ingress rule admits no source pods and every intra-mesh :contratos flow the CNP was authored to allow drops at the eBPF data plane’s default-deny gate with no field naming the identity-source-axis-drift root cause).

CILIUM_KEY_HTTP

Canonical Cilium CiliumNetworkPolicy per-ingress[].toPorts[].rules L7-HTTP-rule-list-discriminator container-axis key every cilium_network_policies-emitted CNP document mounts its per-toPorts[] entry L7 HTTP-rule list under (spec.ingress[].toPorts[].rules.http). Nests exactly one level beneath the sibling KUBE_KEY_RULES (a205eb3) per-toPorts[] rule-list-container axis it sits inside: the Cilium CNP schema places the L7-protocol-selection discriminator (http / future kafka / future dns) as the single per-protocol keyed axis of the per-toPorts[] rules block, so drift on the L7-HTTP-rule-list- discriminator axis is exactly as load-bearing as drift on the sibling KUBE_KEY_RULES per-toPorts[] rule-list-container axis-key it nests inside (the Cilium-operator-side CNP schema validator drops any per- toPorts[] entry whose per-protocol L7-rule-list-discriminator key it recognizes as unknown — a "HTTP" / "Http" / "http/1.1" / "httpRules" typo at either the emit-side rules.insert(…) call site or a downstream renderer’s per-toPorts[] L7-rule-list upsert silently emits a per-toPorts[] entry whose L7-HTTP-rule-list-discriminator key the Cilium CRD schema validator rejects as unknown; the per-toPorts[] entry falls back to L4-only enforcement — no L7 URL-path predicate is applied — silently admitting every HTTP-method / URL-path combination the ingress rule was authored to filter to the exact path prefix set the typed :contratos graph names at the L7 introspection axis, and the emit-side/probe-side split silently masks the per-toPorts[] L7- rule-list pin (.get("http") returns None under both the drifted- key emitter and the drifted-key probe — every downstream .and_then(|h| h.as_sequence()) chain short-circuits vacuously because the outer L7-HTTP-rule-list-lookup is itself None).

CILIUM_KEY_INGRESS

Canonical Cilium CiliumNetworkPolicy traffic-direction container- axis key every cilium_network_policies-emitted CNP document mounts its inbound-per-(:de, :para) ingress-rule list under (spec.ingress[]). Pairs with the sibling CILIUM_KEY_ENDPOINT_SELECTOR (7088789) + CILIUM_KEY_TO_PORTS (c8d9cbf) — the per-CNP spec schema mounts the destination workload identity under endpointSelector, the permitted inbound-per-(:de, :para) ingress-rule list under ingress[], and each per-ingress-rule port-set under ingress[].toPorts[], so drift on the traffic-direction axis is exactly as load-bearing as drift on the destination-identity / port-set-container axes it accompanies (the Cilium-operator-side CRD schema validator drops any spec block whose traffic-direction axis carries an unrecognized key — an "Ingress" / "ingressRules" / "inbound" typo silently emits a CNP whose ingress-rule list the Cilium operator’s per-CNP L4/L7-dispatch pass no-ops entirely: the policy binds against the destination workload but admits no ingress traffic, and every intra-mesh :contratos flow the CNP was authored to allow drops at the eBPF data plane’s default-deny gate with no field naming the traffic-direction-axis-drift root cause).

CILIUM_KEY_MODE

Canonical Cilium CiliumNetworkPolicy per-ingress[].authentication block mTLS-mode-discriminator leaf-scalar-axis key every cilium_network_policies-emitted CNP document mounts its per-rule mutual-auth mode leaf under (spec.ingress[].authentication.mode). Nests exactly one level beneath the sibling CILIUM_KEY_AUTHENTICATION (db31108) per-ingress-rule mutual-auth body-axis it sits inside: the Cilium CNP schema places the mTLS enforcement mode discriminator ("required" / "disabled") as the single leaf-scalar axis of the per-rule authentication block, so drift on the mode-discriminator leaf axis is exactly as load-bearing as drift on the sibling per-ingress-rule mutual-auth body-axis key (authentication) it nests inside (the Cilium-operator-side CNP schema validator drops any per-ingress[] entry whose per-rule mutual-auth block carries an unrecognized leaf axis — a "policy" / "authMode" / "handshakeMode" typo at either the emit-side single- field-overlay call site or a downstream renderer’s per-rule authn leaf upsert silently emits a per-ingress[] mutual-auth block whose mode-discriminator leaf the Cilium CRD schema validator rejects as unknown; the ingress rule falls back to the cluster-default authentication mode (typically "disabled" — no mutual-auth enforcement) silently bypassing the SPIFFE-identity-bound mTLS handshake every intra-mesh :contratos flow the CNP was authored to protect with per-edge mTLS, and the emit-side/probe-side split silently masks the per-rule mutual-auth pin (.get("mode") returns None under both the drifted-key emitter and the drifted-key probe — every downstream .and_then(|v| v.as_str()) chain short-circuits vacuously because the outer mode-leaf-lookup is itself None).

CILIUM_KEY_PATH

Canonical Cilium CiliumNetworkPolicy per-ingress[].toPorts[].rules.http[] per-HTTP-rule URL-path-predicate leaf-scalar-axis key every cilium_network_policies-emitted CNP document mounts its per-HTTP-rule URL-path-prefix predicate scalar under (spec.ingress[].toPorts[].rules.http[].path). Nests exactly one level beneath the sibling CILIUM_KEY_HTTP (ccd81e8) per-toPorts[] L7-HTTP-rule-list-discriminator container-axis it sits inside: the Cilium CNP schema places the per-HTTP-rule URL-path predicate scalar (the exact URL-path regex the Cilium L7 dispatch pass matches the observed HTTP request line’s path segment against) as the single load-bearing leaf- scalar axis of the per-rules.http[] entry — so drift on the per-HTTP- rule URL-path-predicate leaf axis is exactly as load-bearing as drift on the sibling CILIUM_KEY_HTTP per-toPorts[] L7-HTTP-rule-list- discriminator container-axis key it nests inside (the Cilium-operator- side CNP schema validator drops any per-rules.http[] entry whose per- HTTP-rule URL-path-predicate leaf key it recognizes as unknown — a "Path" / "pathPrefix" / "regex" / "urlPath" / "pathMatch" typo at either the emit-side http_rule.insert(…) call site or a downstream renderer’s per-rules.http[] URL-path leaf upsert silently emits a per- rules.http[] entry whose URL-path-predicate leaf-axis key the Cilium CRD schema validator rejects as unknown; the per-rules.http[] entry falls back to a match-any-URL-path predicate — the per-toPorts[] L7 rule admits every URL path on the destination port silently, bypassing the URL-path-prefix predicate the typed :contratos HTTP-shaped edge’s :endpoint slot names at the L7 introspection axis, and the emit- side/probe-side split silently masks the per-rules.http[] URL-path pin (.get("path") returns None under both the drifted-key emitter and the drifted-key probe — every downstream .and_then(|v| v.as_str()) chain short-circuits vacuously because the outer per-HTTP-rule URL- path-lookup is itself None).

CILIUM_KEY_PORTS

Canonical Cilium CiliumNetworkPolicy per-toPorts[]-entry L4 port-tuple-list-container axis key every cilium_network_policies- emitted CNP document mounts its per-port-set [{port, protocol}] list under (spec.ingress[].toPorts[].ports[]). Nests inside the sibling CILIUM_KEY_TO_PORTS (c8d9cbf) — the Cilium CNP schema pins the per-ingress-rule port-set-container axis through the toPorts[] list and the per-port-set L4 port-tuple list through the ports[] axis beneath each entry, so drift on the L4 port-tuple-list-container axis is exactly as load-bearing as drift on the port-set container axis it nests inside (the Cilium-operator-side CRD schema validator drops any per-toPorts[] entry whose port-tuple-list-container axis carries an unrecognized key — a "port" / "portList" / "L4Ports" typo silently emits a CNP whose per-(:de, :para) per-port-set L4 port-tuple list the Cilium operator’s per-CNP L4-allow eBPF-program generation pass no-ops entirely: the port-set admits no (port, protocol) tuple and every intra-mesh :contratos flow the CNP was authored to allow drops at the eBPF data plane’s default-deny gate with no field naming the L4-port-tuple-list-container-axis-drift root cause).

CILIUM_KEY_TO_PORTS

Canonical Cilium CiliumNetworkPolicy L4/L7 per-ingress-rule port-set container-axis key every cilium_network_policies-emitted CNP document mounts its per-ingress-rule [{ports: […], rules: {…}}] list under (spec.ingress[].toPorts[]). Pairs with the sibling KUBE_KEY_RULES (a205eb3) — the Cilium L7-dispatch schema nests spec.ingress[].toPorts[].rules.http[] under the shared (toPorts, rules) container-key pair, so drift on the toPorts axis is exactly as load-bearing as drift on the rules axis it wraps (the Cilium-operator-side CRD schema validator drops any spec.ingress[] entry whose port-set container carries an unrecognized key — a "toports" / "toPort" / "targetPorts" typo silently emits an ingress rule whose per-port set the Cilium operator’s per-CNP L4/L7 dispatch pass no-ops entirely: every intra-mesh :contratos flow the CNP was authored to allow now drops at the eBPF data plane’s default-deny gate with no field naming the port-set-container-drift root cause).

CILIUM_KIND_NETWORK_POLICY

Canonical Cilium CRD kind discriminator the rendered CiliumNetworkPolicy document declares at its top-level KUBE_KEY_KIND axis. Pairs with the sibling CILIUM_API_VERSION (279d611) — the K8s apiserver-side CRD resolution contract is the (apiVersion, kind) tuple keyed against the registered CustomResourceDefinition, so drift on the kind axis is exactly as load-bearing as drift on the apiVersion axis it accompanies (the apiserver’s RESTMapper consults both together; a ("cilium.io/v2", "CilumNetworkPolicy") typo at the production-code call site lands outside the registered Cilium-operator-side CiliumNetworkPolicy CRD’s RESTKind lookup, surfacing apply-side as a non-self-locating “no kind ‘CilumNetworkPolicy’ is registered for version ‘cilium.io/v2’” error far from the source caixa.lisp / the renderer’s kube_resource_skeleton call site).

CIRCUIT_BREAKER_KEY_MAX_FAILURES

Canonical camelCase JSON/YAML sub-key for the crate::aplicacao::CircuitBreaker struct’s max_failures consecutive-failure-count axis — the maxFailures: field the M3 Aplicacao’s #[serde(rename_all = "camelCase")] derive on crate::aplicacao::CircuitBreaker emits inside the POLITICAS_KEY_CIRCUIT_BREAKER sub-block, and the exact camelCase scalar (Rust field max_failures → serde-emitted maxFailures, the load-bearing non-trivial camelCase transform on this CircuitBreaker axis alongside the no-op CIRCUIT_BREAKER_KEY_WINDOW sibling) every downstream breaker- tuning consumer must probe on (the future M4 per-edge :politicas overlay projection onto the mesh’s per-backend consecutive-failure-counter tripping threshold per MESH-COMPOSITION.md §III.3 breaker semantics, the future mesh.pleme.io/v1alpha1/Aplicacao CR materializer’s admission-time breaker cross-check against crate::POLICY_BREAKER_MAX_FAILURES_MAX, the future feira lint per-:politicas :circuit-breaker bound-check gate).

CIRCUIT_BREAKER_KEY_WINDOW

Canonical camelCase JSON/YAML sub-key for the crate::aplicacao::CircuitBreaker struct’s window failure-counter reset-window axis — the window: field the M3 Aplicacao’s #[serde(rename_all = "camelCase")] derive on crate::aplicacao::CircuitBreaker emits inside the POLITICAS_KEY_CIRCUIT_BREAKER sub-block. The Rust field is lowercase window; #[serde(rename_all = "camelCase")] is a no-op on this axis and the emitted key equals the source-side field name byte-for-byte. Peer of CIRCUIT_BREAKER_KEY_MAX_FAILURES on the same crate::aplicacao::CircuitBreaker serialized-key axis; see CIRCUIT_BREAKER_KEY_MAX_FAILURES for the full lift rationale.

CLUSTER_BUNDLE_LAREIRA_ENABLED_DEFAULT

Canonical substrate-side default for the HelmRelease.spec.values.<library>.enabled scalar-value toggle every caixa_flux::cluster_bundle-emitted helmrelease.yaml document seeds inside its per-caixa values overlay to force-on the paired DEFAULT_LIBRARY_NAME child chart at the per-cluster HelmRelease-side apply step. Pairs with the sibling HELM_VALUES_KEY_ENABLED leaf-scalar-key half of the (leaf-key, scalar-value) per-values-overlay child-chart enablement-toggle declaration pair — the key half names the canonical values.<library>.enabled leaf-scalar-key axis every consumer (caixa-helm’s values.yaml per-chart default, this crate’s cluster_bundle overlay) probes on, and this scalar-value half names the substrate-side default the cluster_bundle overlay path seeds under it. Semantically distinct from — and inverse of — the RenderOpts::enabled_default = false default that [caixa_helm::RenderOpts::default] seeds for the standalone lareira-<nome> chart’s own values.yaml (that path renders enabled: false so cluster operators must opt each caixa in per-cluster); the cluster_bundle composition path is the substrate-side opt-in path where the operator has already asserted per-caixa cluster-scoped ownership by materializing a per-caixa GitRepository + HelmRelease + Kustomization trio, so the overlay forces the child chart on by seeding enabled: true under the values.<library> wrap.

COMPUTEUNIT_MODULE_KEY_SOURCE

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

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

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

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

COMPUTEUNIT_YAML_SUFFIX

The canonical compound suffix every :servicos entry — the ComputeUnit-CR axis the M2 typed-substrate caixa-helm / caixa-flux renderers consume via serde_yaml::from_str — must terminate in. Two-segment shape (.computeunit.yaml) rather than a single .yaml extension: the .computeunit segment routes authoring-time to the typed ComputeUnit CR shape the pleme-computeunit library chart resolves, distinguishing the slot’s accepted set from the open .yaml universe (Helm values.yaml, FluxCD Kustomization.yaml, the generic K8s manifest YAML every operator emits) — same axis-discipline the peer LISP_SOURCE_EXTENSION sibling carries on the tatara-lisp- source axis but with a compound suffix because Path::extension only returns the post-last-. segment ("yaml" for foo.computeunit.yaml), so the predicate routes through Path::file_name and a string ends_with check on the full suffix instead.

CONTRATO_AUTHOR_KEY_DE

Canonical author-facing kebab-case (:de "<caixa>") per-:contratos entry source-endpoint sub-slot label the M3 Aplicacao’s WIT-typed inter-Servico edge set surfaces under. Names the “edge tail” — which member :contratos entry n originates from — per MESH-COMPOSITION §IV table row “:contratos | typed inter-Servico edges | each :de + :para must be in :membros; :wit must reference a registered WIT world”.

CONTRATO_AUTHOR_KEY_PARA

Canonical author-facing kebab-case (:para "<caixa>") per-:contratos entry target-endpoint sub-slot label the M3 Aplicacao’s WIT-typed inter-Servico edge set surfaces under. Names the “edge head” — which member :contratos entry n terminates at — per MESH-COMPOSITION §IV table row “:contratos | typed inter-Servico edges | each :de + :para must be in :membros”. Peer of CONTRATO_AUTHOR_KEY_DE on the sibling :contratos per-entry endpoint-shape axis; see CONTRATO_AUTHOR_KEY_DE for the full lift rationale.

CONTRATO_EDGE_LABEL_SEPARATOR

Canonical M3 :contratos edge-direction separator byte-string every caixa-mesh emitter that encodes a typed edge as a K8s-name-shaped scalar (the LABEL_CONTRATO label value carried on every per-(:de, :para) CiliumNetworkPolicy’s metadata.labels, and the per-(:de, :para) CiliumNetworkPolicy’s metadata.name itself) inserts between the :de and :para halves of the typed edge tuple. Load-bearing on both the writer half (the CNP renderer) and the reader half (Hubble flow grouping by contrato label, per-CNP operator filters, kubectl get cnp -l pleme.pleme.io/contrato=<de>-to-<para> grep-by-label). Until this lift landed the -to- byte-string sat in two verbatim inline-format! sites at the caixa-mesh cilium_network_policies emitter — one at the LABEL_CONTRATO labels.insert(...) call and one at the kube_resource_skeleton name: argument — with no compile-time link between them. A future edge-encoding rebrand (-to- → -> for compactness, -to- → _to_ to reserve - for embedded DNS-1123-label boundaries, an edge-direction-arrow migration to UTF-8 shapes) would have had to be threaded through both sites in lockstep or the two would silently split: one CNP’s metadata.name keys off the drifted encoding, its own metadata.labels.pleme.pleme.io/contrato value keys off the original, and every operator-side grep-by-label query (kubectl get cnp -l pleme.pleme.io/contrato=cart-to-catalog) finds the label but the resulting CNP’s metadata.name no longer matches the queried edge encoding. Every downstream consumer that joins the two axes (the M4 mesh-graph audit, the future Hubble-side contrato-flow renderer, the operator’s per-edge policy inspector) silently loses the join. Lifted onto one &'static str so a future edge-encoding rebrand lands at one const, and every downstream consumer picks up the new encoding by construction.

CONTRATO_KEY_DE

Canonical camelCase JSON/YAML top-level key for the crate::aplicacao::WitContract struct’s de per-entry source-endpoint-of-the-contract axis — the de: field the M3 Aplicacao’s #[serde(rename_all = "camelCase")] derive on crate::aplicacao::WitContract emits at each :contratos entry, and the exact scalar every downstream consumer reaching for the caller-Servico name via Value::get(...) (the future wasm-operator’s per-:contratos edge resolver, the M4 mesh.pleme.io/v1alpha1/Aplicacao CR materializer’s admission webhook per-edge cross-check, the feira app graph verb’s per-edge tail-label lookup, the future per-:contratos CiliumNetworkPolicy emitter’s per-edge fromEndpoints selector projection) must probe on.

CONTRATO_KEY_PARA

Canonical camelCase JSON/YAML top-level key for the crate::aplicacao::WitContract struct’s para per-entry target-endpoint-of-the-contract axis. Peer of CONTRATO_KEY_DE on the same crate::aplicacao::WitContract per-entry serialized-key axis; see CONTRATO_KEY_DE for the full lift rationale. The Rust field is lowercase para; #[serde(rename_all = "camelCase")] is a no-op on this axis and the emitted key equals the source-side field name byte-for-byte.

CONTRATO_KEY_WIT

Canonical camelCase JSON/YAML top-level key for the crate::aplicacao::WitContract struct’s wit per-entry WIT-world-reference-of-the-contract axis — the discriminator every downstream WIT-shape dispatcher ([crate::wit_shape_is_http] / [crate::wit_shape_is_pubsub] / [crate::wit_shape_is_store], the future M4 per-edge WIT registry resolver, the future mesh.pleme.io/v1alpha1/Aplicacao CR materializer’s admission-time WIT-world classification) keys off. Peer of CONTRATO_KEY_DE on the same crate::aplicacao::WitContract per-entry serialized-key axis; see CONTRATO_KEY_DE for the full lift rationale. The Rust field is lowercase wit; #[serde(rename_all = "camelCase")] is a no-op on this axis and the emitted key equals the source-side field name byte-for-byte.

DEFAULT_FLUX_CHART_SOURCE_SUBPATH

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. 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 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 every caixa-flux Kustomization document apply-targets. The single source of truth both axes of the rendered kustomization.yaml document reach for:

DEFAULT_GATEWAY_CLASS_NAME

Canonical K8s Gateway API GatewayClass name every caixa-mesh-emitted Gateway document declares at its spec.gatewayClassName axis — the controller-discriminator that binds the emitted Gateway to a specific GatewayClass resource, which in turn names the controller (spec.controllerName) that reconciles every HTTPRoute / GRPCRoute / TLSRoute / TCPRoute attached to Gateways bound to that class.

DEFAULT_LIBRARY_NAME

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 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.

DEP_AUTHOR_KEY_DEPS

Canonical author-facing kebab-case (defcaixa … :deps ((…))) top- level dep-list slot label the two-list dependency-graph slot family surfaces under. Peer of DEP_AUTHOR_KEY_DEPS_DEV on the two-list dep-graph slot axis: :deps names the runtime-closure dep-list (every Cargo.toml [dependencies] equivalent — reached by every build the caixa participates in), the sibling :deps-dev names the dev-only dep-list (every Cargo.toml [dev-dependencies] equivalent — reached only by test / dev-shim builds).

DEP_AUTHOR_KEY_DEPS_DEV

Canonical author-facing kebab-case (defcaixa … :deps-dev ((…))) top-level dep-list slot label the dev-only two-list dependency-graph slot family surfaces under. Peer of DEP_AUTHOR_KEY_DEPS on the two-list dep-graph slot axis; see DEP_AUTHOR_KEY_DEPS for the full lift rationale.

DEP_SOURCE_KEY_TIPO

Canonical lowercase JSON/YAML discriminator-key the crate::dep::DepSource enum’s #[serde(tag = "tipo", rename_all = "lowercase")] derive emits as the tag axis at each serialized Dep.fonte block — the load-bearing byte-string every downstream consumer reading a Dep source (the [caixa_resolver] per-:deps git-clone dispatcher, the future feira lock / feira resolve lacre.lisp closure writer, every test payload that reaches Value::get(DEP_SOURCE_KEY_TIPO) to pin the variant discriminator) must probe on. Peer of the two variant tag consts DEP_SOURCE_TIPO_GIT and DEP_SOURCE_TIPO_PATH the sibling rename_all = "lowercase" axis lifts on the same discriminator block: the DEP_SOURCE_KEY_TIPO const names the outer tag key ("tipo":) the tag = "tipo" attribute pins, the two DEP_SOURCE_TIPO_* consts name the two admitted tag values ("git" / "path") the rename_all = "lowercase" attribute pins as the discriminator’s closed-set arms.

DEP_SOURCE_TIPO_GIT

Canonical lowercase JSON/YAML discriminator-value the crate::dep::DepSource::Git variant surfaces under — the "git" scalar the #[serde(tag = "tipo", rename_all = "lowercase")] derive emits at the DEP_SOURCE_KEY_TIPO axis for the Git arm. Peer of DEP_SOURCE_TIPO_PATH on the sibling closed-set variant-tag axis; see DEP_SOURCE_KEY_TIPO for the full lift rationale. The scalar is derived from the Rust variant name Git by the rename_all = "lowercase" derive; ASCII-lowercase of Git is git.

DEP_SOURCE_TIPO_PATH

Canonical lowercase JSON/YAML discriminator-value the crate::dep::DepSource::Path variant surfaces under — the "path" scalar the #[serde(tag = "tipo", rename_all = "lowercase")] derive emits at the DEP_SOURCE_KEY_TIPO axis for the Path arm. Peer of DEP_SOURCE_TIPO_GIT on the sibling closed-set variant-tag axis; see DEP_SOURCE_KEY_TIPO for the full lift rationale.

DNS_1123_LABEL_MAX_LEN

K8s DNS-1123 label rule’s max length, in bytes — the floor each apiserver-side schema enforces independently on every metadata.name / Service name / label value axis a validated identifier lands in.

ENTRADA_KEY_HOST

Canonical camelCase JSON/YAML top-level key for the crate::aplicacao::Entrada struct’s host external-hostname axis — the host: field the M3 Aplicacao’s #[serde(rename_all = "camelCase")] derive on crate::aplicacao::Entrada emits at the singleton :entrada block, and the exact scalar every downstream consumer reaching for the external hostname via Value::get(...) (the [caixa_mesh] Gateway/HTTPRoute emitter’s per-Aplicacao spec.hostnames projection under GATEWAY_API_KEY_HOSTNAME / GATEWAY_API_KEY_HOSTNAMES, the future app-operator reconciler’s per-Aplicacao ingress-hostname bind, the future mesh.pleme.io/v1alpha1/Aplicacao CR materializer’s admission-time hostname cross-check against the cluster’s declared GATEWAY_API_HOSTNAME_MAX_LEN discipline) must probe on.

ENTRADA_KEY_PARA

Canonical camelCase JSON/YAML top-level key for the crate::aplicacao::Entrada struct’s para destination-member axis — the para: field naming which :membros entry the external Gateway routes to. Peer of ENTRADA_KEY_HOST on the same crate::aplicacao::Entrada singleton serialized-key axis; see ENTRADA_KEY_HOST for the full lift rationale. The Rust field is lowercase para; #[serde(rename_all = "camelCase")] is a no-op on this axis and the emitted key equals the source-side field name byte-for-byte.

ENTRADA_KEY_PATHS

Canonical camelCase JSON/YAML top-level key for the crate::aplicacao::Entrada struct’s paths per-Aplicacao path-filter axis — the paths: sequence the M3 Aplicacao’s #[serde(rename_all = "camelCase")] derive emits at the singleton :entrada block, and the exact scalar every downstream per-:entrada :paths HTTPRoute-match-projection consumer must probe on (the [caixa_mesh] HTTPRoute emitter’s per-Aplicacao matches[] projection under GATEWAY_API_KEY_MATCHES, defaulting to GATEWAY_API_DEFAULT_HTTP_ROUTE_PATH when the slot is empty per 48e2083). Peer of ENTRADA_KEY_HOST on the same crate::aplicacao::Entrada singleton serialized-key axis; see ENTRADA_KEY_HOST for the full lift rationale. The Rust field is lowercase paths; #[serde(rename_all = "camelCase")] is a no-op on this axis and the emitted key equals the source-side field name byte-for-byte.

ENTRADA_KEY_PORT

Canonical camelCase JSON/YAML top-level key for the crate::aplicacao::Entrada struct’s port destination-Servico port axis — the port: field the M3 Aplicacao’s #[serde(rename_all = "camelCase")] derive emits at the singleton :entrada block, defaulting via [crate::aplicacao::default_port] to crate::DEFAULT_SERVICO_PORT when the author omits the slot. Peer of ENTRADA_KEY_HOST on the same crate::aplicacao::Entrada singleton serialized-key axis; see ENTRADA_KEY_HOST for the full lift rationale. The Rust field is lowercase port; #[serde(rename_all = "camelCase")] is a no-op on this axis and the emitted key equals the source-side field name byte-for-byte.

FLEET_PROGRAMS_KEY_APLICACAO

Canonical lareira-fleet-programs values-schema key naming the per-entry parent-Aplicacao-graph discriminator — the aplicacao: annotation the substrate operator’s fleet-aggregator reads to group each rendered programs[] entry back onto the parent Aplicacao its M3 :membros list contributed it, and the exact key downstream fleet consumers (per-graph observability filters, per-Aplicacao Cilium-policy reconciliation, per-graph Gateway/ HTTPRoute attachment) walk to project the flat programs[] sequence back onto its typed Aplicacao graph.

FLEET_PROGRAMS_KEY_NAME

Canonical lareira-fleet-programs values-schema key naming the per-entry name discriminator — the name: field the library chart’s range .Values.programs step reads to key each rendered ComputeUnit CR’s metadata.name off, and the exact key both writer-side upsert paths in [caixa_flux] match against to replace-in-place-vs-append. Peer of FLEET_PROGRAMS_KEY_PROGRAMS on the same fleet-programs values schema — that constant names the top-level array key, this one names the per-entry name-axis both writer verbs walk the array by.

FLEET_PROGRAMS_KEY_PROGRAMS

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:

FLEET_PROGRAMS_KEY_VERSAO

Canonical lareira-fleet-programs values-schema key naming the per-entry version-constraint discriminator — the versao: field each rendered programs[] entry carries so the substrate operator’s per-:membros resolver can resolve each member’s caixa.lisp against its Aplicacao-declared version-constraint. Every :membros row’s :versao (the semver / range constraint the M3 Aplicacao names on its :membros list) flows through this exact key on the emitted per-entry programs.yaml row.

FLUX_GITREPOSITORY_API_VERSION

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 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 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 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 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 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 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-key every caixa-flux-emitted HelmRelease document nests inside the parent spec.chart.spec sub-document (the HelmChartTemplate.spec block the parent FLUX_KEY_CHART (8467748) container-axis key opens; a nested KUBE_KEY_SPEC axis inside that container hosts this leaf plus its sibling FLUX_KEY_SOURCE_REF per-CR source-reference triple).

FLUX_HELMRELEASE_API_VERSION

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. 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 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 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 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 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 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 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. 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 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 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) — 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) — the Flux v2 CRD schema places the []NamespacedObjectKindReference list under this single container key, so drift on the container axis silently dangles the whole per- Kustomization health-gate the Flux v2 kustomize-controller’s per-CR reconcile loop reads to gate Ready=True on the referenced sibling HelmRelease reaching its HelmReleaseReady=True condition (a "HealthChecks" / "healthchecks" / "healthcheck" / "health_checks" / "probes" typo at either the emit-side format- string template or a downstream test-fixture probe silently dangles the parent Kustomization at Reconciling forever at the Flux v2 kustomize-controller’s health-gate evaluation; the dependent per- cluster fleet-programs upsert chain never sees Ready=True at apply time with no field naming the container-axis-drift root cause).

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. Unlike the sibling per-CR body-key axes (FLUX_KEY_SOURCE_REF, FLUX_KEY_CHART, FLUX_KEY_VALUES, FLUX_KEY_HEALTH_CHECKS) which each land on exactly one of the three Flux v2 controller CRDs, the reconcile-poll cadence scalar-axis is the shared Flux v2 per-CR contract every controller (the source-controller, the helm-controller, the kustomize-controller) reads to schedule its per-CR reconcile loop off the sibling per-CR CRD registration. Drift on the scalar-axis key silently drops the per-CR reconcile schedule from the Flux v2 controllers’ per-CR watch registrations — a "Interval" / "period" / "cadence" / "pollInterval" / "reconcileInterval" typo at any of the three emit-side format-string template sites silently drops the per-CR reconcile schedule from the affected Flux v2 controller’s per-CR watch registration; the referenced Git source never re-polls / the referenced chart never re-templates / the parent Kustomization never re-applies at upstream drift, freezing the whole cluster’s per-caixa per-cluster bundle at the last-applied snapshot with no field naming the scalar-axis-drift root cause.

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 pointer under (spec.chart.spec.sourceRef on HelmRelease, spec.sourceRef on Kustomization) — the Flux v2 CRD schema places the (kind, name, namespace) reference triple under this single container key, so drift on the container axis is exactly as load-bearing as drift on the sibling FLUX_KIND_GIT_REPOSITORY (dbbcf29) kind-discriminator + DEFAULT_FLUX_SYSTEM_NAMESPACE (7197d38) namespace axes the block nests (a "source_ref" / "source" / "sourceReference" / "gitSourceRef" typo at either the emit-side format-string template or a downstream test-fixture probe silently dangles the HelmRelease.spec.chart.spec.sourceRef chart resolution + the Kustomization.spec.sourceRef source resolution at the Flux v2 source-controller’s CRD registration; the source-controller’s per-CR reconcile loop keys off this exact container axis to source the (kind, name, namespace) reference triple, and a drift silently freezes the dependent per-Servico dependsOn chain at apply time with no field naming the sourceRef-container-drift root cause).

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) — 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 every caixa-flux-emitted document that names a Flux v2 GitRepository at a KUBE_KEY_KIND-rooted axis declares. Paired peer to the sibling FLUX_GITREPOSITORY_API_VERSION (8a6c8a3) — the K8s apiserver-side CRD resolution contract is the (apiVersion, kind) tuple keyed against the registered CustomResourceDefinition, so drift on the kind axis is exactly as load-bearing as drift on the apiVersion axis it accompanies (the apiserver’s RESTMapper consults both together; a ("source.toolkit.fluxcd.io/v1", "GitRepostiory") typo at any one of the three production-code call sites lands outside the registered Flux v2 source-controller CRD’s RESTKind lookup, surfacing apply-side as a non-self-locating “no kind ‘GitRepostiory’ is registered for version ‘source.toolkit.fluxcd.io/v1’” error far from the source caixa.lisp / the renderer’s format-string template).

FLUX_KIND_HELM_RELEASE

Canonical FluxCD HelmRelease CRD kind discriminator every caixa-flux-emitted document that names a Flux v2 HelmRelease at a KUBE_KEY_KIND-rooted axis declares. Paired peer to the sibling FLUX_HELMRELEASE_API_VERSION (55f0fd9) — the K8s apiserver-side CRD resolution contract is the (apiVersion, kind) tuple keyed against the registered CustomResourceDefinition, so drift on the kind axis is exactly as load-bearing as drift on the apiVersion axis it accompanies (the apiserver’s RESTMapper consults both together; a ("helm.toolkit.fluxcd.io/v2", "HelmRelase") typo at any one of the two production-code call sites lands outside the registered Flux v2 helm-controller CRD’s RESTKind lookup, surfacing apply-side as a non-self-locating “no kind ‘HelmRelase’ is registered for version ‘helm.toolkit.fluxcd.io/v2’” error far from the source caixa.lisp / the renderer’s format-string template).

FLUX_KIND_KUSTOMIZATION

Canonical FluxCD Kustomization CRD kind discriminator every caixa-flux-emitted document that names a Flux v2 Kustomization at a KUBE_KEY_KIND-rooted axis declares. Paired peer to the sibling FLUX_KUSTOMIZATION_API_VERSION (d2dd1b1) — the K8s apiserver-side CRD resolution contract is the (apiVersion, kind) tuple keyed against the registered CustomResourceDefinition, so drift on the kind axis is exactly as load-bearing as drift on the apiVersion axis it accompanies (the apiserver’s RESTMapper consults both together; a ("kustomize.toolkit.fluxcd.io/v1", "Kustomizaton") typo at the production-code call site lands outside the registered Flux v2 kustomize-controller CRD’s RESTKind lookup, surfacing apply-side as a non-self-locating “no kind ‘Kustomizaton’ is registered for version ‘kustomize.toolkit.fluxcd.io/v1’” error far from the source caixa.lisp / the renderer’s format-string template).

FLUX_KUSTOMIZATION_API_VERSION

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

FLUX_KUSTOMIZATION_KEY_PATH

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 every caixa-flux-emitted kustomization.yaml document seeds to true at the top-level spec position of the emitted Kustomization CR. The Flux v2 kustomize-controller- side per-CR reconcile loop keys off this exact leaf to decide whether to garbage-collect resources that were previously reconciled by the CR but no longer appear in the CR’s current desired-state manifest set (spec.prune: true opts every emitted per-caixa Kustomization into the substrate’s canonical GitOps-side sweep-what-you-removed semantic; spec.prune: false (or absent — Flux v2 defaults the axis to false on any CR that omits the leaf) leaves orphaned resources dangling in the cluster after the source manifest set removes them, silently splitting per-caixa live cluster state from the caixa’s tatara-lisp source-of-truth and every downstream feira app deploy / feira deploy reconcile the substrate’s per-caixa GitOps pipeline emits).

FLUX_KUSTOMIZATION_KEY_TIMEOUT

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. 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 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.

GATEWAY_API_API_VERSION

Canonical K8s Gateway API CRD apiVersion every caixa-mesh-emitted Gateway / HTTPRoute document declares. The K8s apiserver-side SIG-Network Gateway API conformance registers the Gateway / HTTPRoute / GatewayClass / TCPRoute / TLSRoute / GRPCRoute CRDs at this exact group/version (gateway.networking.k8s.io/v1); drift to a stale v1beta1 / v1alpha2 (the pre-GA Gateway API betas every upstream conformance doc names) silently routes the rendered Gateway / HTTPRoute outside the apiserver’s CRD-version registration and breaks at apply time with a non-self-locating “no kind ‘Gateway’ is registered for version ‘gateway.networking.k8s.io/v1beta1’” error far from the source caixa.lisp / the renderer’s kube_resource_skeleton call site.

GATEWAY_API_DEFAULT_HTTP_LISTENER_NAME

K8s Gateway API v1 Gateway.spec.listeners[].name — the substrate’s canonical author-chosen listener-name scalar every Aplicacao-level caixa_mesh::gateway_routes -emitted Gateway’s sole per- listener name-discriminator axis reads from. Gateway API v1’s Listener.name is SectionName-typed (a required DNS-1123 label unique within the parent Gateway’s listener list — see the upstream docs at https://gateway-api.sigs.k8s.io/api-types/gateway/#listeners and the type reference at https://gateway-api.sigs.k8s.io/reference/spec/#gateway.networking.k8s.io/v1.SectionName); downstream HTTPRoute.spec.parentRefs[].sectionName selectors bind to this exact byte-string when the author wants to attach a route to one specific listener out of a multi-listener Gateway. The V0 substrate emits exactly one HTTP listener per Aplicacao, so the name is arbitrary from the CRD’s perspective — the substrate picks the byte-string "http" as the canonical short name (matching the listener’s protocol axis GATEWAY_API_PROTOCOL_HTTP in kind, but not in bytes: this is the lowercase-ASCII listener-name identifier, the sibling protocol scalar is the uppercase-ASCII ProtocolType enum value the Gateway API v1 CRD schema pins).

GATEWAY_API_DEFAULT_HTTP_LISTENER_PORT

K8s Gateway API v1 Gateway.spec.listeners[].port — the substrate’s canonical port scalar every Aplicacao-level caixa_mesh::gateway_routes -emitted Gateway’s sole per- listener HTTP-listener-port axis reads from. IANA-registered as the well-known http service port (RFC 9110 §4.2.2 / RFC 3986 §3.2.3 — the port implied by an http://<host>/… URL when the authority carries no explicit :<port> selector), so the substrate’s external :entrada HTTP flow surfaces at http://<entrada.host>/ with no per-client port override.

GATEWAY_API_DEFAULT_HTTP_ROUTE_PATH

K8s Gateway API v1 HTTPRoute.spec.rules[].matches[].path.value substrate-side catch-all path — the fallback URL path every Aplicacao-level caixa_mesh::gateway_routes -emitted HTTPRoute renders when the typed :entrada :paths slot is empty, so an author who declares an external :entrada but no per-path rule surface still gets a route whose sole HTTPPathMatch matches every incoming request under the paired GATEWAY_API_PATH_MATCH_TYPE_PATH_PREFIX discriminator. K8s Gateway API v1’s PathPrefix matcher over the bare-root "/" is the canonical catch-all shape — the upstream docs at https://gateway-api.sigs.k8s.io/api-types/httproute/#path-based-routing pin the PathPrefix "/" combination as the “match anything the listener admits” idiom every gateway-class controller (Cilium’s Envoy today, Envoy Gateway / Istio Gateway on the peer controllers) treats as the equivalent of “no path predicate” under the CRD schema.

GATEWAY_API_HOSTNAME_MAX_LEN

K8s Gateway API v1 Listener.hostname and HTTPRoute.spec.hostnames[] max length, in bytes — the apiserver-side OpenAPI schema’s maxLength: 253 cap, ultimately the RFC 1035 / RFC 1123 DNS name limit (255 wire bytes minus the trailing-dot + one length prefix). Lifted to a typed const so a future axis reaching for the same bound (the M4 mesh.pleme.io/v1alpha1/Aplicacao CR materializer’s per-:entrada :host validator, the future per-Certificate SAN emitter keying off :entrada :host for cert-manager, the future multi-:entrada host-collision gate when M4 lands :entrada as a Vec) reads the limit from one place. The sole landed call site — the :entrada :host axis’s total-length gate at crate::AplicacaoSpec::validate via validate_entrada_host — reads this constant verbatim; drift between the landing site and the K8s CRD schema surfaces at this one const rather than a per-renderer “this passed validate but failed admission” surprise.

GATEWAY_API_HTTP_PATH_MAX_LEN

K8s Gateway API v1 HTTPPathMatch.value max length, in bytes — the apiserver-side OpenAPI schema’s maxLength: 1024 cap. Lifted to a typed const so a future axis reaching for the same bound (the M4 mesh.pleme.io/v1alpha1/Aplicacao CR materializer’s per-path validator, the future per-HTTPRouteRule per-path-match emission when M4 lands per-rule overrides, the future :politicas-derived per-edge HTTP path overlay’s per-path validator) reads the limit from one place. The two landed call sites — :entrada :paths entries (caixa-mesh’s HTTPRoute.spec.rules[].matches[].path.value emission) and :contratos :endpoint (caixa-mesh’s Cilium L7 path: rule emission, caixa-mesh/src/lib.rs:311) — both inherit the same cap; drift between either landing site and the K8s CRD schema surfaces at this one const.

GATEWAY_API_KEY_ATTEMPTS

Canonical K8s Gateway API HTTPRoute per-rule retry-policy attempts leaf scalar-key every gateway_routes-emitted HTTPRoute document mounts its per-rule :politicas :retries typed u32 attempt count under (spec.rules[].retry.attempts). Leaf peer to the container-axis parent GATEWAY_API_KEY_RETRY (231bbf5) — the sibling per-rule retry-policy body-axis lifted in the immediately-preceding commit; this closes the parent-leaf axis pair (retry container + attempts leaf) the Gateway API v1 HTTPRouteRetry sub-shape pins under HTTPRoute.spec.rules[].retry.attempts.

GATEWAY_API_KEY_BACKEND_REFS

Canonical K8s Gateway API HTTPRoute per-rule backend-destination container-axis key every gateway_routes-emitted HTTPRoute document mounts its per-rule [{name, port}] backend list under (spec.rules[].backendRefs[]). Pairs with the sibling GATEWAY_API_KEY_PARENT_REFS (f44e823) — the Gateway API v1 CRD schema pins the per-HTTPRoute route→Gateway attachment through the spec.parentRefs[] container axis and the per-rule route→Servico backend fan-out through the spec.rules[].backendRefs[] axis beneath each rule entry, so drift on the per-rule backend-destination axis is exactly as load-bearing as drift on the per-HTTPRoute parent-Gateway-binding axis it accompanies (the K8s apiserver-side Gateway API CRD schema validator drops any per-rule block whose backend-destination container axis carries an unrecognized key — a "backendRef" / "backends" / "forwardTo" typo silently emits an HTTPRoute whose per-rule backend fan-out the Gateway API implementation’s per-rule L7 dispatch loop no-ops entirely: no backend is picked, and every external :entrada request the rule was authored to route drops at the gateway-class-controller’s per-rule reconcile with no field naming the backend-destination- axis-drift root cause).

GATEWAY_API_KEY_GATEWAY_CLASS_NAME

Canonical K8s Gateway API Gateway per-Gateway controller-binding scalar-axis key every gateway_routes-emitted Gateway document mounts its per-Gateway GatewayClass.metadata.name reference under (spec.gatewayClassName). Pairs with the sibling DEFAULT_GATEWAY_CLASS_NAME (d9b0743) — the K8s Gateway API v1 CRD schema pins the per-Gateway controller-binding through the scalar spec.gatewayClassName axis (each Gateway names exactly one GatewayClass.metadata.name; the sibling spec.listeners[] + spec.addresses[] container axes carry the L7-listener fan-out + per-Gateway address hint under the same spec block), so drift on the per-Gateway controller-binding scalar-axis KEY is exactly as load-bearing as drift on the sibling DEFAULT_GATEWAY_CLASS_NAME VALUE the axis wraps (the K8s apiserver-side Gateway API CRD schema validator drops any spec block whose controller-binding scalar- axis carries an unrecognized key — a "gatewayClass" / "className" / "gatewayClassRef" typo silently emits a Gateway whose controller-binding the Gateway API implementation’s per- Gateway reconcile loop no-ops entirely: no GatewayClass is resolved, no controllerName is looked up, and every external :entrada flow the Gateway was authored to accept drops at the gateway-class-controller’s per-Gateway reconcile with no field naming the controller-binding-axis-drift root cause).

GATEWAY_API_KEY_HOSTNAME

Canonical K8s Gateway API Gateway per-listener DNS-host-discriminator axis key every gateway_routes-emitted Gateway document mounts each listener’s virtual-host name under (spec.listeners[].hostname). Pairs with the sibling GATEWAY_API_KEY_LISTENERS (29f2415) — the Gateway API v1 CRD schema pins the per-Gateway L7-listener-set fan-out through the spec.listeners[] container axis (each entry names one listener the Gateway accepts external traffic on) and pins each entry’s per-listener DNS-host discriminator under the nested hostname axis (Gateway API v1 Listener.hostname — PreciseHostname string, optional per-listener virtual-host filter the Gateway-API-implementation-side per-Gateway reconcile loop honors when routing external inbound traffic against SNI at the TLS handshake / Host: header at the HTTP request line), so drift on the per-listener DNS-host discriminator axis is exactly as load-bearing as drift on the per-Gateway L7-listener-set container axis it nests under (the K8s apiserver-side Gateway API CRD schema validator drops any per-listener entry whose DNS-host discriminator axis carries an unrecognized key — a "host" / "vhost" / "serverName" typo silently emits a Gateway whose per-listener virtual-host filter the Gateway API implementation’s per-listener SNI / Host: header dispatch loop no-ops entirely: the listener accepts traffic on the wildcard host rather than the typed :entrada :host the Aplicacao author declared, and every external :entrada flow the listener was authored to accept lands on the wrong virtual-host filter with no field naming the DNS-host-discriminator-axis-drift root cause).

GATEWAY_API_KEY_HOSTNAMES

Canonical K8s Gateway API HTTPRoute spec-level DNS-host-filter axis key every gateway_routes-emitted HTTPRoute document mounts the route’s per-route virtual-host filter list under (spec.hostnames[]). The plural sibling of GATEWAY_API_KEY_HOSTNAME (c96fa22) — same Gateway-API-CRD DNS-host-discriminator convention nested one level up on the sibling HTTPRoute per-route body-axis surface, distinct spelling (hostnames — plural — is the HTTPRoute spec-level filter list; the singular hostname axis it pairs against is the per-Gateway-listener virtual-host discriminator).

GATEWAY_API_KEY_LISTENERS

Canonical K8s Gateway API Gateway per-listener-set container-axis key every gateway_routes-emitted Gateway document mounts its per-Gateway [{name, port, protocol, hostname}] L7-listener fan-out list under (spec.listeners[]). Pairs with the sibling GATEWAY_API_KEY_PARENT_REFS (f44e823) + GATEWAY_API_KEY_BACKEND_REFS (a6c5679) — the Gateway API v1 CRD schema pins the per-Gateway L7-listener fan-out through the spec.listeners[] container axis (each entry names one listener the Gateway accepts external traffic on; the sibling spec.parentRefs[] + spec.rules[].backendRefs[] container axes carry the per-HTTPRoute parent-Gateway attachment + per-rule backend-destination fan-out halves under the paired HTTPRoute spec block), so drift on the per-Gateway L7-listener-set axis is exactly as load-bearing as drift on the per-HTTPRoute parent-Gateway- binding + per-rule backend-destination axes it accompanies (the K8s apiserver-side Gateway API CRD schema validator drops any spec block whose L7-listener-set container axis carries an unrecognized key — a "listener" / "listen" / "servers" typo silently emits a Gateway whose L7-listener fan-out the Gateway API implementation’s per-Gateway reconcile loop no-ops entirely: no listener is opened, and every external :entrada flow the Gateway was authored to accept drops at the gateway-class-controller’s per- Gateway HTTP-listener fan-in with no field naming the L7-listener- set-axis-drift root cause).

GATEWAY_API_KEY_MATCHES

Canonical K8s Gateway API HTTPRoute per-rule route-match container-axis key every gateway_routes-emitted HTTPRoute per-rule block mounts its per-rule [{path: {type, value}}] route-match fan-out list under (spec.rules[].matches[]). Pairs with the sibling GATEWAY_API_KEY_BACKEND_REFS (a6c5679) — the Gateway API v1 CRD schema pins per-rule request-selection through the spec.rules[].matches[] container axis (each entry names one HTTPRouteMatch predicate the request line + headers + query must satisfy for the rule’s backend fan-out to apply) alongside the per-rule route→Servico backend fan-out under spec.rules[].backendRefs[], so drift on the per-rule route-match axis is exactly as load-bearing as drift on the sibling per-rule backend-destination axis it accompanies (the K8s apiserver-side Gateway API CRD schema validator drops any per-rule block whose route-match container axis carries an unrecognized key — a "match" / "routeMatches" / "predicates" typo silently emits an HTTPRoute whose per-rule request-selection axis the Gateway API implementation’s per-rule L7 dispatch loop no-ops entirely: no request predicate is evaluated, the rule matches every request unconditionally at the wildcard predicate, and every external :entrada path filter the rule was authored to enforce drops at the gateway-class-controller’s per-rule reconcile with no field naming the route-match-axis-drift root cause).

GATEWAY_API_KEY_NAME

Canonical K8s Gateway API v1 per-child-object name-reference discriminator axis key every gateway_routes-emitted Gateway listener + HTTPRoute parentRefs[] / backendRefs[] entry mounts its named-object binding under. Three peer sub-schemas on the shared spec.…[].name axis:

GATEWAY_API_KEY_PARENT_REFS

Canonical K8s Gateway API HTTPRoute parent-Gateway-binding container- axis key every gateway_routes-emitted HTTPRoute document mounts its per-route parent-Gateway [{name}] list under (spec.parentRefs[]). Pairs with the sibling GATEWAY_API_KIND_HTTP_ROUTE (1adccc0) + GATEWAY_API_KIND_GATEWAY (fb4639c) — the Gateway API v1 CRD schema pins the per-HTTPRoute parent-Gateway identity through the spec.parentRefs[] container axis (each entry names the parent Gateway the route attaches to; the sibling hostnames + rules container axes carry the per-route host-match + per-rule L7-dispatch halves under the same spec block), so drift on the parent-Gateway- binding axis is exactly as load-bearing as drift on the per-HTTPRoute kind discriminator axis it accompanies (the K8s apiserver-side Gateway API CRD schema validator drops any spec block whose parent- binding container axis carries an unrecognized key — a "parentRef" / "parents" / "parentGateways" typo silently emits an HTTPRoute whose parent-Gateway attachment the Gateway API implementation’s per-HTTPRoute reconcile loop no-ops entirely: the route lands unattached to any Gateway, and every external :entrada flow the HTTPRoute was authored to accept drops at the Gateway API implementation’s per-Gateway HTTP-listener fan-in with no field naming the parent-Gateway-binding-axis-drift root cause).

GATEWAY_API_KEY_PATH

Canonical K8s Gateway API HTTPRoute per-HTTPRouteMatch path-matcher container-axis key every gateway_routes-emitted HTTPRoute per-rule matches[] entry mounts its per-match {type, value} path-selection predicate under (spec.rules[].matches[].path). Nests one level beneath the sibling GATEWAY_API_KEY_MATCHES (b9ede1a) per-rule route-match container-axis it hangs off of — the Gateway API v1 CRD schema pins per-HTTPRouteMatch request-path selection through the spec.rules[].matches[].path container axis (each match entry names one path-selection predicate the request line’s :path pseudo-header must satisfy under a type discriminator of Exact | PathPrefix | RegularExpression) alongside the sibling per- HTTPRouteMatch headers[] / queryParams[] / method axes it nests under, so drift on the per-match path-matcher container axis is exactly as load-bearing as drift on the per-rule route-match axis it nests inside of (the K8s apiserver-side Gateway API CRD schema validator drops any per-match block whose path-matcher container axis carries an unrecognized key — a "pathMatch" / "prefix" / "url" typo silently emits an HTTPRoute whose per- match path-selection axis the Gateway API implementation’s per-rule L7 dispatch loop no-ops entirely: no path predicate is evaluated, the match degrades to the wildcard predicate at the gateway-class- controller’s per-rule reconcile, the rule matches every request path unconditionally, and every external :entrada path filter the rule was authored to enforce drops with no field naming the path- matcher-axis-drift root cause).

GATEWAY_API_KEY_REQUEST

Canonical K8s Gateway API HTTPRoute per-rule request-timeout-policy request leaf scalar-key every gateway_routes-emitted HTTPRoute document mounts its per-rule :politicas :timeout typed K8s-duration string under (spec.rules[].timeouts.request). Leaf peer to the container-axis parent GATEWAY_API_KEY_TIMEOUTS (db31108) — the sibling per-rule request-timeout-policy body-axis — and to the peer retry-container leaf GATEWAY_API_KEY_ATTEMPTS (e2e136b) landed on the parallel retry.attempts nesting; this closes the parent-leaf axis pair (timeouts container + request leaf) the K8s Gateway API v1 HTTPRouteTimeouts sub-shape pins under HTTPRoute.spec.rules[].timeouts.request.

GATEWAY_API_KEY_RETRY

Canonical K8s Gateway API HTTPRoute per-rule retry-policy body-axis key every gateway_routes-emitted HTTPRoute document mounts its per-rule :politicas :retries overlay under (spec.rules[].retry). Sibling per-rule-body-axis peer to GATEWAY_API_KEY_TIMEOUTS (db31108) — same Gateway-API-CRD-body-axis discipline nested onto the per-rule retry-budget slot the Gateway API v1 CRD schema pins under HTTPRoute.spec.rules[] beside the sibling per-rule request-timeout- policy container.

GATEWAY_API_KEY_SECTION_NAME

Canonical K8s Gateway API HTTPRoute per-spec.parentRefs[] entry listener-selector sub-axis key every gateway_routes-emitted HTTPRoute document mounts under each parent-Gateway attachment to pin the route to one specific listener out of the parent Gateway’s spec.listeners[] list (spec.parentRefs[].sectionName). Pairs with the sibling GATEWAY_API_KEY_PARENT_REFS (f44e823) — the Gateway API v1 CRD schema pins per-HTTPRoute route→Gateway attachment through the spec.parentRefs[] container axis and the per-entry listener-selection sub-axis through sectionName beneath each entry (each SectionName-typed scalar binds to a Gateway.spec.listeners[].name byte-string). Omitting the selector attaches the route to every listener on the parent Gateway — the Gateway API v1 default fan-out that silently doubles route emission once the substrate ships a second listener under the HTTPS-by-default trajectory the peer GATEWAY_API_DEFAULT_HTTP_LISTENER_NAME (cd60fde) docstring forecasts ("http" → "http-v1" alongside a sibling "https" listener once cert-manager-issued per-:entrada :host certificates land). Pinning the selector by construction binds each substrate- emitted route to exactly one listener on the parent Gateway, so a future multi-listener migration lands as one const-edit on the paired GATEWAY_API_DEFAULT_HTTP_LISTENER_NAME declaration instead of a silent per-route dispatch flip.

GATEWAY_API_KEY_TIMEOUTS

Canonical K8s Gateway API HTTPRoute per-rule request-timeout-policy body-axis key every gateway_routes-emitted HTTPRoute document mounts its per-rule :politicas :timeout overlay under (spec.rules[].timeouts). Sibling per-rule-body-axis peer to GATEWAY_API_KEY_BACKEND_REFS (a6c5679) and GATEWAY_API_KEY_HOSTNAMES (b77f744) — same Gateway-API-CRD-body-axis discipline nested one level deeper onto the per-rule request-deadline slot the Gateway API v1 CRD schema pins under HTTPRoute.spec.rules[].

GATEWAY_API_KEY_VALUE

Canonical K8s Gateway API v1 HTTPPathMatch value scalar-axis key every gateway_routes-emitted HTTPRoute per-match path block mounts its request-path-selection scalar payload under (spec.rules[].matches[].path.value). Nests one level beneath the sibling GATEWAY_API_KEY_PATH per-HTTPRouteMatch path-matcher container-axis it hangs off of — the Gateway API v1 CRD schema pins per-HTTPPathMatch request-path selection through the {type, value} two-axis pair (a GATEWAY_API_PATH_MATCH_TYPE_PATH_PREFIX-typed type discriminator picks Exact | PathPrefix | RegularExpression; the value scalar carries the per-match request-path string the discriminator is applied against), so drift on the value scalar axis is exactly as load-bearing as drift on the peer type discriminator axis it nests alongside (the K8s apiserver-side Gateway API CRD schema validator drops any per-match block whose HTTPPathMatch scalar-payload axis carries an unrecognized key — a "path" / "prefix" / "pattern" typo silently emits an HTTPRoute whose per-match request-path predicate the Gateway API implementation’s per-rule L7 dispatch loop treats as bare (no value evaluated against the type discriminator), the match degrades to the wildcard predicate at the gateway-class- controller’s per-rule reconcile, the rule matches every request path unconditionally, and every external :entrada path filter the rule was authored to enforce drops with no field naming the HTTPPathMatch-scalar-payload-drift root cause).

GATEWAY_API_KIND_GATEWAY

Canonical K8s Gateway API CRD kind discriminator the rendered Gateway document declares at its top-level KUBE_KEY_KIND axis. Pairs with the sibling GATEWAY_API_API_VERSION (3c6cfc3) — the K8s apiserver-side CRD resolution contract is the (apiVersion, kind) tuple keyed against the registered CustomResourceDefinition, so drift on the kind axis is exactly as load-bearing as drift on the apiVersion axis it accompanies (the apiserver’s RESTMapper consults both together; a ("gateway.networking.k8s.io/v1", "Gatway") typo at the production- code call site lands outside the registered Gateway-API-conformant Gateway CRD’s RESTKind lookup, surfacing apply-side as a non-self-locating “no kind ‘Gatway’ is registered for version ‘gateway.networking.k8s.io/v1’” error far from the source caixa.lisp / the renderer’s kube_resource_skeleton call site).

GATEWAY_API_KIND_HTTP_ROUTE

Canonical K8s Gateway API CRD kind discriminator the rendered HTTPRoute document declares at its top-level KUBE_KEY_KIND axis. Pairs with the sibling GATEWAY_API_API_VERSION (3c6cfc3) and the peer GATEWAY_API_KIND_GATEWAY (fb4639c) — the K8s apiserver-side CRD resolution contract is the (apiVersion, kind) tuple keyed against the registered CustomResourceDefinition, so drift on the kind axis is exactly as load-bearing as drift on the apiVersion axis it accompanies (the apiserver’s RESTMapper consults both together; a ("gateway.networking.k8s.io/v1", "HTTPRout") typo at the production-code call site lands outside the registered Gateway-API- conformant HTTPRoute CRD’s RESTKind lookup, surfacing apply-side as a non-self-locating “no kind ‘HTTPRout’ is registered for version ‘gateway.networking.k8s.io/v1’” error far from the source caixa.lisp / the renderer’s kube_resource_skeleton call site).

GATEWAY_API_PATH_MATCH_TYPE_PATH_PREFIX

Canonical K8s Gateway API v1 PathMatchType OpenAPI schema enum’s PathPrefix per-HTTPRouteMatch path-selection-predicate discriminator value every gateway_routes-emitted HTTPRoute per-rule matches[] entry declares under its per-match spec.rules[].matches[].path.type scalar axis. Pairs with the sibling GATEWAY_API_KEY_PATH (9f45aa4) per-HTTPRouteMatch path-matcher container-axis key it nests one level beneath — the Gateway API v1 CRD schema pins per-HTTPRouteMatch request-path selection through the spec.rules[].matches[].path container axis (each match entry names one path-selection predicate the request line’s :path pseudo-header must satisfy under a type discriminator scalar value; the Gateway API v1 PathMatchType OpenAPI schema enum admits the closed set {"Exact", "PathPrefix", "RegularExpression"} verbatim), so drift on the path-match-type value is exactly as load-bearing as drift on the sibling GATEWAY_API_PROTOCOL_HTTP (1b57473) per-listener L7-parser-selection scalar value the peer spec.listeners[].protocol axis carries (a "pathPrefix" / "path_prefix" / "Prefix" / "path-prefix" typo at the production-code call site lands outside the Gateway API v1 PathMatchType OpenAPI schema enum’s admitted set, surfacing apply-side as a non-self-locating “spec.rules[0].matches[0].path.type: Unsupported value: "pathPrefix": supported values: "Exact", "PathPrefix", "RegularExpression"” apiserver admission-rejection far from the source caixa.lisp / the renderer’s path_match.insert(…) call site — the rendered per-Aplicacao HTTPRoute object never reconciles at the gateway-class-controller’s per-rule L7 dispatch loop and every external :entrada path-filtered flow drops at the gateway-class-controller’s admission gate with no field naming the path-match-type-drift root cause).

GATEWAY_API_PROTOCOL_HTTP

Canonical K8s Gateway API Gateway.spec.listeners[].protocol HTTP listener-protocol scalar value the rendered Gateway document’s first (and V0-only) listener declares under its KUBE_KEY_PROTOCOL axis. Pairs with the sibling GATEWAY_API_KIND_GATEWAY (fb4639c) + GATEWAY_API_KIND_HTTP_ROUTE (1adccc0) — the K8s Gateway API v1 CRD schema pins the per-listener L7 parser + TLS-termination strategy through the spec.listeners[].protocol scalar value (the gateway-class-controller’s per-listener bind loop selects the L7 parser + TLS termination strategy from this exact byte-sequence; the Gateway API v1 ProtocolType OpenAPI schema enum admits the closed set {"HTTP", "HTTPS", "TCP", "TLS", "UDP"} verbatim), so drift on the listener-protocol value is exactly as load-bearing as drift on the sibling GATEWAY_API_KIND_GATEWAY + GATEWAY_API_KIND_HTTP_ROUTE CRD kind discriminators the pair declares together (a ("Gateway", "http") / ("Gateway", "Http") / ("Gateway", "http/1.1") typo at the production-code call site lands outside the Gateway API v1 ProtocolType OpenAPI schema enum, surfacing apply-side as a non-self-locating “spec.listeners[0].protocol: Unsupported value: "http": supported values: "HTTP", "HTTPS", "TCP", "TLS", "UDP"” apiserver admission-rejection far from the source caixa.lisp / the renderer’s listener.insert(…) call site — the rendered per-Aplicacao Gateway object never reconciles at the gateway-class-controller’s per-listener bind loop and every external :entrada HTTP flow drops at the gateway-class- controller’s admission gate with no field naming the listener-protocol-drift root cause).

GIT_OID_SHA1_LEN

Length, in lowercase-hex characters, of a full Git SHA-1 commit OID — the canonical commit identifier every git rev-parse HEAD invocation emits on a SHA-1-hashed repository. git’s loose-object store keys every object under .git/objects/<first-2-hex>/<last-38-hex>, so the full 40-char OID is the address-of-truth the porcelain consumes at git fetch <remote> <40-hex> and git checkout <40-hex> time; abbreviated OIDs are admitted by the porcelain through a separate prefix-lookup pass and are ambiguous across repository history (a 7-char prefix that resolves to one commit today can become a collision tomorrow as the repo grows). Lifted as a typed const so the :fonte :rev validate gate, the future lacre-side resolved-rev gate, and the future M4 per-dep CR materializer’s per-pin validator all read from one place.

GIT_OID_SHA256_LEN

Length, in lowercase-hex characters, of a full Git SHA-256 commit OID — the canonical commit identifier on a SHA-256-hashed repository (Git’s extensions.objectFormat = sha256 mode, GA since Git 2.42 / Oct 2023). Doubled width vs. SHA-1: 256 bits = 64 hex chars. Carried alongside GIT_OID_SHA1_LEN so the typed :rev slot admits either canonical hash-algorithm OID without per-renderer branching; the lacre’s BLAKE3 content-addressing (THEORY.md §IV — typed reproducibility envelope) is orthogonal to the upstream git’s chosen object hash and neither OID width should leak into downstream code paths.

GIT_REF_NAME_MAX_LEN

Max length, in bytes, of a single typed git ref name passing the is_git_ref_name predicate. 255 bytes — matches the POSIX NAME_MAX filesystem-component limit every Git porcelain ultimately stores refs into (loose refs/<category>/<name> files under .git/refs/, packed-refs index entries). Refs that exceed this cap fail to land on disk at clone/fetch time on every realistic filesystem (ext4, btrfs, xfs, APFS, NTFS), so a :tag / :branch past that length is unsourceable in practice. The cap exists to reject the paste-from-binary footgun (a multi-line blob accidentally landed in the :tag slot) rather than to constrain legitimate authoring — realistic tag/branch names rarely exceed ~32 bytes ("v0.1.0" = 6 bytes, "release-1.0-alpha.1" = 19 bytes, "feature/checkout-rewrite" = 24 bytes). Lifted as a typed const so a future axis reaching for the same bound (the future lacre.lisp ref-shape gate on resolved-pin axes, the future M4 per-dep CR materializer’s per-pin validator) reads from one place.

GIT_REPO_URL_MAX_LEN

:fonte (:tipo git :repo …) value max length, in bytes — a generous URL-shaped cap covering every documented author surface (the github:org/repo shorthand, the https:// / ssh:// / git:// / file:// URL schemes, the git@host:path scp-style SSH form). The cap mirrors the conservative ceiling typical HTTP gateways and git porcelain entries enforce on URL inputs (the OWASP-recommended URL max of 2048 bytes); a :repo value above this bound is structurally untenable on every realistic landing site — the caixa-resolver’s git clone <repo> invocation, the future M4 mesh.pleme.io/v1alpha1/Caixa CR materializer’s per-dep repo: axis, the future lacre BLAKE3 closure’s resolved-repo identity — and a value of that length is almost certainly a paste-from-binary slug or a multi-line blob that landed in the slot.

HELM_CHART_API_VERSION

Canonical Helm 3 Chart.yaml apiVersion every caixa-helm-rendered lareira-<nome> chart declares at its top-level apiVersion axis. The Helm 3 chart-schema resolution contract keys off this exact "v2" value: helm dependency build, helm lint, and helm template all parse the chart under the Helm 3 v2 schema (which requires ChartYaml::description and permits dependencies: at the top level); drift to the legacy Helm 2 "v1" (the pre-Helm-3 chart schema every upstream Helm-3-migration doc names) silently reroutes the rendered Chart.yaml through the Helm 2 parser, where the top-level dependencies: block is unknown and the chart’s dep on the pleme-computeunit library chart never resolves — helm dependency build reports “no requirements found” and every downstream helm template / helm install on the rendered chart emits an empty release (no ComputeUnit / Service / ScaledObject resources land) far from the source caixa.lisp / the renderer’s build_chart_yaml call site.

HELM_CHART_DEPENDENCY_KEY_ALIAS

Canonical Helm 3 Chart.yaml per-dependencies[]-entry sub-mapping YAML axis-key naming the per-dep chart-alias override field — the load-bearing serde field-name at caixa-helm’s ChartDependency struct’s alias field. The chart-schema per-dep entry’s alias: value, when set, overrides the per-dep values wrap-key (Helm’s per-dep alias convention scopes the per-dep values sub-block under alias: when set, and under the sibling HELM_CHART_DEPENDENCY_KEY_NAME name: value otherwise); the caixa-helm substrate today emits the axis as None at every rendered lareira-<nome> chart’s dependencies[0].alias: (the #[serde(default, skip_serializing_if = "Option::is_none")] attribute on the alias field elides the axis entirely from the emitted YAML when unset), so the values wrap-key defaults to the per-dep name: value — but the axis-key remains part of the substrate-side chart-schema-per-dep-entry contract for the future per-Aplicacao library chart’s per-Servico per-dep aliasing HELM_CHART_TYPE_LIBRARY docstring names as a trajectory item. A drift on this per-dep sub-key (a future refactor that renamed the ChartDependency::alias Rust field, or added a #[serde(rename_all = "camelCase")] attribute that silently activates on a future field addition) would rebrand the wire key silently — Helm’s per-dep alias-convention router would silently drop the alias from the parsed dep-entry (the per-dep values wrap- key falls back to the sibling name: value, and every per-cluster per-Servico per-dep values override the operator authored under the alias-key silently routes nowhere at helm template time). Peer to HELM_CHART_DEPENDENCY_KEY_NAME / HELM_CHART_DEPENDENCY_KEY_VERSION / HELM_CHART_DEPENDENCY_KEY_REPOSITORY on the sibling per-dep sub-key axes — completes the per-dependencies[]-entry YAML axis-key canonical-pin tetrad. See HELM_CHART_DEPENDENCY_KEY_NAME for the shared per-entry-sub-mapping lift rationale.

HELM_CHART_DEPENDENCY_KEY_NAME

Canonical Helm 3 Chart.yaml per-dependencies[]-entry sub-mapping YAML axis-key naming the per-dep chart-name field — the load-bearing serde field-name at caixa-helm’s ChartDependency struct’s name field. Byte-identical to the sibling K8s CR KUBE_KEY_NAME axis-key by Helm’s design decision to inherit the K8s CR body-key vocabulary at every schema surface it consumes (chart-metadata, per-CR install-payload, per-dep dependency-list); the paired [tests::helm_chart_dependency_key_name_matches_kube_key_name] pin asserts the two byte-shapes coincide, so a future K8s-side rebrand at KUBE_KEY_NAME that dropped the byte-identity would fail the pin at substrate-build time rather than silently drop the per-dep name lookup at helm dependency build time far from the drift site.

HELM_CHART_DEPENDENCY_KEY_REPOSITORY

Canonical Helm 3 Chart.yaml per-dependencies[]-entry sub-mapping YAML axis-key naming the per-dep chart-registry URL field — the load-bearing serde field-name at caixa-helm’s ChartDependency struct’s repository field. The chart-schema per-dep entry’s repository: value pins the Helm-registry URL (file://…, https://…, oci://…) Helm’s per-dep resolver consults at helm dependency build time to fetch the per-dep chart bytes. At the caixa-helm substrate the default value is the canonical [caixa_helm::DEFAULT_LIBRARY_REPO] pointing at the helmworks file:// path; the future per-edition library-chart re-emission for the OCI registry (once pleme-io/helmworks/charts lands as an OCI-registry-backed chart-source) reaches this axis through a paired scalar-value lift on the per-dep repo axis. A drift on this per-dep sub-key would surface as one of two silent failure modes at chart-vendor time far from the drift site: Helm’s per-dep resolver silently drops the repository scalar from the parsed dep-entry (the per-dep resolver falls back to the “no repository set” shape and refuses to vendor the dep with no repository defined), or the per-dep chart-schema parser silently absorbs a rename drift via #[serde(default)] fall-through at the struct-side and the per-dep repo axis lands under Rust’s "" default — Helm rejects the empty URL at helm dependency build time. Peer to HELM_CHART_DEPENDENCY_KEY_NAME / HELM_CHART_DEPENDENCY_KEY_VERSION / HELM_CHART_DEPENDENCY_KEY_ALIAS on the sibling per-dep sub-key axes. See HELM_CHART_DEPENDENCY_KEY_NAME for the shared per-entry-sub-mapping lift rationale.

HELM_CHART_DEPENDENCY_KEY_VERSION

Canonical Helm 3 Chart.yaml per-dependencies[]-entry sub-mapping YAML axis-key naming the per-dep chart-version-constraint field — the load-bearing serde field-name at caixa-helm’s ChartDependency struct’s version field. Distinct from the sibling per-Chart.yaml top-level chart-own-SemVer axis-key (version: at the top level, whose byte-shape coincides with this per-dep sub-key at the wire — a coincidence the substrate-side paired [tests::helm_chart_dependency_key_version_pins_canonical_value] pin holds byte-verbatim). The chart-schema per-dep entry’s version: value pins the SemVer-range constraint Helm’s per-dep resolver matches against the target dep’s Chart.yaml version: scalar at helm dependency build / helm dependency update time. A drift on this per-dep sub-key would surface as one of two silent failure modes at chart-vendor time far from the drift site: Helm’s per-dep chart-schema parser silently drops the version-constraint scalar from the parsed dep-entry (the per-dep resolver falls back to the wildcard * shape and vendors whatever chart-version the upstream registry currently advertises, silently promoting a chart upgrade the operator never authored), or a subsequent #[serde(rename_all)] addition rebrands the key to Helm’s unrecognized shape and the per-dep entry silently vanishes from the parsed dep-list. Peer to HELM_CHART_DEPENDENCY_KEY_NAME / HELM_CHART_DEPENDENCY_KEY_REPOSITORY / HELM_CHART_DEPENDENCY_KEY_ALIAS on the sibling per-dep sub-key axes — extends the per-entry-sub-key canonical-lift tetrad at the substrate. See HELM_CHART_DEPENDENCY_KEY_NAME for the shared per-entry-sub-mapping lift rationale.

HELM_CHART_KEY_API_VERSION

Canonical Helm 3 Chart.yaml top-level YAML axis-key naming the per-chart chart-schema-apiVersion field whose scalar-value HELM_CHART_API_VERSION already owns as the peer axis-value lift. Where the peer axis-value lift pins the byte-shape of the apiVersion: field’s admitted scalar (Helm 3’s "v2"), this axis-key lift pins the byte-shape of the apiVersion: field’s YAML-key name itself: the load-bearing serde-rename literal at caixa-helm’s ChartYaml struct (caixa-helm/src/lib.rs:145, #[serde(rename = "apiVersion")]) that selects how the Rust field api_version serializes into the rendered Chart.yaml YAML mapping.

HELM_CHART_KEY_APP_VERSION

Canonical Helm 3 Chart.yaml top-level YAML axis-key naming the per-chart underlying-application-version field — the load-bearing serde-rename literal at caixa-helm’s ChartYaml struct (caixa-helm/src/lib.rs:152, #[serde(rename = "appVersion")]) that selects how the Rust field app_version serializes into the rendered Chart.yaml YAML mapping. Distinct from the sibling Chart.yaml version: field (the chart’s own SemVer, incremented per release of the chart itself); the appVersion: field the Helm 3 chart-schema pins carries the underlying application’s version (see app-version-doc) — the version the containerized workload the chart installs advertises (an OCI image tag, a wasm-component :versao, a package release tag). At the caixa-helm renderer today the two axes both draw from the caixa’s :versao at [build_chart_yaml] because a [caixa-core::Caixa]’s :versao names both the chart’s own release cadence and the underlying wasm-component release cadence in one axis (caixa’s per-caixa BLAKE3-closure identity binds a caixa’s chart + wasm-binary + declared source at exactly one release axis), but the Chart.yaml schema pins the two YAML keys distinctly regardless — every downstream Helm-consumer (Artifact Hub’s per-chart-search index, helm search / helm show chart operator surfaces) routes the two axes onto distinct display fields at chart-inspection time.

HELM_CHART_KEY_DEPENDENCIES

Canonical Helm 3 Chart.yaml top-level YAML axis-key naming the per-chart dependency-list field — the load-bearing serde field-name at caixa-helm’s ChartYaml struct’s dependencies field, the parent list-container the already-lifted HELM_CHART_DEPENDENCY_KEY_NAME / HELM_CHART_DEPENDENCY_KEY_VERSION / HELM_CHART_DEPENDENCY_KEY_REPOSITORY / HELM_CHART_DEPENDENCY_KEY_ALIAS per-entry sub-mapping tetrad (69f62db) mounts under. The chart-schema top-level dependencies: field pins the list of chart-registry references Helm’s per-dep resolver consults at helm dependency build / helm dependency update time to vendor each dependency chart under the substrate’s canonical DEFAULT_LIBRARY_NAME wrap-key convention. Every rendered lareira-<nome> chart declares exactly one entry today (the DEFAULT_LIBRARY_NAME pleme-computeunit library-chart dep the sibling caixa-helm’s build_chart_yaml mounts) — see chart-dependencies-doc for the Helm 3 upstream axis documentation.

HELM_CHART_KEY_TYPE

Canonical Helm 3 Chart.yaml top-level YAML axis-key naming the per-chart-kind discriminator field whose closed-set scalar-value pair HELM_CHART_TYPE_APPLICATION / HELM_CHART_TYPE_LIBRARY already owns as the peer axis-value lift. Where the peer axis-value lifts pin the byte-shape of the type: field’s admitted-value set, this axis-key lift pins the byte-shape of the type: field’s YAML-key name itself: the load-bearing serde- rename literal at caixa-helm’s ChartYaml struct (caixa-helm/src/lib.rs:149, #[serde(rename = "type")]) that selects how the Rust field chart_type serializes into the rendered Chart.yaml YAML mapping.

HELM_CHART_README_FILENAME

Canonical lareira-<nome> chart-directory human-facing readme filename every rendered chart carries at its top-level directory — the fixed filename the caixa-helm renderer emits alongside the two schema-load- bearing HELM_CHART_YAML_FILENAME + HELM_VALUES_YAML_FILENAME files as the third leg of the canonical {Chart.yaml, values.yaml, README.md} per-lareira-<nome> chart-directory ChartFile triple the peer HELM_CHART_YAML_FILENAME docstring explicitly acknowledges is the one axis where the substrate-side single-source discipline had not yet landed at the third file. The single source of truth every consumer that names the readme file — the sole caixa-helm production emit site the prior inline "README.md" literal sat at (caixa-helm’s render_chart_for_servico ChartDir assembly’s per-file path axis, the third of the three canonical lareira-<nome> chart-directory files the renderer emits as a bundle, sibling to the metadata-file HELM_CHART_YAML_FILENAME + values-file HELM_VALUES_YAML_FILENAME axes) plus every test-side round-trip navigator that reaches into the rendered ChartDir by the readme filename (two sites: the renders_three_files files-vec- membership pin + the ChartDir::write_to post-write existence pin) — reaches for the same &'static str by construction.

HELM_CHART_TYPE_APPLICATION

Canonical Helm 3 Chart.yaml type field per-chart-kind discriminator scalar-value every rendered lareira-<nome> chart declares. The Helm chart-schema pins the per-chart-kind axis to the closed set {"application", "library"} (see chart-type-doc) — the application chart-kind is Helm’s default install-shape (an application chart that installs into a namespace as a workload + rendered manifests), while the library chart-kind is Helm’s dependency-only shape (a chart authored as a shared-template substrate that can only be consumed as a dependency, never installed directly). Each lareira-<nome> chart the caixa-helm renderer emits declares itself as an application chart because it is the per- Servico install shape a cluster operator’s helm install / helm upgrade per-Servico release cycle materializes — the sibling DEFAULT_LIBRARY_NAME pleme-computeunit chart (the substrate- side library-chart the lareira-<nome> chart depends on for template-shape) carries the sibling library value verbatim in its authored Chart.yaml (out-of-tree at the pleme-io/helmworks repo, so not this crate’s authority).

HELM_CHART_TYPE_LIBRARY

Canonical Helm 3 Chart.yaml type field per-chart-kind discriminator scalar-value the sibling library-chart shape lands on — the second and only other arm of the closed set {"application", "library"} the Helm chart-schema pins the per-chart-kind axis to (see chart-type-doc). The library chart-kind is Helm’s dependency-only install-shape: a chart authored as a shared-template substrate the per-Aplicacao lareira-<nome> application charts depend on for their emitted- object templates (the DEFAULT_LIBRARY_NAME pleme-computeunit chart out-of-tree at pleme-io/helmworks is the substrate’s canonical instance today), and Helm refuses to install it directly (helm install <library-chart> fails with “Error: library charts cannot be installed”) — a chart declaring itself under this scalar-value is only ever consumed as a dependency by a sibling application-typed chart.

HELM_CHART_YAML_FILENAME

Canonical Helm 3 per-chart-directory metadata-file filename every rendered lareira-<nome> chart carries at its top-level directory — the fixed filename Helm’s chart-schema parser (helm dependency build, helm lint, helm template, helm install) looks up by name at the chart-directory root to locate the per-chart HELM_CHART_API_VERSION + HELM_CHART_TYPE_APPLICATION + name/version/dependencies scalars each lareira-<nome> chart declares (see chart-yaml-desc). The single source of truth every consumer that names the metadata file — the sole caixa-helm production emit site the prior inline "Chart.yaml" literal sat at (caixa-helm’s render_chart_for_servico ChartDir assembly’s per-file path axis, one of the three canonical lareira-<nome> chart-directory files the renderer emits as a bundle) plus every test-side round-trip navigator that reaches into the rendered ChartDir by the metadata filename (six sites across caixa-helm’s per-chart-metadata-field sweep tests + [ChartDir::write_to] post-write existence pin) — reaches for the same &'static str by construction.

HELM_VALUES_KEY_ENABLED

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:

HELM_VALUES_YAML_FILENAME

Canonical Helm 3 per-chart-directory values-file filename every rendered lareira-<nome> chart carries at its top-level directory — the fixed filename Helm’s chart-schema parser (helm dependency build, helm lint, helm template, helm install) looks up by name at the chart-directory root to locate the per-chart DEFAULT_LIBRARY_NAME-wrapped values block that HELM_VALUES_KEY_ENABLED toggles (see values-yaml-desc). The single source of truth every consumer that names the values file — the sole caixa-helm production emit site the prior inline "values.yaml" literal sat at (caixa-helm’s render_chart_for_servico ChartDir assembly’s per-file path axis, the second of the three canonical lareira-<nome> chart-directory files the renderer emits as a bundle, sibling to the metadata-file HELM_CHART_YAML_FILENAME axis) plus every test-side round-trip navigator that reaches into the rendered ChartDir by the values filename (eleven sites across caixa-helm’s per-chart-values-field sweep tests + [ChartDir::write_to] post-write existence pin) — reaches for the same &'static str by construction.

KUBE_KEY_API_VERSION

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 API key naming the resource’s kind discriminator (e.g. CiliumNetworkPolicy, Gateway, HTTPRoute, ComputeUnit).

KUBE_KEY_LABELS

Canonical K8s API key naming the resource’s labels (under metadata).

KUBE_KEY_MATCH_LABELS

Canonical K8s API key naming the matchLabels axis of a LabelSelector — the equality-based projection of the selector schema (the other axis, matchExpressions, is set-based and intentionally out-of-scope for the V0 label_selector helper). Spelled exactly as the K8s apiserver expects (camelCase matchLabels, not match_labels / MatchLabels / match-labels) so the rendered YAML round-trips through every K8s schema parser (Cilium CRDs, Gateway API, ComputeUnit, future mesh.pleme.io/v1alpha1/Aplicacao) without per-renderer string drift.

KUBE_KEY_METADATA

Canonical K8s API key naming the resource’s metadata block.

KUBE_KEY_NAME

Canonical K8s API key naming the resource’s name (under metadata).

KUBE_KEY_NAMESPACE

Canonical K8s API key naming the resource’s namespace (under metadata).

KUBE_KEY_PORT

Canonical K8s API key naming the per-CR L4 port scalar axis — the field the apiserver-side OpenAPI schema for every port-carrying CR body-position (Cilium L7 spec.ingress[].toPorts[].ports[].port per-port-tuple L4 port number, Gateway API Gateway.spec.listeners[].port per-listener L4 port number, Gateway API HTTPRoute.spec.rules[].backendRefs[].port per-rule per-backend L4 port number, and every future port-shaped CR body- position the M4 mesh.pleme.io/v1alpha1/Aplicacao materializer + the per-edge CiliumClusterwideEnvoyConfig emitter will land on) mounts the L4 port value under. Spelled exactly as the K8s apiserver expects (lowercase port, not Port / portNumber / portValue / targetPort — the L4-port-number axis, distinct from the targetPort L4-forwarding-destination axis on the K8s Service CRD that lives on a sibling field name the port-value axis is not) so the rendered YAML round-trips through every K8s schema parser without per-renderer string drift.

KUBE_KEY_PROTOCOL

Canonical K8s API key naming the per-CR L4/L7 protocol scalar-discriminator axis — the field the apiserver-side OpenAPI schema for every protocol-carrying CR body-position (Cilium L7 spec.ingress[].toPorts[].ports[].protocol per-port-tuple L4 transport protocol discriminator picking between TCP / UDP / SCTP / ANY, Gateway API Gateway.spec.listeners[].protocol per-listener L7 listener-protocol discriminator picking between HTTP / HTTPS / TCP / TLS / UDP, and every future protocol-shaped CR body-position the M4 mesh.pleme.io/v1alpha1/Aplicacao materializer + the per-edge CiliumClusterwideEnvoyConfig emitter will land on) mounts the protocol-value discriminator under. Spelled exactly as the K8s apiserver expects (lowercase protocol, not Protocol / proto / transportProtocol — the singular scalar-key convention K8s uses across every protocol-carrying CR family, distinct from the protocols[] plural-container axis used on a few application-layer-protocol CRDs which is not this axis) so the rendered YAML round-trips through every K8s schema parser without per-renderer string drift.

KUBE_KEY_RULES

Canonical K8s API key naming the per-CR rules collection axis — the container the apiserver-side OpenAPI schema for every rule-shaped CR (Cilium L7 spec.ingress[].toPorts[].rules, Gateway API HTTPRoute.spec.rules[], RBAC Role.rules[] / ClusterRole.rules[], and every future rule-list-shaped CR the M4 mesh.pleme.io/v1alpha1/Aplicacao materializer + the per-edge CiliumClusterwideEnvoyConfig emitter will land on) mounts the per-CR list of match/action rules under. Spelled exactly as the K8s apiserver expects (lowercase rules, not Rules / rule / ruleset) so the rendered YAML round-trips through every K8s schema parser without per-renderer string drift.

KUBE_KEY_SPEC

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.

KUBE_KEY_TYPE

Canonical K8s API key naming the per-CR discriminated-union type scalar-discriminator axis — the field the apiserver-side OpenAPI schema for every discriminated-union CR body-position (Gateway API v1 HTTPRouteMatch.path.type per-HTTPRouteMatch path-selection-predicate discriminator picking between Exact / PathPrefix / RegularExpression, K8s core Condition.type per-condition kind discriminator, K8s core Volume.<projection>.type per-projection content-source discriminator, and every future discriminated-union CR body-position the M4 mesh.pleme.io/v1alpha1/Aplicacao materializer

KUBE_PROTOCOL_TCP

Canonical K8s core Protocol OpenAPI schema enum’s TCP L4-transport- protocol scalar value every cilium_network_policies-emitted CiliumNetworkPolicy document’s per-spec.ingress[].toPorts[].ports[] port-tuple declares under its per-tuple KUBE_KEY_PROTOCOL axis. Pairs with the sibling KUBE_KEY_PROTOCOL (0307950) per-CR L4/L7 protocol-scalar-discriminator container-axis key the value nests directly under — the K8s core Protocol schema pins per-ContainerPort / ServicePort / EndpointPort / NetworkPolicyPort L4-transport selection through the protocol scalar (each port entry names one L4-transport-protocol discriminator the CNI / kube-proxy / eBPF-data- plane bpf policy dispatch loop keys off before applying the port match; the K8s core Protocol OpenAPI schema enum admits the closed set {"TCP", "UDP", "SCTP"} verbatim — see https://kubernetes.io/docs/reference/generated/kubernetes-api/v1/#protocol-v1-core), so drift on the L4-transport-protocol value is exactly as load-bearing as drift on the sibling GATEWAY_API_PROTOCOL_HTTP (1b57473) per- listener L7-parser-selection scalar value the peer Gateway-API v1 ProtocolType OpenAPI schema enum admits under the same KUBE_KEY_PROTOCOL container-axis key (a "tcp" / "Tcp" / "TCP/IP" / "transport-tcp" typo at the production-code call site lands outside the K8s core Protocol OpenAPI schema enum’s admitted set, surfacing apply-side as a non-self-locating “spec.ingress[0].toPorts[0].ports[0].protocol: Unsupported value: "tcp": supported values: "SCTP", "TCP", "UDP"” apiserver admission-rejection far from the source caixa.lisp / the renderer’s port_entry.insert(…) call site — the rendered per-(:de, :para) CiliumNetworkPolicy object never reconciles at the Cilium operator’s per-CNP L4 dispatch pass and every intra-mesh :contratos L4-tuple- gated flow drops at the Cilium operator’s admission gate with no field naming the L4-transport-protocol-drift root cause; worse — because the protocol scalar carries a schema-side default of TCP on the K8s core Protocol enum, a silently-elided drift on the emit lands a CiliumNetworkPolicy whose ingress rule falls back to the default L4- transport-protocol and every port-match on a non-default transport silently misses at the eBPF data plane’s per-tuple dispatch).

LABEL_APLICACAO

Canonical pleme-io label key naming the Aplicacao the workload belongs to. Together with LABEL_PROGRAM this is the load-bearing identity tuple every per-Aplicacao mesh renderer (Cilium, Gateway, future caixa-otel) keys off — (LABEL_APLICACAO, LABEL_PROGRAM) = the unique workload selector inside one cluster.

LABEL_CONTRATO

Canonical pleme-io label key naming the contrato (the M3 :contratos edge: <de>-to-<para>) a CiliumNetworkPolicy enforces. Carried on the policy’s own labels (not on workload pods) so Hubble + cluster operators can group flows by typed contrato edge, not just by source/destination pod identity.

LABEL_PROGRAM

Canonical pleme-io label key naming the program (i.e. the caixa Servico’s :nome) a pod runs. LABEL_APLICACAO + LABEL_PROGRAM together pick exactly one workload identity in one cluster. Used as the matchLabels axis on every Cilium endpointSelector / fromEndpoints rule and on Gateway API backendRefs selectors emitted by crate’s downstream renderers.

LAREIRA_CHART_KEYWORDS

Canonical substrate-fixed Chart.yaml keywords: entries every rendered lareira-<nome> Helm chart carries — the ordered (BTreeSet-canonical, ascii-alphabetical) list of registry-search tags caixa-helm’s build_chart_yaml unions in on top of the caixa author’s own :etiquetas before folding the joint set into a BTreeSet<String> for the emitted Chart.yaml. Every entry — "caixa-servico" (the substrate-wide per-:kind Servico marker axis), "lareira" (the LAREIRA_CHART_NAME_PREFIX chart-family tag), "tatara-lisp" (the tatara-lisp source-language marker), and "wasm" (the runtime execution-format marker) — is a load-bearing discovery axis for the Artifact Hub keyword-search index and the future caixa-registry keyword axis, so a drift between the production emit at caixa-helm::build_chart_yaml and the two substrate-side positive-set sweep tests ([crate::manifest::tests::validate_etiquetas_accepts_canonical_shaped_forms] and this crate’s own chart_keyword_shape_accepts_canonical_forms) would silently cause every rendered chart to miss the search-index axis the substrate-fixed tag encodes — a chart published without the "caixa-servico" tag would silently drop off the helm search hub caixa-servico results the substrate’s chart discovery pipeline promises. Two production-side call sites (this crate’s is_chart_keyword_shape docstring narrates the four canonical tags verbatim + caixa-helm’s build_chart_yaml unions them into the emitted keywords: sequence) and two test-side positive-sweep sites this array anchors under one source of truth.

LAREIRA_CHART_NAME_NOME_MAX_LEN

The :nome-side budget the lareira_chart_name composition imposes on every caixa :nome reaching a renderer that derives a lareira-<nome> artifact (caixa-helm’s ChartDir.name + Chart.yaml name:, caixa-flux’s cluster_bundle HelmRelease chart: slot, caixa-tatara’s process_for_aplicacao release_name + oci://<registry>/lareira-<nome> chart ref).

LAREIRA_CHART_NAME_PREFIX

Canonical Helm chart-name prefix for every per-Servico chart the substrate emits — the "lareira-" segment of the well-known lareira-<nome> shape every caixa Servico renderer prepends to a caixa’s :nome to derive its Chart.yaml name: field, its OCI artifact reference (oci://<registry>/lareira-<nome>), and the resulting cluster-side HelmRelease release_name. The single source of truth all three downstream Servico renderers consult — caixa-helm’s render_chart_for_servico chart-dir name (caixa-helm/src/lib.rs:207), caixa-flux’s cluster_bundle HelmRelease chart: field (caixa-flux/src/lib.rs:329), and caixa-tatara’s process_for_aplicacao release_name + derive_chart_ref OCI ref (caixa-tatara/src/lib.rs:124,182) — so a future per-chart-name-prefix rebrand (e.g. moving to forno- once lareira- outlives its scoping intent, or any segment-namespace migration the chart-publishing pipeline requires) is a one-line edit here, not a coordinated rewrite across every renderer crate’s chart- name-derivation site.

LAYOUT_DIR_EXE

Canonical caixa-root-relative directory name housing every crate::CaixaKind::Binario caixa’s exe/<name> entry (and every :exe ("exe/tool" …) per-entry source path the M0 :kind Binario typed slot admits). Peer of LAYOUT_DIR_LIB / LAYOUT_DIR_SERVICOS on the sibling M0 per-CaixaKind on-disk-directory-name axes; see LAYOUT_DIR_LIB for the shared lift rationale.

LAYOUT_DIR_LIB

Canonical caixa-root-relative directory name housing every crate::CaixaKind::Biblioteca caixa’s lib/<nome>.lisp entry (and every :bibliotecas ("lib/foo.lisp" …) per-entry source path the M0 :kind Biblioteca typed slot admits). The single source of truth every consumer that composes a caixa-root-relative path pointing at the tatara-lisp library sub-tree reaches for:

LAYOUT_DIR_SERVICOS

Canonical caixa-root-relative directory name housing every crate::CaixaKind::Servico caixa’s servicos/<nome>.computeunit.yaml per-CR ComputeUnit descriptor (and every :servicos ("servicos/foo.computeunit.yaml" …) per-entry source path the M0 :kind Servico typed slot admits). Peer of LAYOUT_DIR_LIB / LAYOUT_DIR_EXE on the sibling M0 per-CaixaKind on-disk-directory-name axes; see LAYOUT_DIR_LIB for the shared lift rationale.

LAYOUT_MISSING_ENTRY_KIND_BEHAVIOR_CALLBACK

Canonical crate::LayoutError::MissingEntry kind: &'static str discriminator scalar the M2 :behavior typed slot’s per-callback on-disk-leaf existence gate surfaces under — the byte-string every crate::LayoutInvariants::verify emission carries when a :behavior :on-init / :on-call / :on-cast / :on-info / :on-state-change / :on-terminate sub-slot’s tatara-lisp source path fails to resolve against the caixa root’s on-disk layout. Names the “M2 :behavior sub-slot leaf-kind” axis one altitude below the M2_AUTHOR_KEY_BEHAVIOR (f49c8b0) parent-slot label: the top-level M2_AUTHOR_KEY_BEHAVIOR const names the M2 slot itself on the author surface ((defcaixa … :behavior (…))), the six [M2_BEHAVIOR_AUTHOR_KEY_ON_*] consts (889dc18) name the per- callback sub-slot labels the author writes ((:on-init "lib/init.lisp" …)), and this const names the per-slot-family leaf-kind byte-string the layout diagnostic emits when the on-disk lib/init.lisp file doesn’t exist (“MissingEntry { kind: "behavior-callback", path: /root/lib/init.lisp }”).

LAYOUT_MISSING_ENTRY_KIND_BIBLIOTECA

Canonical crate::LayoutError::MissingEntry kind: &'static str discriminator scalar the M0 :kind Biblioteca typed slot’s per-:bibliotecas entry on-disk-leaf existence gate surfaces under — the byte-string every crate::LayoutInvariants::verify emission carries when a :bibliotecas ("lib/foo.lisp" …) entry’s tatara-lisp source path fails to resolve against the caixa root’s on-disk layout. Peer of LAYOUT_MISSING_ENTRY_KIND_EXE / LAYOUT_MISSING_ENTRY_KIND_SERVICO on the sibling M0 code-slot per-directory leaf-kind axes, and of the M2-tier LAYOUT_MISSING_ENTRY_KIND_BEHAVIOR_CALLBACK / LAYOUT_MISSING_ENTRY_KIND_UPGRADE_SCRIPT (95c9c4c) leaf-kind labels on the crate::LayoutError::MissingEntry kind: &'static str discriminator’s accept-set — completes the M0-tier arm of the same per-slot leaf-kind categorization axis the M2 lift established.

LAYOUT_MISSING_ENTRY_KIND_EXE

Canonical crate::LayoutError::MissingEntry kind: &'static str discriminator scalar the M0 :kind Binario typed slot’s per-:exe entry on-disk-leaf existence gate surfaces under — the byte-string every crate::LayoutInvariants::verify emission carries when an :exe ("exe/tool.lisp" …) entry’s tatara-lisp source path fails to resolve against the caixa root’s on-disk layout. Peer of LAYOUT_MISSING_ENTRY_KIND_BIBLIOTECA / LAYOUT_MISSING_ENTRY_KIND_SERVICO on the sibling M0 code-slot per-directory leaf-kind axes; see LAYOUT_MISSING_ENTRY_KIND_BIBLIOTECA for the shared lift rationale.

LAYOUT_MISSING_ENTRY_KIND_SERVICO

Canonical crate::LayoutError::MissingEntry kind: &'static str discriminator scalar the M0 :kind Servico typed slot’s per-:servicos entry on-disk-leaf existence gate surfaces under — the byte-string every crate::LayoutInvariants::verify emission carries when a :servicos ("servicos/foo.computeunit.yaml" …) entry fails to resolve against the caixa root’s on-disk layout. Peer of LAYOUT_MISSING_ENTRY_KIND_BIBLIOTECA / LAYOUT_MISSING_ENTRY_KIND_EXE on the sibling M0 code-slot per-directory leaf-kind axes; see LAYOUT_MISSING_ENTRY_KIND_BIBLIOTECA for the shared lift rationale. Byte-identical to crate::CaixaKind::Servico’s crate::CaixaKind::as_str output today (both resolve to the same seven-byte "servico" scalar).

LAYOUT_MISSING_ENTRY_KIND_UPGRADE_SCRIPT

Canonical crate::LayoutError::MissingEntry kind: &'static str discriminator scalar the M2 :upgrade-from typed slot’s per-entry crate::UpgradeInstruction::StateChange script-path on-disk-leaf existence gate surfaces under — the byte-string every crate::LayoutInvariants::verify emission carries when a (:state-change "<script>.lisp") instruction’s tatara-lisp source path fails to resolve against the caixa root’s on-disk layout. Peer of LAYOUT_MISSING_ENTRY_KIND_BEHAVIOR_CALLBACK on the sibling M2 :behavior typed slot’s per-callback leaf-kind axis; see LAYOUT_MISSING_ENTRY_KIND_BEHAVIOR_CALLBACK for the full lift rationale.

LISP_SOURCE_EXTENSION

The canonical tatara-lisp source-file extension every M2 typed path-slot the M2.5 wasm-engine instantiator reads through tatara_lisp::read at instance-start time must terminate in.

M2_AUTHOR_KEY_BEHAVIOR

Canonical author-facing kebab-case (defcaixa … :behavior (…)) top-level slot label the M2 per-Servico OTP-shaped :behavior gen_server-callback-set slot surfaces under. Peer of M2_AUTHOR_KEY_LIMITS on the sibling M2 top-level slot dual axis; see M2_AUTHOR_KEY_LIMITS for the full lift rationale.

M2_AUTHOR_KEY_LIMITS

Canonical author-facing kebab-case (defcaixa … :limits (…)) top-level slot label the M2 per-Servico Lunatic sandbox :limits slot surfaces under. Peer of M2_KEY_LIMITS on the dual-axis pair every M2 top-level slot carries: the camelCase [M2_KEY_*] const names the renderer-side overlay-container wire key the serde-derive-emitted programs.yaml / values.yaml block carries under ("limits", load-bearing per the #[serde(rename_all = "camelCase")] attribute on the emit-side servico_m2_overlay shape), the kebab-case [M2_AUTHOR_KEY_*] const names the author-facing label the crate::Caixa::declared_servico_slots tagger threads through as one of the &'static str entries in the canonical-declaration-order slot list every kind-coherence gate consults (crate::LayoutError::ServicoSlotsOnNonServico joins them into the space-separated slots: diagnostic naming which of the three M2 slots the offending caixa declared on a non-Servico kind).

M2_AUTHOR_KEY_UPGRADE_FROM

Canonical author-facing kebab-case (defcaixa … :upgrade-from (…)) top-level slot label the M2 per-Servico OTP-appup :upgrade-from hot-code-reload table slot surfaces under. Peer of M2_AUTHOR_KEY_LIMITS on the sibling M2 top-level slot dual axis; see M2_AUTHOR_KEY_LIMITS for the full lift rationale.

M2_BEHAVIOR_AUTHOR_KEY_ON_CALL

Canonical author-facing kebab-case (defcaixa … :behavior (:on-call …)) slot label for the :behavior :on-call per-Servico OTP-shaped synchronous request/response handler axis. Peer of M2_BEHAVIOR_AUTHOR_KEY_ON_INIT on the sibling :behavior sub-slot author-facing-label axis.

M2_BEHAVIOR_AUTHOR_KEY_ON_CAST

Canonical author-facing kebab-case (defcaixa … :behavior (:on-cast …)) slot label for the :behavior :on-cast per-Servico OTP-shaped asynchronous fire-and-forget handler axis. Peer of M2_BEHAVIOR_AUTHOR_KEY_ON_INIT on the sibling :behavior sub-slot author-facing-label axis.

M2_BEHAVIOR_AUTHOR_KEY_ON_INFO

Canonical author-facing kebab-case (defcaixa … :behavior (:on-info …)) slot label for the :behavior :on-info per-Servico OTP-shaped out-of-band message handler axis. Peer of M2_BEHAVIOR_AUTHOR_KEY_ON_INIT on the sibling :behavior sub-slot author-facing-label axis.

M2_BEHAVIOR_AUTHOR_KEY_ON_INIT

Canonical author-facing kebab-case (defcaixa … :behavior (:on-init …)) slot label the :behavior :on-init per-Servico OTP-shaped instance-init callback axis surfaces under. Peer of M2_BEHAVIOR_KEY_ON_INIT on the dual-axis pair every M2 :behavior sub-slot carries: the camelCase [M2_BEHAVIOR_KEY_ON_*] const names the renderer-side wire key the serde-derive-emitted M2_KEY_BEHAVIOR overlay carries under ("onInit" etc, load-bearing per the #[serde(rename_all = "camelCase")] attribute on crate::BehaviorSpec), the kebab-case [M2_BEHAVIOR_AUTHOR_KEY_ON_*] const names the author-facing label the crate::BehaviorSpec::declared_slots tagger threads through as the slot: &'static str field on every crate::BehaviorError variant (":on-init" etc, the exact byte-string authors see in the per-slot value-shape diagnostic naming which of the six typed callback slots the offending path landed on).

M2_BEHAVIOR_AUTHOR_KEY_ON_STATE_CHANGE

Canonical author-facing kebab-case (defcaixa … :behavior (:on-state-change …)) slot label for the :behavior :on-state-change per-Servico OTP-shaped hot-upgrade state-migration axis. Peer of M2_BEHAVIOR_AUTHOR_KEY_ON_INIT on the sibling :behavior sub-slot author-facing-label axis; the kebab-case shape (":on-state-change", not ":on-statechange" / ":on_state_change") is load-bearing per the author-facing (defcaixa …) macro’s canonical form and the exact byte-string the per-slot crate::BehaviorError diagnostic threads through.

M2_BEHAVIOR_AUTHOR_KEY_ON_TERMINATE

Canonical author-facing kebab-case (defcaixa … :behavior (:on-terminate …)) slot label for the :behavior :on-terminate per-Servico OTP-shaped graceful-shutdown callback axis. Peer of M2_BEHAVIOR_AUTHOR_KEY_ON_INIT on the sibling :behavior sub-slot author-facing-label axis.

M2_BEHAVIOR_KEY_ON_CALL

Canonical camelCase YAML sub-key the :behavior :on-call per-Servico OTP-shaped sync-request-handler path scalar-axis lands under inside the M2_KEY_BEHAVIOR overlay block. Peer of M2_BEHAVIOR_KEY_ON_INIT on the sibling :behavior sub-slot axis.

M2_BEHAVIOR_KEY_ON_CAST

Canonical camelCase YAML sub-key the :behavior :on-cast per-Servico OTP-shaped async-fire-and-forget-handler path scalar-axis lands under inside the M2_KEY_BEHAVIOR overlay block. Peer of M2_BEHAVIOR_KEY_ON_INIT on the sibling :behavior sub-slot axis.

M2_BEHAVIOR_KEY_ON_INFO

Canonical camelCase YAML sub-key the :behavior :on-info per-Servico OTP-shaped out-of-band-message-handler path scalar-axis lands under inside the M2_KEY_BEHAVIOR overlay block. Peer of M2_BEHAVIOR_KEY_ON_INIT on the sibling :behavior sub-slot axis.

M2_BEHAVIOR_KEY_ON_INIT

Canonical camelCase YAML sub-key the :behavior :on-init per-Servico OTP-shaped instance-init-callback path scalar-axis lands under inside the M2_KEY_BEHAVIOR overlay block. Peer of M2_KEY_BEHAVIOR on the sibling :behavior sub-slot axis: M2_KEY_BEHAVIOR names the overlay-container’s top-level key (“behavior”), the six M2_BEHAVIOR_KEY_ON_* consts name the six typed sub-keys the M2 crate::BehaviorSpec struct’s OTP-shaped callback fields (on_init / on_call / on_cast / on_info / on_state_change / on_terminate, analogs of gen_server:init/1 / handle_call/3 / handle_cast/2 / handle_info/2 / code_change/3 / terminate/2 per theory/INSPIRATIONS.md §II.3) serialize as under the #[serde(rename_all = "camelCase")] derive attribute ("onInit" / "onCall" / "onCast" / "onInfo" / "onStateChange" / "onTerminate"). Emitted by servico_m2_overlay as sub-keys of the M2_KEY_BEHAVIOR overlay block and consumed by every substrate-side test-side navigator that reaches into the rendered programs.yaml per-Servico entry / lareira chart values.yaml per-pleme-computeunit block to pin the per-callback round-trip. The lower-camel shape is load-bearing: the serde-derive on crate::BehaviorSpec emits under the same shape and the drift-detection pin in behavior.rs::tests (behavior_spec_serde_keys_match_lifted_m2_behavior_key_consts) serializes a fully-populated crate::BehaviorSpec and asserts each canonical M2_BEHAVIOR_KEY_ON_* byte-sequence appears in the JSON — so a hypothetical future rename_all = "snake_case" / "kebab-case" accident at the derive attribute or an OTP-lineage per-callback rebrand (:on-init → :on-start matching Akka’s per-actor preStart naming, :on-call → :on-request matching a hypothetical wasi:http/incoming-handler terminology flip, :on-state-change → :on-code-change matching Erlang’s verbatim code_change/3 name) coordinated at the type’s derive attribute surfaces as a build-time test failure at behavior.rs rather than as a silent test-side .get(<stale-camelCase-const>) returning None far from the derive-attr drift’s commit. Same “one canonical byte-string per typed axis” discipline every peer M2 / M3 wire-key axis carries (M2_KEY_LIMITS / M2_KEY_BEHAVIOR / M2_KEY_UPGRADE_FROM, M2_LIMITS_KEY_MEMORY / M2_LIMITS_KEY_FUEL / M2_LIMITS_KEY_WALL_CLOCK / M2_LIMITS_KEY_CPU (d8b8b4f), M3_PLACEMENT_KEY_ESTRATEGIA etc.).

M2_BEHAVIOR_KEY_ON_STATE_CHANGE

Canonical camelCase YAML sub-key the :behavior :on-state-change per-Servico OTP-shaped hot-upgrade state-migration path scalar-axis lands under inside the M2_KEY_BEHAVIOR overlay block. Peer of M2_BEHAVIOR_KEY_ON_INIT on the sibling :behavior sub-slot axis; the camelCase shape ("onStateChange", not "on_state_change") is load-bearing per the serde-derive attribute on crate::BehaviorSpec.

M2_BEHAVIOR_KEY_ON_TERMINATE

Canonical camelCase YAML sub-key the :behavior :on-terminate per-Servico OTP-shaped graceful-shutdown-callback path scalar-axis lands under inside the M2_KEY_BEHAVIOR overlay block. Peer of M2_BEHAVIOR_KEY_ON_INIT on the sibling :behavior sub-slot axis.

M2_KEY_BEHAVIOR

Canonical camelCase YAML key for the :behavior slot’s overlay.

M2_KEY_LIMITS

Canonical camelCase YAML key for the :limits slot’s overlay.

M2_KEY_UPGRADE_FROM

Canonical camelCase YAML key for the :upgrade-from slot’s overlay.

M2_LIMITS_KEY_CPU

Canonical camelCase YAML sub-key the :limits :cpu per-Servico soft-cgroup-CPU-share millicores scalar-axis lands under inside the M2_KEY_LIMITS overlay block. Peer of M2_LIMITS_KEY_MEMORY on the sibling :limits sub-slot axis.

M2_LIMITS_KEY_FUEL

Canonical camelCase YAML sub-key the :limits :fuel per-Servico wasm-instruction-budget scalar-axis lands under inside the M2_KEY_LIMITS overlay block. Peer of M2_LIMITS_KEY_MEMORY on the sibling :limits sub-slot axis.

M2_LIMITS_KEY_MEMORY

Canonical camelCase YAML sub-key the :limits :memory per-Servico linear-memory-cap scalar-axis lands under inside the M2_KEY_LIMITS overlay block. Peer of M2_KEY_LIMITS on the sibling :limits sub-slot axis: M2_KEY_LIMITS names the overlay-container’s top-level key (“limits”), the four M2_LIMITS_KEY_* consts name the four typed sub-keys ([LIMITS_MEMORY_WASM32_MAX_BYTES]-bounded memory cap, crate::LIMITS_FUEL_MAX-bounded fuel budget, crate::LIMITS_WALL_CLOCK_MAX-bounded wall-clock cap, crate::LIMITS_CPU_MILLICORES_MAX-bounded soft cgroup CPU share) that the emit-side servico_m2_overlay serializes through serde (LimitsSpec carries #[serde(rename_all = "camelCase")]) and every substrate-side test-side navigator probes to pin the round-trip through the rendered programs.yaml per-Servico entry / lareira chart values.yaml per-pleme-computeunit block. The lower-camel shape ("memory" / "fuel" / "wallClock" / "cpu") is load-bearing: the serde-derive on crate::LimitsSpec emits under the same shape and the drift-detection pin in limits.rs::tests (limits_spec_serde_keys_match_lifted_m2_limits_key_consts) serializes a fully-populated crate::LimitsSpec and asserts each canonical M2_LIMITS_KEY_* byte-sequence appears in the JSON — so a hypothetical future rename_all = "snake_case" / "kebab-case" accident at the derive attribute surfaces as a build-time test failure at limits.rs rather than as a silent test-side .get(<stale-camelCase-const>) returning None far from the derive-attr drift’s commit. Same “one canonical byte-string per typed axis” discipline every peer M2 / M3 wire-key axis carries (M2_KEY_LIMITS / M2_KEY_BEHAVIOR / M2_KEY_UPGRADE_FROM, M3_PLACEMENT_KEY_ESTRATEGIA etc.).

M2_LIMITS_KEY_WALL_CLOCK

Canonical camelCase YAML sub-key the :limits :wall-clock per-Servico wall-clock-cap scalar-axis lands under inside the M2_KEY_LIMITS overlay block. Peer of M2_LIMITS_KEY_MEMORY on the sibling :limits sub-slot axis; the camelCase shape ("wallClock", not "wall_clock") is load-bearing per the serde-derive attribute on crate::LimitsSpec.

M2_UPGRADE_FROM_KEY_FROM

Canonical camelCase YAML sub-key the :upgrade-from :from per-entry OTP-appup-shaped prior-:versao semver-string scalar-axis lands under inside each element of the M2_KEY_UPGRADE_FROM overlay sequence. Peer of M2_KEY_UPGRADE_FROM on the sibling :upgrade-from sub-slot axis: M2_KEY_UPGRADE_FROM names the overlay-container’s top-level key (“upgradeFrom”), the two M2_UPGRADE_FROM_KEY_* consts name the two typed sub-keys the M2 crate::UpgradeFromEntry struct’s OTP-appup-shaped per-entry fields (from semver-of-the-prior-:versao / instructions typed crate::UpgradeInstruction list, analogs of the OTP .appup file’s {FromVsn, [Instruction, …]} per-entry tuple per theory/INSPIRATIONS.md §II.4) serialize as under the #[serde(rename_all = "camelCase")] derive attribute ("from" / "instructions"). Emitted by servico_m2_overlay as sub-keys of each element of the M2_KEY_UPGRADE_FROM overlay sequence and consumed by every substrate-side test-side navigator that reaches into the rendered programs.yaml per-Servico entry / lareira chart values.yaml per-pleme-computeunit block to pin the per-entry round-trip. The lower-camel shape ("from" / "instructions") is load-bearing: the serde-derive on crate::UpgradeFromEntry emits under the same shape and the drift-detection pin in upgrade.rs::tests (upgrade_from_entry_serde_keys_match_lifted_m2_upgrade_from_key_consts) serializes a fully-populated crate::UpgradeFromEntry and asserts each canonical M2_UPGRADE_FROM_KEY_* byte-sequence appears in the JSON — so a hypothetical future rename_all = "snake_case" / "kebab-case" accident at the derive attribute or an OTP-lineage per-entry-key rebrand (:from → :prior-versao matching a hypothetical verbatim-Erlang FromVsn collapse, :instructions → :steps matching a hypothetical Akka appup-shape rebrand) coordinated at the type’s derive attribute surfaces as a build-time test failure at upgrade.rs rather than as a silent test-side .get(<stale-camelCase-const>) returning None far from the derive-attr drift’s commit. Same “one canonical byte-string per typed axis” discipline every peer M2 / M3 wire-key axis carries (M2_KEY_LIMITS / M2_KEY_BEHAVIOR / M2_KEY_UPGRADE_FROM, M2_LIMITS_KEY_MEMORY / M2_LIMITS_KEY_FUEL / M2_LIMITS_KEY_WALL_CLOCK / M2_LIMITS_KEY_CPU (d8b8b4f), M2_BEHAVIOR_KEY_ON_INIT / M2_BEHAVIOR_KEY_ON_CALL / M2_BEHAVIOR_KEY_ON_CAST / M2_BEHAVIOR_KEY_ON_INFO / M2_BEHAVIOR_KEY_ON_STATE_CHANGE / M2_BEHAVIOR_KEY_ON_TERMINATE (21fe462), M3_PLACEMENT_KEY_ESTRATEGIA etc.). Closes the M2 sub-slot camelCase key axis: with this lift the three M2 typed slots (:limits / :behavior / :upgrade-from) all have their canonical camelCase sub-slot key constants pinned into caixa-core.

M2_UPGRADE_FROM_KEY_INSTRUCTIONS

Canonical camelCase YAML sub-key the :upgrade-from :instructions per-entry OTP-appup-shaped typed crate::UpgradeInstruction list axis lands under inside each element of the M2_KEY_UPGRADE_FROM overlay sequence. Peer of M2_UPGRADE_FROM_KEY_FROM on the sibling :upgrade-from sub-slot axis.

M2_UPGRADE_INSTRUCTION_FIELD_KEY_MODULE

Canonical per-variant data-field JSON key the M2 :upgrade-from :instructions per-entry OTP-appup crate::UpgradeInstruction::LoadModule / crate::UpgradeInstruction::SoftPurge / crate::UpgradeInstruction::Purge variants surface their module-name payload under on serde emission — the internally-tagged per-variant field byte-string every downstream consumer reading the module string reaches for (serde_json::to_value(&instr).get("module") / serde_yaml::Value::Mapping.get("module") / hand-authored {"kind": "load-module", "module": "hello-rio"} JSON blobs the wasm-operator’s upgrade-dispatch step consumes to route the per-module load / soft-purge / purge action). The three variants carrying a module: String field (crate::UpgradeInstruction::LoadModule, crate::UpgradeInstruction::SoftPurge, crate::UpgradeInstruction::Purge) all emit this exact byte-sequence as the data-field JSON key alongside the M2_UPGRADE_INSTRUCTION_KEY_KIND tag-key on the same instruction blob — the #[serde(tag = "kind", rename_all = "kebab-case")] attribute on crate::UpgradeInstruction promotes each variant’s struct-field name to a sibling JSON key at the same nesting level as the tag, so a LoadModule { module: "hello-rio" } serializes to {"kind": "load-module", "module": "hello-rio"} — one tag axis, one data-field axis, both live on the same JSON object and both must be pinned into caixa-core so a future rebrand at either axis surfaces as a build-time test failure rather than an apply-time .get(<stale-field-key>) returning None far from the field-name drift’s commit.

M2_UPGRADE_INSTRUCTION_FIELD_KEY_SCRIPT

Canonical per-variant data-field JSON key the M2 :upgrade-from :instructions per-entry crate::UpgradeInstruction::StateChange variant surfaces its script-path payload under on serde emission — the internally-tagged per-variant field byte-string every downstream consumer reading the migration-script path reaches for (serde_json::to_value(&instr).get("script") / serde_yaml::Value::Mapping.get("script") / hand-authored {"kind": "state-change", "script": "lib/migrations/v01-to-v02.lisp"} JSON blobs the wasm-operator’s upgrade-dispatch step consumes to route the per-gen_server code_change/3 migration action). Peer of M2_UPGRADE_INSTRUCTION_FIELD_KEY_MODULE on the sibling module-payload axis; see M2_UPGRADE_INSTRUCTION_FIELD_KEY_MODULE for the full lift rationale.

M2_UPGRADE_INSTRUCTION_KEY_KIND

Canonical #[serde(tag = "…")] discriminator-key byte-sequence the M2 :upgrade-from :instructions per-entry OTP-appup crate::UpgradeInstruction enum surfaces its variant tag under on serde emission — the internally-tagged wire key downstream consumers navigate to (serde_json::to_value(&instr).get("kind") / serde_yaml::Value::Mapping.get("kind") / hand-authored {"kind": "load-module", "module": "…"} JSON) to disambiguate which of the five OTP-shaped variants they hold. The #[serde(tag = "kind", rename_all = "kebab-case")] attribute on crate::UpgradeInstruction emits exactly this byte-sequence as the tag-slot key, and this const names the same byte-string one altitude above the derive attribute so every downstream consumer that reaches for the tag (the reflection-vs-serde round-trip check in [caixa-core/tests/dispatcher_registration.rs] that probes v.get("kind") against every variant’s expected kebab-case tag, the future M4 mesh.pleme.io/v1alpha1/Caixa CR materializer’s upgrade-instruction admission webhook, any wasm-operator dispatch step that navigates the serialized instruction blob to route by variant) routes through one canonical &'static str rather than re-inlining the literal.

M2_UPGRADE_INSTRUCTION_KIND_LOAD_MODULE

Canonical author-facing kebab-case tag the M2 :upgrade-from :instructions per-entry OTP-appup crate::UpgradeInstruction::LoadModule variant surfaces under — the :kind field the crate::UpgradeError::ModuleEmpty / crate::UpgradeError::ModuleInvalid / crate::UpgradeError::DuplicateCleanup / crate::UpgradeError::PurgeWithoutPriorLoad diagnostics carry so the author can grep their caixa.lisp for (:load-module …) and fix it in one edit. The crate::UpgradeInstruction::lisp_form production dispatch and every test-side probe that pins a kind: / kinds: / other_kinds: / prior_cleanup_kind: field routes through this const, so a future per-variant kebab-case rebrand (:load-module → :load matching a hypothetical Erlang code:load_module collapse, :load-module → :reload matching a hypothetical Elixir/Phoenix hot-reload rebrand, or a per-consumer disambiguation as the defcaixa macro stabilizes) lands at one const-edit per arm and reaches both surfaces (production dispatch + tests) by construction. Peer of M2_UPGRADE_FROM_KEY_FROM / M2_UPGRADE_FROM_KEY_INSTRUCTIONS on the sibling :upgrade-from sub-slot renderer-wire-key axis (36ffe65) — this const family extends the same “one canonical byte-string per typed axis” discipline onto the author-facing per-instruction-variant tag axis one altitude below the :instructions container. Same “one canonical declaration per arm, next to the axis” discipline the peer M2_BEHAVIOR_AUTHOR_KEY_ON_INIT etc. (889dc18) established for the M2 :behavior sub-slot’s per-callback kebab-case labels, CONTRATO_AUTHOR_KEY_DE / CONTRATO_AUTHOR_KEY_PARA (f50c875) for the M3 :contratos per-entry endpoint labels, and every top-level M2_AUTHOR_KEY_LIMITS (f49c8b0) / M3_AUTHOR_KEY_MEMBROS (882f498) / SUPERVISOR_AUTHOR_KEY_ESTRATEGIA (be40492) family established.

M2_UPGRADE_INSTRUCTION_KIND_PURGE

Canonical author-facing kebab-case tag the M2 :upgrade-from :instructions per-entry crate::UpgradeInstruction::Purge variant surfaces under. Peer of M2_UPGRADE_INSTRUCTION_KIND_LOAD_MODULE on the sibling per-instruction-variant tag axis; see M2_UPGRADE_INSTRUCTION_KIND_LOAD_MODULE for the full lift rationale.

M2_UPGRADE_INSTRUCTION_KIND_RESTART

Canonical author-facing kebab-case tag the M2 :upgrade-from :instructions per-entry crate::UpgradeInstruction::Restart variant surfaces under. Peer of M2_UPGRADE_INSTRUCTION_KIND_LOAD_MODULE on the sibling per-instruction-variant tag axis; see M2_UPGRADE_INSTRUCTION_KIND_LOAD_MODULE for the full lift rationale.

M2_UPGRADE_INSTRUCTION_KIND_SOFT_PURGE

Canonical author-facing kebab-case tag the M2 :upgrade-from :instructions per-entry crate::UpgradeInstruction::SoftPurge variant surfaces under. Peer of M2_UPGRADE_INSTRUCTION_KIND_LOAD_MODULE on the sibling per-instruction-variant tag axis; see M2_UPGRADE_INSTRUCTION_KIND_LOAD_MODULE for the full lift rationale.

M2_UPGRADE_INSTRUCTION_KIND_STATE_CHANGE

Canonical author-facing kebab-case tag the M2 :upgrade-from :instructions per-entry crate::UpgradeInstruction::StateChange variant surfaces under. Peer of M2_UPGRADE_INSTRUCTION_KIND_LOAD_MODULE on the sibling per-instruction-variant tag axis; see M2_UPGRADE_INSTRUCTION_KIND_LOAD_MODULE for the full lift rationale.

M3_AUTHOR_KEY_CONTRATOS

Canonical author-facing kebab-case (defcaixa … :contratos (…)) top-level mesh slot label the M3 Aplicacao’s WIT-typed inter-Servico edge set surfaces under. Peer of M3_AUTHOR_KEY_MEMBROS on the sibling M3 top-level mesh-slot dual axis; see M3_AUTHOR_KEY_MEMBROS for the full lift rationale.

M3_AUTHOR_KEY_ENTRADA

Canonical author-facing kebab-case (defcaixa … :entrada (…)) top-level mesh slot label the M3 Aplicacao’s external-ingress gateway surface (crate::aplicacao::Entrada: :host, :para, :paths, :port) surfaces under. Peer of M3_AUTHOR_KEY_MEMBROS on the sibling M3 top-level mesh-slot dual axis; see M3_AUTHOR_KEY_MEMBROS for the full lift rationale.

M3_AUTHOR_KEY_MEMBROS

Canonical author-facing kebab-case (defcaixa … :membros (…)) top-level mesh slot label the M3 Aplicacao’s constituent-Servico set surfaces under. Peer of the four sibling M3 top-level mesh-slot labels (M3_AUTHOR_KEY_CONTRATOS, M3_AUTHOR_KEY_POLITICAS, M3_AUTHOR_KEY_PLACEMENT, M3_AUTHOR_KEY_ENTRADA) on the dual-axis pair every M3 top-level mesh slot carries: the author-facing kebab-case [M3_AUTHOR_KEY_*] const names the label the crate::Caixa::declared_mesh_slots tagger threads through as one of the &'static str entries in the canonical-declaration-order slot list the kind-coherence gate (crate::LayoutError::MeshSlotsOnNonAplicacao) joins into the space-separated slots: diagnostic naming which of the five mesh slots the offending caixa declared on a non-Aplicacao kind. Peer of the M3_KEY_PLACEMENT renderer-side wire-key const declared immediately above on the sole M3 mesh slot the renderer surfaces as a per-entry overlay-container key (:membros / :contratos / :politicas / :entrada render as per-arm derived artifacts — programs.yaml fan-out, CiliumNetworkPolicies, per-edge overlays, Gateway/HTTPRoute — not as a single overlay-container key).

M3_AUTHOR_KEY_PLACEMENT

Canonical author-facing kebab-case (defcaixa … :placement (…)) top-level mesh slot label the M3 Aplicacao’s cross-cluster distribution strategy (crate::aplicacao::Placement: :estrategia + :clusters + :shard-key / :affinity) surfaces under. Peer of M3_AUTHOR_KEY_MEMBROS on the sibling M3 top-level mesh-slot dual axis; see M3_AUTHOR_KEY_MEMBROS for the full lift rationale. Byte-identical to the peer M3_KEY_PLACEMENT renderer-side wire key modulo the leading : — the two consts split on the axis every M3 top-level slot carries (author-facing kebab-case label vs. renderer-side camelCase overlay key), the same split the M2_AUTHOR_KEY_LIMITS / M2_KEY_LIMITS peer pair established on the sibling M2 axis.

M3_AUTHOR_KEY_POLITICAS

Canonical author-facing kebab-case (defcaixa … :politicas (…)) top-level mesh slot label the M3 Aplicacao’s mesh-level policy overlay (crate::aplicacao::MeshPolicy: :timeout, :retries, :circuit-breaker, :mtls-required, :rate-limit) surfaces under. Peer of M3_AUTHOR_KEY_MEMBROS on the sibling M3 top-level mesh-slot dual axis; see M3_AUTHOR_KEY_MEMBROS for the full lift rationale.

M3_KEY_PLACEMENT

Canonical YAML key for the M3 :placement slot’s overlay on a rendered programs.yaml entry. The lareira-fleet-programs aggregator (and the future app-operator per-Aplicacao reconciler) both key off this exact spelling to filter entries by placement.clusters for cross-cluster fanout (MESH-COMPOSITION §III.4) and to dispatch on placement.estrategia for distributed-app takeover semantics (§II.1, §V cross-cluster federation). Lifted as a const alongside the M2 keys so the Aplicacao-side renderer (crate::aplicacao::Placement → caixa-mesh programs_for_aplicacao) and every consumer (the M4 cluster-fanout renderer, the future mesh.pleme.io/v1alpha1/Aplicacao CR materializer, the app-operator’s placement-strategy dispatcher) spell the same key exactly the same way — drift here = a programs.yaml entry whose placement is silently dropped at the aggregator’s filter step (visible only as “the workload doesn’t land where the typed slot said it should”).

M3_PLACEMENT_ESTRATEGIA_REPLICATED

Canonical M3 crate::aplicacao::PlacementStrategy::Replicated variant discriminator scalar-value — the exact byte-string the Serialize derive on the un-renamed enum emits under M3_PLACEMENT_KEY_ESTRATEGIA whenever the typed slot’s distribution strategy is the every-cluster-active-active arm (the enum’s default() and the canonical happy-path per MESH-COMPOSITION.md §II.1).

M3_PLACEMENT_ESTRATEGIA_SHARDED

Canonical M3 crate::aplicacao::PlacementStrategy::Sharded variant discriminator scalar-value — the exact byte-string the Serialize derive on the un-renamed enum emits under M3_PLACEMENT_KEY_ESTRATEGIA whenever the typed slot’s distribution strategy is the hash-keyed-across-clusters arm (Akka cluster sharding, MESH-COMPOSITION.md §II.4). The one arm on which the typed M3_PLACEMENT_KEY_SHARD_KEY sub-block is required — AplicacaoSpec::validate_placement gates shard_key.is_some() == matches!(estrategia, Sharded) as a structural partition of every validated crate::aplicacao::Placement.

M3_PLACEMENT_ESTRATEGIA_SINGLE_NODE

Canonical M3 crate::aplicacao::PlacementStrategy::SingleNode variant discriminator scalar-value — the exact byte-string the Serialize derive on the un-renamed enum emits under M3_PLACEMENT_KEY_ESTRATEGIA whenever the typed slot’s distribution strategy is the single-cluster-active-at-a-time arm (OTP distributed-application takeover, MESH-COMPOSITION.md §II.1).

M3_PLACEMENT_KEY_AFFINITY

Canonical camelCase YAML sub-key for the crate::aplicacao::Placement struct’s affinity placement-engine-hint axis — the per-M3_KEY_PLACEMENT- block optional field carrying the validated non-empty affinity hint (per crate::aplicacao::AplicacaoSpec::validate_placement) that every downstream placement-hint consumer weights off:

M3_PLACEMENT_KEY_CLUSTERS

Canonical camelCase YAML sub-key for the crate::aplicacao::Placement struct’s clusters cluster-pool axis — the per-M3_KEY_PLACEMENT-block field carrying the validated cluster-list (non-empty + duplicate-free per crate::aplicacao::AplicacaoSpec::validate_placement) that every downstream cross-cluster consumer filters off:

M3_PLACEMENT_KEY_ESTRATEGIA

Canonical camelCase YAML sub-key for the crate::aplicacao::Placement struct’s estrategia distribution-strategy discriminator — the per-M3_KEY_PLACEMENT-block field the M3 crate::aplicacao::PlacementStrategy enum’s Serialize derive emits, and the exact scalar every downstream consumer dispatches on:

M3_PLACEMENT_KEY_SHARD_KEY

Canonical camelCase YAML sub-key for the crate::aplicacao::Placement struct’s shard_key shard-selection-template axis — the per-M3_KEY_PLACEMENT- block optional field carrying the validated non-empty shard-key template (per crate::aplicacao::AplicacaoSpec::validate_placement’s ShardedKeyEmpty arm — the build rejects any :placement Sharded that omits the slot, and rejects any non-Sharded strategy that carries the slot as ShardKeyOnNonSharded) that every downstream shard-dispatch consumer materializes off:

MEMBRO_KEY_CAIXA

Canonical camelCase JSON/YAML top-level key for the crate::aplicacao::Membro struct’s caixa per-entry-name-of-the- member-Servico axis — the caixa: field the M3 Aplicacao’s #[serde(rename_all = "camelCase")] derive on crate::aplicacao::Membro emits at each :membros entry, and the exact scalar every downstream #[serde(rename_all = "camelCase")] derive on crate::aplicacao::Membro emits at each :membros entry, and the exact scalar every downstream consumer reaching for the member’s crate::Caixa::nome via Value::get(...) (the future wasm-operator’s per-:membros resolver, the M4 mesh.pleme.io/v1alpha1/Aplicacao CR materializer’s admission webhook, the feira app graph verb’s per-member name-lookup, the [caixa_resolver] per-:membros git-clone step) must probe on.

MEMBRO_KEY_VERSAO

Canonical camelCase JSON/YAML top-level key for the crate::aplicacao::Membro struct’s versao per-entry-semver- constraint-of-the-member axis. Peer of MEMBRO_KEY_CAIXA on the same crate::aplicacao::Membro per-entry serialized-key axis; see MEMBRO_KEY_CAIXA for the full lift rationale. The Rust field is lowercase versao; #[serde(rename_all = "camelCase")] is a no-op on this axis and the emitted key equals the source-side field name byte-for-byte.

NATS_SUBJECT_MAX_LEN

Max length, in bytes, of a single typed :contratos :subject NATS subject passing the is_nats_subject predicate. 256 bytes — matches the upstream NATS Java client’s MAX_SUBJECT_LENGTH constant and sits well above the longest legitimate subject the caixa-mesh test fixtures + example checkout-aplicacao carry ("checkout.events.charge.failed" = 30 bytes, "rio.events.order.charged" = 25 bytes). The cap exists to reject the paste-from-binary footgun (a multi-line blob accidentally landed in the :subject slot) rather than to constrain legitimate authoring. Lifted as a typed const so a future axis reaching for the same bound (the M4 mesh.pleme.io/v1alpha1/Aplicacao CR materializer’s per-subject validator, the future NATS Stream/Consumer CR emitter for the nats:pub-sub branch of :contratos, the future per-edge :politicas-derived NATS-aware policy overlay) reads from one place.

OCI_SCHEME_PREFIX

Canonical OCI URL scheme prefix — the "oci://" byte-string every substrate-side renderer that composes an OCI artifact reference for a Helm chart prepends. The Helm 3 OCI storage protocol (Helm 3.8+) and the FluxCD HelmRepository type: oci source both key off this literal — helm pull / helm install / helm registry login / FluxCD’s source-controller all reject any other scheme on the OCI path — so a byte-shape drift on this prefix silently splits the substrate’s published chart references from the cluster-side resolvers that consume them at helm registry / FluxCD reconcile time far from the source renderer.

PLEME_LABEL_PREFIX

Canonical pleme-io label namespace prefix. Every cluster object emitted by any caixa-side renderer that needs to carry the pleme-io workload identity uses this prefix; runtime label injectors (lareira-fleet-programs chart’s pod template, pleme-computeunit library chart’s identity sidecar, the caixa-operator’s pod-mutating webhook) and runtime label consumers (Cilium identity-based policy, Hubble flow attribution, caixa-mesh’s policy / Gateway emission, future observability/tracing renderers) all spell the same prefix exactly the same way — drift between any of those = a CiliumNetworkPolicy that matches no pods, a Hubble flow that can’t be correlated to its workload, an OpenTelemetry resource attribute that doesn’t join to its caixa lacre.

POLITICAS_KEY_CIRCUIT_BREAKER

Canonical camelCase JSON/YAML top-level key for the crate::aplicacao::MeshPolicy struct’s circuit_breaker circuit-breaker sub-block axis — the circuitBreaker: field the M3 Aplicacao’s #[serde(rename_all = "camelCase")] derive on crate::aplicacao::MeshPolicy emits at the singleton :politicas block, and the exact camelCase scalar (Rust field circuit_breaker → serde-emitted circuitBreaker, one of the two MeshPolicy axes the derive-attribute non-trivially transforms alongside POLITICAS_KEY_MTLS_REQUIRED and POLITICAS_KEY_RATE_LIMIT) every downstream circuit-breaker consumer must probe on (the future M4 per-edge :politicas overlay projection onto the mesh’s per-backend failure-counter reset window per MESH-COMPOSITION.md §III.3 breaker semantics, the future feira lint per-:politicas breaker-window bound-check against crate::POLICY_BREAKER_WINDOW_MAX and crate::POLICY_BREAKER_MAX_FAILURES_MAX). Peer of POLITICAS_KEY_TIMEOUT on the same crate::aplicacao::MeshPolicy singleton serialized-key axis; see POLITICAS_KEY_TIMEOUT for the full lift rationale.

POLITICAS_KEY_MTLS_REQUIRED

Canonical camelCase JSON/YAML top-level key for the crate::aplicacao::MeshPolicy struct’s mtls_required mTLS-enforcement-toggle axis — the mtlsRequired: field the M3 Aplicacao’s #[serde(rename_all = "camelCase")] derive on crate::aplicacao::MeshPolicy emits at the singleton :politicas block, and the exact camelCase scalar (Rust field mtls_required → serde-emitted mtlsRequired) every downstream mesh-identity consumer must probe on (the future M4 per-edge :politicas overlay projection onto Cilium CiliumNetworkPolicy per-rule CILIUM_KEY_AUTHENTICATION mode dispatch under the cilium_auth_mode bijection projection (a4dc43c) — the mesh’s sandboxing-by-default posture MESH-COMPOSITION.md §III.3 promises keys off this exact byte-sequence to opt out of mTLS enforcement per-edge, so drift here silently reopens the every-edge-mTLS invariant the substrate defaults to). Peer of POLITICAS_KEY_TIMEOUT on the same crate::aplicacao::MeshPolicy singleton serialized-key axis; see POLITICAS_KEY_TIMEOUT for the full lift rationale.

POLITICAS_KEY_RATE_LIMIT

Canonical camelCase JSON/YAML top-level key for the crate::aplicacao::MeshPolicy struct’s rate_limit token-bucket-rate-limit axis — the rateLimit: field the M3 Aplicacao’s #[serde(rename_all = "camelCase")] derive on crate::aplicacao::MeshPolicy emits at the singleton :politicas block, and the exact camelCase scalar (Rust field rate_limit → serde-emitted rateLimit) every downstream rate-limit consumer must probe on (the future M4 per-edge :politicas overlay projection onto the mesh’s per-backend token-bucket (rate, window) decoder driven by the canonical [crate::aplicacao::rate_limit_codec] unit-suffix bijection). Peer of POLITICAS_KEY_TIMEOUT on the same crate::aplicacao::MeshPolicy singleton serialized-key axis; see POLITICAS_KEY_TIMEOUT for the full lift rationale.

POLITICAS_KEY_RETRIES

Canonical camelCase JSON/YAML top-level key for the crate::aplicacao::MeshPolicy struct’s retries transient-failure retry-count axis — the retries: field the M3 Aplicacao’s #[serde(rename_all = "camelCase")] derive on crate::aplicacao::MeshPolicy emits at the singleton :politicas block. Peer of POLITICAS_KEY_TIMEOUT on the same crate::aplicacao::MeshPolicy singleton serialized-key axis; see POLITICAS_KEY_TIMEOUT for the full lift rationale. The Rust field is lowercase retries; #[serde(rename_all = "camelCase")] is a no-op on this axis and the emitted key equals the source-side field name byte-for-byte.

POLITICAS_KEY_TIMEOUT

Canonical camelCase JSON/YAML top-level key for the crate::aplicacao::MeshPolicy struct’s timeout per-call wall-clock cap axis — the timeout: field the M3 Aplicacao’s #[serde(rename_all = "camelCase")] derive on crate::aplicacao::MeshPolicy emits at the singleton :politicas block, and the exact scalar every downstream mesh-timeout consumer must probe on (the future M4 per-edge :politicas overlay projection onto Cilium L7Rules / Gateway API HTTPRoute per-backend timeouts.backendRequest axis per MESH-COMPOSITION.md §III.3, the future mesh.pleme.io/v1alpha1/Aplicacao CR materializer’s admission-time mesh-timeout cross-check, the future feira lint per-:politicas authored-duration bound-check against crate::POLICY_TIMEOUT_MAX).

SPDX_EXPRESSION_MAX_LEN

Practical cap on a :licenca (SPDX-expression-shaped) value, in bytes. The SPDX specification places no length cap on expressions — the grammar admits arbitrarily-nested composite expressions — but every realistic pleme-io fixture stays well under this bound (MIT 3, Apache-2.0 10, Apache-2.0 OR MIT 17, the longest SPDX dual-license-with-exception shape Apache-2.0 WITH LLVM-exception 31; a (MIT OR Apache-2.0) AND BSD-3-Clause AND ISC composite caps near 50). 256 bytes is the substrate’s catch-the-paste-from-binary cap on the peer trajectory is_dns_1123_label (63), is_cargo_feature_name (64), is_wit_world_ref (128), is_nats_subject (256), is_wasi_keyvalue_slot (512), is_git_ref_name (255), is_git_oid (40/64), is_git_repo_url (2048) carry: an axis-appropriate ceiling above every legitimate authoring shape, tight enough to surface the “paste-from-license-text” / “multi-line license blob landed in the :licenca slot” footgun at validate time.

STANDALONE_LAREIRA_ENABLED_DEFAULT

Canonical substrate-side default for the values.<library>.enabled scalar-value toggle every caixa_helm::render_chart_for_servico-emitted standalone lareira-<nome> chart’s values.yaml document seeds inside its per-caixa DEFAULT_LIBRARY_NAME wrap block to leave the paired DEFAULT_LIBRARY_NAME child chart opted-out at the per-cluster helm template / helm install apply step. Pairs with the sibling HELM_VALUES_KEY_ENABLED leaf-scalar-key half of the (leaf-key, scalar-value) per-values-block child-chart-enablement-toggle declaration pair — the key half names the canonical values.<library>.enabled leaf-scalar-key axis every consumer (this standalone-path default, caixa_flux::cluster_bundle’s per-CR values-overlay) probes on, and this scalar-value half names the substrate-side default the standalone per-chart path seeds under it. Semantically distinct from — and inverse of — the peer CLUSTER_BUNDLE_LAREIRA_ENABLED_DEFAULT default that caixa_flux::cluster_bundle’s helmrelease.yaml values overlay seeds for the substrate-side composition-path force-on (that path renders enabled: true in the per-cluster HelmRelease.spec.values.<library> overlay so the operator’s per-caixa cluster-scoped ownership at bundle materialization time carries a force-on for the child chart); the standalone per-chart path is the substrate-side opt-out path where the operator has not yet asserted per-caixa cluster-scoped ownership by materializing a per-caixa GitRepository + HelmRelease + Kustomization trio, so the per-chart values.yaml seeds enabled: false under the values.<library> wrap and cluster operators must opt each caixa in per-cluster.

SUPERVISOR_AUTHOR_KEY_CHILDREN

Canonical author-facing kebab-case (defcaixa … :children (…)) top-level supervisor-tree slot label the OTP :kind Supervisor caixa’s static child-spec list (crate::supervisor::ChildSpec) surfaces under. Peer of SUPERVISOR_AUTHOR_KEY_ESTRATEGIA on the sibling supervision-tree slot axis; see SUPERVISOR_AUTHOR_KEY_ESTRATEGIA for the full lift rationale.

SUPERVISOR_AUTHOR_KEY_ESTRATEGIA

Canonical author-facing kebab-case (defcaixa … :estrategia <s>) top-level supervisor-tree slot label the OTP :kind Supervisor caixa’s crate::supervisor::RestartStrategy discriminator surfaces under. Peer of M2_AUTHOR_KEY_LIMITS / M3_AUTHOR_KEY_MEMBROS on the third kind-scoped typed-slot-family axis: the M2 M2_AUTHOR_KEY_* consts (f49c8b0) name the Servico-runtime slots, the M3 M3_AUTHOR_KEY_* consts (882f498) name the Aplicacao mesh slots, and these SUPERVISOR_AUTHOR_KEY_* consts close the last remaining kind ↔ slot-family axis — the Supervisor supervision-tree slots (:estrategia, :max-restarts, :restart-window, :children) that crate::Caixa::declared_supervisor_slots tags for the sibling crate::LayoutError::SupervisorSlotsOnNonSupervisor kind-coherence gate.

SUPERVISOR_AUTHOR_KEY_MAX_RESTARTS

Canonical author-facing kebab-case (defcaixa … :max-restarts <n>) top-level supervisor-tree slot label the OTP :kind Supervisor caixa’s MaxIntensity restart-budget counter surfaces under. Peer of SUPERVISOR_AUTHOR_KEY_ESTRATEGIA on the sibling supervision-tree slot axis; see SUPERVISOR_AUTHOR_KEY_ESTRATEGIA for the full lift rationale.

SUPERVISOR_AUTHOR_KEY_RESTART_WINDOW

Canonical author-facing kebab-case (defcaixa … :restart-window "<duration>") top-level supervisor-tree slot label the OTP :kind Supervisor caixa’s Period rolling-window counter surfaces under. Peer of SUPERVISOR_AUTHOR_KEY_ESTRATEGIA on the sibling supervision-tree slot axis; see SUPERVISOR_AUTHOR_KEY_ESTRATEGIA for the full lift rationale.

SUPERVISOR_CHILD_KEY_CAIXA

Canonical camelCase JSON/YAML top-level key for the crate::supervisor::ChildSpec struct’s caixa per-entry-name-of- the-child-caixa axis — the caixa: field the M2 Supervisor’s #[serde(rename_all = "camelCase")] derive on crate::supervisor::ChildSpec emits at each entry of the crate::supervisor::SupervisorSpec::children list, and the exact scalar every downstream consumer reaching for the child caixa’s crate::Caixa::nome via Value::get(...) (the future wasm-operator’s per-supervisor-tree child resolver, the M4 caixa.pleme.io/v1alpha1/Supervisor CR materializer’s admission webhook per-child cross-check, the future feira supervisor-tree walker’s per-child name-lookup, the [caixa_resolver] per-child git-clone step) must probe on.

SUPERVISOR_CHILD_KEY_RESTART

Canonical camelCase JSON/YAML top-level key for the crate::supervisor::ChildSpec struct’s restart per-entry crate::supervisor::RestartPolicy discriminator axis. Peer of SUPERVISOR_CHILD_KEY_CAIXA on the same crate::supervisor::ChildSpec per-entry serialized-key axis; see SUPERVISOR_CHILD_KEY_CAIXA for the full lift rationale. The Rust field is lowercase restart; #[serde(rename_all = "camelCase")] is a no-op on this axis and the emitted key equals the source-side field name byte-for-byte.

SUPERVISOR_CHILD_KEY_VERSAO

Canonical camelCase JSON/YAML top-level key for the crate::supervisor::ChildSpec struct’s versao per-entry-semver- constraint-of-the-child axis. Peer of SUPERVISOR_CHILD_KEY_CAIXA on the same crate::supervisor::ChildSpec per-entry serialized-key axis; see SUPERVISOR_CHILD_KEY_CAIXA for the full lift rationale. The Rust field is lowercase versao; #[serde(rename_all = "camelCase")] is a no-op on this axis and the emitted key equals the source-side field name byte-for-byte.

SUPERVISOR_CHILD_RESTART_PERMANENT

Canonical M2 crate::supervisor::RestartPolicy::Permanent variant discriminator scalar-value — the exact byte-string the Serialize derive on the un-renamed enum emits under SUPERVISOR_CHILD_KEY_RESTART whenever the typed :children :restart per-child restart-policy slot is the always-restart-regardless-of-exit arm (the enum’s default() and the canonical happy-path per theory/INSPIRATIONS.md §II.2 — Erlang/OTP permanent, the long-running-service posture where the supervisor must bring the child back on every failure mode).

SUPERVISOR_CHILD_RESTART_TEMPORARY

Canonical M2 crate::supervisor::RestartPolicy::Temporary variant discriminator scalar-value — the exact byte-string the Serialize derive on the un-renamed enum emits under SUPERVISOR_CHILD_KEY_RESTART whenever the typed :children :restart per-child restart-policy slot is the never-restart arm (Erlang/OTP temporary, the one-shot posture where the child’s completion — clean or not — is itself the success signal; the oneShot crate::render::COMPUTEUNIT_SPEC_KEY_TRIGGER arm maps here).

SUPERVISOR_CHILD_RESTART_TRANSIENT

Canonical M2 crate::supervisor::RestartPolicy::Transient variant discriminator scalar-value — the exact byte-string the Serialize derive on the un-renamed enum emits under SUPERVISOR_CHILD_KEY_RESTART whenever the typed :children :restart per-child restart-policy slot is the restart-only-on-abnormal-exit arm (Erlang/OTP transient, the “restart on non-zero exit or unhandled exception; a clean exit completes the child” posture — the third canonical OTP per-child restart-decision arm alongside permanent and temporary).

SUPERVISOR_ESTRATEGIA_ONE_FOR_ALL

Canonical M2 crate::supervisor::RestartStrategy::OneForAll variant discriminator scalar-value — the exact byte-string the Serialize derive on the un-renamed enum emits under SUPERVISOR_KEY_ESTRATEGIA whenever the typed :supervisor :estrategia slot’s strategy is the restart-every-sibling-on-any- failure arm (Erlang/OTP one_for_all, used when children share state and must be in sync).

SUPERVISOR_ESTRATEGIA_ONE_FOR_ONE

Canonical M2 crate::supervisor::RestartStrategy::OneForOne variant discriminator scalar-value — the exact byte-string the Serialize derive on the un-renamed enum emits under SUPERVISOR_KEY_ESTRATEGIA whenever the typed :supervisor :estrategia slot’s strategy is the restart-only-the-failed-child arm (the enum’s default() and the canonical happy-path per theory/INSPIRATIONS.md §II.2 — Erlang/OTP one_for_one).

SUPERVISOR_ESTRATEGIA_REST_FOR_ONE

Canonical M2 crate::supervisor::RestartStrategy::RestForOne variant discriminator scalar-value — the exact byte-string the Serialize derive on the un-renamed enum emits under SUPERVISOR_KEY_ESTRATEGIA whenever the typed :supervisor :estrategia slot’s strategy is the restart-failed-and-later-started- siblings arm (Erlang/OTP rest_for_one, used when later children depend on earlier ones so the startup-order suffix must be re-established).

SUPERVISOR_ESTRATEGIA_SIMPLE_ONE_FOR_ONE

Canonical M2 crate::supervisor::RestartStrategy::SimpleOneForOne variant discriminator scalar-value — the exact byte-string the Serialize derive on the un-renamed enum emits under SUPERVISOR_KEY_ESTRATEGIA whenever the typed :supervisor :estrategia slot’s strategy is the dynamic-children-of-one-shape arm (Erlang/OTP simple_one_for_one, the one arm on which crate::supervisor::SupervisorSpec::validate gates children.is_empty() as a structural partition — static :children on a SimpleOneForOne supervisor is a build-time rejection).

SUPERVISOR_KEY_CHILDREN

Canonical camelCase JSON/YAML top-level key for crate::supervisor::SupervisorSpec’s children axis. Peer of SUPERVISOR_KEY_ESTRATEGIA on the same sibling supervision-tree serialized-key axis; see SUPERVISOR_KEY_ESTRATEGIA for the full lift rationale. The Rust field is lowercase children; #[serde(rename_all = "camelCase")] is a no-op on this axis and the emitted key equals the source-side field name byte-for-byte.

SUPERVISOR_KEY_ESTRATEGIA

Canonical camelCase JSON/YAML top-level key for crate::supervisor::SupervisorSpec’s estrategia restart-strategy discriminator — the exact byte-sequence the type’s #[serde(rename_all = "camelCase")] derive emits, and the scalar every downstream JSON/YAML consumer that reaches into a serialized SupervisorSpec (via Value::get(...)) must probe on.

SUPERVISOR_KEY_MAX_RESTARTS

Canonical camelCase JSON/YAML top-level key for crate::supervisor::SupervisorSpec’s max_restarts axis. Peer of SUPERVISOR_KEY_ESTRATEGIA on the same sibling supervision-tree serialized-key axis; see SUPERVISOR_KEY_ESTRATEGIA for the full lift rationale. The Rust field is snake_case max_restarts; #[serde(rename_all = "camelCase")] maps it to the camelCase JSON key "maxRestarts" this constant pins.

SUPERVISOR_KEY_RESTART_WINDOW

Canonical camelCase JSON/YAML top-level key for crate::supervisor::SupervisorSpec’s restart_window axis. Peer of SUPERVISOR_KEY_ESTRATEGIA on the same sibling supervision-tree serialized-key axis; see SUPERVISOR_KEY_ESTRATEGIA for the full lift rationale. The Rust field is snake_case restart_window; #[serde(rename_all = "camelCase")] maps it to the camelCase JSON key "restartWindow" this constant pins.

WASI_KV_SLOT_MAX_LEN

Max length, in bytes, of a single typed :contratos :slot WASI keyvalue store key/template passing the is_wasi_keyvalue_slot predicate. 512 bytes — generously above the longest realistic slot template ("checkout/$orderId" = 17 bytes, "users:{tenant}/{id}" = 19 bytes, "session.tokens.<sid>" = 20 bytes) and well under any canonical WASI-keyvalue backend’s per-key limit (etcd: 1.5 MB, DynamoDB partition+sort key: 2 KB combined, Redis: 512 MB — the cap is chosen for the template slot a typed :contratos edge authors, not the realized key at runtime). The cap exists to reject the paste-from-binary footgun (a multi-line blob accidentally landed in the :slot slot) rather than to constrain legitimate authoring. Lifted as a typed const so a future axis reaching for the same bound (the M4 mesh.pleme.io/v1alpha1/Aplicacao CR materializer’s per-slot validator, the future per-Servico :capabilities wasi:keyvalue/store axis’s per-slot validator when M4 lands per-capability typed slots, the future per-edge :politicas-derived kv-backend-aware policy overlay’s per-slot validator) reads from one place. Same lift trajectory as NATS_SUBJECT_MAX_LEN (which caps the peer pub-sub payload axis at 256 bytes — twice that here because kv slot templates legitimately compose more /-separated path segments + template variables than NATS subjects do .-separated tokens).

WIT_IDENT_MAX_LEN

Max length, in bytes, of a single typed :contratos :wit world reference passing the is_wit_world_ref predicate. 128 bytes — roughly 8× the longest real-world WIT reference the caixa-mesh test fixtures carry (wasi:keyvalue/store = 19 bytes) and the WIT registry references its peers under (wasi:http/proxy@0.2.0 = 21 bytes), so the cap exists to reject the paste-from-binary footgun (a multi-line blob accidentally landed in the :wit slot) rather than to constrain legitimate authoring. Lifted as a typed const so a future axis reaching for the same bound (the M4 per-edge WIT registry resolver, the future mesh.pleme.io/v1alpha1/Aplicacao CR materializer’s per-contract WIT validator) reads from one place.

Traits

MappingExt

Extension methods on serde_yaml::Mapping that lift the per-key scalar-promotion boilerplate every K8s-artifact-emitter across caixa-mesh, caixa-flux, caixa-helm, and caixa-core::render carries: the canonical mapping.insert(Value::String(key.into()), value) three-liner the schema-key axis of every emitted YAML document tunnels a &'static str key axis-name through.

SequenceExt

Extension methods for the Vec<serde_yaml::Value> emission surface that the K8s-artifact-emit sites of caixa-mesh / caixa-flux / caixa-helm / caixa-core::render build up as spec.ingress[] / spec.rules[] / spec.hostnames[] / per- programs.yaml-entry payloads before wrapping each vec as a serde_yaml::Value::Sequence on an outer serde_yaml::Mapping (via MappingExt::insert_sequence).

Functions

assert_str_reexport_identity

Test-side pin that asserts a renderer-crate pub use caixa_core::X; re-export shares both the byte value and the &'static str allocation of its canonical caixa_core::X declaration — the stronger predicate than a plain assert_eq! byte-equality check.

ci_declared_edge_count

Substrate-canonical per-Acao declared-edge-count projection every consumer of a borrowed canteiro_types::CiRun that needs the total number of author-declared deps edges across every canteiro_types::CiNode keys off — returns the plain usize sum ci.nodes.iter().map(|n| n.deps.len()).sum() verbatim, without running canteiro_types::decompose again (the count is a property of the borrowed run’s shape, not of the owned canteiro_types::CanteiroDag the sibling decompose_ci returns — an author-declared cycle carries the same edge count as an author-declared linear DAG of the same node-and-dep list).

cilium_auth_mode

Canonical bool → &'static str bijection projection every consumer of the Cilium CiliumNetworkPolicy MutualAuthenticationMode OpenAPI schema enum’s closed-set author-reachable scalar-value pair (CILIUM_AUTH_MODE_REQUIRED / CILIUM_AUTH_MODE_DISABLED) consults so the per-tristate-arm dispatch — Some(true) (mTLS handshake mandatory) → CILIUM_AUTH_MODE_REQUIRED, Some(false) (mTLS handshake skipped, explicit opt-out) → CILIUM_AUTH_MODE_DISABLED — lives in exactly one place. The two arms of the :politicas :mtls-required tristate’s non-None value-space each land on a distinct MutualAuthenticationMode scalar; the None slot-absent arm is the caller’s single_field_overlay emission-gate concern (the helper returns None and the outer authentication: block is omitted entirely), not this projection’s — see the per-emit-site if let Some(overlay) = mtls_overlay { rule.insert(CILIUM_KEY_AUTHENTICATION, overlay.clone()) } guard.

cilium_network_policy_name

Canonical per-(:de, :para) CiliumNetworkPolicy metadata.name K8s-name-shaped scalar every caixa-mesh cilium_network_policies emitter mounts its per-edge CNP under. Composes on the lifted contrato_edge_label helper (the CNP name is the parent Aplicacao’s :nome joined to the contrato-edge-label by a canonical - separator: format!("{aplicacao}-{edge}")), so the two axes — the CNP metadata.labels.pleme.pleme.io/contrato value and the CNP metadata.name — share one canonical edge-encoding source of truth (CONTRATO_EDGE_LABEL_SEPARATOR).

contrato_edge_label

Canonical M3 :contratos edge label value — the <de>-to-<para> K8s-name-shaped scalar every per-(:de, :para) CiliumNetworkPolicy document carries at its metadata.labels.pleme.pleme.io/contrato axis (the LABEL_CONTRATO label key). Composes on the lifted CONTRATO_EDGE_LABEL_SEPARATOR byte-string so a future edge-encoding rebrand lands at one canonical composition, and every downstream consumer that grep-by-label picks up the new encoding by construction.

decompose_ci

Predicate: decompose a borrowed canteiro_types::CiRun into its typed canteiro_types::CanteiroDag via canteiro_types::decompose, wrapping any canteiro_types::DecomposeError in a typed CiDecomposeFailure view (carrying Caixa::nome) on rejection. The canonical entry-point every per-Acao consumer wraps in its own thiserror Error variant via #[from] — the call site becomes a single let cd = caixa_core::decompose_ci(caixa, ci)?; in place of the prior inline let cd = canteiro_types::decompose(ci).map_err(|source| CiDecomposeFailure { nome: caixa.nome().to_string(), source })?; block.

find_ascii_whitespace_byte

Predicate: find the first ASCII whitespace byte in s, or None if none of the string’s bytes match u8::is_ascii_whitespace.

find_by_kind

Locate the first K8s CR YAML document in docs whose top-level kind discriminator axis equals kind.

find_non_ascii_whitespace_char

Predicate: find the first non-ASCII Unicode-White_Space character in s, or None if every character lies in the ASCII byte range.

flux_kustomization_source_subtree

Canonical substrate-side per-cluster / per-caixa Kustomization.spec.path source-sub-tree scalar composer — the ./clusters/<cluster>/services/<nome> GitRepository-relative directory-tree seed every caixa-flux-emitted kustomization.yaml document mounts under its lifted FLUX_KUSTOMIZATION_KEY_PATH leaf-scalar-key at the top-level spec position so the Flux v2 kustomize-controller’s per-CR reconcile loop walks into the paired per-cluster / per-caixa sub-tree of the pleme-io k8s repository (rather than the GitRepository root, which would pull every unrelated cluster’s manifests through the wrong per-caixa Kustomization).

gateway_api_http_route_name

Canonical per-:entrada HTTPRoute metadata.name K8s-name-shaped scalar every caixa-mesh gateway_routes emitter mounts its per-:entrada HTTPRoute under. Composes the parent Aplicacao’s :nome and the :entrada :para destination Servico’s :nome on a canonical - separator (format!("{aplicacao}-{para}")), so the per-(:aplicacao, :entrada.para) HTTPRoute identity axis lives at one composer instead of a verbatim inline format!("{}-{}", caixa.nome, entrada.para) at the [caixa_mesh::gateway_routes] kube_resource_skeleton name: argument.

insert_first_seen

Bracket a per-list uniqueness gate with the shared “insert into seen; caller-shaped Err on the second occurrence” gate every declaration-order-preserving Vec-authored slot in caixa-core carries. Delegates to std::collections::HashSet::insert verbatim (which returns true on first insertion, false on repeat), then invokes the caller’s on_duplicate closure only on the duplicate arm — keeping the hot path (the unique case) allocation-free.

is_cargo_feature_name

Predicate: assert that s is a valid Cargo feature name. The contract — modeled on Cargo’s restricted_names::validate_feature_name grammar (the parser the Cargo resolver routes every [dependencies.<dep>.features] entry through at cargo metadata time), narrowed to the strict ASCII subset every realistic feature in the Cargo ecosystem uses:

is_chart_description_shape

Predicate: assert that s is a valid chart-description shape. The :descricao axis is a free-form prose summary that lands in the rendered lareira-<nome> Helm chart’s Chart.yaml description: field (a YAML scalar consumed by helm list, helm search, Artifact Hub, and every chart-aware UI) and in the chart’s README.md header paragraph (caixa-helm/src/lib.rs:232, caixa-helm/src/lib.rs:333). The contract — modeled on the YAML 1.2 plain-style scalar grammar and the Helm chart spec’s expectation that description: is a one-line summary:

is_chart_keyword_shape

Predicate: assert that s is a valid chart-keyword shape. The :etiquetas axis is a per-entry registry-search-tag identifier that lands in the rendered lareira-<nome> Helm chart’s Chart.yaml keywords: array via [caixa-helm]’s build_chart_yaml (folded through a std::collections::BTreeSet alongside the four substrate-fixed tags lareira / wasm / tatara-lisp / caixa-servico) and indexes the chart through Artifact Hub’s keyword-search axis + the future caixa-registry’s keyword index. The contract — modeled on Cargo’s crates.io [package] keywords grammar (the parser the crates.io publish API routes every keywords: entry through at publish time), narrowed to the strict ASCII subset every realistic search tag uses:

is_chart_maintainer_name_shape

Predicate: assert that s is a valid chart-maintainer-name shape. The :autores axis is a per-entry maintainer identifier that lands in the rendered lareira-<nome> Helm chart’s Chart.yaml maintainers: [{name: …, email: null}] array via [caixa-helm]’s build_chart_yaml (caixa-helm/src/lib.rs:251); each entry becomes the name: value of a single Maintainer record (a YAML scalar consumed by helm list, helm search, Artifact Hub’s maintainer index, and every chart-aware UI). The contract — modeled on the same YAML 1.2 plain-style scalar grammar is_chart_description_shape enforces on the sibling :descricao axis, with a tighter length cap for the per-entry identifier class:

is_computeunit_yaml_extension

Predicate: assert that path terminates in the canonical COMPUTEUNIT_YAML_SUFFIX (lowercase .computeunit.yaml) — the file-type shape every :servicos entry, the ComputeUnit-CR axis the M2 typed-substrate caixa-helm / caixa-flux renderers consume via serde_yaml::from_str, must take. The contract:

is_digit_only_magnitude

Predicate: s is a non-empty digit-only magnitude — every byte is an ASCII digit [0-9].

is_dns_1123_label

Predicate: assert that s is a valid K8s DNS-1123 label. The contract — exactly the regex the K8s apiserver enforces on every metadata.name / Service name / label value via OpenAPI v3 admission validation, [a-z0-9]([-a-z0-9]*[a-z0-9])? with a 63-byte cap:

is_gateway_api_http_path

Predicate: assert that path is a valid HTTP path under both the K8s Gateway API v1 HTTPPathMatch.value admission grammar AND the Cilium L7 path: rule grammar — the two landing sites every validated pleme-io HTTP-shaped path lands in. The contract:

is_git_oid

Predicate: assert that s is a valid Git commit OID — the canonical shape the typed :fonte (:tipo git …) :rev axis carries. The reproducibility contract :rev carries vs. :tag / :branch (CAIXA-SDLC §V — Substrate; :tag resolves to whatever the upstream has tagged today, :branch to whatever the upstream’s HEAD points at today, :rev to exactly one immutable commit forever — same shape Unison’s content-addressed code identity gives terms by construction: the hash is the address, the address never moves):

is_git_ref_name

Predicate: assert that s is a valid Git ref name under the git check-ref-format --allow-onelevel rule set — the canonical shape every typed :fonte (:tipo git …) :tag / :branch value carries. The contract — modeled on the git check-ref-format grammar the Git porcelain enforces at clone/fetch/checkout time, with the multi-component requirement waived (:tag "v0.1.0" and :branch "main" are both single-component refs, the canonical leaf form for caixa’s :fonte pin axes):

is_git_repo_url

Predicate: assert that s is a value-shape-valid :fonte (:tipo git :repo …) value — the canonical shape every typed :deps :fonte (and future :deps-dev :fonte) git-source carries. The contract — modeled on the intersection of (a) the git porcelain’s URL-parser accepted set the caixa-resolver invokes at git clone <repo> time, (b) the OWASP URL-shape guidance for author-surface inputs that flow to a CLI subprocess, and (c) the typed slot’s documented accepted shapes (crate::DepSource::Git doc comment: github:org/repo shorthand, https://… / ssh://… / git://… / file://… URL schemes, git@host:path scp-style SSH):

is_lareira_chart_name_shape

Predicate: assert that nome produces a lareira_chart_name output satisfying the K8s DNS-1123 label rule — the joint-length invariant the canonical lareira_chart_name helper’s doc comment (f7320d7) defers to “the M4 admission webhook will pin … when it lands”. This predicate lands it at the manifest-validate layer rather than waiting for the apiserver.

is_leading_zero_padded_magnitude

Predicate: s carries a leading-zero-padded magnitude — its length exceeds one byte and its first byte is ASCII '0'.

is_lisp_extension

Predicate: assert that path terminates in the canonical LISP_SOURCE_EXTENSION (lowercase .lisp) — the file-type shape every M2 typed path-slot the wasm-engine instantiator reads as tatara-lisp source must take. The contract:

is_nats_subject

Predicate: assert that s is a valid NATS subject — the canonical shape every typed :contratos :subject value carries. The contract — modeled on the NATS subject grammar (dot- separated tokens with * / > wildcards), restricted to the strict [A-Za-z0-9_-] per-token character set the NATS server’s subject parser accepts at runtime:

is_sandboxed_relative_path

Predicate: assert that path is a sandboxed-relative path — the shape every caixa-author-supplied callback / script path must take so the layout checker’s root.join(p) resolves inside the caixa root sandbox. The contract:

is_spdx_expression_shape

Predicate: assert that s is a valid SPDX-expression shape. The contract — modeled on the SPDX 2.1 expression grammar (compound-expression = simple-expression | "(" compound-expression ")" | compound-expression "WITH" exception-id | compound-expression "AND" compound-expression | compound-expression "OR" compound-expression; simple-expression = license-id | license-id "+" | "LicenseRef-" idstring | "DocumentRef-" idstring ":" "LicenseRef-" idstring; idstring = 1*(ALPHA / DIGIT / "-" / ".")), narrowed to the structural alphabet floor every realistic SPDX expression in the wild uses:

is_wasi_keyvalue_slot

Predicate: assert that s is a valid WASI keyvalue store slot template — the canonical shape every typed :contratos :slot value carries when its :wit dispatch resolves to the WitTarget::Store arm (wasi:keyvalue/store, kv:*). The WASI keyvalue 0.2 specification (bucket = string, key = string, both opaque) places no syntactic constraints on the key shape, so the substrate enforces the canonical printable-ASCII floor every realistic kv backend admits: no raw whitespace, no control bytes, no non-ASCII bytes, length-bounded by WASI_KV_SLOT_MAX_LEN. The grammar:

is_wit_world_ref

Predicate: assert that s is a valid WIT (WebAssembly Component Model) world reference — the canonical shape every typed :contratos :wit value carries. The contract — modeled on the WIT IDL grammar (namespace:package(/interface)*(@version)?) restricted to the lowercase subset the pleme-io substrate dispatches on:

kube_kind_is

Predicate: does the K8s custom resource YAML document at value declare its top-level kind discriminator axis as exactly kind?

kube_metadata_str_field

Read the string-scalar value at metadata.<field> on a K8s custom resource YAML document, returning None when either the top-level KUBE_KEY_METADATA block is absent (a defensively-tolerated missing sub-mapping — the caller’s own test-side expect(...) / production-side unwrap_or(...) names the axis), the requested <field> scalar is absent under it, or the scalar is present but carries a non-string YAML type (a numeric, boolean, or nested mapping — invalid K8s CR shape per the apiserver’s OpenAPI schema but tolerated here as None so the readback stays a total function). The returned &str borrows into the input Value — the caller decides whether to compare (==), clone (.to_string()), or unwrap-then-panic. The three-hop navigation happens in one method call the caller reads as intent (kube_metadata_str_field(<value>, <FIELD>) — “read this metadata.<FIELD> string-scalar off this K8s CR document”) rather than three hand-spelled positional artifacts (the get(KUBE_KEY_METADATA) outer hop, the and_then(|m| m.get(<FIELD>)) inner hop, the and_then(|n| n.as_str()) shape gate).

kube_resource_skeleton

Build the canonical K8s-resource skeleton — the apiVersion + kind + metadata.{name, namespace, labels?} block every cluster artifact emitted by every caixa-side renderer carries — and return it as a fresh serde_yaml::Mapping the caller adds its spec: (and any other top-level keys) to.

kube_root_str_field

Read the string-scalar value at a top-level <field> axis-key on a K8s custom resource YAML document — the root-level readback peer to kube_metadata_str_field on the sub-metadata: axis. Returns None when either the requested <field> scalar is absent (defensively tolerated — the caller’s own unwrap_or(...) / expect(...) names the axis) or the scalar is present but carries a non-string YAML type (a numeric, boolean, or nested mapping — invalid K8s CR shape per the apiserver’s OpenAPI schema but tolerated here as None so the readback stays a total function). The returned &str borrows into the input Value — the caller decides whether to compare (==), clone (.to_string()), or unwrap-then-panic. The two-hop navigation happens in one function call the caller reads as intent (kube_root_str_field(<value>, <FIELD>) — “read this K8s CR’s top-level <FIELD> string-scalar”) rather than two hand-spelled positional artifacts (the get(<FIELD>) outer hop, the and_then(|n| n.as_str()) shape gate).

label_selector

Wrap a typed string-valued label mapping in the canonical K8s LabelSelector shape — {matchLabels: <string-string-map>} — and return it as a serde_yaml::Value::Mapping ready to drop directly under any K8s field that takes a label selector (Cilium endpointSelector / fromEndpoints[].matchLabels, Gateway API BackendRef filters, ComputeUnit selector, Service spec.selector, the future mesh.pleme.io/v1alpha1/Aplicacao CR spec.selector).

lareira_chart_name

Derive the canonical per-Servico Helm chart name from a caixa’s :nome — the substrate-wide lareira-<nome> shape every per-Servico renderer (caixa-helm’s render_chart_for_servico chart-dir name, caixa-flux’s cluster_bundle HelmRelease chart: field, caixa-tatara’s process_for_aplicacao release_name, and the oci://<registry>/lareira-<nome> OCI ref) composes by prepending LAREIRA_CHART_NAME_PREFIX.

oci_chart_ref

Compose the canonical OCI artifact reference for a per-Servico Helm chart — the oci://<registry>/lareira-<nome> shape every renderer that materializes a chart-publish target (or a cluster-side chart resolver keyed off one) composes by prepending OCI_SCHEME_PREFIX, joining the caller-supplied registry, and appending the per-Servico chart name derived through the canonical lareira_chart_name helper.

pleme_program_in_aplicacao_selector

Build the canonical Cilium matchLabels selector for a single pleme-io program scoped to its Aplicacao — the safe default every per-Aplicacao mesh renderer (caixa-mesh’s cilium_network_policies fromEndpoints, future per-edge policy emission, Gateway API backendRefs filters) should use, since two different Aplicacaos can carry programs with the same :nome in the same cluster (e.g. two cart Servicos under different applications) and a LABEL_PROGRAM-only selector would match pods belonging to the wrong Aplicacao.

pleme_program_selector

Build the canonical Cilium matchLabels selector for a single pleme-io program without the Aplicacao constraint — deliberately broader than pleme_program_in_aplicacao_selector for the cases where matching a program across every Aplicacao that hosts it is the intent (cluster-wide rate limits, breakglass observability, the per-cluster operator identity scope).

require_acao_view

Compound per-Acao entry gate: the canonical three-line require_kind(caixa, CaixaKind::Acao)? + require_ci(caixa)? + decompose_ci(caixa, ci)? prelude every per-Acao caixa-<target> consumer runs at its entry-point, collapsed onto one call the caller reads as intent (“gate the input on the V0 Acao shape and hand back the borrowed canteiro_types::CiRun + the decomposed canteiro_types::CanteiroDag”) rather than three hand-spelled steps.

require_aplicacao_view

Compound per-Aplicacao entry gate: the canonical three-line require_kind(caixa, CaixaKind::Aplicacao)? + caixa.aplicacao_view().expect(…) + spec.validate()? prelude every per-Aplicacao caixa-<target> renderer runs at its entry-point, collapsed onto one call the caller reads as intent (“gate the input on the V0 Aplicacao shape and hand back a validated crate::aplicacao::AplicacaoSpec”) rather than three hand-spelled steps.

require_ci

Predicate: assert that caixa.ci().is_some(), returning the borrowed canteiro_types::CiRun on success and a typed MissingCiSlot view (carrying Caixa::nome) on rejection. The canonical entry-point every per-Acao consumer wraps in its own thiserror Error variant via #[from] — the call site becomes a single let ci = caixa_core::require_ci(caixa)?; in place of the prior two-line let ci = caixa.ci().ok_or_else(|| Error::MissingCi { nome: caixa.nome().to_string() })?; block.

require_kind

Predicate: assert that caixa.kind == expected, returning a typed KindMismatch view (carrying Caixa::nome) on rejection. The canonical entry-point every per-kind renderer wraps in its own thiserror Error variant via #[from] — the call site becomes a single caixa_core::require_kind(caixa, CaixaKind::X)?; in place of the prior inline if caixa.kind != CaixaKind::X { return Err(Error::NotAnX(caixa.kind)); } block.

require_positive_bounded_u32

Bracket a typed u32 axis with the “zero-floor + upper-cap” gate pair every capped-u32 :politicas / :supervisor / :limits axis carries. Returns on_zero() when value == 0, on_cap_exceeded(value) when value > cap, Ok(()) otherwise.

require_positive_bounded_u64

Peer of require_positive_bounded_u32 on the u64-typed axes. Returns on_zero() when value == 0, on_cap_exceeded(value) when value > cap, Ok(()) otherwise. See require_positive_bounded_u32 for the ordering / lift rationale (same “zero-floor arm strictly precedes cap arm so 0 surfaces the self-locating diagnostic” discipline the peer helper documents).

require_positive_canonical_bounded_duration

Bracket a typed Duration axis with the “zero-floor + canonical-form + upper-cap” three-arm gate every typed-Duration slot in the crate carries. Returns on_zero() when value is Duration::ZERO, on_not_canonical(value) when value carries sub-millisecond residue the shared crate::supervisor::duration_codec cannot round-trip losslessly, on_cap_exceeded(value) when value > cap, Ok(()) otherwise.

require_sandboxed_lisp_path

Bracket a sandboxed-relative .lisp-terminating path axis with the shared “empty → absolute → parent-escape → non-.lisp-extension” four-arm gate every author-supplied M2 tatara-lisp source-path slot on the caixa surface carries. Delegates to is_sandboxed_relative_path for the three structural arms and to is_lisp_extension for the extension arm; returns each arm’s caller-owned error variant via the four FnOnce closures.

require_single_servico

Predicate: assert that caixa.servicos.len() == 1, returning a typed ServicoCountMismatch view (carrying Caixa::nome + the actual count) on rejection. The canonical entry-point every per-Servico renderer wraps in its own thiserror Error variant via #[from] — the call site becomes a single caixa_core::require_single_servico(caixa)?; in place of the prior inline if caixa.servicos.len() != 1 { return Err(Error::UnsupportedServicoCount(caixa.servicos.len())); } block.

require_v0_servico_shape

Compound V0-shape entry gate: the canonical two-line require_kind(caixa, Servico)? + require_single_servico(caixa)? prelude every per-Servico caixa-<target> renderer runs at its entry-point, collapsed onto one call the caller reads as intent (“gate the input on the V0 Servico shape”) rather than two hand-spelled predicate calls.

require_valid_dns_1123_label

Bracket a K8s DNS-1123-label-shaped axis with the shared “empty-first, then is_dns_1123_label” gate pair every Servico- name reference slot carries. Returns on_empty() when value.is_empty(), on_invalid(reason) when is_dns_1123_label rejects the non-empty input, Ok(()) otherwise.

require_valid_versao_requirement

Bracket a :versao requirement-string axis with the shared “empty-first, then crate::parse_requirement” gate pair every dep-shaped :versao slot carries. Returns on_empty() when versao.is_empty(), on_invalid(reason) when crate::parse_requirement rejects the non-empty input, Ok(()) otherwise.

servico_m2_overlay

Render the M2 typed-slot YAML overlay for a Caixa: the camelCase (key, value) fragments every per-Servico renderer ([caixa-helm]’s values block, [caixa-flux]’s programs.yaml entry) merges into its target with or_insert semantics so explicit spec.* fields from the ComputeUnit YAML take precedence over the manifest-derived overlay.

servico_spec_and_m2_overlay_entries

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:

single_field_overlay

Build a single-field serde_yaml::Value::Mapping from a typed Option<T> slot — None when the slot is unset, Some(Mapping { inner_key: f(t) }) otherwise.

singleton_mapping_sequence

Wrap a single serde_yaml::Mapping as the sole element of a serde_yaml::Value::Sequence, returning the ready-to-drop singleton-mapping-sequence Value.

string_keyed_entries

Iterator over the string-keyed entries of a serde_yaml::Value that may or may not be a serde_yaml::Mapping — the canonical shape both per-Servico renderers reach for when splicing the upstream ComputeUnit YAML’s spec.* fields into their emitted output map.

upsert_named_entry

Upsert new_entry into a typed sequence of programs.yaml-shaped entries by matching on new_entry’s <name_key> scalar — the idempotent “replace-in-place if present, else append” contract every writer-side aggregator overlay lands the same 11-line block in front of. Returns Ok(true) when the entry was appended new, Ok(false) when an existing entry with the same <name_key> value was replaced in place (preserving position); returns on_missing_name() when new_entry doesn’t carry <name_key> as a string scalar (the caller’s own typed crate::RenderError-shaped error surface, threaded through the closure so this helper stays crate-agnostic).

yaml_string_mapping

Convert a typed string-valued mapping (e.g. one of the canonical pleme_program_selector / pleme_program_in_aplicacao_selector selectors, or any caller-built BTreeMap<&'static str, String>) into a serde_yaml::Value::Mapping with String → String shape — the surface every Cilium / Gateway / HTTPRoute / ComputeUnit matchLabels / metadata.labels / selector field expects.