@askexenow/exe-os 0.9.106 → 0.9.108

package/dist/bin/agentic-ontology-backfill.js

@@ -3668,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 scoped per agent per project, 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 per-agent per-project corrections, memory for facts. Behaviors are always yours. Config is always yours. The platform will never modify your local data."
       },
       // --- Updates ---
       {

package/dist/bin/agentic-reflection-backfill.js

@@ -3668,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 scoped per agent per project, 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 per-agent per-project corrections, memory for facts. Behaviors are always yours. Config is always yours. The platform will never modify your local data."
       },
       // --- Updates ---
       {

package/dist/bin/agentic-semantic-label.js

@@ -3668,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 scoped per agent per project, 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 per-agent per-project corrections, memory for facts. Behaviors are always yours. Config is always yours. The platform will never modify your local data."
       },
       // --- Updates ---
       {

package/dist/bin/backfill-conversations.js

@@ -3808,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 scoped per agent per project, 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 per-agent per-project corrections, memory for facts. Behaviors are always yours. Config is always yours. The platform will never modify your local data."
       },
       // --- Updates ---
       {

package/dist/bin/backfill-responses.js

@@ -3808,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 scoped per agent per project, 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 per-agent per-project corrections, memory for facts. Behaviors are always yours. Config is always yours. The platform will never modify your local data."
       },
       // --- Updates ---
       {

package/dist/bin/backfill-vectors.js

@@ -3804,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 scoped per agent per project, 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 per-agent per-project corrections, memory for facts. Behaviors are always yours. Config is always yours. The platform will never modify your local data."
       },
       // --- Updates ---
       {

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

@@ -3976,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 scoped per agent per project, 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 per-agent per-project corrections, memory for facts. Behaviors are always yours. Config is always yours. The platform will never modify your local data."
       },
       // --- Updates ---
       {

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

@@ -4451,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 scoped per agent per project, 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 per-agent per-project corrections, memory for facts. Behaviors are always yours. Config is always yours. The platform will never modify your local data."
       },
       // --- Updates ---
       {

package/dist/bin/cli.js

@@ -9157,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 scoped per agent per project, 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 per-agent per-project corrections, memory for facts. Behaviors are always yours. Config is always yours. The platform will never modify your local data."
       },
       // --- Updates ---
       {

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 scoped per agent per project, 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 per-agent per-project corrections, memory for facts. Behaviors are always yours. Config is always yours. The platform will never modify your local data."
   },
   // --- Updates ---
   {

package/dist/bin/exe-assign.js

@@ -3818,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 scoped per agent per project, 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 per-agent per-project corrections, memory for facts. Behaviors are always yours. Config is always yours. The platform will never modify your local data."
       },
       // --- Updates ---
       {

package/dist/bin/exe-boot.js

@@ -3506,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 scoped per agent per project, 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 per-agent per-project corrections, memory for facts. Behaviors are always yours. Config is always yours. The platform will never modify your local data."
       },
       // --- Updates ---
       {

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 scoped per agent per project, 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 per-agent per-project corrections, memory for facts. Behaviors are always yours. Config is always yours. The platform will never modify your local data."
       },
       // --- Updates ---
       {

package/dist/bin/exe-cloud.js

@@ -6966,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 scoped per agent per project, 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 per-agent per-project corrections, memory for facts. Behaviors are always yours. Config is always yours. The platform will never modify your local data."
       },
       // --- Updates ---
       {

package/dist/bin/exe-dispatch.js

@@ -8260,7 +8260,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 scoped per agent per project, 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 per-agent per-project corrections, memory for facts. Behaviors are always yours. Config is always yours. The platform will never modify your local data."
       },
       // --- Updates ---
       {

package/dist/bin/exe-doctor.js

@@ -4779,7 +4779,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 scoped per agent per project, 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 per-agent per-project corrections, memory for facts. Behaviors are always yours. Config is always yours. The platform will never modify your local data."
       },
       // --- Updates ---
       {

package/dist/bin/exe-export-behaviors.js

@@ -4516,7 +4516,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 scoped per agent per project, 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 per-agent per-project corrections, memory for facts. Behaviors are always yours. Config is always yours. The platform will never modify your local data."
       },
       // --- Updates ---
       {

package/dist/bin/exe-forget.js

@@ -4440,7 +4440,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 scoped per agent per project, 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 per-agent per-project corrections, memory for facts. Behaviors are always yours. Config is always yours. The platform will never modify your local data."
       },
       // --- Updates ---
       {

package/dist/bin/exe-gateway.js

@@ -5124,7 +5124,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 scoped per agent per project, 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 per-agent per-project corrections, memory for facts. Behaviors are always yours. Config is always yours. The platform will never modify your local data."
       },
       // --- Updates ---
       {

package/dist/bin/exe-heartbeat.js

@@ -4479,7 +4479,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 scoped per agent per project, 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 per-agent per-project corrections, memory for facts. Behaviors are always yours. Config is always yours. The platform will never modify your local data."
       },
       // --- Updates ---
       {

package/dist/bin/exe-kill.js

@@ -4440,7 +4440,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 scoped per agent per project, 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 per-agent per-project corrections, memory for facts. Behaviors are always yours. Config is always yours. The platform will never modify your local data."
       },
       // --- Updates ---
       {

package/dist/bin/exe-launch-agent.js

@@ -4538,7 +4538,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 scoped per agent per project, 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 per-agent per-project corrections, memory for facts. Behaviors are always yours. Config is always yours. The platform will never modify your local data."
       },
       // --- Updates ---
       {

package/dist/bin/exe-new-employee.js

@@ -2755,7 +2755,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 scoped per agent per project, 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 per-agent per-project corrections, memory for facts. Behaviors are always yours. Config is always yours. The platform will never modify your local data."
   },
   // --- Updates ---
   {

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

@@ -4921,7 +4921,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 scoped per agent per project, 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 per-agent per-project corrections, memory for facts. Behaviors are always yours. Config is always yours. The platform will never modify your local data."
       },
       // --- Updates ---
       {

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

@@ -4987,7 +4987,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 scoped per agent per project, 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 per-agent per-project corrections, memory for facts. Behaviors are always yours. Config is always yours. The platform will never modify your local data."
       },
       // --- Updates ---
       {

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

@@ -5026,7 +5026,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 scoped per agent per project, 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 per-agent per-project corrections, memory for facts. Behaviors are always yours. Config is always yours. The platform will never modify your local data."
       },
       // --- Updates ---
       {

package/dist/bin/exe-rename.js

@@ -3274,7 +3274,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 scoped per agent per project, 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 per-agent per-project corrections, memory for facts. Behaviors are always yours. Config is always yours. The platform will never modify your local data."
       },
       // --- Updates ---
       {

package/dist/bin/exe-review.js

@@ -4454,7 +4454,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 scoped per agent per project, 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 per-agent per-project corrections, memory for facts. Behaviors are always yours. Config is always yours. The platform will never modify your local data."
       },
       // --- Updates ---
       {

package/dist/bin/exe-search.js

@@ -4439,7 +4439,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 scoped per agent per project, 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 per-agent per-project corrections, memory for facts. Behaviors are always yours. Config is always yours. The platform will never modify your local data."
       },
       // --- Updates ---
       {

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

@@ -4483,7 +4483,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 scoped per agent per project, 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 per-agent per-project corrections, memory for facts. Behaviors are always yours. Config is always yours. The platform will never modify your local data."
       },
       // --- Updates ---
       {

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

@@ -3755,7 +3755,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 scoped per agent per project, 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 per-agent per-project corrections, memory for facts. Behaviors are always yours. Config is always yours. The platform will never modify your local data."
       },
       // --- Updates ---
       {

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

@@ -3755,7 +3755,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 scoped per agent per project, 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 per-agent per-project corrections, memory for facts. Behaviors are always yours. Config is always yours. The platform will never modify your local data."
       },
       // --- Updates ---
       {

package/dist/bin/exe-status.js

@@ -4462,7 +4462,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 scoped per agent per project, 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 per-agent per-project corrections, memory for facts. Behaviors are always yours. Config is always yours. The platform will never modify your local data."
       },
       // --- Updates ---
       {

package/dist/bin/exe-team.js

@@ -4451,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 scoped per agent per project, 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 per-agent per-project corrections, memory for facts. Behaviors are always yours. Config is always yours. The platform will never modify your local data."
       },
       // --- Updates ---
       {

package/dist/bin/git-sweep.js

@@ -8210,7 +8210,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 scoped per agent per project, 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 per-agent per-project corrections, memory for facts. Behaviors are always yours. Config is always yours. The platform will never modify your local data."
       },
       // --- Updates ---
       {

package/dist/bin/graph-backfill.js

@@ -3668,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 scoped per agent per project, 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 per-agent per-project corrections, memory for facts. Behaviors are always yours. Config is always yours. The platform will never modify your local data."
       },
       // --- Updates ---
       {

package/dist/bin/graph-export.js

@@ -4440,7 +4440,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 scoped per agent per project, 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 per-agent per-project corrections, memory for facts. Behaviors are always yours. Config is always yours. The platform will never modify your local data."
       },
       // --- Updates ---
       {