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 ten modules. Six of the "two" cases hold two names for one value or a value derived from another (an admin password and a token only ever set from it, a relay user that is a fixed string beside the relay password). Those are one secret each, and the module's own business to derive from. The "three or more" cases are genuinely independent: a root certificate, its key and that key's password are three values with three lifetimes.
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 requires/secrets vocabulary (the catalogue parser) and the pair credential's key (the controller's secret store). Not fixed here: the key change touches every existing pair and belongs in a feature of its own, with a lab run against the vault bed.