jschoubben
98e9e62fce
060: 44 of 70 modules now mesh-buildable (was 8) — the mechanical majority, proven by direct builds and the bed. The structural remainders: external-dependency fetch (new issue 064) and route-proxy's cross-repo build context. 064 records the build environment's isolation from public npm and Docker Hub.
2.2 KiB
status, opened, located-in, fixed-by, amended-design
| status | opened | located-in | fixed-by | amended-design | ||
|---|---|---|---|---|---|---|
| resolved | 2026-09-17 |
|
mesh-catalog feat/the-mesh-builds-its-catalogue (965c58f); proven by the built-store-cross-node bed and direct builds |
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?