diff --git a/04-ISSUES/044-the-runtime-every-module-builds-on-cannot-be-built-by-the-mesh/00-report.md b/04-ISSUES/044-the-runtime-every-module-builds-on-cannot-be-built-by-the-mesh/00-report.md
index d4d773b..f5ca865 100644
--- a/04-ISSUES/044-the-runtime-every-module-builds-on-cannot-be-built-by-the-mesh/00-report.md
+++ b/04-ISSUES/044-the-runtime-every-module-builds-on-cannot-be-built-by-the-mesh/00-report.md
@@ -1,8 +1,8 @@
 ---
-status: open
+status: resolved
 opened: 2026-09-13
-located-in: []
-fixed-by:
+located-in: [mesh-tools, mesh-sdk]
+fixed-by: mesh-tools feat/run-once-entry, mesh-sdk feat/adr-ref-resync
 amended-design:
 ---
 
@@ -71,3 +71,42 @@ the mesh can produce it too, because that is all the mesh does.
   the builder is a compiled program built from its own sources and a language toolchain, and does
   not stand on this base at all. Only modules written in the mesh's scripted toolchain do. So the
   thing that would build the base is not one of the things built on it, and the chain has an end.
+
+## Resolved, 2026-09-13
+
+The base is a module now, built from its own repository and nothing else.
+
+Three things were in the way, and the third was not visible until the first two were gone:
+
+- **The toolkit could not be fetched.** It is named by a pinned commit of its own repository rather
+  than by a folder on somebody's disk. Both repositories turned out to be readable without a
+  credential, so no package registry was needed after all — which is why this was smaller than it
+  looked.
+- **The toolkit shipped no compiled output.** Every one of its entry points pointed into a directory
+  that is not in source control. It declares the hook that is meant to compile it on install, and
+  the package manager in use does not run that hook — so the build compiles it explicitly instead.
+  Relying on a hook firing would have failed the same invisible way this issue is about.
+- **The base is also the compile environment.** Every module's recipe starts from this image and
+  invokes the compiler out of it. A first attempt dropped the build tools to make a smaller image,
+  which broke every module built on it. They stay, and the recipe now says why.
+
+The drift this issue reported is also closed: the recipe claimed one operating system while serving
+another, and now states what is actually in service. Changing that was deliberately *not* folded in
+— a module already builds against it with that system's package manager, and moving the ground
+under every module at the same moment as making it buildable would be two changes wearing one
+commit.
+
+**Checked the way the report said it should be.** The repository was cloned alone, with nothing
+beside it, and built by the mesh. Then every module was moved onto the result, and the base changed
+for real: all three went stale, each naming the base and the commits it moved between, each listed
+once. Changing only a comment in the base — a new commit, a byte-identical image — correctly makes
+nothing stale, which is a second bug this exercise found and fixed: staleness was comparing commits
+when it should compare artifacts, so the mesh would have rebuilt itself entirely to arrive back
+exactly where it started.
+
+## What is still true
+
+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.