novox/hq
3
0
Fork 0
Code Issues Pull Requests Releases Wiki Activity

The catalogue owns the module graph, and genesis builds rather than carries

Browse Source 
The graph had no owner: what modules are, what they require, what they claim and
what they are built against all sat in the control plane because that is where it
was written first. The control plane's own test says otherwise — anything a single
machine could answer alone is not its work, and what a module needs requires no
knowledge of any node.

So the catalogue becomes a core module beside the control plane and the builder,
owning the graph and serving tools over it. The control plane consumes it, which
is the opposite of what the tiers suggest and is therefore stated rather than
inferred.

That makes the catalogue a fourth thing that cannot arrive through the ordinary
path, so the claim written this morning that the list was closed at three is
corrected. All four are answered by one mechanism instead: the installer carries
an init builder and the core modules are built on the machine, so what is carried
is a builder rather than a result and nothing is left without a route.

Two things are open and named rather than assumed: where the init builder clones
from, given the forge normally runs on the mesh it would be rebuilding, and what
it publishes into, given the registry is installed later in the order today.

Claude-Session: https://claude.ai/code/session_01D6qtiYU3P9jk3pnAXyAFyx
This commit is contained in:
jschoubben
2026-09-12 22:03:05 +02:00
parent 837b5df2f7
commit 64ae75a480
4 changed files with 150 additions and 17 deletions
Download Patch File Download Diff File Expand all files Collapse all files
03-DESIGN/01-to-be/17-raising-a-mesh.md
+16 -3
View File
@@ -36,6 +36,19 @@ Confusing the two is what produced a procedure that only ever worked in a fixtur
raises four machines the same way has not tested genesis at all — it has tested joining, four
times, with the first one hand-fed.
## Genesis is decided to change, and has not yet
*2026-09-12.* [ADR 0070](../../02-DECISIONS/0070-the-catalogue-owns-the-module-graph.md) settles
that the installer carries an **init builder** rather than the control plane's image, and that the
core modules — control plane, catalogue, builder — are **built on the machine** before a mesh exists
to install anything. One thing is carried, and it is a builder rather than a result, which is what
gives the builder and the catalogue a route they did not have.
**The section below describes what the installer does today**, which is to carry the control plane's
image and publish it once there is a registry. It is kept as written because it is true of the
program that exists, and replacing it with the intention would leave nothing describing the thing
anybody actually runs. The order changes when the init builder is built; the pivot does not.
## Genesis
The installer is a single program carrying the control plane's image inside it. That is what makes
@@ -136,9 +149,9 @@ needs a toolchain and a working tree, which is most of the burden the installer
**A mesh cannot say how it was raised.** Nothing afterwards can contradict a claim that a machine
was brought up the supported way, so the rule that it must be is, today, unenforced.
**The builder has no way to arrive.** It cannot be pulled from the public internet, because the
mesh builds it; and the installer carries one image only. So the paragraphs above describing the
core modules being built are, today, describing something that cannot start.
**The init builder is not built.** Until it is, the installer carries the control plane's image and
nothing gives a fresh mesh a builder or a catalogue, so the paragraphs above describing the core
modules being built describe something that cannot yet start.
**A machine has no account for a registry that asks for one.** The mesh grants a consumer a
credential for a database; it does not yet do so for the store its own images live in. Genesis