@askexenow/exe-os 0.8.53 → 0.8.55

package/dist/index.js

@@ -2230,16 +2230,32 @@ var init_tasks_crud = __esm({
 // src/lib/tasks-review.ts
 import path10 from "path";
 import { existsSync as existsSync9, readdirSync as readdirSync2, unlinkSync as unlinkSync2 } from "fs";
-async function countPendingReviews() {
+async function countPendingReviews(sessionScope) {
   const client = getClient();
+  if (sessionScope) {
+    const result2 = await client.execute({
+      sql: "SELECT COUNT(*) as cnt FROM tasks WHERE status = 'needs_review' AND (session_scope = ? OR session_scope IS NULL)",
+      args: [sessionScope]
+    });
+    return Number(result2.rows[0]?.cnt) || 0;
+  }
   const result = await client.execute({
     sql: "SELECT COUNT(*) as cnt FROM tasks WHERE status = 'needs_review'",
     args: []
   });
   return Number(result.rows[0]?.cnt) || 0;
 }
-async function countNewPendingReviewsSince(sinceIso) {
+async function countNewPendingReviewsSince(sinceIso, sessionScope) {
   const client = getClient();
+  if (sessionScope) {
+    const result2 = await client.execute({
+      sql: `SELECT COUNT(*) as cnt FROM tasks
+            WHERE status = 'needs_review' AND updated_at > ?
+              AND (session_scope = ? OR session_scope IS NULL)`,
+      args: [sinceIso, sessionScope]
+    });
+    return Number(result2.rows[0]?.cnt) || 0;
+  }
   const result = await client.execute({
     sql: `SELECT COUNT(*) as cnt FROM tasks
           WHERE status = 'needs_review' AND updated_at > ?`,
@@ -4444,6 +4460,103 @@ var init_shard_manager = __esm({
   }
 });
 
+// src/lib/platform-procedures.ts
+var PLATFORM_PROCEDURES, PLATFORM_PROCEDURE_TITLES;
+var init_platform_procedures = __esm({
+  "src/lib/platform-procedures.ts"() {
+    "use strict";
+    PLATFORM_PROCEDURES = [
+      // --- Foundation: what is exe-os ---
+      {
+        title: "What is exe-os \u2014 the operating model every agent must understand",
+        domain: "architecture",
+        priority: "p0",
+        content: "Exe OS is an AI employee operating system. A founder runs 5-10 AI agents as a real org: COO (exe), CTO (yoshi), CMO (mari), engineers (tom), content (sasha). Each agent has identity, expertise, and experience layers \u2014 persistent memory that makes them better over time. All data is local-first, E2EE, owned by the user. The MCP server is the ONLY data interface \u2014 never access the DB directly."
+      },
+      {
+        title: "Mode 1 \u2014 how exe-os runs inside Claude Code",
+        domain: "architecture",
+        priority: "p0",
+        content: "Mode 1: exe-os runs AS hooks + MCP + skills inside Claude Code. The founder opens CC, runs /exe to boot the COO. exe manages employees in tmux sessions. Each exeN is a separate CC window/project. Employees (yoshi, tom, mari) run in their own tmux panes via create_task auto-spawn. The founder talks to exe; exe orchestrates the team. CC is the shell, exe-os is the brain."
+      },
+      {
+        title: "Sessions explained \u2014 what exeN means and how projects work",
+        domain: "architecture",
+        priority: "p0",
+        content: "Each exeN (exe1, exe2, exe3) is an isolated project session. exe1 might be exe-os development, exe2 might be exe-wiki. Each session spawns its own employees: exe1\u2192yoshi-exe1\u2192tom-exe1. Sessions share the same memory DB but tasks are scoped to the session that created them. A founder can run multiple projects simultaneously. Sessions never interfere with each other."
+      },
+      // --- Hierarchy and dispatch ---
+      {
+        title: "Chain of command \u2014 who talks to whom",
+        domain: "workflow",
+        priority: "p0",
+        content: "Founder \u2192 exe (COO) \u2192 yoshi (CTO) / mari (CMO). Yoshi \u2192 tom (engineer). Mari \u2192 sasha (content). Never skip levels: exe never assigns directly to tom. Tom never reports directly to exe. If you need cross-team info, use ask_team_memory \u2014 don't read other agents' task folders. Each level owns dispatch downward and review upward."
+      },
+      {
+        title: "Single dispatch path \u2014 create_task only",
+        domain: "workflow",
+        priority: "p0",
+        content: "create_task is the ONLY way to dispatch work to another agent. No direct ensureEmployee calls, no manual tmux spawns, no send_message for actionable work. create_task \u2192 system auto-spawns \u2192 session correctly named. ONE PATH. No backdoors. No exceptions."
+      },
+      // --- Session isolation ---
+      {
+        title: "Session scoping \u2014 stay in your exe boundary",
+        domain: "security",
+        priority: "p0",
+        content: "Session scoping is mandatory. Managers dispatch to workers within their own exe session ONLY. exe1\u2192yoshi-exe1\u2192tom-exe1. exe2\u2192yoshi-exe2\u2192tom2-exe2. Cross-session dispatch is blocked by the system. Verify session names before dispatch. Tasks are scoped to the creating exe session."
+      },
+      {
+        title: "Session isolation \u2014 never touch another session's work",
+        domain: "workflow",
+        priority: "p0",
+        content: `Sessions are isolated. exeN owns ONLY tasks it dispatched. (1) Never close/update/cancel tasks from another exe session. (2) Never review work from a different session \u2014 report "belongs to exeN" and skip. (3) Ignore other sessions' items in list_tasks results. (4) Employees inherit session: yoshi-exe1 works ONLY on exe1 tasks. Cross-session work is a system violation.`
+      },
+      // --- Engineering: session scoping in code ---
+      {
+        title: "Three-dimensional scoping \u2014 session, project, role \u2014 enforced in every query",
+        domain: "architecture",
+        priority: "p0",
+        content: "Every DB query, notification, review count, and task operation MUST be scoped on 3 dimensions: (1) Session \u2014 filter by session_scope matching current exeN. (2) Project \u2014 filter by project_name. (3) Role \u2014 agents only see data at their hierarchy level. When writing ANY function that touches tasks, reviews, messages, or notifications: always accept a sessionScope parameter and pass it to the SQL WHERE clause. Unscoped queries are bugs. Test by running 2+ exe sessions simultaneously."
+      },
+      // --- Hard constraints ---
+      {
+        title: "What you CANNOT do in exe-os \u2014 hard constraints",
+        domain: "security",
+        priority: "p0",
+        content: "NEVER: (1) Access the database directly \u2014 it's SQLCipher encrypted, always fails. Use MCP tools only. (2) Manually spawn tmux sessions \u2014 create_task handles it. (3) Run git checkout main \u2014 agents work in worktrees. (4) Modify another agent's in-progress task. (5) Push to remote \u2014 exe reviews and pushes. (6) Skip update_task(done) \u2014 it's the ONLY way your work gets reviewed. (7) Run git init."
+      },
+      // --- Operations ---
+      {
+        title: "Managers must supervise deployed workers",
+        domain: "workflow",
+        priority: "p0",
+        content: `Every manager (COO/CTO/CMO) who dispatches work to a worker MUST actively monitor them. Check tmux capture-pane every 10 minutes. Verify they're working, not stuck. If idle at prompt with in_progress task \u2192 send intercom. If stuck \u2192 unblock or escalate. "Standing by" without checking is negligence.`
+      },
+      {
+        title: "COO boot health check \u2014 memory, cloud sync, daemon on every launch",
+        domain: "workflow",
+        priority: "p0",
+        content: "On every /exe boot, COO MUST check system health BEFORE other work: (1) daemon \u2014 is exed PID alive, (2) cloud sync \u2014 grep workers.log for recent cloud-sync errors, (3) memory count \u2014 total in DB, (4) sync delta \u2014 local vs cloud storage_bytes. Report as 4-line status table. If ANY check fails, surface to founder immediately. Do not proceed to tasks until health confirmed."
+      },
+      {
+        title: "exe-build-adv mandatory for 3+ files",
+        domain: "workflow",
+        priority: "p0",
+        content: "exe-build-adv is MANDATORY for ALL work touching 3+ files. Run /exe-build-adv --auto BEFORE implementation. Pipeline: Spec \u2192 AC \u2192 Tests \u2192 Evaluate \u2192 Fix. No multi-file feature ships without pipeline artifacts. No exceptions \u2014 managers reject work without them."
+      },
+      {
+        title: "Desktop and TUI are the same product",
+        domain: "architecture",
+        priority: "p0",
+        content: "Desktop and TUI are the SAME product in different renderers. Same data contracts, same interactions, same acceptance criteria. Desktop tab specs in ARCHITECTURE.md ARE the TUI specs. When building TUI, cross-reference Desktop spec. Different tab names, identical behavior. Never treat them as separate products."
+      }
+    ];
+    PLATFORM_PROCEDURE_TITLES = new Set(
+      PLATFORM_PROCEDURES.map((p) => p.title)
+    );
+  }
+});
+
 // src/lib/global-procedures.ts
 var global_procedures_exports = {};
 __export(global_procedures_exports, {
@@ -4459,22 +4572,25 @@ async function loadGlobalProcedures() {
     sql: "SELECT * FROM global_procedures WHERE active = 1 ORDER BY priority ASC, created_at ASC",
     args: []
   });
-  const procedures = result.rows;
-  if (procedures.length > 0) {
-    _cache = procedures.map((p) => `### ${p.title}
+  const allRows = result.rows;
+  const customerOnly = allRows.filter((p) => !PLATFORM_PROCEDURE_TITLES.has(p.title));
+  if (customerOnly.length > 0) {
+    _customerCache = customerOnly.map((p) => `### ${p.title}
 ${p.content}`).join("\n\n");
   } else {
-    _cache = "";
+    _customerCache = "";
   }
   _cacheLoaded = true;
-  return procedures;
+  return customerOnly;
 }
 function getGlobalProceduresBlock() {
-  if (!_cacheLoaded) return "";
-  if (!_cache) return "";
+  const sections = [];
+  if (_platformCache) sections.push(_platformCache);
+  if (_cacheLoaded && _customerCache) sections.push(_customerCache);
+  if (sections.length === 0) return "";
   return `## Organization-Wide Procedures (MANDATORY \u2014 supersedes all other rules)
 
-${_cache}
+${sections.join("\n\n")}
 `;
 }
 async function storeGlobalProcedure(input) {
@@ -4499,13 +4615,16 @@ async function deactivateGlobalProcedure(id) {
   await loadGlobalProcedures();
   return result.rowsAffected > 0;
 }
-var _cache, _cacheLoaded;
+var _customerCache, _cacheLoaded, _platformCache;
 var init_global_procedures = __esm({
   "src/lib/global-procedures.ts"() {
     "use strict";
     init_database();
-    _cache = "";
+    init_platform_procedures();
+    _customerCache = "";
     _cacheLoaded = false;
+    _platformCache = PLATFORM_PROCEDURES.map((p) => `### ${p.title}
+${p.content}`).join("\n\n");
   }
 });
 

package/dist/lib/cloud-sync.js

@@ -845,9 +845,17 @@ async function cloudPullGlobalProcedures(config) {
   if (!remoteProcs || remoteProcs.length === 0) return { pulled: 0 };
   const client = getClient();
   const stmts = remoteProcs.map((p) => ({
-    sql: `INSERT OR IGNORE INTO global_procedures
+    sql: `INSERT INTO global_procedures
           (id, title, content, priority, domain, active, created_at, updated_at)
-          VALUES (?, ?, ?, ?, ?, ?, ?, ?)`,
+          VALUES (?, ?, ?, ?, ?, ?, ?, ?)
+          ON CONFLICT(id) DO UPDATE SET
+            title = excluded.title,
+            content = excluded.content,
+            priority = excluded.priority,
+            domain = excluded.domain,
+            active = excluded.active,
+            updated_at = excluded.updated_at
+          WHERE excluded.updated_at > global_procedures.updated_at`,
     args: [
       p.id ?? null,
       p.title ?? null,

package/dist/lib/employee-templates.js

@@ -4,15 +4,110 @@ import { randomUUID } from "crypto";
 // src/lib/database.ts
 import { createClient } from "@libsql/client";
 
+// src/lib/platform-procedures.ts
+var PLATFORM_PROCEDURES = [
+  // --- Foundation: what is exe-os ---
+  {
+    title: "What is exe-os \u2014 the operating model every agent must understand",
+    domain: "architecture",
+    priority: "p0",
+    content: "Exe OS is an AI employee operating system. A founder runs 5-10 AI agents as a real org: COO (exe), CTO (yoshi), CMO (mari), engineers (tom), content (sasha). Each agent has identity, expertise, and experience layers \u2014 persistent memory that makes them better over time. All data is local-first, E2EE, owned by the user. The MCP server is the ONLY data interface \u2014 never access the DB directly."
+  },
+  {
+    title: "Mode 1 \u2014 how exe-os runs inside Claude Code",
+    domain: "architecture",
+    priority: "p0",
+    content: "Mode 1: exe-os runs AS hooks + MCP + skills inside Claude Code. The founder opens CC, runs /exe to boot the COO. exe manages employees in tmux sessions. Each exeN is a separate CC window/project. Employees (yoshi, tom, mari) run in their own tmux panes via create_task auto-spawn. The founder talks to exe; exe orchestrates the team. CC is the shell, exe-os is the brain."
+  },
+  {
+    title: "Sessions explained \u2014 what exeN means and how projects work",
+    domain: "architecture",
+    priority: "p0",
+    content: "Each exeN (exe1, exe2, exe3) is an isolated project session. exe1 might be exe-os development, exe2 might be exe-wiki. Each session spawns its own employees: exe1\u2192yoshi-exe1\u2192tom-exe1. Sessions share the same memory DB but tasks are scoped to the session that created them. A founder can run multiple projects simultaneously. Sessions never interfere with each other."
+  },
+  // --- Hierarchy and dispatch ---
+  {
+    title: "Chain of command \u2014 who talks to whom",
+    domain: "workflow",
+    priority: "p0",
+    content: "Founder \u2192 exe (COO) \u2192 yoshi (CTO) / mari (CMO). Yoshi \u2192 tom (engineer). Mari \u2192 sasha (content). Never skip levels: exe never assigns directly to tom. Tom never reports directly to exe. If you need cross-team info, use ask_team_memory \u2014 don't read other agents' task folders. Each level owns dispatch downward and review upward."
+  },
+  {
+    title: "Single dispatch path \u2014 create_task only",
+    domain: "workflow",
+    priority: "p0",
+    content: "create_task is the ONLY way to dispatch work to another agent. No direct ensureEmployee calls, no manual tmux spawns, no send_message for actionable work. create_task \u2192 system auto-spawns \u2192 session correctly named. ONE PATH. No backdoors. No exceptions."
+  },
+  // --- Session isolation ---
+  {
+    title: "Session scoping \u2014 stay in your exe boundary",
+    domain: "security",
+    priority: "p0",
+    content: "Session scoping is mandatory. Managers dispatch to workers within their own exe session ONLY. exe1\u2192yoshi-exe1\u2192tom-exe1. exe2\u2192yoshi-exe2\u2192tom2-exe2. Cross-session dispatch is blocked by the system. Verify session names before dispatch. Tasks are scoped to the creating exe session."
+  },
+  {
+    title: "Session isolation \u2014 never touch another session's work",
+    domain: "workflow",
+    priority: "p0",
+    content: `Sessions are isolated. exeN owns ONLY tasks it dispatched. (1) Never close/update/cancel tasks from another exe session. (2) Never review work from a different session \u2014 report "belongs to exeN" and skip. (3) Ignore other sessions' items in list_tasks results. (4) Employees inherit session: yoshi-exe1 works ONLY on exe1 tasks. Cross-session work is a system violation.`
+  },
+  // --- Engineering: session scoping in code ---
+  {
+    title: "Three-dimensional scoping \u2014 session, project, role \u2014 enforced in every query",
+    domain: "architecture",
+    priority: "p0",
+    content: "Every DB query, notification, review count, and task operation MUST be scoped on 3 dimensions: (1) Session \u2014 filter by session_scope matching current exeN. (2) Project \u2014 filter by project_name. (3) Role \u2014 agents only see data at their hierarchy level. When writing ANY function that touches tasks, reviews, messages, or notifications: always accept a sessionScope parameter and pass it to the SQL WHERE clause. Unscoped queries are bugs. Test by running 2+ exe sessions simultaneously."
+  },
+  // --- Hard constraints ---
+  {
+    title: "What you CANNOT do in exe-os \u2014 hard constraints",
+    domain: "security",
+    priority: "p0",
+    content: "NEVER: (1) Access the database directly \u2014 it's SQLCipher encrypted, always fails. Use MCP tools only. (2) Manually spawn tmux sessions \u2014 create_task handles it. (3) Run git checkout main \u2014 agents work in worktrees. (4) Modify another agent's in-progress task. (5) Push to remote \u2014 exe reviews and pushes. (6) Skip update_task(done) \u2014 it's the ONLY way your work gets reviewed. (7) Run git init."
+  },
+  // --- Operations ---
+  {
+    title: "Managers must supervise deployed workers",
+    domain: "workflow",
+    priority: "p0",
+    content: `Every manager (COO/CTO/CMO) who dispatches work to a worker MUST actively monitor them. Check tmux capture-pane every 10 minutes. Verify they're working, not stuck. If idle at prompt with in_progress task \u2192 send intercom. If stuck \u2192 unblock or escalate. "Standing by" without checking is negligence.`
+  },
+  {
+    title: "COO boot health check \u2014 memory, cloud sync, daemon on every launch",
+    domain: "workflow",
+    priority: "p0",
+    content: "On every /exe boot, COO MUST check system health BEFORE other work: (1) daemon \u2014 is exed PID alive, (2) cloud sync \u2014 grep workers.log for recent cloud-sync errors, (3) memory count \u2014 total in DB, (4) sync delta \u2014 local vs cloud storage_bytes. Report as 4-line status table. If ANY check fails, surface to founder immediately. Do not proceed to tasks until health confirmed."
+  },
+  {
+    title: "exe-build-adv mandatory for 3+ files",
+    domain: "workflow",
+    priority: "p0",
+    content: "exe-build-adv is MANDATORY for ALL work touching 3+ files. Run /exe-build-adv --auto BEFORE implementation. Pipeline: Spec \u2192 AC \u2192 Tests \u2192 Evaluate \u2192 Fix. No multi-file feature ships without pipeline artifacts. No exceptions \u2014 managers reject work without them."
+  },
+  {
+    title: "Desktop and TUI are the same product",
+    domain: "architecture",
+    priority: "p0",
+    content: "Desktop and TUI are the SAME product in different renderers. Same data contracts, same interactions, same acceptance criteria. Desktop tab specs in ARCHITECTURE.md ARE the TUI specs. When building TUI, cross-reference Desktop spec. Different tab names, identical behavior. Never treat them as separate products."
+  }
+];
+var PLATFORM_PROCEDURE_TITLES = new Set(
+  PLATFORM_PROCEDURES.map((p) => p.title)
+);
+
 // src/lib/global-procedures.ts
-var _cache = "";
+var _customerCache = "";
 var _cacheLoaded = false;
+var _platformCache = PLATFORM_PROCEDURES.map((p) => `### ${p.title}
+${p.content}`).join("\n\n");
 function getGlobalProceduresBlock() {
-  if (!_cacheLoaded) return "";
-  if (!_cache) return "";
+  const sections = [];
+  if (_platformCache) sections.push(_platformCache);
+  if (_cacheLoaded && _customerCache) sections.push(_customerCache);
+  if (sections.length === 0) return "";
   return `## Organization-Wide Procedures (MANDATORY \u2014 supersedes all other rules)
 
-${_cache}
+${sections.join("\n\n")}
 `;
 }