pub const FLEET_PROGRAMS_KEY_VERSAO: &str = "versao";Expand description
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.
Peer of FLEET_PROGRAMS_KEY_NAME, FLEET_PROGRAMS_KEY_APLICACAO,
and M3_KEY_PLACEMENT on the same fleet-programs values schema —
FLEET_PROGRAMS_KEY_NAME carries the per-entry Servico-name
discriminator (each :membros row’s :caixa binding),
FLEET_PROGRAMS_KEY_APLICACAO carries the per-entry parent-graph
annotation, M3_KEY_PLACEMENT carries the M3 placement overlay
cloned per entry, and this constant carries the per-entry version-
constraint the operator’s resolver reads to fetch the correct
caixa.lisp release. Together the four per-entry keys (plus the
top-level FLEET_PROGRAMS_KEY_PROGRAMS array key) name every axis
one programs[] entry the caixa-mesh fan-out emits contributes to
the substrate operator’s read shape.
One production consumer writes this key:
[caixa_mesh::programs_for_aplicacao] — the Aplicacao-side
per-:membros entry-builder writes the per-entry version-
constraint at this exact key (seeded from each :membros row’s
:versao binding), at caixa-mesh/src/lib.rs’s per-member
entry.insert("versao".into(), …) call. Unlike the peer
FLEET_PROGRAMS_KEY_NAME axis (written by both caixa-flux’s
per-Servico entry builder and caixa-mesh’s per-:membros builder
— a Servico rendered standalone through the caixa-flux path resolves
its own :versao from its caixa.lisp root and hands it to the
resolver via a distinct path), the per-:membros version-constraint
annotation is emitted only by the caixa-mesh Aplicacao-side fan-out.
Until this lift landed the caixa-mesh emitter carried the bare
"versao" byte inline at its entry.insert("versao".into(), …)
call — a partial single-source where three of four per-entry
fleet-programs axis keys were canonical
(FLEET_PROGRAMS_KEY_NAME via 030a63f,
FLEET_PROGRAMS_KEY_APLICACAO via cc69ac2, M3_KEY_PLACEMENT)
and the fourth was scattered. Lifting the fourth key completes the
fleet-programs values-schema single-sourcing across every per-entry
axis; every future per-graph aggregator, per-:membros resolver,
per-entry version-constraint consumer inherits the same &'static str by construction. A future schema-key rebrand on the per-entry
version-constraint axis (a namespaced pleme.pleme.io/versao for
multi-tenant aggregator isolation, or version: for parity with
upstream conventions, or typed constraint: on the ABSORPTION-
ROADMAP.md M4 typed-resolver trajectory) lands at the one const
rather than scattered across every future per-emitter/per-resolver
site.
Byte-identical to the Membro::versao field name on the M3
AplicacaoSpec today — both resolve to the same six-byte "versao"
literal — but semantically distinct: Membro::versao names the
author-side :versao slot on each :membros row (the typed
version-constraint slot every defcaixa populates on its
:membros list), while this constant names the
lareira-fleet-programs library chart’s per-entry version-
constraint axis (spelled per the chart’s values.schema.json — a
separate schema contract, one whose future rebrand can land
independently of the author-side slot-name axis). Splitting the two
lets each schema’s future rebrand land at its canonical const /
field definition without coupling the author-side slot-name axis to
the fleet-programs values-schema axis (or vice versa) — the same
discipline the sibling FLEET_PROGRAMS_KEY_APLICACAO doc-comment
establishes vs. the CaixaKind::Aplicacao enum-variant tag.