Files
hq/03-DESIGN
jschoubben 918dc04916 What this actually is, and three things that were assumed
Four things settled by talking them through, all of which had been true in
somebody's head and written nowhere.

It is not a mesh in the peer-to-peer sense and will not become one. 0001 now
says what it is instead: machines linked by a private network, one node holding
knowledge of all of them, modules as the way anything is built and delivered,
and agents hired onto nodes to do the work. The word describes what machines
can reach, not how they are governed. "Master" overstates it the other way --
nothing needs that node to keep running, only to change.

0006 gains the option that would make it a real mesh, recorded as considered
rather than rejected by silence: every node holding the whole inventory, a
replication process, an elected master with promotion on failure. What settles
it is not the complexity but that it still would not deliver the name, because
application databases are not replicated -- so a genuine peer-to-peer mesh
means becoming a replicated database system for every consumer's data too. That
is a larger product than the thing it would support.

Also in 0006: three central roles, not one. Losing the control plane costs
change, losing the broker costs being told anything, and losing the hub costs
nodes in different places reaching each other at all -- which is operation, not
administration. Whether they are one node is not decided.

And SSH access is identity's. It appeared three times as something that uses
the overlay and never as something the mesh provides, which reads as settled
when nothing decided it. Nobody else could: the mesh is the only thing that
knows which humans and agents exist and which nodes they may reach. Node to
node SSH stays out -- the host has no inbound control surface by decision, and
nodes reaching each other that way is a second control path through the back
door.

0007 gains the requirement underneath all of it. Reachability was recorded as a
fact to track and never as a thing some node must have. The broker's node and
the hub must be dialable by every node at a stable address, or nothing can join
and a disconnected node cannot return. A mesh entirely behind NAT cannot be
raised. That is a precondition and it belongs with the others.

The link staying on the underlay is also argued now rather than asserted. At
join time it is forced; afterwards it is a choice, and the reason is that a
repair channel carried over the thing being repaired is not one. Moving it onto
the overlay, with fallback, is recorded as open with what it would have to get
right -- a WireGuard interface has no link state to test, and a silent fallback
is this repository's recurring fault in a new place.

0010 says in one line what was the intention throughout: the module system is
the CI/CD. Not a pipeline beside the mesh. Build, test, publish and deploy are
one reconciliation seen at four points, which is why a thing that cannot be a
module cannot be delivered.
2026-08-29 13:01:36 +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.