hq/04-ISSUES/064-a-mesh-build-cannot-fetch-a-modules-external-dependencies/01-diagnosis.md

Diagnosis — 2026-09-21

1. The package half was read against what the mesh now runs. The mesh's package registry has proxied the public one for every package since early September, before this issue was opened; and the builder's .npmrc names the mesh's registry for the mesh's own scope only, so a public package is asked of the public registry directly. Either the failing build ran before the proxy, or its Dockerfile set the registry itself, or the build machine could not reach the public registry at that moment. The report does not say which, and the 404 cannot be placed without running the build again. Not fixed; not reproduced either.
2. The image half has a precedent. The lab hit the same refusal pulling a vendor tool and found the cause was the public hub denying anonymous pulls, not the mesh's redirect; the fix was to pin the same image from another registry. A COPY --from of a public image is a build input the manifest does not declare, so the mesh cannot pre-fetch or pin it the way it pins bases — which is the second open question, and the one a decision has to settle.
3. Ruled out: that the build environment has no internet. Package installs from the system's repositories succeed in the same Dockerfiles.

Located in: the builder (what it tells npm and the runtime) and the catalogue (three modules whose Dockerfiles fetch what no manifest names). The image half is decided and built: ADR 0097 — a vendor image is declared under build.on, copied in, and a recipe fetching what is undeclared is refused. Still open: the package half — a build must be re-run against the mesh's proxying registry to place the 404 — and the three recipes themselves, which now declare their images or are refused.