node-tools in Go: the node's runtime, launch-only, wire-compatible with the TypeScript (hq ADR 0193) #38

2026-10-03T19:26:16Z

mesh-admin commented

2026-10-03 19:26:16 +00:00

hq ADR 0193 decision 4, design 38 WP4d.

The node's runtime rewritten in Go (node-tools/go.mod, cmd/node-tools, internal/{bus,launch,runtime,console,wire}; ~2,700 lines incl. tests): credential with pinned TLS and patient connect; MESH_TOOL_MODULES / MESH_TOOL_ENV; memberships followed live from ASSIGNMENTS; every served bundle launched (MCP on stdio, module words + MESH_SERVED_MODULE/MESH_MODULE/MESH_NODE, non-executable refused, dead child restarted, mesh/publish published as the module); tools, seat verbs and the tools answer on the membership subjects; the console as MCP over HTTP on loopback (aggregated listing, node routing, _meta.notAnswering).

node-tools/module.json now builds the runtime from Go (system: arch, binary node-tools); mesh-controller #240 runs it as ./node-tools and mesh-host #81 resolves that to its own bundle. Node.js stays for the TypeScript bundles it launches. The TypeScript source stays: it is the runtime image the WP4c containers run.

Differences from the TypeScript: the one-module import form is refused (containers only); flushes after (re-)serving; a tool it cannot serve is logged and skipped rather than fatal; replies always carry result.

Tests: 34 Go tests against a real bus (bus, console, runtime), stable over three runs; reviewed and rerun by me. Live smoke test before merge: the binary ran on the laptop with the laptop's runtime credential (pinned TLS), its console on a spare port: it connected, listed 228 tools, and mesh-controller.nodes answered with all four machines. Static binary 7.9 MB.

Merge after #36 and after every TypeScript bundle carries a launcher with SDK 0.1.5.

hq ADR 0193 decision 4, design 38 WP4d. The node's runtime rewritten in Go (node-tools/go.mod, cmd/node-tools, internal/{bus,launch,runtime,console,wire}; ~2,700 lines incl. tests): credential with pinned TLS and patient connect; `MESH_TOOL_MODULES` / `MESH_TOOL_ENV`; memberships followed live from ASSIGNMENTS; every served bundle launched (MCP on stdio, module words + `MESH_SERVED_MODULE`/`MESH_MODULE`/`MESH_NODE`, non-executable refused, dead child restarted, `mesh/publish` published as the module); tools, seat verbs and the `tools` answer on the membership subjects; the console as MCP over HTTP on loopback (aggregated listing, `node` routing, `_meta.notAnswering`). `node-tools/module.json` now builds the runtime from Go (`system: arch`, binary `node-tools`); mesh-controller #240 runs it as `./node-tools` and mesh-host #81 resolves that to its own bundle. Node.js stays for the TypeScript bundles it launches. The TypeScript source stays: it is the runtime image the WP4c containers run. Differences from the TypeScript: the one-module import form is refused (containers only); flushes after (re-)serving; a tool it cannot serve is logged and skipped rather than fatal; replies always carry `result`. Tests: 34 Go tests against a real bus (bus, console, runtime), stable over three runs; reviewed and rerun by me. **Live smoke test before merge:** the binary ran on the laptop with the laptop's runtime credential (pinned TLS), its console on a spare port: it connected, listed 228 tools, and `mesh-controller.nodes` answered with all four machines. Static binary 7.9 MB. Merge after #36 and after every TypeScript bundle carries a launcher with SDK 0.1.5.

mesh-admin added 2 commits 2026-10-03 19:26:16 +00:00

node-tools in Go: the node's runtime, launch-only, wire-compatible with the TypeScript (hq ADR 0193) e45389f75a

The runtime knows no language, so nothing ties it to Node.js. This ports its serve mode — the
pinned bus connection and patient connect, following memberships, launching every served bundle
over MCP on stdio with its own environment, a child's emit published as its module, each tool,
the tools verb and seat verbs served where the mesh issued them, and the console on loopback —
to one static binary. Same subjects, request and reply bodies, event headers and MCP answers.
The TypeScript stays: it is still the runtime inside the per-module containers until WP4c.
Tests run against a real bus and share the TypeScript fixtures.

node-tools is built from Go (hq ADR 0193) e6a33dd969

The node's runtime is the Go binary: one static executable the host runs as ./node-tools from its own
bundle. Node.js stays on the machine for the TypeScript bundles the runtime launches. The TypeScript
source stays in the repository: it is the runtime image the per-module containers run until WP4c.

jschoubben added 1 commit 2026-10-03 20:02:14 +00:00

Merge remote-tracking branch 'origin/main' into feat/0193-node-tools-in-go 486dad99a5

mesh-admin merged commit 915f372a85 into main

2026-10-03 20:02:16 +00:00

mesh-admin deleted branch feat/0193-node-tools-in-go

2026-10-03 20:02:16 +00:00

Sign in to join this conversation.

2 Participants

Notifications

Due Date

No due date set.

Dependencies

No dependencies set.

Reference: novox/mesh-tools#38