04-ISSUES/209-a-bundles-own-sdk-copy-registers-into-a-registry-the-runtime-never-reads/00-report.md

@@ -1,9 +1,9 @@
 ---
-status: located
+status: resolved
 opened: 2026-10-03
 located-in:
   - mesh-tools
-fixed-by:
+fixed-by: mesh-tools #32
 amended-design:
 ---
 
@@ -49,3 +49,11 @@ one broker — and leaves everything else a bundle carries to the bundle's own t
 bundle from a directory holding its own copy of the SDK and asserts its tools are served. The
 toolchain keeps copying dependencies in: a bundle launched as a process ([ADR 0188](../../02-DECISIONS/0188-a-modules-own-code-is-bundles-in-any-language-and-a-tools-bundle-speaks-mcp-to-the-runtime.md))
 needs them, and an imported one is simply not allowed to bring a second SDK.
+
+## Resolution
+
+2026-10-03, mesh-tools #32: the runtime installs a synchronous resolve hook before the first bundle is
+imported, sending every import of the SDK, from whichever bundle, to its own copy; a bundle's other
+dependencies still resolve from its own tree, and a bundle launched as a process is untouched. The test
+loads a bundle from a directory holding its own copy of the SDK and its own dependency, and sees its
+tool served with the dependency's answer. Proven live by WP4's proof in design 38.