@askexenow/exe-os 0.9.361 → 0.9.364

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

@@ -69,7 +69,16 @@ 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

@@ -99,7 +99,16 @@ 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

@@ -376,6 +376,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}
@@ -460,17 +472,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}
     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 +544,32 @@ 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:-}
       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
@@ -983,9 +1063,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
@@ -1320,11 +1407,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
@@ -1369,11 +1461,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

package/deploy/compose/generate-env.ts

@@ -27,7 +27,11 @@ const CLICKHOUSE_USER = "exe";
 export const CRM_IMAGE_TAG = `${REGISTRY}/exe-crm:${CRM_RELEASE_TAG}`;
 const CRM_HOST_PORT = "3000";
 export const WIKI_IMAGE_TAG = `${REGISTRY}/exe-wiki:${WIKI_RELEASE_TAG}`;
-const WIKI_DB_SCHEMA = "wiki";
+// Bug 2a8d3003: the wiki's data lives in `public` and generated .env files must say
+// so. This constant used to be "wiki", which meant every freshly generated stack
+// pinned the wiki to an empty schema — Prisma bootstraps it silently rather than
+// erroring, so the wiki simply comes up with no users and no documents.
+const WIKI_DB_SCHEMA = "public";
 const WIKI_VECTOR_DB = "exeOsMcp";
 const WIKI_HOST_PORT = "3001";
 export const EXE_OS_IMAGE_TAG = `${REGISTRY}/exe-os:${EXED_RELEASE_TAG}`;
@@ -174,6 +178,15 @@ export function generateEnv(options: GenerateEnvOptions): string {
     "",
     "# --- Wiki ---",
     `WIKI_IMAGE_TAG=${WIKI_IMAGE_TAG}`,
+    "# 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=${WIKI_DB_SCHEMA}`,
     `WIKI_VECTOR_DB=${WIKI_VECTOR_DB}`,
     `WIKI_AUTH_TOKEN=${randomSecret(RANDOM_SECRET_48)}`,
@@ -428,6 +441,15 @@ export function generateExampleEnv(): string {
     "",
     "# --- Wiki ---",
     `WIKI_IMAGE_TAG=${WIKI_IMAGE_TAG}`,
+    "# 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=${WIKI_DB_SCHEMA}`,
     `WIKI_VECTOR_DB=${WIKI_VECTOR_DB}`,
     "WIKI_AUTH_TOKEN=CHANGEME_WIKI_AUTH_TOKEN",

package/deploy/compose/status.sh

@@ -47,6 +47,36 @@ docker exec exe-db psql -U exe -d exedb -c "SELECT schemaname, COUNT(*) as table
 
 echo ""
 
+# Bug 2a8d3003: which schema is the wiki ACTUALLY running against?
+# exe-wiki-schema-guard gates `docker compose up`, but compose dependencies are not
+# evaluated by `docker start exe-wiki` or by restart:unless-stopped after a reboot —
+# so a wiki can still come back on the wrong schema without the guard ever running.
+# This makes that visible on demand. Read from the LIVE container, never from .env:
+# a docker-compose.override.yml can rewrite DATABASE_URL and .env would not show it.
+echo "Wiki schema (bug 2a8d3003):"
+WIKI_URL=$(docker inspect exe-wiki --format '{{range .Config.Env}}{{println .}}{{end}}' 2>/dev/null | sed -n 's/^DATABASE_URL=//p')
+if [[ -z "$WIKI_URL" ]]; then
+  echo "  ⚠️  exe-wiki not running — cannot determine schema"
+else
+  WIKI_SCHEMA=$(printf '%s' "$WIKI_URL" | sed -n 's/.*[?&]schema=\([^&]*\).*/\1/p')
+  [[ -z "$WIKI_SCHEMA" ]] && WIKI_SCHEMA="public"
+  COUNTS=$(docker exec exe-db psql -U exe -d exedb -tA -F' ' -c \
+    "SELECT COALESCE((SELECT count(*) FROM ${WIKI_SCHEMA}.users), -1),
+            COALESCE((SELECT count(*) FROM ${WIKI_SCHEMA}.workspace_documents), -1)" 2>/dev/null)
+  W_USERS=$(echo "$COUNTS" | awk '{print $1}')
+  W_DOCS=$(echo "$COUNTS" | awk '{print $2}')
+  if [[ "${W_USERS:-0}" -gt 0 || "${W_DOCS:-0}" -gt 0 ]]; then
+    echo -e "  ${GREEN}✅${NC} schema '$WIKI_SCHEMA' — users=$W_USERS documents=$W_DOCS"
+  else
+    echo -e "  ${RED}❌${NC} schema '$WIKI_SCHEMA' has NO users and NO documents — the wiki is"
+    echo -e "     serving an EMPTY schema. This is a config fault, not data loss."
+    echo -e "     ${YELLOW}DO NOT RESTORE FROM BACKUP.${NC} Check WIKI_DB_SCHEMA in .env and any"
+    echo -e "     docker-compose.override.yml, then: docker compose up -d exe-wiki"
+  fi
+fi
+
+echo ""
+
 # Disk/Memory
 echo "Resources:"
 echo "  RAM: $(free -h 2>/dev/null | awk '/^Mem:/ {print $3 "/" $2}' || echo 'N/A')"

package/deploy/compose/uptime-check.sh

@@ -1,6 +1,6 @@
 #!/usr/bin/env bash
 # exe-os uptime check — runs every 5 min via cron.
-# Checks: CRM, Gateway, WhatsApp state, Postgres.
+# Checks: CRM, Gateway, WhatsApp state, Postgres, wiki schema (bug 2a8d3003).
 # Writes JSONL to /opt/exe-stack/uptime.jsonl.
 # Logs ALERT to stderr (captured by cron/syslog) on any failure.
 #
@@ -92,10 +92,40 @@ check_whatsapp() {
 # --- Run checks ---
 NOW=$(ts)
 
+# Bug 2a8d3003: is the wiki serving the schema its data is actually in?
+# exe-wiki-schema-guard gates `docker compose up`, but nothing evaluates compose
+# dependencies on `docker start exe-wiki` or on restart:unless-stopped after a
+# reboot. Those paths can bring the wiki back on an empty schema with no guard run
+# and no error anywhere — silent-empty, which is the whole failure mode. Checking it
+# here bounds how long that can go unnoticed to one cron interval.
+# Reads the LIVE container env, not .env: a compose override can rewrite DATABASE_URL.
+check_wiki_schema() {
+  local url schema counts users docs
+  url=$(docker inspect exe-wiki --format '{{range .Config.Env}}{{println .}}{{end}}' 2>/dev/null \
+    | sed -n 's/^DATABASE_URL=//p')
+  [[ -z "$url" ]] && { echo "skip"; return; }
+  schema=$(printf '%s' "$url" | sed -n 's/.*[?&]schema=\([^&]*\).*/\1/p')
+  [[ -z "$schema" ]] && schema="public"
+  # Only ever interpolate a bare identifier into SQL.
+  [[ ! "$schema" =~ ^[A-Za-z_][A-Za-z0-9_]*$ ]] && { echo "fail:bad-schema-name"; return; }
+  counts=$(docker exec exe-db psql -U "${POSTGRES_USER:-exe}" -d "${POSTGRES_DB:-exedb}" -tA -F' ' -c \
+    "SELECT COALESCE((SELECT count(*) FROM ${schema}.users), 0),
+            COALESCE((SELECT count(*) FROM ${schema}.workspace_documents), 0)" 2>/dev/null)
+  [[ -z "$counts" ]] && { echo "skip"; return; }
+  users=$(echo "$counts" | awk '{print $1}')
+  docs=$(echo "$counts" | awk '{print $2}')
+  if [[ "${users:-0}" -gt 0 || "${docs:-0}" -gt 0 ]]; then
+    echo "ok:$schema"
+  else
+    echo "fail:empty-schema-$schema"
+  fi
+}
+
 crm_status=$(check_http "CRM" "http://127.0.0.1:3000/healthz")
 gateway_status=$(check_http "Gateway" "http://127.0.0.1:3100/health")
 whatsapp_status=$(check_whatsapp)
 postgres_status=$(check_postgres)
+wiki_schema_status=$(check_wiki_schema)
 
 # --- Determine overall health ---
 overall="ok"
@@ -117,11 +147,18 @@ if [[ "$postgres_status" != "ok" ]]; then
   overall="critical"
   alerts="${alerts}Postgres($postgres_status) "
 fi
+# A wiki serving an empty schema is critical: it looks like total data loss to
+# whoever opens it, and the wrong reflex (restore from backup) destroys the real
+# rows still sitting in the other schema. Say so in the alert itself.
+if [[ "$wiki_schema_status" == fail:* ]]; then
+  overall="critical"
+  alerts="${alerts}WikiSchema($wiki_schema_status — CONFIG FAULT, DO NOT RESTORE FROM BACKUP, see bug 2a8d3003) "
+fi
 
 # --- Write JSONL ---
 # Single-line JSON — no jq dependency required
 ENTRY=$(cat <<JSONEOF
-{"ts":"${NOW}","overall":"${overall}","crm":"${crm_status}","gateway":"${gateway_status}","whatsapp":"${whatsapp_status}","postgres":"${postgres_status}"}
+{"ts":"${NOW}","overall":"${overall}","crm":"${crm_status}","gateway":"${gateway_status}","whatsapp":"${whatsapp_status}","postgres":"${postgres_status}","wiki_schema":"${wiki_schema_status}"}
 JSONEOF
 )