Issues 046, 049 and 069 located, each with the decision its fix needs named

2026-09-21 17:50:42 +02:00
parent 16442ecd23
commit 62ff9a5bd3
6 changed files with 62 additions and 6 deletions
@@ -0,0 +1,21 @@
+# 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.