jochen
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.
04-ISSUES
The front door for "something is wrong" at the level of the mesh's design or governance. Diagnosis happens here, where the whole mesh is in view; the fix lands in the owning code repository.
What belongs here
| Belongs here | Belongs in the knowledge base |
|---|---|
| The design permits a failure to be silent | How to fix one occurrence of it |
| A documented rule is enforced by nothing | A command that works around it |
| A stated invariant is false in practice | A node-specific quirk |
| The owner is unknown and finding it needs the whole mesh in view | Symptom → fix, once the answer is known |
The knowledge base already holds the operational record and is indexed on symptoms. This folder is not a second copy of it. An issue here is a question HQ must answer; an entry there is an incident someone must clear. An issue whose answer is a general lesson belongs in both.
Structure
NNN-short-name/
00-report.md the symptom as observed, with the evidence; status in frontmatter
01-diagnosis.md the investigation trail, dated, including what was ruled out
Frontmatter, on 00-report.md
---
status: open | diagnosing | located | resolved | wontfix
opened: YYYY-MM-DD
located-in: [] # owning repo(s) or module(s), filled by diagnosis
fixed-by: # pull request or commit reference, filled at resolution
amended-design: # design doc path, when the root cause was a design gap
---
Rules
- Anyone may open an issue. No localisation is required to report one.
- The full flow is playbook
00-META/process/03-issues.md. - Closed issues are never deleted — they are the mesh's symptom-to-component memory.
wontfixis legitimate and requires a sentence saying why.