@askexenow/exe-os 0.9.298 → 0.9.300

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

@@ -48,7 +48,7 @@ CRM_HOST_PORT=3000
 # --- Wiki ---
 WIKI_IMAGE_TAG=update.askexe.com/askexe/exe-wiki:v0.9.21
 WIKI_DB_SCHEMA=wiki
-WIKI_VECTOR_DB=postgres
+WIKI_VECTOR_DB=exeOsMcp
 WIKI_AUTH_TOKEN=CHANGEME_WIKI_AUTH_TOKEN
 WIKI_JWT_SECRET=CHANGEME_WIKI_JWT_SECRET
 WIKI_SIG_KEY=CHANGEME_WIKI_SIG_KEY

package/deploy/compose/.env.example

@@ -75,7 +75,7 @@ CRM_HOST_PORT=3000
 # --- Wiki ---
 WIKI_IMAGE_TAG=ghcr.io/askexe/exe-wiki:v0.9.21
 WIKI_DB_SCHEMA=wiki
-WIKI_VECTOR_DB=postgres
+WIKI_VECTOR_DB=exeOsMcp
 WIKI_AUTH_TOKEN=CHANGEME_WIKI_AUTH_TOKEN
 EXE_WIKI_ADMIN_TOKEN=CHANGEME_EXE_WIKI_ADMIN_TOKEN
 WIKI_JWT_SECRET=CHANGEME_WIKI_JWT_SECRET

package/deploy/compose/docker-compose.yml

@@ -128,6 +128,12 @@ services:
     # whole secret file). A compromise of one app container cannot read another
     # service's GOTRUE_JWT_SECRET / DB passwords / CLOUDFLARE_TUNNEL_TOKEN, etc.
     command: ["redis-server", "--requirepass", "${REDIS_PASSWORD:?REDIS_PASSWORD is required}", "--save", "60", "1", "--appendonly", "yes"]
+    # bug f1e79d3b: the in-container healthcheck reads $${REDIS_PASSWORD} at
+    # runtime, but #199 (bug 67d62490) dropped `env_file: .env`, so the password
+    # was no longer a container env var (only compose-time interpolated into
+    # `command:`). Provide it explicitly so redis-cli -a can authenticate.
+    environment:
+      REDIS_PASSWORD: ${REDIS_PASSWORD:?REDIS_PASSWORD is required}
     volumes:
       - redis_data:/data
     networks:
@@ -377,7 +383,22 @@ 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}
-      VECTOR_DB: ${WIKI_VECTOR_DB:-postgres}
+      # 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}
+      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.
+      EXE_OS_MCP_COMMAND: ${WIKI_EXE_OS_MCP_COMMAND:-npx}
+      EXE_OS_MCP_ARGS: ${WIKI_EXE_OS_MCP_ARGS:--y @askexenow/exe-os mcp}
       BRANDING_CONFIG_PATH: /app/branding.json
     ports:
       - "127.0.0.1:${WIKI_HOST_PORT:-3001}:3001"
@@ -694,9 +715,11 @@ services:
       - frontend
     healthcheck:
       # Probe an app subdomain so the gate's server block (not the default 404)
-      # answers. Unauthenticated → 302, which wget treats as success with
-      # --max-redirect=0; any 2xx/3xx from the edge proves it is serving.
-      test: ["CMD", "wget", "-qO-", "--max-redirect=0", "--header=Host: crm.${DOMAIN}", "http://127.0.0.1:80/"]
+      # 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/"]
       interval: 30s
       timeout: 5s
       retries: 3
@@ -865,7 +888,10 @@ services:
       - backend
       - frontend
     healthcheck:
-      test: ["CMD", "wget", "-qO-", "http://127.0.0.1:80/"]
+      # bug f1e79d3b: Frappe multi-tenancy resolves the site by Host header.
+      # Without it, nginx/Frappe returns 404 and the healthcheck fails. Send the
+      # configured ERP site as Host so the correct tenant site answers.
+      test: ["CMD", "wget", "-qO-", "--header=Host: ${ERP_SITE_NAME:-erp.askexe.com}", "http://127.0.0.1:80/"]
       interval: 30s
       timeout: 5s
       retries: 3

package/deploy/compose/generate-env.ts

@@ -20,7 +20,7 @@ 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";
-const WIKI_VECTOR_DB = "postgres";
+const WIKI_VECTOR_DB = "exeOsMcp";
 const WIKI_HOST_PORT = "3001";
 export const EXE_OS_IMAGE_TAG = `${REGISTRY}/exe-os:${EXED_RELEASE_TAG}`;
 export const GATEWAY_IMAGE_TAG = `${REGISTRY}/exe-gateway:${GATEWAY_RELEASE_TAG}`;

package/deploy/compose/observability/otel-collector-config.yaml

@@ -57,7 +57,16 @@ service:
     logs:
       level: info
     metrics:
-      address: 0.0.0.0:8888
+      # Non-deprecated metrics reader (replaces the deprecated `address` field,
+      # which logs a deprecation warning on 0.114.0 and is removed in later
+      # collector releases). Exposes the collector's own metrics on the same
+      # 0.0.0.0:8888 Prometheus endpoint.
+      readers:
+        - pull:
+            exporter:
+              prometheus:
+                host: 0.0.0.0
+                port: 8888
   pipelines:
     traces:
       receivers: [otlp]

package/deploy/compose/setup.sh

@@ -96,7 +96,7 @@ EXE_CRM_ADMIN_TOKEN=$(gen 48)
 CRM_HOST_PORT=3000
 WIKI_IMAGE_TAG=ghcr.io/askexe/exe-wiki:v0.9.4
 WIKI_DB_SCHEMA=wiki
-WIKI_VECTOR_DB=postgres
+WIKI_VECTOR_DB=exeOsMcp
 WIKI_AUTH_TOKEN=$(gen 48)
 EXE_WIKI_ADMIN_TOKEN=$(gen 48)
 WIKI_JWT_SECRET=$(gen 48)

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

@@ -1346,7 +1346,7 @@
       "breakingChanges": [],
       "services": {
         "exe-os": {
-          "image": "update.askexe.com/askexe/exe-os:v0.9.294@sha256:cb89b04278beafc1596dd7b7c0012cbb75ce58a8e4c0ea2c1ffa5efffd5a03d7",
+          "image": "update.askexe.com/askexe/exe-os:v0.9.297@sha256:9fb38b3972202c410bb03d437a7fbaaf34a474f123285f45cbd9ceb039d276c1",
           "env": "EXE_OS_IMAGE_TAG",
           "composeService": "exe-os",
           "healthUrl": "http://127.0.0.1:8765/health",
@@ -1355,7 +1355,7 @@
           "description": "Exe OS Daemon \u2014 memory, orchestration, MCP server"
         },
         "crm": {
-          "image": "update.askexe.com/askexe/exe-crm:v0.9.48@sha256:f7fa8e1b8f7fbdc29c77b60461da0cfbda52cdd479ab1ffc25d8a618c94d1c82",
+          "image": "update.askexe.com/askexe/exe-crm:v0.9.49@sha256:656512528d2cecc7c0424f917a9b3d0a999f91b160c7b7e7e05778dd8b1319cc",
           "env": "CRM_IMAGE_TAG",
           "composeService": "exe-crm",
           "healthUrl": "http://127.0.0.1:3000/healthz",
@@ -1364,7 +1364,7 @@
           "description": "Customer Relationship Management"
         },
         "wiki": {
-          "image": "update.askexe.com/askexe/exe-wiki:v0.9.23@sha256:9e1ab889c902e641e2fe37910d85ed39ddfd7c728eceb40f25402d1abb734ea8",
+          "image": "update.askexe.com/askexe/exe-wiki:v0.9.24@sha256:3acf72b992d34ce1e802b075cef8e4e1dd5e4b5681a4681398545f1f7e13e331",
           "env": "WIKI_IMAGE_TAG",
           "composeService": "exe-wiki",
           "healthUrl": "http://127.0.0.1:3001/api/ping",
@@ -1373,7 +1373,7 @@
           "description": "Knowledge Base & Documentation"
         },
         "erp": {
-          "image": "update.askexe.com/askexe/exe-erp:v0.2.1@sha256:2d55a7c30bc6c5240b516de00e75e7384d0e6ec2580691e31cf3cb32ec012b4e",
+          "image": "update.askexe.com/askexe/exe-erp:v0.2.2@sha256:00fecc790ff848bfd4b7d87f42f859edfeb6090a7ca26bf2359dc6cb96767afb",
           "env": "ERP_IMAGE_TAG",
           "composeService": "exe-erp",
           "healthUrl": "http://127.0.0.1:8069/api/method/ping",
@@ -1382,7 +1382,7 @@
           "description": "Enterprise Resource Planning"
         },
         "gateway": {
-          "image": "update.askexe.com/askexe/exe-gateway:v0.9.21@sha256:c07baf4d57a9c3f4db04a31efba3e37da5fefc459b12189220ec99d8d648a018",
+          "image": "update.askexe.com/askexe/exe-gateway:v0.9.22@sha256:4d0b545699f2a38d1b6bbc2f81e4360e96d2b27e9b565da9fcd0ba1eac82f7c8",
           "env": "GATEWAY_IMAGE_TAG",
           "composeService": "exe-gateway",
           "healthUrl": "http://127.0.0.1:3100/health",
@@ -1391,7 +1391,7 @@
           "description": "WhatsApp, Telegram & API Gateway"
         },
         "monitorAgent": {
-          "image": "update.askexe.com/askexe/exe-monitor-agent:v0.9.4@sha256:9ca4e75577b2ff2abb754140ccfaf8df19161bcef601faf37d1fce743fe814fc",
+          "image": "update.askexe.com/askexe/exe-monitor-agent:v0.9.5@sha256:d442170bb0d7411beb4195e7888377cee2013a0c2adb194d4e44cdab41886d2d",
           "env": "MONITOR_AGENT_IMAGE_TAG",
           "composeService": "exe-monitor-agent",
           "required": false,
@@ -1399,7 +1399,7 @@
           "description": "System Monitoring Agent"
         },
         "monitorHub": {
-          "image": "update.askexe.com/askexe/exe-monitor-hub:v0.9.4@sha256:d593bec5a4b248388d0d85353fae1ba8f93cab628a03833aa79acd0632fd11cb",
+          "image": "update.askexe.com/askexe/exe-monitor-hub:v0.9.5@sha256:e9a406d1be7efe59cec38db1ace4beef728afa713781675cb30d33fe06b2ed08",
           "env": "MONITOR_HUB_IMAGE_TAG",
           "composeService": "exe-monitor-hub",
           "healthUrl": "http://127.0.0.1:8090/api/health",

package/dist/active-agent-56J56WW5.js

@@ -0,0 +1,27 @@
+import {
+  cleanupSessionMarkers,
+  clearActiveAgent,
+  getActiveAgent,
+  getAllActiveAgents,
+  resolveActiveAgentFromTmuxSession,
+  writeActiveAgent
+} from "./chunk-RCEULTPF.js";
+import "./chunk-CVYC6DUW.js";
+import "./chunk-GJV3WDWM.js";
+import "./chunk-XABJRAUW.js";
+import "./chunk-2I23RPSI.js";
+import "./chunk-PH6VRRFR.js";
+import "./chunk-PNQDP3OA.js";
+import "./chunk-7HLWBYH7.js";
+import "./chunk-FXU7JOXK.js";
+import "./chunk-R36FAN53.js";
+import "./chunk-LYH5HE24.js";
+import "./chunk-MLKGABMK.js";
+export {
+  cleanupSessionMarkers,
+  clearActiveAgent,
+  getActiveAgent,
+  getAllActiveAgents,
+  resolveActiveAgentFromTmuxSession,
+  writeActiveAgent
+};

package/dist/active-agent-VDWK7TES.js

@@ -0,0 +1,28 @@
+import "./chunk-SH45SJQW.js";
+import {
+  cleanupSessionMarkers,
+  clearActiveAgent,
+  getActiveAgent,
+  getAllActiveAgents,
+  resolveActiveAgentFromTmuxSession,
+  writeActiveAgent
+} from "./chunk-RCEULTPF.js";
+import "./chunk-CVYC6DUW.js";
+import "./chunk-GJV3WDWM.js";
+import "./chunk-XABJRAUW.js";
+import "./chunk-2I23RPSI.js";
+import "./chunk-PH6VRRFR.js";
+import "./chunk-PNQDP3OA.js";
+import "./chunk-7HLWBYH7.js";
+import "./chunk-FXU7JOXK.js";
+import "./chunk-R36FAN53.js";
+import "./chunk-LYH5HE24.js";
+import "./chunk-MLKGABMK.js";
+export {
+  cleanupSessionMarkers,
+  clearActiveAgent,
+  getActiveAgent,
+  getAllActiveAgents,
+  resolveActiveAgentFromTmuxSession,
+  writeActiveAgent
+};

package/dist/agentic-ontology-MZ4WHFDE.js

@@ -0,0 +1,25 @@
+import {
+  clean,
+  extractGoalCandidates,
+  inferIntention,
+  inferOntologyEventType,
+  inferOutcome,
+  inferSemanticLabel,
+  insertOntologyForBatch,
+  insertOntologyForMemory,
+  ontologyPayload,
+  stableId
+} from "./chunk-SVUYBT5N.js";
+import "./chunk-MLKGABMK.js";
+export {
+  clean,
+  extractGoalCandidates,
+  inferIntention,
+  inferOntologyEventType,
+  inferOutcome,
+  inferSemanticLabel,
+  insertOntologyForBatch,
+  insertOntologyForMemory,
+  ontologyPayload,
+  stableId
+};

package/dist/assets/com.askexe.exed.plist

@@ -20,11 +20,12 @@
     <!-- Resolved at install time by exe-setup -->
     <string>__NODE_PATH__</string>
     <!-- Daemon proper needs ~250-400MB; the embed model runs in a forked
-         worker, not this heap. A 2GB cap is ample and avoids the 6GB cap that
-         let the embed model load IN-PROCESS instead of forking to a child,
-         which is the root cause of the embed-worker OOM crash loop in
-         0.9.285-290 (bugs 9af29660 / eba6d502). DO NOT raise this. -->
-    <string>--max-old-space-size=2048</string>
+         worker with its OWN 6144 heap (never this one). 4GB cap per feature
+         6ee417ca ("heap cap 4096MB"); safe post-#221/#223 because the model
+         loads ONLY in the forked worker — never in-process. The OOM crash loop
+         in 0.9.285-290 (eba6d502) was the OLD 6GB cap letting the model load
+         IN-PROCESS, not this value. Keep in lockstep with computeDaemonHeapCapMb. -->
+    <string>--max-old-space-size=4096</string>
     <string>--expose-gc</string>
     <string>__DAEMON_PATH__</string>
   </array>