2026-09-17 20:39:02 +00:00
1 changed files with 42 additions and 0 deletions
@@ -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?