@askexenow/exe-os 0.9.373 → 0.9.376

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

@@ -10,7 +10,12 @@ DOMAIN=CHANGEME_DOMAIN
 # bug 8dc31733: EXE_DB_IMAGE overrides the Postgres image tag in compose.
 # The manifest declares env: "EXE_DB_IMAGE" — keep this in sync with the
 # stack manifest pin. Defaults to pgvector/pgvector:0.8.0-pg16 in compose.
-# EXE_DB_IMAGE=pgvector/pgvector:0.8.0-pg16
+EXE_DB_IMAGE=update.askexe.com/askexe/pgvector:0.8.0-pg16@sha256:a132765ec351c65111b5b675928a3a0515a466a40f97277329db8b8209ad8bc9
+
+# --- Observability ---
+# OTLP collector image. Compose carries no fallback default: a missing pin
+# ABORTS the deploy rather than substituting an old image.
+OTEL_COLLECTOR_IMAGE=update.askexe.com/askexe/otel-collector-contrib:0.114.0@sha256:37fa87091cfaaec7234a27e4e395a40c31c2bfaea97a349a4afef6d9e9681197
 POSTGRES_USER=exe
 POSTGRES_PASSWORD=CHANGEME_POSTGRES_PASSWORD
 POSTGRES_DB=exedb
@@ -33,7 +38,12 @@ GOTRUE_EXTERNAL_URL=https://auth.CHANGEME_DOMAIN
 # tokens are rejected as iss-mismatch. Keep equal to GOTRUE_EXTERNAL_URL.
 GOTRUE_JWT_ISSUER=https://auth.CHANGEME_DOMAIN
 # SSO redirect allow-list (bug 66f8e10a) — app origins for unified SSO.
-GOTRUE_URI_ALLOW_LIST=https://crm.CHANGEME_DOMAIN,https://wiki.CHANGEME_DOMAIN,https://erp.CHANGEME_DOMAIN
+# Must list EVERY origin the SPA can redirect back to, including the opt-in
+# dashboard: dashboard-page sends ?redirect=https://dashboard.<domain> through
+# auth, and GoTrue rejects any redirect_to that is not on this list. Kept in
+# lockstep with generate-env.ts and .env.example — a customer who enables the
+# dashboard profile must not have to discover this entry themselves.
+GOTRUE_URI_ALLOW_LIST=https://crm.CHANGEME_DOMAIN,https://wiki.CHANGEME_DOMAIN,https://erp.CHANGEME_DOMAIN,https://dashboard.CHANGEME_DOMAIN,https://gateway.CHANGEME_DOMAIN
 # Bug 0327b017: parent-domain session cookie → shared across all subdomains.
 GOTRUE_COOKIE_DOMAIN=.CHANGEME_DOMAIN
 GOTRUE_COOKIE_KEY=exe-auth
@@ -48,10 +58,18 @@ SMTP_PORT=587
 SMTP_USER=
 SMTP_PASS=
 
+# --- Dashboard (exe-dashboard — customer dashboard at dashboard.<domain>) ---
+# OPT-IN: the exe-dashboard compose service sits behind `profiles: [dashboard]`.
+# No default is written here on purpose — the pin comes from the signed stack
+# manifest (services.dashboard.image), so .env stays derived rather than
+# becoming a competing source of truth that outranks it once it goes stale.
+#DASHBOARD_IMAGE_TAG=update.askexe.com/askexe/exe-dashboard:vX.Y.Z@sha256:...
+#DASHBOARD_PORT=3301
+
 # --- 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.5.0
+AUTH_IMAGE_TAG=update.askexe.com/askexe/exe-auth:v0.6.1@sha256:89670a15bc59255299be695525863e66f949694eec1dd8886038dc3659a4a941
 # 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
@@ -106,7 +124,7 @@ EXE_ORG_ID=
 EXE_ORG_WORKSPACE_ID=
 
 # --- CRM ---
-CRM_IMAGE_TAG=update.askexe.com/askexe/exe-crm:v0.9.51
+CRM_IMAGE_TAG=update.askexe.com/askexe/exe-crm:v0.9.53@sha256:a586dcc8bbd992538e3caa18c44e772d30f31155dfef0a2b7466ca3fc7c553d8
 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
@@ -120,7 +138,7 @@ 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_IMAGE_TAG=update.askexe.com/askexe/exe-wiki:v0.9.28@sha256:61856a4c6b97ce62c62ecdc3a377139287be5860eb807d9fbb737115758d7856
 # 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
@@ -131,7 +149,22 @@ WIKI_IMAGE_TAG=update.askexe.com/askexe/exe-wiki:v0.9.26
 # 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
+# Bugs bed3cb4a / c604df37 — see deploy/compose/docker-compose.yml's exe-wiki
+# environment block for the full rationale. pgvector reuses this same
+# exe-db instance; native runs in-process (no API key, no exe-os MCP daemon).
+WIKI_VECTOR_DB=pgvector
+# bug bed3cb4a / corrected 2026-08-31 (founder direction): wiki's RAG/chat
+# uses GLM via Z.ai directly (exe-wiki PR #78's real, verified `zai`
+# provider) — not Anthropic through exe-gateway. Supply ZAI_API_KEY to match.
+WIKI_LLM_PROVIDER=zai
+ZAI_MODEL_PREF=glm-4.6
+ZAI_BASE_PATH=https://api.z.ai/api/coding/paas/v4
+# exe-gateway's /v1/messages authenticates via an exe_sk_* billing API key
+# (exe-gateway src/api-keys.ts), provisioned per-customer through
+# dashboard.askexe.com — it cannot be generated here. Chat/RAG will fail
+# ("No Anthropic API key was set") until this is set.
+# SET_MANUALLY
+WIKI_ANTHROPIC_API_KEY=CHANGEME_WIKI_ANTHROPIC_API_KEY
 WIKI_AUTH_TOKEN=CHANGEME_WIKI_AUTH_TOKEN
 WIKI_JWT_SECRET=CHANGEME_WIKI_JWT_SECRET
 WIKI_SIG_KEY=CHANGEME_WIKI_SIG_KEY
@@ -143,7 +176,7 @@ WIKI_HOST_PORT=3001
 EXE_SSO_COOKIE_NAME=exe_access_token
 
 # --- exe-os ---
-EXE_OS_IMAGE_TAG=update.askexe.com/askexe/exe-os:v0.9.311
+EXE_OS_IMAGE_TAG=update.askexe.com/askexe/exe-os:v0.9.324@sha256:3ce6406e0f7f279ff2568bbbb7d55de51a46fdf35c49691f24fd959d6fd2d3fa
 EXED_MCP_TOKEN=CHANGEME_EXED_MCP_TOKEN
 EXED_DEVICE_ID=CHANGEME_DEVICE_ID
 EXE_MCP_HOST_BIND=127.0.0.1
@@ -153,7 +186,7 @@ EXE_MCP_HOST_PORT=48739
 EXE_CLOUD_SYNC_TO_POSTGRES=true
 
 # --- ERP (Frappe/ERPNext fork) ---
-ERP_IMAGE_TAG=update.askexe.com/askexe/exe-erp:v0.2.2
+ERP_IMAGE_TAG=update.askexe.com/askexe/exe-erp:v2026.08.07-d185286-stamped@sha256:1c655f3f7819c797afd13c79561354f0276cf337403f32aee3e406a497e8827b
 # Administrator password for the ERPNext site (created on first boot).
 # bug 43854b31: this only applies at FIRST boot. To rotate it later you must also
 # run `bench --site $ERP_SITE_NAME set-admin-password <new>` inside exe-erp —
@@ -169,7 +202,7 @@ ERP_WS_PORT=9069
 ERP_SENTRY_DSN=
 
 # --- Gateway ---
-GATEWAY_IMAGE_TAG=update.askexe.com/askexe/exe-gateway:v0.9.24
+GATEWAY_IMAGE_TAG=update.askexe.com/askexe/exe-gateway:v2026.08.07-c15f093-stamped@sha256:1bc11a2a0ad1f3929d59d2685696f22a72042b9fca9c75e15c02dc7d3c640105
 EXE_GATEWAY_AUTH_TOKEN=CHANGEME_EXE_GATEWAY_AUTH_TOKEN
 EXE_GATEWAY_WS_RELAY_AUTH_TOKEN=CHANGEME_EXE_GATEWAY_WS_RELAY_AUTH_TOKEN
 EXE_GATEWAY_WHATSAPP_VERIFY_TOKEN=CHANGEME_EXE_GATEWAY_WHATSAPP_VERIFY_TOKEN
@@ -190,7 +223,7 @@ CRM_GRAPHQL_URL=http://exe-crm:3000/graphql
 # bug 633995f1: v0.9.5 is a QUARANTINED build that crashloops on any existing
 # deployment; v0.9.4 is the last known-good generation and matches the signed
 # apps manifest. See deploy/known-bad-images.json.
-MONITOR_HUB_IMAGE_TAG=update.askexe.com/askexe/exe-monitor-hub:v0.9.4
+MONITOR_HUB_IMAGE_TAG=update.askexe.com/askexe/exe-monitor-hub:v2026.08.09-10660eb4-stamped@sha256:c9a9218c2713b8dffea7e1cf8c0702a614657d311a7a4e821c6a543bab29bb97
 MONITOR_HUB_PORT=8090
 # Bootstrap superuser created on first start. Use your admin email + a strong password.
 # After first boot these values are no longer used (stored in pb_data volume).
@@ -224,7 +257,7 @@ GATEWAY_ALERT_URL=http://exe-gateway:3100/api/alerts/error-spike
 # Full scope details: deploy/monitor/HOST-ACCESS-CONSENT.md
 # COMPOSE_PROFILES=monitor-agent
 # bug 633995f1 / 9ce2a68b: the agent healthcheck is coupled to this generation.
-MONITOR_AGENT_IMAGE_TAG=update.askexe.com/askexe/exe-monitor-agent:v0.9.4
+MONITOR_AGENT_IMAGE_TAG=update.askexe.com/askexe/exe-monitor-agent:v2026.08.09-10660eb4-stamped@sha256:29fbd445f79484df04f000603e4ff445e76f0380f86d687a0033e3a0ef7d1b7a
 # Reports to the local hub. Auto-populated by `exe-os stack-update` during bootstrap.
 MONITOR_HUB_URL=http://exe-monitor-hub:8090
 # bug dacf0042: TOKEN and KEY MUST start EMPTY (the safe "unpaired" state) — NOT a

package/deploy/compose/.env.example

@@ -76,11 +76,26 @@ SMTP_PORT=587
 SMTP_USER=
 SMTP_PASS=
 
+# --- Dashboard (exe-dashboard — customer dashboard at dashboard.<domain>) ---
+# OPT-IN: the exe-dashboard compose service sits behind `profiles: [dashboard]`
+# and is off unless you run `docker compose --profile dashboard ...`.
+# DELIBERATELY UNSET AND COMMENTED OUT. Unlike the older *_IMAGE_TAG lines
+# above/below, this one carries no hardcoded literal: a pinned default here is
+# a second source of truth that silently outranks the manifest the moment it
+# goes stale. Take the value from the signed stack manifest
+# (deploy/stack-manifests/v0.9.json -> services.dashboard.image), digest and all.
+# Leave it unset and compose refuses the dashboard loudly ("has neither an image
+# nor a build context specified") instead of booting something arbitrary.
+#DASHBOARD_IMAGE_TAG=update.askexe.com/askexe/exe-dashboard:vX.Y.Z@sha256:...
+# Host port for the dashboard container (bound to 127.0.0.1; the tunnel and the
+# SSO edge reach it over the docker network, not this port).
+#DASHBOARD_PORT=3301
+
 # --- 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. exe-auth
 # ships only from the private update.askexe.com registry (no GHCR mirror).
-AUTH_IMAGE_TAG=update.askexe.com/askexe/exe-auth:v0.5.0
+AUTH_IMAGE_TAG=update.askexe.com/askexe/exe-auth:v0.6.1@sha256:89670a15bc59255299be695525863e66f949694eec1dd8886038dc3659a4a941
 # 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
@@ -140,7 +155,7 @@ EXE_ORG_ID=
 EXE_ORG_WORKSPACE_ID=
 
 # --- CRM ---
-CRM_IMAGE_TAG=ghcr.io/askexe/exe-crm:v0.9.51
+CRM_IMAGE_TAG=ghcr.io/askexe/exe-crm:v0.9.53@sha256:a586dcc8bbd992538e3caa18c44e772d30f31155dfef0a2b7466ca3fc7c553d8
 CRM_SERVER_URL=https://crm.CHANGEME_DOMAIN
 CRM_APP_SECRET=CHANGEME_CRM_APP_SECRET
 EXE_CRM_ADMIN_TOKEN=CHANGEME_EXE_CRM_ADMIN_TOKEN
@@ -153,7 +168,7 @@ EXE_CRM_ADMIN_EMAIL=CHANGEME_ADMIN_EMAIL
 CRM_HOST_PORT=3000
 
 # --- Wiki ---
-WIKI_IMAGE_TAG=ghcr.io/askexe/exe-wiki:v0.9.26
+WIKI_IMAGE_TAG=ghcr.io/askexe/exe-wiki:v0.9.28@sha256:61856a4c6b97ce62c62ecdc3a377139287be5860eb807d9fbb737115758d7856
 # 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
@@ -164,7 +179,22 @@ WIKI_IMAGE_TAG=ghcr.io/askexe/exe-wiki:v0.9.26
 # 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
+# Bugs bed3cb4a / c604df37 — see deploy/compose/docker-compose.yml's exe-wiki
+# environment block for the full rationale. pgvector reuses this same
+# exe-db instance; native runs in-process (no API key, no exe-os MCP daemon).
+WIKI_VECTOR_DB=pgvector
+# bug bed3cb4a / corrected 2026-08-31 (founder direction): wiki's RAG/chat
+# uses GLM via Z.ai directly (exe-wiki PR #78's real, verified `zai`
+# provider) — not Anthropic through exe-gateway. Supply ZAI_API_KEY to match.
+WIKI_LLM_PROVIDER=zai
+ZAI_MODEL_PREF=glm-4.6
+ZAI_BASE_PATH=https://api.z.ai/api/coding/paas/v4
+# exe-gateway's /v1/messages authenticates via an exe_sk_* billing API key
+# (exe-gateway src/api-keys.ts), provisioned per-customer through
+# dashboard.askexe.com — it cannot be generated here. Chat/RAG will fail
+# ("No Anthropic API key was set") until this is set.
+# SET_MANUALLY
+WIKI_ANTHROPIC_API_KEY=CHANGEME_WIKI_ANTHROPIC_API_KEY
 WIKI_AUTH_TOKEN=CHANGEME_WIKI_AUTH_TOKEN
 EXE_WIKI_ADMIN_TOKEN=CHANGEME_EXE_WIKI_ADMIN_TOKEN
 WIKI_JWT_SECRET=CHANGEME_WIKI_JWT_SECRET
@@ -176,7 +206,12 @@ WIKI_HOST_PORT=3001
 EXE_SSO_COOKIE_NAME=exe_access_token
 
 # --- exe-os ---
-EXE_OS_IMAGE_TAG=ghcr.io/askexe/exe-os:v0.9.311
+EXE_OS_IMAGE_TAG=ghcr.io/askexe/exe-os:v0.9.324@sha256:3ce6406e0f7f279ff2568bbbb7d55de51a46fdf35c49691f24fd959d6fd2d3fa
+
+# Infra image pins — manifest-derived. Compose has no fallback default for
+# these: a missing pin ABORTS the deploy instead of substituting an old image.
+EXE_DB_IMAGE=update.askexe.com/askexe/pgvector:0.8.0-pg16@sha256:a132765ec351c65111b5b675928a3a0515a466a40f97277329db8b8209ad8bc9
+OTEL_COLLECTOR_IMAGE=update.askexe.com/askexe/otel-collector-contrib:0.114.0@sha256:37fa87091cfaaec7234a27e4e395a40c31c2bfaea97a349a4afef6d9e9681197
 EXED_MCP_TOKEN=CHANGEME_EXED_MCP_TOKEN
 EXED_DEVICE_ID=vps-default
 EXE_MCP_HOST_BIND=127.0.0.1
@@ -186,7 +221,7 @@ EXE_MCP_HOST_PORT=48739
 EXE_CLOUD_SYNC_TO_POSTGRES=true
 
 # --- Gateway ---
-GATEWAY_IMAGE_TAG=ghcr.io/askexe/exe-gateway:v0.9.24
+GATEWAY_IMAGE_TAG=ghcr.io/askexe/exe-gateway:v2026.08.07-c15f093-stamped@sha256:1bc11a2a0ad1f3929d59d2685696f22a72042b9fca9c75e15c02dc7d3c640105
 EXE_GATEWAY_AUTH_TOKEN=CHANGEME_EXE_GATEWAY_AUTH_TOKEN
 EXE_GATEWAY_WS_RELAY_AUTH_TOKEN=CHANGEME_EXE_GATEWAY_WS_RELAY_AUTH_TOKEN
 EXE_GATEWAY_WHATSAPP_VERIFY_TOKEN=CHANGEME_EXE_GATEWAY_WHATSAPP_VERIFY_TOKEN
@@ -226,7 +261,7 @@ ERROR_REPORTING_ENABLED=true
 MONITOR_ERROR_URL=http://exe-monitor-hub:8090/api/exe-monitor/errors
 
 # --- ERP (optional — Exe ERP, Frappe/ERPNext fork) ---
-ERP_IMAGE_TAG=ghcr.io/askexe/exe-erp:v0.2.2
+ERP_IMAGE_TAG=ghcr.io/askexe/exe-erp:v2026.08.07-d185286-stamped@sha256:1c655f3f7819c797afd13c79561354f0276cf337403f32aee3e406a497e8827b
 ERP_ADMIN_PASSWORD=CHANGEME_ERP_ADMIN_PASSWORD
 EXE_ERP_ADMIN_TOKEN=CHANGEME_EXE_ERP_ADMIN_TOKEN
 # Frappe site name — must match the erp.<domain> the customer serves (bug e61ad373).
@@ -248,7 +283,7 @@ EXE_BUILD_HTTP_PORT=9222
 # data dir and entrypoint all changed) and crashloops on any existing
 # deployment. v0.9.4 is the last known-good generation and is what the signed
 # apps manifest pins. See deploy/known-bad-images.json.
-MONITOR_HUB_IMAGE_TAG=ghcr.io/askexe/exe-monitor-hub:v0.9.4
+MONITOR_HUB_IMAGE_TAG=ghcr.io/askexe/exe-monitor-hub:v2026.08.09-10660eb4-stamped@sha256:c9a9218c2713b8dffea7e1cf8c0702a614657d311a7a4e821c6a543bab29bb97
 MONITOR_HUB_PORT=8090
 # Bootstrap superuser created on first start. Use your admin email + a strong password.
 # After first boot these values are no longer used (stored in pb_data volume).
@@ -268,7 +303,7 @@ MONITOR_HUB_ADMIN_PASSWORD=CHANGEME_MONITOR_HUB_ADMIN_PASSWORD
 # COMPOSE_PROFILES=monitor-agent
 # bug 633995f1 / 9ce2a68b: keep the agent on the v0.9.4 generation — the
 # compose healthcheck (`/app/beszel-agent health`) is coupled to it.
-MONITOR_AGENT_IMAGE_TAG=ghcr.io/askexe/exe-monitor-agent:v0.9.4
+MONITOR_AGENT_IMAGE_TAG=ghcr.io/askexe/exe-monitor-agent:v2026.08.09-10660eb4-stamped@sha256:29fbd445f79484df04f000603e4ff445e76f0380f86d687a0033e3a0ef7d1b7a
 # Reports to the local hub. Auto-populated by `exe-os stack-update` during bootstrap.
 MONITOR_HUB_URL=http://exe-monitor-hub:8090
 # bug dacf0042: TOKEN and KEY MUST start EMPTY (the safe "unpaired" state) —

package/deploy/compose/docker-compose.yml

@@ -29,7 +29,7 @@ services:
     # bug ee16e7ef: pin a versioned tag, not the mutable :pg16 rolling tag.
     # pgvector/pgvector:pg16 can change upstream without notice; 0.8.0-pg16
     # is the tested stable release. Override via EXE_DB_IMAGE in .env.
-    image: ${EXE_DB_IMAGE:-pgvector/pgvector:0.8.0-pg16@sha256:a132765ec351c65111b5b675928a3a0515a466a40f97277329db8b8209ad8bc9}
+    image: ${EXE_DB_IMAGE:?EXE_DB_IMAGE must be set from the signed stack manifest (digest-pinned) — refusing to fall back to a stale hard-coded image}
     container_name: exe-db
     restart: unless-stopped
     # SECURITY (bug 67d62490): no blanket `env_file: .env`. Each service
@@ -278,7 +278,7 @@ services:
     # is what the signed apps manifest (deploy/stack-manifests/v0.9.30-apps.json)
     # and exe-monitor's own stack.release.json pin. Do not reintroduce the bad
     # digest.
-    image: ${MONITOR_HUB_IMAGE_TAG:-ghcr.io/askexe/exe-monitor-hub:v0.9.4@sha256:d593bec5a4b248388d0d85353fae1ba8f93cab628a03833aa79acd0632fd11cb}
+    image: ${MONITOR_HUB_IMAGE_TAG:?MONITOR_HUB_IMAGE_TAG must be set from the signed stack manifest (digest-pinned) — refusing to fall back to a stale hard-coded image}
     container_name: exe-monitor-hub
     restart: unless-stopped
     # bug d3d49101 / 1fdb8be9: PocketBase's data dir for this hub is a RELATIVE
@@ -360,7 +360,7 @@ services:
   # ------------------------------------------------------------------
 
   exe-crm:
-    image: ${CRM_IMAGE_TAG:-ghcr.io/askexe/exe-crm:v0.9.51@sha256:73864ce14aaac06b73d67100bbf88e669fd13c7da39edd9644107037211559b7}
+    image: ${CRM_IMAGE_TAG:?CRM_IMAGE_TAG must be set from the signed stack manifest (digest-pinned) — refusing to fall back to a stale hard-coded image}
     container_name: exe-crm
     restart: unless-stopped
     # bug ad4471ad: NO compose `command` override. The image entrypoint
@@ -467,6 +467,13 @@ services:
       STORAGE_TYPE: local
       STORAGE_LOCAL_PATH: /app/.local-storage
       BRANDING_CONFIG_PATH: /app/branding.json
+      # Bug 2355a199 / exe-crm PR #125: exe-crm sits behind two hops of reverse
+      # proxy (cloudflared -> exe-sso-edge -> exe-crm), so the raw peer address
+      # Node sees is exe-sso-edge, not the real client. Without telling the app
+      # how many trusted hops to peel off X-Forwarded-For, rate limiting keys on
+      # the wrong address (the edge, shared by every request) instead of the
+      # actual client.
+      EXE_TRUSTED_PROXY_HOPS: "2"
     ports:
       - "127.0.0.1:${CRM_HOST_PORT:-3000}:3000"
     volumes:
@@ -486,7 +493,7 @@ services:
       options: { max-size: "10m", max-file: "3" }
 
   exe-crm-worker:
-    image: ${CRM_IMAGE_TAG:-ghcr.io/askexe/exe-crm:v0.9.51@sha256:73864ce14aaac06b73d67100bbf88e669fd13c7da39edd9644107037211559b7}
+    image: ${CRM_IMAGE_TAG:?CRM_IMAGE_TAG must be set from the signed stack manifest (digest-pinned) — refusing to fall back to a stale hard-coded image}
     container_name: exe-crm-worker
     restart: unless-stopped
     command: ["yarn", "worker:prod"]
@@ -552,7 +559,7 @@ services:
   # 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}
+    image: ${EXE_DB_IMAGE:?EXE_DB_IMAGE must be set from the signed stack manifest (digest-pinned) — refusing to fall back to a stale hard-coded image}
     container_name: exe-wiki-schema-guard
     restart: "no"
     depends_on:
@@ -588,7 +595,7 @@ services:
       options: { max-size: "10m", max-file: "3" }
 
   exe-wiki:
-    image: ${WIKI_IMAGE_TAG:-ghcr.io/askexe/exe-wiki:v0.9.26@sha256:c0d61d183b274a67977fdfb1b40d5e4736559a9d90507843183e5642da2a959d}
+    image: ${WIKI_IMAGE_TAG:?WIKI_IMAGE_TAG must be set from the signed stack manifest (digest-pinned) — refusing to fall back to a stale hard-coded image}
     container_name: exe-wiki
     restart: unless-stopped
     # Wiki uses Prisma — runs migrate on boot via built-in entrypoint.
@@ -684,25 +691,78 @@ services:
       JWT_SECRET: ${WIKI_JWT_SECRET:?WIKI_JWT_SECRET is required}
       SIG_KEY: ${WIKI_SIG_KEY:?WIKI_SIG_KEY is required}
       SIG_SALT: ${WIKI_SIG_SALT:?WIKI_SIG_SALT is required}
-      # Embeddings (bug 49221421): in the current wiki build the ONLY functional
-      # embedding path is the exeOsMcp vector provider, which spawns the exe-os
-      # MCP daemon over stdio and owns vectorization. The pgvector/postgres path
-      # relies on an inert embedder shim and silently produces NO vectors, so it
-      # must NOT be the default. We default the wiki to exeOsMcp + native and
-      # wire the stdio spawn command below so embeddings actually work. If an
-      # operator overrides WIKI_VECTOR_DB to a non-mcp engine while leaving
-      # EMBEDDING_ENGINE=native and no MCP command, the wiki now FAILS LOUD at
-      # boot (see server/utils/boot/productionEnv.js) instead of silent no-op.
-      VECTOR_DB: ${WIKI_VECTOR_DB:-exeOsMcp}
+      # Embeddings + vector DB (bugs bed3cb4a, c604df37). This used to default to
+      # exeOsMcp + native, on the assumption that exeOsMcp was the only functional
+      # embedding path. Two things changed that:
+      #   1. exe-wiki PR #78 ("revive the embedding pipeline, unbreak pgvector
+      #      retrieval", merged 2026-08-31) restored the real EMBEDDING_ENGINE
+      #      switch in getEmbeddingEngineSelection() (it had been reduced to an
+      #      unconditional exeOsMcp shim) and fixed pgvector's table-schema
+      #      resolution (server/utils/vectorDbProviders/pgvector). native + pgvector
+      #      is now the wiki's own documented default (docker/.env.example) and a
+      #      genuinely self-contained combo: native runs @xenova/transformers
+      #      in-process — no API key, no exe-os MCP daemon, no separate database.
+      #   2. bug c604df37: the exeOsMcp path was never actually reachable in
+      #      production. server/utils/vectorDbProviders/exeOsMcpClient spawns
+      #      `npx @askexenow/exe-os@<pin> mcp`, but in exe-os `args[0] === "mcp"`
+      #      (src/bin/cli.ts) routes to the Claude Code MCP config-manager CLI
+      #      (src/bin/exe-mcp.ts), not the JSON-RPC stdio server
+      #      (src/mcp/server.ts, exposed only as a package export with no bin
+      #      entry). The handshake never completes and every embed call no-ops.
+      # Default to pgvector so a fresh deploy actually vectorizes documents.
+      # exeOsMcp remains selectable via WIKI_VECTOR_DB for an operator who fixes
+      # the client-side routing bug above first.
+      VECTOR_DB: ${WIKI_VECTOR_DB:-pgvector}
       EMBEDDING_ENGINE: ${WIKI_EMBEDDING_ENGINE:-native}
-      # stdio spawn of the exe-os MCP server. The wiki client only supports
-      # stdio transport today (HTTP to the exe-os service is not wired yet), so
-      # the wiki runs its own pinned exe-os MCP subprocess for embedding.
-      # bug 8d084f7c: PIN the exe-os npm version. An unversioned `npx
-      # @askexenow/exe-os` resolves to whatever "latest" is at boot, so a customer
-      # could silently run a different MCP build than the rest of the stack (and
-      # offline boots fail). WIKI_EXE_OS_NPM_VERSION defaults to the stack's
-      # pinned exe-os npm version and is threaded into the spawn args.
+      # pgvector reuses the SAME exe-db Postgres instance the wiki's own
+      # DATABASE_URL points at — exe-db already runs pgvector/pgvector:pg16 (see
+      # the exe-db image comment above), so `CREATE EXTENSION IF NOT EXISTS
+      # vector` in server/utils/vectorDbProviders/pgvector/index.js succeeds with
+      # no separate database or extra service to provision.
+      #
+      # NOTE this is NOT the same shape as DATABASE_URL above: PGVECTOR_CONNECTION_STRING
+      # is handed straight to the `pg` client, not Prisma, so it does not understand
+      # a `?schema=` query param (Prisma-only syntax) — it is deliberately omitted.
+      # pgvector resolves its own table (default name `exe-wiki_vectors`, see
+      # PGVECTOR_TABLE_NAME) through the connection's default search_path, i.e. the
+      # same `public` schema the wiki's own Prisma tables live in (WIKI_DB_SCHEMA
+      # above). See server/utils/vectorDbProviders/pgvector/SETUP.md for the
+      # provider's own setup notes.
+      PGVECTOR_CONNECTION_STRING: ${WIKI_PGVECTOR_CONNECTION_STRING:-postgres://${POSTGRES_USER:-exe}:${POSTGRES_PASSWORD:?POSTGRES_PASSWORD is required}@exe-db:5432/${POSTGRES_DB:-exedb}?sslmode=disable}
+      # LLM provider (bug bed3cb4a, corrected per founder direction 2026-08-31:
+      # wiki's RAG/chat must use GLM, not Anthropic-via-gateway).
+      #
+      # A fresh deploy shipped NO LLM_PROVIDER at all, so AnythingLLM's
+      # getLLMProvider() fell back to the OpenAI provider, which throws "No
+      # OpenAI API key was set" on every chat/RAG request. exe-wiki PR #78 added
+      # a real, working `zai` provider directly (no gateway hop needed — GLM/Z.ai
+      # exposes its own OpenAI-Messages-compatible endpoint that the wiki client
+      # speaks natively), verified end-to-end against a real uploaded PDF
+      # including a negative control (correctly declines to answer an
+      # out-of-corpus question rather than hallucinating). Use that.
+      #
+      # An earlier draft of this config pointed wiki at exe-gateway with
+      # LLM_PROVIDER=anthropic instead, reasoning that the gateway only speaks
+      # the Anthropic Messages protocol. That reasoning is correct AS FAR AS THE
+      # GATEWAY GOES, but it's the wrong fix: it routes around wiki's own
+      # already-built, already-verified GLM integration instead of using it, and
+      # it does not match what the founder explicitly asked for. If exe-wiki
+      # ever needs to go through exe-gateway instead of calling Z.ai directly
+      # (e.g. for centralized billing/rate-limiting), that's a deliberate future
+      # change, not the default.
+      LLM_PROVIDER: ${WIKI_LLM_PROVIDER:-zai}
+      # Z.ai key is an account credential, not a generatable secret — left empty
+      # so the operator fills it in; compose reads it as ${ZAI_API_KEY:-} rather
+      # than failing closed. WARN-first check for this lives in generate-env.ts.
+      ZAI_API_KEY: ${ZAI_API_KEY:-}
+      ZAI_MODEL_PREF: ${ZAI_MODEL_PREF:-glm-4.6}
+      # bug 62ba51e9: default to the Coding Plan path (the entitlement we hold).
+      # ZAI_BASE_PATH is only honoured by a wiki image carrying exe-wiki PR #78;
+      # older images hardcode the PAYG path and will 1113 regardless of this.
+      ZAI_BASE_PATH: ${ZAI_BASE_PATH:-https://api.z.ai/api/coding/paas/v4}
+      # stdio spawn of the exe-os MCP server. Only used if WIKI_VECTOR_DB is
+      # overridden back to exeOsMcp — see bug c604df37 above before doing that;
+      # the spawn args below currently point at the wrong CLI entrypoint.
       EXE_OS_MCP_COMMAND: ${WIKI_EXE_OS_MCP_COMMAND:-npx}
       EXE_OS_MCP_ARGS: ${WIKI_EXE_OS_MCP_ARGS:--y @askexenow/exe-os@${WIKI_EXE_OS_NPM_VERSION:-0.9.324} mcp}
       BRANDING_CONFIG_PATH: /app/branding.json
@@ -728,7 +788,15 @@ 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@sha256:011730042f55277724dbe83fde1a6416db2f3e8bf62d3254738d68d8de33e1f9}}}
+    # FAIL-CLOSED PIN. The signed stack manifest is the single source of truth for
+    # this image; stack-update writes EXE_OS_IMAGE_TAG from it. The legacy aliases are
+    # kept so an older .env keeps working, and the chain terminates EMPTY on purpose:
+    # docker compose evaluates nested defaults eagerly, so `:?` inside a chain would
+    # fire even when an alias IS set. With no pin at all compose aborts with
+    # "has neither an image nor a build context specified" — loud, not a silent
+    # substitution of a stale hard-coded version (which is how auth nearly shipped a
+    # four-minor-version downgrade).
+    image: ${EXE_OS_SERVER_IMAGE_TAG:-${EXE_OS_IMAGE_TAG:-${EXED_IMAGE_TAG:-}}}
     container_name: exe-os
     restart: unless-stopped
     # bug debf4a39 / 93ddfa27: the daemon connects to exe-db at boot
@@ -847,7 +915,7 @@ services:
       options: { max-size: "10m", max-file: "3" }
 
   exe-gateway:
-    image: ${GATEWAY_IMAGE_TAG:-ghcr.io/askexe/exe-gateway:v0.9.24@sha256:9cda7c00d886b4ab16a3b88aa953aa45c991f2977084ea8532f55fcaf75e8f37}
+    image: ${GATEWAY_IMAGE_TAG:?GATEWAY_IMAGE_TAG must be set from the signed stack manifest (digest-pinned) — refusing to fall back to a stale hard-coded image}
     container_name: exe-gateway
     restart: unless-stopped
     # Gateway needs 45s to flush outbound queues + disconnect Baileys adapters.
@@ -1011,7 +1079,7 @@ services:
     # v0.9.5 default contradicted that healthcheck, so the agent was
     # permanently unhealthy from the first recreate. Matches the signed apps
     # manifest and exe-monitor's stack.release.json.
-    image: ${MONITOR_AGENT_IMAGE_TAG:-ghcr.io/askexe/exe-monitor-agent:v0.9.4@sha256:9ca4e75577b2ff2abb754140ccfaf8df19161bcef601faf37d1fce743fe814fc}
+    image: ${MONITOR_AGENT_IMAGE_TAG:?MONITOR_AGENT_IMAGE_TAG must be set from the signed stack manifest (digest-pinned) — refusing to fall back to a stale hard-coded image}
     container_name: exe-monitor-agent
     # Host-access consent gate: only starts when the operator has
     # acknowledged the host-access scope (COMPOSE_PROFILES=monitor-agent).
@@ -1116,7 +1184,15 @@ 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@sha256:011730042f55277724dbe83fde1a6416db2f3e8bf62d3254738d68d8de33e1f9}}
+    # FAIL-CLOSED PIN. The signed stack manifest is the single source of truth for
+    # this image; stack-update writes EXE_OS_IMAGE_TAG from it. The legacy aliases are
+    # kept so an older .env keeps working, and the chain terminates EMPTY on purpose:
+    # docker compose evaluates nested defaults eagerly, so `:?` inside a chain would
+    # fire even when an alias IS set. With no pin at all compose aborts with
+    # "has neither an image nor a build context specified" — loud, not a silent
+    # substitution of a stale hard-coded version (which is how auth nearly shipped a
+    # four-minor-version downgrade).
+    image: ${EXE_OS_IMAGE_TAG:-${EXED_IMAGE_TAG:-}}
     container_name: exe-update
     profiles: ["registry-proxy", "askexe-control-plane"]
     restart: unless-stopped
@@ -1205,6 +1281,8 @@ services:
       - ./sso-edge/default.conf.template:/etc/nginx/exe-templates/default.conf.template:ro
       - ./sso-edge/sso-redirect.conf:/etc/nginx/snippets/sso-redirect.conf:ro
       - ./sso-edge/entrypoint.sh:/docker-entrypoint.d/99-render-sso-edge.sh:ro
+      # Branded shared error pages (packages/exe-error-pages, vendored by its sync.mjs; bug 64324162).
+      - ./sso-edge/error-pages:/usr/share/nginx/html/error-pages:ro
     # nginx:alpine runs /docker-entrypoint.d/*.sh then `nginx -g 'daemon off;'`.
     # Our script renders the template from ${DOMAIN}; it does not exec nginx
     # itself (the base entrypoint does), so it ends after `nginx -t`.
@@ -1675,7 +1753,7 @@ services:
   exe-otel-collector:
     # bug 32d6e02f: digest-pinned default (was tag-only) — matches the
     # stack manifest pin for otel/opentelemetry-collector-contrib:0.114.0.
-    image: ${OTEL_COLLECTOR_IMAGE:-otel/opentelemetry-collector-contrib:0.114.0@sha256:37fa87091cfaaec7234a27e4e395a40c31c2bfaea97a349a4afef6d9e9681197}
+    image: ${OTEL_COLLECTOR_IMAGE:?OTEL_COLLECTOR_IMAGE must be set from the signed stack manifest (digest-pinned) — refusing to fall back to a stale hard-coded image}
     container_name: exe-otel-collector
     restart: unless-stopped
     command: ["--config=/etc/otelcol-contrib/config.yaml"]
@@ -1743,7 +1821,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.5.0@sha256:ecc57f92b1f2c2d9df4fafe648622fe1fdd87c27012048d950e3f6b82086ccf9}
+    image: ${AUTH_IMAGE_TAG:?AUTH_IMAGE_TAG must be set from the signed stack manifest (digest-pinned) — refusing to fall back to a stale hard-coded image}
     container_name: exe-auth
     restart: unless-stopped
     environment:
@@ -1813,6 +1891,79 @@ services:
       driver: json-file
       options: { max-size: "10m", max-file: "3" }
 
+  # ------------------------------------------------------------------
+  # Dashboard — customer dashboard at dashboard.yourdomain.com
+  # Static nginx image built from dashboard-page/ in the exe-os repo.
+  # ------------------------------------------------------------------
+  #
+  # WHY THIS IS HERE AT ALL (2026-08-20). exe-dashboard has been running in
+  # production for months WITHOUT a service in this file. Its only compose
+  # definition was dashboard-page/docker-compose.yml — a standalone side-car
+  # that carried `build: .` and a hardcoded `image: …:v0.1.0`, joined the
+  # external `exe-net` network, and answered the `upstream sso_dashboard`
+  # in sso-edge/default.conf.template. Nothing in the stack manifest could pin
+  # a service the stack compose did not define, which is exactly why the
+  # dashboard drifted three builds behind main with nobody able to see it.
+  # This entry makes it a first-class, manifest-governed stack service.
+  #
+  # OPT-IN VIA PROFILE. `profiles: ["dashboard"]` keeps this off for every
+  # existing deployment that has not opted in. That is deliberate and it is why
+  # the image pin uses the empty-default form and NOT the required-variable
+  # (colon-question-mark) form: compose interpolates the WHOLE file before it
+  # filters by profile (verified on Docker 28.5.1 — a required-variable
+  # reference inside an INACTIVE profile still aborts `docker compose config`),
+  # so that form here would break every customer who never asked for the
+  # dashboard. The empty terminator gets the same fail-loud
+  # behaviour exactly where it belongs: with the profile ACTIVE and the variable
+  # unset, compose refuses with `service "exe-dashboard" has neither an image nor
+  # a build context specified` instead of silently substituting a stale literal.
+  exe-dashboard:
+    image: ${DASHBOARD_IMAGE_TAG:-}
+    profiles: ["dashboard"]
+    container_name: exe-dashboard
+    restart: unless-stopped
+    environment:
+      # Customer apex domain — templates server_name, CSP and the SPA's API/auth
+      # URLs at container start via dashboard-page/docker-entrypoint.sh. Never
+      # falls back to askexe.com.
+      DOMAIN: ${DOMAIN:?DOMAIN is required — set to your customer apex domain (e.g. hygo.co)}
+      # Optional explicit overrides; each defaults to the matching *.${DOMAIN}.
+      DASH_DOMAIN: ${DASH_DOMAIN:-}
+      DASH_API_URL: ${DASH_API_URL:-}
+      DASH_AUTH_URL: ${DASH_AUTH_URL:-}
+      DASH_DASHBOARD_URL: ${DASH_DASHBOARD_URL:-}
+    ports:
+      - "127.0.0.1:${DASHBOARD_PORT:-3301}:80"
+    networks:
+      # `backend` so exe-sso-edge can resolve `exe-dashboard` for its
+      # `upstream sso_dashboard { server exe-dashboard:80; }`; `frontend` so the
+      # cloudflared tunnel can reach it. Same pair as exe-auth/exe-crm/exe-wiki.
+      #
+      # NOTE: exe-sso-edge deliberately does NOT list this service in its
+      # depends_on. The edge must keep starting on deployments that never enable
+      # the dashboard profile, and a depends_on would make the edge unstartable
+      # for them.
+      - backend
+      - frontend
+    healthcheck:
+      # dashboard-page/nginx.conf serves `location = /health` as a literal 200.
+      # This is the same URL the stack manifest's healthUrl names, so the deploy
+      # gate and the container agree on what "up" means. Before this existed,
+      # /health fell through to the SPA `location /` and returned the index page
+      # with a 200 — a probe that could not fail while nginx was running at all.
+      test: ["CMD", "wget", "--spider", "-q", "http://127.0.0.1/health"]
+      interval: 30s
+      timeout: 5s
+      start_period: 5s
+      retries: 3
+    deploy:
+      resources:
+        limits:
+          memory: 128M
+    logging:
+      driver: json-file
+      options: { max-size: "10m", max-file: "3" }
+
 # ------------------------------------------------------------------
 # Volumes
 # ------------------------------------------------------------------

package/deploy/compose/gateway-watchdog.sh

@@ -7,6 +7,10 @@
 #   chmod +x /opt/exe-stack/gateway-watchdog.sh
 #   crontab -l | { cat; echo "*/2 * * * * /opt/exe-stack/gateway-watchdog.sh 2>&1 | logger -t exe-gw-watchdog"; } | crontab -
 #
+#   Or via Ansible (preferred — this header alone was never enough; see bug
+#   b5b01c2d, part 2: the install line above documented here was never actually
+#   run on exe-db-jkt): import_tasks: deploy/ansible/tasks/gateway-watchdog-cron.yml
+#
 # ─────────────────────────────────────────────────────────────────────────────
 # BUG HISTORY (facd5078, P0)
 # ─────────────────────────────────────────────────────────────────────────────
@@ -54,12 +58,25 @@ COOLDOWN_SECS="${EXE_GATEWAY_WATCHDOG_COOLDOWN_SECS:-300}"
 STATE_DIR="${EXE_GATEWAY_WATCHDOG_STATE_DIR:-${STACK_DIR}/.gateway-watchdog}"
 STRIKE_FILE="${STATE_DIR}/strikes"
 LAST_RESTART_FILE="${STATE_DIR}/last-restart"
+LAST_RUN_FILE="${STATE_DIR}/last-run"
 
 mkdir -p "$STATE_DIR" 2>/dev/null || true
 
 ts() { date -u +"%Y-%m-%dT%H:%M:%SZ"; }
 log() { echo "[$(ts)] gateway-watchdog: $*"; }
 
+# Heartbeat: proves the cron entry is actually firing, independent of what the
+# probe finds. strikes/last-restart only update on specific outcomes, so a
+# process that stopped being scheduled would leave them looking unremarkable
+# forever. This file updates on EVERY invocation — same "a monitor going quiet
+# must be detectable" pattern as backup.sh's LAST_STATUS file. A stale
+# last-run (older than a few cron intervals) means the cron stopped firing,
+# not that the gateway is healthy.
+write_heartbeat() {
+  printf 'last_run=%s\nepoch=%s\n' "$(ts)" "$(date -u +%s)" > "$LAST_RUN_FILE" 2>/dev/null || true
+}
+trap write_heartbeat EXIT
+
 # Read a single KEY=VALUE from the stack .env WITHOUT sourcing it (the .env holds
 # many secrets and arbitrary values; sourcing could execute / mangle them).
 read_env() {