Issue 069: the count is the catalogue's, not the report's

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

@@ -4,12 +4,14 @@
    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
+2. The third question was answered by reading the catalogue as it is today: nine modules hold two
-   names for one value or a value derived from another (an admin password and a token only ever
+   or more own secrets besides their broker account. Two hold a relay user beside a relay
-   set from it, a relay user that is a fixed string beside the relay password). Those are one
+   password — the user is a name, not a secret, and could travel as configuration. The other
-   secret each, and the module's own business to derive from. The "three or more" cases are
+   seven hold genuinely independent values with independent lifetimes: an internal token beside
-   genuinely independent: a root certificate, its key and that key's password are three values
+   an admin password; a source, an admin and a relay password; an admin password beside an API
-   with three lifetimes.
+   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