5 Commits

Include renames

Author	SHA1	Message	Date
jochen	847055c758	Give the TypeScript toolchain pg, mongodb and mssql, so a catalogue check can type-check the modules that use them (issue 385) ... A catalogue's TypeScript check fetches nothing and reads this image's node_modules. Once a module it cannot check fails rather than passing with a note, mesh-catalog, model-usage, mongodb and mssql could never merge again. They are development dependencies, so the runtime image stays as it is.	2026-10-12 12:27:46 +02:00
jochen	b52669577d	The toolchain carries the SDK the mesh last published, and esbuild (hq issue 212, ADR 0193) ... mesh-tools stands on mesh-sdk's published package: the build receives its exact version and installs it after the package.json install, so a release is a new argument and the cached layer cannot keep an older SDK; the planner orders the toolchain after the SDK, and every bundle after the toolchain (issue 211). esbuild, a development dependency, is what the builder bundles each TypeScript entrypoint and launcher into one file with.	2026-10-03 23:26:09 +02:00
jochen	ffe229308c	The node's runtime is its modules' bus: it binds each module's consumer and hands its events to the bundle (hq ADR 0198) ... A launched bundle's mesh/subscribe binds the module's own durable consumer — EVENTS, <node>_<module>, by name as the module's own runtime bound it, so nothing is lost or replayed in the move — and every event goes to each child of the module that subscribed as mesh/event, acknowledged only when all answered, negatively acknowledged after a short delay when one failed or died, terminated when it is not an event. mesh/ask calls a tool as the module. Every launched bundle is started again when it exits, with backoff, since long-running code waits for no call. Requires SDK 0.1.6.	2026-10-03 22:29:20 +02:00
jochen	ae6bdc9b06	Require SDK 0.1.5: a launched bundle names its module and emits through the runtime (hq ADR 0193) ... The toolchain image installs from this package.json with a range; unchanged, Docker reused the cached install and the image kept SDK 0.1.3 after 0.1.5 was published. Bundles copied that copy, so a launched bundle registering its seat first served the seat's verbs as its own tools. Requiring 0.1.5 says what the runtime and its bundles need, and invalidates the cached layer.	2026-10-03 21:23:50 +02:00
jochen	c46f9502ee	node-tools is a module beside mesh-tools: the runtime as a bundle, and serve is the console (hq ADR 0175, to-be 38 WP3) ... One repository, two modules (ADR 0069). `node-tools/` holds the runtime — its code, tests, package and the manifest of the module the controller composes a process for on every machine it is assigned to: a bundle of `src/main.js`, the interpreter as a package, a place for the node's credential, the loopback port the console declared, and leave to call every tool. Nothing about how it runs: which bundles to load, where the credential is and whose machine it is are the controller's to compose (WP2). The root module `mesh-tools` keeps the two images TypeScript bundles are compiled in and a module's own service may run in; it is no longer how tools reach a node. As node-tools, `serve` is also the console (ADR 0175 §6): the same process answers MCP on loopback for whoever is on the machine, through which the tools it serves can be called. A module's own runtime in a container keeps serving without a listener. The toolchain image now carries /app/runtime — a package.json saying the compiled files are ES modules and the production node_modules — for the builder to copy into every TypeScript bundle, so a bundle unpacked on a machine starts (ADR 0188 §5; the builder's side is the controller's). Proven here by compiling node-tools with the toolchain's exact flags and starting the result. The AMQP probe script is gone with the bus it probed.	2026-10-02 21:43:37 +02:00