Constant HELM_CHART_KEY_DEPENDENCIES 

pub const HELM_CHART_KEY_DEPENDENCIES: &str = "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.

The single source of truth every consumer that names the per- Chart.yaml top-level dependency-list key reaches for:

• caixa-helm’s ChartYaml struct’s dependencies field (the sole production serialize-side site the wire-key appears at — Rust’s default field-name-verbatim serde emission means no #[serde(rename = "…")] attribute pins the key today; the paired drift-detection pin at [caixa-helm]’s 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 hostile refactor could otherwise leave silent: a rename of the Rust field to Vec<ChartDependency> under a deps:/chartDependencies:name, or an accidental#[serde(rename_all = “camelCase”)]attribute onChartYaml` that stays a no-op on the four identity-mapped top-level keys today but silently activates on a future multi-word field addition);
• every test-side navigator that inspects the serialized [caixa-helm]-emitted Chart.yaml YAML mapping by the top- level per-chart-dependency-list key.

A drift on this per-Chart.yaml top-level list-container axis-key would silently rebrand the wire key — Helm’s chart-schema parser silently drops the dep list from the parsed chart-metadata shape, helm dependency build finds no chart to vendor, and every rendered lareira-<nome> chart’s install fails with template: no template ... associated with template ... far from the drift site with no field naming the top-level-list-key-drift root cause. The failure mode is byte-shape-symmetric with the peer HELM_CHART_DEPENDENCY_KEY_NAME drift narrative (which closes on the per-entry name axis one level down) — both close on the helm dependency build / apply-time path.

The PRIME DIRECTIVE duplication-budget rule (THEORY.md §I.3.5) promotes the top-level list-container axis-key to a typed substrate-side &'static str on the same trajectory the peer HELM_CHART_KEY_TYPE / HELM_CHART_KEY_APP_VERSION / HELM_CHART_KEY_API_VERSION top-level axis-key lifts (d29bc23, cc44e4b) established — completes the parent+children canonical-pin pair with the already-lifted per-dependencies[]-entry sub-mapping tetrad. Where the child tetrad pins the byte-shape of each per-dep entry’s four sub-mapping keys (name, version, repository, alias), this parent-axis lift pins the byte-shape of the top-level list-container the tetrad mounts under, so the full (dependencies: → [name/version/repository/alias]) per-Chart.yaml dependency-list schema surface lives at one canonical &'static str per YAML axis-key. Same “parent list-container + child sub-mapping tetrad” canonical-pin discipline the peer SUPERVISOR_KEY_CHILDREN (parent) + SUPERVISOR_CHILD_KEY_CAIXA / SUPERVISOR_CHILD_KEY_VERSAO / SUPERVISOR_CHILD_KEY_RESTART (children) pair (40cc4e5, ef912df) established on the sibling per-:supervisor :children axis, and the peer M2_KEY_UPGRADE_FROM (parent) + M2_UPGRADE_FROM_KEY_FROM / M2_UPGRADE_FROM_KEY_INSTRUCTIONS (children) pair established on the sibling per-:upgrade-from axis.