The three parked questions are answered: 0114 accepted, 0068 superseded, 117 settled

**0114 accepted.** The separation it draws — a consumer's resource and a
credential that reaches it are different things — is a data-loss rule,
and a record naming one should not sit unresolved while the code that
could hit it is written. Not built, and accepting it schedules nothing;
accepted-and-not-built is where 0141 and 0142 already are.

**0068 superseded by 0149, the live mesh is the test bed.** Never built,
and contradicted by practice that was written down nowhere but a handoff
note. The faults that cost the most are faults of a mesh that already
exists — bound consumers, containers made against an older roster, an
adopted machine — and a bed is by construction a mesh that does not.
Issue 156 settles it: that change was verified honestly, on the only path
where it cannot fail. The lab is not retired; raising a mesh from bare is
now its whole job.

**117 answered by 0150.** A module's own code runs as supervised
processes under the module's one account. 0047's argument was for a
runtime per module, not for a container — a unit satisfies it and runs as
an account. The invariant is the account, not the process count: its
worry was a second identity to scope and seal, and processes sharing one
account create none. Designs 18 and 20 now cite it and 0047 carries a
dated pointer, which closes the third disagreement — that neither design
knew the record existed.

04-ISSUES/117-a-modules-own-code-is-a-container-and-a-process/00-report.md

@@ -1,8 +1,8 @@
 ---
-status: located
+status: resolved
 opened: 2026-09-25
 located-in: [hq, mesh-catalog modules/showcase, mesh-sdk src/tools/index.ts, mesh-tools]
-fixed-by:
+fixed-by: hq ADR 0150 — a module's own code runs as supervised processes under the module's one account; designs 18 and 20 now cite it, and ADR 0047 carries a dated note pointing at it
 amended-design:
 ---
 
@@ -99,3 +99,27 @@ what the sidecar is has nowhere in the design layer to look, which is how this w
   is mechanically checkable: the resource types a design doc names are a closed set, and every
   member of it either appears in a decision or does not. Whether that check is worth writing is
   part of this issue, not settled by it.
+
+## Answered (2026-09-30)
+
+[ADR 0150](../../02-DECISIONS/0150-a-modules-own-code-runs-as-supervised-processes-under-one-account.md)
+settles all three disagreements, and the design documents win two of them:
+
+1. **Container or unit — a supervised process.** ADR 0047's argument never required a container. It
+   argued for a runtime *per module*, because a node-wide one could not hold a per-module account and
+   per-module runtimes on one tool key would be handed calls for tools they do not have. A unit per
+   module satisfies that exactly, and a unit runs as an account. The container was the mechanism to
+   hand. [ADR 0142](../../02-DECISIONS/0142-the-mesh-delivers-its-own-components-as-binaries.md) had
+   already gone the same way for the mesh's own components, and a module is not a container.
+2. **One process or several — several, under one account.** 0047's "one module, one process, one
+   account" carried its weight in the last clause; its stated worry was "not a second one to scope and
+   seal", which is about a second *identity*. Processes sharing the module's one account create none.
+   What a module may not have is two accounts.
+3. **Whether the record was consulted — fixed rather than answered.** Designs 18 and 20 now name 0150
+   in `decisions:`, and 0047 carries a dated note saying where its hosting form was settled, so neither
+   door leads to the wrong answer any more.
+
+**What this does not fix.** A module's code delivered as a binary is behind the same gap as the host's
+own ([ADR 0141](../../02-DECISIONS/0141-the-host-delivers-its-own-successor.md), accepted and not
+built): a container's code arrives by `docker pull` and this does not, so until delivery exists such a
+module is one somebody places by hand. 0150 records that as the cost of the decision, unpaid.