2026-09-29 21:37:04 +00:00
7 changed files with 69 additions and 10 deletions
@@ -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.
@@ -1,8 +1,8 @@
 ---
-status: open
+status: resolved
 opened: 2026-09-22
-located-in: []
+located-in: [mesh-catalog modules/gitea, mesh-controller internal/catalogue/declaration.go]
-fixed-by:
+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.
@@ -1,8 +1,8 @@
 ---
-status: open
+status: resolved
 opened: 2026-09-22
-located-in: []
+located-in: [mesh-controller internal/catalogue/declaration.go, mesh-catalog (every routed module)]
-fixed-by:
+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.
@@ -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.
@@ -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 <node>` 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.
@@ -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.
@@ -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.