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

L · Landscape

The environment kind: raichu, lapras, castform…

P · Platform

A product family. Registered by creating its .carbon repo. Example: mercury.

S · Service

One repo, one deployable: .<svc>. Example: argon.zinc.

M · Module

One named piece inside a service: an API, a database (maindb), a cache.

Remember this

Hostnames are the coordinate reversed: module first, landscape last.
Instance is not a fifth slot. It is added only where a physical name must be unique (one developer, one CI run, one preview).
Cleanup never selects by instance. Cleanup uses allocation ID + generation.

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).

03 · The eight landscapes

A landscape is a rule set, not a place

A landscape fixes four rules: secret class, data posture, lifetime, network edge.
Location is a property of a cluster. Consistency (one dataset) is a property of a landscape.
Six landscapes are Garden workload profiles (development copies). Primordial and serving are not.
A new landscape is a new row of settings, never new machinery.

Pick a landscape

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.

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).

Sources: environments.md §1, §1.1, §1.2, §1.3.

04 · How each landscape starts

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

Bootstrap · primordial

The seed-cluster bootstrap creates Primordial, ArgoCD, Infisical and the fleet root app.
Root of trust: the SOPS root key.
After that, Primordial's own ArgoCD keeps it in line with Git.

Git · serving

New landscape or cluster: one pull request to fleet/registry/.
New platform: create the .carbon repo.
New service: create the .<svc> repo.
Release: Kargo edits one row file per stage.
On/off for traffic: set traffic: true|false on the cluster.

pls · the six Garden profiles

pls env up --profile  starts one.
pls env down --profile  stops it.
pls env doctor checks it without changing anything.
pls is the command-line tool shipped by the garden-k3d-profiles node; it runs Garden.

Pick a landscape: the exact start sequence

Sources: environments.md §1.3, §3; goals/garden-k3d-profiles.md (pls commands); goals/garden-vcluster-profiles.md (eevee, castform); goals/ci-k3d-lanes.md (nsc lanes); ARCHITECTURE.md §10–§11.

05 · Planes

Primordial decides, clusters serve

The rule behind everything

Nothing on a live request path depends on Primordial. Primordial composes desired state. If it is down for hours, deploys pause; traffic, failover and login keep working.

Control plane

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

Serving plane

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

Development plane

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

Edge plane

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

Every dependency has three layers

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

Delivery: where a dependency is realized

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

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 12.

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

The 4 chart concept (confirmed 2026-11-07)

The design docs call this the 2-chart law (rule R20). A platform applies it twice: once for its carbon home repo and once per service. That gives the 4 chart kinds below.

1 · Service app chart

Runtime only. Deployment, Service, the database-init hook Job.

Goes to every host cluster of each landscape. One Argo Application per service × landscape × cluster.

2 · Service primordial chart

Custom resources only. PlatformDependency, WebhookRoute, Problem, LogtoApp…

Goes to Primordial. One Application per service × landscape.

3 · Carbon app chart

The platform's namespace + SecretStore.

Goes to each host cluster. Services read secrets through this store.

4 · Carbon primordial chart

Platform-shared CRs: ProviderAccount, shared PlatformDependency, WebhookEngine.

Goes to Primordial. The only render home for platform-shared dependencies.

Plus one fleet chart

diene-platform, the compiler chart, lives in fleet/registry/charts/. Per platform it renders the Platform CR, the Kargo pipelines and the platform ApplicationSet. It is Git-sourced on the moving tag machinery-stable; every other chart is published as OCI.

Try it: how many Argo Applications does one platform make?

Services: 3

Landscapes in platform.yaml: 4

Clusters per landscape: 1

Counts follow ARCHITECTURE.md §8: g1 = one primordial Application per service × landscape; g2 = one app Application per service × landscape × cluster. Carbon is an ordinary chart-only service, so it counts as one more service here.

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; rules/SAMPLE-CREATING-RULES.md R20; goals/charts/carbon.md; 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.

3D · argon's first deploy, step by step · drag to turn, pinch to zoom

Loading the 3D view…

1 / 10

pod PendingContainerCreatingRunning · Readydb-init Jobnamespace argonSecretStoreSecret (from ESO)

Top: GitHub. Middle: Primordial (one VM running a k3s cluster). Front: the 5 host clusters (example names). Right: services outside Primordial. 2 replicas per cluster is an example.

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.

How and where a deployment happens

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

1 / 8

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.

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 their 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).

Try it: one user signs in

DNS across regions

Names that span several landscapes use Route 53 geoproximity: one record set per landscape, nearest healthy one answers. Example: hooks.webhook.mercury.mew.cluster.atomi.cloud.

Virtual landscapes

mew (production) and celebi (staging) are names only. They exist because OIDC browsers and webhook senders need one stable address that survives region changes.

A whole region dies

That is a restore event, not a routing event: restore from cross-vendor backup and move the declaration. Expect hours (data loss window: minutes).

Why not a global database

AWS's strongly consistent multi-region options exclude Singapore (mid-2026), break EF Core, and cost 3–5× Neon.
A globally consistent Redis does not exist.

Sources: ARCHITECTURE.md §2 (multi-region), §4 (geoproximity, edge docs), §5 (client flow, token lifetimes).

11 · Runtimes and runners

Five languages, one runner per job

Runtimes (what services are written in)

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

Every language starts its libraries in the same order: result → interfaces → core-utils.

Runners (what executes each job)

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.

Kubernetes substrates (where clusters come from)

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" (decision S11), not live-verified. Production use waits on your live test of aws-load-balancer-eip-allocations.

Sources: ARCHITECTURE.md §3, §3.1, §8, §10; environments.md §1.2; goals/ci-k3d-lanes.md; ratchet graph (nodes and edges, 2026-11-07).

12 · How diene itself is built

Templates branch on three switches

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

Four kinds of link between nodes

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

Build planes: from sample to a 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: ratchet graph (node types template/code, edge kinds), carbon goal discussion; goals/workspace.md, goals/shared.md.

13 · Failure drill

Break one piece, see what still works

Pick what fails

Sources: ARCHITECTURE.md §1 (axiom 7), §3, §4 (failure rungs, Cloudflare outage posture), §7 (vendor posture); environments.md §1.1 (ENTEI).

14 · 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.

15 · 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.

Approve the monitoring add-on's rewrite (work rounds 12 to 17), or ask for changes on its review page.

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 five template reviews that are next, top-down — or comment on a review page and ask for changes.

bun-base, rounds 11–14 · approved by you, 2 fixes comingThe base Bun template; every Bun template sits under it. Fixes: the Biome format script stops running bun install, and the Express example leaves the validation doc. Then the Bun chain (bun-lib, bun-cli, releaser) comes next.

dotnet-base, rounds 10–14The base .NET template. After approval, the .NET chain follows.

shared-wo-docker-helm, first reviewShared without Docker and Helm; the Dart templates sit under it.

helm-wrapper, first reviewThe Helm chart template; the eight charts sit under it.

go-base-wo-helm, first reviewThe Go base without Helm; go-lib sits under it.

Concepts you need

Top-down orderA template's review comes only after its parents are approved. The tree is in How diene is built.

What a review page showsOnly the change since your last approval, or since the approved parent. bun-base and dotnet-base changed after your last approval; the other three have never been reviewed.

Where things stand

Five reviews are truly next; bun-base-wo-helm and bun-base-wo-helm-docker follow, only after bun-base.
Approving one sends its children's reviews to this card next.
After these five, the queue unlocks top-down: the Bun libraries, the .NET chain, dart-lib, then the eight charts.

Links

bun-base review — rounds 11–14, 17 files.
dotnet-base review — rounds 10–14, 8 files.
shared-wo-docker-helm review — first review, 32 files.
helm-wrapper review — first review, 98 files.
go-base-wo-helm review — first review, 31 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

Every dependency has three layers

Delivery: where a dependency is realized

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

Tap a repo, watch its charts land

pls env up, piece by piece

castform copies real data, then throws it away

Login is global, data is local

Five languages, one runner per job

Runtimes (what services are written in)

Runners (what executes each job)

Kubernetes substrates (where clusters come from)

Templates branch on three switches

Four kinds of link between nodes

Build planes: from sample to a real repo

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