diff --git a/04-ISSUES/060-the-mesh-cannot-build-most-of-its-own-catalogue/00-report.md b/04-ISSUES/060-the-mesh-cannot-build-most-of-its-own-catalogue/00-report.md
new file mode 100644
index 0000000..9719020
--- /dev/null
+++ b/04-ISSUES/060-the-mesh-cannot-build-most-of-its-own-catalogue/00-report.md
@@ -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?