jochen
7722668220
The Go runtime answers $SRV.PING, $SRV.INFO and $SRV.STATS (and per name and id) in the io.nats.micro.v1 format with what it serves at the moment it is asked: one service per runtime process, since the bus admits one reply per request from each responder, and one endpoint per tool per subject, its metadata saying module, seat, scope, machine, description, schema and whether the module is interchangeable. Serving is unchanged. The console gathers one $SRV.INFO request's answers instead of asking the catalogue's roster and each module's tools, and reads the controller's records as JSON for what should have answered: an assignment with tools that did not announce is named, a module without tools never is. The text parsers of node list and module list are gone. Packages share the test bus: go test -p 1.
node-tools
The node's tool runtime as a module (novox/hq ADR 0175, to-be 38 WP3). Assigned to a machine, it is one process the host runs from this bundle, as the operator's account: it serves every assigned module's tools and every held seat's verbs on the bus, and answers MCP on the machine's loopback — the console (design 34). The controller composes the process (which bundles to load, where the credential is, whose machine it is); this manifest says only what the machine must have for it: the interpreter, a place for the credential, the loopback port, and leave to call every tool.
The code is the mesh-tools package in this directory; the module at the repository root,
mesh-tools, builds the images TypeScript bundles are compiled in. See the repository README.