jschoubben
0b002ef39c
Only 8 of 70 modules carry a build section; the other 62 exist through an out-of-band build script plus placeholder rewriting, so the mesh's own build-and-deliver path has never run for them. Found by the no-fake bed; blocks it and the migration's delivery assumption. https://claude.ai/code/session_01D6qtiYU3P9jk3pnAXyAFyx
2.1 KiB
status, opened, located-in, fixed-by, amended-design
| status | opened | located-in | fixed-by | amended-design |
|---|---|---|---|---|
| open | 2026-09-17 |
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+buildblock per module, mirroring the eight that have one (amqp-pingthe 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 abuildsection be refused atmodule 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?