Issue 209: a bundle's own SDK copy registers into a registry the runtime never reads; design 38 WP4 note #316
+10
-2
@@ -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.
|
||||
|
||||
Reference in New Issue
Block a user