A module names its base, so the mesh can act on what it notices

The mesh could already say which modules a base change invalidated, and could
not do anything about it: each recipe named one particular copy of the base by
fingerprint, and rebuilding produced the old one. Worse, the copy each named
existed only inside a throwaway lab, so those three modules could not be built
anywhere at all — and the line each replaced had the same fault.

04-ISSUES/044-the-runtime-every-module-builds-on-cannot-be-built-by-the-mesh/00-report.md

@@ -104,9 +104,26 @@ nothing stale, which is a second bug this exercise found and fixed: staleness wa
 when it should compare artifacts, so the mesh would have rebuilt itself entirely to arrive back
 exactly where it started.
 
-## What is still true
+## And then the other half, 2026-09-13
 
-A module names its base as a literal fingerprint in its own recipe. So the mesh can now *say* that
-three modules must be rebuilt, and rebuilding them still produces the old base until somebody edits
-that fingerprint. Noticing is solved; acting on it is the build chain driving itself, which is
-separate work.
+The paragraph that stood here said a module still named its base as a literal fingerprint in its own
+recipe — so the mesh could *say* which modules a base change had invalidated, and rebuilding them
+produced the old base anyway until somebody edited that line by hand.
+
+Worse than inconvenient, as it turned out. **A fingerprint names one particular copy of an image,
+and a copy exists on one mesh.** The three modules in the catalogue named a copy produced inside a
+throwaway lab, so none of them could be built anywhere else at all; and the line each of them
+replaced named a copy from an even earlier throwaway lab. Nobody noticed because the only place they
+had ever been built was the place the copy existed.
+
+**A module names the module now, and the mesh answers with the copy it holds.** The declaration says
+which module, which artifact, and the build argument the recipe reads it from. The request carries
+what this mesh has built, so the builder stays a thing that clones, builds and answers rather than
+something that asks the mesh questions — the answer travels with the question, because only the mesh
+knows what it has. A base the mesh has not built is refused before anything is built, naming which
+module has to exist first.
+
+Checked on a bare machine: postgres with nothing supplied is refused and says to build mesh-tools
+first; mesh-tools is built; postgres is built against it and the image carries the compiled module,
+the toolkit and the database client it provisions through. The recipes carry no default at all, so a
+build nobody told stops at the declaration rather than at a reference that resolves to nothing.