Issue 060 — the mesh cannot build most of its own catalogue #51

Merged
jschoubben merged 1 commits from issue/060-catalog-not-mesh-buildable into main 2026-09-17 20:39:02 +00:00
Showing only changes of commit 0b002ef39c - Show all commits
@@ -0,0 +1,42 @@
---
status: open
opened: 2026-09-17
located-in: []
fixed-by:
amended-design:
---
# 060 — The mesh cannot build most of its own catalogue
## Symptom
Only 8 of the catalogue's 70 modules carry a `build` section; 62 do not. A module without one
cannot be built by the mesh's own builder: its runtime container pins a placeholder digest
(`mesh-runtime-<m>@sha256:0000…`) that only an out-of-band script ever resolves — the lab builds
the image on a workstation and rewrites the manifest before registering it. Asked to `build` such
a module, the mesh has nothing to produce, and asked to run one unbuilt, it refuses the
placeholder digest.
Found by the no-fake lab bed, which registers committed manifests verbatim and lets the builder
fill every placeholder — the first consumer chosen to prove the store cross-node turned out to be
unbuildable, and the census followed.
## Why it matters
The delivery design says a module is built by the mesh and pulled from the mesh's registry by
digest. For 62 of 70 modules that path has never run: every proof of them so far went through the
workstation shortcut, which the no-fake principle retires. Production migration assumes the same
path ("publish every module runtime, the builder pins at publish"), so each unbuildable module is
a module the migration cannot deliver. The gap is invisible in single-module review — the module
compiles, installs, and passes its bed — and appears only when the mesh itself must produce the
image, which is the property nothing was checking.
## Open questions
- Is the fix purely mechanical — a `Dockerfile` + `build` block per module, mirroring the eight
that have one (`amqp-ping` the smallest example) — or do the tool-serving modules need a shared
runtime entrypoint convention settled first?
- Should a manifest that names a `mesh-runtime-*` placeholder without a `build` section be
refused at `module add`, so the gap cannot re-open silently?
- In what order do the 62 get their build sections — migration-critical modules first (the novox
and ace sets), or alongside each module's lab proof?