From 14be8576f80a97b6aff9616e229799f8b67758a4 Mon Sep 17 00:00:00 2001 From: jochen Date: Tue, 29 Sep 2026 22:25:25 +0200 Subject: [PATCH 1/2] Grooming: five issues were fixed and never closed, and one is not MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit 088, 089, 120, 128 and 130 each name a commit that is on main and cites them — the forge's address following a moved port, a route naming its endpoint, a provisioner asking the backend what is there, the hosts file written into a marked block, and undeclaring giving a unit back the state it was found in. Each says it was closed by reading commits rather than by a run, so nobody reads a green that was never measured. 129 stays located on purpose: ca-trust is merged and no machine holds it, so the symptom it opened on is still true everywhere. --- .../00-report.md | 12 +++++++++--- .../00-report.md | 12 +++++++++--- .../00-report.md | 10 ++++++++-- .../00-report.md | 9 ++++++++- .../01-diagnosis.md | 13 +++++++++++++ .../130-undeclaring-a-service-stops-it/00-report.md | 9 ++++++++- 6 files changed, 55 insertions(+), 10 deletions(-) diff --git a/04-ISSUES/088-the-forges-own-address-names-a-port-it-may-not-have/00-report.md b/04-ISSUES/088-the-forges-own-address-names-a-port-it-may-not-have/00-report.md index 4aa2eea..890b6c8 100644 --- a/04-ISSUES/088-the-forges-own-address-names-a-port-it-may-not-have/00-report.md +++ b/04-ISSUES/088-the-forges-own-address-names-a-port-it-may-not-have/00-report.md @@ -1,8 +1,8 @@ --- -status: open +status: resolved opened: 2026-09-22 -located-in: [] -fixed-by: +located-in: [mesh-catalog modules/gitea, mesh-controller internal/catalogue/declaration.go] +fixed-by: mesh-controller 7352c84, merged in #46 — a module is told its port in a container's environment too, as a file already was amended-design: --- @@ -39,3 +39,9 @@ the assignment happens to differ. - Should composition refuse an environment value that names a port the module does not fix, the way it refuses other claims a module cannot make? - Which other modules write their own address, with a port, into their environment? + +## Closed + +*2026-09-29, in a grooming pass rather than by whoever fixed it.* The forge's address follows a moved port the same way every other reader does. Found by +reading what the code repositories' commits cite: the fix names this issue and is on `main`. It was +not re-verified on a machine, and this record says so rather than implying a run that did not happen. diff --git a/04-ISSUES/089-a-contributed-route-names-a-port-the-node-may-have-moved/00-report.md b/04-ISSUES/089-a-contributed-route-names-a-port-the-node-may-have-moved/00-report.md index 80df81c..038b028 100644 --- a/04-ISSUES/089-a-contributed-route-names-a-port-the-node-may-have-moved/00-report.md +++ b/04-ISSUES/089-a-contributed-route-names-a-port-the-node-may-have-moved/00-report.md @@ -1,8 +1,8 @@ --- -status: open +status: resolved opened: 2026-09-22 -located-in: [] -fixed-by: +located-in: [mesh-controller internal/catalogue/declaration.go, mesh-catalog (every routed module)] +fixed-by: mesh-controller bdf965d (a route names the endpoint it serves) with `portOfEndpoint` and `AtPublishedPort` — the contribution carries the endpoint's declared port and the machine-side redirection is applied to it like any other amended-design: --- @@ -45,3 +45,9 @@ precisely because the predecessor holds the usual one. keeping the mapping out of rendered configuration? - What should refuse a declaration whose contributed route names a port nothing on that node listens on? + +## Closed + +*2026-09-29, in a grooming pass rather than by whoever fixed it.* A route names an endpoint rather than a port, and the redirection that turns a declared port into the published one is applied to contributions too. Found by +reading what the code repositories' commits cite: the fix names this issue and is on `main`. It was +not re-verified on a machine, and this record says so rather than implying a run that did not happen. diff --git a/04-ISSUES/120-a-provisioner-remembers-what-it-did-not-what-is/00-report.md b/04-ISSUES/120-a-provisioner-remembers-what-it-did-not-what-is/00-report.md index 9b697f3..078d27c 100644 --- a/04-ISSUES/120-a-provisioner-remembers-what-it-did-not-what-is/00-report.md +++ b/04-ISSUES/120-a-provisioner-remembers-what-it-did-not-what-is/00-report.md @@ -1,8 +1,8 @@ --- -status: located +status: resolved opened: 2026-09-26 located-in: [mesh-sdk src/provisioner, mesh-catalog modules/redis] -fixed-by: +fixed-by: mesh-catalog bbda88c, merged in #84 — every credential provider says whether it still holds a consumer amended-design: --- @@ -60,3 +60,9 @@ checks it after the first pass. instance and leaves the gap for the others. - Where does the record of what was applied live, if not in memory? ADR 0114, still proposed, puts rotation state with the vault. The same place may answer this. + +## Closed + +*2026-09-29, in a grooming pass rather than by whoever fixed it.* A provisioner asks the backend what is there rather than trusting what it remembers doing. Found by +reading what the code repositories' commits cite: the fix names this issue and is on `main`. It was +not re-verified on a machine, and this record says so rather than implying a run that did not happen. diff --git a/04-ISSUES/128-the-hosts-file-is-written-whole/00-report.md b/04-ISSUES/128-the-hosts-file-is-written-whole/00-report.md index fa02a00..509ee3f 100644 --- a/04-ISSUES/128-the-hosts-file-is-written-whole/00-report.md +++ b/04-ISSUES/128-the-hosts-file-is-written-whole/00-report.md @@ -1,5 +1,6 @@ --- -status: located +status: resolved +fixed-by: mesh-host 1cb8953 and fdc768c — the mesh writes into a marked block of a text file instead of over it opened: 2026-09-26 located-in: [mesh-controller internal/catalogue/facts.go, mesh-host internal/apply] --- @@ -71,3 +72,9 @@ private network loses that name too. - The host's file resource supports `into: "json"` only; anything else is a whole write. - `node show ` on the adopted workstation: `holds file /etc/hosts mesh-wireguard.fact-node-names`, original kept. + +## Closed + +*2026-09-29, in a grooming pass rather than by whoever fixed it.* A shared hosts file keeps every line that is not the mesh's. Found by +reading what the code repositories' commits cite: the fix names this issue and is on `main`. It was +not re-verified on a machine, and this record says so rather than implying a run that did not happen. diff --git a/04-ISSUES/129-nothing-makes-a-machine-trust-the-meshs-authority/01-diagnosis.md b/04-ISSUES/129-nothing-makes-a-machine-trust-the-meshs-authority/01-diagnosis.md index 0071b16..e262608 100644 --- a/04-ISSUES/129-nothing-makes-a-machine-trust-the-meshs-authority/01-diagnosis.md +++ b/04-ISSUES/129-nothing-makes-a-machine-trust-the-meshs-authority/01-diagnosis.md @@ -30,3 +30,16 @@ network, installs it as a trust anchor, refreshes the machine's bundles, and — unassigned stops its unit, and stopping the unit is what undoes it — takes both away again. The owner is therefore `mesh-catalog`, module `ca-trust`, and nothing in the control plane. + +## The module exists, and this stays open until a machine holds it + +*2026-09-29.* `ca-trust` is in the catalogue and merged +([ADR 0147](../../02-DECISIONS/0147-a-module-anchors-the-meshs-authority.md)), and what it renders +is checked in the control plane's own suite: the script fetches from the authority it was bound to, +and the unit runs it both ways. + +**No machine has been assigned it, and nothing has verified a name because of it.** The bed written +for that cannot run ([issue 146](../146-the-foundation-cannot-be-raised-on-the-bus-the-mesh-runs-on/00-report.md)), +and the live mesh has not been given the module. So the symptom this record opened on — every +internal name failing verification on every machine — is still true everywhere, and the record stays +`located` until it is not. Closing it on a module that exists would be closing it on an intention. diff --git a/04-ISSUES/130-undeclaring-a-service-stops-it/00-report.md b/04-ISSUES/130-undeclaring-a-service-stops-it/00-report.md index 57fb3de..b9ea3ec 100644 --- a/04-ISSUES/130-undeclaring-a-service-stops-it/00-report.md +++ b/04-ISSUES/130-undeclaring-a-service-stops-it/00-report.md @@ -1,5 +1,6 @@ --- -status: located +status: resolved +fixed-by: mesh-host 3112c88 — undeclaring gives a unit back the state it was found in, and removes only a process the mesh made opened: 2026-09-27 located-in: [mesh-host internal/apply/apply.go (remove)] amended-design: 02-DECISIONS/0118-undeclaring-gives-a-unit-back-the-state-it-was-found-in.md @@ -64,3 +65,9 @@ something to settle in passing. The unassign preview is partly answered — the host's plan names each unit it will stop — and the controller's side is left open. + +## Closed + +*2026-09-29, in a grooming pass rather than by whoever fixed it.* Undeclaring no longer stops a unit the mesh only reloaded or only kept running. Found by +reading what the code repositories' commits cite: the fix names this issue and is on `main`. It was +not re-verified on a machine, and this record says so rather than implying a run that did not happen. From 9a1dc4665cdf2bf7f259b92ec9ed0422421b9f44 Mon Sep 17 00:00:00 2001 From: jochen Date: Tue, 29 Sep 2026 22:26:13 +0200 Subject: [PATCH 2/2] Grooming: issue 006's knowledge base is the predecessor's, and is gone MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit The record catches README claiming this repository is indexed into a knowledge base. Nothing indexed it, and since the cut-over there is nothing to index it into — the surface that answered is on the transport the mesh removed (issue 147). Noted where the record is, so the next reader does not go looking for a search that cannot exist. --- .../00-report.md | 14 ++++++++++++++ 1 file changed, 14 insertions(+) diff --git a/04-ISSUES/006-hq-is-not-indexed-into-the-knowledge-base/00-report.md b/04-ISSUES/006-hq-is-not-indexed-into-the-knowledge-base/00-report.md index 7c8280e..2c8c762 100644 --- a/04-ISSUES/006-hq-is-not-indexed-into-the-knowledge-base/00-report.md +++ b/04-ISSUES/006-hq-is-not-indexed-into-the-knowledge-base/00-report.md @@ -155,3 +155,17 @@ design document here, and get it back. That check fails today by design. **What stands until then** is the signpost, and the honest description of it: reachable, not surfacing. + +## Where this stands, 2026-09-29 + +*Added in a grooming pass.* The knowledge base this record is about is the **predecessor's**, and it +is no longer reachable from anything: the surface that answered `recall_search` speaks the transport +the mesh removed at the cut-over +([issue 147](../147-the-operators-tools-still-dial-the-bus-that-was-removed/00-report.md)). + +So the sentence in `README.md` that this record catches — *these documents are still indexed into +the knowledge base* — is now wrong twice over: nothing indexed them, and there is nothing to index +them into. The record stays open, and its answer is no longer "index this repository somewhere"; it +is whatever the mesh grows as its own knowledge surface, if it grows one. Until then the honest fix +is the README, which should stop claiming a property nothing provides. +