@askexenow/exe-os 0.9.105 → 0.9.107

package/dist/bin/agentic-ontology-backfill.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;
@@ -3660,7 +3668,7 @@ var init_platform_procedures = __esm({
         title: "What the platform provides vs what you customize",
         domain: "architecture",
         priority: "p0",
-        content: "Exe OS has two layers. PLATFORM layer (shipped in code, updated via npm): platform procedures, default identity templates, MCP tools, tool gating, schema migrations, daemon behavior. You get improvements automatically on update. CUSTOMER layer (yours, stored locally): agent identities (exe.md files), behaviors, company procedures, config.json, wiki content, CRM data, memory. These are NEVER overwritten by updates. Identity templates are stamped once at /exe-new-employee \u2014 after that the file is yours. If the platform ships a better template, you can compare yours against the default with getTemplate() and merge what you want. Company procedures (company_procedure tool) layer ON TOP of platform procedures \u2014 both are injected, platform first. Behaviors are always yours. Config is always yours. The platform will never modify your local data."
+        content: "Exe OS has two layers. PLATFORM layer (shipped in code, updated via npm): platform procedures, default identity templates, MCP tools, tool gating, schema migrations, daemon behavior. You get improvements automatically on update. CUSTOMER layer (yours, stored locally): agent identities (exe.md files), behaviors, company procedures, config.json, wiki content, CRM data, memory. These are NEVER overwritten by updates. Identity templates are stamped once at /exe-new-employee \u2014 after that the file is yours. If the platform ships a better template, you can compare yours against the default with getTemplate() and merge what you want. Company procedures (company_procedure tool) layer ON TOP of platform procedures \u2014 both are injected, platform first. FIVE LAYERS \u2014 know when to use each: (1) Platform procedures: how exe-os works, shipped to ALL customers, updated via npm. Never put org-specific rules here. (2) Company procedures: your org's workflow rules, stored in DB, injected after platform. Use for internal gates, review checklists, org-specific policies. (3) Identity (exe.md): an agent's permanent role definition \u2014 who they are, what they own, non-negotiable rules. Use for rules that must NEVER be forgotten across sessions. (4) Behaviors: corrections and learned patterns (Layer 2 expertise). Use for 'from now on do X' or 'never do Y again' \u2014 agent-specific, deactivatable. (5) Memory: facts, decisions, context (Layer 3 experience). Use for what happened, what was decided, project state. Searchable, consolidatable. Rule of thumb: platform procedures for product behavior, company procedures for org workflow, identity for permanent role rules, behaviors for corrections, memory for facts. Behaviors are always yours. Config is always yours. The platform will never modify your local data."
       },
       // --- Updates ---
       {
@@ -3737,12 +3745,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",

package/dist/bin/agentic-reflection-backfill.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;
@@ -3660,7 +3668,7 @@ var init_platform_procedures = __esm({
         title: "What the platform provides vs what you customize",
         domain: "architecture",
         priority: "p0",
-        content: "Exe OS has two layers. PLATFORM layer (shipped in code, updated via npm): platform procedures, default identity templates, MCP tools, tool gating, schema migrations, daemon behavior. You get improvements automatically on update. CUSTOMER layer (yours, stored locally): agent identities (exe.md files), behaviors, company procedures, config.json, wiki content, CRM data, memory. These are NEVER overwritten by updates. Identity templates are stamped once at /exe-new-employee \u2014 after that the file is yours. If the platform ships a better template, you can compare yours against the default with getTemplate() and merge what you want. Company procedures (company_procedure tool) layer ON TOP of platform procedures \u2014 both are injected, platform first. Behaviors are always yours. Config is always yours. The platform will never modify your local data."
+        content: "Exe OS has two layers. PLATFORM layer (shipped in code, updated via npm): platform procedures, default identity templates, MCP tools, tool gating, schema migrations, daemon behavior. You get improvements automatically on update. CUSTOMER layer (yours, stored locally): agent identities (exe.md files), behaviors, company procedures, config.json, wiki content, CRM data, memory. These are NEVER overwritten by updates. Identity templates are stamped once at /exe-new-employee \u2014 after that the file is yours. If the platform ships a better template, you can compare yours against the default with getTemplate() and merge what you want. Company procedures (company_procedure tool) layer ON TOP of platform procedures \u2014 both are injected, platform first. FIVE LAYERS \u2014 know when to use each: (1) Platform procedures: how exe-os works, shipped to ALL customers, updated via npm. Never put org-specific rules here. (2) Company procedures: your org's workflow rules, stored in DB, injected after platform. Use for internal gates, review checklists, org-specific policies. (3) Identity (exe.md): an agent's permanent role definition \u2014 who they are, what they own, non-negotiable rules. Use for rules that must NEVER be forgotten across sessions. (4) Behaviors: corrections and learned patterns (Layer 2 expertise). Use for 'from now on do X' or 'never do Y again' \u2014 agent-specific, deactivatable. (5) Memory: facts, decisions, context (Layer 3 experience). Use for what happened, what was decided, project state. Searchable, consolidatable. Rule of thumb: platform procedures for product behavior, company procedures for org workflow, identity for permanent role rules, behaviors for corrections, memory for facts. Behaviors are always yours. Config is always yours. The platform will never modify your local data."
       },
       // --- Updates ---
       {
@@ -3737,12 +3745,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",

package/dist/bin/agentic-semantic-label.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;
@@ -3660,7 +3668,7 @@ var init_platform_procedures = __esm({
         title: "What the platform provides vs what you customize",
         domain: "architecture",
         priority: "p0",
-        content: "Exe OS has two layers. PLATFORM layer (shipped in code, updated via npm): platform procedures, default identity templates, MCP tools, tool gating, schema migrations, daemon behavior. You get improvements automatically on update. CUSTOMER layer (yours, stored locally): agent identities (exe.md files), behaviors, company procedures, config.json, wiki content, CRM data, memory. These are NEVER overwritten by updates. Identity templates are stamped once at /exe-new-employee \u2014 after that the file is yours. If the platform ships a better template, you can compare yours against the default with getTemplate() and merge what you want. Company procedures (company_procedure tool) layer ON TOP of platform procedures \u2014 both are injected, platform first. Behaviors are always yours. Config is always yours. The platform will never modify your local data."
+        content: "Exe OS has two layers. PLATFORM layer (shipped in code, updated via npm): platform procedures, default identity templates, MCP tools, tool gating, schema migrations, daemon behavior. You get improvements automatically on update. CUSTOMER layer (yours, stored locally): agent identities (exe.md files), behaviors, company procedures, config.json, wiki content, CRM data, memory. These are NEVER overwritten by updates. Identity templates are stamped once at /exe-new-employee \u2014 after that the file is yours. If the platform ships a better template, you can compare yours against the default with getTemplate() and merge what you want. Company procedures (company_procedure tool) layer ON TOP of platform procedures \u2014 both are injected, platform first. FIVE LAYERS \u2014 know when to use each: (1) Platform procedures: how exe-os works, shipped to ALL customers, updated via npm. Never put org-specific rules here. (2) Company procedures: your org's workflow rules, stored in DB, injected after platform. Use for internal gates, review checklists, org-specific policies. (3) Identity (exe.md): an agent's permanent role definition \u2014 who they are, what they own, non-negotiable rules. Use for rules that must NEVER be forgotten across sessions. (4) Behaviors: corrections and learned patterns (Layer 2 expertise). Use for 'from now on do X' or 'never do Y again' \u2014 agent-specific, deactivatable. (5) Memory: facts, decisions, context (Layer 3 experience). Use for what happened, what was decided, project state. Searchable, consolidatable. Rule of thumb: platform procedures for product behavior, company procedures for org workflow, identity for permanent role rules, behaviors for corrections, memory for facts. Behaviors are always yours. Config is always yours. The platform will never modify your local data."
       },
       // --- Updates ---
       {
@@ -3737,12 +3745,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",

package/dist/bin/backfill-conversations.js

@@ -1746,7 +1746,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;
@@ -3800,7 +3808,7 @@ var init_platform_procedures = __esm({
         title: "What the platform provides vs what you customize",
         domain: "architecture",
         priority: "p0",
-        content: "Exe OS has two layers. PLATFORM layer (shipped in code, updated via npm): platform procedures, default identity templates, MCP tools, tool gating, schema migrations, daemon behavior. You get improvements automatically on update. CUSTOMER layer (yours, stored locally): agent identities (exe.md files), behaviors, company procedures, config.json, wiki content, CRM data, memory. These are NEVER overwritten by updates. Identity templates are stamped once at /exe-new-employee \u2014 after that the file is yours. If the platform ships a better template, you can compare yours against the default with getTemplate() and merge what you want. Company procedures (company_procedure tool) layer ON TOP of platform procedures \u2014 both are injected, platform first. Behaviors are always yours. Config is always yours. The platform will never modify your local data."
+        content: "Exe OS has two layers. PLATFORM layer (shipped in code, updated via npm): platform procedures, default identity templates, MCP tools, tool gating, schema migrations, daemon behavior. You get improvements automatically on update. CUSTOMER layer (yours, stored locally): agent identities (exe.md files), behaviors, company procedures, config.json, wiki content, CRM data, memory. These are NEVER overwritten by updates. Identity templates are stamped once at /exe-new-employee \u2014 after that the file is yours. If the platform ships a better template, you can compare yours against the default with getTemplate() and merge what you want. Company procedures (company_procedure tool) layer ON TOP of platform procedures \u2014 both are injected, platform first. FIVE LAYERS \u2014 know when to use each: (1) Platform procedures: how exe-os works, shipped to ALL customers, updated via npm. Never put org-specific rules here. (2) Company procedures: your org's workflow rules, stored in DB, injected after platform. Use for internal gates, review checklists, org-specific policies. (3) Identity (exe.md): an agent's permanent role definition \u2014 who they are, what they own, non-negotiable rules. Use for rules that must NEVER be forgotten across sessions. (4) Behaviors: corrections and learned patterns (Layer 2 expertise). Use for 'from now on do X' or 'never do Y again' \u2014 agent-specific, deactivatable. (5) Memory: facts, decisions, context (Layer 3 experience). Use for what happened, what was decided, project state. Searchable, consolidatable. Rule of thumb: platform procedures for product behavior, company procedures for org workflow, identity for permanent role rules, behaviors for corrections, memory for facts. Behaviors are always yours. Config is always yours. The platform will never modify your local data."
       },
       // --- Updates ---
       {
@@ -3877,12 +3885,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",

package/dist/bin/backfill-responses.js

@@ -1746,7 +1746,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;
@@ -3800,7 +3808,7 @@ var init_platform_procedures = __esm({
         title: "What the platform provides vs what you customize",
         domain: "architecture",
         priority: "p0",
-        content: "Exe OS has two layers. PLATFORM layer (shipped in code, updated via npm): platform procedures, default identity templates, MCP tools, tool gating, schema migrations, daemon behavior. You get improvements automatically on update. CUSTOMER layer (yours, stored locally): agent identities (exe.md files), behaviors, company procedures, config.json, wiki content, CRM data, memory. These are NEVER overwritten by updates. Identity templates are stamped once at /exe-new-employee \u2014 after that the file is yours. If the platform ships a better template, you can compare yours against the default with getTemplate() and merge what you want. Company procedures (company_procedure tool) layer ON TOP of platform procedures \u2014 both are injected, platform first. Behaviors are always yours. Config is always yours. The platform will never modify your local data."
+        content: "Exe OS has two layers. PLATFORM layer (shipped in code, updated via npm): platform procedures, default identity templates, MCP tools, tool gating, schema migrations, daemon behavior. You get improvements automatically on update. CUSTOMER layer (yours, stored locally): agent identities (exe.md files), behaviors, company procedures, config.json, wiki content, CRM data, memory. These are NEVER overwritten by updates. Identity templates are stamped once at /exe-new-employee \u2014 after that the file is yours. If the platform ships a better template, you can compare yours against the default with getTemplate() and merge what you want. Company procedures (company_procedure tool) layer ON TOP of platform procedures \u2014 both are injected, platform first. FIVE LAYERS \u2014 know when to use each: (1) Platform procedures: how exe-os works, shipped to ALL customers, updated via npm. Never put org-specific rules here. (2) Company procedures: your org's workflow rules, stored in DB, injected after platform. Use for internal gates, review checklists, org-specific policies. (3) Identity (exe.md): an agent's permanent role definition \u2014 who they are, what they own, non-negotiable rules. Use for rules that must NEVER be forgotten across sessions. (4) Behaviors: corrections and learned patterns (Layer 2 expertise). Use for 'from now on do X' or 'never do Y again' \u2014 agent-specific, deactivatable. (5) Memory: facts, decisions, context (Layer 3 experience). Use for what happened, what was decided, project state. Searchable, consolidatable. Rule of thumb: platform procedures for product behavior, company procedures for org workflow, identity for permanent role rules, behaviors for corrections, memory for facts. Behaviors are always yours. Config is always yours. The platform will never modify your local data."
       },
       // --- Updates ---
       {
@@ -3877,12 +3885,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",

package/dist/bin/backfill-vectors.js

@@ -1742,7 +1742,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;
@@ -3796,7 +3804,7 @@ var init_platform_procedures = __esm({
         title: "What the platform provides vs what you customize",
         domain: "architecture",
         priority: "p0",
-        content: "Exe OS has two layers. PLATFORM layer (shipped in code, updated via npm): platform procedures, default identity templates, MCP tools, tool gating, schema migrations, daemon behavior. You get improvements automatically on update. CUSTOMER layer (yours, stored locally): agent identities (exe.md files), behaviors, company procedures, config.json, wiki content, CRM data, memory. These are NEVER overwritten by updates. Identity templates are stamped once at /exe-new-employee \u2014 after that the file is yours. If the platform ships a better template, you can compare yours against the default with getTemplate() and merge what you want. Company procedures (company_procedure tool) layer ON TOP of platform procedures \u2014 both are injected, platform first. Behaviors are always yours. Config is always yours. The platform will never modify your local data."
+        content: "Exe OS has two layers. PLATFORM layer (shipped in code, updated via npm): platform procedures, default identity templates, MCP tools, tool gating, schema migrations, daemon behavior. You get improvements automatically on update. CUSTOMER layer (yours, stored locally): agent identities (exe.md files), behaviors, company procedures, config.json, wiki content, CRM data, memory. These are NEVER overwritten by updates. Identity templates are stamped once at /exe-new-employee \u2014 after that the file is yours. If the platform ships a better template, you can compare yours against the default with getTemplate() and merge what you want. Company procedures (company_procedure tool) layer ON TOP of platform procedures \u2014 both are injected, platform first. FIVE LAYERS \u2014 know when to use each: (1) Platform procedures: how exe-os works, shipped to ALL customers, updated via npm. Never put org-specific rules here. (2) Company procedures: your org's workflow rules, stored in DB, injected after platform. Use for internal gates, review checklists, org-specific policies. (3) Identity (exe.md): an agent's permanent role definition \u2014 who they are, what they own, non-negotiable rules. Use for rules that must NEVER be forgotten across sessions. (4) Behaviors: corrections and learned patterns (Layer 2 expertise). Use for 'from now on do X' or 'never do Y again' \u2014 agent-specific, deactivatable. (5) Memory: facts, decisions, context (Layer 3 experience). Use for what happened, what was decided, project state. Searchable, consolidatable. Rule of thumb: platform procedures for product behavior, company procedures for org workflow, identity for permanent role rules, behaviors for corrections, memory for facts. Behaviors are always yours. Config is always yours. The platform will never modify your local data."
       },
       // --- Updates ---
       {
@@ -3873,12 +3881,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",

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;
@@ -3968,7 +3976,7 @@ var init_platform_procedures = __esm({
         title: "What the platform provides vs what you customize",
         domain: "architecture",
         priority: "p0",
-        content: "Exe OS has two layers. PLATFORM layer (shipped in code, updated via npm): platform procedures, default identity templates, MCP tools, tool gating, schema migrations, daemon behavior. You get improvements automatically on update. CUSTOMER layer (yours, stored locally): agent identities (exe.md files), behaviors, company procedures, config.json, wiki content, CRM data, memory. These are NEVER overwritten by updates. Identity templates are stamped once at /exe-new-employee \u2014 after that the file is yours. If the platform ships a better template, you can compare yours against the default with getTemplate() and merge what you want. Company procedures (company_procedure tool) layer ON TOP of platform procedures \u2014 both are injected, platform first. Behaviors are always yours. Config is always yours. The platform will never modify your local data."
+        content: "Exe OS has two layers. PLATFORM layer (shipped in code, updated via npm): platform procedures, default identity templates, MCP tools, tool gating, schema migrations, daemon behavior. You get improvements automatically on update. CUSTOMER layer (yours, stored locally): agent identities (exe.md files), behaviors, company procedures, config.json, wiki content, CRM data, memory. These are NEVER overwritten by updates. Identity templates are stamped once at /exe-new-employee \u2014 after that the file is yours. If the platform ships a better template, you can compare yours against the default with getTemplate() and merge what you want. Company procedures (company_procedure tool) layer ON TOP of platform procedures \u2014 both are injected, platform first. FIVE LAYERS \u2014 know when to use each: (1) Platform procedures: how exe-os works, shipped to ALL customers, updated via npm. Never put org-specific rules here. (2) Company procedures: your org's workflow rules, stored in DB, injected after platform. Use for internal gates, review checklists, org-specific policies. (3) Identity (exe.md): an agent's permanent role definition \u2014 who they are, what they own, non-negotiable rules. Use for rules that must NEVER be forgotten across sessions. (4) Behaviors: corrections and learned patterns (Layer 2 expertise). Use for 'from now on do X' or 'never do Y again' \u2014 agent-specific, deactivatable. (5) Memory: facts, decisions, context (Layer 3 experience). Use for what happened, what was decided, project state. Searchable, consolidatable. Rule of thumb: platform procedures for product behavior, company procedures for org workflow, identity for permanent role rules, behaviors for corrections, memory for facts. Behaviors are always yours. Config is always yours. The platform will never modify your local data."
       },
       // --- Updates ---
       {
@@ -4045,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",

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;
@@ -4443,7 +4451,7 @@ var init_platform_procedures = __esm({
         title: "What the platform provides vs what you customize",
         domain: "architecture",
         priority: "p0",
-        content: "Exe OS has two layers. PLATFORM layer (shipped in code, updated via npm): platform procedures, default identity templates, MCP tools, tool gating, schema migrations, daemon behavior. You get improvements automatically on update. CUSTOMER layer (yours, stored locally): agent identities (exe.md files), behaviors, company procedures, config.json, wiki content, CRM data, memory. These are NEVER overwritten by updates. Identity templates are stamped once at /exe-new-employee \u2014 after that the file is yours. If the platform ships a better template, you can compare yours against the default with getTemplate() and merge what you want. Company procedures (company_procedure tool) layer ON TOP of platform procedures \u2014 both are injected, platform first. Behaviors are always yours. Config is always yours. The platform will never modify your local data."
+        content: "Exe OS has two layers. PLATFORM layer (shipped in code, updated via npm): platform procedures, default identity templates, MCP tools, tool gating, schema migrations, daemon behavior. You get improvements automatically on update. CUSTOMER layer (yours, stored locally): agent identities (exe.md files), behaviors, company procedures, config.json, wiki content, CRM data, memory. These are NEVER overwritten by updates. Identity templates are stamped once at /exe-new-employee \u2014 after that the file is yours. If the platform ships a better template, you can compare yours against the default with getTemplate() and merge what you want. Company procedures (company_procedure tool) layer ON TOP of platform procedures \u2014 both are injected, platform first. FIVE LAYERS \u2014 know when to use each: (1) Platform procedures: how exe-os works, shipped to ALL customers, updated via npm. Never put org-specific rules here. (2) Company procedures: your org's workflow rules, stored in DB, injected after platform. Use for internal gates, review checklists, org-specific policies. (3) Identity (exe.md): an agent's permanent role definition \u2014 who they are, what they own, non-negotiable rules. Use for rules that must NEVER be forgotten across sessions. (4) Behaviors: corrections and learned patterns (Layer 2 expertise). Use for 'from now on do X' or 'never do Y again' \u2014 agent-specific, deactivatable. (5) Memory: facts, decisions, context (Layer 3 experience). Use for what happened, what was decided, project state. Searchable, consolidatable. Rule of thumb: platform procedures for product behavior, company procedures for org workflow, identity for permanent role rules, behaviors for corrections, memory for facts. Behaviors are always yours. Config is always yours. The platform will never modify your local data."
       },
       // --- Updates ---
       {
@@ -4520,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",

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;
@@ -9149,7 +9157,7 @@ var init_platform_procedures = __esm({
         title: "What the platform provides vs what you customize",
         domain: "architecture",
         priority: "p0",
-        content: "Exe OS has two layers. PLATFORM layer (shipped in code, updated via npm): platform procedures, default identity templates, MCP tools, tool gating, schema migrations, daemon behavior. You get improvements automatically on update. CUSTOMER layer (yours, stored locally): agent identities (exe.md files), behaviors, company procedures, config.json, wiki content, CRM data, memory. These are NEVER overwritten by updates. Identity templates are stamped once at /exe-new-employee \u2014 after that the file is yours. If the platform ships a better template, you can compare yours against the default with getTemplate() and merge what you want. Company procedures (company_procedure tool) layer ON TOP of platform procedures \u2014 both are injected, platform first. Behaviors are always yours. Config is always yours. The platform will never modify your local data."
+        content: "Exe OS has two layers. PLATFORM layer (shipped in code, updated via npm): platform procedures, default identity templates, MCP tools, tool gating, schema migrations, daemon behavior. You get improvements automatically on update. CUSTOMER layer (yours, stored locally): agent identities (exe.md files), behaviors, company procedures, config.json, wiki content, CRM data, memory. These are NEVER overwritten by updates. Identity templates are stamped once at /exe-new-employee \u2014 after that the file is yours. If the platform ships a better template, you can compare yours against the default with getTemplate() and merge what you want. Company procedures (company_procedure tool) layer ON TOP of platform procedures \u2014 both are injected, platform first. FIVE LAYERS \u2014 know when to use each: (1) Platform procedures: how exe-os works, shipped to ALL customers, updated via npm. Never put org-specific rules here. (2) Company procedures: your org's workflow rules, stored in DB, injected after platform. Use for internal gates, review checklists, org-specific policies. (3) Identity (exe.md): an agent's permanent role definition \u2014 who they are, what they own, non-negotiable rules. Use for rules that must NEVER be forgotten across sessions. (4) Behaviors: corrections and learned patterns (Layer 2 expertise). Use for 'from now on do X' or 'never do Y again' \u2014 agent-specific, deactivatable. (5) Memory: facts, decisions, context (Layer 3 experience). Use for what happened, what was decided, project state. Searchable, consolidatable. Rule of thumb: platform procedures for product behavior, company procedures for org workflow, identity for permanent role rules, behaviors for corrections, memory for facts. Behaviors are always yours. Config is always yours. The platform will never modify your local data."
       },
       // --- Updates ---
       {
@@ -9226,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",

package/dist/bin/exe-agent.js

@@ -1434,7 +1434,7 @@ var PLATFORM_PROCEDURES = [
     title: "What the platform provides vs what you customize",
     domain: "architecture",
     priority: "p0",
-    content: "Exe OS has two layers. PLATFORM layer (shipped in code, updated via npm): platform procedures, default identity templates, MCP tools, tool gating, schema migrations, daemon behavior. You get improvements automatically on update. CUSTOMER layer (yours, stored locally): agent identities (exe.md files), behaviors, company procedures, config.json, wiki content, CRM data, memory. These are NEVER overwritten by updates. Identity templates are stamped once at /exe-new-employee \u2014 after that the file is yours. If the platform ships a better template, you can compare yours against the default with getTemplate() and merge what you want. Company procedures (company_procedure tool) layer ON TOP of platform procedures \u2014 both are injected, platform first. Behaviors are always yours. Config is always yours. The platform will never modify your local data."
+    content: "Exe OS has two layers. PLATFORM layer (shipped in code, updated via npm): platform procedures, default identity templates, MCP tools, tool gating, schema migrations, daemon behavior. You get improvements automatically on update. CUSTOMER layer (yours, stored locally): agent identities (exe.md files), behaviors, company procedures, config.json, wiki content, CRM data, memory. These are NEVER overwritten by updates. Identity templates are stamped once at /exe-new-employee \u2014 after that the file is yours. If the platform ships a better template, you can compare yours against the default with getTemplate() and merge what you want. Company procedures (company_procedure tool) layer ON TOP of platform procedures \u2014 both are injected, platform first. FIVE LAYERS \u2014 know when to use each: (1) Platform procedures: how exe-os works, shipped to ALL customers, updated via npm. Never put org-specific rules here. (2) Company procedures: your org's workflow rules, stored in DB, injected after platform. Use for internal gates, review checklists, org-specific policies. (3) Identity (exe.md): an agent's permanent role definition \u2014 who they are, what they own, non-negotiable rules. Use for rules that must NEVER be forgotten across sessions. (4) Behaviors: corrections and learned patterns (Layer 2 expertise). Use for 'from now on do X' or 'never do Y again' \u2014 agent-specific, deactivatable. (5) Memory: facts, decisions, context (Layer 3 experience). Use for what happened, what was decided, project state. Searchable, consolidatable. Rule of thumb: platform procedures for product behavior, company procedures for org workflow, identity for permanent role rules, behaviors for corrections, memory for facts. Behaviors are always yours. Config is always yours. The platform will never modify your local data."
   },
   // --- Updates ---
   {
@@ -1511,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",

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;
@@ -3810,7 +3818,7 @@ var init_platform_procedures = __esm({
         title: "What the platform provides vs what you customize",
         domain: "architecture",
         priority: "p0",
-        content: "Exe OS has two layers. PLATFORM layer (shipped in code, updated via npm): platform procedures, default identity templates, MCP tools, tool gating, schema migrations, daemon behavior. You get improvements automatically on update. CUSTOMER layer (yours, stored locally): agent identities (exe.md files), behaviors, company procedures, config.json, wiki content, CRM data, memory. These are NEVER overwritten by updates. Identity templates are stamped once at /exe-new-employee \u2014 after that the file is yours. If the platform ships a better template, you can compare yours against the default with getTemplate() and merge what you want. Company procedures (company_procedure tool) layer ON TOP of platform procedures \u2014 both are injected, platform first. Behaviors are always yours. Config is always yours. The platform will never modify your local data."
+        content: "Exe OS has two layers. PLATFORM layer (shipped in code, updated via npm): platform procedures, default identity templates, MCP tools, tool gating, schema migrations, daemon behavior. You get improvements automatically on update. CUSTOMER layer (yours, stored locally): agent identities (exe.md files), behaviors, company procedures, config.json, wiki content, CRM data, memory. These are NEVER overwritten by updates. Identity templates are stamped once at /exe-new-employee \u2014 after that the file is yours. If the platform ships a better template, you can compare yours against the default with getTemplate() and merge what you want. Company procedures (company_procedure tool) layer ON TOP of platform procedures \u2014 both are injected, platform first. FIVE LAYERS \u2014 know when to use each: (1) Platform procedures: how exe-os works, shipped to ALL customers, updated via npm. Never put org-specific rules here. (2) Company procedures: your org's workflow rules, stored in DB, injected after platform. Use for internal gates, review checklists, org-specific policies. (3) Identity (exe.md): an agent's permanent role definition \u2014 who they are, what they own, non-negotiable rules. Use for rules that must NEVER be forgotten across sessions. (4) Behaviors: corrections and learned patterns (Layer 2 expertise). Use for 'from now on do X' or 'never do Y again' \u2014 agent-specific, deactivatable. (5) Memory: facts, decisions, context (Layer 3 experience). Use for what happened, what was decided, project state. Searchable, consolidatable. Rule of thumb: platform procedures for product behavior, company procedures for org workflow, identity for permanent role rules, behaviors for corrections, memory for facts. Behaviors are always yours. Config is always yours. The platform will never modify your local data."
       },
       // --- Updates ---
       {
@@ -3887,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",

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;
@@ -3498,7 +3506,7 @@ var init_platform_procedures = __esm({
         title: "What the platform provides vs what you customize",
         domain: "architecture",
         priority: "p0",
-        content: "Exe OS has two layers. PLATFORM layer (shipped in code, updated via npm): platform procedures, default identity templates, MCP tools, tool gating, schema migrations, daemon behavior. You get improvements automatically on update. CUSTOMER layer (yours, stored locally): agent identities (exe.md files), behaviors, company procedures, config.json, wiki content, CRM data, memory. These are NEVER overwritten by updates. Identity templates are stamped once at /exe-new-employee \u2014 after that the file is yours. If the platform ships a better template, you can compare yours against the default with getTemplate() and merge what you want. Company procedures (company_procedure tool) layer ON TOP of platform procedures \u2014 both are injected, platform first. Behaviors are always yours. Config is always yours. The platform will never modify your local data."
+        content: "Exe OS has two layers. PLATFORM layer (shipped in code, updated via npm): platform procedures, default identity templates, MCP tools, tool gating, schema migrations, daemon behavior. You get improvements automatically on update. CUSTOMER layer (yours, stored locally): agent identities (exe.md files), behaviors, company procedures, config.json, wiki content, CRM data, memory. These are NEVER overwritten by updates. Identity templates are stamped once at /exe-new-employee \u2014 after that the file is yours. If the platform ships a better template, you can compare yours against the default with getTemplate() and merge what you want. Company procedures (company_procedure tool) layer ON TOP of platform procedures \u2014 both are injected, platform first. FIVE LAYERS \u2014 know when to use each: (1) Platform procedures: how exe-os works, shipped to ALL customers, updated via npm. Never put org-specific rules here. (2) Company procedures: your org's workflow rules, stored in DB, injected after platform. Use for internal gates, review checklists, org-specific policies. (3) Identity (exe.md): an agent's permanent role definition \u2014 who they are, what they own, non-negotiable rules. Use for rules that must NEVER be forgotten across sessions. (4) Behaviors: corrections and learned patterns (Layer 2 expertise). Use for 'from now on do X' or 'never do Y again' \u2014 agent-specific, deactivatable. (5) Memory: facts, decisions, context (Layer 3 experience). Use for what happened, what was decided, project state. Searchable, consolidatable. Rule of thumb: platform procedures for product behavior, company procedures for org workflow, identity for permanent role rules, behaviors for corrections, memory for facts. Behaviors are always yours. Config is always yours. The platform will never modify your local data."
       },
       // --- Updates ---
       {
@@ -3575,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",

package/dist/bin/exe-call.js

@@ -371,7 +371,7 @@ var init_platform_procedures = __esm({
         title: "What the platform provides vs what you customize",
         domain: "architecture",
         priority: "p0",
-        content: "Exe OS has two layers. PLATFORM layer (shipped in code, updated via npm): platform procedures, default identity templates, MCP tools, tool gating, schema migrations, daemon behavior. You get improvements automatically on update. CUSTOMER layer (yours, stored locally): agent identities (exe.md files), behaviors, company procedures, config.json, wiki content, CRM data, memory. These are NEVER overwritten by updates. Identity templates are stamped once at /exe-new-employee \u2014 after that the file is yours. If the platform ships a better template, you can compare yours against the default with getTemplate() and merge what you want. Company procedures (company_procedure tool) layer ON TOP of platform procedures \u2014 both are injected, platform first. Behaviors are always yours. Config is always yours. The platform will never modify your local data."
+        content: "Exe OS has two layers. PLATFORM layer (shipped in code, updated via npm): platform procedures, default identity templates, MCP tools, tool gating, schema migrations, daemon behavior. You get improvements automatically on update. CUSTOMER layer (yours, stored locally): agent identities (exe.md files), behaviors, company procedures, config.json, wiki content, CRM data, memory. These are NEVER overwritten by updates. Identity templates are stamped once at /exe-new-employee \u2014 after that the file is yours. If the platform ships a better template, you can compare yours against the default with getTemplate() and merge what you want. Company procedures (company_procedure tool) layer ON TOP of platform procedures \u2014 both are injected, platform first. FIVE LAYERS \u2014 know when to use each: (1) Platform procedures: how exe-os works, shipped to ALL customers, updated via npm. Never put org-specific rules here. (2) Company procedures: your org's workflow rules, stored in DB, injected after platform. Use for internal gates, review checklists, org-specific policies. (3) Identity (exe.md): an agent's permanent role definition \u2014 who they are, what they own, non-negotiable rules. Use for rules that must NEVER be forgotten across sessions. (4) Behaviors: corrections and learned patterns (Layer 2 expertise). Use for 'from now on do X' or 'never do Y again' \u2014 agent-specific, deactivatable. (5) Memory: facts, decisions, context (Layer 3 experience). Use for what happened, what was decided, project state. Searchable, consolidatable. Rule of thumb: platform procedures for product behavior, company procedures for org workflow, identity for permanent role rules, behaviors for corrections, memory for facts. Behaviors are always yours. Config is always yours. The platform will never modify your local data."
       },
       // --- Updates ---
       {
@@ -448,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",

package/dist/bin/exe-cloud.js

@@ -2344,7 +2344,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;
@@ -6958,7 +6966,7 @@ var init_platform_procedures = __esm({
         title: "What the platform provides vs what you customize",
         domain: "architecture",
         priority: "p0",
-        content: "Exe OS has two layers. PLATFORM layer (shipped in code, updated via npm): platform procedures, default identity templates, MCP tools, tool gating, schema migrations, daemon behavior. You get improvements automatically on update. CUSTOMER layer (yours, stored locally): agent identities (exe.md files), behaviors, company procedures, config.json, wiki content, CRM data, memory. These are NEVER overwritten by updates. Identity templates are stamped once at /exe-new-employee \u2014 after that the file is yours. If the platform ships a better template, you can compare yours against the default with getTemplate() and merge what you want. Company procedures (company_procedure tool) layer ON TOP of platform procedures \u2014 both are injected, platform first. Behaviors are always yours. Config is always yours. The platform will never modify your local data."
+        content: "Exe OS has two layers. PLATFORM layer (shipped in code, updated via npm): platform procedures, default identity templates, MCP tools, tool gating, schema migrations, daemon behavior. You get improvements automatically on update. CUSTOMER layer (yours, stored locally): agent identities (exe.md files), behaviors, company procedures, config.json, wiki content, CRM data, memory. These are NEVER overwritten by updates. Identity templates are stamped once at /exe-new-employee \u2014 after that the file is yours. If the platform ships a better template, you can compare yours against the default with getTemplate() and merge what you want. Company procedures (company_procedure tool) layer ON TOP of platform procedures \u2014 both are injected, platform first. FIVE LAYERS \u2014 know when to use each: (1) Platform procedures: how exe-os works, shipped to ALL customers, updated via npm. Never put org-specific rules here. (2) Company procedures: your org's workflow rules, stored in DB, injected after platform. Use for internal gates, review checklists, org-specific policies. (3) Identity (exe.md): an agent's permanent role definition \u2014 who they are, what they own, non-negotiable rules. Use for rules that must NEVER be forgotten across sessions. (4) Behaviors: corrections and learned patterns (Layer 2 expertise). Use for 'from now on do X' or 'never do Y again' \u2014 agent-specific, deactivatable. (5) Memory: facts, decisions, context (Layer 3 experience). Use for what happened, what was decided, project state. Searchable, consolidatable. Rule of thumb: platform procedures for product behavior, company procedures for org workflow, identity for permanent role rules, behaviors for corrections, memory for facts. Behaviors are always yours. Config is always yours. The platform will never modify your local data."
       },
       // --- Updates ---
       {
@@ -7035,12 +7043,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",