1.8 KiB
Diagnosis — 2026-09-21
- 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.
- 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.
- The refusal found a stale delivery at once: the whole-mesh bed delivered
smtp-passto a module that declaressmtp-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.