4 Commits

Include renames

Author	SHA1	Message	Date
jochen	37947ca4ee	Raise genesis on the bus the mesh runs on, from one bundle (hq issue 146, ADR 0331) ... The installer could not raise a first node: the old bundle's control plane had no MESH_BUS_NATS and crash-looped, and the NATS bundle was refused because rootsecrets only knew the previous broker's guest:guest@ template. One bundle now, the NATS one. rootsecrets makes the controller's bus account and puts it in both placeholders (the address and the bcrypt hash in the carried user list), kept with its hash so a re-run writes the same bundle. Preflight refuses a template naming no bus connection it knows, naming the placeholder, instead of waiting out the verify step. The broker step adopts the bus as the nats module and refuses, by name, a catalogue without it or a server that is not the foundation's container.	2026-10-12 22:49:49 +02:00
jschoubben	121367319d	Rename mesh-control -> mesh-controller, substrate -> foundation ... One name per thing, per the HQ glossary: the module/container/image/binary/repo becomes mesh-controller, the seat the-controller, and the store+broker pair the foundation (embedded base bundles, default template and example lock renamed with their go:embed directives). No behaviour change — a pure vocabulary rename. Claude-Session: https://claude.ai/code/session_01D6qtiYU3P9jk3pnAXyAFyx	2026-09-16 18:40:40 +02:00
jschoubben	7e3481f025	bootstrap: the slot the installer fills is not a registry to reach for ... The first real run of mesh-bootstrap stopped in preflight, dialling 192.0.2.250:5000 for ninety seconds on a machine whose network was fine. That address is the registry the lab used to raise; the substrate template still names the control plane by it, and step 3 replaces that reference with the id of the image this installer carries. Nothing ever pulls it. So preflight excludes the control plane's resource by identity, rather than by the happy accident of the template filling its slot with something that needs no registry. Every other container's registry is still dialled, because those are somebody else's images at somebody else's registry and a machine that cannot reach one fails inside a pull, which says the wrong thing. Also: `make bootstrap` takes BOOTSTRAP_OUT. The lab now builds the installer from source before every raise, into a path it chooses, and a caller that could not say where the output goes would have to copy it afterwards. Claude-Session: https://claude.ai/code/session_01LrgweAeERJYBg88c5cKDzF	2026-09-11 11:38:15 +02:00
jschoubben	b82ab95f74	mesh-bootstrap: the first-node procedure, as a program rather than a test ... The only complete written-down copy of how a mesh is stood up was an integration test in the lab. That is why every bootstrap gap kept being found late: an install procedure that lives as a test fixture is exercised by whoever writes tests, never by whoever installs. This is that procedure. A separate binary, not a mesh-host subcommand. mesh-host says of itself that it connects to nothing and listens on nothing and that what it applies comes from a file, and that sentence is what makes an always-running root daemon auditable. An installer loads images and interrogates a control plane. Same tier, different program. The control plane's image is carried, not built and not fetched. The forge that holds its source runs on the mesh, so a bootstrap that had to fetch it would need a mesh in order to raise one. Embedding breaks that cycle the way the carried bundle breaks "copy it onto a machine and run it". The image id is read out of the saved tar before the runtime is asked anything, which is what makes the load idempotent: the installer can ask whether the machine already holds exactly this. Five steps, each idempotent and each saying whether it found or changed something, because this is run over and over by somebody getting a machine working. It stops at a running substrate with a control plane that replies — enrolment, the module catalogue and assignment are the next stage and are deliberately absent. Claude-Session: https://claude.ai/code/session_01LrgweAeERJYBg88c5cKDzF	2026-09-10 23:17:30 +02:00