Merge pull request 'Issue 211: a bundle is built before the toolchain it is compiled in; ADR 0192 progressive insight; design 38 WP4b built, WP4c opened' (#322) from issues/211-and-0192-insight into main

This commit was merged in pull request #322.
This commit is contained in:
2026-10-03 13:36:43 +00:00
3 changed files with 79 additions and 0 deletions
@@ -30,6 +30,19 @@ runtime calls without one, so every bundle reads the process's four words.
Without a rule, each of the thirty-one would answer the question its own way, and the runtime's
process would be the one place where every module's paths meet.
> **Progressive insight — 2026-10-03.** The context above calls the thirty-one remaining containers
> tool containers handed what a bundle cannot receive. Measured the same day while building this
> record: nine of them run only tools; three run a main of their own; twenty import, beside their
> tools, the module's own long-running code — event handlers that subscribe on the bus and
> provisioners that act on grants — under the module's own bus identity, and some reach their
> service by a container network name or need a package the image installed. That code is not a
> tool and is not this record's to move: under
> [ADR 0188](0188-a-modules-own-code-is-bundles-in-any-language-and-a-tools-bundle-speaks-mcp-to-the-runtime.md)
> §3 it is a `process` bundle, and how it is given its credential, its words and its reach is the
> open question of [design 38](../03-DESIGN/01-to-be/38-building-the-operators-machine.md) WP4c.
> Decision 4 applies to these containers' tools; the containers themselves go when their other
> code has moved. The decision and its options stand.
## Considered Options
1. **The bundle declares its environment on its artifact, and the mesh composes it as a
@@ -245,6 +245,25 @@ credential gone. Last, the registration gate refuses the container shape for eve
answer from the runtime on the machines that run it, `docker ps` shows no tool container on any of
the four, and `status` is well.
*Found 2026-10-03, building it:* of the thirty-one, nine run only tools, three a main of their own,
and twenty import the module's own event handlers and provisioners beside their tools (ADR 0192's
dated note). WP4b moves the tools-only nine; WP4c holds the rest. Two of the nine stay with WP4c as
well — one carries a run-once provisioning step in a second container, one reads an env-file and two
sockets — so seven move here. *Built 2026-10-03:* mesh-sdk #12 (`collectToolsEach`), mesh-tools #33
(each bundle its own environment), mesh-controller #236 and #237 (the words composed, made the
account's to read, and named files restarting the runtime), and the seven modules in one change.
Building it found issue [211](../../04-ISSUES/211-a-bundle-is-built-before-the-toolchain-it-is-compiled-in/00-report.md).
## WP4c — The module's own long-running code moves
*Not yet broken down.* Twenty-three containers carry code that is not a tool: event handlers,
provisioners, a step, a main. [ADR 0188](../../02-DECISIONS/0188-a-modules-own-code-is-bundles-in-any-language-and-a-tools-bundle-speaks-mcp-to-the-runtime.md)
§3 already says such code is a `process` bundle the host runs. What no record says yet is how that
process is given what its container was: the module's own bus credential and the subscriptions it
consumes with, the words its code reads at import, the packages the image installed (a database's
client), and the service it reaches by a container network name. That begins with a decision record,
after which the twenty-three move and the registration gate refuses the container shape for all.
## WP5 — The shell, on a server first
*mesh-catalog #224, already written. Half a day to assign and prove.*
@@ -0,0 +1,47 @@
---
status: located
opened: 2026-10-03
located-in:
- mesh-controller
fixed-by:
amended-design:
---
# 211 — A bundle is built in the same tier as the toolchain it is compiled in, against the old toolchain
## What was observed
2026-10-03, merging a runtime change that needed a new SDK release. The SDK was published first;
then the merge of the tools repository planned two tiers, and the first held both the toolchain
images and the runtime's own bundle:
```
> tier 0
mesh-tools asked
node-tools built from 8e30ea9f
```
The bundle was built while its toolchain image was still being built. A TypeScript bundle's
dependencies are copied from the toolchain image it is compiled in
([design 38](../../03-DESIGN/01-to-be/38-building-the-operators-machine.md) WP3), so this one was
compiled and packed against the toolchain as it stood before the merge — carrying the old SDK —
and was recorded as built from the new commit.
## Why it matters beyond this instance
Every bundle compiled by a toolchain depends on the module that publishes that toolchain, and the
planner does not know it: a manifest names its toolchain by `language`, not in `build.on`, so the
dependency is implicit and the tiers are computed without it. Whenever a change touches the
toolchain and a bundle in one merge — or the toolchain's own repository holds a bundle, as this one
does — the bundle is built against the previous toolchain and reported current. Nothing fails; the
bundle simply carries yesterday's dependencies under today's commit.
## Diagnosis
Owner mesh-controller: the planner orders a merge's modules by `build.on`; the builder's toolchain
for a bundle (`ToolchainFor(language)`: the module and artifact it is compiled in) is not part of
that order. **Fix direction:** the planner treats a bundle's toolchain as a `build.on` it did not
have to write — a bundle of language L depends on the module that publishes L's toolchain — so the
bundle lands in the tier after it. A test: a merge touching the toolchain module and a TypeScript
bundle plans the bundle one tier later. Worked around on the day by building the bundle again once
the toolchain was built.