Files
hq/03-DESIGN
jschoubben 19997d56c3 Approve 0057-0059, with four corrections from review
Not approved as drafted -- four things came out of checking them against each
other, and one was a bug that would have broken every upgrade.

The bug: 0059 specified Restart=on-failure while 0057 has the host restart onto
a new binary by exiting CLEANLY. on-failure does not restart a process that
exited zero, so every upgraded node would have been left stopped, having
successfully upgraded. Found by reading the two records against each other
rather than by either alone. Now Restart=always in all three places that
mention it.

The host cannot run in a container, and the reason is decisive rather than
stylistic: step 0 of the substrate bootstrap installs the container runtime, so
a host inside a container would need the thing it exists to install. It would
also break 0041 -- copy it onto a machine and run it stops being true when the
machine must already have a runtime. Everything above tier 0 is a container;
the host is not. That split is the tier boundary, not an inconsistency.

systemd is named rather than abstracted. An init is not a dependency in 0041's
sense: 0041 is about what must be installed before the host works, and an init
is not installed, it is what the machine already is. The unit file is the only
systemd-specific artefact and it belongs to the package, so a machine with a
different supervisor ships a different package.

The mesh is a watchdog, and my first draft was half an answer. Recovery must be
local -- nothing dials a node, and a host that cannot start cannot report. But
detection is the mesh's, and a local supervisor structurally cannot do it: it
sees one process failing and cannot tell a broken machine from a broken
release. Only something watching every node can, and that distinction decides
whether the response is "fix this machine" or "stop shipping this version". So
a host rollout is staged -- a few nodes, wait for heartbeats, continue or stop
on silence. Local rollback still needed, because the canary nodes break and
because a node offline during the rollout gets the declaration later with no
batch around it.

The first declaration is the overlay and nothing else. Forced, because a node's
address and peers are assigned rather than chosen. But also the way back in: a
node reachable over the overlay can be fixed by hand if a later declaration
breaks it, and a large first declaration risks a node that is broken and
unreachable at once.

Also stated plainly, because it reads as a contradiction: nodes reach each
other over the overlay and every node consumes from the broker; what 0039
forbids is an inbound CONTROL surface, not reachability.

And in 06: no node holds a credential to any control-plane store, for reads or
writes. Four ADRs already say this separately and none of them said it in one
place. Nodes state over the broker; the owning context writes. With a note that
most high-frequency writes are observability's, not the registry's -- routing
logs into the registry would be the shared-schema mistake arriving through a
door marked performance.
2026-08-27 22:12:12 +02:00
..
2026-08-25 01:55:52 +02:00

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.