Please check the build logs for more information.
See Builds for ideas on how to fix a failed build, or Metadata for how to configure docs.rs builds.
If you believe this is docs.rs' fault, open an issue.
tatara-env — typed environments that compose tatara-domain resources into one validated stack snapshot.
What it solves
Domains in isolation are useful — (defgateway …) is a typed
gateway, (defciliumnetworkpolicy …) is a typed network
policy. But a real platform is the composition — gateway
- network policies + monitors + BPF programs + storage + policy, all coherent, all referencing each other. Without a composition layer, every consumer (arch-synthesizer, FluxCD manifest writer, tameshi attestation builder) reinvents the "collect heterogeneous resources" wheel.
tatara-env is the layer. One typed Env snapshot per stack,
produced by walking a program's top-level forms and dispatching
each through the global domain registry. The output is a
stable, serializable graph downstream pipelines consume.
Authoring shape
; …more resource forms…
compile_into_env reads the whole list, finds the one
(defenv …) form, treats every other form whose head is a
registered domain keyword as a resource, ignores comments +
macros + non-domain forms.
What's compounding
- Cross-resource validation — a future
validatepass walks the resources looking for dangling refs (adefservicepointing at asecretthat doesn't exist). - Stable serialization — JSON Schema-friendly output for the rest of the pipeline.
- Typed FluxCD / Helm / Pangea emission — env →
per-platform manifests via
arch-synthesizer. - Diff-based rollouts — BLAKE3 the env JSON; only changed resources reapply.
Every one of those bolts on top of the typed graph this crate produces.