26 lines
1.8 KiB
Markdown
26 lines
1.8 KiB
Markdown
# Diagnosis — 2026-09-21
|
|
|
|
1. Acceptance sealed the value and wrote the row without reading the module's manifest, which the
|
|
mesh holds. Both delivery paths did: a module's own secret, and a pair credential for a
|
|
requirement kept in the vault.
|
|
2. Refused now, in the inventory, so every caller gets it: an own secret must be one the manifest
|
|
declares; a pair credential must name a requirement the module has, and where the module keeps
|
|
several secrets for it (ADR 0094) a local it keeps — and no local where it keeps one. Each
|
|
refusal names what the module does declare.
|
|
3. The refusal found a stale delivery at once: the whole-mesh bed delivered `smtp-pass` to a module
|
|
that declares `smtp-password`. Corrected in the bed.
|
|
|
|
**Located in:** the inventory's two accept paths. Not a decision: the manifest was already the
|
|
authority on what a module holds. Proven by unit tests against the store: a delivery under an
|
|
undeclared name is refused naming the declared ones; under a declared name it is kept; to an
|
|
unknown module it is refused with the remedy; a pair delivery for a requirement the module has not
|
|
got, or with no local where several are kept, or under a local it does not keep, is refused.
|
|
|
|
*Later the same day.* The refusal caught the mesh itself: `module issue` made a broker account
|
|
for any module and delivered it as the own secret named `broker`, whether or not the module
|
|
declared one — a bed issuing the certificate authority, which speaks on no bus, left an account
|
|
on the broker that nothing would ever read. `module issue` now refuses a module with no `broker`
|
|
own secret before the account is made; a unit test holds it to that. A pair delivery for a
|
|
requirement the module keeps no secret for is refused too, on review. An own secret the mesh mints (the authority's password)
|
|
never needed an issue: it is minted when the node is resolved.
|