Files
hq/02-DECISIONS
jschoubben a1a10e9ed2 Bootstrap ends at a usable mesh, and the first credential comes from a person
Bootstrap stopped when the control plane started — a mesh that runs and
cannot be used by anybody not standing at the machine, since the
networked surfaces need an identity provider and no module has been
assigned yet. It now runs through the provider and the first login.

The obstacle was not incidental. The mesh has never held a readable
secret: Make generates and seals, keeping no readable copy. An initial
administrator's credential is the first value a person must read.

Generating it and printing it once was the convenient option and is
refused. It would give the control plane a plaintext secret for the
first time — briefly, and to one terminal, but the capability would then
exist, and an exception made for one case does not stay one. The next
awkward credential gets printed too, and "a copy of the database is a
copy of nothing" stops being checkable by reading the code.

So the operator supplies it, on standard input, not echoed — the path
that already exists for a model-access key. What is created is an
account in the identity provider, not a user of the mesh; there is still
no user model.

Unattended bootstrap remains possible and the value still comes from
outside: automation supplying it is the operator supplying it. What is
refused is the mesh inventing one, so an unattended bootstrap with
nothing provided yields a mesh with no administrator — correct rather
than broken.
2026-08-31 21:23:55 +02:00
..

02-DECISIONS

Architecture decision records — the "why" trail behind the rules in 00-META and the specifications in 03-DESIGN.

Numbered 02 because a decision precedes the design it authorises. Research concludes, the decision is recorded here, and only then is the design written. Following the folder numbers walks the process in the order it happens.

One file per decision, numbered, never deleted. A superseded record has its status: changed and gains a pointer to what replaced it — its text is never edited. The reasoning that was rejected is the expensive half to rediscover.

The records run in the order the decisions were taken, oldest first.

Every decision is a record. There is no ledger and no index file — if a decision is worth recording it is worth a record, and if it is not worth a record it is not recorded (ADR 0019). A "decision" small enough to be one line is almost always a rule, and a rule belongs in 00-META/how-we-build.md, where it is enforced and keeps the incident that earned it.

Frontmatter

---
status: proposed | accepted | superseded
date: YYYY-MM-DD          # when the decision was taken, not when it was written down
deciders: name
reconstructed: true|false # true when the record was written after the fact from evidence
superseded-by:            # 02-DECISIONS/NNNN-....md, when status is superseded
extends:                  # 02-DECISIONS/NNNN-....md, when this record widens an earlier one
---

Body

# N. Title in plain language

## Context            what was true, with evidence
## Considered Options numbered, each with why it was rejected
## Decision           what was decided
## Consequences       what follows, including what got harder
## References         commits, pull requests, knowledge-base entries, prior art

State evidence, not assertion. "Zero of 124 modules declare brain as a dependency" outranks "the dependency rule is not followed".

Reconstructed records

Records 0001–0014 were written on 2026-08-23, after the decisions they describe. Records 0015 onward were taken as records. Those decisions were taken in implementation rather than in a document; the records state what was decided and the evidence it was decided from, and each carries reconstructed: true and says so in its first lines.

A reconstructed record is not a transcript. Where the deliberation is not recoverable, the options section states what the alternatives were and why the chosen one won on the evidence available — not a discussion that did not happen. Where a date is not establishable it says so rather than guessing.

Index

A number identifies a record and never changes. Records are referenced from outside this repository — code comments, commit messages — so a number that moves invalidates them silently. Renumbering once cost 96 references across two code repositories, and that is why the numbers are now fixed.

So the folder is in creation order, and the reading order lives here. It is generated from each record's topic: and written, because a reader looking at the folder on a forge sees the folder rather than a command. The objection to a written index is that it drifts — which is answered by checking it rather than by refusing to write one:

python3 00-META/checks/index.py --write    regenerate
python3 00-META/checks/index.py            fail if stale

What the mesh is

Its tiers, from the bottom up

What runs on them, and how it gets there

How it is built

How it is checked

How we work