@aifabrix/builder 2.60.0 → 2.62.0

package/lib/schema/infra.parameter.yaml

@@ -105,6 +105,9 @@ parameters:
       value: 'redis://${REDIS_HOST}:${REDIS_PORT}'
     ensureOn: [upInfra, resolveApp]
     azure:
+      vaultSecretName: redis-url
+      legacyVaultSecretNames:
+        - redis-urlKeyVault
       notes: >-
         Local up-infra resolves the REDIS_HOST/REDIS_PORT placeholders. Azure application deploy
         must leave this key absent so the Azure SDK derives the rediss URL and credential.
@@ -590,53 +593,92 @@ parameters:
     azure:
       notes: Not a typical Key Vault name; local optional pypi token.
 
-  # Default client id for controller app in local multi-service layout; override after register if needed.
+  # Miso Controller ↔ controller OAuth. The Controller issues both values at registration;
+  # local infrastructure must leave them empty until application resolution retrieves them.
   - key: miso-controller-client-idKeyVault
     ownerAppKey: miso-controller
     scope: app
+    sensitive: false
     generator:
-      type: literal
-      value: 'miso-controller-miso-miso-controller'
-    ensureOn: [upInfra, resolveApp]
+      type: emptyString
+    ensureOn: [resolveApp]
     azure:
       legacyVaultSecretNames:
         - '{serviceName}-miso-clientIdKeyVault'
       notes: >-
-        Per-app OAuth client id from controller registration; literal default matches local Keycloak client naming.
+        Per-app OAuth client id issued when miso-controller is registered with Miso.
 
   - key: miso-controller-client-secretKeyVault
     ownerAppKey: miso-controller
     scope: app
     generator:
-      type: randomBytes32
-    ensureOn: [upInfra, resolveApp]
+      type: emptyString
+    ensureOn: [resolveApp]
     azure:
       notes: >-
-        Per-app OAuth client secret used by miso-controller for service-to-service auth (MISO_CLIENTSECRET).
-        Generated on first ensure for local bootstrap.
+        Per-app OAuth client secret issued when miso-controller is registered with Miso and used
+        for service-to-service auth (MISO_CLIENTSECRET). Never generated by local infrastructure.
+
+  # Builder API ↔ controller OAuth. These are explicit declarations rather than catch-all
+  # matches so the backup catalog records the owner and canonical names unambiguously.
+  - key: builder-api-client-idKeyVault
+    ownerAppKey: builder-api
+    scope: app
+    sensitive: false
+    generator:
+      type: emptyString
+    ensureOn: [resolveApp]
+    azure:
+      vaultSecretName: builder-api-client-idKeyVault
+      notes: Per-app OAuth client id issued when builder-api is registered with Miso.
+
+  - key: builder-api-client-secretKeyVault
+    ownerAppKey: builder-api
+    scope: app
+    sensitive: true
+    generator:
+      type: emptyString
+    ensureOn: [resolveApp]
+    azure:
+      vaultSecretName: builder-api-client-secretKeyVault
+      notes: Per-app OAuth client secret issued when builder-api is registered with Miso.
 
   # Dataplane ↔ controller OAuth (builder/dataplane env.template MISO_CLIENTID / MISO_CLIENTSECRET).
+  # Plan 265.0: issued by the Controller at registration, so the catalog must not produce a
+  # value for it. The previous `literal` on the `upInfra` hook meant Builder generated an id
+  # the Controller owns — and the literal was `miso-controller-dev-dataplane`, with `dev`
+  # baked into an entry that is not dev-specific. `emptyString` on `resolveApp` is the shape
+  # `builder-api-client-idKeyVault` already uses for the same relationship.
   - key: dataplane-client-idKeyVault
     ownerAppKey: dataplane
     scope: app
+    sensitive: false
     generator:
-      type: literal
-      value: 'miso-controller-dev-dataplane'
-    ensureOn: [upInfra, resolveApp]
+      type: emptyString
+    ensureOn: [resolveApp]
     azure:
       notes: >-
-        Per-app OAuth client id from controller registration; literal default matches local Keycloak client naming
-        (override for environments such as miso-controller-dev-dataplane).
-
+        Per-app OAuth client id issued when dataplane is registered with Miso. Not generated
+        locally: the Controller owns it, and a locally invented id is one the Controller has
+        never seen.
+
+  # Plan 265.0: the Controller issues this secret, so a `randomBytes32` generator on the
+  # `upInfra` hook had Builder inventing an OAuth secret the Controller owns. That invented
+  # value is what defeated the "credentials missing locally" guard and surfaced as a
+  # misleading auth error rather than a clear one. Matches
+  # `builder-api-client-secretKeyVault`.
   - key: dataplane-client-secretKeyVault
     ownerAppKey: dataplane
     scope: app
     generator:
-      type: randomBytes32
-    ensureOn: [upInfra, resolveApp]
+      type: emptyString
+    ensureOn: [resolveApp]
     azure:
       vaultSecretName: dataplane-client-secretKeyVault
-      notes: Per-app OAuth client secret for dataplane; generated on first ensure.
+      notes: >-
+        Per-app OAuth client secret issued when dataplane is registered with Miso. Never
+        generated locally; it is fetched from the Controller, which is the only party that
+        can issue one it will accept.
 
   # Mori / telemetry is optional for an unlicensed Community installation.
   - key: mori-controller-api-keyKeyVault
@@ -652,18 +694,46 @@ parameters:
       notes: Empty locally; set when calling Mori with API key auth.
 
   # Public, but a security-critical trust anchor. Never derive it from a pasted JWT.
+  #
+  # `sensitive: true` on a public key is deliberate -- 227.1 made Miso verify licences against a
+  # PINNED key precisely because a key travelling inside the token it verifies proves nothing, so
+  # this value must be protected from tampering even though disclosing it costs nothing.
+  #
+  # It is owned by `miso-controller` rather than left system-scoped because a system-scoped
+  # sensitive secret is readable by NO application (`forbidden-system-secret`). Measured on
+  # aifabrix-ce-16 2026-09-27: miso-controller declares MORI_LICENSE_PUBLIC_KEY in its manifest, yet
+  # the key was absent from its 70 registry rows and from its snapshot, so the installation could
+  # never have verified a licence. Ownership is what makes a trust anchor readable by the service
+  # whose trust it anchors -- the same correction already applied to secrets-policyPrivateKeyVault.
   - key: mori-license-public-keyKeyVault
     category: Mori
+    ownerAppKey: miso-controller
     sensitive: true
     valueSource: optionalInput
     requiredOnSystemOnboarding: false
-    scope: system
+    scope: app
+    # The public half of the Mori licence pair above, so the key Miso verifies with cannot drift
+    # from the key Mori signs with. Was `emptyString`: the two halves came from unrelated places
+    # and an installation could hold a perfectly valid public key belonging to a different private
+    # key, which verifies nothing and reports no error.
+    #
+    # Rotating an installation that already holds a value here means clearing BOTH halves
+    # together — the generator is get-or-create, so replacing one alone leaves a mismatched pair.
+    # Supplied, never generated. Mori owns this pair and keeps the private half; an installation
+    # that minted it would hold the private half of the key it verifies against and could sign a
+    # licence it would then accept. Builder refuses these pairs (aifabrix-builder 211.0 /
+    # 5bfeb06d); `rsaKeyPair` here made Miso mint them anyway, because catalog-resolver runs the
+    # generator unconditionally and never consults valueSource. `emptyAllowed` is what stops it:
+    # the materializer skips isEmptyByDesign rows, so Miso no longer writes this secret at all.
+    # It arrives instead as a deploy parameter -- packages.json -> main.bicep ->
+    # 08_keyvault-secrets.bicep -> the installation vault -- which is also the only writer that
+    # can hold Mori's real key rather than a locally invented one.
     generator:
-      type: emptyString
+      type: emptyAllowed
     ensureOn: [upInfra, resolveApp]
     azure:
       vaultSecretName: mori-license-public-keyKeyVault
-      notes: Trusted Mori SPKI PEM public key, provisioned by the installer or issuer release identity.
+      notes: SPKI PEM public half of the Mori licence signing pair; linked to secrets-licensePrivateKeyVault.
 
   - key: appinsights-connectionStringKeyVault
     category: Observability
@@ -705,7 +775,7 @@ parameters:
       vaultSecretName: loganalytics-workspace-id
       notes: Azure SDK-derived Log Analytics workspace customer identifier.
 
-  - key: azureopenai-endpoint
+  - key: azure-openai/endpoint
     category: Azure OpenAI
     sensitive: false
     valueSource: optionalInput
@@ -715,10 +785,10 @@ parameters:
       type: emptyString
     ensureOn: [resolveApp]
     azure:
-      vaultSecretName: azureopenai-endpoint
-      notes: Azure OpenAI endpoint produced by the environment infrastructure deployment.
+      vaultSecretName: dev-dataplane-azure-openai-endpoint
+      notes: Azure OpenAI endpoint produced by infrastructure at the standard dev Dataplane address.
 
-  - key: azureopenai-apikey
+  - key: azure-openai/apiKey
     category: Azure OpenAI
     sensitive: true
     valueSource: optionalInput
@@ -728,21 +798,8 @@ parameters:
       type: emptyString
     ensureOn: [resolveApp]
     azure:
-      vaultSecretName: azureopenai-apikey
-      notes: Azure OpenAI API key produced by the environment infrastructure deployment.
-
-  # Dataplane builder/dataplane env.template (AI/LLM); optional until OpenAI or Azure OpenAI is configured.
-  - key: secrets-openaiApiKeyVault
-    category: OpenAI
-    sensitive: true
-    valueSource: optionalInput
-    requiredOnSystemOnboarding: false
-    scope: system
-    generator:
-      type: emptyString
-    ensureOn: [resolveApp]
-    azure:
-      notes: Optional shared OpenAI API key; empty until supplied and never auto-generated.
+      vaultSecretName: dev-dataplane-azure-openai-api-key
+      notes: Azure OpenAI API key produced by infrastructure at the standard dev Dataplane address.
 
   - key: azure-openaiapi-urlKeyVault
     scope: app
@@ -752,17 +809,13 @@ parameters:
     azure:
       notes: Empty until set; Azure OpenAI endpoint URL.
 
-  - key: secrets-azureOpenaiApiKeyVault
-    scope: app
-    generator:
-      type: emptyString
-    ensureOn: [upInfra, resolveApp]
-    azure:
-      notes: Empty until set; user-supplied Azure OpenAI API key (not auto-generated).
-
   # Dataplane RS256 signing identity. The two rows are generated as one linked pair.
   - key: secrets-certificatePrivateKeyVault
     ownerAppKey: dataplane
+    # Deliberately NOT shared with mori-controller. `readability-real-catalog.test.ts` asserts
+    # "denies mori signing licences with the dataplane signing key" — Mori's manifest pointing
+    # MORI_LICENSE_PRIVATE_KEY at this key is the misconfiguration, not the denial. The fix is a
+    # mori-controller-owned licence key and a manifest change, never widening this entry.
     scope: app
     generator:
       type: rsaKeyPair
@@ -773,6 +826,80 @@ parameters:
       vaultSecretName: secrets-certificatePrivateKeyVault
       notes: PKCS#8 PEM private key generated with the matching public key.
 
+  # Mori's policy signing key. Present in every installation's vault but absent from this catalog,
+  # so it fell through to the `^[a-zA-Z0-9_-]+KeyVault$` catch-all — `scope: app` with no owner,
+  # which `resolveOwnershipDecision` cannot classify and the policy therefore denies to everyone.
+  #
+  # Measured on aifabrix-ce-16, 2026-09-26: the secret exists, Mori reads it today through an App
+  # Service Key Vault reference, and bootstrap omitted it. That is the same key whose absence
+  # previously failed Mori's signing health check.
+  - key: secrets-policyPrivateKeyVault
+    ownerAppKey: mori-controller
+    scope: app
+    sensitive: true
+    # Supplied, never generated. Mori owns this pair and keeps the private half; an installation
+    # that minted it would hold the private half of the key it verifies against and could sign a
+    # licence it would then accept. Builder refuses these pairs (aifabrix-builder 211.0 /
+    # 5bfeb06d); `rsaKeyPair` here made Miso mint them anyway, because catalog-resolver runs the
+    # generator unconditionally and never consults valueSource. `emptyAllowed` is what stops it:
+    # the materializer skips isEmptyByDesign rows, so Miso no longer writes this secret at all.
+    # It arrives instead as a deploy parameter -- packages.json -> main.bicep ->
+    # 08_keyvault-secrets.bicep -> the installation vault -- which is also the only writer that
+    # can hold Mori's real key rather than a locally invented one.
+    generator:
+      type: emptyAllowed
+    ensureOn: [resolveApp]
+    azure:
+      vaultSecretName: secrets-policyPrivateKeyVault
+      notes: PKCS#8 PEM private key for Mori policy signing; MORI_POLICY_KEY_ID names the pair.
+
+  # Mori's LICENCE signing key, which is not its policy signing key and not the dataplane's.
+  #
+  # `subscription-license.operations.ts` refuses to issue at all without it:
+  #   if (!privateKey) throw ErrorFactory.internalServerError('License signing is unavailable')
+  # and until this entry existed there was nothing for it to read. Mori's manifest pointed
+  # MORI_LICENSE_PRIVATE_KEY at `secrets-certificatePrivateKeyVault`, which the dataplane owns, so
+  # the read was denied -- correctly. An existing test (`denies mori signing licences with the
+  # dataplane signing key`) pins that denial, so the fix is a key Mori owns, never a wider grant.
+  #
+  # `emptyString` rather than `rsaKeyPair`: the operator supplies the pair, because whoever holds
+  # this key decides which licences an installation will believe. Generating it during onboarding
+  # would make the platform mint its own trust root as a side effect of deployment. Onboarding
+  # creates the placeholder, `aifabrix env secret push` writes the real value, and create-if-absent
+  # then leaves it alone. The verifying half is `mori-license-public-keyKeyVault`, pinned to
+  # miso-controller; a pair is only useful if both halves are readable by their own service.
+  - key: secrets-licensePrivateKeyVault
+    category: Mori
+    ownerAppKey: mori-controller
+    scope: app
+    sensitive: true
+    valueSource: optionalInput
+    requiredOnSystemOnboarding: false
+    # Generated as one linked pair with mori-license-public-keyKeyVault, the same way the
+    # dataplane's signing identity is. Was `emptyString`, which meant an installation that
+    # repointed Mori at this key got nothing and `subscription-license.operations.ts` refused
+    # with "License signing is unavailable" -- so the only working configuration was the wrong
+    # one: Mori signing with the DATAPLANE's key via secrets-certificatePrivateKeyVault.
+    #
+    # Mori and the dataplane must not share a signing identity. Sharing one means the dataplane
+    # holds a key that mints licences, and the two services have completely different blast
+    # radii. Mori is the licence server; the dataplane runs customer workloads.
+    # Supplied, never generated. Mori owns this pair and keeps the private half; an installation
+    # that minted it would hold the private half of the key it verifies against and could sign a
+    # licence it would then accept. Builder refuses these pairs (aifabrix-builder 211.0 /
+    # 5bfeb06d); `rsaKeyPair` here made Miso mint them anyway, because catalog-resolver runs the
+    # generator unconditionally and never consults valueSource. `emptyAllowed` is what stops it:
+    # the materializer skips isEmptyByDesign rows, so Miso no longer writes this secret at all.
+    # It arrives instead as a deploy parameter -- packages.json -> main.bicep ->
+    # 08_keyvault-secrets.bicep -> the installation vault -- which is also the only writer that
+    # can hold Mori's real key rather than a locally invented one.
+    generator:
+      type: emptyAllowed
+    ensureOn: [resolveApp]
+    azure:
+      vaultSecretName: secrets-licensePrivateKeyVault
+      notes: PKCS#8 PEM private key for Mori licence signing; MORI_LICENSE_KEY_ID names the pair.
+
   - key: secrets-certificatePublicKeyVault
     ownerAppKey: dataplane
     scope: app
@@ -825,8 +952,12 @@ parameters:
       type: databaseUrl
     ensureOn: [upInfra, resolveApp]
     azure:
-      vaultSecretNamePattern: '{appKey}-databases-{index}-urlKeyVault'
+      vaultSecretNamePattern: '{environment}-{appKey}-databases-{index}-urlKeyVault'
       legacyVaultSecretNames:
+        # Pre-environment naming: app and index only, so two environments sharing one vault
+        # collided. Kept so installations written under it keep resolving without a vault write.
+        - '{appKey}-databases-{index}-urlKeyVault'
+        # The original logical key, which is what aifabrix-ce-16 actually holds.
         - '{key}'
         - '{serviceName}-databases-0-urlKeyVault'
 
@@ -837,8 +968,12 @@ parameters:
       type: databasePassword
     ensureOn: [upInfra, resolveApp]
     azure:
-      vaultSecretNamePattern: '{appKey}-databases-{index}-passwordKeyVault'
+      vaultSecretNamePattern: '{environment}-{appKey}-databases-{index}-passwordKeyVault'
       legacyVaultSecretNames:
+        # Pre-environment naming: app and index only, so two environments sharing one vault
+        # collided. Kept so installations written under it keep resolving without a vault write.
+        - '{appKey}-databases-{index}-passwordKeyVault'
+        # The original logical key, which is what aifabrix-ce-16 actually holds.
         - '{key}'
 
   - key: databases-miso-controller-1-urlKeyVault
@@ -848,8 +983,12 @@ parameters:
       type: databaseUrl
     ensureOn: [upInfra, resolveApp]
     azure:
-      vaultSecretNamePattern: '{appKey}-databases-{index}-urlKeyVault'
+      vaultSecretNamePattern: '{environment}-{appKey}-databases-{index}-urlKeyVault'
       legacyVaultSecretNames:
+        # Pre-environment naming: app and index only, so two environments sharing one vault
+        # collided. Kept so installations written under it keep resolving without a vault write.
+        - '{appKey}-databases-{index}-urlKeyVault'
+        # The original logical key, which is what aifabrix-ce-16 actually holds.
         - '{key}'
         - '{serviceName}-databases-1-urlKeyVault'
 
@@ -860,9 +999,120 @@ parameters:
       type: databasePassword
     ensureOn: [upInfra, resolveApp]
     azure:
-      vaultSecretNamePattern: '{appKey}-databases-{index}-passwordKeyVault'
+      vaultSecretNamePattern: '{environment}-{appKey}-databases-{index}-passwordKeyVault'
+      legacyVaultSecretNames:
+        # Pre-environment naming: app and index only, so two environments sharing one vault
+        # collided. Kept so installations written under it keep resolving without a vault write.
+        - '{appKey}-databases-{index}-passwordKeyVault'
+        # The original logical key, which is what aifabrix-ce-16 actually holds.
+        - '{key}'
+
+  # Installed Dataplane stacks used semantic database names before the environment-scoped
+  # convention. Keep the exact inventory here so onboarding can copy each value to its canonical
+  # name without guessing which database slot it belongs to.
+  - key: databases-dataplane-0-urlKeyVault
+    ownerAppKey: dataplane
+    scope: app
+    generator:
+      type: databaseUrl
+    ensureOn: [upInfra, resolveApp]
+    azure:
+      vaultSecretNamePattern: '{environment}-{appKey}-databases-{index}-urlKeyVault'
+      legacyVaultSecretNames:
+        - '{appKey}-databases-{index}-urlKeyVault'
+        - '{key}'
+        - dataplane-connection-string
+
+  - key: databases-dataplane-0-passwordKeyVault
+    ownerAppKey: dataplane
+    scope: app
+    generator:
+      type: databasePassword
+    ensureOn: [upInfra, resolveApp]
+    azure:
+      vaultSecretNamePattern: '{environment}-{appKey}-databases-{index}-passwordKeyVault'
+      legacyVaultSecretNames:
+        - '{appKey}-databases-{index}-passwordKeyVault'
+        - '{key}'
+        - dataplane-password
+
+  - key: databases-dataplane-1-urlKeyVault
+    ownerAppKey: dataplane
+    scope: app
+    generator:
+      type: databaseUrl
+    ensureOn: [upInfra, resolveApp]
+    azure:
+      vaultSecretNamePattern: '{environment}-{appKey}-databases-{index}-urlKeyVault'
+      legacyVaultSecretNames:
+        - '{appKey}-databases-{index}-urlKeyVault'
+        - '{key}'
+        - dataplane-vector-connection-string
+
+  - key: databases-dataplane-1-passwordKeyVault
+    ownerAppKey: dataplane
+    scope: app
+    generator:
+      type: databasePassword
+    ensureOn: [upInfra, resolveApp]
+    azure:
+      vaultSecretNamePattern: '{environment}-{appKey}-databases-{index}-passwordKeyVault'
+      legacyVaultSecretNames:
+        - '{appKey}-databases-{index}-passwordKeyVault'
+        - '{key}'
+        - dataplane-vector-password
+
+  - key: databases-dataplane-2-urlKeyVault
+    ownerAppKey: dataplane
+    scope: app
+    generator:
+      type: databaseUrl
+    ensureOn: [upInfra, resolveApp]
+    azure:
+      vaultSecretNamePattern: '{environment}-{appKey}-databases-{index}-urlKeyVault'
+      legacyVaultSecretNames:
+        - '{appKey}-databases-{index}-urlKeyVault'
+        - '{key}'
+        - dataplane-logs-connection-string
+
+  - key: databases-dataplane-2-passwordKeyVault
+    ownerAppKey: dataplane
+    scope: app
+    generator:
+      type: databasePassword
+    ensureOn: [upInfra, resolveApp]
+    azure:
+      vaultSecretNamePattern: '{environment}-{appKey}-databases-{index}-passwordKeyVault'
+      legacyVaultSecretNames:
+        - '{appKey}-databases-{index}-passwordKeyVault'
+        - '{key}'
+        - dataplane-logs-password
+
+  - key: databases-dataplane-3-urlKeyVault
+    ownerAppKey: dataplane
+    scope: app
+    generator:
+      type: databaseUrl
+    ensureOn: [upInfra, resolveApp]
+    azure:
+      vaultSecretNamePattern: '{environment}-{appKey}-databases-{index}-urlKeyVault'
       legacyVaultSecretNames:
+        - '{appKey}-databases-{index}-urlKeyVault'
         - '{key}'
+        - dataplane-records-connection-string
+
+  - key: databases-dataplane-3-passwordKeyVault
+    ownerAppKey: dataplane
+    scope: app
+    generator:
+      type: databasePassword
+    ensureOn: [upInfra, resolveApp]
+    azure:
+      vaultSecretNamePattern: '{environment}-{appKey}-databases-{index}-passwordKeyVault'
+      legacyVaultSecretNames:
+        - '{appKey}-databases-{index}-passwordKeyVault'
+        - '{key}'
+        - dataplane-records-password
 
   # Per-index database secrets. Index must match requires.databases order in application.yaml.
   - keyPattern: '^databases-[a-z0-9-]+-\d+-urlKeyVault$'
@@ -871,8 +1121,12 @@ parameters:
       type: databaseUrl
     ensureOn: [upInfra, resolveApp]
     azure:
-      vaultSecretNamePattern: '{appKey}-databases-{index}-urlKeyVault'
+      vaultSecretNamePattern: '{environment}-{appKey}-databases-{index}-urlKeyVault'
       legacyVaultSecretNames:
+        # Pre-environment naming: app and index only, so two environments sharing one vault
+        # collided. Kept so installations written under it keep resolving without a vault write.
+        - '{appKey}-databases-{index}-urlKeyVault'
+        # The original logical key, which is what aifabrix-ce-16 actually holds.
         - '{key}'
       notes: The manifest key stays logical; the app-prefixed name is the physical vault key.
 
@@ -882,12 +1136,26 @@ parameters:
       type: databasePassword
     ensureOn: [upInfra, resolveApp]
     azure:
-      vaultSecretNamePattern: '{appKey}-databases-{index}-passwordKeyVault'
+      vaultSecretNamePattern: '{environment}-{appKey}-databases-{index}-passwordKeyVault'
       legacyVaultSecretNames:
+        # Pre-environment naming: app and index only, so two environments sharing one vault
+        # collided. Kept so installations written under it keep resolving without a vault write.
+        - '{appKey}-databases-{index}-passwordKeyVault'
+        # The original logical key, which is what aifabrix-ce-16 actually holds.
         - '{key}'
 
+  # Addresses, not credentials.
+  #
+  # These defaulted to sensitive (`sensitive` is absent, and the service reads `entry.sensitive !== false`),
+  # so the system-secrets list API withheld the VALUE of a URL, a hostname and a virtual directory. Six
+  # literal entries — frontdoor-url, frontdoor-host, keycloak-web-server-url,
+  # keycloak-internal-server-url, keycloak-vdir-public, miso-controller-web-server-url and friends —
+  # exist only to override that one key at a time, which is the hardcoding this convention removes.
+  # An address is operator-facing by nature: hiding it makes an installation harder to diagnose and
+  # protects nothing.
   # Keycloak and other *-url keys (non-database).
   - keyPattern: '^keycloak-.+-url$'
+    sensitive: false
     scope: shared-service
     generator:
       type: emptyString
@@ -895,6 +1163,7 @@ parameters:
 
   # App-scoped URL placeholders (filled at resolve / deploy).
   - keyPattern: '^[a-z0-9-]+-url$'
+    sensitive: false
     scope: app
     generator:
       type: emptyString
@@ -902,6 +1171,7 @@ parameters:
 
   # Deploy manifest maps frontDoorRouting.host templates to this secret (Azure / pipeline).
   - keyPattern: '^[a-z0-9-]+-frontdoor-routing-host$'
+    sensitive: false
     scope: app
     generator:
       type: emptyString
@@ -910,32 +1180,146 @@ parameters:
       notes: Hostname template for Traefik / Front Door; filled at deploy.
 
   - keyPattern: '^[a-z0-9-]+-vdir-public$'
+    sensitive: false
     scope: app
     generator:
       type: emptyString
     ensureOn: [resolveApp]
 
   - keyPattern: '^[a-z0-9-]+-vdir-internal$'
+    sensitive: false
     scope: app
     generator:
       type: emptyString
     ensureOn: [resolveApp]
 
   - keyPattern: '^[a-z0-9-]+-host-public$'
+    sensitive: false
     scope: app
     generator:
       type: emptyString
     ensureOn: [resolveApp]
 
   - keyPattern: '^[a-z0-9-]+-host-internal$'
+    sensitive: false
     scope: app
     generator:
       type: emptyString
     ensureOn: [resolveApp]
 
-  # Remaining *KeyVault secrets — generated tokens/passwords (not database rows above).
-  - keyPattern: '^[a-zA-Z0-9_-]+KeyVault$'
+  # Secrets that are genuinely generated here, declared explicitly because the catch-all below no
+  # longer invents values. Each is a shared secret with no other issuer: nothing outside this
+  # catalog mints them, so an empty value would leave the consumer with nothing to verify against.
+  - key: notification-event-webhook-secretKeyVault
+    scope: app
+    generator:
+      type: randomBytes32
+    ensureOn: [resolveApp]
+    azure:
+      vaultSecretName: notification-event-webhook-secretKeyVault
+      notes: Shared secret signing notification webhook callbacks; generated, never supplied.
+
+  - key: secrets-encryptionKeyVault
+    scope: app
+    generator:
+      type: randomBytes32
+    ensureOn: [resolveApp]
+    azure:
+      vaultSecretName: secrets-encryptionKeyVault
+      notes: Application-scoped encryption key; generated, never supplied.
+
+  - key: miso-controller-api-key-secretKeyVault
     scope: app
     generator:
       type: randomBytes32
     ensureOn: [resolveApp]
+    azure:
+      vaultSecretName: miso-controller-api-key-secretKeyVault
+      notes: Generated API key for test/integration apps; generated, never supplied.
+
+  # `-idKeyVault` and `-nameKeyVault` are NOT secrets.
+  #
+  # An identifier and a name are operator-facing: a client ID, a tenant ID, a subscription ID, a
+  # service name. They live in the same store as the secrets because they arrive the same way, but
+  # there is nothing to withhold, and withholding them makes an installation harder to read.
+  #
+  # These two rows replace five literal entries that existed only to set `sensitive: false` on one
+  # key each — `keycloak-client-idKeyVault`, `entra-client-idKeyVault`,
+  # `azure-subscription-idKeyVault`, `azure-tenant-idKeyVault`, `azure-service-nameKeyVault`. The
+  # convention now carries the decision, so a customer's own `myapp-tenant-idKeyVault` is readable
+  # without an edit here.
+  #
+  # ORDER MATTERS: `findCatalogEntry` checks exact keys, then patterns in FILE ORDER and returns the
+  # first match. Both suffixes also match the generic `*KeyVault` catch-all below, so they have to
+  # stay above it or they inherit `sensitive: true` and the convention silently does nothing.
+  - keyPattern: '^[a-zA-Z0-9_-]+-idKeyVault$'
+    scope: app
+    sensitive: false
+    generator:
+      type: emptyString
+    ensureOn: [resolveApp]
+
+  - keyPattern: '^[a-zA-Z0-9_-]+-nameKeyVault$'
+    scope: app
+    sensitive: false
+    generator:
+      type: emptyString
+    ensureOn: [resolveApp]
+
+  # Remaining *KeyVault secrets — created EMPTY, then supplied.
+  #
+  # This generated `randomBytes32`, so any `kv://<anything>KeyVault` key the catalog did not name
+  # explicitly received 32 random bytes — 44 base64 characters — and the reference resolved to a
+  # value that was never a credential anybody issued.
+  #
+  # Measured on installation aifabrix-ce-16, 2026-09-25: `secrets-policyPrivateKeyVault` is Mori's
+  # licence-policy SIGNING KEY and held exactly that, 44 characters and not a PEM. Mori's
+  # `signingKeysHealthCheck` parses the key rather than checking presence, so it reported
+  # `signingKeys` down, the container exited, and the web app answered HTTP 503 on every path for two
+  # days while App Service reported it Running. Mori's own comment had predicted this class in
+  # writing: "the deployment builder provisioned an unknown Key Vault catalog key with a random
+  # 44-character secret rather than failing: present, resolved, and not a private key at all".
+  #
+  # Empty is the correct default for a key nobody here mints. It creates the secret — so `kv://`
+  # resolves and the reference is valid — while leaving the value visibly unset, which is a state an
+  # operator can see and fix. A random value is indistinguishable from a real credential from the
+  # outside, which is precisely what made it expensive.
+  #
+  # The catch-all stays a pattern rather than becoming a list of literals on purpose: a customer
+  # deploying their own application declares its own `kv://` keys, and those must work without being
+  # hardcoded here. Values arrive afterwards through the write-only system-secrets API
+  # (`PUT /api/v1/environments/{envKey}/system-secrets/{catalogKey}`), which is what
+  # aifabrix-builder plan 204.0 builds the CLI for.
+  #
+  # A secret that genuinely has no issuer but must exist gets an explicit `randomBytes32` entry
+  # above. Adding one is the deliberate act; generation is no longer the silent default.
+  - keyPattern: '^[a-zA-Z0-9_-]+KeyVault$'
+    scope: app
+    sensitive: true
+    generator:
+      type: emptyString
+    ensureOn: [resolveApp]
+
+  # Non-secret values in the same store — the suffix carries the sensitivity.
+  #
+  # `*KeyVault` above means "secret": hidden by the list API, write-only through
+  # `PUT /api/v1/environments/{envKey}/system-secrets/{catalogKey}`. `*Param` means the same storage
+  # with nothing to hide: the list API returns the value, because `summarize()` emits `value` only
+  # when `sensitive === false`.
+  #
+  # Why a pattern and not more literals: the suffix used to say nothing about sensitivity, so every
+  # non-secret that happened to end in `KeyVault` needed its own literal row purely to set
+  # `sensitive: false` — `keycloak-client-idKeyVault`, `entra-client-idKeyVault`,
+  # `azure-subscription-idKeyVault`, `azure-tenant-idKeyVault`, `azure-service-nameKeyVault`. Client
+  # IDs, tenant IDs and service names are not credentials, and hardcoding each one does not scale:
+  # a customer deploying their own application cannot get a visible parameter without an edit here.
+  #
+  # With the convention, visibility is a naming decision the application author makes and a reader
+  # can see: name it `…Param` to be readable, `…KeyVault` to be secret. Changing your mind is a
+  # rename, not a catalog change. Both create the entry EMPTY and are supplied afterwards.
+  - keyPattern: '^[a-zA-Z0-9_-]+Param$'
+    scope: app
+    sensitive: false
+    generator:
+      type: emptyString
+    ensureOn: [resolveApp]