hq/04-ISSUES/069-one-secret-provision-yields-one-value/01-diagnosis.md

Diagnosis — 2026-09-21

1. The constraint is real and where the report put it: a module requires a provision name once, a pair credential is keyed on (name, consumer node, consumer module, provider), and the login the vault derives is keyed on the (node, module) pair. Two secrets for one module and one vault collide on every key.
2. The third question was answered by reading the catalogue as it is today: nine modules hold two or more own secrets besides their broker account. Two hold a relay user beside a relay password — the user is a name, not a secret, and could travel as configuration. The other seven hold genuinely independent values with independent lifetimes: an internal token beside an admin password; a source, an admin and a relay password; an admin password beside an API token; a root certificate, its key, that key's password and an intermediate's. None of those derives from another. So "one value per module, derivation the module's business" is not an answer for most of them.
3. So the answer is neither option as the report framed them. A module keeps one secret provision per independent value, and needs a way to require the same provision name more than once under distinct local names — the way secrets: already maps a provision to a path. That is a manifest-vocabulary decision, and it moves the pair key: the credential must be keyed on the local name, not the provision name, or the second pair overwrites the first.

Located in: the manifest's secrets vocabulary (the catalogue parser) and the pair credential's key (the controller's secret store). Fixed as ADR 0094: the key gains the local name, empty for every existing pair, so nothing that exists changed.