Crate caixa_helm

Expand description

caixa-helm — typed renderer that emits a per-program lareira-<name> Helm chart from a Caixa manifest plus its servicos/<name>.computeunit.yaml.

§Output shape

Every chart emitted here mirrors the canonical pleme-io/helmworks/charts/lareira-<name>/ layout, which is thin:

Chart.yaml ; metadata + dependency on pleme-computeunit values.yaml ; pleme-computeunit values block (the typed L2 ComputeUnit shape) README.md ; one-line elevator pitch for the chart

There are no templates/ — the rendering is delegated to the pleme-computeunit library chart in helmworks (per theory/META-FRAMEWORK.md §I, Layer 3 → Layer 2 transformation). caixa-helm’s job is to derive the values block from a Caixa, not to render Kubernetes objects directly.

§Why a separate crate

Same pattern as [caixa_flake] (renders flake.nix) and [caixa_pangea] (renders pangea Ruby) — caixa-<target> crates take a typed Caixa and emit the canonical source for <target>. Naming is uniform across the workspace.

§V0 contract

use caixa_core::Caixa;
use caixa_helm::{ChartDir, render_chart_for_servico};

let caixa: Caixa = Caixa::from_lisp(src)?;
let cu_yaml: serde_yaml::Value =
    serde_yaml::from_str(std::fs::read_to_string("servicos/hello-rio.computeunit.yaml")?)?;
let dir: ChartDir = render_chart_for_servico(&caixa, &cu_yaml)?;
dir.write_to(std::path::Path::new("/tmp/lareira-hello-rio"))?;

§What this is NOT

Not a chart for the caixa-operator itself — that lives in pleme-io/caixa/operator-chart/.
Not a Helm CLI wrapper — emitting bytes only; consumers (feira chart, eventually) drive the I/O.
Not a renderer of K8s resources — pleme-computeunit library chart owns the templates that turn this values block into ComputeUnit + Service + ScaledObject + ConfigMap.

Structs§

ChartDependency
ChartDir: The rendered chart — a flat list of files, plus the chart name.
ChartYaml: Top-level Chart.yaml shape for a generated lareira- chart.
Maintainer
RenderOpts: Knobs that don’t come from the Caixa manifest.

Enums§

Error: Errors caixa-helm can raise.

Constants§

COMPUTEUNIT_SPEC_KEY_CAPABILITIES: Local re-export of the canonical caixa_core::COMPUTEUNIT_SPEC_KEY_CAPABILITIES — the wasm.pleme.io/v1alpha1/ComputeUnit CRD per-CR WASI-capability-list spec.capabilities sub-block key every rendered values.yaml’s DEFAULT_LIBRARY_NAME-wrapped block carries so the pleme-computeunit library chart’s per-Servico WASI-preview-2 capability-token binding fires exactly against the axis the caixa.lisp’s :servicos fixture pins. Peer of COMPUTEUNIT_SPEC_KEY_MODULE and COMPUTEUNIT_SPEC_KEY_TRIGGER on the same ComputeUnit CRD per-spec.* sub-block axis — completes the substrate-side ComputeUnit-CRD per-spec.* sub-block re-export triple in this crate. See caixa_core::COMPUTEUNIT_SPEC_KEY_CAPABILITIES for the full lift rationale. Canonical wasm.pleme.io/v1alpha1/ComputeUnit CRD spec.capabilities per-CR WASI-capability-list sub-block key — the top-level spec.* child every rendered ComputeUnit YAML carries to declare the wasm-component-capability tokens the M2.5 wasm-engine instantiator binds at Servico bring-up (http-in:0.0.0.0:8080 for the HTTP incoming-handler, env for read-only environment access, sock-* for TCP outbound, and the sibling WASI-preview-2 preview- interfaces per the WIT Component Model). Peer of COMPUTEUNIT_SPEC_KEY_MODULE and COMPUTEUNIT_SPEC_KEY_TRIGGER on the same ComputeUnit CRD per-spec.* sub-block surface — completes the substrate-side ComputeUnit-CRD per-spec.* sub-block re-export triple every rendered ComputeUnit YAML declares as its top-level (module, trigger, capabilities) axis. Same lift trajectory as the sibling COMPUTEUNIT_SPEC_KEY_MODULE axis — three verbatim inline test-side literals (one caixa-flux drift- detection navigator + two caixa-helm per-values drift-detection navigators, one under the canonical wrap-key + one under the library-name-override wrap-key) collapsed onto the same &'static str so any future rebrand (the substrate moving the capability-list axis to caps: for terse-schema parity with the WASI-preview-2 upstream naming, splitting into capabilities.wasi.* / capabilities.pleme.* runtime-vs-substrate discriminators, or the M4 WIT Component Model materializer moving to a typed imports: / exports: split) reaches every consumer by construction. See COMPUTEUNIT_SPEC_KEY_MODULE for the full lift rationale.
COMPUTEUNIT_SPEC_KEY_MODULE: Local re-export of the canonical caixa_core::COMPUTEUNIT_SPEC_KEY_MODULE — the wasm.pleme.io/v1alpha1/ComputeUnit CRD per-CR wasm-module-reference spec.module sub-block key every rendered values.yaml’s DEFAULT_LIBRARY_NAME-wrapped block carries so the pleme-computeunit library chart’s per-Servico module-source axis binds to the exact source the caixa.lisp’s :servicos fixture pins. Two per-values drift-detection navigators in this crate’s test module (the canonical-wrap-key round-trip + the library-name-override wrap-key round-trip) now consult the same &'static str as the peer caixa-flux writer’s per-Servico programs[]-entry module-source navigators. Same re-export shape as the peer HELM_VALUES_KEY_ENABLED / KUBE_KEY_SPEC surfaces on the sibling canonical-Helm-load-bearing-string / canonical-K8s-CR-body-key axes — extends the discipline the M2-typed-slot / K8s-CR key re-export families establish onto the substrate-side ComputeUnit-CRD per-spec.* sub-block axis. See caixa_core::COMPUTEUNIT_SPEC_KEY_MODULE for the full lift rationale. Canonical wasm.pleme.io/v1alpha1/ComputeUnit CRD spec.module per-CR wasm-module-reference sub-block key — the top-level spec.* child every rendered ComputeUnit YAML carries to name the wasm component (module.source: oci://... for OCI-hosted binaries, module.source: file://... for locally-mounted wasm bundles) the M2.5 wasm-engine instantiator loads at Servico bring-up. The single source of truth every downstream consumer that reads or emits the per-CR module sub-block reaches for:
COMPUTEUNIT_SPEC_KEY_TRIGGER: Local re-export of the canonical caixa_core::COMPUTEUNIT_SPEC_KEY_TRIGGER — the wasm.pleme.io/v1alpha1/ComputeUnit CRD per-CR invocation-shape spec.trigger sub-block key every rendered values.yaml’s DEFAULT_LIBRARY_NAME-wrapped block carries so the pleme-computeunit library chart’s per-Servico trigger.service.{port, paths, breathability} routing binds to the exact axis the caixa.lisp’s :servicos fixture pins. Peer of COMPUTEUNIT_SPEC_KEY_MODULE on the same ComputeUnit CRD per-spec.* sub-block axis — see caixa_core::COMPUTEUNIT_SPEC_KEY_TRIGGER for the full lift rationale. Canonical wasm.pleme.io/v1alpha1/ComputeUnit CRD spec.trigger per-CR invocation-trigger sub-block key — the top-level spec.* child every rendered ComputeUnit YAML carries to name how the wasm component is invoked (trigger.service.{port, paths} for HTTP-triggered Servicos, trigger.subscription.{subject} for the future NATS-triggered Servicos the M4 :contratos typed-mesh pubsub axis will emit). Peer of COMPUTEUNIT_SPEC_KEY_MODULE on the same ComputeUnit CRD per-spec.* sub-block surface — COMPUTEUNIT_SPEC_KEY_MODULE names the per-CR wasm-binary reference axis, this constant names the per-CR invocation-shape axis every downstream trigger consumer (the pleme-computeunit library chart’s per-Servico trigger.service.port / trigger.service.paths / trigger.service.breathability values- block routing, the future M4 pubsub-subscription binding, the caixa-mesh CiliumNetworkPolicy L4-port fallback that reads the destination Servico’s per-trigger.service.port axis via a future resolver round-trip) reaches for. Same lift trajectory as the sibling COMPUTEUNIT_SPEC_KEY_MODULE axis — three verbatim inline test-side literals (one caixa-flux drift-detection navigator
DEFAULT_LIBRARY_NAME: Canonical Helm library-chart name every lareira-<nome> chart depends on — re-export of the lifted caixa_core::DEFAULT_LIBRARY_NAME so the load-bearing string lives in exactly one place across every caixa renderer (caixa-helm’s RenderOpts::library_name default here + caixa-flux’s cluster_bundle helmrelease.yaml wrap key). A future per-edition library-chart fork — every entry on the absorption-roadmap that names a per-cluster / per-namespace / per-tenant variant of the canonical library chart — reaches both consumers through one &'static str by construction. Same shape as the caixa_core::DEFAULT_NAMESPACE (a085b26) / caixa_core::DEFAULT_SERVICO_PORT (1e22add) lifts on the peer canonical-K8s-axis-constant surface. Canonical Helm library-chart name every lareira-<nome> chart depends on — the pleme-computeunit library chart in pleme-io/helmworks/charts/pleme-computeunit that owns the K8s resource templates (ComputeUnit + Service + ScaledObject + ConfigMap) every per-Servico chart consumes via Helm’s per-dep alias convention (when no alias: is set on a dependency, values are scoped under the dependency’s name:).
DEFAULT_LIBRARY_REPO: Repository for the pleme-computeunit library chart. Defaults to the helmworks file:// path used by lareira-* charts; consumers can override via RenderOpts::library_repo to point at the published OCI registry.
DEFAULT_LIBRARY_VERSION
HELM_CHART_API_VERSION: Canonical Helm 3 Chart.yaml apiVersion every rendered lareira-<nome> chart declares. Re-export of the lifted caixa_core::HELM_CHART_API_VERSION so the Helm-side chart-schema apiVersion — the discriminator the Helm binary’s chart-schema parser (helm dependency build, helm lint, helm template) consults to select the schema that reads the rendered Chart.yaml — lives in exactly one place across every caixa renderer. The single production-code call site consuming it is [build_chart_yaml]’s api_version field assignment; a drifted local pub const HELM_CHART_API_VERSION: &str = "…" at this crate (or any sibling per-chart-schema renderer the absorption roadmap acknowledges — the future per-Aplicacao library chart, the future per-cluster snapshot chart) would silently reroute the rendered Chart.yaml through a stale chart-schema parser at helm template time far from the rebrand commit’s source, so the equality + &'static static-data identity pin (helm_chart_api_version_re_export_points_at_caixa_core_canonical) closes the drift footgun at caixa-helm build time. Same shape as the DEFAULT_LIBRARY_NAME / KUBE_KEY_SPEC re-exports on the sibling canonical-Helm-load-bearing-string / canonical-K8s-CR-key axes. Canonical Helm 3 Chart.yaml apiVersion every caixa-helm-rendered lareira-<nome> chart declares at its top-level apiVersion axis. The Helm 3 chart-schema resolution contract keys off this exact "v2" value: helm dependency build, helm lint, and helm template all parse the chart under the Helm 3 v2 schema (which requires ChartYaml::description and permits dependencies: at the top level); drift to the legacy Helm 2 "v1" (the pre-Helm-3 chart schema every upstream Helm-3-migration doc names) silently reroutes the rendered Chart.yaml through the Helm 2 parser, where the top-level dependencies: block is unknown and the chart’s dep on the pleme-computeunit library chart never resolves — helm dependency build reports “no requirements found” and every downstream helm template / helm install on the rendered chart emits an empty release (no ComputeUnit / Service / ScaledObject resources land) far from the source caixa.lisp / the renderer’s build_chart_yaml call site.
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 — re-export of the lifted caixa_core::HELM_CHART_DEPENDENCY_KEY_ALIAS so the load-bearing serde field-name at ChartDependency’s alias field lives in exactly one place across every caixa renderer. Peer to HELM_CHART_DEPENDENCY_KEY_NAME on the sibling per-dep sub-key axes. 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 — re-export of the lifted caixa_core::HELM_CHART_DEPENDENCY_KEY_NAME so the load- bearing serde field-name at ChartDependency’s name field lives in exactly one place across every caixa renderer. Peer to HELM_CHART_DEPENDENCY_KEY_VERSION / HELM_CHART_DEPENDENCY_KEY_REPOSITORY / HELM_CHART_DEPENDENCY_KEY_ALIAS on the sibling per-dep sub-key axes. The drift-detection round-trip pin at [tests::chart_dependency_serializes_tetrad_under_lifted_helm_chart_dependency_keys] serializes a fully-populated ChartDependency and asserts each of the four per-dep sub-mapping wire keys resolves — closing the drift a rename of the Rust field or a #[serde(rename_all)] attribute addition would otherwise leave silent. 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 — re-export of the lifted caixa_core::HELM_CHART_DEPENDENCY_KEY_REPOSITORY so the load-bearing serde field-name at ChartDependency’s repository field lives in exactly one place across every caixa renderer. Peer to HELM_CHART_DEPENDENCY_KEY_NAME on the sibling per-dep sub-key axes. 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 — re-export of the lifted caixa_core::HELM_CHART_DEPENDENCY_KEY_VERSION so the load-bearing serde field-name at ChartDependency’s version field lives in exactly one place across every caixa renderer. Peer to HELM_CHART_DEPENDENCY_KEY_NAME on the sibling per-dep sub-key axes. See HELM_CHART_DEPENDENCY_KEY_NAME for the shared per-entry-sub-mapping lift rationale. 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 — re-export of the lifted caixa_core::HELM_CHART_KEY_API_VERSION so the top-level chart- schema-apiVersion YAML key the ChartYaml api_version field’s #[serde(rename = "apiVersion")] attribute encodes lives in exactly one place across every caixa renderer. Rust’s attribute grammar admits only string literals so the const cannot substitute for the literal syntactically, but the drift-detection pin at [tests::chart_yaml_serializes_api_version_axis_under_lifted_helm_chart_key_api_version] round-trips a rendered Chart.yaml and asserts the top-level Mapping::get(HELM_CHART_KEY_API_VERSION) resolves, closing the drift the attribute-literal-only grammar leaves silent (a future refactor that dropped the #[serde(rename = "apiVersion")] attribute would silently serialize the field as Rust’s default snake_case api_version:, which Helm’s chart-schema parser rejects at helm lint / helm dependency build / helm template time with an “apiVersion is required” error far from the drift site). Peer to HELM_CHART_KEY_TYPE / HELM_CHART_KEY_APP_VERSION on the sibling per-Chart.yaml top-level YAML axis-key re-export surface — completes the per-Chart.yaml top-level YAML axis-key re-export trio at the caixa-helm surface for the three serde- rename-literal-only axes on this crate’s ChartYaml struct. 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 — re-export of the lifted caixa_core::HELM_CHART_KEY_APP_VERSION so the top-level per-chart-app-version YAML key the ChartYaml app_version field’s #[serde(rename = "appVersion")] attribute encodes lives in exactly one place across every caixa renderer. Rust’s attribute grammar admits only string literals so the const cannot substitute for the literal syntactically, but the drift-detection pin at [tests::chart_yaml_serializes_app_version_axis_under_lifted_helm_chart_key_app_version] round-trips a rendered Chart.yaml and asserts the top-level Mapping::get(HELM_CHART_KEY_APP_VERSION) resolves, closing the drift the attribute-literal-only grammar leaves silent (a future refactor that dropped the #[serde(rename = "appVersion")] attribute would silently serialize the field as Rust’s default snake_case app_version:, which Helm’s chart-schema parser silently drops from the parsed chart-metadata shape, and every downstream Artifact Hub / helm search per-chart index falls back to “no application version” for the rendered chart far from the drift site). Peer to HELM_CHART_KEY_TYPE on the sibling per-Chart.yaml top-level YAML axis-key re-export surface — completes the per-Chart.yaml top-level YAML axis-key re-export pair at the caixa-helm surface for the two serde-rename-literal- only axes on this crate’s ChartYaml struct that Rust’s attribute-argument grammar leaves un-substitutable syntactically (the third top-level axis-key apiVersion re-exports through HELM_CHART_KEY_API_VERSION below, whose byte-shape coincides with the sibling caixa_core::KUBE_KEY_API_VERSION by Helm’s design decision to inherit the K8s CR top-level shape verbatim — the paired substrate-side [caixa_core-side helm_chart_key_api_version_matches_kube_key_api_version] pin makes the byte-shape coincidence load-bearing rather than accidental). 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 — re-export of the lifted caixa_core::HELM_CHART_KEY_DEPENDENCIES so the load-bearing serde field-name at ChartYaml’s dependencies field (the parent list-container the already-re-exported per-dependencies[]-entry sub-mapping tetrad HELM_CHART_DEPENDENCY_KEY_NAME / HELM_CHART_DEPENDENCY_KEY_VERSION / HELM_CHART_DEPENDENCY_KEY_REPOSITORY / HELM_CHART_DEPENDENCY_KEY_ALIAS mounts one level down under) lives in exactly one place across every caixa renderer. The Rust field name and the wire key coincide by default (no #[serde(rename)] attribute today), so the const doesn’t substitute for the field-name syntactically at the struct definition, but the drift-detection pin at [tests::chart_yaml_serializes_dependencies_axis_under_lifted_helm_chart_key_dependencies] round-trips a rendered Chart.yaml through serde_yaml::from_str::<serde_yaml::Value> and asserts the top- level Mapping::get(HELM_CHART_KEY_DEPENDENCIES) resolves — closing the drift a future field rename (dependencies → deps / chartDependencies) or a #[serde(rename_all = "camelCase")] attribute addition on ChartYaml would otherwise leave silent (Helm’s chart-schema parser silently drops the entire dep list from the parsed chart-metadata, helm dependency build finds no chart to vendor, and every rendered lareira-<nome> chart’s install fails at apply time far from the drift site). Peer to HELM_CHART_KEY_TYPE / HELM_CHART_KEY_APP_VERSION / HELM_CHART_KEY_API_VERSION on the sibling per-Chart.yaml top-level YAML axis-key re-export surface — extends the per- Chart.yaml top-level YAML axis-key re-export trio at the caixa-helm surface onto the fourth top-level axis-key, the parent list- container whose per-entry sub-mapping tetrad is already re-exported under [HELM_CHART_DEPENDENCY_KEY_*]. 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 — re-export of the lifted caixa_core::HELM_CHART_KEY_TYPE so the top-level per-chart-kind discriminator YAML key the sibling HELM_CHART_TYPE_APPLICATION / HELM_CHART_TYPE_LIBRARY axis-value re-exports carry the closed- set admitted scalars for lives in exactly one place across every caixa renderer. The production emitter today is ChartYaml’s chart_type field #[serde(rename = "type")] attribute — Rust’s attribute grammar admits only string literals so the const cannot substitute for the literal syntactically, but the drift-detection pin at [tests::chart_yaml_serializes_type_axis_under_lifted_helm_chart_key_type] round-trips a rendered Chart.yaml through serde_yaml::from_str::<serde_yaml::Value> and asserts the top- level Mapping::get(HELM_CHART_KEY_TYPE) resolves, closing the drift the attribute-literal-only grammar leaves silent (a future refactor that dropped the #[serde(rename = "type")] attribute would silently serialize the field as Rust’s default snake_case chart_type:, which Helm’s chart-schema parser silently ignores as an unknown top-level key, defaulting the per-chart-kind axis to application with no process-log drift-signal). Peer to the HELM_CHART_TYPE_APPLICATION / HELM_CHART_TYPE_LIBRARY re-exports on the sibling per-chart-kind axis-value canonical surface — completes the per-Chart.yaml per-chart-kind discriminator axis’s (key, value-set) canonical re-export trio at the caixa-helm surface. 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 — re-export of the lifted caixa_core::HELM_CHART_README_FILENAME so the third leg of the canonical {Chart.yaml, values.yaml, README.md} per-lareira-<nome> chart-directory ChartFile triple lives in exactly one place across every caixa renderer. The single production-code call site consuming it is render_chart_for_servico’s ChartDir assembly where the readme file’s per-ChartFile path axis is set (the sole emitter site the prior inline "README.md" string literal sat at); every test-side round-trip navigator that reaches into the rendered ChartDir by the readme filename (the render_chart_for_servico files-vec- membership pin + the ChartDir::write_to post-write existence pin — two sites) now consults the same &'static str. A drifted local pub const HELM_CHART_README_FILENAME: &str = "…" at this crate — the canonical drift footgun where a sibling local pub const could happen to carry the same string at the source while pointing at a different &'static allocation — surfaces as GitHub / Artifact Hub / any downstream per-chart README-surfacing UI silently falling back to “no README available” for the rendered lareira-<nome> chart far from the drift commit’s source, with no field naming the readme-filename-drift root cause. The equality + &'static static-data identity pin (helm_chart_readme_filename_re_export_points_at_caixa_core_canonical) closes the drift footgun at caixa-helm build time. Peer to the HELM_CHART_YAML_FILENAME / HELM_VALUES_YAML_FILENAME re-exports on the sibling canonical-Helm-per-chart-directory- filename axes — completes the per-lareira-<nome>-chart-directory (Chart.yaml, values.yaml, README.md) canonical-per-chart-directory- filename-axis re-export triple every rendered chart declares as its three ChartDir::files entries. 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. Re-export of the lifted caixa_core::HELM_CHART_TYPE_APPLICATION so the Helm chart-schema per-chart-kind discriminator — the scalar Helm’s per-release install- shape dispatch loop keys off to select the per-chart-kind install pathway — lives in exactly one place across every caixa renderer. The single production-code call site consuming it is [build_chart_yaml]’s chart_type field assignment (the sole emitter site the prior inline "application".into() literal sat at); a drifted local pub const HELM_CHART_TYPE_APPLICATION: &str = "…" at this crate (or any sibling per-chart renderer the absorption roadmap acknowledges — the future per-Aplicacao library chart, the future per-cluster snapshot chart) would surface as one of two silent failure modes at helm install time: a value outside the schema’s admitted set ({"application", "library"}) that Helm’s chart-schema parser silently treats as the default application shape (masking the schema violation with no process-log signal), or an accidental collapse onto the sibling "library" shape that Helm refuses to install directly (“Error: library charts cannot be installed”) with no field naming the chart-kind-drift root cause. The equality + &'static static-data identity pin (helm_chart_type_application_re_export_points_at_caixa_core_canonical) closes the drift footgun at caixa-helm build time. Peer to the HELM_CHART_API_VERSION re-export on the sibling canonical-Helm- chart-schema-axis — completes the per-Chart.yaml (apiVersion, type) canonical-scalar-axis re-export pair every rendered lareira-<nome> chart declares at its top-level Chart.yaml body. 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 — re-export of the lifted caixa_core::HELM_CHART_TYPE_LIBRARY so the second and only other arm of the Helm chart-schema’s closed set {"application", "library"} lives in exactly one place across every caixa renderer. No production emitter here consumes it today — the caixa-helm renderer emits per-Servico application-typed lareira-<nome> charts, and the sibling DEFAULT_LIBRARY_NAME pleme-computeunit library chart is out-of-tree at pleme-io/helmworks (not this crate’s authority) — but every future substrate-side per-chart-kind classifier and every emitter for the future per-Aplicacao library chart the HELM_CHART_TYPE_APPLICATION docstring names as a trajectory item reads the same &'static str by construction. Peer to the HELM_CHART_TYPE_APPLICATION re-export on the sibling closed-set arm — completes the two-arm re-export pair of the Helm chart-schema’s per-chart-kind axis at the caixa-helm surface so consumers reaching for either shape read from one canonical source per arm. The paired identity pins (helm_chart_type_library_re_export_points_at_caixa_core_canonical) close the drift footgun at caixa-helm build time. 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 — re-export of the lifted caixa_core::HELM_CHART_YAML_FILENAME so the fixed lookup name Helm’s chart-schema parser (helm dependency build, helm lint, helm template, helm install) consults at chart-open time to locate the per-chart schema-body scalars (HELM_CHART_API_VERSION, HELM_CHART_TYPE_APPLICATION, the name/version/dependencies fields) lives in exactly one place across every caixa renderer. The single production-code call site consuming it is render_chart_for_servico’s ChartDir assembly where the metadata file’s per-ChartFile path axis is set (the sole emitter site the prior inline PathBuf::from("Chart.yaml") literal sat at); every test-side round-trip navigator that reaches into the rendered ChartDir by the metadata filename (the per-chart-metadata-field sweep tests + ChartDir::write_to post-write existence pin) now consults the same &'static str, so a rebrand of the Helm 3 metadata-file axis (any per-fork Chartfile.yaml / Helm 4 metadata-file rename the upstream packaging spec might adopt) lands at one const and reaches every consumer by construction. A drifted local pub const HELM_CHART_YAML_FILENAME: &str = "…" at this crate — the canonical drift footgun where a sibling local pub const could happen to carry the same string at the source while pointing at a different &'static allocation — surfaces as one of two silent failure modes at chart-consumption time: Helm’s chart-schema parser refuses to open the rendered chart-directory (“Error: Chart.yaml file is missing”) far from the drift commit, or the sibling [caixa_flux::cluster_bundle]’s future per-chart-directory resolver — a per-cluster snapshot bundle that re-lists the chart-dir contents by filename — silently returns None at cluster-side feira app deploy time. The equality + &'static static-data identity pin (helm_chart_yaml_filename_re_export_points_at_caixa_core_canonical) closes the drift footgun at caixa-helm build time. Peer to the HELM_CHART_API_VERSION / HELM_CHART_TYPE_APPLICATION re-exports on the sibling canonical-Helm-chart-schema-body-axis surface — completes the per-lareira-<nome>-chart-directory (filename, apiVersion, type) canonical-scalar-axis re-export triple every rendered chart declares at its top-level metadata file. 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 — re-export of the lifted caixa_core::HELM_VALUES_KEY_ENABLED so the values-block toggle every rendered lareira-<nome> chart’s values.yaml carries under its DEFAULT_LIBRARY_NAME wrap key lives in exactly one place across every caixa renderer. The single production-code call site consuming it is [build_values_yaml]’s block.insert(HELM_VALUES_KEY_ENABLED.to_string(), …) (formerly an inline "enabled".to_string() literal at caixa-helm/src/lib.rs:389); the peer test-fixture navigators pinning the default-off round-trip (values_yaml_wraps_under_pleme_computeunit_key, values_yaml_wrap_key_follows_library_name_override) also consult the re-export so a rebrand of the library-chart’s per-values enable-toggle axis lands at one const and reaches every consumer by construction. A drifted local pub const HELM_VALUES_KEY_ENABLED: &str = "…" (or any sibling per-renderer variant that inlined a stale "enabled" / "enable" / "disabled" literal) would silently emit a values block whose per-values enable-toggle lands under one key while [caixa_flux::cluster_bundle]’s HelmRelease spec.values.<library>.enabled per-cluster override lands under another — Helm’s per-values merge treats them as sibling scalars, the enable-toggle the library chart’s own template consults never sees the flip, and the workload silently comes up with the library chart’s admission-time defaults instead of the per-cluster override the operator set. Same shape as the DEFAULT_LIBRARY_NAME / KUBE_KEY_SPEC / HELM_CHART_API_VERSION re-exports on the sibling canonical-Helm-load-bearing-string / canonical-K8s-CR-body- key / canonical-Helm-chart-schema-apiVersion axes. Canonical pleme-computeunit library-chart values-block enable-toggle key — the enabled: <bool> axis every lareira-<nome> chart’s values block carries under its DEFAULT_LIBRARY_NAME wrap key, and every caixa-flux-rendered HelmRelease spec.values.<library>.enabled per-cluster override targets. The single source of truth all four downstream consumers reach for:
HELM_VALUES_YAML_FILENAME: Canonical Helm 3 per-chart-directory values-file filename every rendered lareira-<nome> chart carries at its top-level directory — re-export of the lifted caixa_core::HELM_VALUES_YAML_FILENAME so the fixed lookup name Helm’s chart-schema parser (helm dependency build, helm lint, helm template, helm install) consults at chart-open time to locate the per-chart values block that HELM_VALUES_KEY_ENABLED toggles under its DEFAULT_LIBRARY_NAME wrap key lives in exactly one place across every caixa renderer. The single production-code call site consuming it is render_chart_for_servico’s ChartDir assembly where the values file’s per-ChartFile path axis is set (the sole emitter site the prior inline PathBuf::from("values.yaml") literal sat at); every test-side round-trip navigator that reaches into the rendered ChartDir by the values filename (the per-chart-values-field sweep tests + ChartDir::write_to post-write existence pin) now consults the same &'static str, so a rebrand of the Helm 3 values-file axis (any per-fork defaults.yaml / Helm 4 values-file rename the upstream packaging spec might adopt) lands at one const and reaches every consumer by construction. A drifted local pub const HELM_VALUES_YAML_FILENAME: &str = "…" at this crate — the canonical drift footgun where a sibling local pub const could happen to carry the same string at the source while pointing at a different &'static allocation — surfaces as one of two silent failure modes at chart-consumption time: Helm’s per-chart values-loader silently falls back to the empty values block (helm template emits the library chart under its admission-time defaults, the workload comes up disabled or without any per-Servico M2 overlay applied) far from the drift commit, or the sibling [caixa_flux::cluster_bundle]’s future per-chart-directory resolver — a per-cluster snapshot bundle that re-lists the chart-dir contents by filename to route per-cluster values overlays through the canonical values file — silently returns None at cluster-side feira app deploy time. The equality + &'static static-data identity pin (helm_values_yaml_filename_re_export_points_at_caixa_core_canonical) closes the drift footgun at caixa-helm build time. Peer to the HELM_CHART_YAML_FILENAME re-export on the sibling canonical-Helm-per-chart-directory-metadata-file-axis surface — completes the per-lareira-<nome>-chart-directory (Chart.yaml, values.yaml) canonical-per-chart-directory-filename- axis re-export pair every rendered chart declares as its two schema-load-bearing ChartDir::files entries. 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_SPEC: Canonical K8s CR top-level spec key. Re-export of the canonical caixa_core::KUBE_KEY_SPEC so the per-kind body key lives in exactly one place across every caixa renderer — caixa-helm’s build_values_yaml (the upstream ComputeUnit YAML’s spec.* axis the rendered lareira-<nome> chart’s values block re-routes through the library alias) now consults the same &'static str as the peer caixa-flux / caixa-mesh renderers’ KUBE_KEY_SPEC re-exports. The prior inline "spec" literal at the production- code call site would have let a typo (e.g. "Spec", "specs", "spec_") silently emit a values block that drops every typed ComputeUnit-side field (module, trigger, capabilities, resources, serviceAccount) at the rendered chart’s landing site — the Error::MissingField("spec") diagnostic now threads the same &'static str through the diagnostic surface so the error message stays byte-identical to the key it failed to find. Same shape as the DEFAULT_LIBRARY_NAME re-export on the sibling canonical-Helm-load-bearing-string axis. 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.
STANDALONE_LAREIRA_ENABLED_DEFAULT: Canonical substrate-side default for the values.<library>.enabled scalar-value toggle every 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. Re-export of the canonical caixa_core::STANDALONE_LAREIRA_ENABLED_DEFAULT so the substrate-side default the standalone per-chart path seeds under the sibling HELM_VALUES_KEY_ENABLED leaf-scalar-key lives in exactly one place across every caixa renderer. Consumed by RenderOpts::default’s enabled_default field seed (formerly an inline false scalar-value literal at caixa-helm/src/lib.rs:700); the peer test-fixture navigators pinning the default-off round-trip also consult the re-export so a rebrand of the per-values-block child-chart-enablement-toggle scalar on the standalone per-chart path lands at one const and reaches every consumer by construction. Semantically distinct from — and inverse of — the peer [caixa_flux::CLUSTER_BUNDLE_LAREIRA_ENABLED_DEFAULT] on the composition per-cluster-HelmRelease values-overlay path (which force-ons the child chart under the substrate-side composition path); the two peer scalar-value defaults name mirror-symmetric per-path child-chart-enablement-toggle-scalar-value defaults at the exact same values.<library>.enabled sub-block position on the standalone per-chart-values.yaml path (this re-export) and the composition per-cluster-HelmRelease values-overlay path (the peer re-export). Same shape as the DEFAULT_LIBRARY_NAME / KUBE_KEY_SPEC / HELM_VALUES_KEY_ENABLED re-exports on the sibling canonical-Helm-load-bearing-string / canonical-K8s-CR-body- key / canonical-Helm-per-values-block-enable-toggle-key axes. See caixa_core::STANDALONE_LAREIRA_ENABLED_DEFAULT for the full lift rationale. 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.

Functions§

render_chart_for_servico: Render a per-program lareira- chart from a Caixa Servico + its loaded ComputeUnit YAML.
render_chart_for_servico_with: render_chart_for_servico with explicit options.
servico_spec_and_m2_overlay_entries: Local re-export of the canonical caixa_core::servico_spec_and_m2_overlay_entries — the composed per-Servico value-block splice helper this crate’s [build_values_yaml] and the peer [caixa_flux::programs_yaml_entry] both now route their two-step spec.* field-splice + M2 typed-slot overlay through. The single production-code call site consuming it is [build_values_yaml]’s inner splice loop (formerly two hand-written for-loops chained around string_keyed_entries + servico_m2_overlay); re-exported so the shared composition contract lives in exactly one place across both per-Servico renderers — a future author reading caixa_helm::build_values_yaml finds the composition helper immediately without an extra use caixa_core::… line, and a rebrand of the composition axis (e.g. a swap of the or_insert precedence rule once per-Aplicacao operator overrides land) reaches both renderers through one canonical &'static function pointer. Same shape as the peer COMPUTEUNIT_SPEC_KEY_MODULE / COMPUTEUNIT_SPEC_KEY_TRIGGER / COMPUTEUNIT_SPEC_KEY_CAPABILITIES re-exports on the sibling canonical-ComputeUnit-CRD spec.* axis — extends the shared-composition discipline the per-spec.* sub-block re-export triple establishes onto the composed spec.*+M2 splice axis every per-Servico renderer navigates. 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:

Type Aliases§

ChartFile: One file in the rendered chart — (path, contents) pair every render_chart_for_servico-rendered lareira-<nome> chart-tree leaf lands at (Chart.yaml, values.yaml, README.md).

Crate caixa_helm

Crate caixa_helm Copy item path

§Output shape

§Why a separate crate

§V0 contract

§What this is NOT

Structs§

Enums§

Constants§

Functions§

Type Aliases§

Crate caixa_helm