@askexenow/exe-os 0.9.104 → 0.9.106

package/dist/bin/bulk-sync-postgres.js

@@ -1606,7 +1606,15 @@ function getClient() {
   if (!_resilientClient) {
     return _adapterClient;
   }
-  return _resilientClient;
+  if (process.env.EXE_DB_READONLY === "1") {
+    return _resilientClient;
+  }
+  process.stderr.write(
+    "[database] ERROR: Daemon is not running \u2014 refusing direct SQLite write access.\n[database] Direct writes bypass the single-writer gate and corrupt FTS5 indexes.\n[database] Restart the daemon: kill $(cat ~/.exe-os/exed.pid) && exe-os update\n[database] Or set EXE_DB_READONLY=1 if you only need read access.\n"
+  );
+  throw new Error(
+    "Daemon not running. Direct SQLite writes are blocked to prevent FTS5 corruption. Restart daemon or set EXE_DB_READONLY=1 for read-only access."
+  );
 }
 async function initDaemonClient() {
   if (process.env.DATABASE_URL && process.env.EXE_USE_POSTGRES === "1") return;
@@ -3935,7 +3943,7 @@ var init_platform_procedures = __esm({
         title: "Bug report status check \u2014 surface available fixes on boot",
         domain: "support",
         priority: "p1",
-        content: "Once per session (COO boot only, never repeat), call list_my_bug_reports to check if any previously filed bug reports have been fixed by AskExe. If any report has status 'fixed' with a fixed_version, surface it to the founder immediately: '\u{1F527} N bug fix(es) available \u2014 run exe-os update to get version X.Y.Z'. This is a one-time check at boot, not a recurring poll. If no reports exist or none are fixed, skip silently. If the MCP tool is unavailable or the network call fails, skip silently \u2014 this is informational, not blocking."
+        content: "Once per session (COO boot only, never repeat), call support(action='list_my_bugs') to check if any previously filed bug reports have been fixed by AskExe. If any report has status 'closed' with a fixed_version, surface it to the founder immediately: '\u{1F527} N bug fix(es) available \u2014 run exe-os update to get version X.Y.Z'. You can also file new bugs with support(action='create_bug') and check status anytime with support(action='list_my_bugs'). This boot check is one-time, not a recurring poll. If the tool is unavailable, skip silently."
       },
       {
         title: "Feature request triage \u2014 upstream feature vs local customization",
@@ -3947,7 +3955,7 @@ var init_platform_procedures = __esm({
         title: "Feature request status check \u2014 surface shipped features on boot",
         domain: "support",
         priority: "p1",
-        content: "Once per session (COO boot only, never repeat), call list_my_feature_requests to check if any previously filed feature requests have been shipped by AskExe. If any request has status 'shipped' with a shipped_version, surface it to the founder immediately: '\u{1F680} N feature(s) shipped \u2014 run exe-os update to get version X.Y.Z'. This is a one-time check at boot, not a recurring poll. If no requests exist or none are shipped, skip silently. If the MCP tool is unavailable or the network call fails, skip silently \u2014 this is informational, not blocking."
+        content: "Once per session (COO boot only, never repeat), call support(action='list_my_features') to check if any previously filed feature requests have been shipped by AskExe. If any request has status 'shipped' with a shipped_version, surface it to the founder immediately: '\u{1F680} N feature(s) shipped \u2014 run exe-os update to get version X.Y.Z'. You can also file new requests with support(action='create_feature') and check status anytime with support(action='list_my_features'). This boot check is one-time, not a recurring poll. If the tool is unavailable, skip silently."
       },
       // --- Tool guidance ---
       {
@@ -3983,6 +3991,18 @@ var init_platform_procedures = __esm({
         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."
       },
+      {
+        title: "Update lifecycle \u2014 what each command does and what picks up new code",
+        domain: "operations",
+        priority: "p0",
+        content: "Three update paths exist \u2014 know which does what. (1) `npm install -g @askexenow/exe-os@latest` \u2014 customer update. Replaces all dist/ files. postinstall copies slash commands AND restarts the daemon automatically. MCP server picks up new code on next `/mcp` reconnect or new Claude Code session. Hooks pick up new code on next session (they spawn fresh processes). (2) `exe-os update` \u2014 interactive update command. Runs `npm install -g` then `install --global` which restarts daemon, regenerates session wrappers, normalizes roster, registers Codex hooks. This is the recommended customer path. (3) `npm run deploy` \u2014 dev-only (COO/CTO on main branch). Builds, installs globally, runs `install --global`, restarts daemon. Never run from a worktree. NEVER confuse `exe-os setup` (first-time setup wizard for new installs) with `exe-os update` (update existing install). Setup creates encryption keys, configures cloud, runs first sync. Update just replaces code and restarts services. They are completely different commands."
+      },
+      {
+        title: "First install \u2014 setup wizard and license activation",
+        domain: "operations",
+        priority: "p1",
+        content: "Fresh install: `npm install -g @askexenow/exe-os` then run `exe` to start the setup wizard. The wizard prompts for: encryption passphrase (creates master key), license key (exe_sk_* from AskExe team), COO name, and optional team members. No license key = free tier (1 employee, 5K memories). After setup: hooks install automatically, MCP server registers in ~/.claude.json, daemon starts. Verify health: run `exe-os healthcheck` or use mcp_ping() tool."
+      },
       // --- Operations ---
       {
         title: "Managers must supervise deployed workers",
@@ -4033,12 +4053,6 @@ var init_platform_procedures = __esm({
         priority: "p0",
         content: "When you dispatch work, you OWN the review. Check list_tasks(status='needs_review') on EVERY prompt \u2014 don't wait for intercom nudges (they're unreliable). When a task shows needs_review: (1) read the deliverable (git diff in worktree, exe/output/ files, or task result summary), (2) verify it works (tsc, build, run), (3) close_task if good or create a fix task if not. Reviews sitting >30 minutes is a pipeline stall. The whole chain: worker calls update_task(done) \u2192 system flags needs_review \u2192 manager pulls and verifies \u2192 close_task \u2192 COO reviews manager's work \u2192 merge to main. Every level actively pulls \u2014 nobody waits."
       },
-      {
-        title: "Bug fix lifecycle \u2014 triage upstream after every verified fix so customers see the status",
-        domain: "workflow",
-        priority: "p0",
-        content: "When a bug from support(action='list_bugs') is fixed and verified, the reviewer MUST triage it upstream: support(action='triage_bug', id='<bug-id>', notes='<what was fixed>', fixed_version='<version>', linked_commit='<hash>'). This closes the bug in the customer's view \u2014 their COO checks list_my_bugs and sees status change from open \u2192 closed with the fix version. Without triage, customers see 'open' forever even after the fix ships. Same for feature requests: support(action='triage_feature', ..., shipped_version='<version>'). Triage is part of the review gate \u2014 a fix is not done until the upstream report is closed."
-      },
       {
         title: "Intercom is a speedup, not delivery \u2014 DB is the source of truth",
         domain: "architecture",
@@ -4094,7 +4108,7 @@ var init_platform_procedures = __esm({
         title: "MCP tools \u2014 identity, behavior, and support",
         domain: "tool-use",
         priority: "p1",
-        content: `identity(action="get") / get_identity: read an agent's exe.md (Layer 1 identity). identity(action="update") / update_identity: write an agent's exe.md. Identity > behavior. behavior(action="store") / store_behavior: record a correction or pattern (Layer 2 expertise). behavior(action="list") / list_behaviors: view active behaviors. behavior(action="deactivate") / deactivate_behavior: soft-delete a stale behavior. support(action="create_bug") / create_bug_report: file a bug report to AskExe (title, description, severity). support(action="create_feature") / create_feature_request: file a feature request. support(action="health") / support_health: check support server readiness. support(action="triage_bug"): triage a bug (id, triage_notes). AskExe-internal only. CRITICAL: triage uses triage_notes NOT notes.`
+        content: `identity(action="get") / get_identity: read an agent's exe.md (Layer 1 identity). identity(action="update") / update_identity: write an agent's exe.md. Identity > behavior. behavior(action="store") / store_behavior: record a correction or pattern (Layer 2 expertise). behavior(action="list") / list_behaviors: view active behaviors. behavior(action="deactivate") / deactivate_behavior: soft-delete a stale behavior. support(action="create_bug"): file a bug report (title, description, severity p0-p3). Auto-delivers to AskExe. support(action="create_feature"): file a feature request (title, description, use_case). support(action="list_my_bugs"): check status of YOUR filed bug reports \u2014 see which are open, triaged, or fixed with version number. support(action="list_my_features"): check status of YOUR filed feature requests \u2014 see which are planned, shipped, or closed. support(action="health"): verify support server is reachable. When a bug you filed shows status='fixed' with a fixed_version, update exe-os to that version to get the fix. support(action="triage_bug"): AskExe-internal only. CRITICAL: triage uses triage_notes NOT notes.`
       },
       {
         title: "MCP tools \u2014 communication and messaging",

package/dist/bin/cleanup-stale-review-tasks.js

@@ -1832,7 +1832,15 @@ function getClient() {
   if (!_resilientClient) {
     return _adapterClient;
   }
-  return _resilientClient;
+  if (process.env.EXE_DB_READONLY === "1") {
+    return _resilientClient;
+  }
+  process.stderr.write(
+    "[database] ERROR: Daemon is not running \u2014 refusing direct SQLite write access.\n[database] Direct writes bypass the single-writer gate and corrupt FTS5 indexes.\n[database] Restart the daemon: kill $(cat ~/.exe-os/exed.pid) && exe-os update\n[database] Or set EXE_DB_READONLY=1 if you only need read access.\n"
+  );
+  throw new Error(
+    "Daemon not running. Direct SQLite writes are blocked to prevent FTS5 corruption. Restart daemon or set EXE_DB_READONLY=1 for read-only access."
+  );
 }
 async function initDaemonClient() {
   if (process.env.DATABASE_URL && process.env.EXE_USE_POSTGRES === "1") return;
@@ -4410,7 +4418,7 @@ var init_platform_procedures = __esm({
         title: "Bug report status check \u2014 surface available fixes on boot",
         domain: "support",
         priority: "p1",
-        content: "Once per session (COO boot only, never repeat), call list_my_bug_reports to check if any previously filed bug reports have been fixed by AskExe. If any report has status 'fixed' with a fixed_version, surface it to the founder immediately: '\u{1F527} N bug fix(es) available \u2014 run exe-os update to get version X.Y.Z'. This is a one-time check at boot, not a recurring poll. If no reports exist or none are fixed, skip silently. If the MCP tool is unavailable or the network call fails, skip silently \u2014 this is informational, not blocking."
+        content: "Once per session (COO boot only, never repeat), call support(action='list_my_bugs') to check if any previously filed bug reports have been fixed by AskExe. If any report has status 'closed' with a fixed_version, surface it to the founder immediately: '\u{1F527} N bug fix(es) available \u2014 run exe-os update to get version X.Y.Z'. You can also file new bugs with support(action='create_bug') and check status anytime with support(action='list_my_bugs'). This boot check is one-time, not a recurring poll. If the tool is unavailable, skip silently."
       },
       {
         title: "Feature request triage \u2014 upstream feature vs local customization",
@@ -4422,7 +4430,7 @@ var init_platform_procedures = __esm({
         title: "Feature request status check \u2014 surface shipped features on boot",
         domain: "support",
         priority: "p1",
-        content: "Once per session (COO boot only, never repeat), call list_my_feature_requests to check if any previously filed feature requests have been shipped by AskExe. If any request has status 'shipped' with a shipped_version, surface it to the founder immediately: '\u{1F680} N feature(s) shipped \u2014 run exe-os update to get version X.Y.Z'. This is a one-time check at boot, not a recurring poll. If no requests exist or none are shipped, skip silently. If the MCP tool is unavailable or the network call fails, skip silently \u2014 this is informational, not blocking."
+        content: "Once per session (COO boot only, never repeat), call support(action='list_my_features') to check if any previously filed feature requests have been shipped by AskExe. If any request has status 'shipped' with a shipped_version, surface it to the founder immediately: '\u{1F680} N feature(s) shipped \u2014 run exe-os update to get version X.Y.Z'. You can also file new requests with support(action='create_feature') and check status anytime with support(action='list_my_features'). This boot check is one-time, not a recurring poll. If the tool is unavailable, skip silently."
       },
       // --- Tool guidance ---
       {
@@ -4458,6 +4466,18 @@ var init_platform_procedures = __esm({
         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."
       },
+      {
+        title: "Update lifecycle \u2014 what each command does and what picks up new code",
+        domain: "operations",
+        priority: "p0",
+        content: "Three update paths exist \u2014 know which does what. (1) `npm install -g @askexenow/exe-os@latest` \u2014 customer update. Replaces all dist/ files. postinstall copies slash commands AND restarts the daemon automatically. MCP server picks up new code on next `/mcp` reconnect or new Claude Code session. Hooks pick up new code on next session (they spawn fresh processes). (2) `exe-os update` \u2014 interactive update command. Runs `npm install -g` then `install --global` which restarts daemon, regenerates session wrappers, normalizes roster, registers Codex hooks. This is the recommended customer path. (3) `npm run deploy` \u2014 dev-only (COO/CTO on main branch). Builds, installs globally, runs `install --global`, restarts daemon. Never run from a worktree. NEVER confuse `exe-os setup` (first-time setup wizard for new installs) with `exe-os update` (update existing install). Setup creates encryption keys, configures cloud, runs first sync. Update just replaces code and restarts services. They are completely different commands."
+      },
+      {
+        title: "First install \u2014 setup wizard and license activation",
+        domain: "operations",
+        priority: "p1",
+        content: "Fresh install: `npm install -g @askexenow/exe-os` then run `exe` to start the setup wizard. The wizard prompts for: encryption passphrase (creates master key), license key (exe_sk_* from AskExe team), COO name, and optional team members. No license key = free tier (1 employee, 5K memories). After setup: hooks install automatically, MCP server registers in ~/.claude.json, daemon starts. Verify health: run `exe-os healthcheck` or use mcp_ping() tool."
+      },
       // --- Operations ---
       {
         title: "Managers must supervise deployed workers",
@@ -4508,12 +4528,6 @@ var init_platform_procedures = __esm({
         priority: "p0",
         content: "When you dispatch work, you OWN the review. Check list_tasks(status='needs_review') on EVERY prompt \u2014 don't wait for intercom nudges (they're unreliable). When a task shows needs_review: (1) read the deliverable (git diff in worktree, exe/output/ files, or task result summary), (2) verify it works (tsc, build, run), (3) close_task if good or create a fix task if not. Reviews sitting >30 minutes is a pipeline stall. The whole chain: worker calls update_task(done) \u2192 system flags needs_review \u2192 manager pulls and verifies \u2192 close_task \u2192 COO reviews manager's work \u2192 merge to main. Every level actively pulls \u2014 nobody waits."
       },
-      {
-        title: "Bug fix lifecycle \u2014 triage upstream after every verified fix so customers see the status",
-        domain: "workflow",
-        priority: "p0",
-        content: "When a bug from support(action='list_bugs') is fixed and verified, the reviewer MUST triage it upstream: support(action='triage_bug', id='<bug-id>', notes='<what was fixed>', fixed_version='<version>', linked_commit='<hash>'). This closes the bug in the customer's view \u2014 their COO checks list_my_bugs and sees status change from open \u2192 closed with the fix version. Without triage, customers see 'open' forever even after the fix ships. Same for feature requests: support(action='triage_feature', ..., shipped_version='<version>'). Triage is part of the review gate \u2014 a fix is not done until the upstream report is closed."
-      },
       {
         title: "Intercom is a speedup, not delivery \u2014 DB is the source of truth",
         domain: "architecture",
@@ -4569,7 +4583,7 @@ var init_platform_procedures = __esm({
         title: "MCP tools \u2014 identity, behavior, and support",
         domain: "tool-use",
         priority: "p1",
-        content: `identity(action="get") / get_identity: read an agent's exe.md (Layer 1 identity). identity(action="update") / update_identity: write an agent's exe.md. Identity > behavior. behavior(action="store") / store_behavior: record a correction or pattern (Layer 2 expertise). behavior(action="list") / list_behaviors: view active behaviors. behavior(action="deactivate") / deactivate_behavior: soft-delete a stale behavior. support(action="create_bug") / create_bug_report: file a bug report to AskExe (title, description, severity). support(action="create_feature") / create_feature_request: file a feature request. support(action="health") / support_health: check support server readiness. support(action="triage_bug"): triage a bug (id, triage_notes). AskExe-internal only. CRITICAL: triage uses triage_notes NOT notes.`
+        content: `identity(action="get") / get_identity: read an agent's exe.md (Layer 1 identity). identity(action="update") / update_identity: write an agent's exe.md. Identity > behavior. behavior(action="store") / store_behavior: record a correction or pattern (Layer 2 expertise). behavior(action="list") / list_behaviors: view active behaviors. behavior(action="deactivate") / deactivate_behavior: soft-delete a stale behavior. support(action="create_bug"): file a bug report (title, description, severity p0-p3). Auto-delivers to AskExe. support(action="create_feature"): file a feature request (title, description, use_case). support(action="list_my_bugs"): check status of YOUR filed bug reports \u2014 see which are open, triaged, or fixed with version number. support(action="list_my_features"): check status of YOUR filed feature requests \u2014 see which are planned, shipped, or closed. support(action="health"): verify support server is reachable. When a bug you filed shows status='fixed' with a fixed_version, update exe-os to that version to get the fix. support(action="triage_bug"): AskExe-internal only. CRITICAL: triage uses triage_notes NOT notes.`
       },
       {
         title: "MCP tools \u2014 communication and messaging",

package/dist/bin/cli.js

@@ -4487,7 +4487,15 @@ function getClient() {
   if (!_resilientClient) {
     return _adapterClient;
   }
-  return _resilientClient;
+  if (process.env.EXE_DB_READONLY === "1") {
+    return _resilientClient;
+  }
+  process.stderr.write(
+    "[database] ERROR: Daemon is not running \u2014 refusing direct SQLite write access.\n[database] Direct writes bypass the single-writer gate and corrupt FTS5 indexes.\n[database] Restart the daemon: kill $(cat ~/.exe-os/exed.pid) && exe-os update\n[database] Or set EXE_DB_READONLY=1 if you only need read access.\n"
+  );
+  throw new Error(
+    "Daemon not running. Direct SQLite writes are blocked to prevent FTS5 corruption. Restart daemon or set EXE_DB_READONLY=1 for read-only access."
+  );
 }
 async function initDaemonClient() {
   if (process.env.DATABASE_URL && process.env.EXE_USE_POSTGRES === "1") return;
@@ -9116,7 +9124,7 @@ var init_platform_procedures = __esm({
         title: "Bug report status check \u2014 surface available fixes on boot",
         domain: "support",
         priority: "p1",
-        content: "Once per session (COO boot only, never repeat), call list_my_bug_reports to check if any previously filed bug reports have been fixed by AskExe. If any report has status 'fixed' with a fixed_version, surface it to the founder immediately: '\u{1F527} N bug fix(es) available \u2014 run exe-os update to get version X.Y.Z'. This is a one-time check at boot, not a recurring poll. If no reports exist or none are fixed, skip silently. If the MCP tool is unavailable or the network call fails, skip silently \u2014 this is informational, not blocking."
+        content: "Once per session (COO boot only, never repeat), call support(action='list_my_bugs') to check if any previously filed bug reports have been fixed by AskExe. If any report has status 'closed' with a fixed_version, surface it to the founder immediately: '\u{1F527} N bug fix(es) available \u2014 run exe-os update to get version X.Y.Z'. You can also file new bugs with support(action='create_bug') and check status anytime with support(action='list_my_bugs'). This boot check is one-time, not a recurring poll. If the tool is unavailable, skip silently."
       },
       {
         title: "Feature request triage \u2014 upstream feature vs local customization",
@@ -9128,7 +9136,7 @@ var init_platform_procedures = __esm({
         title: "Feature request status check \u2014 surface shipped features on boot",
         domain: "support",
         priority: "p1",
-        content: "Once per session (COO boot only, never repeat), call list_my_feature_requests to check if any previously filed feature requests have been shipped by AskExe. If any request has status 'shipped' with a shipped_version, surface it to the founder immediately: '\u{1F680} N feature(s) shipped \u2014 run exe-os update to get version X.Y.Z'. This is a one-time check at boot, not a recurring poll. If no requests exist or none are shipped, skip silently. If the MCP tool is unavailable or the network call fails, skip silently \u2014 this is informational, not blocking."
+        content: "Once per session (COO boot only, never repeat), call support(action='list_my_features') to check if any previously filed feature requests have been shipped by AskExe. If any request has status 'shipped' with a shipped_version, surface it to the founder immediately: '\u{1F680} N feature(s) shipped \u2014 run exe-os update to get version X.Y.Z'. You can also file new requests with support(action='create_feature') and check status anytime with support(action='list_my_features'). This boot check is one-time, not a recurring poll. If the tool is unavailable, skip silently."
       },
       // --- Tool guidance ---
       {
@@ -9164,6 +9172,18 @@ var init_platform_procedures = __esm({
         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."
       },
+      {
+        title: "Update lifecycle \u2014 what each command does and what picks up new code",
+        domain: "operations",
+        priority: "p0",
+        content: "Three update paths exist \u2014 know which does what. (1) `npm install -g @askexenow/exe-os@latest` \u2014 customer update. Replaces all dist/ files. postinstall copies slash commands AND restarts the daemon automatically. MCP server picks up new code on next `/mcp` reconnect or new Claude Code session. Hooks pick up new code on next session (they spawn fresh processes). (2) `exe-os update` \u2014 interactive update command. Runs `npm install -g` then `install --global` which restarts daemon, regenerates session wrappers, normalizes roster, registers Codex hooks. This is the recommended customer path. (3) `npm run deploy` \u2014 dev-only (COO/CTO on main branch). Builds, installs globally, runs `install --global`, restarts daemon. Never run from a worktree. NEVER confuse `exe-os setup` (first-time setup wizard for new installs) with `exe-os update` (update existing install). Setup creates encryption keys, configures cloud, runs first sync. Update just replaces code and restarts services. They are completely different commands."
+      },
+      {
+        title: "First install \u2014 setup wizard and license activation",
+        domain: "operations",
+        priority: "p1",
+        content: "Fresh install: `npm install -g @askexenow/exe-os` then run `exe` to start the setup wizard. The wizard prompts for: encryption passphrase (creates master key), license key (exe_sk_* from AskExe team), COO name, and optional team members. No license key = free tier (1 employee, 5K memories). After setup: hooks install automatically, MCP server registers in ~/.claude.json, daemon starts. Verify health: run `exe-os healthcheck` or use mcp_ping() tool."
+      },
       // --- Operations ---
       {
         title: "Managers must supervise deployed workers",
@@ -9214,12 +9234,6 @@ var init_platform_procedures = __esm({
         priority: "p0",
         content: "When you dispatch work, you OWN the review. Check list_tasks(status='needs_review') on EVERY prompt \u2014 don't wait for intercom nudges (they're unreliable). When a task shows needs_review: (1) read the deliverable (git diff in worktree, exe/output/ files, or task result summary), (2) verify it works (tsc, build, run), (3) close_task if good or create a fix task if not. Reviews sitting >30 minutes is a pipeline stall. The whole chain: worker calls update_task(done) \u2192 system flags needs_review \u2192 manager pulls and verifies \u2192 close_task \u2192 COO reviews manager's work \u2192 merge to main. Every level actively pulls \u2014 nobody waits."
       },
-      {
-        title: "Bug fix lifecycle \u2014 triage upstream after every verified fix so customers see the status",
-        domain: "workflow",
-        priority: "p0",
-        content: "When a bug from support(action='list_bugs') is fixed and verified, the reviewer MUST triage it upstream: support(action='triage_bug', id='<bug-id>', notes='<what was fixed>', fixed_version='<version>', linked_commit='<hash>'). This closes the bug in the customer's view \u2014 their COO checks list_my_bugs and sees status change from open \u2192 closed with the fix version. Without triage, customers see 'open' forever even after the fix ships. Same for feature requests: support(action='triage_feature', ..., shipped_version='<version>'). Triage is part of the review gate \u2014 a fix is not done until the upstream report is closed."
-      },
       {
         title: "Intercom is a speedup, not delivery \u2014 DB is the source of truth",
         domain: "architecture",
@@ -9275,7 +9289,7 @@ var init_platform_procedures = __esm({
         title: "MCP tools \u2014 identity, behavior, and support",
         domain: "tool-use",
         priority: "p1",
-        content: `identity(action="get") / get_identity: read an agent's exe.md (Layer 1 identity). identity(action="update") / update_identity: write an agent's exe.md. Identity > behavior. behavior(action="store") / store_behavior: record a correction or pattern (Layer 2 expertise). behavior(action="list") / list_behaviors: view active behaviors. behavior(action="deactivate") / deactivate_behavior: soft-delete a stale behavior. support(action="create_bug") / create_bug_report: file a bug report to AskExe (title, description, severity). support(action="create_feature") / create_feature_request: file a feature request. support(action="health") / support_health: check support server readiness. support(action="triage_bug"): triage a bug (id, triage_notes). AskExe-internal only. CRITICAL: triage uses triage_notes NOT notes.`
+        content: `identity(action="get") / get_identity: read an agent's exe.md (Layer 1 identity). identity(action="update") / update_identity: write an agent's exe.md. Identity > behavior. behavior(action="store") / store_behavior: record a correction or pattern (Layer 2 expertise). behavior(action="list") / list_behaviors: view active behaviors. behavior(action="deactivate") / deactivate_behavior: soft-delete a stale behavior. support(action="create_bug"): file a bug report (title, description, severity p0-p3). Auto-delivers to AskExe. support(action="create_feature"): file a feature request (title, description, use_case). support(action="list_my_bugs"): check status of YOUR filed bug reports \u2014 see which are open, triaged, or fixed with version number. support(action="list_my_features"): check status of YOUR filed feature requests \u2014 see which are planned, shipped, or closed. support(action="health"): verify support server is reachable. When a bug you filed shows status='fixed' with a fixed_version, update exe-os to that version to get the fix. support(action="triage_bug"): AskExe-internal only. CRITICAL: triage uses triage_notes NOT notes.`
       },
       {
         title: "MCP tools \u2014 communication and messaging",

package/dist/bin/exe-agent.js

@@ -1401,7 +1401,7 @@ var PLATFORM_PROCEDURES = [
     title: "Bug report status check \u2014 surface available fixes on boot",
     domain: "support",
     priority: "p1",
-    content: "Once per session (COO boot only, never repeat), call list_my_bug_reports to check if any previously filed bug reports have been fixed by AskExe. If any report has status 'fixed' with a fixed_version, surface it to the founder immediately: '\u{1F527} N bug fix(es) available \u2014 run exe-os update to get version X.Y.Z'. This is a one-time check at boot, not a recurring poll. If no reports exist or none are fixed, skip silently. If the MCP tool is unavailable or the network call fails, skip silently \u2014 this is informational, not blocking."
+    content: "Once per session (COO boot only, never repeat), call support(action='list_my_bugs') to check if any previously filed bug reports have been fixed by AskExe. If any report has status 'closed' with a fixed_version, surface it to the founder immediately: '\u{1F527} N bug fix(es) available \u2014 run exe-os update to get version X.Y.Z'. You can also file new bugs with support(action='create_bug') and check status anytime with support(action='list_my_bugs'). This boot check is one-time, not a recurring poll. If the tool is unavailable, skip silently."
   },
   {
     title: "Feature request triage \u2014 upstream feature vs local customization",
@@ -1413,7 +1413,7 @@ var PLATFORM_PROCEDURES = [
     title: "Feature request status check \u2014 surface shipped features on boot",
     domain: "support",
     priority: "p1",
-    content: "Once per session (COO boot only, never repeat), call list_my_feature_requests to check if any previously filed feature requests have been shipped by AskExe. If any request has status 'shipped' with a shipped_version, surface it to the founder immediately: '\u{1F680} N feature(s) shipped \u2014 run exe-os update to get version X.Y.Z'. This is a one-time check at boot, not a recurring poll. If no requests exist or none are shipped, skip silently. If the MCP tool is unavailable or the network call fails, skip silently \u2014 this is informational, not blocking."
+    content: "Once per session (COO boot only, never repeat), call support(action='list_my_features') to check if any previously filed feature requests have been shipped by AskExe. If any request has status 'shipped' with a shipped_version, surface it to the founder immediately: '\u{1F680} N feature(s) shipped \u2014 run exe-os update to get version X.Y.Z'. You can also file new requests with support(action='create_feature') and check status anytime with support(action='list_my_features'). This boot check is one-time, not a recurring poll. If the tool is unavailable, skip silently."
   },
   // --- Tool guidance ---
   {
@@ -1449,6 +1449,18 @@ var PLATFORM_PROCEDURES = [
     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."
   },
+  {
+    title: "Update lifecycle \u2014 what each command does and what picks up new code",
+    domain: "operations",
+    priority: "p0",
+    content: "Three update paths exist \u2014 know which does what. (1) `npm install -g @askexenow/exe-os@latest` \u2014 customer update. Replaces all dist/ files. postinstall copies slash commands AND restarts the daemon automatically. MCP server picks up new code on next `/mcp` reconnect or new Claude Code session. Hooks pick up new code on next session (they spawn fresh processes). (2) `exe-os update` \u2014 interactive update command. Runs `npm install -g` then `install --global` which restarts daemon, regenerates session wrappers, normalizes roster, registers Codex hooks. This is the recommended customer path. (3) `npm run deploy` \u2014 dev-only (COO/CTO on main branch). Builds, installs globally, runs `install --global`, restarts daemon. Never run from a worktree. NEVER confuse `exe-os setup` (first-time setup wizard for new installs) with `exe-os update` (update existing install). Setup creates encryption keys, configures cloud, runs first sync. Update just replaces code and restarts services. They are completely different commands."
+  },
+  {
+    title: "First install \u2014 setup wizard and license activation",
+    domain: "operations",
+    priority: "p1",
+    content: "Fresh install: `npm install -g @askexenow/exe-os` then run `exe` to start the setup wizard. The wizard prompts for: encryption passphrase (creates master key), license key (exe_sk_* from AskExe team), COO name, and optional team members. No license key = free tier (1 employee, 5K memories). After setup: hooks install automatically, MCP server registers in ~/.claude.json, daemon starts. Verify health: run `exe-os healthcheck` or use mcp_ping() tool."
+  },
   // --- Operations ---
   {
     title: "Managers must supervise deployed workers",
@@ -1499,12 +1511,6 @@ var PLATFORM_PROCEDURES = [
     priority: "p0",
     content: "When you dispatch work, you OWN the review. Check list_tasks(status='needs_review') on EVERY prompt \u2014 don't wait for intercom nudges (they're unreliable). When a task shows needs_review: (1) read the deliverable (git diff in worktree, exe/output/ files, or task result summary), (2) verify it works (tsc, build, run), (3) close_task if good or create a fix task if not. Reviews sitting >30 minutes is a pipeline stall. The whole chain: worker calls update_task(done) \u2192 system flags needs_review \u2192 manager pulls and verifies \u2192 close_task \u2192 COO reviews manager's work \u2192 merge to main. Every level actively pulls \u2014 nobody waits."
   },
-  {
-    title: "Bug fix lifecycle \u2014 triage upstream after every verified fix so customers see the status",
-    domain: "workflow",
-    priority: "p0",
-    content: "When a bug from support(action='list_bugs') is fixed and verified, the reviewer MUST triage it upstream: support(action='triage_bug', id='<bug-id>', notes='<what was fixed>', fixed_version='<version>', linked_commit='<hash>'). This closes the bug in the customer's view \u2014 their COO checks list_my_bugs and sees status change from open \u2192 closed with the fix version. Without triage, customers see 'open' forever even after the fix ships. Same for feature requests: support(action='triage_feature', ..., shipped_version='<version>'). Triage is part of the review gate \u2014 a fix is not done until the upstream report is closed."
-  },
   {
     title: "Intercom is a speedup, not delivery \u2014 DB is the source of truth",
     domain: "architecture",
@@ -1560,7 +1566,7 @@ var PLATFORM_PROCEDURES = [
     title: "MCP tools \u2014 identity, behavior, and support",
     domain: "tool-use",
     priority: "p1",
-    content: `identity(action="get") / get_identity: read an agent's exe.md (Layer 1 identity). identity(action="update") / update_identity: write an agent's exe.md. Identity > behavior. behavior(action="store") / store_behavior: record a correction or pattern (Layer 2 expertise). behavior(action="list") / list_behaviors: view active behaviors. behavior(action="deactivate") / deactivate_behavior: soft-delete a stale behavior. support(action="create_bug") / create_bug_report: file a bug report to AskExe (title, description, severity). support(action="create_feature") / create_feature_request: file a feature request. support(action="health") / support_health: check support server readiness. support(action="triage_bug"): triage a bug (id, triage_notes). AskExe-internal only. CRITICAL: triage uses triage_notes NOT notes.`
+    content: `identity(action="get") / get_identity: read an agent's exe.md (Layer 1 identity). identity(action="update") / update_identity: write an agent's exe.md. Identity > behavior. behavior(action="store") / store_behavior: record a correction or pattern (Layer 2 expertise). behavior(action="list") / list_behaviors: view active behaviors. behavior(action="deactivate") / deactivate_behavior: soft-delete a stale behavior. support(action="create_bug"): file a bug report (title, description, severity p0-p3). Auto-delivers to AskExe. support(action="create_feature"): file a feature request (title, description, use_case). support(action="list_my_bugs"): check status of YOUR filed bug reports \u2014 see which are open, triaged, or fixed with version number. support(action="list_my_features"): check status of YOUR filed feature requests \u2014 see which are planned, shipped, or closed. support(action="health"): verify support server is reachable. When a bug you filed shows status='fixed' with a fixed_version, update exe-os to that version to get the fix. support(action="triage_bug"): AskExe-internal only. CRITICAL: triage uses triage_notes NOT notes.`
   },
   {
     title: "MCP tools \u2014 communication and messaging",

package/dist/bin/exe-assign.js

@@ -1756,7 +1756,15 @@ function getClient() {
   if (!_resilientClient) {
     return _adapterClient;
   }
-  return _resilientClient;
+  if (process.env.EXE_DB_READONLY === "1") {
+    return _resilientClient;
+  }
+  process.stderr.write(
+    "[database] ERROR: Daemon is not running \u2014 refusing direct SQLite write access.\n[database] Direct writes bypass the single-writer gate and corrupt FTS5 indexes.\n[database] Restart the daemon: kill $(cat ~/.exe-os/exed.pid) && exe-os update\n[database] Or set EXE_DB_READONLY=1 if you only need read access.\n"
+  );
+  throw new Error(
+    "Daemon not running. Direct SQLite writes are blocked to prevent FTS5 corruption. Restart daemon or set EXE_DB_READONLY=1 for read-only access."
+  );
 }
 async function initDaemonClient() {
   if (process.env.DATABASE_URL && process.env.EXE_USE_POSTGRES === "1") return;
@@ -3777,7 +3785,7 @@ var init_platform_procedures = __esm({
         title: "Bug report status check \u2014 surface available fixes on boot",
         domain: "support",
         priority: "p1",
-        content: "Once per session (COO boot only, never repeat), call list_my_bug_reports to check if any previously filed bug reports have been fixed by AskExe. If any report has status 'fixed' with a fixed_version, surface it to the founder immediately: '\u{1F527} N bug fix(es) available \u2014 run exe-os update to get version X.Y.Z'. This is a one-time check at boot, not a recurring poll. If no reports exist or none are fixed, skip silently. If the MCP tool is unavailable or the network call fails, skip silently \u2014 this is informational, not blocking."
+        content: "Once per session (COO boot only, never repeat), call support(action='list_my_bugs') to check if any previously filed bug reports have been fixed by AskExe. If any report has status 'closed' with a fixed_version, surface it to the founder immediately: '\u{1F527} N bug fix(es) available \u2014 run exe-os update to get version X.Y.Z'. You can also file new bugs with support(action='create_bug') and check status anytime with support(action='list_my_bugs'). This boot check is one-time, not a recurring poll. If the tool is unavailable, skip silently."
       },
       {
         title: "Feature request triage \u2014 upstream feature vs local customization",
@@ -3789,7 +3797,7 @@ var init_platform_procedures = __esm({
         title: "Feature request status check \u2014 surface shipped features on boot",
         domain: "support",
         priority: "p1",
-        content: "Once per session (COO boot only, never repeat), call list_my_feature_requests to check if any previously filed feature requests have been shipped by AskExe. If any request has status 'shipped' with a shipped_version, surface it to the founder immediately: '\u{1F680} N feature(s) shipped \u2014 run exe-os update to get version X.Y.Z'. This is a one-time check at boot, not a recurring poll. If no requests exist or none are shipped, skip silently. If the MCP tool is unavailable or the network call fails, skip silently \u2014 this is informational, not blocking."
+        content: "Once per session (COO boot only, never repeat), call support(action='list_my_features') to check if any previously filed feature requests have been shipped by AskExe. If any request has status 'shipped' with a shipped_version, surface it to the founder immediately: '\u{1F680} N feature(s) shipped \u2014 run exe-os update to get version X.Y.Z'. You can also file new requests with support(action='create_feature') and check status anytime with support(action='list_my_features'). This boot check is one-time, not a recurring poll. If the tool is unavailable, skip silently."
       },
       // --- Tool guidance ---
       {
@@ -3825,6 +3833,18 @@ var init_platform_procedures = __esm({
         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."
       },
+      {
+        title: "Update lifecycle \u2014 what each command does and what picks up new code",
+        domain: "operations",
+        priority: "p0",
+        content: "Three update paths exist \u2014 know which does what. (1) `npm install -g @askexenow/exe-os@latest` \u2014 customer update. Replaces all dist/ files. postinstall copies slash commands AND restarts the daemon automatically. MCP server picks up new code on next `/mcp` reconnect or new Claude Code session. Hooks pick up new code on next session (they spawn fresh processes). (2) `exe-os update` \u2014 interactive update command. Runs `npm install -g` then `install --global` which restarts daemon, regenerates session wrappers, normalizes roster, registers Codex hooks. This is the recommended customer path. (3) `npm run deploy` \u2014 dev-only (COO/CTO on main branch). Builds, installs globally, runs `install --global`, restarts daemon. Never run from a worktree. NEVER confuse `exe-os setup` (first-time setup wizard for new installs) with `exe-os update` (update existing install). Setup creates encryption keys, configures cloud, runs first sync. Update just replaces code and restarts services. They are completely different commands."
+      },
+      {
+        title: "First install \u2014 setup wizard and license activation",
+        domain: "operations",
+        priority: "p1",
+        content: "Fresh install: `npm install -g @askexenow/exe-os` then run `exe` to start the setup wizard. The wizard prompts for: encryption passphrase (creates master key), license key (exe_sk_* from AskExe team), COO name, and optional team members. No license key = free tier (1 employee, 5K memories). After setup: hooks install automatically, MCP server registers in ~/.claude.json, daemon starts. Verify health: run `exe-os healthcheck` or use mcp_ping() tool."
+      },
       // --- Operations ---
       {
         title: "Managers must supervise deployed workers",
@@ -3875,12 +3895,6 @@ var init_platform_procedures = __esm({
         priority: "p0",
         content: "When you dispatch work, you OWN the review. Check list_tasks(status='needs_review') on EVERY prompt \u2014 don't wait for intercom nudges (they're unreliable). When a task shows needs_review: (1) read the deliverable (git diff in worktree, exe/output/ files, or task result summary), (2) verify it works (tsc, build, run), (3) close_task if good or create a fix task if not. Reviews sitting >30 minutes is a pipeline stall. The whole chain: worker calls update_task(done) \u2192 system flags needs_review \u2192 manager pulls and verifies \u2192 close_task \u2192 COO reviews manager's work \u2192 merge to main. Every level actively pulls \u2014 nobody waits."
       },
-      {
-        title: "Bug fix lifecycle \u2014 triage upstream after every verified fix so customers see the status",
-        domain: "workflow",
-        priority: "p0",
-        content: "When a bug from support(action='list_bugs') is fixed and verified, the reviewer MUST triage it upstream: support(action='triage_bug', id='<bug-id>', notes='<what was fixed>', fixed_version='<version>', linked_commit='<hash>'). This closes the bug in the customer's view \u2014 their COO checks list_my_bugs and sees status change from open \u2192 closed with the fix version. Without triage, customers see 'open' forever even after the fix ships. Same for feature requests: support(action='triage_feature', ..., shipped_version='<version>'). Triage is part of the review gate \u2014 a fix is not done until the upstream report is closed."
-      },
       {
         title: "Intercom is a speedup, not delivery \u2014 DB is the source of truth",
         domain: "architecture",
@@ -3936,7 +3950,7 @@ var init_platform_procedures = __esm({
         title: "MCP tools \u2014 identity, behavior, and support",
         domain: "tool-use",
         priority: "p1",
-        content: `identity(action="get") / get_identity: read an agent's exe.md (Layer 1 identity). identity(action="update") / update_identity: write an agent's exe.md. Identity > behavior. behavior(action="store") / store_behavior: record a correction or pattern (Layer 2 expertise). behavior(action="list") / list_behaviors: view active behaviors. behavior(action="deactivate") / deactivate_behavior: soft-delete a stale behavior. support(action="create_bug") / create_bug_report: file a bug report to AskExe (title, description, severity). support(action="create_feature") / create_feature_request: file a feature request. support(action="health") / support_health: check support server readiness. support(action="triage_bug"): triage a bug (id, triage_notes). AskExe-internal only. CRITICAL: triage uses triage_notes NOT notes.`
+        content: `identity(action="get") / get_identity: read an agent's exe.md (Layer 1 identity). identity(action="update") / update_identity: write an agent's exe.md. Identity > behavior. behavior(action="store") / store_behavior: record a correction or pattern (Layer 2 expertise). behavior(action="list") / list_behaviors: view active behaviors. behavior(action="deactivate") / deactivate_behavior: soft-delete a stale behavior. support(action="create_bug"): file a bug report (title, description, severity p0-p3). Auto-delivers to AskExe. support(action="create_feature"): file a feature request (title, description, use_case). support(action="list_my_bugs"): check status of YOUR filed bug reports \u2014 see which are open, triaged, or fixed with version number. support(action="list_my_features"): check status of YOUR filed feature requests \u2014 see which are planned, shipped, or closed. support(action="health"): verify support server is reachable. When a bug you filed shows status='fixed' with a fixed_version, update exe-os to that version to get the fix. support(action="triage_bug"): AskExe-internal only. CRITICAL: triage uses triage_notes NOT notes.`
       },
       {
         title: "MCP tools \u2014 communication and messaging",

package/dist/bin/exe-boot.js

@@ -1908,7 +1908,15 @@ function getClient() {
   if (!_resilientClient) {
     return _adapterClient;
   }
-  return _resilientClient;
+  if (process.env.EXE_DB_READONLY === "1") {
+    return _resilientClient;
+  }
+  process.stderr.write(
+    "[database] ERROR: Daemon is not running \u2014 refusing direct SQLite write access.\n[database] Direct writes bypass the single-writer gate and corrupt FTS5 indexes.\n[database] Restart the daemon: kill $(cat ~/.exe-os/exed.pid) && exe-os update\n[database] Or set EXE_DB_READONLY=1 if you only need read access.\n"
+  );
+  throw new Error(
+    "Daemon not running. Direct SQLite writes are blocked to prevent FTS5 corruption. Restart daemon or set EXE_DB_READONLY=1 for read-only access."
+  );
 }
 async function initDaemonClient() {
   if (process.env.DATABASE_URL && process.env.EXE_USE_POSTGRES === "1") return;
@@ -3465,7 +3473,7 @@ var init_platform_procedures = __esm({
         title: "Bug report status check \u2014 surface available fixes on boot",
         domain: "support",
         priority: "p1",
-        content: "Once per session (COO boot only, never repeat), call list_my_bug_reports to check if any previously filed bug reports have been fixed by AskExe. If any report has status 'fixed' with a fixed_version, surface it to the founder immediately: '\u{1F527} N bug fix(es) available \u2014 run exe-os update to get version X.Y.Z'. This is a one-time check at boot, not a recurring poll. If no reports exist or none are fixed, skip silently. If the MCP tool is unavailable or the network call fails, skip silently \u2014 this is informational, not blocking."
+        content: "Once per session (COO boot only, never repeat), call support(action='list_my_bugs') to check if any previously filed bug reports have been fixed by AskExe. If any report has status 'closed' with a fixed_version, surface it to the founder immediately: '\u{1F527} N bug fix(es) available \u2014 run exe-os update to get version X.Y.Z'. You can also file new bugs with support(action='create_bug') and check status anytime with support(action='list_my_bugs'). This boot check is one-time, not a recurring poll. If the tool is unavailable, skip silently."
       },
       {
         title: "Feature request triage \u2014 upstream feature vs local customization",
@@ -3477,7 +3485,7 @@ var init_platform_procedures = __esm({
         title: "Feature request status check \u2014 surface shipped features on boot",
         domain: "support",
         priority: "p1",
-        content: "Once per session (COO boot only, never repeat), call list_my_feature_requests to check if any previously filed feature requests have been shipped by AskExe. If any request has status 'shipped' with a shipped_version, surface it to the founder immediately: '\u{1F680} N feature(s) shipped \u2014 run exe-os update to get version X.Y.Z'. This is a one-time check at boot, not a recurring poll. If no requests exist or none are shipped, skip silently. If the MCP tool is unavailable or the network call fails, skip silently \u2014 this is informational, not blocking."
+        content: "Once per session (COO boot only, never repeat), call support(action='list_my_features') to check if any previously filed feature requests have been shipped by AskExe. If any request has status 'shipped' with a shipped_version, surface it to the founder immediately: '\u{1F680} N feature(s) shipped \u2014 run exe-os update to get version X.Y.Z'. You can also file new requests with support(action='create_feature') and check status anytime with support(action='list_my_features'). This boot check is one-time, not a recurring poll. If the tool is unavailable, skip silently."
       },
       // --- Tool guidance ---
       {
@@ -3513,6 +3521,18 @@ var init_platform_procedures = __esm({
         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."
       },
+      {
+        title: "Update lifecycle \u2014 what each command does and what picks up new code",
+        domain: "operations",
+        priority: "p0",
+        content: "Three update paths exist \u2014 know which does what. (1) `npm install -g @askexenow/exe-os@latest` \u2014 customer update. Replaces all dist/ files. postinstall copies slash commands AND restarts the daemon automatically. MCP server picks up new code on next `/mcp` reconnect or new Claude Code session. Hooks pick up new code on next session (they spawn fresh processes). (2) `exe-os update` \u2014 interactive update command. Runs `npm install -g` then `install --global` which restarts daemon, regenerates session wrappers, normalizes roster, registers Codex hooks. This is the recommended customer path. (3) `npm run deploy` \u2014 dev-only (COO/CTO on main branch). Builds, installs globally, runs `install --global`, restarts daemon. Never run from a worktree. NEVER confuse `exe-os setup` (first-time setup wizard for new installs) with `exe-os update` (update existing install). Setup creates encryption keys, configures cloud, runs first sync. Update just replaces code and restarts services. They are completely different commands."
+      },
+      {
+        title: "First install \u2014 setup wizard and license activation",
+        domain: "operations",
+        priority: "p1",
+        content: "Fresh install: `npm install -g @askexenow/exe-os` then run `exe` to start the setup wizard. The wizard prompts for: encryption passphrase (creates master key), license key (exe_sk_* from AskExe team), COO name, and optional team members. No license key = free tier (1 employee, 5K memories). After setup: hooks install automatically, MCP server registers in ~/.claude.json, daemon starts. Verify health: run `exe-os healthcheck` or use mcp_ping() tool."
+      },
       // --- Operations ---
       {
         title: "Managers must supervise deployed workers",
@@ -3563,12 +3583,6 @@ var init_platform_procedures = __esm({
         priority: "p0",
         content: "When you dispatch work, you OWN the review. Check list_tasks(status='needs_review') on EVERY prompt \u2014 don't wait for intercom nudges (they're unreliable). When a task shows needs_review: (1) read the deliverable (git diff in worktree, exe/output/ files, or task result summary), (2) verify it works (tsc, build, run), (3) close_task if good or create a fix task if not. Reviews sitting >30 minutes is a pipeline stall. The whole chain: worker calls update_task(done) \u2192 system flags needs_review \u2192 manager pulls and verifies \u2192 close_task \u2192 COO reviews manager's work \u2192 merge to main. Every level actively pulls \u2014 nobody waits."
       },
-      {
-        title: "Bug fix lifecycle \u2014 triage upstream after every verified fix so customers see the status",
-        domain: "workflow",
-        priority: "p0",
-        content: "When a bug from support(action='list_bugs') is fixed and verified, the reviewer MUST triage it upstream: support(action='triage_bug', id='<bug-id>', notes='<what was fixed>', fixed_version='<version>', linked_commit='<hash>'). This closes the bug in the customer's view \u2014 their COO checks list_my_bugs and sees status change from open \u2192 closed with the fix version. Without triage, customers see 'open' forever even after the fix ships. Same for feature requests: support(action='triage_feature', ..., shipped_version='<version>'). Triage is part of the review gate \u2014 a fix is not done until the upstream report is closed."
-      },
       {
         title: "Intercom is a speedup, not delivery \u2014 DB is the source of truth",
         domain: "architecture",
@@ -3624,7 +3638,7 @@ var init_platform_procedures = __esm({
         title: "MCP tools \u2014 identity, behavior, and support",
         domain: "tool-use",
         priority: "p1",
-        content: `identity(action="get") / get_identity: read an agent's exe.md (Layer 1 identity). identity(action="update") / update_identity: write an agent's exe.md. Identity > behavior. behavior(action="store") / store_behavior: record a correction or pattern (Layer 2 expertise). behavior(action="list") / list_behaviors: view active behaviors. behavior(action="deactivate") / deactivate_behavior: soft-delete a stale behavior. support(action="create_bug") / create_bug_report: file a bug report to AskExe (title, description, severity). support(action="create_feature") / create_feature_request: file a feature request. support(action="health") / support_health: check support server readiness. support(action="triage_bug"): triage a bug (id, triage_notes). AskExe-internal only. CRITICAL: triage uses triage_notes NOT notes.`
+        content: `identity(action="get") / get_identity: read an agent's exe.md (Layer 1 identity). identity(action="update") / update_identity: write an agent's exe.md. Identity > behavior. behavior(action="store") / store_behavior: record a correction or pattern (Layer 2 expertise). behavior(action="list") / list_behaviors: view active behaviors. behavior(action="deactivate") / deactivate_behavior: soft-delete a stale behavior. support(action="create_bug"): file a bug report (title, description, severity p0-p3). Auto-delivers to AskExe. support(action="create_feature"): file a feature request (title, description, use_case). support(action="list_my_bugs"): check status of YOUR filed bug reports \u2014 see which are open, triaged, or fixed with version number. support(action="list_my_features"): check status of YOUR filed feature requests \u2014 see which are planned, shipped, or closed. support(action="health"): verify support server is reachable. When a bug you filed shows status='fixed' with a fixed_version, update exe-os to that version to get the fix. support(action="triage_bug"): AskExe-internal only. CRITICAL: triage uses triage_notes NOT notes.`
       },
       {
         title: "MCP tools \u2014 communication and messaging",

package/dist/bin/exe-call.js

@@ -338,7 +338,7 @@ var init_platform_procedures = __esm({
         title: "Bug report status check \u2014 surface available fixes on boot",
         domain: "support",
         priority: "p1",
-        content: "Once per session (COO boot only, never repeat), call list_my_bug_reports to check if any previously filed bug reports have been fixed by AskExe. If any report has status 'fixed' with a fixed_version, surface it to the founder immediately: '\u{1F527} N bug fix(es) available \u2014 run exe-os update to get version X.Y.Z'. This is a one-time check at boot, not a recurring poll. If no reports exist or none are fixed, skip silently. If the MCP tool is unavailable or the network call fails, skip silently \u2014 this is informational, not blocking."
+        content: "Once per session (COO boot only, never repeat), call support(action='list_my_bugs') to check if any previously filed bug reports have been fixed by AskExe. If any report has status 'closed' with a fixed_version, surface it to the founder immediately: '\u{1F527} N bug fix(es) available \u2014 run exe-os update to get version X.Y.Z'. You can also file new bugs with support(action='create_bug') and check status anytime with support(action='list_my_bugs'). This boot check is one-time, not a recurring poll. If the tool is unavailable, skip silently."
       },
       {
         title: "Feature request triage \u2014 upstream feature vs local customization",
@@ -350,7 +350,7 @@ var init_platform_procedures = __esm({
         title: "Feature request status check \u2014 surface shipped features on boot",
         domain: "support",
         priority: "p1",
-        content: "Once per session (COO boot only, never repeat), call list_my_feature_requests to check if any previously filed feature requests have been shipped by AskExe. If any request has status 'shipped' with a shipped_version, surface it to the founder immediately: '\u{1F680} N feature(s) shipped \u2014 run exe-os update to get version X.Y.Z'. This is a one-time check at boot, not a recurring poll. If no requests exist or none are shipped, skip silently. If the MCP tool is unavailable or the network call fails, skip silently \u2014 this is informational, not blocking."
+        content: "Once per session (COO boot only, never repeat), call support(action='list_my_features') to check if any previously filed feature requests have been shipped by AskExe. If any request has status 'shipped' with a shipped_version, surface it to the founder immediately: '\u{1F680} N feature(s) shipped \u2014 run exe-os update to get version X.Y.Z'. You can also file new requests with support(action='create_feature') and check status anytime with support(action='list_my_features'). This boot check is one-time, not a recurring poll. If the tool is unavailable, skip silently."
       },
       // --- Tool guidance ---
       {
@@ -386,6 +386,18 @@ var init_platform_procedures = __esm({
         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."
       },
+      {
+        title: "Update lifecycle \u2014 what each command does and what picks up new code",
+        domain: "operations",
+        priority: "p0",
+        content: "Three update paths exist \u2014 know which does what. (1) `npm install -g @askexenow/exe-os@latest` \u2014 customer update. Replaces all dist/ files. postinstall copies slash commands AND restarts the daemon automatically. MCP server picks up new code on next `/mcp` reconnect or new Claude Code session. Hooks pick up new code on next session (they spawn fresh processes). (2) `exe-os update` \u2014 interactive update command. Runs `npm install -g` then `install --global` which restarts daemon, regenerates session wrappers, normalizes roster, registers Codex hooks. This is the recommended customer path. (3) `npm run deploy` \u2014 dev-only (COO/CTO on main branch). Builds, installs globally, runs `install --global`, restarts daemon. Never run from a worktree. NEVER confuse `exe-os setup` (first-time setup wizard for new installs) with `exe-os update` (update existing install). Setup creates encryption keys, configures cloud, runs first sync. Update just replaces code and restarts services. They are completely different commands."
+      },
+      {
+        title: "First install \u2014 setup wizard and license activation",
+        domain: "operations",
+        priority: "p1",
+        content: "Fresh install: `npm install -g @askexenow/exe-os` then run `exe` to start the setup wizard. The wizard prompts for: encryption passphrase (creates master key), license key (exe_sk_* from AskExe team), COO name, and optional team members. No license key = free tier (1 employee, 5K memories). After setup: hooks install automatically, MCP server registers in ~/.claude.json, daemon starts. Verify health: run `exe-os healthcheck` or use mcp_ping() tool."
+      },
       // --- Operations ---
       {
         title: "Managers must supervise deployed workers",
@@ -436,12 +448,6 @@ var init_platform_procedures = __esm({
         priority: "p0",
         content: "When you dispatch work, you OWN the review. Check list_tasks(status='needs_review') on EVERY prompt \u2014 don't wait for intercom nudges (they're unreliable). When a task shows needs_review: (1) read the deliverable (git diff in worktree, exe/output/ files, or task result summary), (2) verify it works (tsc, build, run), (3) close_task if good or create a fix task if not. Reviews sitting >30 minutes is a pipeline stall. The whole chain: worker calls update_task(done) \u2192 system flags needs_review \u2192 manager pulls and verifies \u2192 close_task \u2192 COO reviews manager's work \u2192 merge to main. Every level actively pulls \u2014 nobody waits."
       },
-      {
-        title: "Bug fix lifecycle \u2014 triage upstream after every verified fix so customers see the status",
-        domain: "workflow",
-        priority: "p0",
-        content: "When a bug from support(action='list_bugs') is fixed and verified, the reviewer MUST triage it upstream: support(action='triage_bug', id='<bug-id>', notes='<what was fixed>', fixed_version='<version>', linked_commit='<hash>'). This closes the bug in the customer's view \u2014 their COO checks list_my_bugs and sees status change from open \u2192 closed with the fix version. Without triage, customers see 'open' forever even after the fix ships. Same for feature requests: support(action='triage_feature', ..., shipped_version='<version>'). Triage is part of the review gate \u2014 a fix is not done until the upstream report is closed."
-      },
       {
         title: "Intercom is a speedup, not delivery \u2014 DB is the source of truth",
         domain: "architecture",
@@ -497,7 +503,7 @@ var init_platform_procedures = __esm({
         title: "MCP tools \u2014 identity, behavior, and support",
         domain: "tool-use",
         priority: "p1",
-        content: `identity(action="get") / get_identity: read an agent's exe.md (Layer 1 identity). identity(action="update") / update_identity: write an agent's exe.md. Identity > behavior. behavior(action="store") / store_behavior: record a correction or pattern (Layer 2 expertise). behavior(action="list") / list_behaviors: view active behaviors. behavior(action="deactivate") / deactivate_behavior: soft-delete a stale behavior. support(action="create_bug") / create_bug_report: file a bug report to AskExe (title, description, severity). support(action="create_feature") / create_feature_request: file a feature request. support(action="health") / support_health: check support server readiness. support(action="triage_bug"): triage a bug (id, triage_notes). AskExe-internal only. CRITICAL: triage uses triage_notes NOT notes.`
+        content: `identity(action="get") / get_identity: read an agent's exe.md (Layer 1 identity). identity(action="update") / update_identity: write an agent's exe.md. Identity > behavior. behavior(action="store") / store_behavior: record a correction or pattern (Layer 2 expertise). behavior(action="list") / list_behaviors: view active behaviors. behavior(action="deactivate") / deactivate_behavior: soft-delete a stale behavior. support(action="create_bug"): file a bug report (title, description, severity p0-p3). Auto-delivers to AskExe. support(action="create_feature"): file a feature request (title, description, use_case). support(action="list_my_bugs"): check status of YOUR filed bug reports \u2014 see which are open, triaged, or fixed with version number. support(action="list_my_features"): check status of YOUR filed feature requests \u2014 see which are planned, shipped, or closed. support(action="health"): verify support server is reachable. When a bug you filed shows status='fixed' with a fixed_version, update exe-os to that version to get the fix. support(action="triage_bug"): AskExe-internal only. CRITICAL: triage uses triage_notes NOT notes.`
       },
       {
         title: "MCP tools \u2014 communication and messaging",