Issue 117: a module's own code is a container in one record and a process in another #110

2026-09-25T14:35:03Z

jschoubben commented

2026-09-25 14:35:03 +00:00

Opened from the question "what is the sidecar, and could it be a process instead?" — and the answer is that the repository already says both.

What this adds

Issue 117 — report and diagnosis. The report records the disagreement; the diagnosis settles what the report could not, against the code repositories rather than against hq alone.

Issue 114 — the controller's container-or-process question, filed 2026-09-24 on a branch of its own and never merged. Its commit and authorship are intact; it is renumbered from 113 (taken) to 114 (free, because a sibling branch folded it) and cross-referenced with 117 both ways.

What the diagnosis found

The process shape is real. mesh-host defines TypeProcess, applies it — unit, timer, run-once gating — and tests it in two packages. The host's vocabulary is twelve shapes, not the nine ADR 0029 counted. So the report's alternative, that two proposed documents describe a type that does not exist, is disproven.
ADR 0029's enforcement is intact and was not enough. The vocabulary-count test names the decision behind each addition: network→0029, access→0051, opening→0100. The eleventh names a proposed design document, and TypeProcess is the only shape in the vocabulary whose doc comment cites no ADR. Requiring every addition to name something does not require it to name a decision.
The argument exists as a Go test comment. "It is a full-host shape rather than a portable one: it needs a process supervisor to install into. It does NOT need a container runtime, which is the point — only software that genuinely needs isolation asks for a container." That is a decision's context and consequences, in another repository.
The catalogue is a third answer: 115 container declarations against 3 process, all three in showcase — the module the worked guide documents. There the tools resource is a container running sleep infinity on a bare upstream base with the broker credential mounted, and the tools and provisioner entrypoints are run by nothing. That is the condition ADR 0047 was written to end, back in a new shape.
Where the isolation argument leaks is narrower than expected. The serving key and the credential shape both conform to ADR 0047. But serveTools serves every registered module over one broker connection, the runtime takes its modules from a comma-separated list, and x-source is stamped from the single credential — so two modules in one runtime means the second's events are attributed to the first. Nothing refuses it and no test asserts against it.

What it deliberately does not do

It does not decide whether container or process is right. It establishes that the question was answered in practice and never recorded, and locates the gap on hq: the implementation and the design layer agree with each other, and the missing thing is the record, while ADR 0047 stands accepted and unsuperseded saying the other thing.

Notes for review

One correction is kept in the diagnosis trail rather than tidied away: the first search was for len(Vocabulary()), found nothing, and was two steps from being written up as "the mechanism ADR 0029 relied on is gone." The test binds the slice to a local first. A negative search result read as a fact about the world is the same error issue 113 recorded, and the diagnosis names which trees were searched for that reason.
114 and 117 are both status: located/open as appropriate; no decision record is added here, because which shape is right is not settled by this.
The superseded branch issue/113-controller-container-or-process should be deleted once this merges.
cycle.py, records.py and index.py all pass (269 documents).

Opened from the question *"what is the sidecar, and could it be a process instead?"* — and the answer is that the repository already says both. ## What this adds **Issue 117** — report and diagnosis. The report records the disagreement; the diagnosis settles what the report could not, against the code repositories rather than against `hq` alone. **Issue 114** — the controller's container-or-process question, filed 2026-09-24 on a branch of its own and never merged. Its commit and authorship are intact; it is renumbered from 113 (taken) to 114 (free, because a sibling branch folded it) and cross-referenced with 117 both ways. ## What the diagnosis found - **The `process` shape is real.** `mesh-host` defines `TypeProcess`, applies it — unit, timer, run-once gating — and tests it in two packages. The host's vocabulary is **twelve** shapes, not the nine ADR 0029 counted. So the report's alternative, that two proposed documents describe a type that does not exist, is disproven. - **ADR 0029's enforcement is intact and was not enough.** The vocabulary-count test names the decision behind each addition: `network`→0029, `access`→0051, `opening`→0100. The eleventh names a **`proposed` design document**, and `TypeProcess` is the only shape in the vocabulary whose doc comment cites no ADR. Requiring every addition to name *something* does not require it to name a decision. - **The argument exists as a Go test comment.** *"It is a full-host shape rather than a portable one: it needs a process supervisor to install into. It does NOT need a container runtime, which is the point — only software that genuinely needs isolation asks for a container."* That is a decision's context and consequences, in another repository. - **The catalogue is a third answer:** 115 `container` declarations against 3 `process`, all three in `showcase` — the module the worked guide documents. There the tools resource is a container running `sleep infinity` on a bare upstream base with the broker credential mounted, and the tools and provisioner entrypoints are run by nothing. That is the condition ADR 0047 was written to end, back in a new shape. - **Where the isolation argument leaks is narrower than expected.** The serving key and the credential shape both conform to ADR 0047. But `serveTools` serves every registered module over one broker connection, the runtime takes its modules from a comma-separated list, and `x-source` is stamped from the single credential — so two modules in one runtime means the second's events are attributed to the first. Nothing refuses it and no test asserts against it. ## What it deliberately does not do It does not decide whether `container` or `process` is right. It establishes that the question was answered in practice and never recorded, and locates the gap on `hq`: the implementation and the design layer agree with each other, and the missing thing is the record, while ADR 0047 stands accepted and unsuperseded saying the other thing. ## Notes for review - One correction is kept in the diagnosis trail rather than tidied away: the first search was for `len(Vocabulary())`, found nothing, and was two steps from being written up as *"the mechanism ADR 0029 relied on is gone."* The test binds the slice to a local first. A negative search result read as a fact about the world is the same error issue 113 recorded, and the diagnosis names which trees were searched for that reason. - `114` and `117` are both `status: located`/`open` as appropriate; no decision record is added here, because which shape is right is not settled by this. - The superseded branch `issue/113-controller-container-or-process` should be deleted once this merges. - `cycle.py`, `records.py` and `index.py` all pass (269 documents).

jschoubben added 3 commits 2026-09-25 14:35:03 +00:00

Issue 117: a module's own code is a container in one record and a process in another 35db2aaa41

Asked what the "sidecar" is and whether a supervised process would do instead. The repository
answers both ways. ADR 0047 (accepted, unsuperseded) says a module with tools or events runs a
container carrying its compiled code. To-be 18 and 20 (both proposed) define a `process` resource
type — the module's own code, a unit the machine's supervisor keeps up — and the worked guide says
plainly "it is why these are `process` rather than four containers." Neither design doc names 0047,
and no decision record mentions a `process` shape at all.

Diagnosed rather than left open, because the ground truth settles what the report could not.
The shape is real: mesh-host defines TypeProcess, applies it, and tests it, and the host's
vocabulary is twelve shapes rather than the nine ADR 0029 counted. So the alternative the report
offered — that two proposed documents describe a type that does not exist — is disproven.

ADR 0029's mechanism is intact and was not enough. The vocabulary-count test names the decision
behind each addition: network 0029, access 0051, opening 0100. The eleventh names a *proposed
design document*, and TypeProcess is the only shape in the vocabulary whose doc comment cites no
ADR. Requiring every addition to name something does not require it to name a decision.

The argument this issue asked for already exists — as a Go test comment. "It is a full-host shape
rather than a portable one: it needs a process supervisor to install into. It does NOT need a
container runtime, which is the point — only software that genuinely needs isolation asks for a
container." That is a decision's context and consequences, in another repository.

What the catalogue does is a third thing: 115 container declarations against 3 process, all three
in showcase — the module to-be 20 documents. There the tools resource is a container running
`sleep infinity` on a bare upstream base with the broker credential mounted, and the tools and
provisioner entrypoints are run by nothing. That is the condition 0047 was written to end, back
in a new shape.

Where the isolation argument leaks is narrower than expected and worth having precisely: the
serving key and the credential shape both conform. But serveTools serves every registered module
over one broker connection, the runtime takes its modules from a comma-separated list, and
x-source is stamped from the single credential — so two modules in one runtime means the second's
events are attributed to the first. Nothing refuses it and no test asserts against it.

Located on hq rather than on a code repository: the implementation and the design layer agree,
and the missing thing is the record. Which shape is right is left open, deliberately — this
establishes that the question was answered in practice and never written down, not which answer
is correct.

One correction kept in the trail: the first search here was for len(Vocabulary()), found nothing,
and was two steps from being written up as "the mechanism ADR 0029 relied on is gone." The test
binds the slice to a local first. A negative search result read as a fact about the world is the
same error issue 113 recorded.

Issue 113: should the controller be a container or a process the host supervises 10a2b706c6

Filed after a session where every mesh-controller interaction went through
docker exec — its manifest runs it as a container with network: host, using
none of the isolation that resource type usually buys, while ADR 0006 makes
it the mesh's single point of coordination. Open question, not a claimed
defect: does type: container get the controller anything type: process
(supervised the way the host supervises its own unit, per ADR 0005) would not.

Issue 114: land the controller's container-or-process question, renumbered 82a6badc7c

Filed 2026-09-24 on a branch of its own and never merged, numbered 113, which is taken. 114 is
free because a sibling branch folded it, so it takes that number and keeps its commit.

Kept separate from issue 117 rather than folded into it. 117 asks the same question of every
module and locates the missing decision; this asks it of the controller, where `network: host`
means container network isolation — the property that resource type usually buys — is not in use.
That observation is this report's own and is nowhere in 117, and folding would lose it.

Its first open question is answered by 117's diagnosis and now says so: the host's `process` shape
is built, applied and tested, restart and run-to-completion semantics included, so deciding this
does not wait on host-side work.

jschoubben merged commit 93502a05dc into main

2026-09-26 12:14:38 +00:00

jschoubben deleted branch issue/117-a-modules-own-code-is-a-container-and-a-process

2026-09-26 12:14:38 +00:00

jschoubben referenced this pull request

2026-09-26 12:14:47 +00:00

Issue 114: should the controller be a container or a process the host supervises #100

jschoubben referenced this pull request

2026-09-26 12:20:39 +00:00

Issue 121: builder's real package-registry grant deadlocks a genesis bootstrap #117

Sign in to join this conversation.