caixa-flux 0.1.20

caixa-flux — typed renderer that emits the FluxCD-side fragments a caixa Servico needs in the cluster's GitOps tree.

Same naming convention as [caixa_helm] (renders per-program Helm charts) and [caixa_flake] (renders flake.nix): caixa-<target> = "Rust crate that takes a typed [Caixa] and emits the canonical source for <target>".

Two paths, two surfaces

Per theory/META-FRAMEWORK.md §I, two equally-canonical ways exist to deploy a caixa Servico:

1. Aggregator path ([programs_yaml_entry]) — the cluster has exactly one lareira-fleet-programs HelmRelease whose values contain a programs: array. Adding a Servico = adding one entry to that array. Higher leverage — one HelmRelease handles the whole fleet's worth of caixas, fewer reconciler events, simpler cluster surface. This is what feira deploy uses by default.

2. Bundle path ([cluster_bundle]) — emit a fresh GitRepository

   • HelmRelease + Kustomization trio for the caixa's own per- program chart (rendered by caixa-helm). Used for one-off / isolated services where the aggregator overhead is undesirable (e.g. alpha workloads with non-standard images, breakglass tooling).

V0 contract

use caixa_core::Caixa;
use caixa_flux::programs_yaml_entry;

let 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 entry: serde_yaml::Value = programs_yaml_entry(&caixa, &cu_yaml)?;
// → { name: hello-rio, namespace: tatara-system, module: { source: ... }, ... }

What this is NOT

• Not a Flux CLI wrapper — bytes only.
• Not the operator deploy bundle — that lives in pleme-io/caixa/operator-flux/.
• Not an installer — feira deploy orchestrates the I/O of writing to a GitOps repo + opening a PR.