Issues 106 and 138 resolved (ADR 0161 built and live); 187 notes a report lost without retry

2026-10-01 17:18:17 +02:00
parent a7e9e6dea0
commit 86d1763cfa
3 changed files with 29 additions and 4 deletions
@@ -1,8 +1,8 @@
 ---
-status: located
+status: resolved
 opened: 2026-09-23
 located-in: [mesh-controller internal/catalogue/seats.go (the seed lacks mesh-vault), mesh-catalog modules/mesh-vault/module.json (claims nothing)]
-fixed-by: 
+fixed-by: mesh-controller PR 192 (the seat row), mesh-catalog PR 205 (the claim; the vault's events renamed to its own)
 amended-design: [03-DESIGN/01-to-be/26-the-seats.md]
 ---

@@ -39,3 +39,11 @@ own set, mesh-scoped, delivering `secret`, and the vault claims it; a second pro
 claimant, refused by name. The record also answers the second question: a provision the mesh's own
 code dereferences by name gets a seat, every other mesh-scoped provision may have several providers.
 Design 26's *reserved* for `secret` named an effect no rule produced; corrected there.
+
+## Resolved, 2026-10-01
+
+`seats` on the live mesh lists `mesh-vault` at mesh scope, delivering `secret`, held by the vault on
+the control node. A second provider of `secret` is now a second claimant and refused by name
+(`CanHold`'s test). Found on the way: the vault's definition could not be rebuilt at all — it emitted
+`secret.provisioned` and the like, which the builder reads as another module's events — so the events
+are now the vault's own, `provisioned`, `rotated`, `deprovisioned`.
@@ -1,8 +1,8 @@
 ---
-status: located
+status: resolved
 opened: 2026-09-28
 located-in: [mesh-host internal/profile/detectors.go (no detector for the network manager), mesh-host cmd/mesh-host (the profile is detected at enrolment only), mesh-controller internal/link (a report carries no profile), mesh-catalog modules/networkmanager, systemd-networkd, dhcpcd (declare no capability of their own)]
-fixed-by: 
+fixed-by: mesh-controller PR 192 (a report carries the profile), mesh-host PR 61 (uplink-<manager> detected and reported with every apply), mesh-catalog PR 206 (each holder declares its own)
 amended-design: [03-DESIGN/01-to-be/26-the-seats.md]
 ---

@@ -63,3 +63,16 @@ capability refusal does the rest, naming it. The profile is detected again by ev
 travels in the report, so a machine that switches managers is refused at its next push. The uplink
 stays one seat; the capability picks the dialect. Order of building: controller (a report may carry
 a profile), host, then the three definitions.
+
+## Resolved, 2026-10-01
+
+Every machine now reports which network manager it runs — the control node `uplink-systemd-networkd`,
+the laptop and the workstation `uplink-networkmanager`, the home server both `uplink-dhcpcd` and
+`uplink-networkmanager`, which is its truth — renewed with every report, and each holder declares the
+capability it needs, so the wrong holder is refused on assignment with the capability named. The uplink
+stays one seat; the capability picks the dialect. A machine that switches managers is a machine whose
+holder lacks a capability at its next push.
+
+*How it is checked:* the host's detector test per manager; the controller's test that a report's
+profile replaces the enrolled one; the capability refusal's existing tests; live, `node show <machine>`
+lists `uplink-<manager>` for each.
@@ -30,6 +30,10 @@ it began, and each invisible to every surface the mesh offers:
 In every case the designed fallback held — runtimes served the derived shape, a push later carried
 what an earlier one had not — which is why the mesh kept working and why nobody was told.

+One more the same evening: the laptop applied a declaration and logged *applied, and could not tell
+the mesh: reporting: context canceled*. The report was not retried; the mesh went on believing the
+machine's previous state until the next push, and nothing on either side counted the loss.
+
 ## Why this is here

 The repository's own rule is that a rule states how it is checked, and every record here does. But