jochen
dbe100ca96
Seats have been doing two jobs and neither is written down. The mechanism ADR 0009 introduced is enforced — a second holder is refused — but any well-formed name becomes a seat by being claimed, and nothing can say which seats a mesh has or who holds them: holdings are assembled while planning and discarded. The enumeration done while preparing this missed the control plane's own manifest, because core modules' manifests live in its repository rather than the catalogue. 0110 closes the set. Each seat has a name, a scope, what occupying it delivers, and the record that made it one; a claim outside the set is refused. A seat is held by a module assignment, and what the mesh knows about the holder is what it knows about that assignment — nothing is stored beside it. A seat may deliver a provision, and then its holder answers for it among several providers: pin, then the holder, then the only provider, then refused. That keeps 0009's "refused, never guessed": the seat is the choice made once, mesh-wide, instead of a pin per consumer node. The first set is the eleven seats already claimed plus 0109's npm-package-registry, so nothing in use is refused. Two concepts — seats for exclusion, a new word for consumable singulars — was rejected: both mean "this mesh's one X", and the overview a person wants is one list. 0111 gives the mesh a git seat and makes a build source one of two explicit forms: a repository on the seat's holder, recorded by its path and cloned from wherever the holder runs at build time; or an external URL, recorded and cloned exactly as given. Recognising self-hosted sources by matching URLs against the forge's address was rejected — it fails in the one case it exists for, after the forge moves. Credentials for private repositories are left undecided and said so. Design: new to-be 26 (the seats); 23 gains the seat step in resolution; 18's source entry names the two forms; the glossary's seat and provision entries say where they meet. 0109 is carried from its own branch so every link here resolves.
03-DESIGN
The authoritative specification. Implementation is built against what is written here.
Two layers
| Folder | What it is |
|---|---|
00-as-is/ |
The mesh that exists today. Shipped behaviour, described as it is — including behaviour nobody would choose again. |
01-to-be/ |
The mesh being built toward. Every statement traceable to a record in 02-DECISIONS/. |
They are never mixed. A statement about the future does not belong in an as-is document, and an as-is document is never edited to describe an intention.
When a to-be design ships, it does not move. Its as-is counterpart is written or updated,
the to-be document's status becomes implemented, and both stand — one describing what runs,
the other recording what was intended. Deleting the intention loses the reasoning, which is
the expensive half.
Frontmatter
Every design document (not the READMEs) carries:
---
layer: as-is | to-be
status: designed | in-progress | implemented | abandoned
code: [] # owning code repo(s), from 00-META/repos.md
updated: YYYY-MM-DD # date of the last status change, not of text edits
decisions: [] # 02-DECISIONS/ records this document rests on
---
For an as-is document, status: implemented is the normal state — it describes something that
runs — and code: names where that implementation lives.
Status changes when implementation state changes, never because design text was edited. An
implemented claim must be defensible from the owning repository's main branch, not from
intent. If it cannot be checked, it is in-progress.
Cross-cutting views are generated from this frontmatter by the hq-status skill and never
written to disk.
What belongs here
Functional analysis, architectural description, and specification — prose and diagrams
only, no code. A manifest field may be named; a manifest may not be pasted. A document
enters the to-be layer only after the decision behind it is recorded in 02-DECISIONS/
and the research that produced it is closed.
Subfolders are encouraged where a layer grows enough to need them.