@aifabrix/builder 2.59.0 → 2.61.2

package/lib/schema/infra.parameter.yaml

@@ -29,7 +29,6 @@ standardUpInfraEnsureKeys:
   - databases-dataplane-3-urlKeyVault
   - databases-dataplane-3-passwordKeyVault
   # Miso-controller Entra onboarding (vendor app); required for aifabrix resolve miso-controller
-  - entra-callback-state-secret
   - entra-callback-uri
   - entra-client-idKeyVault
   - entra-client-secretKeyVault
@@ -106,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.
@@ -349,20 +351,6 @@ parameters:
 
   # Miso-controller Entra ID onboarding (vendor multi-tenant app). Empty client/callback values
   # allow local resolve and start-dev; set real values before Entra admin-consent flows.
-  - key: entra-callback-state-secret
-    category: Microsoft Entra ID
-    sensitive: true
-    valueSource: generated
-    requiredOnSystemOnboarding: true
-    scope: system
-    generator:
-      type: randomBytes32
-    ensureOn: [upInfra, resolveApp]
-    azure:
-      notes: >-
-        Shared HMAC secret (min 16 chars) for OAuth state between controller and Mori callback;
-        maps to ENTRA_CALLBACK_STATE_SECRET in miso-controller env.template.
-
   - key: entra-callback-uri
     category: Microsoft Entra ID
     sensitive: false
@@ -441,8 +429,9 @@ parameters:
     # side is decrypted by the other. The read was already happening in the shipped template
     # and the policy denied it. Declared rather than silently permitted, and kept to the one
     # application that needs it instead of moving the key to a scope that grants everyone.
-    sharedWithAppKeys:
+    visibility:
       - dataplane
+      - mori-controller
     scope: app
     generator:
       type: randomBytes32
@@ -454,6 +443,32 @@ parameters:
       notes: >-
         32-byte secret as base64; generated on first ensure. Rotate in production.
 
+  - key: integration-server-secrets-encryptionKeyVault
+    ownerAppKey: integration-server
+    # Deliberately NOT shared with any other app, which is the point of the row.
+    # An integrator installation hands this key to every developer it provisions: it is
+    # written into each managed ~/.aifabrix/config.yaml as `secrets-encryption`, so the
+    # CLI can decrypt what that installation's own secrets API encrypted. A key shared
+    # with another application would therefore be readable by everyone holding a shell
+    # in that container, and one leak would reach every installation using it.
+    # One installation, one key, so the blast radius stays inside it.
+    #
+    # Before this row existed, integration-server's env.template read
+    # `kv://builder-server-secrets-encryptionKeyVault` — another application's key.
+    # That resolves only by being granted, and granting it grants exactly the access
+    # above; without a grant it silently generated an unrelated value instead, so the
+    # two server types drifted apart with nothing reporting it.
+    scope: app
+    generator:
+      type: randomBytes32
+    ensureOn: [upInfra, resolveApp]
+    azure:
+      vaultSecretName: integration-server-secrets-encryptionKeyVault
+      notes: >-
+        32-byte secret as base64; generated on first ensure, per installation. Rotating it
+        requires re-running configuration sync so every managed config.yaml is rewritten;
+        secrets already stored by that installation do not survive the rotation.
+
   # Local kv:// name matches miso-controller env.template (JWT_SECRET); not the generic {appKey}-secrets-jwtKeyVault Azure name.
   - key: miso-controller-jwt-secretKeyVault
     ownerAppKey: miso-controller
@@ -582,6 +597,7 @@ parameters:
   - key: miso-controller-client-idKeyVault
     ownerAppKey: miso-controller
     scope: app
+    sensitive: false
     generator:
       type: literal
       value: 'miso-controller-miso-miso-controller'
@@ -603,10 +619,35 @@ parameters:
         Per-app OAuth client secret used by miso-controller for service-to-service auth (MISO_CLIENTSECRET).
         Generated on first ensure for local bootstrap.
 
+  # 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).
   - key: dataplane-client-idKeyVault
     ownerAppKey: dataplane
     scope: app
+    sensitive: false
     generator:
       type: literal
       value: 'miso-controller-dev-dataplane'
@@ -640,18 +681,39 @@ 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.
     generator:
-      type: emptyString
+      type: rsaKeyPair
+      pairId: mori-license-signing
+      part: public
     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
@@ -693,7 +755,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
@@ -703,10 +765,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
@@ -716,21 +778,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
@@ -740,17 +789,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
@@ -761,6 +806,66 @@ 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
+    generator:
+      type: rsaKeyPair
+      pairId: mori-policy-signing
+      part: private
+    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.
+    generator:
+      type: rsaKeyPair
+      pairId: mori-license-signing
+      part: private
+    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
@@ -794,18 +899,6 @@ parameters:
         Optional local testing/development bearer bypass. A supplied local value is resolved; when absent,
         local and Azure application deployment resolve it as empty and do not fail.
 
-  - key: mori-callback-api-keyKeyVault
-    ownerAppKey: miso-controller
-    scope: app
-    generator:
-      type: randomBytes32
-    ensureOn: [resolveApp]
-    azure:
-      vaultSecretName: mori-callback-api-keyKeyVault
-      legacyVaultSecretNames:
-        - marketplace-mori-callback-api-key
-      notes: Miso Controller callback credential; generated only when its resolved manifest requires it.
-
   # App semver when env.template / conversion yields kv://version (local secrets backfill).
   - key: version
     scope: app
@@ -825,8 +918,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 +934,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 +949,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 +965,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 +1087,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 +1102,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 +1129,7 @@ parameters:
 
   # App-scoped URL placeholders (filled at resolve / deploy).
   - keyPattern: '^[a-z0-9-]+-url$'
+    sensitive: false
     scope: app
     generator:
       type: emptyString
@@ -902,6 +1137,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 +1146,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]