@askexenow/exe-os 0.9.91 → 0.9.93

package/dist/bin/exe-pending-messages.js

@@ -4645,7 +4645,13 @@ var init_platform_procedures = __esm({
         title: "How to update exe-os \u2014 CLI first, then stack",
         domain: "operations",
         priority: "p0",
-        content: "When bug fixes or features are available (surfaced at boot via list_my_bug_reports/list_my_feature_requests), update in two steps: (1) CLI: `npm install -g @askexenow/exe-os@latest` \u2014 this updates the local tools, MCP server, and bundled stack manifest. Must happen first so the stack-update tool itself has the latest fixes. (2) Stack (VPS only): `exe-os stack-update --target <version> --yes` \u2014 pulls new Docker images and restarts services. The target version comes from the stack manifest bundled with the CLI. Always update CLI before stack. Use `exe-os update --check` to see if a CLI update is available. Use `exe-os stack-update --check` to see stack status. For non-interactive/SSH: use `--yes` or `-y` flag. Never run `npm install -g` inside a tmux agent session \u2014 have the founder or COO do it from the host shell."
+        content: "When bug fixes or features are available (surfaced at boot via list_my_bug_reports/list_my_feature_requests), update in two steps: (1) CLI: `npm install -g @askexenow/exe-os@latest` \u2014 this updates the local tools, MCP server, and bundled stack manifest. Must happen first so the stack-update tool itself has the latest fixes. (2) Stack (VPS only): `exe-os stack-update --target <version> --yes` \u2014 pulls new Docker images and restarts services. The target version comes from the stack manifest bundled with the CLI. Always update CLI before stack. Use `exe-os update --check` to see if a CLI update is available. Use `exe-os stack-update --check` to see stack status. For non-interactive/SSH: use `--yes` or `-y` flag. Never run `npm install -g` inside a tmux agent session \u2014 have the founder or COO do it from the host shell. If stack-update fails with EACCES on /opt/exe-stack, run: `sudo mkdir -p /opt/exe-stack && sudo chown $(whoami) /opt/exe-stack` then retry."
+      },
+      {
+        title: "CLI version vs stack version \u2014 two tracks, both normal",
+        domain: "operations",
+        priority: "p0",
+        content: "exe-os has TWO version numbers that move independently. This is normal \u2014 do not treat a mismatch as an error. (1) CLI version (e.g. 0.9.89, 0.9.90) \u2014 the npm package installed locally. Updates frequently: bug fixes, new MCP tools, platform procedures, search improvements, client-side changes. Update with `npm install -g @askexenow/exe-os@latest`. (2) Stack version (e.g. 0.9.7, 0.9.8) \u2014 the Docker images on the VPS. Updates less frequently: only when server-side daemon, gateway, wiki, or CRM images need rebuilding. Update with `exe-os stack-update --target <version> --yes`. The CLI version will almost always be higher than the stack version. A CLI at 0.9.90 with a stack at 0.9.8 is perfectly normal \u2014 it means the CLI got 12 patches since the last Docker image rebuild. Only update the stack when: (a) the boot brief surfaces a fix that mentions 'stack update required', (b) a new stack manifest version is bundled in the CLI (`exe-os stack-update --check` shows pending changes), or (c) AskExe support explicitly tells you to. Do NOT attempt to make the numbers match \u2014 they are separate tracks."
       },
       // --- Operations ---
       {

package/dist/bin/exe-pending-notifications.js

@@ -4711,7 +4711,13 @@ var init_platform_procedures = __esm({
         title: "How to update exe-os \u2014 CLI first, then stack",
         domain: "operations",
         priority: "p0",
-        content: "When bug fixes or features are available (surfaced at boot via list_my_bug_reports/list_my_feature_requests), update in two steps: (1) CLI: `npm install -g @askexenow/exe-os@latest` \u2014 this updates the local tools, MCP server, and bundled stack manifest. Must happen first so the stack-update tool itself has the latest fixes. (2) Stack (VPS only): `exe-os stack-update --target <version> --yes` \u2014 pulls new Docker images and restarts services. The target version comes from the stack manifest bundled with the CLI. Always update CLI before stack. Use `exe-os update --check` to see if a CLI update is available. Use `exe-os stack-update --check` to see stack status. For non-interactive/SSH: use `--yes` or `-y` flag. Never run `npm install -g` inside a tmux agent session \u2014 have the founder or COO do it from the host shell."
+        content: "When bug fixes or features are available (surfaced at boot via list_my_bug_reports/list_my_feature_requests), update in two steps: (1) CLI: `npm install -g @askexenow/exe-os@latest` \u2014 this updates the local tools, MCP server, and bundled stack manifest. Must happen first so the stack-update tool itself has the latest fixes. (2) Stack (VPS only): `exe-os stack-update --target <version> --yes` \u2014 pulls new Docker images and restarts services. The target version comes from the stack manifest bundled with the CLI. Always update CLI before stack. Use `exe-os update --check` to see if a CLI update is available. Use `exe-os stack-update --check` to see stack status. For non-interactive/SSH: use `--yes` or `-y` flag. Never run `npm install -g` inside a tmux agent session \u2014 have the founder or COO do it from the host shell. If stack-update fails with EACCES on /opt/exe-stack, run: `sudo mkdir -p /opt/exe-stack && sudo chown $(whoami) /opt/exe-stack` then retry."
+      },
+      {
+        title: "CLI version vs stack version \u2014 two tracks, both normal",
+        domain: "operations",
+        priority: "p0",
+        content: "exe-os has TWO version numbers that move independently. This is normal \u2014 do not treat a mismatch as an error. (1) CLI version (e.g. 0.9.89, 0.9.90) \u2014 the npm package installed locally. Updates frequently: bug fixes, new MCP tools, platform procedures, search improvements, client-side changes. Update with `npm install -g @askexenow/exe-os@latest`. (2) Stack version (e.g. 0.9.7, 0.9.8) \u2014 the Docker images on the VPS. Updates less frequently: only when server-side daemon, gateway, wiki, or CRM images need rebuilding. Update with `exe-os stack-update --target <version> --yes`. The CLI version will almost always be higher than the stack version. A CLI at 0.9.90 with a stack at 0.9.8 is perfectly normal \u2014 it means the CLI got 12 patches since the last Docker image rebuild. Only update the stack when: (a) the boot brief surfaces a fix that mentions 'stack update required', (b) a new stack manifest version is bundled in the CLI (`exe-os stack-update --check` shows pending changes), or (c) AskExe support explicitly tells you to. Do NOT attempt to make the numbers match \u2014 they are separate tracks."
       },
       // --- Operations ---
       {

package/dist/bin/exe-pending-reviews.js

@@ -4750,7 +4750,13 @@ var init_platform_procedures = __esm({
         title: "How to update exe-os \u2014 CLI first, then stack",
         domain: "operations",
         priority: "p0",
-        content: "When bug fixes or features are available (surfaced at boot via list_my_bug_reports/list_my_feature_requests), update in two steps: (1) CLI: `npm install -g @askexenow/exe-os@latest` \u2014 this updates the local tools, MCP server, and bundled stack manifest. Must happen first so the stack-update tool itself has the latest fixes. (2) Stack (VPS only): `exe-os stack-update --target <version> --yes` \u2014 pulls new Docker images and restarts services. The target version comes from the stack manifest bundled with the CLI. Always update CLI before stack. Use `exe-os update --check` to see if a CLI update is available. Use `exe-os stack-update --check` to see stack status. For non-interactive/SSH: use `--yes` or `-y` flag. Never run `npm install -g` inside a tmux agent session \u2014 have the founder or COO do it from the host shell."
+        content: "When bug fixes or features are available (surfaced at boot via list_my_bug_reports/list_my_feature_requests), update in two steps: (1) CLI: `npm install -g @askexenow/exe-os@latest` \u2014 this updates the local tools, MCP server, and bundled stack manifest. Must happen first so the stack-update tool itself has the latest fixes. (2) Stack (VPS only): `exe-os stack-update --target <version> --yes` \u2014 pulls new Docker images and restarts services. The target version comes from the stack manifest bundled with the CLI. Always update CLI before stack. Use `exe-os update --check` to see if a CLI update is available. Use `exe-os stack-update --check` to see stack status. For non-interactive/SSH: use `--yes` or `-y` flag. Never run `npm install -g` inside a tmux agent session \u2014 have the founder or COO do it from the host shell. If stack-update fails with EACCES on /opt/exe-stack, run: `sudo mkdir -p /opt/exe-stack && sudo chown $(whoami) /opt/exe-stack` then retry."
+      },
+      {
+        title: "CLI version vs stack version \u2014 two tracks, both normal",
+        domain: "operations",
+        priority: "p0",
+        content: "exe-os has TWO version numbers that move independently. This is normal \u2014 do not treat a mismatch as an error. (1) CLI version (e.g. 0.9.89, 0.9.90) \u2014 the npm package installed locally. Updates frequently: bug fixes, new MCP tools, platform procedures, search improvements, client-side changes. Update with `npm install -g @askexenow/exe-os@latest`. (2) Stack version (e.g. 0.9.7, 0.9.8) \u2014 the Docker images on the VPS. Updates less frequently: only when server-side daemon, gateway, wiki, or CRM images need rebuilding. Update with `exe-os stack-update --target <version> --yes`. The CLI version will almost always be higher than the stack version. A CLI at 0.9.90 with a stack at 0.9.8 is perfectly normal \u2014 it means the CLI got 12 patches since the last Docker image rebuild. Only update the stack when: (a) the boot brief surfaces a fix that mentions 'stack update required', (b) a new stack manifest version is bundled in the CLI (`exe-os stack-update --check` shows pending changes), or (c) AskExe support explicitly tells you to. Do NOT attempt to make the numbers match \u2014 they are separate tracks."
       },
       // --- Operations ---
       {

package/dist/bin/exe-rename.js

@@ -3091,7 +3091,13 @@ var init_platform_procedures = __esm({
         title: "How to update exe-os \u2014 CLI first, then stack",
         domain: "operations",
         priority: "p0",
-        content: "When bug fixes or features are available (surfaced at boot via list_my_bug_reports/list_my_feature_requests), update in two steps: (1) CLI: `npm install -g @askexenow/exe-os@latest` \u2014 this updates the local tools, MCP server, and bundled stack manifest. Must happen first so the stack-update tool itself has the latest fixes. (2) Stack (VPS only): `exe-os stack-update --target <version> --yes` \u2014 pulls new Docker images and restarts services. The target version comes from the stack manifest bundled with the CLI. Always update CLI before stack. Use `exe-os update --check` to see if a CLI update is available. Use `exe-os stack-update --check` to see stack status. For non-interactive/SSH: use `--yes` or `-y` flag. Never run `npm install -g` inside a tmux agent session \u2014 have the founder or COO do it from the host shell."
+        content: "When bug fixes or features are available (surfaced at boot via list_my_bug_reports/list_my_feature_requests), update in two steps: (1) CLI: `npm install -g @askexenow/exe-os@latest` \u2014 this updates the local tools, MCP server, and bundled stack manifest. Must happen first so the stack-update tool itself has the latest fixes. (2) Stack (VPS only): `exe-os stack-update --target <version> --yes` \u2014 pulls new Docker images and restarts services. The target version comes from the stack manifest bundled with the CLI. Always update CLI before stack. Use `exe-os update --check` to see if a CLI update is available. Use `exe-os stack-update --check` to see stack status. For non-interactive/SSH: use `--yes` or `-y` flag. Never run `npm install -g` inside a tmux agent session \u2014 have the founder or COO do it from the host shell. If stack-update fails with EACCES on /opt/exe-stack, run: `sudo mkdir -p /opt/exe-stack && sudo chown $(whoami) /opt/exe-stack` then retry."
+      },
+      {
+        title: "CLI version vs stack version \u2014 two tracks, both normal",
+        domain: "operations",
+        priority: "p0",
+        content: "exe-os has TWO version numbers that move independently. This is normal \u2014 do not treat a mismatch as an error. (1) CLI version (e.g. 0.9.89, 0.9.90) \u2014 the npm package installed locally. Updates frequently: bug fixes, new MCP tools, platform procedures, search improvements, client-side changes. Update with `npm install -g @askexenow/exe-os@latest`. (2) Stack version (e.g. 0.9.7, 0.9.8) \u2014 the Docker images on the VPS. Updates less frequently: only when server-side daemon, gateway, wiki, or CRM images need rebuilding. Update with `exe-os stack-update --target <version> --yes`. The CLI version will almost always be higher than the stack version. A CLI at 0.9.90 with a stack at 0.9.8 is perfectly normal \u2014 it means the CLI got 12 patches since the last Docker image rebuild. Only update the stack when: (a) the boot brief surfaces a fix that mentions 'stack update required', (b) a new stack manifest version is bundled in the CLI (`exe-os stack-update --check` shows pending changes), or (c) AskExe support explicitly tells you to. Do NOT attempt to make the numbers match \u2014 they are separate tracks."
       },
       // --- Operations ---
       {

package/dist/bin/exe-review.js

@@ -4222,7 +4222,13 @@ var init_platform_procedures = __esm({
         title: "How to update exe-os \u2014 CLI first, then stack",
         domain: "operations",
         priority: "p0",
-        content: "When bug fixes or features are available (surfaced at boot via list_my_bug_reports/list_my_feature_requests), update in two steps: (1) CLI: `npm install -g @askexenow/exe-os@latest` \u2014 this updates the local tools, MCP server, and bundled stack manifest. Must happen first so the stack-update tool itself has the latest fixes. (2) Stack (VPS only): `exe-os stack-update --target <version> --yes` \u2014 pulls new Docker images and restarts services. The target version comes from the stack manifest bundled with the CLI. Always update CLI before stack. Use `exe-os update --check` to see if a CLI update is available. Use `exe-os stack-update --check` to see stack status. For non-interactive/SSH: use `--yes` or `-y` flag. Never run `npm install -g` inside a tmux agent session \u2014 have the founder or COO do it from the host shell."
+        content: "When bug fixes or features are available (surfaced at boot via list_my_bug_reports/list_my_feature_requests), update in two steps: (1) CLI: `npm install -g @askexenow/exe-os@latest` \u2014 this updates the local tools, MCP server, and bundled stack manifest. Must happen first so the stack-update tool itself has the latest fixes. (2) Stack (VPS only): `exe-os stack-update --target <version> --yes` \u2014 pulls new Docker images and restarts services. The target version comes from the stack manifest bundled with the CLI. Always update CLI before stack. Use `exe-os update --check` to see if a CLI update is available. Use `exe-os stack-update --check` to see stack status. For non-interactive/SSH: use `--yes` or `-y` flag. Never run `npm install -g` inside a tmux agent session \u2014 have the founder or COO do it from the host shell. If stack-update fails with EACCES on /opt/exe-stack, run: `sudo mkdir -p /opt/exe-stack && sudo chown $(whoami) /opt/exe-stack` then retry."
+      },
+      {
+        title: "CLI version vs stack version \u2014 two tracks, both normal",
+        domain: "operations",
+        priority: "p0",
+        content: "exe-os has TWO version numbers that move independently. This is normal \u2014 do not treat a mismatch as an error. (1) CLI version (e.g. 0.9.89, 0.9.90) \u2014 the npm package installed locally. Updates frequently: bug fixes, new MCP tools, platform procedures, search improvements, client-side changes. Update with `npm install -g @askexenow/exe-os@latest`. (2) Stack version (e.g. 0.9.7, 0.9.8) \u2014 the Docker images on the VPS. Updates less frequently: only when server-side daemon, gateway, wiki, or CRM images need rebuilding. Update with `exe-os stack-update --target <version> --yes`. The CLI version will almost always be higher than the stack version. A CLI at 0.9.90 with a stack at 0.9.8 is perfectly normal \u2014 it means the CLI got 12 patches since the last Docker image rebuild. Only update the stack when: (a) the boot brief surfaces a fix that mentions 'stack update required', (b) a new stack manifest version is bundled in the CLI (`exe-os stack-update --check` shows pending changes), or (c) AskExe support explicitly tells you to. Do NOT attempt to make the numbers match \u2014 they are separate tracks."
       },
       // --- Operations ---
       {

package/dist/bin/exe-search.js

@@ -4207,7 +4207,13 @@ var init_platform_procedures = __esm({
         title: "How to update exe-os \u2014 CLI first, then stack",
         domain: "operations",
         priority: "p0",
-        content: "When bug fixes or features are available (surfaced at boot via list_my_bug_reports/list_my_feature_requests), update in two steps: (1) CLI: `npm install -g @askexenow/exe-os@latest` \u2014 this updates the local tools, MCP server, and bundled stack manifest. Must happen first so the stack-update tool itself has the latest fixes. (2) Stack (VPS only): `exe-os stack-update --target <version> --yes` \u2014 pulls new Docker images and restarts services. The target version comes from the stack manifest bundled with the CLI. Always update CLI before stack. Use `exe-os update --check` to see if a CLI update is available. Use `exe-os stack-update --check` to see stack status. For non-interactive/SSH: use `--yes` or `-y` flag. Never run `npm install -g` inside a tmux agent session \u2014 have the founder or COO do it from the host shell."
+        content: "When bug fixes or features are available (surfaced at boot via list_my_bug_reports/list_my_feature_requests), update in two steps: (1) CLI: `npm install -g @askexenow/exe-os@latest` \u2014 this updates the local tools, MCP server, and bundled stack manifest. Must happen first so the stack-update tool itself has the latest fixes. (2) Stack (VPS only): `exe-os stack-update --target <version> --yes` \u2014 pulls new Docker images and restarts services. The target version comes from the stack manifest bundled with the CLI. Always update CLI before stack. Use `exe-os update --check` to see if a CLI update is available. Use `exe-os stack-update --check` to see stack status. For non-interactive/SSH: use `--yes` or `-y` flag. Never run `npm install -g` inside a tmux agent session \u2014 have the founder or COO do it from the host shell. If stack-update fails with EACCES on /opt/exe-stack, run: `sudo mkdir -p /opt/exe-stack && sudo chown $(whoami) /opt/exe-stack` then retry."
+      },
+      {
+        title: "CLI version vs stack version \u2014 two tracks, both normal",
+        domain: "operations",
+        priority: "p0",
+        content: "exe-os has TWO version numbers that move independently. This is normal \u2014 do not treat a mismatch as an error. (1) CLI version (e.g. 0.9.89, 0.9.90) \u2014 the npm package installed locally. Updates frequently: bug fixes, new MCP tools, platform procedures, search improvements, client-side changes. Update with `npm install -g @askexenow/exe-os@latest`. (2) Stack version (e.g. 0.9.7, 0.9.8) \u2014 the Docker images on the VPS. Updates less frequently: only when server-side daemon, gateway, wiki, or CRM images need rebuilding. Update with `exe-os stack-update --target <version> --yes`. The CLI version will almost always be higher than the stack version. A CLI at 0.9.90 with a stack at 0.9.8 is perfectly normal \u2014 it means the CLI got 12 patches since the last Docker image rebuild. Only update the stack when: (a) the boot brief surfaces a fix that mentions 'stack update required', (b) a new stack manifest version is bundled in the CLI (`exe-os stack-update --check` shows pending changes), or (c) AskExe support explicitly tells you to. Do NOT attempt to make the numbers match \u2014 they are separate tracks."
       },
       // --- Operations ---
       {

package/dist/bin/exe-session-cleanup.js

@@ -4251,7 +4251,13 @@ var init_platform_procedures = __esm({
         title: "How to update exe-os \u2014 CLI first, then stack",
         domain: "operations",
         priority: "p0",
-        content: "When bug fixes or features are available (surfaced at boot via list_my_bug_reports/list_my_feature_requests), update in two steps: (1) CLI: `npm install -g @askexenow/exe-os@latest` \u2014 this updates the local tools, MCP server, and bundled stack manifest. Must happen first so the stack-update tool itself has the latest fixes. (2) Stack (VPS only): `exe-os stack-update --target <version> --yes` \u2014 pulls new Docker images and restarts services. The target version comes from the stack manifest bundled with the CLI. Always update CLI before stack. Use `exe-os update --check` to see if a CLI update is available. Use `exe-os stack-update --check` to see stack status. For non-interactive/SSH: use `--yes` or `-y` flag. Never run `npm install -g` inside a tmux agent session \u2014 have the founder or COO do it from the host shell."
+        content: "When bug fixes or features are available (surfaced at boot via list_my_bug_reports/list_my_feature_requests), update in two steps: (1) CLI: `npm install -g @askexenow/exe-os@latest` \u2014 this updates the local tools, MCP server, and bundled stack manifest. Must happen first so the stack-update tool itself has the latest fixes. (2) Stack (VPS only): `exe-os stack-update --target <version> --yes` \u2014 pulls new Docker images and restarts services. The target version comes from the stack manifest bundled with the CLI. Always update CLI before stack. Use `exe-os update --check` to see if a CLI update is available. Use `exe-os stack-update --check` to see stack status. For non-interactive/SSH: use `--yes` or `-y` flag. Never run `npm install -g` inside a tmux agent session \u2014 have the founder or COO do it from the host shell. If stack-update fails with EACCES on /opt/exe-stack, run: `sudo mkdir -p /opt/exe-stack && sudo chown $(whoami) /opt/exe-stack` then retry."
+      },
+      {
+        title: "CLI version vs stack version \u2014 two tracks, both normal",
+        domain: "operations",
+        priority: "p0",
+        content: "exe-os has TWO version numbers that move independently. This is normal \u2014 do not treat a mismatch as an error. (1) CLI version (e.g. 0.9.89, 0.9.90) \u2014 the npm package installed locally. Updates frequently: bug fixes, new MCP tools, platform procedures, search improvements, client-side changes. Update with `npm install -g @askexenow/exe-os@latest`. (2) Stack version (e.g. 0.9.7, 0.9.8) \u2014 the Docker images on the VPS. Updates less frequently: only when server-side daemon, gateway, wiki, or CRM images need rebuilding. Update with `exe-os stack-update --target <version> --yes`. The CLI version will almost always be higher than the stack version. A CLI at 0.9.90 with a stack at 0.9.8 is perfectly normal \u2014 it means the CLI got 12 patches since the last Docker image rebuild. Only update the stack when: (a) the boot brief surfaces a fix that mentions 'stack update required', (b) a new stack manifest version is bundled in the CLI (`exe-os stack-update --check` shows pending changes), or (c) AskExe support explicitly tells you to. Do NOT attempt to make the numbers match \u2014 they are separate tracks."
       },
       // --- Operations ---
       {

package/dist/bin/exe-start-codex.js

@@ -3523,7 +3523,13 @@ var init_platform_procedures = __esm({
         title: "How to update exe-os \u2014 CLI first, then stack",
         domain: "operations",
         priority: "p0",
-        content: "When bug fixes or features are available (surfaced at boot via list_my_bug_reports/list_my_feature_requests), update in two steps: (1) CLI: `npm install -g @askexenow/exe-os@latest` \u2014 this updates the local tools, MCP server, and bundled stack manifest. Must happen first so the stack-update tool itself has the latest fixes. (2) Stack (VPS only): `exe-os stack-update --target <version> --yes` \u2014 pulls new Docker images and restarts services. The target version comes from the stack manifest bundled with the CLI. Always update CLI before stack. Use `exe-os update --check` to see if a CLI update is available. Use `exe-os stack-update --check` to see stack status. For non-interactive/SSH: use `--yes` or `-y` flag. Never run `npm install -g` inside a tmux agent session \u2014 have the founder or COO do it from the host shell."
+        content: "When bug fixes or features are available (surfaced at boot via list_my_bug_reports/list_my_feature_requests), update in two steps: (1) CLI: `npm install -g @askexenow/exe-os@latest` \u2014 this updates the local tools, MCP server, and bundled stack manifest. Must happen first so the stack-update tool itself has the latest fixes. (2) Stack (VPS only): `exe-os stack-update --target <version> --yes` \u2014 pulls new Docker images and restarts services. The target version comes from the stack manifest bundled with the CLI. Always update CLI before stack. Use `exe-os update --check` to see if a CLI update is available. Use `exe-os stack-update --check` to see stack status. For non-interactive/SSH: use `--yes` or `-y` flag. Never run `npm install -g` inside a tmux agent session \u2014 have the founder or COO do it from the host shell. If stack-update fails with EACCES on /opt/exe-stack, run: `sudo mkdir -p /opt/exe-stack && sudo chown $(whoami) /opt/exe-stack` then retry."
+      },
+      {
+        title: "CLI version vs stack version \u2014 two tracks, both normal",
+        domain: "operations",
+        priority: "p0",
+        content: "exe-os has TWO version numbers that move independently. This is normal \u2014 do not treat a mismatch as an error. (1) CLI version (e.g. 0.9.89, 0.9.90) \u2014 the npm package installed locally. Updates frequently: bug fixes, new MCP tools, platform procedures, search improvements, client-side changes. Update with `npm install -g @askexenow/exe-os@latest`. (2) Stack version (e.g. 0.9.7, 0.9.8) \u2014 the Docker images on the VPS. Updates less frequently: only when server-side daemon, gateway, wiki, or CRM images need rebuilding. Update with `exe-os stack-update --target <version> --yes`. The CLI version will almost always be higher than the stack version. A CLI at 0.9.90 with a stack at 0.9.8 is perfectly normal \u2014 it means the CLI got 12 patches since the last Docker image rebuild. Only update the stack when: (a) the boot brief surfaces a fix that mentions 'stack update required', (b) a new stack manifest version is bundled in the CLI (`exe-os stack-update --check` shows pending changes), or (c) AskExe support explicitly tells you to. Do NOT attempt to make the numbers match \u2014 they are separate tracks."
       },
       // --- Operations ---
       {

package/dist/bin/exe-start-opencode.js

@@ -3523,7 +3523,13 @@ var init_platform_procedures = __esm({
         title: "How to update exe-os \u2014 CLI first, then stack",
         domain: "operations",
         priority: "p0",
-        content: "When bug fixes or features are available (surfaced at boot via list_my_bug_reports/list_my_feature_requests), update in two steps: (1) CLI: `npm install -g @askexenow/exe-os@latest` \u2014 this updates the local tools, MCP server, and bundled stack manifest. Must happen first so the stack-update tool itself has the latest fixes. (2) Stack (VPS only): `exe-os stack-update --target <version> --yes` \u2014 pulls new Docker images and restarts services. The target version comes from the stack manifest bundled with the CLI. Always update CLI before stack. Use `exe-os update --check` to see if a CLI update is available. Use `exe-os stack-update --check` to see stack status. For non-interactive/SSH: use `--yes` or `-y` flag. Never run `npm install -g` inside a tmux agent session \u2014 have the founder or COO do it from the host shell."
+        content: "When bug fixes or features are available (surfaced at boot via list_my_bug_reports/list_my_feature_requests), update in two steps: (1) CLI: `npm install -g @askexenow/exe-os@latest` \u2014 this updates the local tools, MCP server, and bundled stack manifest. Must happen first so the stack-update tool itself has the latest fixes. (2) Stack (VPS only): `exe-os stack-update --target <version> --yes` \u2014 pulls new Docker images and restarts services. The target version comes from the stack manifest bundled with the CLI. Always update CLI before stack. Use `exe-os update --check` to see if a CLI update is available. Use `exe-os stack-update --check` to see stack status. For non-interactive/SSH: use `--yes` or `-y` flag. Never run `npm install -g` inside a tmux agent session \u2014 have the founder or COO do it from the host shell. If stack-update fails with EACCES on /opt/exe-stack, run: `sudo mkdir -p /opt/exe-stack && sudo chown $(whoami) /opt/exe-stack` then retry."
+      },
+      {
+        title: "CLI version vs stack version \u2014 two tracks, both normal",
+        domain: "operations",
+        priority: "p0",
+        content: "exe-os has TWO version numbers that move independently. This is normal \u2014 do not treat a mismatch as an error. (1) CLI version (e.g. 0.9.89, 0.9.90) \u2014 the npm package installed locally. Updates frequently: bug fixes, new MCP tools, platform procedures, search improvements, client-side changes. Update with `npm install -g @askexenow/exe-os@latest`. (2) Stack version (e.g. 0.9.7, 0.9.8) \u2014 the Docker images on the VPS. Updates less frequently: only when server-side daemon, gateway, wiki, or CRM images need rebuilding. Update with `exe-os stack-update --target <version> --yes`. The CLI version will almost always be higher than the stack version. A CLI at 0.9.90 with a stack at 0.9.8 is perfectly normal \u2014 it means the CLI got 12 patches since the last Docker image rebuild. Only update the stack when: (a) the boot brief surfaces a fix that mentions 'stack update required', (b) a new stack manifest version is bundled in the CLI (`exe-os stack-update --check` shows pending changes), or (c) AskExe support explicitly tells you to. Do NOT attempt to make the numbers match \u2014 they are separate tracks."
       },
       // --- Operations ---
       {

package/dist/bin/exe-status.js

@@ -4230,7 +4230,13 @@ var init_platform_procedures = __esm({
         title: "How to update exe-os \u2014 CLI first, then stack",
         domain: "operations",
         priority: "p0",
-        content: "When bug fixes or features are available (surfaced at boot via list_my_bug_reports/list_my_feature_requests), update in two steps: (1) CLI: `npm install -g @askexenow/exe-os@latest` \u2014 this updates the local tools, MCP server, and bundled stack manifest. Must happen first so the stack-update tool itself has the latest fixes. (2) Stack (VPS only): `exe-os stack-update --target <version> --yes` \u2014 pulls new Docker images and restarts services. The target version comes from the stack manifest bundled with the CLI. Always update CLI before stack. Use `exe-os update --check` to see if a CLI update is available. Use `exe-os stack-update --check` to see stack status. For non-interactive/SSH: use `--yes` or `-y` flag. Never run `npm install -g` inside a tmux agent session \u2014 have the founder or COO do it from the host shell."
+        content: "When bug fixes or features are available (surfaced at boot via list_my_bug_reports/list_my_feature_requests), update in two steps: (1) CLI: `npm install -g @askexenow/exe-os@latest` \u2014 this updates the local tools, MCP server, and bundled stack manifest. Must happen first so the stack-update tool itself has the latest fixes. (2) Stack (VPS only): `exe-os stack-update --target <version> --yes` \u2014 pulls new Docker images and restarts services. The target version comes from the stack manifest bundled with the CLI. Always update CLI before stack. Use `exe-os update --check` to see if a CLI update is available. Use `exe-os stack-update --check` to see stack status. For non-interactive/SSH: use `--yes` or `-y` flag. Never run `npm install -g` inside a tmux agent session \u2014 have the founder or COO do it from the host shell. If stack-update fails with EACCES on /opt/exe-stack, run: `sudo mkdir -p /opt/exe-stack && sudo chown $(whoami) /opt/exe-stack` then retry."
+      },
+      {
+        title: "CLI version vs stack version \u2014 two tracks, both normal",
+        domain: "operations",
+        priority: "p0",
+        content: "exe-os has TWO version numbers that move independently. This is normal \u2014 do not treat a mismatch as an error. (1) CLI version (e.g. 0.9.89, 0.9.90) \u2014 the npm package installed locally. Updates frequently: bug fixes, new MCP tools, platform procedures, search improvements, client-side changes. Update with `npm install -g @askexenow/exe-os@latest`. (2) Stack version (e.g. 0.9.7, 0.9.8) \u2014 the Docker images on the VPS. Updates less frequently: only when server-side daemon, gateway, wiki, or CRM images need rebuilding. Update with `exe-os stack-update --target <version> --yes`. The CLI version will almost always be higher than the stack version. A CLI at 0.9.90 with a stack at 0.9.8 is perfectly normal \u2014 it means the CLI got 12 patches since the last Docker image rebuild. Only update the stack when: (a) the boot brief surfaces a fix that mentions 'stack update required', (b) a new stack manifest version is bundled in the CLI (`exe-os stack-update --check` shows pending changes), or (c) AskExe support explicitly tells you to. Do NOT attempt to make the numbers match \u2014 they are separate tracks."
       },
       // --- Operations ---
       {

package/dist/bin/exe-team.js

@@ -4219,7 +4219,13 @@ var init_platform_procedures = __esm({
         title: "How to update exe-os \u2014 CLI first, then stack",
         domain: "operations",
         priority: "p0",
-        content: "When bug fixes or features are available (surfaced at boot via list_my_bug_reports/list_my_feature_requests), update in two steps: (1) CLI: `npm install -g @askexenow/exe-os@latest` \u2014 this updates the local tools, MCP server, and bundled stack manifest. Must happen first so the stack-update tool itself has the latest fixes. (2) Stack (VPS only): `exe-os stack-update --target <version> --yes` \u2014 pulls new Docker images and restarts services. The target version comes from the stack manifest bundled with the CLI. Always update CLI before stack. Use `exe-os update --check` to see if a CLI update is available. Use `exe-os stack-update --check` to see stack status. For non-interactive/SSH: use `--yes` or `-y` flag. Never run `npm install -g` inside a tmux agent session \u2014 have the founder or COO do it from the host shell."
+        content: "When bug fixes or features are available (surfaced at boot via list_my_bug_reports/list_my_feature_requests), update in two steps: (1) CLI: `npm install -g @askexenow/exe-os@latest` \u2014 this updates the local tools, MCP server, and bundled stack manifest. Must happen first so the stack-update tool itself has the latest fixes. (2) Stack (VPS only): `exe-os stack-update --target <version> --yes` \u2014 pulls new Docker images and restarts services. The target version comes from the stack manifest bundled with the CLI. Always update CLI before stack. Use `exe-os update --check` to see if a CLI update is available. Use `exe-os stack-update --check` to see stack status. For non-interactive/SSH: use `--yes` or `-y` flag. Never run `npm install -g` inside a tmux agent session \u2014 have the founder or COO do it from the host shell. If stack-update fails with EACCES on /opt/exe-stack, run: `sudo mkdir -p /opt/exe-stack && sudo chown $(whoami) /opt/exe-stack` then retry."
+      },
+      {
+        title: "CLI version vs stack version \u2014 two tracks, both normal",
+        domain: "operations",
+        priority: "p0",
+        content: "exe-os has TWO version numbers that move independently. This is normal \u2014 do not treat a mismatch as an error. (1) CLI version (e.g. 0.9.89, 0.9.90) \u2014 the npm package installed locally. Updates frequently: bug fixes, new MCP tools, platform procedures, search improvements, client-side changes. Update with `npm install -g @askexenow/exe-os@latest`. (2) Stack version (e.g. 0.9.7, 0.9.8) \u2014 the Docker images on the VPS. Updates less frequently: only when server-side daemon, gateway, wiki, or CRM images need rebuilding. Update with `exe-os stack-update --target <version> --yes`. The CLI version will almost always be higher than the stack version. A CLI at 0.9.90 with a stack at 0.9.8 is perfectly normal \u2014 it means the CLI got 12 patches since the last Docker image rebuild. Only update the stack when: (a) the boot brief surfaces a fix that mentions 'stack update required', (b) a new stack manifest version is bundled in the CLI (`exe-os stack-update --check` shows pending changes), or (c) AskExe support explicitly tells you to. Do NOT attempt to make the numbers match \u2014 they are separate tracks."
       },
       // --- Operations ---
       {

package/dist/bin/git-sweep.js

@@ -7924,7 +7924,13 @@ var init_platform_procedures = __esm({
         title: "How to update exe-os \u2014 CLI first, then stack",
         domain: "operations",
         priority: "p0",
-        content: "When bug fixes or features are available (surfaced at boot via list_my_bug_reports/list_my_feature_requests), update in two steps: (1) CLI: `npm install -g @askexenow/exe-os@latest` \u2014 this updates the local tools, MCP server, and bundled stack manifest. Must happen first so the stack-update tool itself has the latest fixes. (2) Stack (VPS only): `exe-os stack-update --target <version> --yes` \u2014 pulls new Docker images and restarts services. The target version comes from the stack manifest bundled with the CLI. Always update CLI before stack. Use `exe-os update --check` to see if a CLI update is available. Use `exe-os stack-update --check` to see stack status. For non-interactive/SSH: use `--yes` or `-y` flag. Never run `npm install -g` inside a tmux agent session \u2014 have the founder or COO do it from the host shell."
+        content: "When bug fixes or features are available (surfaced at boot via list_my_bug_reports/list_my_feature_requests), update in two steps: (1) CLI: `npm install -g @askexenow/exe-os@latest` \u2014 this updates the local tools, MCP server, and bundled stack manifest. Must happen first so the stack-update tool itself has the latest fixes. (2) Stack (VPS only): `exe-os stack-update --target <version> --yes` \u2014 pulls new Docker images and restarts services. The target version comes from the stack manifest bundled with the CLI. Always update CLI before stack. Use `exe-os update --check` to see if a CLI update is available. Use `exe-os stack-update --check` to see stack status. For non-interactive/SSH: use `--yes` or `-y` flag. Never run `npm install -g` inside a tmux agent session \u2014 have the founder or COO do it from the host shell. If stack-update fails with EACCES on /opt/exe-stack, run: `sudo mkdir -p /opt/exe-stack && sudo chown $(whoami) /opt/exe-stack` then retry."
+      },
+      {
+        title: "CLI version vs stack version \u2014 two tracks, both normal",
+        domain: "operations",
+        priority: "p0",
+        content: "exe-os has TWO version numbers that move independently. This is normal \u2014 do not treat a mismatch as an error. (1) CLI version (e.g. 0.9.89, 0.9.90) \u2014 the npm package installed locally. Updates frequently: bug fixes, new MCP tools, platform procedures, search improvements, client-side changes. Update with `npm install -g @askexenow/exe-os@latest`. (2) Stack version (e.g. 0.9.7, 0.9.8) \u2014 the Docker images on the VPS. Updates less frequently: only when server-side daemon, gateway, wiki, or CRM images need rebuilding. Update with `exe-os stack-update --target <version> --yes`. The CLI version will almost always be higher than the stack version. A CLI at 0.9.90 with a stack at 0.9.8 is perfectly normal \u2014 it means the CLI got 12 patches since the last Docker image rebuild. Only update the stack when: (a) the boot brief surfaces a fix that mentions 'stack update required', (b) a new stack manifest version is bundled in the CLI (`exe-os stack-update --check` shows pending changes), or (c) AskExe support explicitly tells you to. Do NOT attempt to make the numbers match \u2014 they are separate tracks."
       },
       // --- Operations ---
       {

package/dist/bin/graph-backfill.js

@@ -3436,7 +3436,13 @@ var init_platform_procedures = __esm({
         title: "How to update exe-os \u2014 CLI first, then stack",
         domain: "operations",
         priority: "p0",
-        content: "When bug fixes or features are available (surfaced at boot via list_my_bug_reports/list_my_feature_requests), update in two steps: (1) CLI: `npm install -g @askexenow/exe-os@latest` \u2014 this updates the local tools, MCP server, and bundled stack manifest. Must happen first so the stack-update tool itself has the latest fixes. (2) Stack (VPS only): `exe-os stack-update --target <version> --yes` \u2014 pulls new Docker images and restarts services. The target version comes from the stack manifest bundled with the CLI. Always update CLI before stack. Use `exe-os update --check` to see if a CLI update is available. Use `exe-os stack-update --check` to see stack status. For non-interactive/SSH: use `--yes` or `-y` flag. Never run `npm install -g` inside a tmux agent session \u2014 have the founder or COO do it from the host shell."
+        content: "When bug fixes or features are available (surfaced at boot via list_my_bug_reports/list_my_feature_requests), update in two steps: (1) CLI: `npm install -g @askexenow/exe-os@latest` \u2014 this updates the local tools, MCP server, and bundled stack manifest. Must happen first so the stack-update tool itself has the latest fixes. (2) Stack (VPS only): `exe-os stack-update --target <version> --yes` \u2014 pulls new Docker images and restarts services. The target version comes from the stack manifest bundled with the CLI. Always update CLI before stack. Use `exe-os update --check` to see if a CLI update is available. Use `exe-os stack-update --check` to see stack status. For non-interactive/SSH: use `--yes` or `-y` flag. Never run `npm install -g` inside a tmux agent session \u2014 have the founder or COO do it from the host shell. If stack-update fails with EACCES on /opt/exe-stack, run: `sudo mkdir -p /opt/exe-stack && sudo chown $(whoami) /opt/exe-stack` then retry."
+      },
+      {
+        title: "CLI version vs stack version \u2014 two tracks, both normal",
+        domain: "operations",
+        priority: "p0",
+        content: "exe-os has TWO version numbers that move independently. This is normal \u2014 do not treat a mismatch as an error. (1) CLI version (e.g. 0.9.89, 0.9.90) \u2014 the npm package installed locally. Updates frequently: bug fixes, new MCP tools, platform procedures, search improvements, client-side changes. Update with `npm install -g @askexenow/exe-os@latest`. (2) Stack version (e.g. 0.9.7, 0.9.8) \u2014 the Docker images on the VPS. Updates less frequently: only when server-side daemon, gateway, wiki, or CRM images need rebuilding. Update with `exe-os stack-update --target <version> --yes`. The CLI version will almost always be higher than the stack version. A CLI at 0.9.90 with a stack at 0.9.8 is perfectly normal \u2014 it means the CLI got 12 patches since the last Docker image rebuild. Only update the stack when: (a) the boot brief surfaces a fix that mentions 'stack update required', (b) a new stack manifest version is bundled in the CLI (`exe-os stack-update --check` shows pending changes), or (c) AskExe support explicitly tells you to. Do NOT attempt to make the numbers match \u2014 they are separate tracks."
       },
       // --- Operations ---
       {

package/dist/bin/graph-export.js

@@ -4208,7 +4208,13 @@ var init_platform_procedures = __esm({
         title: "How to update exe-os \u2014 CLI first, then stack",
         domain: "operations",
         priority: "p0",
-        content: "When bug fixes or features are available (surfaced at boot via list_my_bug_reports/list_my_feature_requests), update in two steps: (1) CLI: `npm install -g @askexenow/exe-os@latest` \u2014 this updates the local tools, MCP server, and bundled stack manifest. Must happen first so the stack-update tool itself has the latest fixes. (2) Stack (VPS only): `exe-os stack-update --target <version> --yes` \u2014 pulls new Docker images and restarts services. The target version comes from the stack manifest bundled with the CLI. Always update CLI before stack. Use `exe-os update --check` to see if a CLI update is available. Use `exe-os stack-update --check` to see stack status. For non-interactive/SSH: use `--yes` or `-y` flag. Never run `npm install -g` inside a tmux agent session \u2014 have the founder or COO do it from the host shell."
+        content: "When bug fixes or features are available (surfaced at boot via list_my_bug_reports/list_my_feature_requests), update in two steps: (1) CLI: `npm install -g @askexenow/exe-os@latest` \u2014 this updates the local tools, MCP server, and bundled stack manifest. Must happen first so the stack-update tool itself has the latest fixes. (2) Stack (VPS only): `exe-os stack-update --target <version> --yes` \u2014 pulls new Docker images and restarts services. The target version comes from the stack manifest bundled with the CLI. Always update CLI before stack. Use `exe-os update --check` to see if a CLI update is available. Use `exe-os stack-update --check` to see stack status. For non-interactive/SSH: use `--yes` or `-y` flag. Never run `npm install -g` inside a tmux agent session \u2014 have the founder or COO do it from the host shell. If stack-update fails with EACCES on /opt/exe-stack, run: `sudo mkdir -p /opt/exe-stack && sudo chown $(whoami) /opt/exe-stack` then retry."
+      },
+      {
+        title: "CLI version vs stack version \u2014 two tracks, both normal",
+        domain: "operations",
+        priority: "p0",
+        content: "exe-os has TWO version numbers that move independently. This is normal \u2014 do not treat a mismatch as an error. (1) CLI version (e.g. 0.9.89, 0.9.90) \u2014 the npm package installed locally. Updates frequently: bug fixes, new MCP tools, platform procedures, search improvements, client-side changes. Update with `npm install -g @askexenow/exe-os@latest`. (2) Stack version (e.g. 0.9.7, 0.9.8) \u2014 the Docker images on the VPS. Updates less frequently: only when server-side daemon, gateway, wiki, or CRM images need rebuilding. Update with `exe-os stack-update --target <version> --yes`. The CLI version will almost always be higher than the stack version. A CLI at 0.9.90 with a stack at 0.9.8 is perfectly normal \u2014 it means the CLI got 12 patches since the last Docker image rebuild. Only update the stack when: (a) the boot brief surfaces a fix that mentions 'stack update required', (b) a new stack manifest version is bundled in the CLI (`exe-os stack-update --check` shows pending changes), or (c) AskExe support explicitly tells you to. Do NOT attempt to make the numbers match \u2014 they are separate tracks."
       },
       // --- Operations ---
       {

package/dist/bin/intercom-check.js

@@ -4317,7 +4317,13 @@ var init_platform_procedures = __esm({
         title: "How to update exe-os \u2014 CLI first, then stack",
         domain: "operations",
         priority: "p0",
-        content: "When bug fixes or features are available (surfaced at boot via list_my_bug_reports/list_my_feature_requests), update in two steps: (1) CLI: `npm install -g @askexenow/exe-os@latest` \u2014 this updates the local tools, MCP server, and bundled stack manifest. Must happen first so the stack-update tool itself has the latest fixes. (2) Stack (VPS only): `exe-os stack-update --target <version> --yes` \u2014 pulls new Docker images and restarts services. The target version comes from the stack manifest bundled with the CLI. Always update CLI before stack. Use `exe-os update --check` to see if a CLI update is available. Use `exe-os stack-update --check` to see stack status. For non-interactive/SSH: use `--yes` or `-y` flag. Never run `npm install -g` inside a tmux agent session \u2014 have the founder or COO do it from the host shell."
+        content: "When bug fixes or features are available (surfaced at boot via list_my_bug_reports/list_my_feature_requests), update in two steps: (1) CLI: `npm install -g @askexenow/exe-os@latest` \u2014 this updates the local tools, MCP server, and bundled stack manifest. Must happen first so the stack-update tool itself has the latest fixes. (2) Stack (VPS only): `exe-os stack-update --target <version> --yes` \u2014 pulls new Docker images and restarts services. The target version comes from the stack manifest bundled with the CLI. Always update CLI before stack. Use `exe-os update --check` to see if a CLI update is available. Use `exe-os stack-update --check` to see stack status. For non-interactive/SSH: use `--yes` or `-y` flag. Never run `npm install -g` inside a tmux agent session \u2014 have the founder or COO do it from the host shell. If stack-update fails with EACCES on /opt/exe-stack, run: `sudo mkdir -p /opt/exe-stack && sudo chown $(whoami) /opt/exe-stack` then retry."
+      },
+      {
+        title: "CLI version vs stack version \u2014 two tracks, both normal",
+        domain: "operations",
+        priority: "p0",
+        content: "exe-os has TWO version numbers that move independently. This is normal \u2014 do not treat a mismatch as an error. (1) CLI version (e.g. 0.9.89, 0.9.90) \u2014 the npm package installed locally. Updates frequently: bug fixes, new MCP tools, platform procedures, search improvements, client-side changes. Update with `npm install -g @askexenow/exe-os@latest`. (2) Stack version (e.g. 0.9.7, 0.9.8) \u2014 the Docker images on the VPS. Updates less frequently: only when server-side daemon, gateway, wiki, or CRM images need rebuilding. Update with `exe-os stack-update --target <version> --yes`. The CLI version will almost always be higher than the stack version. A CLI at 0.9.90 with a stack at 0.9.8 is perfectly normal \u2014 it means the CLI got 12 patches since the last Docker image rebuild. Only update the stack when: (a) the boot brief surfaces a fix that mentions 'stack update required', (b) a new stack manifest version is bundled in the CLI (`exe-os stack-update --check` shows pending changes), or (c) AskExe support explicitly tells you to. Do NOT attempt to make the numbers match \u2014 they are separate tracks."
       },
       // --- Operations ---
       {

package/dist/bin/scan-tasks.js

@@ -7995,7 +7995,13 @@ var init_platform_procedures = __esm({
         title: "How to update exe-os \u2014 CLI first, then stack",
         domain: "operations",
         priority: "p0",
-        content: "When bug fixes or features are available (surfaced at boot via list_my_bug_reports/list_my_feature_requests), update in two steps: (1) CLI: `npm install -g @askexenow/exe-os@latest` \u2014 this updates the local tools, MCP server, and bundled stack manifest. Must happen first so the stack-update tool itself has the latest fixes. (2) Stack (VPS only): `exe-os stack-update --target <version> --yes` \u2014 pulls new Docker images and restarts services. The target version comes from the stack manifest bundled with the CLI. Always update CLI before stack. Use `exe-os update --check` to see if a CLI update is available. Use `exe-os stack-update --check` to see stack status. For non-interactive/SSH: use `--yes` or `-y` flag. Never run `npm install -g` inside a tmux agent session \u2014 have the founder or COO do it from the host shell."
+        content: "When bug fixes or features are available (surfaced at boot via list_my_bug_reports/list_my_feature_requests), update in two steps: (1) CLI: `npm install -g @askexenow/exe-os@latest` \u2014 this updates the local tools, MCP server, and bundled stack manifest. Must happen first so the stack-update tool itself has the latest fixes. (2) Stack (VPS only): `exe-os stack-update --target <version> --yes` \u2014 pulls new Docker images and restarts services. The target version comes from the stack manifest bundled with the CLI. Always update CLI before stack. Use `exe-os update --check` to see if a CLI update is available. Use `exe-os stack-update --check` to see stack status. For non-interactive/SSH: use `--yes` or `-y` flag. Never run `npm install -g` inside a tmux agent session \u2014 have the founder or COO do it from the host shell. If stack-update fails with EACCES on /opt/exe-stack, run: `sudo mkdir -p /opt/exe-stack && sudo chown $(whoami) /opt/exe-stack` then retry."
+      },
+      {
+        title: "CLI version vs stack version \u2014 two tracks, both normal",
+        domain: "operations",
+        priority: "p0",
+        content: "exe-os has TWO version numbers that move independently. This is normal \u2014 do not treat a mismatch as an error. (1) CLI version (e.g. 0.9.89, 0.9.90) \u2014 the npm package installed locally. Updates frequently: bug fixes, new MCP tools, platform procedures, search improvements, client-side changes. Update with `npm install -g @askexenow/exe-os@latest`. (2) Stack version (e.g. 0.9.7, 0.9.8) \u2014 the Docker images on the VPS. Updates less frequently: only when server-side daemon, gateway, wiki, or CRM images need rebuilding. Update with `exe-os stack-update --target <version> --yes`. The CLI version will almost always be higher than the stack version. A CLI at 0.9.90 with a stack at 0.9.8 is perfectly normal \u2014 it means the CLI got 12 patches since the last Docker image rebuild. Only update the stack when: (a) the boot brief surfaces a fix that mentions 'stack update required', (b) a new stack manifest version is bundled in the CLI (`exe-os stack-update --check` shows pending changes), or (c) AskExe support explicitly tells you to. Do NOT attempt to make the numbers match \u2014 they are separate tracks."
       },
       // --- Operations ---
       {

package/dist/bin/setup.js

@@ -6618,7 +6618,13 @@ var init_platform_procedures = __esm({
         title: "How to update exe-os \u2014 CLI first, then stack",
         domain: "operations",
         priority: "p0",
-        content: "When bug fixes or features are available (surfaced at boot via list_my_bug_reports/list_my_feature_requests), update in two steps: (1) CLI: `npm install -g @askexenow/exe-os@latest` \u2014 this updates the local tools, MCP server, and bundled stack manifest. Must happen first so the stack-update tool itself has the latest fixes. (2) Stack (VPS only): `exe-os stack-update --target <version> --yes` \u2014 pulls new Docker images and restarts services. The target version comes from the stack manifest bundled with the CLI. Always update CLI before stack. Use `exe-os update --check` to see if a CLI update is available. Use `exe-os stack-update --check` to see stack status. For non-interactive/SSH: use `--yes` or `-y` flag. Never run `npm install -g` inside a tmux agent session \u2014 have the founder or COO do it from the host shell."
+        content: "When bug fixes or features are available (surfaced at boot via list_my_bug_reports/list_my_feature_requests), update in two steps: (1) CLI: `npm install -g @askexenow/exe-os@latest` \u2014 this updates the local tools, MCP server, and bundled stack manifest. Must happen first so the stack-update tool itself has the latest fixes. (2) Stack (VPS only): `exe-os stack-update --target <version> --yes` \u2014 pulls new Docker images and restarts services. The target version comes from the stack manifest bundled with the CLI. Always update CLI before stack. Use `exe-os update --check` to see if a CLI update is available. Use `exe-os stack-update --check` to see stack status. For non-interactive/SSH: use `--yes` or `-y` flag. Never run `npm install -g` inside a tmux agent session \u2014 have the founder or COO do it from the host shell. If stack-update fails with EACCES on /opt/exe-stack, run: `sudo mkdir -p /opt/exe-stack && sudo chown $(whoami) /opt/exe-stack` then retry."
+      },
+      {
+        title: "CLI version vs stack version \u2014 two tracks, both normal",
+        domain: "operations",
+        priority: "p0",
+        content: "exe-os has TWO version numbers that move independently. This is normal \u2014 do not treat a mismatch as an error. (1) CLI version (e.g. 0.9.89, 0.9.90) \u2014 the npm package installed locally. Updates frequently: bug fixes, new MCP tools, platform procedures, search improvements, client-side changes. Update with `npm install -g @askexenow/exe-os@latest`. (2) Stack version (e.g. 0.9.7, 0.9.8) \u2014 the Docker images on the VPS. Updates less frequently: only when server-side daemon, gateway, wiki, or CRM images need rebuilding. Update with `exe-os stack-update --target <version> --yes`. The CLI version will almost always be higher than the stack version. A CLI at 0.9.90 with a stack at 0.9.8 is perfectly normal \u2014 it means the CLI got 12 patches since the last Docker image rebuild. Only update the stack when: (a) the boot brief surfaces a fix that mentions 'stack update required', (b) a new stack manifest version is bundled in the CLI (`exe-os stack-update --check` shows pending changes), or (c) AskExe support explicitly tells you to. Do NOT attempt to make the numbers match \u2014 they are separate tracks."
       },
       // --- Operations ---
       {

package/dist/bin/shard-migrate.js

@@ -3436,7 +3436,13 @@ var init_platform_procedures = __esm({
         title: "How to update exe-os \u2014 CLI first, then stack",
         domain: "operations",
         priority: "p0",
-        content: "When bug fixes or features are available (surfaced at boot via list_my_bug_reports/list_my_feature_requests), update in two steps: (1) CLI: `npm install -g @askexenow/exe-os@latest` \u2014 this updates the local tools, MCP server, and bundled stack manifest. Must happen first so the stack-update tool itself has the latest fixes. (2) Stack (VPS only): `exe-os stack-update --target <version> --yes` \u2014 pulls new Docker images and restarts services. The target version comes from the stack manifest bundled with the CLI. Always update CLI before stack. Use `exe-os update --check` to see if a CLI update is available. Use `exe-os stack-update --check` to see stack status. For non-interactive/SSH: use `--yes` or `-y` flag. Never run `npm install -g` inside a tmux agent session \u2014 have the founder or COO do it from the host shell."
+        content: "When bug fixes or features are available (surfaced at boot via list_my_bug_reports/list_my_feature_requests), update in two steps: (1) CLI: `npm install -g @askexenow/exe-os@latest` \u2014 this updates the local tools, MCP server, and bundled stack manifest. Must happen first so the stack-update tool itself has the latest fixes. (2) Stack (VPS only): `exe-os stack-update --target <version> --yes` \u2014 pulls new Docker images and restarts services. The target version comes from the stack manifest bundled with the CLI. Always update CLI before stack. Use `exe-os update --check` to see if a CLI update is available. Use `exe-os stack-update --check` to see stack status. For non-interactive/SSH: use `--yes` or `-y` flag. Never run `npm install -g` inside a tmux agent session \u2014 have the founder or COO do it from the host shell. If stack-update fails with EACCES on /opt/exe-stack, run: `sudo mkdir -p /opt/exe-stack && sudo chown $(whoami) /opt/exe-stack` then retry."
+      },
+      {
+        title: "CLI version vs stack version \u2014 two tracks, both normal",
+        domain: "operations",
+        priority: "p0",
+        content: "exe-os has TWO version numbers that move independently. This is normal \u2014 do not treat a mismatch as an error. (1) CLI version (e.g. 0.9.89, 0.9.90) \u2014 the npm package installed locally. Updates frequently: bug fixes, new MCP tools, platform procedures, search improvements, client-side changes. Update with `npm install -g @askexenow/exe-os@latest`. (2) Stack version (e.g. 0.9.7, 0.9.8) \u2014 the Docker images on the VPS. Updates less frequently: only when server-side daemon, gateway, wiki, or CRM images need rebuilding. Update with `exe-os stack-update --target <version> --yes`. The CLI version will almost always be higher than the stack version. A CLI at 0.9.90 with a stack at 0.9.8 is perfectly normal \u2014 it means the CLI got 12 patches since the last Docker image rebuild. Only update the stack when: (a) the boot brief surfaces a fix that mentions 'stack update required', (b) a new stack manifest version is bundled in the CLI (`exe-os stack-update --check` shows pending changes), or (c) AskExe support explicitly tells you to. Do NOT attempt to make the numbers match \u2014 they are separate tracks."
       },
       // --- Operations ---
       {

package/dist/bin/stack-update.js

@@ -409,7 +409,21 @@ function copyTemplateIfMissing(srcRel, dest, created) {
   if (existsSync4(dest)) return;
   const src = path3.join(resolvePackageRoot(), srcRel);
   if (!existsSync4(src)) throw new Error(`Missing packaged stack template: ${srcRel}. Reinstall/update exe-os and retry.`);
-  mkdirSync3(path3.dirname(dest), { recursive: true });
+  try {
+    mkdirSync3(path3.dirname(dest), { recursive: true });
+  } catch (err) {
+    if (err.code === "EACCES") {
+      const dir = path3.dirname(dest);
+      throw new Error(
+        `Permission denied creating ${dir}. Run this first:
+
+  sudo mkdir -p ${dir} && sudo chown $(whoami) ${dir}
+
+Then re-run stack-update.`
+      );
+    }
+    throw err;
+  }
   copyFileSync(src, dest);
   created.push(dest);
 }
@@ -453,7 +467,7 @@ function hydrateEnv(raw, opts) {
   for (const [key, value] of env.entries()) {
     if (!/CHANGEME/.test(value)) continue;
     if (key === "EXE_LICENSE_KEY" && license) replacements[key] = license;
-    else if (key === "MONITOR_AGENT_KEY") continue;
+    else if (key === "MONITOR_AGENT_TOKEN" || key === "MONITOR_AGENT_KEY") continue;
     else if (key === "EXE_GATEWAY_WS_RELAY_AUTH_TOKEN") replacements[key] = randomHexSecret(24);
     else if (key.endsWith("_PASSWORD")) replacements[key] = randomSecret(24);
     else if (key.endsWith("_TOKEN")) replacements[key] = randomHexSecret(32);
@@ -465,6 +479,45 @@ function hydrateEnv(raw, opts) {
   const remaining = [...parseEnv(next).entries()].filter(([, value]) => /CHANGEME/.test(value)).map(([key, value]) => `${key}=${value}`);
   return { raw: next, hadPlaceholders: /CHANGEME/.test(raw), remaining: [...new Set(remaining)] };
 }
+async function pairMonitorAgent(hubUrl, licenseKey, domain, envFile) {
+  if (!hubUrl || !licenseKey || !domain) {
+    return { paired: false, error: "Missing hubUrl, licenseKey, or domain for monitor pairing" };
+  }
+  const registrationUrl = `${hubUrl.replace(/\/+$/, "")}/api/register-agent`;
+  try {
+    const res = await fetch(registrationUrl, {
+      method: "POST",
+      headers: {
+        "content-type": "application/json",
+        authorization: `Bearer ${licenseKey}`
+      },
+      body: JSON.stringify({ name: domain, host: domain, port: 45876 }),
+      signal: AbortSignal.timeout(15e3)
+    });
+    if (!res.ok) {
+      const body = await res.text().catch(() => "");
+      return { paired: false, error: `Monitor hub returned HTTP ${res.status}: ${body}` };
+    }
+    const data = await res.json();
+    if (!data.token || !data.key) {
+      return { paired: false, error: "Monitor hub response missing token or key" };
+    }
+    if (existsSync4(envFile)) {
+      const envRaw = readFileSync3(envFile, "utf8");
+      const patched = patchEnv(envRaw, {
+        MONITOR_AGENT_TOKEN: data.token,
+        MONITOR_AGENT_KEY: data.key
+      });
+      if (patched !== envRaw) {
+        writeFileSync2(envFile, patched, { mode: 384 });
+      }
+    }
+    return { paired: true, systemName: data.name ?? domain };
+  } catch (err) {
+    const reason = err instanceof Error ? err.message : String(err);
+    return { paired: false, error: `Monitor hub unreachable: ${reason}` };
+  }
+}
 function bootstrapStackHost(options) {
   const exec = options.exec ?? defaultExec;
   const createdFiles = [];
@@ -537,6 +590,24 @@ async function runStackUpdate(options) {
     const report = bootstrapStackHost({ ...options, installDocker: options.installDocker ?? !!options.yes });
     if (!options.dryRun) assertHostReadyForApply(report);
   }
+  const hubUrl = options.monitorHubUrl || parseEnv(readFileSync3(options.envFile, "utf8")).get("MONITOR_HUB_URL") || "";
+  const pairLicense = options.licenseKey || process.env.EXE_LICENSE_KEY || loadLicense() || "";
+  const pairDomain = options.domain || process.env.EXE_STACK_DOMAIN || process.env.CUSTOMER_DOMAIN || "";
+  if (hubUrl && pairLicense && pairDomain) {
+    const envBefore = readFileSync3(options.envFile, "utf8");
+    const hasPlaceholder = /CHANGEME/.test(parseEnv(envBefore).get("MONITOR_AGENT_TOKEN") ?? "");
+    if (hasPlaceholder) {
+      const pair = options.pairMonitor ? options.pairMonitor(hubUrl, pairLicense, pairDomain, options.envFile) : pairMonitorAgent(hubUrl, pairLicense, pairDomain, options.envFile);
+      const result = await pair;
+      if (typeof result === "object" && result && "paired" in result) {
+        if (result.paired) {
+          console.log(`[stack-update] Monitor agent paired: ${result.systemName}`);
+        } else {
+          console.warn(`[stack-update] Monitor pairing skipped: ${result.error}`);
+        }
+      }
+    }
+  }
   const manifest = await loadStackManifest(options.manifestRef, options.fetchText, options.manifestPublicKey, options.manifestAuthToken);
   const envRaw = readFileSync3(options.envFile, "utf8");
   const plan = createStackUpdatePlan(manifest, envRaw, options.targetVersion);

package/dist/gateway/index.js

@@ -4876,7 +4876,13 @@ var init_platform_procedures = __esm({
         title: "How to update exe-os \u2014 CLI first, then stack",
         domain: "operations",
         priority: "p0",
-        content: "When bug fixes or features are available (surfaced at boot via list_my_bug_reports/list_my_feature_requests), update in two steps: (1) CLI: `npm install -g @askexenow/exe-os@latest` \u2014 this updates the local tools, MCP server, and bundled stack manifest. Must happen first so the stack-update tool itself has the latest fixes. (2) Stack (VPS only): `exe-os stack-update --target <version> --yes` \u2014 pulls new Docker images and restarts services. The target version comes from the stack manifest bundled with the CLI. Always update CLI before stack. Use `exe-os update --check` to see if a CLI update is available. Use `exe-os stack-update --check` to see stack status. For non-interactive/SSH: use `--yes` or `-y` flag. Never run `npm install -g` inside a tmux agent session \u2014 have the founder or COO do it from the host shell."
+        content: "When bug fixes or features are available (surfaced at boot via list_my_bug_reports/list_my_feature_requests), update in two steps: (1) CLI: `npm install -g @askexenow/exe-os@latest` \u2014 this updates the local tools, MCP server, and bundled stack manifest. Must happen first so the stack-update tool itself has the latest fixes. (2) Stack (VPS only): `exe-os stack-update --target <version> --yes` \u2014 pulls new Docker images and restarts services. The target version comes from the stack manifest bundled with the CLI. Always update CLI before stack. Use `exe-os update --check` to see if a CLI update is available. Use `exe-os stack-update --check` to see stack status. For non-interactive/SSH: use `--yes` or `-y` flag. Never run `npm install -g` inside a tmux agent session \u2014 have the founder or COO do it from the host shell. If stack-update fails with EACCES on /opt/exe-stack, run: `sudo mkdir -p /opt/exe-stack && sudo chown $(whoami) /opt/exe-stack` then retry."
+      },
+      {
+        title: "CLI version vs stack version \u2014 two tracks, both normal",
+        domain: "operations",
+        priority: "p0",
+        content: "exe-os has TWO version numbers that move independently. This is normal \u2014 do not treat a mismatch as an error. (1) CLI version (e.g. 0.9.89, 0.9.90) \u2014 the npm package installed locally. Updates frequently: bug fixes, new MCP tools, platform procedures, search improvements, client-side changes. Update with `npm install -g @askexenow/exe-os@latest`. (2) Stack version (e.g. 0.9.7, 0.9.8) \u2014 the Docker images on the VPS. Updates less frequently: only when server-side daemon, gateway, wiki, or CRM images need rebuilding. Update with `exe-os stack-update --target <version> --yes`. The CLI version will almost always be higher than the stack version. A CLI at 0.9.90 with a stack at 0.9.8 is perfectly normal \u2014 it means the CLI got 12 patches since the last Docker image rebuild. Only update the stack when: (a) the boot brief surfaces a fix that mentions 'stack update required', (b) a new stack manifest version is bundled in the CLI (`exe-os stack-update --check` shows pending changes), or (c) AskExe support explicitly tells you to. Do NOT attempt to make the numbers match \u2014 they are separate tracks."
       },
       // --- Operations ---
       {

package/dist/hooks/bug-report-worker.js

@@ -4618,7 +4618,13 @@ var init_platform_procedures = __esm({
         title: "How to update exe-os \u2014 CLI first, then stack",
         domain: "operations",
         priority: "p0",
-        content: "When bug fixes or features are available (surfaced at boot via list_my_bug_reports/list_my_feature_requests), update in two steps: (1) CLI: `npm install -g @askexenow/exe-os@latest` \u2014 this updates the local tools, MCP server, and bundled stack manifest. Must happen first so the stack-update tool itself has the latest fixes. (2) Stack (VPS only): `exe-os stack-update --target <version> --yes` \u2014 pulls new Docker images and restarts services. The target version comes from the stack manifest bundled with the CLI. Always update CLI before stack. Use `exe-os update --check` to see if a CLI update is available. Use `exe-os stack-update --check` to see stack status. For non-interactive/SSH: use `--yes` or `-y` flag. Never run `npm install -g` inside a tmux agent session \u2014 have the founder or COO do it from the host shell."
+        content: "When bug fixes or features are available (surfaced at boot via list_my_bug_reports/list_my_feature_requests), update in two steps: (1) CLI: `npm install -g @askexenow/exe-os@latest` \u2014 this updates the local tools, MCP server, and bundled stack manifest. Must happen first so the stack-update tool itself has the latest fixes. (2) Stack (VPS only): `exe-os stack-update --target <version> --yes` \u2014 pulls new Docker images and restarts services. The target version comes from the stack manifest bundled with the CLI. Always update CLI before stack. Use `exe-os update --check` to see if a CLI update is available. Use `exe-os stack-update --check` to see stack status. For non-interactive/SSH: use `--yes` or `-y` flag. Never run `npm install -g` inside a tmux agent session \u2014 have the founder or COO do it from the host shell. If stack-update fails with EACCES on /opt/exe-stack, run: `sudo mkdir -p /opt/exe-stack && sudo chown $(whoami) /opt/exe-stack` then retry."
+      },
+      {
+        title: "CLI version vs stack version \u2014 two tracks, both normal",
+        domain: "operations",
+        priority: "p0",
+        content: "exe-os has TWO version numbers that move independently. This is normal \u2014 do not treat a mismatch as an error. (1) CLI version (e.g. 0.9.89, 0.9.90) \u2014 the npm package installed locally. Updates frequently: bug fixes, new MCP tools, platform procedures, search improvements, client-side changes. Update with `npm install -g @askexenow/exe-os@latest`. (2) Stack version (e.g. 0.9.7, 0.9.8) \u2014 the Docker images on the VPS. Updates less frequently: only when server-side daemon, gateway, wiki, or CRM images need rebuilding. Update with `exe-os stack-update --target <version> --yes`. The CLI version will almost always be higher than the stack version. A CLI at 0.9.90 with a stack at 0.9.8 is perfectly normal \u2014 it means the CLI got 12 patches since the last Docker image rebuild. Only update the stack when: (a) the boot brief surfaces a fix that mentions 'stack update required', (b) a new stack manifest version is bundled in the CLI (`exe-os stack-update --check` shows pending changes), or (c) AskExe support explicitly tells you to. Do NOT attempt to make the numbers match \u2014 they are separate tracks."
       },
       // --- Operations ---
       {

package/dist/hooks/codex-stop-task-finalizer.js

@@ -4301,7 +4301,13 @@ var init_platform_procedures = __esm({
         title: "How to update exe-os \u2014 CLI first, then stack",
         domain: "operations",
         priority: "p0",
-        content: "When bug fixes or features are available (surfaced at boot via list_my_bug_reports/list_my_feature_requests), update in two steps: (1) CLI: `npm install -g @askexenow/exe-os@latest` \u2014 this updates the local tools, MCP server, and bundled stack manifest. Must happen first so the stack-update tool itself has the latest fixes. (2) Stack (VPS only): `exe-os stack-update --target <version> --yes` \u2014 pulls new Docker images and restarts services. The target version comes from the stack manifest bundled with the CLI. Always update CLI before stack. Use `exe-os update --check` to see if a CLI update is available. Use `exe-os stack-update --check` to see stack status. For non-interactive/SSH: use `--yes` or `-y` flag. Never run `npm install -g` inside a tmux agent session \u2014 have the founder or COO do it from the host shell."
+        content: "When bug fixes or features are available (surfaced at boot via list_my_bug_reports/list_my_feature_requests), update in two steps: (1) CLI: `npm install -g @askexenow/exe-os@latest` \u2014 this updates the local tools, MCP server, and bundled stack manifest. Must happen first so the stack-update tool itself has the latest fixes. (2) Stack (VPS only): `exe-os stack-update --target <version> --yes` \u2014 pulls new Docker images and restarts services. The target version comes from the stack manifest bundled with the CLI. Always update CLI before stack. Use `exe-os update --check` to see if a CLI update is available. Use `exe-os stack-update --check` to see stack status. For non-interactive/SSH: use `--yes` or `-y` flag. Never run `npm install -g` inside a tmux agent session \u2014 have the founder or COO do it from the host shell. If stack-update fails with EACCES on /opt/exe-stack, run: `sudo mkdir -p /opt/exe-stack && sudo chown $(whoami) /opt/exe-stack` then retry."
+      },
+      {
+        title: "CLI version vs stack version \u2014 two tracks, both normal",
+        domain: "operations",
+        priority: "p0",
+        content: "exe-os has TWO version numbers that move independently. This is normal \u2014 do not treat a mismatch as an error. (1) CLI version (e.g. 0.9.89, 0.9.90) \u2014 the npm package installed locally. Updates frequently: bug fixes, new MCP tools, platform procedures, search improvements, client-side changes. Update with `npm install -g @askexenow/exe-os@latest`. (2) Stack version (e.g. 0.9.7, 0.9.8) \u2014 the Docker images on the VPS. Updates less frequently: only when server-side daemon, gateway, wiki, or CRM images need rebuilding. Update with `exe-os stack-update --target <version> --yes`. The CLI version will almost always be higher than the stack version. A CLI at 0.9.90 with a stack at 0.9.8 is perfectly normal \u2014 it means the CLI got 12 patches since the last Docker image rebuild. Only update the stack when: (a) the boot brief surfaces a fix that mentions 'stack update required', (b) a new stack manifest version is bundled in the CLI (`exe-os stack-update --check` shows pending changes), or (c) AskExe support explicitly tells you to. Do NOT attempt to make the numbers match \u2014 they are separate tracks."
       },
       // --- Operations ---
       {

package/dist/hooks/commit-complete.js

@@ -7989,7 +7989,13 @@ var init_platform_procedures = __esm({
         title: "How to update exe-os \u2014 CLI first, then stack",
         domain: "operations",
         priority: "p0",
-        content: "When bug fixes or features are available (surfaced at boot via list_my_bug_reports/list_my_feature_requests), update in two steps: (1) CLI: `npm install -g @askexenow/exe-os@latest` \u2014 this updates the local tools, MCP server, and bundled stack manifest. Must happen first so the stack-update tool itself has the latest fixes. (2) Stack (VPS only): `exe-os stack-update --target <version> --yes` \u2014 pulls new Docker images and restarts services. The target version comes from the stack manifest bundled with the CLI. Always update CLI before stack. Use `exe-os update --check` to see if a CLI update is available. Use `exe-os stack-update --check` to see stack status. For non-interactive/SSH: use `--yes` or `-y` flag. Never run `npm install -g` inside a tmux agent session \u2014 have the founder or COO do it from the host shell."
+        content: "When bug fixes or features are available (surfaced at boot via list_my_bug_reports/list_my_feature_requests), update in two steps: (1) CLI: `npm install -g @askexenow/exe-os@latest` \u2014 this updates the local tools, MCP server, and bundled stack manifest. Must happen first so the stack-update tool itself has the latest fixes. (2) Stack (VPS only): `exe-os stack-update --target <version> --yes` \u2014 pulls new Docker images and restarts services. The target version comes from the stack manifest bundled with the CLI. Always update CLI before stack. Use `exe-os update --check` to see if a CLI update is available. Use `exe-os stack-update --check` to see stack status. For non-interactive/SSH: use `--yes` or `-y` flag. Never run `npm install -g` inside a tmux agent session \u2014 have the founder or COO do it from the host shell. If stack-update fails with EACCES on /opt/exe-stack, run: `sudo mkdir -p /opt/exe-stack && sudo chown $(whoami) /opt/exe-stack` then retry."
+      },
+      {
+        title: "CLI version vs stack version \u2014 two tracks, both normal",
+        domain: "operations",
+        priority: "p0",
+        content: "exe-os has TWO version numbers that move independently. This is normal \u2014 do not treat a mismatch as an error. (1) CLI version (e.g. 0.9.89, 0.9.90) \u2014 the npm package installed locally. Updates frequently: bug fixes, new MCP tools, platform procedures, search improvements, client-side changes. Update with `npm install -g @askexenow/exe-os@latest`. (2) Stack version (e.g. 0.9.7, 0.9.8) \u2014 the Docker images on the VPS. Updates less frequently: only when server-side daemon, gateway, wiki, or CRM images need rebuilding. Update with `exe-os stack-update --target <version> --yes`. The CLI version will almost always be higher than the stack version. A CLI at 0.9.90 with a stack at 0.9.8 is perfectly normal \u2014 it means the CLI got 12 patches since the last Docker image rebuild. Only update the stack when: (a) the boot brief surfaces a fix that mentions 'stack update required', (b) a new stack manifest version is bundled in the CLI (`exe-os stack-update --check` shows pending changes), or (c) AskExe support explicitly tells you to. Do NOT attempt to make the numbers match \u2014 they are separate tracks."
       },
       // --- Operations ---
       {

package/dist/hooks/error-recall.js

@@ -4209,7 +4209,13 @@ var init_platform_procedures = __esm({
         title: "How to update exe-os \u2014 CLI first, then stack",
         domain: "operations",
         priority: "p0",
-        content: "When bug fixes or features are available (surfaced at boot via list_my_bug_reports/list_my_feature_requests), update in two steps: (1) CLI: `npm install -g @askexenow/exe-os@latest` \u2014 this updates the local tools, MCP server, and bundled stack manifest. Must happen first so the stack-update tool itself has the latest fixes. (2) Stack (VPS only): `exe-os stack-update --target <version> --yes` \u2014 pulls new Docker images and restarts services. The target version comes from the stack manifest bundled with the CLI. Always update CLI before stack. Use `exe-os update --check` to see if a CLI update is available. Use `exe-os stack-update --check` to see stack status. For non-interactive/SSH: use `--yes` or `-y` flag. Never run `npm install -g` inside a tmux agent session \u2014 have the founder or COO do it from the host shell."
+        content: "When bug fixes or features are available (surfaced at boot via list_my_bug_reports/list_my_feature_requests), update in two steps: (1) CLI: `npm install -g @askexenow/exe-os@latest` \u2014 this updates the local tools, MCP server, and bundled stack manifest. Must happen first so the stack-update tool itself has the latest fixes. (2) Stack (VPS only): `exe-os stack-update --target <version> --yes` \u2014 pulls new Docker images and restarts services. The target version comes from the stack manifest bundled with the CLI. Always update CLI before stack. Use `exe-os update --check` to see if a CLI update is available. Use `exe-os stack-update --check` to see stack status. For non-interactive/SSH: use `--yes` or `-y` flag. Never run `npm install -g` inside a tmux agent session \u2014 have the founder or COO do it from the host shell. If stack-update fails with EACCES on /opt/exe-stack, run: `sudo mkdir -p /opt/exe-stack && sudo chown $(whoami) /opt/exe-stack` then retry."
+      },
+      {
+        title: "CLI version vs stack version \u2014 two tracks, both normal",
+        domain: "operations",
+        priority: "p0",
+        content: "exe-os has TWO version numbers that move independently. This is normal \u2014 do not treat a mismatch as an error. (1) CLI version (e.g. 0.9.89, 0.9.90) \u2014 the npm package installed locally. Updates frequently: bug fixes, new MCP tools, platform procedures, search improvements, client-side changes. Update with `npm install -g @askexenow/exe-os@latest`. (2) Stack version (e.g. 0.9.7, 0.9.8) \u2014 the Docker images on the VPS. Updates less frequently: only when server-side daemon, gateway, wiki, or CRM images need rebuilding. Update with `exe-os stack-update --target <version> --yes`. The CLI version will almost always be higher than the stack version. A CLI at 0.9.90 with a stack at 0.9.8 is perfectly normal \u2014 it means the CLI got 12 patches since the last Docker image rebuild. Only update the stack when: (a) the boot brief surfaces a fix that mentions 'stack update required', (b) a new stack manifest version is bundled in the CLI (`exe-os stack-update --check` shows pending changes), or (c) AskExe support explicitly tells you to. Do NOT attempt to make the numbers match \u2014 they are separate tracks."
       },
       // --- Operations ---
       {