@askexenow/exe-os 0.9.364 → 0.9.367

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,10 +61,45 @@ 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 ---

package/deploy/compose/.env.example

@@ -80,21 +80,59 @@ 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 ---

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
@@ -413,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"]
@@ -515,7 +560,7 @@ services:
       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.
@@ -561,6 +606,29 @@ services:
       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
@@ -632,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
@@ -697,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
@@ -736,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.
@@ -884,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).
@@ -933,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
@@ -964,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
@@ -1173,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"]
@@ -1314,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: []
@@ -1376,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: []
@@ -1430,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: []
@@ -1560,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:
@@ -1577,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.

package/deploy/compose/generate-env.ts

@@ -18,7 +18,7 @@ const EXE_BUILD_RELEASE_TAG = "v0.1.0";
 // Bug 58840873: pin exe-auth to the manifest-pinned tag so a generated .env never
 // lets compose fall back to its (stale) hardcoded default image. MUST equal the
 // AUTH_IMAGE_TAG tag in deploy/stack-manifests/v0.9.json and the compose default.
-const AUTH_RELEASE_TAG = "v0.2.0";
+const AUTH_RELEASE_TAG = "v0.5.0";
 
 const POSTGRES_USER = "exe";
 const POSTGRES_DB = "exedb";
@@ -46,6 +46,47 @@ const GATEWAY_WS_HOST_PORT = "3101";
 const RANDOM_SECRET_16 = 16;
 const RANDOM_SECRET_32 = 32;
 const RANDOM_SECRET_48 = 48;
+// Centralized role administration (e51ca54c §10.6b). Emitted verbatim into both
+// the generated customer .env and the checked-in .env.example so a fresh install
+// STATES its permissions posture instead of inheriting one silently.
+//
+// exe-crm#102 / exe-wiki#45 make managed permissions REQUIRED by default in the
+// apps, so an unmanaged first login can no longer mint its own admin. Those
+// defaults are kept. What a fresh install needs in addition is a legitimate way
+// to seat its FIRST admin, and for the CRM that way is EXE_CRM_ADMIN_EMAIL: the
+// boot-time WorkspaceBootstrapService seeds that user, so the intended owner is
+// an EXISTING user by the time they sign in and the first-login refusal never
+// applies to them. Leave it empty and the seed silently throws (onModuleInit
+// swallows it), after which nobody can ever get in.
+const MANAGED_PERMS_ENV_BLOCK = [
+  "# --- 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=",
+];
+
 const LICENSE_KEY_COMMENT = "# injected by deploy_client";
 const MANUAL_VALUE_COMMENT = "# SET_MANUALLY";
 const EXAMPLE_LICENSE_KEY = "CHANGEME_EXE_LICENSE_KEY";
@@ -169,11 +210,21 @@ export function generateEnv(options: GenerateEnvOptions): string {
     "# resolved GOTRUE_DISABLE_SIGNUP value above (bug d6f980c1).",
     `AUTH_DISABLE_SIGNUP=${disableSignup}`,
     "",
+    ...MANAGED_PERMS_ENV_BLOCK,
+    "",
     "# --- CRM ---",
     `CRM_IMAGE_TAG=${CRM_IMAGE_TAG}`,
     `CRM_SERVER_URL=https://crm.${normalizedDomain}`,
     `CRM_APP_SECRET=${randomSecret(RANDOM_SECRET_48)}`,
     `EXE_CRM_ADMIN_TOKEN=${randomSecret(RANDOM_SECRET_48)}`,
+    // The CRM's first admin. Seeded into core."user" 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). It cannot be generated — it must be a real
+    // mailbox that also exists in GoTrue — so it ships as SET_MANUALLY rather
+    // than as a random secret or a guessed admin@<domain>.
+    MANUAL_VALUE_COMMENT,
+    "EXE_CRM_ADMIN_EMAIL=CHANGEME_ADMIN_EMAIL",
     `CRM_HOST_PORT=${CRM_HOST_PORT}`,
     "",
     "# --- Wiki ---",
@@ -428,15 +479,28 @@ export function generateExampleEnv(): string {
     "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",
     "",
+    ...MANAGED_PERMS_ENV_BLOCK,
+    "",
     "# --- CRM ---",
     `CRM_IMAGE_TAG=${CRM_IMAGE_TAG}`,
     "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.",
+    MANUAL_VALUE_COMMENT,
+    "EXE_CRM_ADMIN_EMAIL=CHANGEME_ADMIN_EMAIL",
     `CRM_HOST_PORT=${CRM_HOST_PORT}`,
     "",
     "# --- Wiki ---",

package/deploy/stack-manifests/v0.9.json

@@ -1,6 +1,6 @@
 {
   "schemaVersion": 1,
-  "latest": "0.9.34",
+  "latest": "0.9.35",
   "stacks": {
     "0.9.0": {
       "version": "0.9.0",
@@ -2574,11 +2574,126 @@
         }
       },
       "rolloutStage": "ga"
+    },
+    "0.9.35": {
+      "version": "0.9.35",
+      "releasedAt": "2026-08-13T00:16:05Z",
+      "notes": "exe-auth v0.5.0 — the shared SSO login page is now one front door with one identity: the logo reads EXE INTELLIGENCE regardless of which product bounced the visitor here (?product= no longer rebrands it), configurable per-deploy via AUTH_BRAND_NAME. Includes the brand-word escaping fix (every '<' encoded for the JS/HTML context) so a white-label value can never break the login page. Bumps the auth image digest ONLY; every other pin is identical to 0.9.34. Founder-approved GO 2026-08-12.",
+      "npmVersion": "0.9.324",
+      "services": {
+        "exe-db": {
+          "image": "update.askexe.com/askexe/pgvector:0.8.0-pg16@sha256:a132765ec351c65111b5b675928a3a0515a466a40f97277329db8b8209ad8bc9",
+          "env": "EXE_DB_IMAGE",
+          "composeService": "exe-db",
+          "required": true,
+          "category": "core",
+          "description": "Postgres (pgvector) — digest-pinned (bug 32d6e02f; was tag-only in 0.9.25, regressed from 0.9.24)"
+        },
+        "exe-os": {
+          "image": "update.askexe.com/askexe/exe-os:v0.9.324@sha256:3ce6406e0f7f279ff2568bbbb7d55de51a46fdf35c49691f24fd959d6fd2d3fa",
+          "env": "EXE_OS_IMAGE_TAG",
+          "composeService": "exe-os",
+          "healthUrl": "http://127.0.0.1:8765/health",
+          "required": true,
+          "category": "core",
+          "description": "exe-os daemon + MCP server"
+        },
+        "crm": {
+          "image": "update.askexe.com/askexe/exe-crm:v0.9.53@sha256:a586dcc8bbd992538e3caa18c44e772d30f31155dfef0a2b7466ca3fc7c553d8",
+          "env": "CRM_IMAGE_TAG",
+          "composeService": "exe-crm",
+          "healthUrl": "http://127.0.0.1:3000/healthz",
+          "category": "app"
+        },
+        "wiki": {
+          "image": "update.askexe.com/askexe/exe-wiki:v0.9.28@sha256:61856a4c6b97ce62c62ecdc3a377139287be5860eb807d9fbb737115758d7856",
+          "env": "WIKI_IMAGE_TAG",
+          "composeService": "exe-wiki",
+          "healthUrl": "http://127.0.0.1:3001/api/ping",
+          "category": "app"
+        },
+        "gateway": {
+          "image": "update.askexe.com/askexe/exe-gateway:v2026.08.07-c15f093-stamped@sha256:1bc11a2a0ad1f3929d59d2685696f22a72042b9fca9c75e15c02dc7d3c640105",
+          "env": "GATEWAY_IMAGE_TAG",
+          "composeService": "exe-gateway",
+          "healthUrl": "http://127.0.0.1:3100/health",
+          "category": "app",
+          "description": "WhatsApp/messaging gateway — provenance-stamped rebuild of main (outbound message persistence fix); pinned by digest, dated immutable tag.",
+          "gitSha": "c15f093a0f59730bd5c2c73791ff77059dfa7cc1"
+        },
+        "monitorAgent": {
+          "image": "update.askexe.com/askexe/exe-monitor-agent:v2026.08.09-10660eb4-stamped@sha256:29fbd445f79484df04f000603e4ff445e76f0380f86d687a0033e3a0ef7d1b7a",
+          "env": "MONITOR_AGENT_IMAGE_TAG",
+          "composeService": "exe-monitor-agent",
+          "category": "monitoring",
+          "gitSha": "10660eb4abdeffbcba2aad13549aa58e208ac7a3"
+        },
+        "monitorHub": {
+          "image": "update.askexe.com/askexe/exe-monitor-hub:v2026.08.09-10660eb4-stamped@sha256:c9a9218c2713b8dffea7e1cf8c0702a614657d311a7a4e821c6a543bab29bb97",
+          "env": "MONITOR_HUB_IMAGE_TAG",
+          "composeService": "exe-monitor-hub",
+          "healthUrl": "http://127.0.0.1:8090/api/health",
+          "category": "monitoring",
+          "gitSha": "10660eb4abdeffbcba2aad13549aa58e208ac7a3"
+        },
+        "auth": {
+          "image": "update.askexe.com/askexe/exe-auth:v0.5.0@sha256:ecc57f92b1f2c2d9df4fafe648622fe1fdd87c27012048d950e3f6b82086ccf9",
+          "env": "AUTH_IMAGE_TAG",
+          "composeService": "exe-auth",
+          "healthUrl": "http://127.0.0.1:3300/api/health",
+          "category": "auth",
+          "description": "exe-auth v0.5.0 — one front door, one identity: logo reads EXE INTELLIGENCE (config-driven via AUTH_BRAND_NAME, escaped for the JS/HTML context).",
+          "gitSha": "874941df74041299d829fbc0b37887d64fae6f78"
+        },
+        "erp": {
+          "image": "update.askexe.com/askexe/exe-erp:v2026.08.07-d185286-stamped@sha256:1c655f3f7819c797afd13c79561354f0276cf337403f32aee3e406a497e8827b",
+          "env": "ERP_IMAGE_TAG",
+          "composeService": "exe-erp",
+          "healthUrl": "http://127.0.0.1:8069/api/method/ping",
+          "healthHost": "localhost",
+          "required": false,
+          "category": "app",
+          "description": "Enterprise Resource Planning",
+          "gitSha": "d185286873dcfa11e4b3f9672c4e23efea240cc5"
+        },
+        "gotrue": {
+          "image": "update.askexe.com/askexe/gotrue:v2.172.1@sha256:b0dd7aa28dd1f9a8bd31f136c8b912661f701d9b863171e5843cb08f18f49de4",
+          "composeService": "gotrue",
+          "healthUrl": "http://127.0.0.1:9999/health",
+          "category": "infra"
+        },
+        "redis": {
+          "image": "update.askexe.com/askexe/redis:7.4-alpine@sha256:6ab0b6e7381779332f97b8ca76193e45b0756f38d4c0dcda72dbb3c32061ab99",
+          "composeService": "redis",
+          "category": "infra"
+        },
+        "clickhouse": {
+          "image": "update.askexe.com/askexe/clickhouse-server:24.8.4.13-alpine@sha256:88a45f9e328549b2579256c46ee38e5c0e25ae58303d9eb6d9c7ed8d6d2bbf3c",
+          "composeService": "clickhouse",
+          "category": "infra"
+        },
+        "cloudflared": {
+          "image": "update.askexe.com/askexe/cloudflared:2026-07@sha256:ba461b8aa9c042156dbd39c38657fe7431bafa063220eab8d5330a523863da9f",
+          "composeService": "cloudflared",
+          "category": "infra"
+        },
+        "exe-sso-edge": {
+          "image": "update.askexe.com/askexe/nginx:alpine@sha256:20316569d8f81a160065d7d2a5eeffc7ca97d79022462ee255fd23fa103a6b5c",
+          "composeService": "exe-sso-edge",
+          "category": "infra"
+        },
+        "exe-otel-collector": {
+          "image": "update.askexe.com/askexe/otel-collector-contrib:0.114.0@sha256:37fa87091cfaaec7234a27e4e395a40c31c2bfaea97a349a4afef6d9e9681197",
+          "composeService": "exe-otel-collector",
+          "category": "infra"
+        }
+      },
+      "rolloutStage": "ga"
     }
   },
   "signature": {
     "keyId": "exe-stack-1",
     "alg": "ed25519",
-    "signature": "i3o3MZRZK46RCnWrzn/W4LyQdkyqPlprlK2hQVCtcqd3/1y9HPJUZMIQ8MX0pLFrQjK7BTtQA0YBUAnLDxlyCg=="
+    "signature": "pm9jH5HQp+Wo+eSqsFKBYekhFmSFUdJp1YYyBMqaufsnbOxj7JXakBGL4ssrzzi8s+xuNRY6SVXgXTT4biIpAg=="
   }
 }

package/dist/.dist-verified.json

@@ -1,6 +1,6 @@
 {
   "version": 1,
-  "verified_at": "2026-08-13T02:24:58.833Z",
-  "manifest_sha256": "9f5cf3755cf786a6053c42f7a3bdea6f5df40a844cff0a3202f6ab883ab1e13f",
-  "package_version": "0.9.364"
+  "verified_at": "2026-08-13T14:39:38.295Z",
+  "manifest_sha256": "347aa641dc9a0643d96a98a87cc14cb14edc413fad524aad808a86625b1079fe",
+  "package_version": "0.9.367"
 }