@aifabrix/builder 2.60.0 → 2.61.2

package/templates/applications/dataplane/env.template

@@ -44,7 +44,7 @@ API_KEY_BYPASS_ROLES=full-access
 
 # API Configuration
 API_V1_STR=/api/v1
-VERSION=2.0.74
+VERSION=2.0.79
 # Minimum supported aifabrix-builder CLI semver (advertised on /health and /api/v1/health; empty = no gate)
 # MIN_BUILDER_CLI_VERSION=2.45.0
 MIN_BUILDER_CLI_VERSION=2.45.5
@@ -137,21 +137,18 @@ ABAC_POLICY_PARSE_CACHE_MAX_ENTRIES=2048
 # AUTHENTICATION CONFIGURATION
 # =============================================================================
 
-# MISO secret runtime (583.0): every process calls miso-client init_secrets() once.
-# Unset/local: MISO_AUTH_MODE=local — the SDK keeps this .env/dotenv credential flow.
-# Azure: deployment supplies MISO_AUTH_MODE=azure-managed-identity, MISO_CONTROLLER_URL,
-# MISO_BOOTSTRAP_AUDIENCE (and optional AZURE_CLIENT_ID); Miso-managed secrets
-# (DATABASE_URL, REDIS_URL, ENCRYPTION_KEY, ...) come from the Controller broker,
-# never from this file, and no MISO_CLIENTSECRET is required or returned.
-# Rotation: changed names are reread from the SDK; DB/Redis pools are disposed and
-# the process reports secretRotationRestartRequired until restarted. Invalidation
-# (denial/expiry) stops new secret-dependent work and makes health unhealthy.
+# MISO governed configuration runtime (583.0): client credentials are active by default.
+# The SDK uses the per-application credentials below to load its bootstrap snapshot and
+# refreshes it automatically within two minutes. Changed names invoke application refresh
+# handlers; a handler may still recreate an internal resource such as a DB or Redis client.
+# Override with MISO_AUTH_MODE=local only for an explicit .env/dotenv development flow.
+# Invalidation (denial/expiry) stops new secret-dependent work and makes health unhealthy.
 # Health: /health, /api/v1/health and /api/v1/health/platform return HTTP 503 with
 # reasonCode misoTokenUnavailable | misoTokenRejected | misoControllerUnreachable |
 # misoValidationTimeout whenever the Controller does not accept the live client
 # token — in LOCAL_MODE too. These endpoints measure usable application health,
 # not process liveness.
-MISO_AUTH_MODE=local
+MISO_AUTH_MODE=client-credentials
 # MISO Application Client Credentials (per application)
 # Backend-only: never expose MISO_CLIENTSECRET to the Vite frontend (use VITE_* in app-ui).
 MISO_CLIENTID=kv://dataplane-client-idKeyVault
@@ -167,7 +164,8 @@ KEYCLOAK_REALM=aifabrix
 # =============================================================================
 # Public: browser redirects and CORS (includes /controller front-door path from miso-controller application.yaml).
 MISO_WEB_SERVER_URL=url://miso-controller-public
-# Internal: server-to-controller API calls (Docker: service:port; local: host:port — no front-door path).
+# Private service-to-service controller origin. The SDK permits HTTP only for a local/private
+# target; public or remote controller origins still require HTTPS.
 MISO_CONTROLLER_URL=url://miso-controller-internal
 # Browser logout page on miso-controller (path relative to MISO_WEB_SERVER_URL; not dataplane /login).
 MISO_LOGOUT_URL=/logout

package/templates/applications/keycloak/application.yaml

@@ -9,7 +9,12 @@ app:
 # Image Configuration
 image:
   name: aifabrix/keycloak
-  tag: '26.7.3-aifabrix.1'
+  # `latest`, like every other app here. The Keycloak version lives in app.version above,
+  # which is what `aifabrix push --tag 'latest,{version}'` expands, so nothing is lost by
+  # not repeating it here. Pinning it made `aifabrix run` look for keycloak-dev1:<version>
+  # while `aifabrix build` only ever produces :latest, so dev-build-kc failed with
+  # "Docker image not found" on an image it had just built.
+  tag: latest
   registry: aifabrixacr.azurecr.io
   registryMode: external
 

package/templates/applications/miso-controller/application.yaml

@@ -4,7 +4,7 @@ app:
   displayName: 'Miso Controller'
   description: 'Miso is the AI Fabrix in-tenant controller and portal layer for securely operating enterprise AI apps inside a customer’s Azure tenant. It provides Entra ID SSO, RBAC, audit logs, environment/app configuration via schemas, and safe secret handling via Key Vault references—ensuring governance, traceability, and predictable UX across portal, SDK, and CLI.'
   type: webapp
-  version: '2.0.83'
+  version: '2.0.89'
 # Image Configuration
 # Set tag to match your build (e.g. aifabrix build miso-controller -t 1.0.0 then tag: 1.0.0)
 # Registry is required so the controller can pull the image (avoids "docker: not found" on the controller host).
@@ -84,12 +84,68 @@ repository:
 # are stack-level, not per environment: there is no `environments:` section.
 # env.template consumes these names as {NAME}.
 platforms:
+  # Production is matched first and by its literal name, because its host is not the suffixed
+  # pattern the other platforms follow: `platform.aifabrix.dev`, not `platform-pro.aifabrix.dev`.
+  - resource: aifabrix-int-pro
+    name: aifabrix
+    platform: pro
+    configuration:
+      - name: LOCATION
+        value: 'swedencentral'
+      - name: MORI_BASE_URL
+        value: 'https://platform.aifabrix.dev/mori'
+
+  # Local Docker runs. No resource group is supplied, so `matchLocalPlatform` takes the FIRST entry
+  # declaring the local platform (`dev`) -- this one -- and the literal `aifabrix-local` can never
+  # match a real group, so Azure deployments fall through to the entries below.
+  #
+  # It MUST sit above `aifabrix-int-{platform}`: that entry also resolves to `dev`, so without this
+  # one a local stack took `https://platform-dev.aifabrix.dev/mori` -- a host that does not exist on
+  # a developer machine. Measured on dev01 2026-09-28: every Mori call failed with `socket hang up`,
+  # and `LicenseValidationService.pickupLicenseFromMori` maps that transport failure to
+  # `LicenseInvalidError`, which surfaces as **HTTP 403** on
+  # `POST /api/ide/onboarding/license/pickup`. A connection failure reported as Forbidden sent the
+  # investigation after api-key permissions for days (mori 48.0 `reproduce-license-pickup-403`).
+  #
+  # Service-to-service traffic has no reason to leave the cluster through the public edge, and the
+  # public host is not even resolvable from inside the container. Verified from the miso-controller
+  # container: `http://mori-controller:3004/api/v1/health` answers 200 while both
+  # `platform-dev.aifabrix.dev` and `dev01.aifabrix.dev` fail to connect.
+  #
+  # The value is the declarative `url://` form rather than a literal host, so the Builder resolves
+  # it from the platform topology the same way Mori's own env.template resolves
+  # `url://miso-controller-internal`. A literal would be a second place to edit whenever the local
+  # service address changes, and the whole point of `url://` is that there is one.
+  #
+  # Verified on dev01 that this is the reachable address and that the `/mori` prefix it carries is
+  # served: from the miso-controller container both `http://mori-controller:3004/api/v1/health` and
+  # `http://mori-controller:3004/mori/api/v1/health` answer 200. `moriApiBase()` appends `/api/v1`.
+  #
+  # NOT `kv://mori-controller-web-server-url`, which is what the entries below deliberately moved
+  # away from: that reads the application RECORD, and on aifabrix-ce-16 the record still held
+  # `http://localhost:3004`. `url://` is resolved from the topology at resolve time, not from a
+  # record an Azure deployment never overwrites.
+  - resource: aifabrix-local
+    name: aifabrix
+    platform: dev
+    configuration:
+      - name: LOCATION
+        value: 'swedencentral'
+      - name: MORI_BASE_URL
+        value: 'url://mori-controller-internal'
+
   - resource: aifabrix-int-{platform}
     name: aifabrix
-    options: [dev, tst, pro]
+    options: [dev, tst]
     configuration:
       - name: LOCATION
         value: 'swedencentral'
+      # Mori the installation talks to. Previously `kv://mori-controller-web-server-url`, which
+      # resolved to whatever the *application record* held — on aifabrix-ce-16 that was
+      # `http://localhost:3004`, because an Azure deployment never overwrites a stale URL, so every
+      # consumer of it was pointed at a loopback address that does not exist in the cluster.
+      - name: MORI_BASE_URL
+        value: 'https://platform-{platform}.aifabrix.dev/mori'
 
   - resource: aifabrix-ce-*
     name: '*'
@@ -98,6 +154,22 @@ platforms:
     configuration:
       - name: LOCATION
         value: 'swedencentral'
+      # The App Service hostname, not the Front Door one, because only this is derivable.
+      #
+      # The Front Door endpoint carries an Azure-generated suffix (`fzahchbachcfbgaj`) that no
+      # template can spell: `{platform}`, `{platform.name}` and `{resourceGroup}` are the only
+      # tokens, and none of them yields it. The previous literal was aifabrix-ce-16's endpoint and
+      # was therefore wrong for every other `aifabrix-ce-*` installation -- the next one built would
+      # have pointed its Miso at ce-16's Mori.
+      #
+      # The web app is named `{resourceGroup}-miso-mori-controller` by the installer, so its default
+      # hostname IS derivable and is correct for every installation in the group. Verified on
+      # aifabrix-ce-16 2026-09-27: that host answers /mori/health with 200. This is also the better
+      # address for Miso->Mori traffic, which is service-to-service and has no reason to leave the
+      # cluster through the public edge. When the named platform hosts exist
+      # (`platform-dev.aifabrix.dev/mori`) this entry can follow the pattern used above.
+      - name: MORI_BASE_URL
+        value: 'https://{resourceGroup}-miso-mori-controller.azurewebsites.net/mori'
 
 configuration:
   # -------------------------------------------------------------------------

package/templates/applications/miso-controller/env.template

@@ -193,16 +193,21 @@ WAIT_FOR_KEYCLOAK=true
 # For production: use public domain (e.g., https://miso.example.com)
 # url://public includes front-door path from application.yaml (e.g. /controller).
 MISO_WEB_SERVER_URL=url://public
+# Private service-to-service controller origin; public/browser traffic uses MISO_WEB_SERVER_URL.
 MISO_CONTROLLER_URL=url://internal
 MISO_RELATIVE_PATH=url://vdir-public
-ALLOWED_ORIGINS=http://localhost:*,url://host-public,url://host-private,url://dataplane-host-public,url://dataplane-host-private
+ALLOWED_ORIGINS=http://localhost:*,url://host-public,url://host-private,url://dataplane-host-public,url://dataplane-host-private,url://mori-controller-host-public
 # Opt-in: broker/entry/referer under /data keep …/data/auth/callback (do not append /miso). Default off.
 # AUTH_PRESERVE_DATAPLANE_VDIR=true
 
 # MISO Environment Configuration (miso, dev, tst, pro)
 MISO_ENVIRONMENT=miso
 
-# MISO Application Client Credentials (per application)
+# Governed configuration uses per-application client credentials by default. The SDK loads
+# its bootstrap snapshot and refreshes it automatically within two minutes; consumers decide
+# whether a changed key also requires an internal client or resource to be recreated.
+MISO_AUTH_MODE=client-credentials
+# MISO Application Client Credentials (per application; never expose the secret to the browser)
 MISO_CLIENTID=kv://miso-controller-client-idKeyVault
 MISO_CLIENTSECRET=kv://miso-controller-client-secretKeyVault
 
@@ -378,8 +383,17 @@ ENTRA_GRAPH_DELEGATED_REDIRECT_URI=url://mori-controller-public/entra-graph-dele
 # registered and running for this developer.
 # MORI_API_KEY is per-installation and is minted by POST /marketplace/bootstrap; it is written
 # here by the controller after registration, not provisioned ahead of it.
-MORI_BASE_URL=kv://mori-controller-web-server-url
+MORI_BASE_URL={MORI_BASE_URL}
 MORI_API_KEY=kv://mori-controller-api-keyKeyVault
+# Ask Mori for a container-registry credential when the installation was given none.
+# Off by default: the call has a 30s timeout inside credential resolution, so enabling it on an
+# installation whose Mori cannot issue would stall every deployment that reaches that point.
+# Declared here because it was previously read from process.env and set nowhere, so there was no
+# supported way to turn the path on — an installation that pulls vendor images through a
+# Mori-issued token had to have an app setting added by hand. Cross-tenant managed identity
+# cannot grant registry access, so this is the only mechanism that works for a customer
+# installation pulling from the vendor registry.
+MORI_REGISTRY_CREDENTIALS=false
 
 # =============================================================================
 # LOGGING CONFIGURATION
@@ -412,3 +426,28 @@ OTEL_SERVICE_VERSION=
 
 # Mount Volume Configuration
 MOUNT_VOLUME=/mnt/data/
+
+# Image registry this installation deploys from.
+#
+# `pipeline-validation-flow.helper.ts` resolves the deploy registry as ACR_LOGIN_SERVER first, then
+# the controller record's `configuration.imageRegistry`. Azure installations get the record from the
+# installer, so this stays EMPTY there and behaviour is unchanged. A local installation matches no
+# platform (`allowLocalPlatform` is false for the controller) and has no record, so without this key
+# every `aifabrix deploy` fails with "Image registry is not configured on the controller
+# installation".
+#
+# EMPTY on purpose. The controller record is read AFTER this and overwrites it, so an Azure
+# installation ignores whatever stands here; only a local installation consumes it.
+#
+# This briefly shipped as `aifabrixce16.azurecr.io` — one test installation's registry, committed
+# into the product, so every developer who did not override it would have pushed and pulled
+# against ce-16 without being told. A `{ACR_LOGIN_SERVER}` token was tried instead and is worse
+# still: nothing resolves it without a resource group, so it breaks `aifabrix build` outright
+# ("no platform or environment configuration resolves it for environment dev").
+#
+# Empty is the honest third answer. An Azure installation is unaffected, and a local
+# `aifabrix deploy` fails with "Image registry is not configured on the controller installation",
+# which names the missing thing. Its proper home is the Builder run tooling, which already knows
+# the answer (`aifabrix dev print-registry`) and should inject it per developer rather than have
+# Miso ship one installation's registry to everybody.
+ACR_LOGIN_SERVER=

package/templates/applications/miso-controller/rbac.yaml

@@ -176,6 +176,23 @@ permissions:
     roles: ['aifabrix-platform-admin', 'aifabrix-deployment-admin']
     description: 'Remove applications from environments'
 
+  # External-system catalog (aligned with src/examples/permissions.csv)
+  - name: 'external-system:read'
+    roles:
+      [
+        'aifabrix-platform-admin',
+        'aifabrix-security-admin',
+        'aifabrix-deployment-admin',
+        'aifabrix-compliance-admin',
+        'aifabrix-developer',
+        'aifabrix-observer'
+      ]
+    description: 'Read external systems'
+
+  - name: 'external-systems:domain-manager'
+    roles: ['aifabrix-platform-admin', 'aifabrix-security-admin']
+    description: 'Manage external-system catalog promotion and role-derived dimension governance'
+
   # Pipeline & Deployment
   - name: 'applications:deploy'
     roles: ['aifabrix-platform-admin', 'aifabrix-deployment-admin', 'aifabrix-developer']

package/templates/external-system/external-datasource.yaml.hbs

@@ -122,7 +122,13 @@ openapi:
 # documentStorage:
 #   enabled: true
 #   binaryOperationRef: get
-#   embeddingField: content
+#   responseType: binary
+#   ingestAfterSync: true
+# Keyed retrieval (no list): for a vendor PDF, image or octet-stream response,
+# keep only get in capabilities and end its CIP steps with output.mode: documents.
+# Fetch: { source: openapi, openapiRef: get, responseType: binary }
+# Map response metadata from raw.headers.FileName and raw.params.DocumentId.
+# The wizard and repair infer this shape from the vendor OpenAPI response media type.
 {{/if}}
 {{#if (eq schemaEntityType "vectorStore")}}
 # vectorStore: vector index settings (model id, dimensions, etc. per schema). Uncomment and set to match your embedding deployment.

package/templates/marketplace/main.json

@@ -5,7 +5,7 @@
     "_generator": {
       "name": "bicep",
       "version": "0.47.16.16243",
-      "templateHash": "6752412774681258733"
+      "templateHash": "8811550299172477333"
     }
   },
   "parameters": {
@@ -1047,7 +1047,7 @@
             "_generator": {
               "name": "bicep",
               "version": "0.47.16.16243",
-              "templateHash": "11131379543865133238"
+              "templateHash": "9369439869727192513"
             }
           },
           "parameters": {
@@ -1099,7 +1099,7 @@
             {
               "type": "Microsoft.KeyVault/vaults/secrets",
               "apiVersion": "2023-07-01",
-              "name": "[format('{0}/{1}', parameters('keyVaultName'), 'azureopenai-endpoint')]",
+              "name": "[format('{0}/{1}', parameters('keyVaultName'), 'dev-dataplane-azure-openai-endpoint')]",
               "properties": {
                 "value": "[reference(resourceId('Microsoft.CognitiveServices/accounts', variables('accountName')), '2023-05-01').endpoint]"
               },
@@ -1110,7 +1110,7 @@
             {
               "type": "Microsoft.KeyVault/vaults/secrets",
               "apiVersion": "2023-07-01",
-              "name": "[format('{0}/{1}', parameters('keyVaultName'), 'azureopenai-apikey')]",
+              "name": "[format('{0}/{1}', parameters('keyVaultName'), 'dev-dataplane-azure-openai-api-key')]",
               "properties": {
                 "value": "[listKeys(resourceId('Microsoft.CognitiveServices/accounts', variables('accountName')), '2023-05-01').key1]"
               },

package/templates/python/docker-compose.hbs

@@ -327,4 +327,4 @@ volumes:
 
 networks:
   {{networkName}}:
-    external: true
+    external: true

package/templates/agent-kit/skills/aifabrix-plan/references/interaction.md

@@ -1,41 +0,0 @@
-# Phase and result interaction
-
-Use structured questions. Do not start the next phase from chat prose alone.
-
-## After success
-
-Offer the next eligible phase. Proceed only on `next-yes`.
-
-Shared option ids: `next-yes` · `next-no` · `next-stop`.
-
-| Completed | Next offer |
-| --- | --- |
-| aifabrix-plan PLAN_READY | connected-system validate |
-| connected-system READY | connected-system build |
-| connected-system BUILT | connected-system publish |
-| connected-system PASS or PASS_WITH_SKIPS | archive (separate) and/or prove validate |
-| prove READY / BUILT / UPDATED | prove next phase |
-| prove PASS or PASS_WITH_SKIPS | iterate validate/build |
-
-Archive is a distinct user decision (`archive-yes` / `archive-no`). Never archive as a side effect of PASS.
-
-## On gaps
-
-- NEEDS_DECISIONS: AskQuestion challenge rows. No `cust-next`.
-- BLOCKED / FAIL / NEEDS_FIXES / ABORTED: do not offer the next phase as if success.
-
-A phase gate is per-gate, not overall. Offer the next phase only when the **Delivery** row
-supports it; a passing package gate beside `Delivery: NEEDS_FIXES` is not success and the
-offer must name what is still open.
-
-## Phase detection (connected-system and prove)
-
-1. Explicit phase from the user
-2. Ask, offering the routes in [status.md](../../shared/status.md)
-
-There is no third step. Package and plan state decide what you *recommend*, never what you
-run: a bare invocation reports status and stops ([status.md](../../shared/status.md)).
-Inferring "the safe next eligible phase" is what makes a skill start working before the
-user has said what they want.
-
-Never silently run the following phase after success.