@askexenow/exe-os 0.9.362 → 0.9.365

package/deploy/compose/.env.customer.example

@@ -51,7 +51,7 @@ SMTP_PASS=
 # --- Auth gateway (exe-auth — shared SSO sign-in UI at auth.<domain>) ---
 # Bug 58840873: pin the auth image so compose never falls back to its stale
 # hardcoded default tag. Keep in sync with the manifest AUTH_IMAGE_TAG.
-AUTH_IMAGE_TAG=update.askexe.com/askexe/exe-auth:v0.2.0
+AUTH_IMAGE_TAG=update.askexe.com/askexe/exe-auth:v0.5.0
 # Bug 379e5c13: server_name / CORS from the CONFIGURED apex domain, not by naive
 # last-2-label slicing (which breaks company.co.uk → co.uk).
 AUTH_SERVER_NAME=auth.CHANGEME_DOMAIN
@@ -61,15 +61,59 @@ AUTH_DEFAULT_PRODUCT=AUTH
 # the sign-up UI/route instead of showing a form that always fails.
 AUTH_DISABLE_SIGNUP=true
 
+# --- Centralized role administration (permissions) ---
+# The apps refuse to let an unmanaged first login mint its own admin
+# (exe-crm#102 / exe-wiki#45). Both flags below are therefore left at their
+# SECURE default of true, stated explicitly rather than inherited silently.
+#
+# Because of that, a fresh CRM gets its first admin from EXE_CRM_ADMIN_EMAIL
+# in the CRM section below — NOT from whoever signs in first. That user is
+# seeded at boot, so their sign-in is an existing-user login and is allowed;
+# every OTHER unmanaged first login is still refused. If you leave
+# EXE_CRM_ADMIN_EMAIL empty, the seed silently does not happen and the CRM
+# cannot be bootstrapped at all. The wiki does not need this: its first admin
+# comes from POST /system/enable-multi-user, authorised by WIKI_AUTH_TOKEN.
+CRM_REQUIRE_MANAGED_PERMS=true
+WIKI_REQUIRE_MANAGED_PERMS=true
+#
+# MANAGED MODE — roles set ONLY in the Exe dashboard. Empty means unmanaged:
+# no token can carry permissions for an org that was never named. To adopt it:
+#   EXE_ORG_ID=<org id from the Exe dashboard>
+#   EXE_ORG_WORKSPACE_ID=<the org's canonical ACTIVE CRM workspace>
+# EXE_ORG_WORKSPACE_ID must ALREADY EXIST and have a legitimate admin, because
+# managed users join THAT workspace instead of creating their own. That is why
+# managed mode cannot be the shipped default: on a fresh stack the workspace
+# does not exist yet, so its id is unknowable at install time. Bootstrap the
+# stack first, then set these and redeploy. The wiki needs only EXE_ORG_ID.
+EXE_ORG_ID=
+EXE_ORG_WORKSPACE_ID=
+
 # --- CRM ---
 CRM_IMAGE_TAG=update.askexe.com/askexe/exe-crm:v0.9.51
 CRM_SERVER_URL=https://crm.CHANGEME_DOMAIN
 CRM_APP_SECRET=CHANGEME_CRM_APP_SECRET
+# The CRM's first admin — seeded at boot by WorkspaceBootstrapService, which is
+# what makes that person an EXISTING user whose sign-in is allowed while every
+# other unmanaged first login is refused (e51ca54c §10.6b). Must be a real
+# mailbox that also exists in GoTrue (CUSTOMER-GUIDE Step 6), so it cannot be
+# generated. Leave it empty and the seed silently throws: the CRM comes up
+# healthy with no workspace and no user, and nobody can ever sign in.
+# SET_MANUALLY
+EXE_CRM_ADMIN_EMAIL=CHANGEME_ADMIN_EMAIL
 CRM_HOST_PORT=3000
 
 # --- Wiki ---
 WIKI_IMAGE_TAG=update.askexe.com/askexe/exe-wiki:v0.9.26
-WIKI_DB_SCHEMA=wiki
+# Bug 2a8d3003 — DO NOT change this without migrating the data first.
+# The wiki's users / workspaces / workspace_documents live in `public`. Point it at a
+# different schema and Prisma will NOT error: it finds no tables, assumes a fresh
+# database, creates empty ones, and the wiki comes up with zero documents and the
+# admin locked out. It looks exactly like catastrophic data loss while every row is
+# still sitting safely in `public`. That misread has a very expensive next step —
+# restoring a backup over good data. This value used to default to `wiki`, and the
+# only thing holding production together was a host-local compose override.
+# exe-wiki-schema-guard blocks the boot if you get this wrong.
+WIKI_DB_SCHEMA=public
 WIKI_VECTOR_DB=exeOsMcp
 WIKI_AUTH_TOKEN=CHANGEME_WIKI_AUTH_TOKEN
 WIKI_JWT_SECRET=CHANGEME_WIKI_JWT_SECRET

package/deploy/compose/.env.example

@@ -80,26 +80,73 @@ SMTP_PASS=
 # Bug 58840873: pin the auth image so compose never falls back to its stale
 # hardcoded default tag. Keep in sync with the manifest AUTH_IMAGE_TAG. exe-auth
 # ships only from the private update.askexe.com registry (no GHCR mirror).
-AUTH_IMAGE_TAG=update.askexe.com/askexe/exe-auth:v0.2.0
+AUTH_IMAGE_TAG=update.askexe.com/askexe/exe-auth:v0.5.0
 # Bug 379e5c13: server_name / CORS derived from the CONFIGURED apex domain,
 # not by naive last-2-label slicing (which breaks company.co.uk → co.uk).
 AUTH_SERVER_NAME=auth.CHANGEME_DOMAIN
 AUTH_CORS_ORIGIN=https://CHANGEME_DOMAIN
 AUTH_DEFAULT_PRODUCT=AUTH
+# Brand word after the gold "EXE" in the login logo (exe-auth v0.5.0+). One
+# identity for the whole front door — ?product= never rebrands the page. Leave
+# unset for the stack default "EXE INTELLIGENCE"; white-label deploys set their
+# own word here.
+#AUTH_BRAND_NAME=INTELLIGENCE
 # Bug 5960ebb1: invite-only — mirror GOTRUE_DISABLE_SIGNUP so the auth SPA hides
 # the sign-up UI/route instead of showing a form that always fails.
 AUTH_DISABLE_SIGNUP=true
 
+# --- Centralized role administration (permissions) ---
+# The apps refuse to let an unmanaged first login mint its own admin
+# (exe-crm#102 / exe-wiki#45). Both flags below are therefore left at their
+# SECURE default of true, stated explicitly rather than inherited silently.
+#
+# Because of that, a fresh CRM gets its first admin from EXE_CRM_ADMIN_EMAIL
+# in the CRM section below — NOT from whoever signs in first. That user is
+# seeded at boot, so their sign-in is an existing-user login and is allowed;
+# every OTHER unmanaged first login is still refused. If you leave
+# EXE_CRM_ADMIN_EMAIL empty, the seed silently does not happen and the CRM
+# cannot be bootstrapped at all. The wiki does not need this: its first admin
+# comes from POST /system/enable-multi-user, authorised by WIKI_AUTH_TOKEN.
+CRM_REQUIRE_MANAGED_PERMS=true
+WIKI_REQUIRE_MANAGED_PERMS=true
+#
+# MANAGED MODE — roles set ONLY in the Exe dashboard. Empty means unmanaged:
+# no token can carry permissions for an org that was never named. To adopt it:
+#   EXE_ORG_ID=<org id from the Exe dashboard>
+#   EXE_ORG_WORKSPACE_ID=<the org's canonical ACTIVE CRM workspace>
+# EXE_ORG_WORKSPACE_ID must ALREADY EXIST and have a legitimate admin, because
+# managed users join THAT workspace instead of creating their own. That is why
+# managed mode cannot be the shipped default: on a fresh stack the workspace
+# does not exist yet, so its id is unknowable at install time. Bootstrap the
+# stack first, then set these and redeploy. The wiki needs only EXE_ORG_ID.
+EXE_ORG_ID=
+EXE_ORG_WORKSPACE_ID=
+
 # --- CRM ---
 CRM_IMAGE_TAG=ghcr.io/askexe/exe-crm:v0.9.51
 CRM_SERVER_URL=https://crm.CHANGEME_DOMAIN
 CRM_APP_SECRET=CHANGEME_CRM_APP_SECRET
 EXE_CRM_ADMIN_TOKEN=CHANGEME_EXE_CRM_ADMIN_TOKEN
+# The CRM's first admin — seeded at boot by WorkspaceBootstrapService, which
+# is what makes that person an EXISTING user whose sign-in is allowed while
+# every other unmanaged first login is refused (e51ca54c §10.6b). Must be a
+# real mailbox that also exists in GoTrue, so it cannot be generated.
+# SET_MANUALLY
+EXE_CRM_ADMIN_EMAIL=CHANGEME_ADMIN_EMAIL
 CRM_HOST_PORT=3000
 
 # --- Wiki ---
 WIKI_IMAGE_TAG=ghcr.io/askexe/exe-wiki:v0.9.26
-WIKI_DB_SCHEMA=wiki
+# Bug 2a8d3003 — DO NOT change this without migrating the data first.
+# The wiki's users / workspaces / workspace_documents live in `public`. Point it at a
+# different schema and Prisma will NOT error: it finds no tables, assumes a fresh
+# database, creates empty ones, and the wiki comes up with zero documents and the
+# admin locked out. It looks exactly like catastrophic data loss while every row is
+# still sitting safely in `public`. That misread has a very expensive next step —
+# restoring a backup over good data. This value used to default to `wiki`, and the
+# only thing holding production together was a host-local compose override.
+# exe-wiki-schema-guard blocks the boot if you get this wrong.
+WIKI_DB_SCHEMA=public
 WIKI_VECTOR_DB=exeOsMcp
 WIKI_AUTH_TOKEN=CHANGEME_WIKI_AUTH_TOKEN
 EXE_WIKI_ADMIN_TOKEN=CHANGEME_EXE_WIKI_ADMIN_TOKEN

package/deploy/compose/cloudflared/config.yml.example

@@ -8,16 +8,18 @@
 #        wiki.<domain>    → http://exe-sso-edge:80   (unified SSO redirect)
 #        erp.<domain>     → http://exe-sso-edge:80   (unified SSO redirect)
 #        gateway.<domain> → http://exe-gateway:3100
-#        dashboard.askexe.com → http://exe-dashboard:80
+#        dashboard.<domain> → http://exe-sso-edge:80 (unified SSO redirect — NOT
+#                            exe-dashboard:80, which would skip the login gate)
 #        monitor.<domain> → http://exe-monitor-hub:8090
 #        auth.<domain>    → http://exe-sso-edge:80  (auth gateway + real health aliases)
 #        api.<domain>     → http://exe-os:8765
 #   No config.yml or credentials file needed — the token embeds everything.
 #
-#   IMPORTANT: crm/wiki/erp MUST route through exe-sso-edge (NOT straight to the
-#   app container). The edge is what 302s unauthenticated visitors to
-#   auth.<domain>; routing direct to the app skips the redirect (this was the
-#   bug). exe-sso-edge picks the app by Host header, so all three share one route.
+#   IMPORTANT: crm/wiki/erp/dashboard MUST route through exe-sso-edge (NOT
+#   straight to the app container). The edge is what 302s unauthenticated
+#   visitors to auth.<domain>; routing direct to the app skips the redirect
+#   (this was the bug). exe-sso-edge picks the app by Host header, so all four
+#   share one route.
 #
 # ADVANCED (config file mode): only needed if you want to manage routes locally
 # instead of via the Cloudflare dashboard. Leave CLOUDFLARE_TUNNEL_TOKEN empty
@@ -44,9 +46,14 @@ ingress:
   # Gateway (WhatsApp, webhooks, pairing)
   - hostname: gateway.CHANGEME_DOMAIN
     service: http://exe-gateway:3100
-  # AskExe customer dashboard (nginx in exe-dashboard listens on container port 80).
-  - hostname: dashboard.askexe.com
-    service: http://exe-dashboard:80
+  # Dashboard — through the unified SSO edge, same as crm/wiki/erp. The edge
+  # gates on the canonical exe_access_token cookie and 302s unauthenticated
+  # visitors to auth.<domain>/?product=Dashboard&redirect=<dashboard-url><uri>.
+  # Routing straight to exe-dashboard:80 skips that gate (same class of bug as
+  # 96f8b2b2 for crm/wiki/erp) and leaves an ungated hostname serving 200 to
+  # anonymous requests.
+  - hostname: dashboard.CHANGEME_DOMAIN
+    service: http://exe-sso-edge:80
   # Monitor — /_/ admin panel blocked; only the API and UI are exposed publicly.
   # The PocketBase superadmin UI must be accessed via SSH tunnel:
   #   ssh -L 8090:127.0.0.1:8090 <vps> then open http://localhost:8090/_/

package/deploy/compose/docker-compose.yml

@@ -254,7 +254,7 @@ services:
       options: { max-size: "10m", max-file: "3" }
 
   exe-monitor-hub:
-    image: ${MONITOR_HUB_IMAGE_TAG:-ghcr.io/askexe/exe-monitor-hub:v0.9.5}
+    image: ${MONITOR_HUB_IMAGE_TAG:-ghcr.io/askexe/exe-monitor-hub:v0.9.5@sha256:1af31893cc8b1e51892be7d7705fa6c6b3108af8366b1fa8da2879d8ae21ec88}
     container_name: exe-monitor-hub
     restart: unless-stopped
     # bug d3d49101 / 1fdb8be9: PocketBase's data dir for this hub is a RELATIVE
@@ -332,7 +332,7 @@ services:
   # ------------------------------------------------------------------
 
   exe-crm:
-    image: ${CRM_IMAGE_TAG:-ghcr.io/askexe/exe-crm:v0.9.51}
+    image: ${CRM_IMAGE_TAG:-ghcr.io/askexe/exe-crm:v0.9.51@sha256:73864ce14aaac06b73d67100bbf88e669fd13c7da39edd9644107037211559b7}
     container_name: exe-crm
     restart: unless-stopped
     # bug ad4471ad: NO compose `command` override. The image entrypoint
@@ -368,7 +368,52 @@ services:
       MONITOR_API_KEY: ${MONITOR_API_KEY:-${EXE_MONITOR_KEY:-}}
       APP_SECRET: ${CRM_APP_SECRET:?CRM_APP_SECRET is required}
       EXE_CRM_ADMIN_TOKEN: ${EXE_CRM_ADMIN_TOKEN:-}
+      # ── Centralized role administration (e51ca54c §10.6b) ──────────────────
+      # READ BEFORE CHANGING. These four values decide whether a fresh install
+      # can seat an administrator at all, and whether a stranger can seat
+      # himself. Both failure modes are one empty variable away.
+      #
+      # HOW A FIRST ADMIN IS MEANT TO APPEAR. On an empty database
+      # WorkspaceBootstrapService (workspace-bootstrap.service.ts, OnModuleInit)
+      # seeds one workspace (activationStatus=PENDING_CREATION) plus the user
+      # named by EXE_CRM_ADMIN_EMAIL. When that person later signs in through
+      # GoTrue they are an EXISTING user, so the first-login path is never
+      # entered; the pending workspace is activated and setupDefaultRoles grants
+      # them Admin. The first admin is therefore chosen by the OPERATOR, in this
+      # file, before anyone logs in.
+      #
+      # WHY EXE_CRM_ADMIN_EMAIL IS NOT OPTIONAL IN PRACTICE. bootstrapIfEmpty()
+      # THROWS when it is empty, and onModuleInit swallows that error as
+      # "non-fatal" — the CRM boots healthy with no workspace and no user. Leave
+      # it unset and the seed silently does not happen; the next sign-in is then
+      # a FIRST login, which exe-crm#102 refuses (403), and the
+      # POST /api/auth/admin-token break-glass also fails ("No workspace found"),
+      # because it activates an existing workspace and never creates one. That is
+      # a fresh install nobody can ever get into. It is left `:-` rather than
+      # `:?` ONLY so that already-provisioned customer stacks keep parsing this
+      # file; a NEW install that omits it is broken, which is why generate-env.ts
+      # now emits it and .env.customer.example marks it SET_MANUALLY.
       EXE_CRM_ADMIN_EMAIL: ${EXE_CRM_ADMIN_EMAIL:-}
+      # The guard itself stays at its SECURE default, stated rather than
+      # inherited. exe-crm#102 makes managed-permissions required by default so
+      # an unmanaged FIRST login can no longer create a workspace and take its
+      # Admin role. Because the bootstrap above seats the intended owner as an
+      # existing user, keeping this ON costs a correct install nothing — and it
+      # still refuses every OTHER unmanaged first login. Set it to false only for
+      # a deliberate no-control-plane bootstrap where you accept that the first
+      # unmanaged sign-in becomes a workspace Admin; the app logs that choice as
+      # a SECURITY DOWNGRADE on every boot.
+      CRM_REQUIRE_MANAGED_PERMS: ${CRM_REQUIRE_MANAGED_PERMS:-true}
+      # Managed mode (roles set ONLY in the Exe dashboard). Empty here means
+      # unmanaged: no token can carry permissions for an org that was never
+      # named, so every login resolves { managed: false }. To adopt it, set both
+      # — EXE_ORG_WORKSPACE_ID must name an ALREADY-EXISTING active workspace
+      # with a legitimate admin, because managed users join THAT workspace
+      # instead of minting their own. That ordering is why managed mode cannot be
+      # the shipped default: on a fresh stack the workspace does not exist yet,
+      # so its id is unknowable at install time. Bootstrap first, then adopt.
+      EXE_ORG_ID: ${EXE_ORG_ID:-}
+      EXE_ORG_WORKSPACE_ID: ${EXE_ORG_WORKSPACE_ID:-}
       GOTRUE_URL: http://gotrue:9999
       # Bug 51086951: the EXPECTED JWT issuer. GOTRUE_URL above is the INTERNAL
       # address used to call GoTrue, but browser tokens are signed with the PUBLIC
@@ -376,6 +421,18 @@ services:
       # SAME public value here so issuer validation accepts real browser sessions
       # instead of rejecting them as iss-mismatch. Same default as the gotrue pin.
       GOTRUE_JWT_ISSUER: ${GOTRUE_JWT_ISSUER:-${GOTRUE_EXTERNAL_URL:?GOTRUE_EXTERNAL_URL is required — set to https://auth.<your-domain> in .env}}
+      # Bug 550d6ab7: CRM verifies GoTrue tokens JWKS-first with an HS256
+      # shared-secret fallback (exe-crm access-token.service.ts verifyGoTrueToken
+      # -> getGoTrueSymmetricVerificationKey, landed in exe-crm 80c5cd95). Our
+      # GoTrue is configured with a SYMMETRIC GOTRUE_JWT_SECRET and no
+      # GOTRUE_JWT_KEYS, so it publishes an empty JWKS ({"keys":[]}) — and it
+      # MUST stay empty, because publishing an `oct` key would publish the
+      # signing secret itself. The HS256 fallback is therefore the ONLY viable
+      # verification path, and it returns null when this variable is unset. That
+      # is the same defect class as bug 0c0d5187 on exe-wiki (see the wiki
+      # service block below): the fix landed in the app, the secret was never
+      # handed to the container, so SSO stayed dead. Fail loud.
+      GOTRUE_JWT_SECRET: ${GOTRUE_JWT_SECRET:?GOTRUE_JWT_SECRET is required}
       PG_DATABASE_URL: postgres://${POSTGRES_USER:-exe}:${POSTGRES_PASSWORD:?POSTGRES_PASSWORD is required}@exe-db:5432/${POSTGRES_DB:-exedb}?sslmode=disable
       REDIS_URL: redis://:${REDIS_PASSWORD:?REDIS_PASSWORD is required}@redis:6379
       CLICKHOUSE_URL: http://${CLICKHOUSE_USER:-exe}:${CLICKHOUSE_PASSWORD:?CLICKHOUSE_PASSWORD is required}@clickhouse:8123/${CLICKHOUSE_DB:-default}
@@ -401,7 +458,7 @@ services:
       options: { max-size: "10m", max-file: "3" }
 
   exe-crm-worker:
-    image: ${CRM_IMAGE_TAG:-ghcr.io/askexe/exe-crm:v0.9.51}
+    image: ${CRM_IMAGE_TAG:-ghcr.io/askexe/exe-crm:v0.9.51@sha256:73864ce14aaac06b73d67100bbf88e669fd13c7da39edd9644107037211559b7}
     container_name: exe-crm-worker
     restart: unless-stopped
     command: ["yarn", "worker:prod"]
@@ -460,17 +517,63 @@ services:
       driver: json-file
       options: { max-size: "10m", max-file: "3" }
 
+  # Bug 2a8d3003: one-shot pre-flight that refuses to let exe-wiki start against a
+  # schema where its data isn't. Reuses the already-present Postgres image purely for
+  # its psql client — no extra pull. See wiki-schema-guard.sh for the full rationale;
+  # the short version is that Prisma silently bootstraps an empty schema rather than
+  # erroring, so "wiki looks wiped" and "wiki is misconfigured" are indistinguishable
+  # at a glance, and the wrong diagnosis (restore from backup) destroys real data.
+  exe-wiki-schema-guard:
+    image: ${EXE_DB_IMAGE:-pgvector/pgvector:0.8.0-pg16@sha256:a132765ec351c65111b5b675928a3a0515a466a40f97277329db8b8209ad8bc9}
+    container_name: exe-wiki-schema-guard
+    restart: "no"
+    depends_on:
+      exe-db:
+        condition: service_healthy
+    environment:
+      # MUST stay byte-identical to exe-wiki's DATABASE_URL below — the guard's whole
+      # job is to assert on the schema the wiki itself will resolve.
+      DATABASE_URL: postgres://${POSTGRES_USER:-exe}:${POSTGRES_PASSWORD:?POSTGRES_PASSWORD is required}@exe-db:5432/${POSTGRES_DB:-exedb}?schema=${WIKI_DB_SCHEMA:-public}&sslmode=disable
+      WIKI_SCHEMA_GUARD: ${WIKI_SCHEMA_GUARD:-enforce}
+    volumes:
+      - ./wiki-schema-guard.sh:/usr/local/bin/wiki-schema-guard.sh:ro
+    # Fail OPEN when the script itself is missing, fail CLOSED on what it detects.
+    # On a stack dir that predates this change Docker materialises the bind source as
+    # an empty directory, and a guard that can't be found must not be the reason the
+    # wiki stays down — an absent guard is no worse than the status quo, whereas a
+    # guard that wedges the wiki is a new outage. stack-update installs the real
+    # script next to docker-compose.yml on every run.
+    entrypoint:
+      - bash
+      - -c
+      - |
+        if [ -f /usr/local/bin/wiki-schema-guard.sh ]; then
+          exec bash /usr/local/bin/wiki-schema-guard.sh
+        fi
+        echo "[wiki-schema-guard] script not installed next to docker-compose.yml — skipping."
+        echo "[wiki-schema-guard] run 'exe-os stack update' to install it; until then the"
+        echo "[wiki-schema-guard] wiki can boot against an empty schema undetected (bug 2a8d3003)."
+    networks:
+      - backend
+    logging:
+      driver: json-file
+      options: { max-size: "10m", max-file: "3" }
+
   exe-wiki:
-    image: ${WIKI_IMAGE_TAG:-ghcr.io/askexe/exe-wiki:v0.9.26}
+    image: ${WIKI_IMAGE_TAG:-ghcr.io/askexe/exe-wiki:v0.9.26@sha256:c0d61d183b274a67977fdfb1b40d5e4736559a9d90507843183e5642da2a959d}
     container_name: exe-wiki
     restart: unless-stopped
     # Wiki uses Prisma — runs migrate on boot via built-in entrypoint.
-    # If tables don't exist, Prisma creates them automatically.
+    # If tables don't exist, Prisma creates them automatically. That convenience is
+    # exactly why exe-wiki-schema-guard has to clear the boot first (bug 2a8d3003):
+    # pointed at the wrong schema, Prisma builds empty tables instead of complaining.
     depends_on:
       exe-db:
         condition: service_healthy
       gotrue:
         condition: service_healthy
+      exe-wiki-schema-guard:
+        condition: service_completed_successfully
     # SECURITY (bug 67d62490): no blanket `env_file: .env`. Each service
     # receives ONLY the secrets it owns via the explicit `environment:` block
     # below (values interpolated from .env at compose-parse time, never the
@@ -486,10 +589,55 @@ services:
       ERROR_REPORTING_ENABLED: "true"
       MONITOR_ERROR_URL: http://exe-monitor-hub:8090/api/exe-monitor/errors
       MONITOR_API_KEY: ${MONITOR_API_KEY:-${EXE_MONITOR_KEY:-}}
-      DATABASE_URL: postgres://${POSTGRES_USER:-exe}:${POSTGRES_PASSWORD:?POSTGRES_PASSWORD is required}@exe-db:5432/${POSTGRES_DB:-exedb}?schema=${WIKI_DB_SCHEMA:-wiki}&sslmode=disable
+      # Bug 2a8d3003: the wiki's live data lives in the `public` schema and ALWAYS has.
+      # This default used to be `wiki`, and the ONLY thing keeping production pointed at
+      # its real content was a hand-written docker-compose.override.yml on the host that
+      # dropped the schema param. Drop that override — or honour WIKI_DB_SCHEMA=wiki —
+      # and the wiki boots against an empty `wiki` schema that Prisma will happily
+      # bootstrap: zero users, zero documents, admin locked out, and the real rows
+      # sitting untouched in `public` looking exactly like data loss. `public` is now the
+      # explicit, authoritative default so base and override agree.
+      #
+      # Why keep `?schema=` rather than omitting it: an omitted param makes resolution
+      # implicit (it falls back to the role's search_path, which ALTER ROLE can silently
+      # change). Naming the schema pins it deterministically and keeps the knob available
+      # for operators who genuinely want isolation — see WIKI_DB_SCHEMA in .env.example
+      # for the migration that requires. exe-wiki-schema-guard below enforces the choice.
+      DATABASE_URL: postgres://${POSTGRES_USER:-exe}:${POSTGRES_PASSWORD:?POSTGRES_PASSWORD is required}@exe-db:5432/${POSTGRES_DB:-exedb}?schema=${WIKI_DB_SCHEMA:-public}&sslmode=disable
       AUTH_TOKEN: ${WIKI_AUTH_TOKEN:?WIKI_AUTH_TOKEN is required}
       EXE_WIKI_ADMIN_TOKEN: ${EXE_WIKI_ADMIN_TOKEN:-}
+      # ── Centralized role administration (e51ca54c §10.6b) ──────────────────
+      # The wiki keeps the SECURE default, stated rather than inherited.
+      #
+      # exe-wiki#45 makes WIKI_REQUIRE_MANAGED_PERMS default ON: an unmanaged
+      # identity (which is every identity while EXE_ORG_ID is empty) provisions
+      # as a non-privileged `default` — it can sign in, gets no admin and no
+      # workspace, and sees "contact your administrator to request access to a
+      # team". Unlike the CRM this does NOT strand a fresh install, because the
+      # wiki's first admin does not come from an SSO first login at all: a fresh
+      # wiki boots in single-user mode (prisma seed sets multi_user_mode=false)
+      # and POST /system/enable-multi-user — authorised by the admin-token bypass
+      # in validatedRequest.js, which accepts EXE_WIKI_ADMIN_TOKEN *or* the
+      # always-required AUTH_TOKEN above — creates the first `role: admin` user
+      # directly, never touching resolveGoTrueUser. So the guard costs a correct
+      # install nothing here and is left ON.
+      #
+      # Managed mode: set EXE_ORG_ID (shared with exe-crm) and roles follow the
+      # dashboard's caps. The wiki needs no workspace-id pin because it never
+      # creates a tenant, so it can be flipped as soon as an org id exists.
+      # Setting this to false restores first-user-admin and is logged as a
+      # SECURITY DOWNGRADE on every boot.
+      WIKI_REQUIRE_MANAGED_PERMS: ${WIKI_REQUIRE_MANAGED_PERMS:-true}
+      EXE_ORG_ID: ${EXE_ORG_ID:-}
       GOTRUE_URL: http://gotrue:9999
+      # Bug 0c0d5187: the wiki verifies GoTrue HS256 tokens with GOTRUE_JWT_SECRET
+      # (server/utils/gotrue/index.js getGoTrueJwtSecret reads ONLY
+      # GOTRUE_JWT_SECRET || EXE_GOTRUE_JWT_SECRET) — NOT the wiki-local JWT_SECRET
+      # below. Without it, GoTrue's JWKS is empty so the asymmetric path is dead too,
+      # and every SSO exchange AND the wiki's own password form 401 with
+      # "Invalid or expired SSO token." Fail loud rather than ship a wiki nobody can
+      # log in to.
+      GOTRUE_JWT_SECRET: ${GOTRUE_JWT_SECRET:?GOTRUE_JWT_SECRET is required}
       # Bug 98a528a7 (class): the PUBLIC auth domain the wiki login link must point at.
       # Same lever as ERP — without it the wiki frontend can default to auth.askexe.com
       # instead of the customer's auth.<domain>. The wiki image must build its SSO
@@ -552,7 +700,7 @@ services:
   # to pin the split server image; falls back to the combined EXE_OS_IMAGE_TAG
   # for backward compatibility with existing manifests.
   exe-os:
-    image: ${EXE_OS_SERVER_IMAGE_TAG:-${EXE_OS_IMAGE_TAG:-${EXED_IMAGE_TAG:-ghcr.io/askexe/exe-os:v0.9.311}}}
+    image: ${EXE_OS_SERVER_IMAGE_TAG:-${EXE_OS_IMAGE_TAG:-${EXED_IMAGE_TAG:-ghcr.io/askexe/exe-os:v0.9.311@sha256:011730042f55277724dbe83fde1a6416db2f3e8bf62d3254738d68d8de33e1f9}}}
     container_name: exe-os
     restart: unless-stopped
     # bug debf4a39 / 93ddfa27: the daemon connects to exe-db at boot
@@ -617,7 +765,22 @@ services:
   # the GGUF model files at /home/exed/.exe-os/models/.
   # ------------------------------------------------------------------
   exe-os-worker:
-    image: ${EXE_OS_WORKER_IMAGE_TAG:-ghcr.io/askexe/exe-os-worker:v0.9.311}
+    # NO DEFAULT ON PURPOSE. This slot used to default to
+    # ghcr.io/askexe/exe-os-worker:v0.9.311 — an image that has NEVER been
+    # published (GHCR returns "manifest unknown" for every tag, and the package
+    # itself 404s). Nobody noticed because embeddings are off by default and this
+    # service is profile-gated, so the tag was only ever a promise.
+    #
+    # A default that cannot be pulled is worse than no default: it turns "enable
+    # embeddings" into an unpullable-image failure, and it cannot be digest-pinned,
+    # which is what the strict-digest gate requires. The slot is left EMPTY instead —
+    # `docker compose` refuses to start a service with no image, so activating the
+    # embeddings profile without setting this fails loudly and immediately. When a
+    # worker image is published, set EXE_OS_WORKER_IMAGE_TAG to a digest-pinned ref
+    # (ghcr.io/askexe/exe-os-worker:<tag>@sha256:<digest>) — strict-digest enforces
+    # the pin from there. Deliberately NOT `:?`: that would make the variable
+    # mandatory for every deploy, including the default embeddings-off one.
+    image: ${EXE_OS_WORKER_IMAGE_TAG:-}
     container_name: exe-os-worker
     profiles: ["embeddings"]
     restart: unless-stopped
@@ -656,7 +819,7 @@ services:
       options: { max-size: "10m", max-file: "3" }
 
   exe-gateway:
-    image: ${GATEWAY_IMAGE_TAG:-ghcr.io/askexe/exe-gateway:v0.9.24}
+    image: ${GATEWAY_IMAGE_TAG:-ghcr.io/askexe/exe-gateway:v0.9.24@sha256:9cda7c00d886b4ab16a3b88aa953aa45c991f2977084ea8532f55fcaf75e8f37}
     container_name: exe-gateway
     restart: unless-stopped
     # Gateway needs 45s to flush outbound queues + disconnect Baileys adapters.
@@ -804,7 +967,7 @@ services:
   # include "monitor-agent". See deploy/monitor/HOST-ACCESS-CONSENT.md.
   # ------------------------------------------------------------------
   exe-monitor-agent:
-    image: ${MONITOR_AGENT_IMAGE_TAG:-ghcr.io/askexe/exe-monitor-agent:v0.9.5}
+    image: ${MONITOR_AGENT_IMAGE_TAG:-ghcr.io/askexe/exe-monitor-agent:v0.9.5@sha256:cada7dace00ccb629aa10976e80e20d7d25685042519bd2aec58ab4bf35ff0cd}
     container_name: exe-monitor-agent
     # Host-access consent gate: only starts when the operator has
     # acknowledged the host-access scope (COMPOSE_PROFILES=monitor-agent).
@@ -853,11 +1016,32 @@ services:
     networks:
       - backend
     healthcheck:
-      # bug 9ce2a68b: the released agent image binary is /agent (scratch image,
-      # see exe-monitor internal/dockerfile_agent), NOT /app/beszel-agent. The
-      # binary-native `/agent health` checks the freshness of the agent's health
-      # file, which only stays fresh while it is actively reporting to the hub.
-      test: ["CMD", "/agent", "health"]
+      # COUPLED TO THE PINNED AGENT IMAGE GENERATION — change both together.
+      #
+      # Two agent image generations exist with DIFFERENT binary paths:
+      #   v0.9.4 and earlier        -> /app/beszel-agent  (has a shell)
+      #   v2026.08.09-*-stamped     -> /agent             (scratch, NO shell)
+      #
+      # bug 9ce2a68b moved this to `/agent health` for the stamped generation.
+      # The stack manifest pins the v0.9.4 generation (the stamped monitor
+      # rollout in stack 0.9.34 was attempted 3x on exe-db-jkt and rolled back
+      # every time), so the check must address /app/beszel-agent again.
+      #
+      # A generation-agnostic check is NOT possible: the stamped image is
+      # scratch, so there is no shell for a `a || b` fallback and no
+      # wget/curl for a port probe. Docker healthchecks execute inside the
+      # container, so the check can only use binaries the image ships.
+      #
+      # If this mismatches the pinned image the container is permanently
+      # unhealthy from the first recreate. Observed live on exe-db-jkt
+      # 2026-08-10 08:13-08:40, every 30s:
+      #   Health check ... error: OCI runtime exec failed: exec: "/agent":
+      #   stat /agent: no such file or directory
+      #
+      # The binary-native `health` subcommand checks the freshness of the
+      # agent's health file, which only stays fresh while it is actively
+      # reporting to the hub.
+      test: ["CMD", "/app/beszel-agent", "health"]
       interval: 30s
       timeout: 5s
       start_period: 30s
@@ -884,7 +1068,7 @@ services:
   # Without a token the binary exits 0 (no crash-loop). (bug 3416cead)
   # ------------------------------------------------------------------
   exe-update:
-    image: ${EXE_OS_IMAGE_TAG:-${EXED_IMAGE_TAG:-ghcr.io/askexe/exe-os:v0.9.311}}
+    image: ${EXE_OS_IMAGE_TAG:-${EXED_IMAGE_TAG:-ghcr.io/askexe/exe-os:v0.9.311@sha256:011730042f55277724dbe83fde1a6416db2f3e8bf62d3254738d68d8de33e1f9}}
     container_name: exe-update
     profiles: ["registry-proxy", "askexe-control-plane"]
     restart: unless-stopped
@@ -983,9 +1167,16 @@ services:
       # Probe an app subdomain so the gate's server block (not the default 404)
       # answers. Any 2xx/3xx from the edge proves it is serving.
       # bug f1e79d3b: nginx:alpine ships BusyBox wget, which does NOT support
-      # --max-redirect — that flag made the probe error out. Drop it and follow
-      # the unauthenticated 302 to a 2xx; either way wget exits 0 when served.
-      test: ["CMD", "wget", "-qO-", "--header=Host: crm.${DOMAIN}", "http://127.0.0.1:80/"]
+      # --max-redirect — that flag made the probe error out.
+      # Follow-up: probing "/" on a gated vhost cannot work either. Anonymous "/"
+      # is exactly what the gate 302s to auth.<domain>, and BusyBox wget FOLLOWS
+      # redirects with no way to cap them, so the probe chases the login funnel
+      # and dies with "wget: too many redirections" — the edge is serving
+      # correctly but reports unhealthy (seen live on askexe.com once crm was
+      # routed through the edge). Probe the crm vhost's EXEMPT /healthz instead:
+      # it never redirects and it proves vhost selection + gate exemption + the
+      # CRM upstream in one request.
+      test: ["CMD", "wget", "-qO-", "--header=Host: crm.${DOMAIN}", "http://127.0.0.1:80/healthz"]
       interval: 30s
       timeout: 5s
       retries: 3
@@ -1086,7 +1277,7 @@ services:
   # 4 services: gunicorn API, websocket, RQ worker, scheduler.
 
   exe-erp:
-    image: ${ERP_IMAGE_TAG:-ghcr.io/askexe/exe-erp:v0.2.2}
+    image: ${ERP_IMAGE_TAG:-ghcr.io/askexe/exe-erp:v0.2.2@sha256:00fecc790ff848bfd4b7d87f42f859edfeb6090a7ca26bf2359dc6cb96767afb}
     container_name: exe-erp
     restart: unless-stopped
     entrypoint: ["/usr/local/bin/entrypoint.sh"]
@@ -1227,7 +1418,7 @@ services:
       options: { max-size: "10m", max-file: "3" }
 
   exe-erp-websocket:
-    image: ${ERP_IMAGE_TAG:-ghcr.io/askexe/exe-erp:v0.2.2}
+    image: ${ERP_IMAGE_TAG:-ghcr.io/askexe/exe-erp:v0.2.2@sha256:00fecc790ff848bfd4b7d87f42f859edfeb6090a7ca26bf2359dc6cb96767afb}
     container_name: exe-erp-websocket
     restart: unless-stopped
     entrypoint: []
@@ -1289,7 +1480,7 @@ services:
       options: { max-size: "10m", max-file: "3" }
 
   exe-erp-queue:
-    image: ${ERP_IMAGE_TAG:-ghcr.io/askexe/exe-erp:v0.2.2}
+    image: ${ERP_IMAGE_TAG:-ghcr.io/askexe/exe-erp:v0.2.2@sha256:00fecc790ff848bfd4b7d87f42f859edfeb6090a7ca26bf2359dc6cb96767afb}
     container_name: exe-erp-queue
     restart: unless-stopped
     entrypoint: []
@@ -1320,11 +1511,16 @@ services:
     networks:
       - backend
     healthcheck:
-      # Verify the bench worker process is alive and Redis queue is reachable.
-      # bug c8fb434f: pgrep is NOT in the Frappe image (exit 127) → permanent
-      # false-unhealthy. ps + grep are present; the [r] bracket avoids matching
-      # the grep process itself.
-      test: ["CMD-SHELL", "ps -ef | grep -q '[r]q worker'"]
+      # Liveness = the RQ worker process (PID 1) is still running.
+      # bug ed19883e: the slim Frappe base has NEITHER pgrep NOR ps/procps
+      # (exit 127 "not found") → the process-table probes were permanently
+      # false-unhealthy → 180s stack-update gate → rollback. Also `bench
+      # worker` runs the RQ worker in-process (frappe.utils.background_jobs
+      # .start_worker → Worker.work()); PID 1 argv stays "bench worker", so a
+      # `rq worker` grep would miss it even if ps existed. Use python (the
+      # image base is python:3.14-slim) to read PID 1's argv directly — this
+      # matches the exe-erp repo's own docker-compose.yml probe.
+      test: ["CMD-SHELL", "python -c \"import sys; cmd=open('/proc/1/cmdline','rb').read().replace(b'\\0', b' '); sys.exit(0 if b'bench worker' in cmd else 1)\""]
       interval: 30s
       timeout: 5s
       start_period: 30s
@@ -1338,7 +1534,7 @@ services:
       options: { max-size: "10m", max-file: "3" }
 
   exe-erp-scheduler:
-    image: ${ERP_IMAGE_TAG:-ghcr.io/askexe/exe-erp:v0.2.2}
+    image: ${ERP_IMAGE_TAG:-ghcr.io/askexe/exe-erp:v0.2.2@sha256:00fecc790ff848bfd4b7d87f42f859edfeb6090a7ca26bf2359dc6cb96767afb}
     container_name: exe-erp-scheduler
     restart: unless-stopped
     entrypoint: []
@@ -1369,11 +1565,13 @@ services:
     networks:
       - backend
     healthcheck:
-      # Verify the bench schedule process is alive.
-      # bug c8fb434f: pgrep is NOT in the Frappe image (exit 127) → permanent
-      # false-unhealthy. ps + grep are present; the [b] bracket avoids matching
-      # the grep process itself.
-      test: ["CMD-SHELL", "ps -ef | grep -q '[b]ench schedule'"]
+      # Liveness = the scheduler process (PID 1) is still running.
+      # bug ed19883e: the slim Frappe base has NEITHER pgrep NOR ps/procps
+      # (exit 127 "not found") → the process-table probe was permanently
+      # false-unhealthy → 180s stack-update gate → rollback. Use python (the
+      # image base is python:3.14-slim) to read PID 1's argv directly — this
+      # matches the exe-erp repo's own docker-compose.yml probe.
+      test: ["CMD-SHELL", "python -c \"import sys; cmd=open('/proc/1/cmdline','rb').read().replace(b'\\0', b' '); sys.exit(0 if b'bench schedule' in cmd else 1)\""]
       interval: 30s
       timeout: 5s
       start_period: 30s
@@ -1466,7 +1664,7 @@ services:
     # a fresh/migrated install boots an old image while the manifest reads "latest".
     # generate-env.ts now always writes AUTH_IMAGE_TAG, and this default mirrors the
     # pin as defense-in-depth — keep BOTH in lockstep on every auth release.
-    image: ${AUTH_IMAGE_TAG:-update.askexe.com/askexe/exe-auth:v0.2.0}
+    image: ${AUTH_IMAGE_TAG:-update.askexe.com/askexe/exe-auth:v0.5.0@sha256:ecc57f92b1f2c2d9df4fafe648622fe1fdd87c27012048d950e3f6b82086ccf9}
     container_name: exe-auth
     restart: unless-stopped
     environment:
@@ -1483,6 +1681,14 @@ services:
       AUTH_CORS_ORIGIN: ${AUTH_CORS_ORIGIN:-https://${DOMAIN}}
       AUTH_DEFAULT_REDIRECT: ${AUTH_DEFAULT_REDIRECT:-}
       AUTH_DEFAULT_PRODUCT: ${AUTH_DEFAULT_PRODUCT:-AUTH}
+      # Brand word rendered after the gold "EXE" in the login logo (exe-auth
+      # v0.5.0+). The auth gateway is ONE front door for the whole stack, so it
+      # carries one identity regardless of which product bounced the visitor
+      # here — ?product= no longer rebrands the page. Unset => the image
+      # defaults to INTELLIGENCE ("EXE INTELLIGENCE"); white-label deploys set
+      # AUTH_BRAND_NAME in .env. Passthrough is required or the .env value can
+      # never reach the container.
+      AUTH_BRAND_NAME: ${AUTH_BRAND_NAME:-}
       # Bug 5960ebb1: invite-only posture. Mirror GOTRUE_DISABLE_SIGNUP (which
       # blocks signup server-side) so the auth SPA hides its sign-up UI/route
       # instead of presenting a form that can only ever fail. Defaults true.