ADR 0161: what deserves a seat — the vault's seat, the hub as a placement of capacity one, the uplink holder as the machine's dialect; design 26; issues 105, 106, 138

2026-10-01 15:55:15 +02:00
parent 6b8fb562ce
commit f35f3757bb
6 changed files with 162 additions and 15 deletions
@@ -1,9 +1,9 @@
 ---
-status: open
+status: resolved
 opened: 2026-09-23
-located-in: []
-fixed-by:
-amended-design:
+located-in: [mesh-controller cmd/mesh-controller/network.go (the placing command), internal/inventory/migrations/0004-the-overlay.sql (one hub)]
+fixed-by: nothing to build — ADR 0161 rule 2; the second hub was already refused by name, and the private network's seat waits for ADR 0121's server and client modules
+amended-design: [03-DESIGN/01-to-be/26-the-seats.md]
 ---

 # 105 — The hub of the private network is a placement, not a seat
@@ -32,3 +32,16 @@ a node-scoped seat held by every node, which is true and not what was asked.
 - Does the per-node seat still say anything once the hub is a seat, or is it the interface's
  presence restated?
 - What else in the mesh is "exactly one" and recorded as a placement rather than a seat?
+
+## Resolved, 2026-10-01
+
+Read against the code: the store has kept one hub since the overlay's first migration (a unique
+index), and `overlay place <node> --hub` refuses a second naming the first. What this report saw as
+silent is not. [ADR 0161](../../02-DECISIONS/0161-what-deserves-a-seat.md), rule 2, answers the
+question that remained: a singular fact about machines is a placement with a capacity of one,
+refused by name and named in the listing — never a seat, because a seat is held by a module
+assignment and the private network is the host's own until
+[ADR 0121](../../02-DECISIONS/0121-a-system-seat-is-named-for-its-scope-and-modules-define-their-own.md)'s
+server and client modules exist. That seat stands, deferred with the split it needs.
+
+*How it is checked:* the overlay command's test for a second hub, and the index.
@@ -1,9 +1,9 @@
 ---
-status: open
+status: located
 opened: 2026-09-23
-located-in: []
-fixed-by:
-amended-design:
+located-in: [mesh-controller internal/catalogue/seats.go (the seed lacks mesh-vault), mesh-catalog modules/mesh-vault/module.json (claims nothing)]
+fixed-by: 
+amended-design: [03-DESIGN/01-to-be/26-the-seats.md]
 ---

 # 106 — The vault claims no seat, so nothing refuses a second one
@@ -31,3 +31,11 @@ others were missed the same way — every provider added after 0079.
 - A mesh-scoped seat `mesh-vault`, by the 0079 convention — is there any reason not to?
 - Should a provider of a mesh-scoped provision be required to claim a seat, or say explicitly that
  more than one is allowed, so the omission cannot recur?
+
+## Decided, 2026-10-01
+
+[ADR 0161](../../02-DECISIONS/0161-what-deserves-a-seat.md), rule 1: `mesh-vault` joins the mesh's
+own set, mesh-scoped, delivering `secret`, and the vault claims it; a second provider is a second
+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.
@@ -1,9 +1,9 @@
 ---
-status: open
+status: located
 opened: 2026-09-28
-located-in: [mesh-controller internal/catalogue, mesh-catalog]
-fixed-by:
-amended-design:
+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: 
+amended-design: [03-DESIGN/01-to-be/26-the-seats.md]
 ---

 # 138 — Two modules claim one seat and are not interchangeable, and nothing says so
@@ -54,3 +54,12 @@ able to switch the manager, which ADR 0117 refuses for a reason that has not cha
  alternative is one module that speaks whichever dialect the machine needs, chosen from the report.
 - What should happen on a machine that switches manager afterwards? The seat would then be held by the
  wrong module, and the machine is the only place that knows.
+
+## Decided, 2026-10-01
+
+[ADR 0161](../../02-DECISIONS/0161-what-deserves-a-seat.md), rule 3: the host's profile gains one
+capability per network manager found active, each holder declares its own, and the existing
+capability refusal does the rest, naming it. The profile is detected again by every apply and
+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.