50 lines
2.6 KiB
Markdown
50 lines
2.6 KiB
Markdown
---
|
|
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: 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]
|
|
---
|
|
|
|
# 106 — The vault claims no seat, so nothing refuses a second one
|
|
|
|
## What was observed
|
|
|
|
Reading the registry, 2026-09-23. The vault provides `secret` to the whole mesh and **claims no
|
|
seat**. The store, the broker, the controller and the catalogue each claim one, named after
|
|
themselves, so that a second claimant is refused at resolution
|
|
([ADR 0079](../../02-DECISIONS/0079-the-foundation-seats-are-named-after-their-servers.md)). The vault
|
|
was added after that record and did not inherit the rule.
|
|
|
|
## Why it matters beyond this instance
|
|
|
|
The vault holds every credential the mesh mints. A second vault, assigned by mistake or by a module
|
|
that provides `secret` itself, would answer requirements the first was answering, and nothing in
|
|
resolution would object. Of all the components to allow two of silently, this is the one to allow
|
|
least.
|
|
|
|
The rule is already written; this is an instance it was not applied to. Worth asking whether
|
|
others were missed the same way — every provider added after 0079.
|
|
|
|
## Open questions
|
|
|
|
- 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.
|
|
|
|
## 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`.
|