2 Commits

Include renames

Author	SHA1	Message	Date
jschoubben	bf4d4e2e7b	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.	2026-09-30 00:39:09 +02:00
jochen	35db2aaa41	Issue 117: a module's own code is a container in one record and a process in another ... 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.	2026-09-25 16:15:00 +02:00