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

04-ISSUES/106-the-vault-claims-no-seat/00-report.md

@@ -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.