18 lines
1.2 KiB
Markdown
18 lines
1.2 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.
|