WP3: a TypeScript bundle carries what it runs with, the runtime's credential belongs to its account, and the gate refuses spreading not standing (hq to-be 38) #226

2026-10-02T19:46:21Z

mesh-admin commented

2026-10-02 19:46:21 +00:00

The controller's side of hq to-be 38 WP3 (node-tools beside mesh-tools). Three commits, each with tests.

A TypeScript bundle carries what it runs with (ca7e81e). Toolchain.Dependencies names a directory in the toolchain image copied whole into the compiled output after the compile; typescript sets /app/runtime, which mesh-tools #31's toolchain image carries: a package.json saying "type": "module" and the pruned production node_modules. Without it no TypeScript bundle could ever start on a machine (no bundle had run live to show it). An older toolchain image fails the build by name. Go and Python set nothing.
The runtime's credential belongs to the account it runs as (773b561). For the runtime module only, when the node has an account, its own-secret files get owner: <account>; a manifest cannot say ${machine:account} safely because a node without an account has nothing to resolve it to.
The gate refuses spreading, not standing (729a5f9). Once node-tools is registered, a tools container on the runtime's image is refused for a module new to the catalogue or returning to that shape after moving; the ~30 modules already in that shape are rebuilt without complaint until each moves (WP4 on). Design 38 WP2.4 is amended accordingly (hq PR to follow).

Also confirmed: MESH_TOOL_MODULES composes to "" on a node where node-tools is the only bundle; the host's process shape and the runtime both accept that.

go build, go vet, go test ./... green except the pre-existing fail2ban manifest check.

Merge order: this first (it rolls to the control node), then mesh-tools #31 rebuilds the toolchain image with /app/runtime; only then is node-tools registered by building the repository path, which is the live step.

The controller's side of **hq to-be 38 WP3** (node-tools beside mesh-tools). Three commits, each with tests. 1. **A TypeScript bundle carries what it runs with** (`ca7e81e`). `Toolchain.Dependencies` names a directory in the toolchain image copied whole into the compiled output after the compile; typescript sets `/app/runtime`, which mesh-tools #31's toolchain image carries: a `package.json` saying `"type": "module"` and the pruned production node_modules. Without it no TypeScript bundle could ever start on a machine (no bundle had run live to show it). An older toolchain image fails the build by name. Go and Python set nothing. 2. **The runtime's credential belongs to the account it runs as** (`773b561`). For the runtime module only, when the node has an account, its own-secret files get `owner: <account>`; a manifest cannot say `${machine:account}` safely because a node without an account has nothing to resolve it to. 3. **The gate refuses spreading, not standing** (`729a5f9`). Once node-tools is registered, a tools container on the runtime's image is refused for a module new to the catalogue or returning to that shape after moving; the ~30 modules already in that shape are rebuilt without complaint until each moves (WP4 on). Design 38 WP2.4 is amended accordingly (hq PR to follow). Also confirmed: `MESH_TOOL_MODULES` composes to `""` on a node where node-tools is the only bundle; the host's process shape and the runtime both accept that. `go build`, `go vet`, `go test ./...` green except the pre-existing fail2ban manifest check. **Merge order:** this first (it rolls to the control node), then mesh-tools #31 rebuilds the toolchain image with `/app/runtime`; only then is node-tools registered by building the repository path, which is the live step.

mesh-admin added 3 commits 2026-10-02 19:46:21 +00:00

A TypeScript bundle carries what it runs with: the toolchain's runtime directory is copied into it (hq to-be 38 WP3, ADR 0188) ca7e81e964

A bundle that compiled was not yet a bundle that ran. The compiler resolved `import "nats"` from
the toolchain image's own node_modules and the pack took only what the compiler wrote, so what a
machine unpacked could not find a single dependency — and Node would have read the bare `.js` as
CommonJS besides. No TypeScript bundle had run live to show it; the runtime's own is the first that
must. A toolchain now names a Dependencies directory in its image, copied whole into the output's
root after the compile by a second run in the same image: for TypeScript /app/runtime, which the
runtime's image puts a `"type": "module"` package.json and its pruned node_modules at. An older
image without it fails the build by name rather than packing a bundle that starts nowhere. The
SDK's and the runtime's dependencies, nothing module-specific yet: a skeleton, by ADR 0188 §5.

The runtime's credential belongs to the account it runs as (hq to-be 38 WP3) 773b561f5e

The runtime's process is composed `user: <account>` where the node has one, and its broker file was
root's at 0600: a credential the process could not read. Composed in the declaration rather than
said in the manifest, because a manifest cannot say ${machine:account} safely — a node with no
account has nothing to resolve it to — and there the runtime runs as root and the file stays root's.

The gate refuses the old tool-container pattern spreading, not a rebuild of what already stands (hq to-be 38 WP2.4, amended by WP3) 729a5f9e6c

Once the runtime module is registered, a module serving tools from a container built on the
runtime's image is refused at registration — as written, including every rebuild of the thirty-odd
modules already in that shape, from the day the runtime arrives until WP4 onward moves each one.
That would stop the catalogue's whole pipeline to make a point the record already makes. Now a
module already registered in that shape — judged from the manifest the catalogue holds and what
its newest build stood on, the same two things a new registration is judged by — is rebuilt as
before; a module new to the catalogue in that shape, or one that had moved to a bundle and comes
back, is refused naming the record.

mesh-admin merged commit d07018f3c5 into main

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

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

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

Sign in to join this conversation.

1 Participants

Notifications

Due Date

No due date set.

Dependencies

No dependencies set.

Reference: novox/mesh-controller#226