diene Ecosystem Map

01 · Big picture

Five layers, one direction of control

Physically Git repositories on GitHub.com, plus an OCI registry where CI pushes the built images and charts.

What it holdsEvery input. Nothing in the fleet is configured any other way.

Humans editfleet/registry/, each <platform>.carbon repo (example: argon.carbon) and each service repo (example: argon.zinc).

Machines editfleet/platforms/. Example: Kargo edits platforms/argon/landscapes/pichu/zinc.yaml.

Indigo frame = a human-edited folder; orange frame = a machine-edited folder. A human never edits platforms/.

Physically One virtual machine running k3s, a one-node Kubernetes cluster. When the VM boots, cloud-init decrypts its first secrets with SOPS and starts everything else.

What runs on itArgoCD, Kargo, fleet-operator, Infisical, logto-operator, erbium, grafana-operator and argo-rollouts (analysis only).

What it doesReads Git and writes the desired state into the host clusters and the data vendors.

What it never doesRun product workloads. Its landscape is called primordial, and no user traffic reaches it.

If it is downServing clusters keep serving, and secrets already copied into clusters stay there. Only changes pause: deploys, promotions and secret rotation. It is safe to be down for hours.

Source: concepts/seed-cluster.md (single-node k3s on one VM, SOPS via cloud-init) and ARCHITECTURE.md §3 (Infisical runs on Primordial; safe to be down for hours).

Physically Managed Kubernetes clusters at cloud providers: DigitalOcean, AWS and Oracle Cloud. fleet-operator creates each cluster through the provider's API.

How a cluster is named<landscape>·. Example: raichu·opal. The mark (opal, ruby, emerald) tells you the provider.

Which landscapespichu (dev tier), pikachu (staging), raichu (production, Singapore), ampharos (production, US). mew and celebi are DNS names only, with no clusters.

Two clusters, one landscaperaichu·opal and raichu·ruby share one dataset. They are blue/green siblings.

Traffic pathA user's request goes to DNS, then the provider's cloud load balancer (fixed IP), then the cluster's Gateway (TLS), then the pods.

"copper" is an example second service. Source: ARCHITECTURE.md §2 (cluster = landscape × mark; gems share a dataset) and §3 (provider load balancer, TLS at the Gateway).

Physically 3 kinds of machine: your laptop, a throwaway CI machine, and ENTEI (one shared Kubernetes cluster that hosts virtual clusters).

How one startspls env up --profile <name>. Garden builds the whole instance. See section 08.

DataEach instance has its own local databases (CNPG, Dragonfly, MinIO). Only castform runs on forks (copies) of real data. See section 09.

What it never doesWrite to serving data or to Infisical.

Source: environments.md (profiles and hosts); ARCHITECTURE.md §3 (ENTEI hosts the vclusters and is never a serving landscape).

Control flows one way: Git → Primordial → clusters and vendors. Nothing below writes back up, except the machine-written fleet/platforms/ files.

8

landscapes (environment kinds)

4

serving host landscapes: pichu, pikachu, raichu, ampharos

2

DNS-only virtual landscapes: mew, celebi

2

Helm charts per service (the 2-chart law)

12

diene custom resource types (CRDs)

5 s

health poll that drives all public DNS

Tap any box: what it is, where it runs, which repo owns it

Gitsource of truth · humans edit here

▼ pulled by ArgoCD (SCM discovery of *.carbon) ▼

Control plane · Primordialone permanent cluster · not a serving landscape

▼ renders + syncs app charts, CRs, DNS ▼

Serving plane · registered host landscapesreal data · real users

Development plane · Garden instancesno real data, except castform (fork of real data)

Outside · must survive Primordial lossexternal services

Pick a box above

Each box opens a plain description: what it does, where it runs, and which repo or node owns it.

Sources: ARCHITECTURE.md §1–§3, §8–§9; environments.md §1.

02 · LPSM, the one name

Four slots name every workload

In one line LPSM is a coordinate, not a machine. Four slots — Landscape · Platform · Service · Module — name every deployed workload in the fleet.

Type a name: module . service . platform [ . instance ] . landscape

L · LandscapeThe environment kind: raichu, lapras, castform…

P · PlatformA product family. Registered by creating its .carbon repo. Example: argon.

S · ServiceOne repo, one deployable: .<svc>. Example: argon.zinc.

M · ModuleOne named piece inside a service: an API, a database (maindb), a cache.

m modules servicep platformi instancel landscape

Sources: ARCHITECTURE.md §2 (LPSM, the closed roster of landscapes). Colours follow the legend used by the name builder in tab 3.

Physically DNS names. A serving workload is reached at <module>.<service>.<platform>.<landscape>.cluster.atomi.cloud — the coordinate reversed: module first, landscape last.

Press ▶ Play: each coordinate slot flies to its place in the hostname — in reverse order.

Where: ARCHITECTURE.md §2, §4 (DNS is derived, never registered)

Host landscapeThe wildcard *.<l>.cluster.atomi.cloud points at the load-balancer IPs of that landscape's healthy clusters (the ones with traffic: true passing the 5-second health poll).

Virtual landscapemew and celebi get an explicit record per service, answered by the healthy host landscapes named in the envelope.

Garden instanceA Garden workload adds the instance: <module>.<service>.<platform>.<instance>.<landscape>.<zone>. The zone comes from operator policy, never from the app.

Sources: ARCHITECTURE.md §2 (hostname forms), §4 (wildcards, v-landscape records); concepts/environments.md §1.1 (instance surface name).

In one line One coordinate, four naming systems. The same LPSM value decides the public hostname, the secret address, the Helm name and outside resource names — nothing is named by hand.

Try it: build the names from a coordinate

Module

Service

Platform

Landscape

Instance (Garden only)

Dependency module

Dependency class

m modules servicep platformi instancel landscape

noteOpen on your agenda

Error records (the Problem custom resource) are named {service}.{module}.{landscape}.{version} today, which leaves out platform. A proposal to name them in full LPSM order is waiting on your answer in the error-records agenda item.

Sources: ARCHITECTURE.md §2, §7 (secret address), §9 (external names); goals/instance-segment-naming.md; goals/helm-wrapper.md (fullname rule).

Physically The instance is a naming add-on, not a fifth slot. It is added only where a physical name must be unique: one developer, one CI run, one preview.

Press the buttons above to compare the two roles.

Where: concepts/environments.md §1.1 (allocation ID + generation is the only fence)

Where it appearsHostnames, cluster and backing namespaces, vcluster names, provider children, tenants, and allocation records — nowhere else.

What it never doesSelect or fence a cleanup. The instance may be written down as cleanup evidence, but only allocation ID + generation decides what is deleted or fenced.

ExampleA castform preview gets a petname like otter-beats-potato; the same manifest re-requested while live simply joins that preview.

Sources: ARCHITECTURE.md §2 (instance is a Garden projection, not a fifth slot); concepts/environments.md §1.1 (cleanup selection), §3 (petname).

03 · The eight landscapes

A landscape is a rule set, not a place

Physically A landscape is a row of settings, not a machine. It fixes four rules for everything deployed in it; the machines come from clusters, and several clusters can share one landscape.

Four rulesA landscape fixes secret class, data posture, lifetime, network edge.

Place vs consistencyLocation is a property of a cluster. Consistency (one dataset) is a property of a landscape.

Which are Garden copiesSix landscapes are Garden workload profiles (development copies). Primordial and serving are not.

Adding oneA new landscape is a new row of settings, never new machinery.

Source: concepts/environments.md §0 (the landscape matrix requirement: a landscape row is configuration).

In one line Six profiles, one deployment graph. The same Garden machinery runs all six; only the settings change — including which build modes each profile allows.

sync = hot reload from source.

Build modes: sync = hot reload from source; build-local = build the image on this machine; target-pull = pull the exact image CI built (by digest)

All six Garden profiles side by side build modes · data · secrets · edge

Landscape	Runs on	Build modes	Data	Secrets	Edge
lapras	laptop k3d, kept	sync · build-local · target-pull	local CNPG, Dragonfly, MinIO, Mailpit, local Logto	read-only lapras seed; no writes	Boron direct to approved services
ditto	fresh cluster per test run	build-local · target-pull	deterministic fixtures	read-only ditto seed + demo credentials	loopback-only local kgateway
rotom	laptop k3d, offline, kept	sync only	signed offline bundle only	fake local store; zero keys	loopback-only local kgateway
absol	fresh cluster per run, offline	build-local from bundle	same bundle as rotom	fake local store; zero keys	loopback-only local kgateway
eevee	vcluster on ENTEI, one per person	sync · build-local · target-pull	local dependencies on host volumes	read-only eevee seed	ENTEI shared edge, real HTTPS
castform	vcluster on ENTEI, one per preview	target-pull only	forks of Neon, Upstash, Tigris	read-only castform seed + short-lived doors	ENTEI shared edge

Build modes: sync = hot reload from source; build-local = build the image on this machine; target-pull = pull the exact image CI built (by digest).

Source: environments.md §1.2 (posture table). Watch one come up piece by piece in section 08 · Garden in motion.

Physically ENTEI is one registered cluster with role anonymous-vcluster-host and traffic: false. It is not a landscape; it hosts the eevee and castform virtual clusters.

ENTEI is not a ninth landscape

ENTEI is one registered cluster with role anonymous-vcluster-host and traffic: false.
It hosts the eevee and castform virtual clusters (vclusters). It runs no application, no shared Logto and no shared database.
It shares only the public gateway (kgateway), cert-manager, DNS/TLS for hosted names, and the exposure materializer.
If ENTEI dies, eevee and castform go down together. Serving is not affected.

Source: environments.md §1.1 (the ENTEI boundary). Try the button above the picture.

04 · How each landscape starts

Three ways in: bootstrap, Git, or `pls`

Physically One bootstrap, ever. The seed-cluster bootstrap creates Primordial — a single VM running a one-node k3s cluster — and its root of trust is the SOPS root key.

1 / 4

What it createsPrimordial, ArgoCD, Infisical and the fleet root app. After that, Primordial's own ArgoCD keeps it in line with Git.

Created outside itThe Cloudflare zone and the ledger bucket.

Never stoppedThere is no "switch Primordial off". If it dies: rebuild, Git re-syncs, controllers adopt everything back from the ledger.

Sources: concepts/seed-cluster.md (single-node k3s on one VM, SOPS via cloud-init); ARCHITECTURE.md §10 (the L0 seed sequence).

Physically A serving landscape starts with one pull request to fleet/registry/. A new platform or service starts with no fleet pull request at all — creating its GitHub repo is the registration.

New landscape or clusterOne pull request to fleet/registry/. The cluster controller provisions it; the platform opts in by listing the landscape in its platform.yaml.

New platformCreate the .carbon repo. SCM discovery does the rest — no fleet pull request.

New serviceCreate the .<svc> repo. The materializer writes the row stubs and the machine roster; no fleet pull request.

ReleaseKargo edits one row file per stage. Watch that flow in section 07 · Deploy, animated.

Traffic on/offSet traffic: true|false on the cluster. Off leaves DNS in about 5 seconds; the cluster keeps running.

Source: ARCHITECTURE.md §11 (ops traces), §8 (name-is-registration).

Physically pls is a command-line tool on your machine. It is shipped by the garden-k3d-profiles node and runs Garden, the one deployment graph behind all six development profiles.

Start onepls env up --profile , with a build mode: --sync, --build-local, or --target-pull --artifact <digest>.

Stop or resetpls env down --profile  stops it; pls env reset --profile  deletes the edge objects, then the cluster.

Check firstpls env doctor --profile  is read-only: it checks without changing anything.

Watch it happenThe piece-by-piece build of each profile is animated in section 08 · Garden in motion.

Source: goals/garden-k3d-profiles.md (the pls command surface).

05 · Planes

Primordial decides, clusters serve

In one line A plane is a group of machines with one job. Four of them: control, serving, development, edge. Control flows one way: from Primordial outward, never back.

Control planePrimordial. ArgoCD, Kargo, the operators, Infisical. Outside the landscape registry. Never load-bearing for traffic.

Serving planeHost-landscape clusters. Each sits behind a cloud load balancer with fixed IPs. TLS ends at the cluster gateway (cert-manager, Let's Encrypt).

Development planeGarden instances. k3d on laptops, nsc in CI, vclusters on ENTEI. Argo and Kargo never run inside these.

Edge planeDNS + edge docs. Route 53 is primary, Cloudflare is secondary. The fleet, landscape and catalog docs are published twice: R2 and S3/CloudFront.

Also called a plane: the execution plane

The execution plane is the machinery that builds diene itself (the ratchet: nodes, rounds, reviews). Its identifiers never appear in shipped docs. See section 13.

Sources: ARCHITECTURE.md §3 (the physical fleet), §4 (DNS and edge docs).

In one line Every dependency is three layers. An app holds the contract; the data plane serves requests; the provisioning plane creates and resizes — and never sits on the traffic path.

Layer	What it is	Where it lives
Contract	Endpoint, credentials, behaviour. Same for every realization.	the app's config + secret names
Provisioning plane	Creates and resizes the dependency. Never on the traffic path.	Primordial (vendor APIs)
Data plane	The only layer that requests actually traverse.	vendor or in-cluster engine

Source: ARCHITECTURE.md §7 (T4-LAYERS, three layers of dependency design).

In one line delivery says where a dependency is realized — at a vendor, in every cluster of the landscape, or inside one Garden instance.

delivery	Meaning	Used for
external	A vendor's data plane, reconciled from Primordial	Neon (Postgres), Upstash (KV), Tigris / R2 / S3 (storage)
replicated	Fanned out to every eligible cluster of the landscape	Dragonfly cache only (one instance per claim)
local	Applied directly inside one Garden instance	CNPG, MinIO, Dragonfly KV + cache, Mailpit

Source: ARCHITECTURE.md §7 (delivery is module-level and explicit on every type).

Sources: ARCHITECTURE.md §1 (axiom 7), §3, §4, §7 (T4-LAYERS, delivery); environments.md §1.2; rules/AUTHORING-RULES.md (execution plane).

06 · Charts

The 2-chart law, used twice = 4 charts per platform

Physically Two Helm charts inside every service repo. One repo, one version number, two charts: the app chart and the primordial chart.

App chartRuntime only: the Deployment, the Service, the database-init hook Job. Destined for the landscape's clusters.

Primordial chartCustom resources only: PlatformDependency, WebhookRoute, Problem, LogtoApp… Destined for Primordial, where the controllers read them.

One pair = one rowOne materialization of the pair is one row file in fleet/platforms//landscapes/<l>/<svc>.yaml. The pair contains everything the service needs in isolation.

Watch it moveThe full deploy animation — registry to Primordial to five clusters — is section 07.

Sources: ARCHITECTURE.md §1 (axiom 5, the 2-chart law), §8 (repos, release trace).

Physically One Helm chart in a folder of the fleet repo: fleet/registry/charts/diene-platform, the compiler chart.

What it rendersPer platform: the Platform custom resource, the Kargo Project with one pipeline per service, and the platform ApplicationSet.

Git-sourced, not OCIThe compiler chart is the only chart read from Git, on the moving tag machinery-stable. Every other chart in the fleet is published as OCI.

One version for the whole fleetA bump is one merge request, a green run on the canary platform, then the tag fast-forwards. Rollback = move the tag back.

The canary platformA synthetic platform rides main with auto-sync off: a human reviews the rendered diff before anything syncs. Real platforms ride machinery-stable.

Sources: ARCHITECTURE.md §8 (three sources, compiler-chart versioning); goals/fleet.md (tag mechanics).

Physically A row file is one small YAML file — one per service per landscape in fleet/platforms//landscapes/<l>/<svc>.yaml. Kargo edits it to promote.

Two independent dimensionsLandscape and cluster overlays are separate files, never one combined values.<landscape>.<cluster>.yaml.

The chart is the config homeA row values: block is a short-lived ops knob (scale now, flip a flag). It is folded back into the chart at the next release; a probe flags overrides older than 7 days.

Try it: promote one release of zinc through the stages

Where config values come from, in order last one wins

values.yaml: the chart's base.
values.<landscape>.yaml: the landscape overlay.
values.<cluster>.yaml: the cluster overlay, usually one identity value.
The row file's optional values: block: a short-lived ops override, folded back into the chart at the next release. A probe flags overrides older than 7 days.

Landscape and cluster are two independent stacked dimensions, never one combined file.

Sources: ARCHITECTURE.md §1 (axiom 5), §8 (row values, Kargo per-service promotion); goals/helm-wrapper.md (overlays).

07 · Deploy, animated

Tap a repo, watch its charts land

One release, charts onceA repo publishes its charts once. ArgoCD on Primordial fans them out.

P · primordial chartLands on Primordial, once per landscape.

A · app chartLands on every cluster of every landscape in platform.yaml.

In one line Tap a repo and count how many charts it ships, how many Applications ArgoCD makes, and where each one lands, including the databases its PlatformDependency creates.

Tap a repo (in the picture or here)

Landscapes listed in argon.carbon's platform.yaml

Aapp chart: the pods, Service and db-init Job. Goes to every host cluster.

Pprimordial chart: custom resources (orders for the controllers). Goes onto Primordial, once per landscape.

→orange = a Git or Kargo edit

→green = a controller acting

0charts shipped

0Primordial Applications

0app Applications (clusters)

Tap argon.carbon to start.

Cluster names (opal, ruby, emerald) are examples. raichu has 2 clusters here to show the per-cluster fan-out.

Sources: ARCHITECTURE.md §8 (repos, discovery, three sources, g1/g2, Kargo per-service promotion, release trace), §9 (controllers), secrets-chain.md (Platform CR write path).

08 · Garden in motion

`pls env up`, piece by piece

One graphGarden runs one deployment graph for all six development profiles. pls drives it.

Only settings changeWhere the cluster runs, the network, secrets and data differ per profile.

No Argo, no KargoThey never run inside these clusters.

In one line Three questions pick the profile: whose machine (yours, a throwaway, or the shared ENTEI host) · what data (local copies or a fork of real data) · how long (kept, one run, or leased).

Writing code on your laptop, with internet — everyday work, hot reloadlapras
No internet at all — plane, train, outage; keep working offlinerotom
A CI test run — integration tests that must repeat exactly, onlineditto
An offline CI run — hermetic tests with captured evidenceabsol
Need a real HTTPS URL — share your dev stack, work from any machine, let your agent use iteevee
See one change against real data — review a preview before it shipscastform

lapras vs dittoBoth connected. lapras is kept, so you iterate fast and your data survives; ditto is a fresh cluster every run, so nothing carries over but every run repeats exactly.

rotom vs absolSame offline laws. rotom is kept, so you can iterate offline; absol is one clean run — fresh cluster, evidence captured, deleted unconditionally.

eevee vs castformBoth on ENTEI. eevee is yours and editable but has no real data; castform is a frozen fork of real data, built to be reviewed, not edited.

lapras vs eeveeBoth for writing code. lapras is on your laptop next to your files, but private (tunnel, no public URL); eevee has a real public URL but lives on a shared, capped host.

All six, side by side

lapras

Where: Your laptop — k3d cluster in Docker, one per developer per repository
Network: Full network; you reach services through Boron, a private outbound tunnel. No public route
Real data?: No — local copies only (CNPG, Dragonfly, MinIO, Mailpit, local Logto)
Lifetime: Kept: down keeps the cluster; reset deletes it
Cost: not stated
Startup time: not stated

ditto

Where: A fresh throwaway cluster per run — k3d on a laptop, or the built-in k3s of a one-shot nsc CI machine
Network: Loopback only; egress denied by default; never Boron, never public DNS
Real data?: No — deterministic versioned fixtures, same every run
Lifetime: One run, never reused; nsc destroy --force always runs in CI
Cost: not stated
Startup time: not stated

rotom

Where: Your laptop — k3d cluster, kept; offline
Network: Zero network, proven before the cluster exists; loopback-only local kgateway
Real data?: No — everything loads from a signed offline bundle
Lifetime: Kept across down/up
Cost: not stated
Startup time: not stated

absol

Where: A fresh throwaway cluster per run (laptop or one nsc CI machine); offline
Network: Denied before the cluster is created; loopback-only local kgateway
Real data?: No — the same signed bundle and fixtures as rotom
Lifetime: One run; deleted unconditionally after evidence capture
Cost: not stated
Startup time: not stated

eevee

Where: Your own virtual cluster on ENTEI, the fleet's one shared development host
Network: ENTEI shared edge: real public HTTPS on your claimed hostnames; no inbound callbacks
Real data?: No — local dependencies on host-backed volumes; no fork door
Lifetime: Renewable lease, days or weeks; 4 slots in the fleet, at most one per person
Cost: not stated (capacity per allocation: 6 CPU · 16 Gi · 120 pods)
Startup time: not stated

castform

Where: One virtual cluster on ENTEI per immutable pinned set; named by a petname like otter-beats-potato
Network: ENTEI shared edge; a production-source preview stays dark until its safety check is signed
Real data?: Yes — forks (copies) of real Neon, Upstash and Tigris data. The only development landscape with real data
Lifetime: Leased: explicit close, with a 7-day renewable TTL as backstop
Cost: not stated
Startup time: not stated end-to-end. The data forks alone: Neon branch under 1 s, Tigris instant, Upstash restore in minutes

Money cost is not stated anywhere in the design docs for these six; "not stated" means exactly that. Watch any profile come up piece by piece in the animation below. Preview forks in detail: section 09.

Sources: concepts/environments.md §1–§1.3; goals/garden-k3d-profiles.md (profile table, pls commands); goals/garden-vcluster-profiles.md (eevee, castform); goals/dependency-operator.md (fork timings); ARCHITECTURE.md §3 (ENTEI).

Physically A k3d cluster inside Docker on your laptop — one per developer per repository, kept across down/up. Connected: it may use the internet.

Typical useEveryday development with hot reload while you are online. The cluster is yours and remembers your data between runs.

Start itpls env up --profile lapras --sync (hot reload), or --build-local / --target-pull --artifact <digest>. One-time per machine: pls setup.

DataLocal copies only: CNPG (Postgres), Dragonfly (KV and cache), MinIO, Mailpit, one local Logto. Never real data — there is no fork door.

NetworkFull network out. You reach your services through Boron, a private outbound tunnel to approved services only. No kgateway, no public route, no inbound callbacks (the cluster has no DNS name).

LifetimeKept. pls env down keeps the cluster; pls env reset deletes the edge objects first, then the cluster.

RefusesReal inbound callbacks, real money (the link is absent, not disabled), copied real data, real deliveries (email stops in Mailpit).

vs dittoContinuity versus reproducibility. lapras keeps state and hot-reloads, so it is fast but never clean; ditto starts from an identical fresh cluster every run, so results repeat but nothing carries over.

Source: concepts/environments.md §1.2–§1.3 (lapras row and page); goals/garden-k3d-profiles.md (profile table, substrate, pls commands); goals/charts/boron.md (private outbound tunnel, lapras only).

Physically A brand-new throwaway cluster per test run — k3d on a laptop, or the built-in k3s of a one-shot nsc CI machine that is destroyed afterwards.

Typical useThe blocking system-integration test run (SIT) in CI. The canonical lane uses no outside vendors, so the same tests give the same answers everywhere.

Start itCI creates the machine (nsc create --ephemeral), then the driver runs pls env up --profile ditto --target-pull --artifact <digest> (or --build-local).

DataDeterministic versioned fixtures — the same every run. A separately named lane may exercise a vendor's sandbox; that lane does not change the rules.

NetworkLoopback-only local kgateway; egress denied by default; never Boron, never public DNS.

LifetimeOne run, never reused. nsc destroy --force runs in an unconditional cleanup step; all credentials die with the run.

RefusesPublic inbound anything, real people, copied data, real effects in the core lane, cross-run continuity.

vs laprasReproducibility versus continuity. ditto proves things; lapras builds things. Nothing from a ditto run leaks into the next — that is the point.

Source: concepts/environments.md §1.2–§1.3 (ditto row and page); goals/garden-k3d-profiles.md (substrate nsc-k3s, profile table); goals/ci-k3d-lanes.md (nsc lifecycle).

Physically A k3d cluster on your laptop, sealed: zero network is proven before the cluster exists, and everything it needs arrives in a signed offline bundle.

Typical useWorking with no internet at all — a plane, a train, an outage. Deterministic local realizations, kept between sessions.

Start itpls env up --profile rotom. Sync (hot reload) is the only build mode; nothing is ever pulled.

DataEverything loads from the signed offline bundle: local CNPG, Dragonfly, MinIO, Mailpit, one local Logto — plus a real local Mercury fed by the local callback injector, so webhook journeys still run.

SecretsA fake local store with zero keys: values are derived locally or the run refuses. No Infisical environment, key or seed exists at all.

NetworkLoopback-only local kgateway on dotted localhost. Nothing leaves the machine, by construction.

LifetimeKept across down/up.

RefusesAnything that must leave or reach the machine, vendor test systems, federated sign-in, real sending domains or certificates.

vs absolSame laws, different clock. rotom is kept so you can iterate offline; absol is the same guarantees squeezed into one clean run with evidence at the end.

Source: concepts/environments.md §1.2–§1.3 (rotom row and page; local Mercury fed by a callback injector); goals/garden-k3d-profiles.md (sync only, fake-local secrets, offline closure).

Physically A fresh throwaway cluster per run, offline — on a laptop or one nsc CI machine. The network is denied before the cluster is created; images are built only from the signed bundle.

Typical useHermetic test runs that must prove they are offline, and capture evidence doing it — the offline CI lane.

Start itpls env up --profile absol --build-local --artifact <digest>. The image must come from the verified offline closure.

DataThe same signed bundle and deterministic fixtures as rotom.

SecretsFake local store, zero keys — derive or refuse.

LifetimeOne run. Deleted unconditionally after evidence capture; the cleanup is receipt-scoped, so an absol cleanup can never delete a rotom session.

RefusesEverything rotom refuses, plus anything needing cross-run state.

vs rotomEvidence versus iteration. absol exists to prove a hermetic claim once, loudly; rotom exists so you can keep working.

Source: concepts/environments.md §1.2–§1.3 (absol row and page); goals/garden-k3d-profiles.md (build-local from closure, run-once lifecycle).

Physically Your own virtual cluster (vcluster) on ENTEI, the fleet's one shared development host. Each allocation: 6 CPU · 16 Gi · 120 pods; 4 slots in the fleet; at most one active per person.

Typical useHosted live development with a real URL: open your dev stack from any machine, share the link, or let your agent use the same cluster.

Start itpls env up --profile eevee. The allocator authenticates you (fleet single sign-on) or your agent (a rotating token) and creates or reuses your one vcluster.

DataLocal dependencies on host-backed volumes; one fresh local Logto. Never real data — no fork door.

NetworkThe ENTEI shared edge: real public HTTPS on your claimed hostnames. No inbound callbacks.

LifetimeA renewable lease of days or weeks. Authenticated close: fence, revoke, withdraw routes, delete.

RefusesInbound callbacks, real effects, forking, real-person logins, public admin surfaces.

vs castformEditable versus faithful. eevee is a live workspace you can hot-reload; castform is a frozen, pinned copy of real data that exists to be reviewed. If you need real data, you need castform.

vs laprasLaptop versus hosted. lapras sits next to your files with no size cap but is private (tunnel only, no public URL); eevee gives you a real URL on shared hardware you never maintain — capped at 6 CPU · 16 Gi · 120 pods, with 4 slots in the whole fleet.

Source: concepts/environments.md §1.2–§1.3 (eevee row and page); goals/garden-vcluster-profiles.md (profile table, TTL policy); ARCHITECTURE.md §3 (ENTEI shares only the gateway, cert-manager and exposure machinery).

Physically One virtual cluster on ENTEI per immutable pinned set — a manifest that fixes every service's exact version. Named by a petname like otter-beats-potato.

Typical usePreview one exact change against a copy of real data and review it — the only development landscape with real data.

Start itpls env up --profile castform submits a mint request: forkSource (staging or production), the default channel, and a pin per service. Newer commits later mean a new preview, never an update.

DataForks (copies) of real data: a Neon branch, an Upstash database, a Tigris bucket. Logto runs on its own forked, sanitized Neon branch. Cache starts fresh; email lands in Mailpit.

NetworkThe ENTEI shared edge. A production-source preview needs a separately authorized grant, only one at a time, and stays dark until its signed safety check passes.

LifetimeLeased: the explicit close command, with a 7-day renewable TTL as backstop. fork-reaper deletes the forks and proves they are gone.

RefusesFederated sign-in, seeders, real outbound effects, a second production-source preview at the same time.

vs eeveeFaithful versus editable. castform shows you the truth (real data, exact pinned versions) but is frozen and costs a fork; eevee is free to edit but shows you local copies only.

Source: concepts/environments.md §1.2–§1.3 and §3 (castform row, preview rulings); goals/garden-vcluster-profiles.md (profile table); fork mechanics: section 09.

Pick a profile, watch it come up

Sources: environments.md §1.1–§1.4; goals/garden-k3d-profiles.md, goals/garden-vcluster-profiles.md, goals/ci-k3d-lanes.md; ARCHITECTURE.md §3, §4 (ENTEI traffic path).

09 · How a preview fork works

castform copies real data, then throws it away

Fixed at creationNewer commits mean a new preview, never an update.

3 data classes forkedPostgres (Neon), KV (Upstash), storage (Tigris). Cache starts empty.

Cleanup lives outsidefork-reaper owns it, so it works even if the preview's cluster is already gone.

Fork source

1 / 10

What cannot be forked

Dragonfly (cache or KV), MinIO, R2 and S3: the fork is refused with a ForkUnsupported condition. Nothing is faked.
Local CNPG has no fork mechanic. A local module that needs real data uses a remote Neon branch instead.

Sources: environments.md §3 (preview model, R-P1…R-P9), §1.2 (castform row); goals/dependency-operator.md (fork mechanics table, broker-only creation); goals/fork-reaper.md (release steps); ARCHITECTURE.md §5 (forked identity safety).

10 · Multi-region

Login is global, data is local

Home-sharding: each user has one home landscape per platform, stored as a claim in that platform's identity.
Production has two home landscapes today: raichu (Singapore) and ampharos (US).
Each landscape has its own Logto issuer and its own dataset. There is no cross-region database.
Caches stay regional with a time limit (TTL).

In one line One home landscape per user per platform — a claim stored in that platform's identity. Everything the user owns lives there: login, API traffic and data.

One claim, per platformThe claim is called home_landscape. The app checks the claim on every sign-in and sign-up: present means go straight home.

One dataset per landscapeLocation belongs to a cluster; consistency belongs to a landscape. raichu·opal and raichu·ruby are two clusters sharing raichu's one dataset (blue/green siblings).

What lives in the homeThe user's login (that landscape's Logto), the API hostnames the app calls, and every row the user owns: database, key-value store, files. The cache is regional too, per cluster, with a TTL.

Sources: ARCHITECTURE.md §1 (axiom 1), §2 (host landscapes, clusters), §5 (home claim); concepts/environments.md §1.

In one line No home yet → the picker: the app fetches the landscape selector doc, pings each region, the user picks a home, then login and onboarding write the home claim.

1 / 7

The landscape list carries names onlyLandscape names and metadata — no addresses, no issuer. Ping addresses are derived by convention from the names, and a region is listed only once its deployment is healthy.

Interrupted? Just againAn abandoned sign-up leaves the claim absent, so the picker simply shows again. Once the claim exists, the landscape list is never fetched again for that user — and never for per-request routing.

How the claim is writtenOnboarding's sync step writes home_landscape into the user's custom_data through the login service's Management API; a token script then stamps the claim onto every issued token.

Identity before homeThe web-to-app handoff (get-the-app link) finishes the login first; the picker runs after the handoff. New users get an identity before they get a home.

Sources: concepts/deferred-login.md (handoff × onboarding); concepts/lib-contracts.md §4 (the landscape list trigger); ARCHITECTURE.md §4 (the landscape list), §5 (client flow); concepts/authorization-pattern.md (home-landscape claim).

In one line mew and celebi are DNS-only names over host landscapes. Callers who cannot hold a hostname — OIDC browsers, webhook senders — get one stable address that survives region changes.

1 / 5

An envelope, nothing moreA virtual landscape is {name, hosts}: which host landscapes may serve the name. A v-landscape owns no clusters, no apps, no data. mew is production; celebi is staging.

Explicit recordsA v-landscape hostname gets one explicit record per service (explicit beats the wildcard): the union of the load-balancer IPs of the rows marked serve: true.

Geoproximity, not health checksMulti-landscape names use Route 53 geoproximity record sets — one set per landscape, multivalue A records, bias 0, custom coordinates for non-AWS regions. No Route 53 health checks and no traffic-flow objects exist.

The 5-second poll owns DNSOne loop probes every cluster's gateway once, recomputes the whole desired record set, and writes only on change (Route 53 primary, Cloudflare mirror, TTL 30–60 s). No healthy IP left in a landscape → that landscape's whole set is deleted and resolvers fall to the next-nearest. If the writer dies, DNS freezes at its last state — stale but serving.

Sources: ARCHITECTURE.md §2 (virtual landscapes), §4 (geoproximity, explicit records, the 5-second poll), §6 (webhook name example).

Sources for this section: ARCHITECTURE.md §1, §2, §4, §5, §6, §7, §11; concepts/deferred-login.md; concepts/authorization-pattern.md; concepts/lib-contracts.md §3–§4; concepts/environments.md §0.6.

11 · Mercury

Mercury: webhooks in, signed delivery out

Mercury is the fleet's webhook product. Providers call one stable name; Mercury checks the signature, stores the event, then delivers it to the right service — signed, retried, replayable.
It is an ordinary service: one repo, one image, the usual two charts — and the fleet's one deliberate multi-tenant exception.
Delivery is at-least-once. Consumers must treat every delivery as possibly repeated; ordering is never promised.

Physically A Bun web service in a pod, deployed like any other service — one repo, one image, the standard app chart + primordial chart pair — running on its own registered platform. Not a Cloudflare Worker, and nothing of it runs on Primordial.

Own platform, own trainMercury runs on the dedicated mercury products platform (home repo mercury.carbon, service repo mercury.webhook). It owns its rows, its virtual landscape and its own promotion stages, exactly like any platform.

Where the pods runOn every serving landscape: pichu, pikachu, raichu, ampharos. It never runs on Primordial — only its orders (custom resources) land there. See section 07 for how charts land.

The stable addressProviders send to a virtual-landscape name, e.g. hooks.webhook.mercury.mew.cluster.atomi.cloud. mew is production, celebi is staging. Route 53 geoproximity answers with the nearest healthy landscape. See section 10.

What is deliberately absentNo Cloudflare Worker, no Cloudflare D1 or Worker KV stores, no buffer, no wrangler — adding any would be a design regression, not an option.

One posture per landscape

primordialnothing — orders only

laprasfresh local copy

dittooff — no inbound rail

rotom · absolreal local copy, injector-fed

eeveeoff — callbacks denied

castformfresh tenant routes on the shared router

servingthe one multi-tenant instance

Sources: goals/mercury.md (kind, purpose, landscape ruling), concepts/ARCHITECTURE.md §6, concepts/environments.md §6 (shared-service table).

In one line land → verify → dedup → persist + enqueue → ack 200 → deliver — fixed, landscape-local, and durable before anything is acknowledged.

→indigo = a webhook or delivery on the move

→orange = a Git / chart edit

→green = a controller or Mercury acting

→pink = the failure path

1 / 8

Who registers whatWebhookRoute fragments ride each receiver service's own primordial chart (zinc ships one). The platform's WebhookEngine rides carbon's. The controller merges fragments; Mercury alone compiles the per-landscape candidate config into Upstash.

Pick the right serviceThe registered URL path is the only routing decision. Mercury never inspects the payload to choose a service, and the request Host never identifies the tenant.

Claim or disclaim200 from exactly one candidate = "mine". 421 from every other = "not mine". Anything else — zero, several, half-answered — is refused loudly. A retry re-probes the whole current set, never one remembered endpoint.

Sources: goals/mercury.md §3–§4 (pipeline, dedup, delivery, retry), concepts/ARCHITECTURE.md §6 (candidate addressing, DNS), concepts/environments.md §6 Mercury row.

Physically Mercury's management API is a Logto API resource. Machine callers get tokens from that landscape's own Logto (its machine-to-machine door); Mercury checks them against that same Logto. Mercury itself issues no machine tokens.

Two tenant doorsInternal platforms are internal/<platform> tenants, registered through Git (the custom-resource door). External customers are external/<slug> tenants using the same management API with signup. Both sit under the landscape's Logto.

Name-blind by lawThe request Host is never authority for tenant identity, authorization, signature input, metering or secret lookup. The registered route plus the verified credential prove the request.

Login never carries webhook powerAn identity outage cannot stop intake or delivery: providers sign their own events, delivery uses Mercury's per-tenant HMAC, and no login token grants any Mercury authority. The human console (replay, dead letters) is a real product page behind the same landscape Logto.

The controller is just a clientThe webhook controller on Primordial authenticates with a Logto machine token and acts through Mercury's provisioned default internal account. There is no second admin surface.

Sources: concepts/environments.md §7 (the shared-service Logto authorization rule, Mercury plane table, audience format), goals/mercury.md (common-service contract), concepts/ARCHITECTURE.md §6.

In one line At-least-once, unordered, durable before acknowledged — and the rules around it are fixed, not knobs.

Durable before ack, never 4xx on a transientThe event is persisted and its obligations enqueued before the provider sees 200. A failure before the durable write returns 5xx so the provider retries; a hiccup after persistence must never become a provider-facing 4xx.

72 hours, twiceThe default retry window and the dedup-key lifetime are both 72 hours, on purpose. A tenant may shorten the window. Nothing creates exactly-once; consumer idempotency is mandatory.

Truth is splitNeon holds long-lived truth (external tenants, accounts, custom domains, quotas) and sits off the hot path. Upstash holds only bounded operational data: derived config, dedup keys, two months of event streams, retry queues, dead letters, counters. Aging streams archive to Tigris before they are dropped; archive failure alerts and blocks deletion.

Home is fixedA tenant's home virtual landscape is immutable. Moving home means creating a new tenant and cutting over — there is no migration mechanism.

Also ruled

Seven verification adapters in v1: Stripe-style HMAC, Airwallex, Apple, Play Store, Telegram, Discord, Logto. After the last route for a provider is deleted, a grace period keeps its verification config and alerts instead of silently rejecting a live provider.
Provider operations stay reconciled: an Apple backfill job runs as a singleton; Play Store realtime notifications pin 31-day retention and an explicit dead letter, with drift continuously corrected.
v1 has no payload transformation and no separate durable-subscription product: registered routes plus bounded delivery obligations are the whole surface.
Custom domains are routing only: two CNAMEs (traffic + DNS-01), identity never derives from them.

Sources: goals/mercury.md §4.2–§4.3 and Rules in force; concepts/ARCHITECTURE.md §6. What breaks when pieces fail: section 14.

12 · Runtimes and runners

Five languages, one runner per job

Physically Programming languages plus the shared libraries each one gets. Every template and every lib/<lang>-* library in the graph belongs to one of five runtimes.

Runtime	Templates	Libraries (`lib/<lang>-*`)
Bun (TypeScript)	bun-base, bun-lib, bun-cli, bun-consumer, nextjs-frontend	result, interfaces, core-utils, config, otel, problems, auth-engine, api-engine, frontend-utils, standard-config, e2e
.NET	dotnet-base, dotnet-lib, dotnet-api	result, interfaces, core-utils, config, otel, problems, auth-engine, api-engine, server-engine, standard-config, e2e
Go	go-base, go-lib, go-consumer, operator-template	errors-problems, interfaces, core-utils, config, otel, auth-engine, api-engine, standard-config, e2e
Dart / Flutter	dart-lib, flutter-base, flutter-e4	result, problems, interfaces, core-utils, config, auth-engine, api-engine, e2e
Next.js (web)	nextjs-frontend, frontend-standalone-chart	uses the Bun libraries

One repo per libraryEach library is its own unit with its own repo, e.g. lib/bun-result — the Result and Option library every Bun service uses.

Same head of the chainEvery language starts result → interfaces → core-utils, so the shared ideas behave the same everywhere.

Sources: ARCHITECTURE.md §3, §3.1, §8, §10; the build graph (templates and lib/<lang>-* units, 2026-11-07); concepts/lib-contracts.md.

In one line Pick a language, see its templates, its libraries, and who builds it.

The runner is the same for all fiveGitHub Actions on a Namespace runner builds every repo and publishes one version: the image plus the two charts, to the OCI registry.

One label per jobA job selects exactly one runner label — primary nscloud-ubuntu-26.04-amd64-16x32, fallback nscloud-ubuntu-24.04-amd64-16x32 — never both.

Sources: the runtimes table above; goals/ci-k3d-lanes.md (runner labels); ARCHITECTURE.md §8 (one semver per repo).

Physically Six runners, one job each. A runner is the program or service that executes one kind of work — never two kinds.

Garden, via pls

Runs the one deployment graph for all six development profiles. Owns up, down, reset.

ArgoCD + Kargo

Run Primordial and serving only. Argo syncs Git to clusters; Kargo promotes one service's release stage by stage.

GitHub Actions on Namespace

CI. Runner label nscloud-ubuntu-26.04-amd64-16x32. Fallback: nscloud-ubuntu-24.04-amd64-16x32.

nsc instance (CI test lanes)

ditto and absol tests each get one throwaway nsc machine with built-in k3s, then nsc destroy --force.

task (Taskfile)

The per-repo command surface: build, test, chart tasks. Files are .yaml.

Cloudflare Workers

Only two kinds: web frontends (Next.js) and erbium's error portal. Released as tagged versions through CloudflareDeploy.

Sources: ARCHITECTURE.md §3, §8, §10; environments.md §1.2; goals/ci-k3d-lanes.md.

Physically Four ways a Kubernetes cluster comes to exist — the substrate decides who owns the cluster and how long it lives.

Substrate	Used by	Lifetime
k3d	lapras, rotom (laptop)	kept across down/up
nsc k3s	ditto, absol (CI)	one run, then destroyed
vcluster on ENTEI	eevee, castform	lease: days–weeks (eevee), 7-day renewable (castform)
Provider clusters	serving (DigitalOcean, AWS, OCI; EKS Auto Mode is the AWS direction)	permanent; removed only by Decommission

noteNot settled

EKS Auto Mode is assumed green — an engine decision, not a vendor-verified fact. Production use waits on your live test of aws-load-balancer-eip-allocations.

Sources: ARCHITECTURE.md §3, §3.1 (EKS Auto Mode posture); environments.md §1.2; goals/ci-k3d-lanes.md.

13 · How diene itself is built

Templates branch on three switches

Physically A tree of sample repositories. Every template is a working repo that builds and passes CI; every real repo is stamped from one.

Every template starts as a working sample repo that builds and passes CI.
Templates form a tree from workspace → shared. Each child removes or adds one capability.
The switches (dimensions): language, Helm on/off, Docker on/off, observability on/off.

Try it: flip the switches, see which template node exists Language

Capabilities

Sources: the build graph (template nodes and edges, 2026-11-07); goals/workspace.md, goals/shared.md.

Physically Four kinds of edge between nodes in the build graph. Each link says exactly why one node points at another.

Link	Meaning	Example
template-depend	A template built on a parent template	shared → bun-base
template-materialize	Real code created from a template	bun-lib → lib/bun-result
library-depend	Code that uses a published library	lib/bun-result → lib/bun-config
execution-depend	Needs another node to run its proof	observability-block → bun-base-w-observability

Sources: the build graph (node types template and code, edge kinds); goals/observability-block.md.

Physically Four planes a piece of diene code lives on — from sample repo, to real code, back to template, to your real repo.

Template plane

Working sample repos, e.g. helm-wrapper. Released as CyanPrint templates.

Code plane

Real code materialized from a template, e.g. charts/carbon (copied from helm-wrapper).

Template-publish plane

Code turned back into a template, e.g. the new carbon-template node.

Instance plane

One real repo per platform or service, stamped with cyanprint create, e.g. mercury.carbon.

Sources: the build graph (template, code and publish nodes); the carbon goal discussion.

14 · Failure drill

Break one piece, see what still works

Physically The live request path never touches Primordial. A request goes DNS → cloud load balancer → cluster gateway → pods. Primordial only composes desired state, off to the side.

The rulePrimordial composes desired state; nothing reactive depends on Primordial. Primordial down = deploys pause; traffic, failover and login keep working.

Safe to be down for hoursSecrets already copied into clusters stay there. Only changes wait: deploys, promotions, secret rotation.

Outside on purposeDNS (Route 53 primary, Cloudflare secondary), the ledger bucket and the data vendors (Neon, Upstash, Tigris) all live outside Primordial so they survive its loss.

Sources: ARCHITECTURE.md §1 (axiom 7), §3, §7.

15 · Glossary

Every word on this page

LPSM: Landscape / Platform / Service / Module: the four-slot name of every deployed workload.
Landscape: A rule set for secrets, data, lifetime and network edge. One landscape = one consistent dataset per platform.
Host landscape: A landscape that owns clusters: pichu, pikachu, raichu, ampharos.
Virtual landscape: A DNS-only name over host landscapes: mew, celebi. Owns no clusters or data.
Cluster mark: A gem name (opal, ruby, emerald…) that shows the provider. A cluster = landscape × mark.
Gem siblings: Two clusters of one landscape, same dataset, used for blue/green cutover.
Primordial: The one permanent control-plane cluster: ArgoCD, Kargo, operators, Infisical.
ENTEI: The one host cluster for eevee and castform vclusters. Not a landscape.
Instance: One developer, run or preview inside a landscape. A naming add-on, not an LPSM slot.
Allocation ID + generation: The only key used to clean up or fence an instance.
Garden: The tool that runs the deployment graph for development profiles.
pls: The command-line tool that drives Garden: pls env up, down, doctor.
vcluster: A virtual Kubernetes cluster that runs inside a host cluster.
Carbon: A platform's home repo (.carbon). Creating it registers the platform.
Row: One file per service per landscape in fleet/platforms//landscapes/<l>/<svc>.yaml. Kargo edits it to promote.
T3 / fleet-operator: The operator on Primordial with the cluster, platform, dependency, traffic, webhook and cf-deploy controllers. Graph node: dependency-operator.
SoS: Secrets-of-secrets: the Infisical project that holds each platform's machine credentials.
ESO: External Secrets Operator: copies secrets from Infisical into Kubernetes Secrets.
forkSource: castform's setting: staging or production. Production needs a separate grant and allows one preview at a time.
Decommission: The explicit custom resource that deletes something for real. Deleting a repo or a CR alone never destroys data.

16 · Your open decisions

Eight cards, answers first

Eight questions from the build engine are waiting on your answer. Each tab is one card: the question first, then the concepts you need, where things stand, and links.
Nothing merges by itself. Review pages are for reading and comments; your answer on the card is what unblocks work.

Words used on every tab

Unit: one template or library the engine builds and checks on its own, e.g. bun-base. The tree of units is in How diene is built.
Round: one finished chunk of a unit's work, checked by the engine before it is shown to you.
Review: a GitHub pull request you read and comment on. Approving records your OK; it never merges anything.
Held: the engine will not finish a held unit until you answer.
Mirror: a unit's own public GitHub repo in the ProtoDurian organization. Review pages live in ProtoDurian/diene.all; goal drafts (what "done" means for a unit) live in ProtoDurian/diene-corpus.

You approved the monitoring add-on, on one condition: one short section that lists the 3 dashboard test layers in order gets written in. The card is resting until that round lands; then you check that one section.

Approve RecommendedThe rewrite is accepted. The four templates whose names end in -w-observability then come to you for review, one by one.

ChangesYou comment on the review page; one more round fixes your comments before anything is approved.

Concepts you need

Monitoring add-onThe unit observability-block: monitoring documentation, five Grafana skills and a dashboard sandbox, built on the shared template and mixed into every template ending in -w-observability. How diene is built

GrafanaThe dashboards and alerting tool AtomiCloud uses.

Dashboard sandboxA local Grafana filled with fake data, where a dashboard is drawn and checked before merge. Example: a generator writes hours of fake log lines.

Query-check tool (not built)A planned tool that runs every dashboard and alert query after a test run with real traffic, and fails if a query returns nothing. Its goal draft is in the links below.

Where things stand

Rounds 12 to 17 are ready for your approval together; the checks on the public mirror are green (3 of 3).
Your three picks are in: the log-panel table with evidence panels, text panels to introduce sections, and the longer log-level format list.
A fresh agent ran all five skills using only these docs: 5 of 5 passed.
The query-check tool does not block this approval.

Links

Review page: rounds 16 to 17 — everything since the version you last looked at; 15 files, documentation only.
The full rewrite: rounds 12 to 15 — the version you already reviewed; 41 files.
Query-check goal draft — the new tool's goal, for your review; its checks fail on purpose until the engine gives the tool its own unit.

Nothing to decide yet. Your feedback is in; lib/bun-result is being fixed and its review comes back to this card. Approving that review publishes version 1.1.0.

Fix both sync checks DecidedTwo small fixes ride the current round: the instant checks stop throwing after you have awaited, and a plain value stays plain after map. No API change; async stays async.

Consumer test everywhere DecidedAll four library templates (Bun, .NET, Go, Dart) gain a test tier that uses the library the way a real app would, with a should helper such as await actual.should.be.equal(expected).

Concepts you need

lib/bun-resultThe Result and Option library every Bun service and library uses. It heads the library chain: every language starts with result, then interfaces, then core-utils. Runtimes and libraries

Result and OptionA return value that is Ok (a value) or Err (a failure) instead of a thrown error. Example: Ok(5), Err('bad').

The sync checksisOkSync() and isErrSync(): instant checks, meant for when the answer is already known. Two cases still throw today; both are fixed this round.

Where things stand

Fix order: bun-base, then the four library templates, then lib/bun-result with the should helper and both sync fixes.
The consumer-test rule is merged into the goal files (link below).
dart-lib is the first template with the consumer test: its round 19 landed, checks green, reviewer approved; its review is queued.
When lib/bun-result lands, a new review page comes to this card; approving it publishes 1.1.0 to npm, the public JavaScript package store.

Links

lib/bun-result review page — the version already open; it shows only what lib/bun-result adds on top of bun-lib.
Consumer-test rule — the goal-file change, already merged.

Two answers, ruled as a pair: confirm that a new carbon-template unit publishes the carbon template, and choose how mercury.carbon gets made — hand-built once (recommended) or stamped by the engine.

A + A: confirm, hand-built once RecommendedA new carbon-template unit publishes the template; a person runs the scaffold once and edits platform.yaml. Carbon's hold lifts immediately.

B + B: undo, engine-generatedThe carbon chart unit itself becomes a template unit, and the engine stamps mercury.carbon, re-stamping it when the template changes. No new unit, but carbon mixes a Helm chart pair with a scaffold generator.

Concepts you need

carbonA platform's home repo, e.g. mercury.carbon. Creating that repo is what registers a platform. Glossary

The four build planescharts/carbon is the code (a Helm chart pair); carbon-template is the new publish step; each platform's carbon repo is an instance. How diene is built

CyanPrintThe scaffolding tool that stamps a new repo from a template. It asks one question: the platform name.

Goal fileThe file that says what "done" means for one unit. The carbon-template goal draft stays unmerged until you confirm (link below).

Where things stand

Your carbon-template pick is held until you confirm it; charts/carbon stays held on this pair; nothing was reverted.
14 units wait behind carbon (fork-reaper, the Garden profile units, logto-operator, mercury and others); they are not held themselves.
This ruling removes one blocker, not all: carbon also waits on other open questions through its parent units.
Everything here is at zero; no deadlines.

Links

carbon-template goal draft — written, but unmerged until you confirm your pick.

Three answers on error records: confirm that the module is part of a record's identity; rename records to LPSM order (recommended); let each app template own its error-portal pieces (recommended).

LPSM names RecommendedRename to lapras.nitroso.zinc.api.v1 (landscape.platform.service.module.version). Same order as the error pages' URLs; readable on its own; cheap now because nothing is published yet.

Keep today's namezinc.api.lapras.v1 (service.module.landscape.version). Platform lives in the Kubernetes namespace, so the name skips it.

Each template owns the pieces RecommendedThe five app templates each carry the three pieces in their goal files and prove them against their own error library. Never expires.

Link them to error-portalNone of the five can finish until error-portal does, and it waits on 41 units above it. Only possible while all five are at zero.

Concepts you need

Error recordOne Kubernetes record (kind Problem) per landscape + platform + service + module + version, listing every error a service can return: id, HTTP status, retryable or not, data shape. The naming note in LPSM names is this very question.

error-portalMerges every service's error records into one public docs site.

LPSMThe four coordinates every workload is named by: Landscape, Platform, Service, Module. LPSM names

The five app templatesbun-consumer, dotnet-api, go-consumer (back ends), nextjs-frontend (web), flutter-base (mobile). Runtimes and libraries

The three piecesExport the error list into the chart (CI turns red on drift); show errors in web and mobile apps without calling the portal; delete the old error-info endpoints.

Where things stand

Your "module counts" pick is held as a draft until you confirm.
Nothing is published under the current name; renaming touches only the four problems libraries and two goal files.
error-portal is held as a draft; nothing sits downstream of it.

Links

None on this card.

Decide the mobile template's shape: split flutter-base into a v1 unit plus a later flutter-e4 unit (already drawn, nothing built), or keep one unit — and if split, two follow-up answers.

Yes, split itv1 ships first; the Dart libraries and the monitoring add-on arrive in the later unit. The graph already holds both units.

No, keep one unitThe split is reverted; everything stays in flutter-base.

If split — the recommended picksThe v1 template owns the mobile Garden adapter (it needs only what v1 already has), and the app-link checks are later work.

Concepts you need

flutter-base / flutter-e4The mobile app template, and the later unit that completes it. Runtimes and libraries

Garden adapterA small config bundle the Garden tool writes so an app template runs under it. Garden in motion

App linksThe Apple app-site-association file and Android's assetlinks list an app's web links; the planned checks prove those links work.

The monitoring add-onDefined in the Observability add-on tab above: docs, skills and a sandbox, mixed into -w-observability templates.

Where things stand

Both flutter units are paused on this card; the split is kept in the graph, not undone, and nothing has climbed.
The two follow-ups (adapter owner, link checks) only matter if the split stays.

Links

None on this card.

Give the two naming libraries publishing homes: their own repos with the usual diene names (recommended), their own repos with names you pick, or folders inside their parents' repos.

Own repos, usual names Recommendeddiene.instance-segment-naming and diene.fork-name-qualifier. No re-checks, no patch rounds.

Own repos, your namesYou pick both. Renaming a published package later is painful, so pick names you will keep.

Inside the parents' reposNo new names, but two patch rounds — one re-checks 31 units for two small libraries, and the libraries ride big parents' release rhythms.

Concepts you need

instance-segment-namingOne shared spelling of instance names, so Helm, the gateway and cleanup agree. Ships a name codec, test vectors and Helm helpers. LPSM names

fork-name-qualifierDeterministic names for every piece of outside data a preview creates: a database fork, a KV fork, a storage fork. How a preview fork works

Publish / mirrorPublish: push a version to a public package store. Mirror: the unit's own public GitHub repo in the ProtoDurian organization.

Patch roundA finished unit reopens for one change, and everything below it re-checks.

Where things stand

Both units are held here and on the preview fingerprint decision (Preview pieces tab); both rulings must land before either starts.
11 units wait behind instance-segment-naming; 4 sit downstream of fork-name-qualifier.
No deadlines — but a published name is the name you keep.

Links

None on this card.

Pick the owner of the two trusted preview pieces: a new preview-assembler unit builds the fingerprint and the assembler (recommended), or the existing fork-reaper absorbs them.

New preview-assembler unit RecommendedOne clear owner for the signer; every unit that uses the receipt keeps proving its own use. Costs one new unit and 8 waiting links.

fork-reaper absorbs itNo new unit, but the five units above fork-reaper cannot link down to it (that would be a loop), so their checks move into fork-reaper's own list and are proven late.

Concepts you need

PreviewA short-lived, private copy of the whole platform, made to test one change. Runs as its own virtual cluster on ENTEI, in the castform landscape, on forks of real data. How a preview fork works

FingerprintA short digest (SHA-256) of the preview's manifest: the exact list of what goes in. Any change to the list changes the fingerprint; same inputs, same fingerprint, always.

AssemblerThe one trusted service that fills in unpinned apps, writes the manifest, computes the fingerprint and signs it. Nothing is created without its receipt: no cluster, no name, no data fork.

fork-reaperThe unit that closes previews out: deletes the virtual cluster, the data forks and the DNS names, and proves they are gone. How a preview fork works

Where things stand

Nothing is ruled and nothing is built: 6 units are held on this, plus 11 behind them.
Two of those units also wait on the naming-libraries decision; both cards must clear to free them.

Links

None on this card.

Approve the helm-wrapper template, or comment on its review page and ask for changes.

helm-wrapper, first reviewThe template every fleet Helm chart is built from. About 26 hand-copied chart repos become copies of this one template. The eight chart repos wait for this approval.

What to look atThe chart skeleton (values, templates, hooks), and the manifest check every chart repo inherits: helm template, then kubeconform (schemas), then the admission rules through kyverno apply.

Already decided by you

Approved: dotnet-base, shared-wo-docker-helm, go-base-wo-helm.
Approved with 2 fixes: bun-base. The Biome format script stops running bun install, and the Express example leaves the validation doc. The fix round arrives as its own card.
From now on, every review gets its own card.

Links

helm-wrapper review — first review, rounds 1–14, 98 files.

Sources: the eight open decision cards, 2026-11-07. Concept links point at the sections above on this page.

One name, eight landscapes, one control plane

Five layers, one direction of control

Pick a box above

Four slots name every workload

A landscape is a rule set, not a place

Three ways in: bootstrap, Git, or pls

Primordial decides, clusters serve

The 2-chart law, used twice = 4 charts per platform

Tap a repo, watch its charts land

pls env up, piece by piece

lapras

ditto

rotom

absol

eevee

castform

castform copies real data, then throws it away

Login is global, data is local

Mercury: webhooks in, signed delivery out

Five languages, one runner per job

Templates branch on three switches

Break one piece, see what still works

Every word on this page

Eight cards, answers first

Three ways in: bootstrap, Git, or `pls`

`pls env up`, piece by piece