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) #31

2026-10-02T19:43:59Z

mesh-admin commented

2026-10-02 19:43:59 +00:00

hq to-be 38 WP3, with the operator's decision: keep mesh-tools as the module the images come from, add node-tools beside it in the same repository (ADR 0069).

node-tools/ holds the runtime (code, tests, package) and its manifest: one typescript bundle with entrypoint src/main.js, package: nodejs, own-secrets.broker under a 0755 mesh-state directory (the controller sets the file's owner to the operator account), the loopback listens the console declared, invokes: ["*"], no tools. The process itself is the controller's to compose (WP2).
As node-tools, serve is also the console: MCP on 127.0.0.1:4270 (or MESH_CONSOLE_LISTEN). Containers of a module's own runtime keep serving without a listener.
Dockerfile: stages deps → compiling → lean → toolchain / runtime; the toolchain image carries /app/runtime (package.json {"type":"module"} + production node_modules) for the builder to copy into every TypeScript bundle, so a bundle unpacked on a machine starts. The builder's side is a mesh-controller PR to follow.
Root README describes the two modules; the dead AMQP probe script is removed.

Tests: 32 of 32 against a real NATS, including the new one: main.js started with a node-tools credential and MESH_TOOL_MODULES serves a bundle on the bus and answers tools/list and tools/call on loopback as the console. The bundle was also compiled with the toolchain's exact flags (--rootDir . --outDir … src/main.ts) and started.

Merge order: this can merge any time (it only rebuilds the images; node-tools is not registered until the controller's toolchain change has rolled). Registering and assigning node-tools is the live step and happens by hand afterwards, one node at a time.

**hq to-be 38 WP3**, with the operator's decision: keep `mesh-tools` as the module the images come from, add `node-tools` beside it in the same repository (ADR 0069). - `node-tools/` holds the runtime (code, tests, package) and its manifest: one typescript `bundle` with entrypoint `src/main.js`, `package: nodejs`, `own-secrets.broker` under a 0755 `mesh-state` directory (the controller sets the file's owner to the operator account), the loopback `listens` the console declared, `invokes: ["*"]`, no `tools`. The process itself is the controller's to compose (WP2). - As node-tools, `serve` is also the console: MCP on `127.0.0.1:4270` (or `MESH_CONSOLE_LISTEN`). Containers of a module's own runtime keep serving without a listener. - Dockerfile: stages `deps → compiling → lean → toolchain / runtime`; the toolchain image carries `/app/runtime` (`package.json` `{"type":"module"}` + production node_modules) for the builder to copy into every TypeScript bundle, so a bundle unpacked on a machine starts. The builder's side is a mesh-controller PR to follow. - Root README describes the two modules; the dead AMQP probe script is removed. **Tests:** 32 of 32 against a real NATS, including the new one: `main.js` started with a node-tools credential and `MESH_TOOL_MODULES` serves a bundle on the bus and answers `tools/list` and `tools/call` on loopback as the console. The bundle was also compiled with the toolchain's exact flags (`--rootDir . --outDir … src/main.ts`) and started. **Merge order:** this can merge any time (it only rebuilds the images; node-tools is not registered until the controller's toolchain change has rolled). Registering and assigning node-tools is the live step and happens by hand afterwards, one node at a time.

mesh-admin added 1 commit 2026-10-02 19:43:59 +00:00

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) c46f9502ee

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.

mesh-admin merged commit 5d488a45f7 into main

2026-10-02 19:57:25 +00:00

mesh-admin deleted branch feat/wp3-node-tools

2026-10-02 19:57:26 +00:00

Sign in to join this conversation.

1 Participants

Notifications

Due Date

No due date set.

Dependencies

No dependencies set.

Reference: novox/mesh-tools#31