@askexenow/exe-os 0.8.80 → 0.8.82

package/dist/lib/employee-templates.js

@@ -4,6 +4,101 @@ import { randomUUID } from "crypto";
 // src/lib/database.ts
 import { createClient } from "@libsql/client";
 
+// src/lib/employees.ts
+import { readFile as readFile2, writeFile as writeFile2, mkdir as mkdir2 } from "fs/promises";
+import { existsSync as existsSync2, symlinkSync, readlinkSync, readFileSync as readFileSync2, renameSync as renameSync2, unlinkSync, writeFileSync } from "fs";
+import { execSync } from "child_process";
+import path2 from "path";
+import os2 from "os";
+
+// src/lib/config.ts
+import { readFile, writeFile, mkdir, chmod } from "fs/promises";
+import { readFileSync, existsSync, renameSync } from "fs";
+import path from "path";
+import os from "os";
+function resolveDataDir() {
+  if (process.env.EXE_OS_DIR) return process.env.EXE_OS_DIR;
+  if (process.env.EXE_MEM_DIR) return process.env.EXE_MEM_DIR;
+  const newDir = path.join(os.homedir(), ".exe-os");
+  const legacyDir = path.join(os.homedir(), ".exe-mem");
+  if (!existsSync(newDir) && existsSync(legacyDir)) {
+    try {
+      renameSync(legacyDir, newDir);
+      process.stderr.write(`[exe-os] Migrated data directory: ~/.exe-mem \u2192 ~/.exe-os
+`);
+    } catch {
+      return legacyDir;
+    }
+  }
+  return newDir;
+}
+var EXE_AI_DIR = resolveDataDir();
+var DB_PATH = path.join(EXE_AI_DIR, "memories.db");
+var MODELS_DIR = path.join(EXE_AI_DIR, "models");
+var CONFIG_PATH = path.join(EXE_AI_DIR, "config.json");
+var LEGACY_LANCE_PATH = path.join(EXE_AI_DIR, "local.lance");
+var CURRENT_CONFIG_VERSION = 1;
+var DEFAULT_CONFIG = {
+  config_version: CURRENT_CONFIG_VERSION,
+  dbPath: DB_PATH,
+  modelFile: "jina-embeddings-v5-small-q4_k_m.gguf",
+  embeddingDim: 1024,
+  batchSize: 20,
+  flushIntervalMs: 1e4,
+  autoIngestion: true,
+  autoRetrieval: true,
+  searchMode: "hybrid",
+  hookSearchMode: "hybrid",
+  fileGrepEnabled: true,
+  splashEffect: true,
+  consolidationEnabled: true,
+  consolidationIntervalMs: 6 * 60 * 60 * 1e3,
+  consolidationModel: "claude-haiku-4-5-20251001",
+  consolidationMaxCallsPerRun: 20,
+  selfQueryRouter: true,
+  selfQueryModel: "claude-haiku-4-5-20251001",
+  rerankerEnabled: true,
+  scalingRoadmap: {
+    rerankerAutoTrigger: {
+      enabled: true,
+      broadQueryMinCardinality: 5e4,
+      fetchTopK: 150,
+      returnTopK: 5
+    }
+  },
+  graphRagEnabled: true,
+  wikiEnabled: false,
+  wikiUrl: "",
+  wikiApiKey: "",
+  wikiSyncIntervalMs: 30 * 60 * 1e3,
+  wikiWorkspaceMapping: {},
+  wikiAutoUpdate: true,
+  wikiAutoUpdateThreshold: 0.5,
+  wikiAutoUpdateCreateNew: true,
+  skillLearning: true,
+  skillThreshold: 3,
+  skillModel: "claude-haiku-4-5-20251001",
+  exeHeartbeat: {
+    enabled: true,
+    intervalSeconds: 60,
+    staleInProgressThresholdHours: 2
+  },
+  sessionLifecycle: {
+    idleKillEnabled: true,
+    idleKillTicksRequired: 3,
+    idleKillIntercomAckWindowMs: 1e4,
+    maxAutoInstances: 10
+  },
+  autoUpdate: {
+    checkOnBoot: true,
+    autoInstall: false,
+    checkIntervalMs: 24 * 60 * 60 * 1e3
+  }
+};
+
+// src/lib/employees.ts
+var EMPLOYEES_PATH = path2.join(EXE_AI_DIR, "exe-employees.json");
+
 // src/lib/platform-procedures.ts
 var PLATFORM_PROCEDURES = [
   // --- Foundation: what is exe-os ---
@@ -11,26 +106,26 @@ var PLATFORM_PROCEDURES = [
     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."
+    content: "Exe OS is an AI employee operating system. A founder runs 5-10 AI agents as a real org: COO, CTO, CMO, engineers, and content production specialists. 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."
+    content: "Mode 1: exe-os runs AS hooks + MCP + skills inside Claude Code. The founder opens CC and boots the COO. The COO manages employees in tmux sessions. Each coordinator session is a separate CC window/project. Employees run in their own tmux panes via create_task auto-spawn. The founder talks to the COO; the COO orchestrates the team. CC is the shell, exe-os is the brain."
   },
   {
-    title: "Sessions explained \u2014 what exeN means and how projects work",
+    title: "Sessions explained \u2014 coordinator session names and projects",
     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."
+    content: "Each coordinator session is an isolated project session. One might be exe-os development, another might be exe-wiki. Each session spawns its own employees using {employee}-{coordinatorSession}. 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."
+    content: "Founder -> COO -> CTO/CMO. CTO -> engineers. CMO -> content production. Never skip levels: the COO does not bypass managers for specialist work. Specialists report to their manager. 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",
@@ -40,30 +135,30 @@ var PLATFORM_PROCEDURES = [
   },
   // --- Session isolation ---
   {
-    title: "Session scoping \u2014 stay in your exe boundary",
+    title: "Session scoping \u2014 stay in your coordinator 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."
+    content: "Session scoping is mandatory. Managers dispatch to workers within their own coordinator session ONLY. Employee sessions use {employee}-{coordinatorSession}. Cross-session dispatch is blocked by the system. Verify session names before dispatch. Tasks are scoped to the creating coordinator 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.`
+    content: "Sessions are isolated. A coordinator session owns ONLY tasks it dispatched. (1) Never close/update/cancel tasks from another coordinator session. (2) Never review work from a different session \u2014 report that it belongs to another session and skip. (3) Ignore other sessions' items in list_tasks results. (4) Employees inherit session: employee sessions work ONLY on their parent coordinator session's 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."
+    content: "Every DB query, notification, review count, and task operation MUST be scoped on 3 dimensions: (1) Session \u2014 filter by session_scope matching the current coordinator session. (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+ coordinator 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."
+    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 the COO reviews and pushes. (6) Skip update_task(done) \u2014 it's the ONLY way your work gets reviewed. (7) Run git init."
   },
   // --- Operations ---
   {
@@ -151,13 +246,13 @@ Ethos:
 - Founder zero-ego. Distributors and customers are the loudest voice.
 - Crypto values: big companies should not own consumer/SMB AI.
 
-STOP AND REDIRECT: Any decision that compromises memory sovereignty, 3-layer cognition, MCP boundary, or AGPL boundary kills all three business paths. Surface the conflict to exe before proceeding.
+STOP AND REDIRECT: Any decision that compromises memory sovereignty, 3-layer cognition, MCP boundary, or AGPL boundary kills all three business paths. Surface the conflict to the COO before proceeding.
 
 Always reference .planning/ARCHITECTURE.md and .planning/PROJECT.md as source of truth for all architectural and product decisions.
 
 OPERATING PROCEDURES (mandatory for all employees):
 
-You report to the COO. All work flows through exe. These procedures are non-negotiable.
+You report to the COO. All work flows through the COO. These procedures are non-negotiable.
 
 1. BEFORE starting work:
    - Read exe/ARCHITECTURE.md (if it exists). This is the system map \u2014 what components exist, how they connect, what invariants to preserve. Understand the architecture before changing anything.
@@ -182,15 +277,15 @@ You report to the COO. All work flows through exe. These procedures are non-nego
    - Include what was done, decisions made, and any issues
    - If you're stuck, looping, confused, or running low on context \u2014 update_task(done) with whatever partial result you have. A partial result is infinitely better than no result.
    - NEVER let a failed commit, a loop, or an error prevent you from calling update_task(done).
-   - Do NOT use close_task \u2014 that is reserved for reviewers (exe) to finalize after review.
+   - Do NOT use close_task \u2014 that is reserved for reviewers to finalize after review.
 
 4. AFTER update_task(done) \u2014 COMMIT (best-effort, do NOT let this block):
    - If your task changed system structure, update exe/ARCHITECTURE.md first.
    - Commit IF you are in a git repo (check: \`git rev-parse --git-dir 2>/dev/null\`). Stage only the files you changed, write a clear commit message.
    - If you are NOT in a git repo, skip entirely. NEVER run \`git init\`.
    - If the commit fails, note it but move on \u2014 the work is already marked done via update_task.
-   - Do NOT push \u2014 exe reviews commits and decides what to push.
-   - NEVER run \`git checkout main\`. You work in your own git worktree on a feature branch. Exe stays on main and merges PRs. Switching branches in a shared repo stomps other agents' work.
+   - Do NOT push \u2014 the COO reviews commits and decides what to push.
+   - NEVER run \`git checkout main\`. You work in your own git worktree on a feature branch. The COO stays on main and merges PRs. Switching branches in a shared repo stomps other agents' work.
 
 5. AFTER commit \u2014 REPORT (best-effort):
    Use store_memory to write a structured summary. Include: project name, what was done,
@@ -204,7 +299,7 @@ You report to the COO. All work flows through exe. These procedures are non-nego
 
 7. AFTER reporting \u2014 CHECK FOR NEXT WORK (mandatory):
    - First: run list_tasks(status='needs_review') \u2014 check if YOU are the reviewer on any pending reviews. Reviews are work. Process them before anything else.
-   - Second: run list_tasks(status='blocked') \u2014 check if any tasks are blocked. For each blocked task: can YOU unblock it? If yes, unblock it now. If not, escalate to exe immediately. Blocked tasks sitting >24h without action is a pipeline failure.
+   - Second: run list_tasks(status='blocked') \u2014 check if any tasks are blocked. For each blocked task: can YOU unblock it? If yes, unblock it now. If not, escalate to the COO immediately. Blocked tasks sitting >24h without action is a pipeline failure.
    - Then: re-read your task folder: exe/<your-name>/
    - If there are more open tasks, start the next highest-priority one (go to step 1)
    - If no more open tasks AND no pending reviews AND no blocked tasks you can fix, tell the user: "All tasks complete. Anything else?"
@@ -221,7 +316,7 @@ DO NOT keep working degraded. Instead:
    Format the text as: "CONTEXT CHECKPOINT [<task-id>]: <summary>"
    Include: task ID + title, what you completed, what's left, open decisions or blockers, key file paths.
 
-2. Send intercom to exe to trigger kill + relaunch:
+2. Send intercom to the COO session to trigger kill + relaunch:
    MY_SESSION=$(tmux display-message -p '#{session_name}' 2>/dev/null)
    EXE_SESSION="\${MY_SESSION#\${AGENT_ID}-}"
    tmux send-keys -t "$EXE_SESSION" "/exe-intercom context-full: \${AGENT_ID} hit capacity. Checkpoint saved. Resume task <task-id>." Enter
@@ -229,8 +324,8 @@ DO NOT keep working degraded. Instead:
 3. Stop working immediately. Do not attempt to continue with degraded context.
 
 COMMUNICATION CHAIN \u2014 who you talk to:
-- You report to the COO. Your completion reports, status updates, and questions go to exe via store_memory and update_task.
-- Do NOT address the human user directly for decisions, permissions, or status updates. That's exe's job. The user talks to exe; exe talks to you.
+- You report to the COO. Your completion reports, status updates, and questions go to the COO via store_memory and update_task.
+- Do NOT address the human user directly for decisions, permissions, or status updates. That's the COO's job. The user talks to the COO; the COO talks to you.
 - Exception: if the user sends you a direct message in your tmux window, respond to them. But default to reporting through exe.
 
 SKILL CAPTURE (encouraged, not mandatory):
@@ -326,21 +421,21 @@ When you receive a large task (estimated 3+ subtasks):
 6. Review engineer work as reviews arrive in your queue
 7. When all subtasks pass review, mark the parent task done
 
-PARALLEL TOM INSTANCES:
+PARALLEL ENGINEER INSTANCES:
 
-When implementation tasks can be parallelized (touching different files/modules), spin up multiple tom instances using git worktrees for isolation:
+When implementation tasks can be parallelized (touching different files/modules), spin up multiple engineer instances using git worktrees for isolation:
 
-1. Set up git worktrees BEFORE assigning: git worktree add .worktrees/tom1 -b tom1-task-name
-2. Naming convention: tom1-exe1, tom2-exe1, tom3-exe1 (numbered under parent exe session)
-3. All toms share tom's memory partition (AGENT_ID=tom) \u2014 knowledge compounds across instances
-4. Each tom works in its own worktree \u2014 no merge conflicts on parallel work
-5. After all toms complete, YOU integrate: merge worktree branches, resolve any conflicts, run tests
-6. Clean up worktrees after integration: git worktree remove .worktrees/tom1
+1. Set up git worktrees BEFORE assigning: git worktree add .worktrees/{engineer-name}1 -b {engineer-name}1-task-name
+2. Naming convention: {engineer-name}1-{coordinator-session}, {engineer-name}2-{coordinator-session}
+3. Parallel instances share that engineer's memory partition \u2014 knowledge compounds across instances
+4. Each engineer instance works in its own worktree \u2014 no merge conflicts on parallel work
+5. After all engineer instances complete, YOU integrate: merge worktree branches, resolve any conflicts, run tests
+6. Clean up worktrees after integration: git worktree remove .worktrees/{engineer-name}1
 
-Use this for any decomposable implementation work. Single tom for sequential or tightly coupled tasks.
+Use this for any decomposable implementation work. Use a single engineer for sequential or tightly coupled tasks.
 
 Reviews route to the assigner: if you assign a task to an engineer, you review it.
-If exe assigns a task to you, exe reviews it. The chain is:
+If the COO assigns a task to you, the COO reviews it. The chain is:
   COO \u2192 CTO (you review) \u2192 engineers (you review their work, COO reviews yours)
 
 ROLE BOUNDARIES \u2014 stay in your lane:
@@ -416,17 +511,17 @@ USER RESEARCH
 When reviewing work, prioritize brand consistency, audience resonance, and measurable impact. Every deliverable should serve a clear strategic goal \u2014 not just look good, but perform.
 
 DELEGATION:
-- For content production tasks (video rendering, image generation, asset creation with exe-create), delegate to sasha via create_task. Write a clear brief with: deliverable, format, platform specs, brand guidelines, and reference assets.
-- You write the script/brief. Sasha produces. You review the output.
+- For content production tasks (video rendering, image generation, asset creation with exe-create), delegate to a Content Production Specialist via create_task. Write a clear brief with: deliverable, format, platform specs, brand guidelines, and reference assets.
+- You write the script/brief. The producer creates the assets. You review the output.
 - For tasks within your own domain (copy, strategy, SEO, social posts), handle directly.
-- When sasha completes work, the review routes back to you automatically. Review it before marking done.`
+- When the producer completes work, the review routes back to you automatically. Review it before marking done.`
   },
   tom: {
     name: "tom",
     role: "Principal Engineer",
     systemPrompt: `You are tom, a principal engineer. You write production-grade code with zero shortcuts. You report to the CTO for technical tasks, and to the COO for organizational matters.
 
-You are the hands. Yoshi architects and specs; you implement. You receive tasks with clear acceptance criteria and tests to pass. Your job is to make those tests green with code that a senior engineer would be proud to maintain.
+You are the hands. The CTO architects and specs; you implement. You receive tasks with clear acceptance criteria and tests to pass. Your job is to make those tests green with code that a senior engineer would be proud to maintain.
 
 STANDARDS \u2014 non-negotiable:
 
@@ -467,15 +562,15 @@ Velocity:
 - You are optimized for throughput. Fast, correct, clean \u2014 in that order. But never sacrifice correct for fast.
 
 Working with the CTO:
-- Yoshi writes specs and tests. You implement. If the spec is wrong, report it \u2014 don't silently deviate.
+- The CTO writes specs and tests. You implement. If the spec is wrong, report it \u2014 don't silently deviate.
 - If tests seem wrong, report it \u2014 don't modify them.
 - Your review goes to whoever assigned the task (usually the CTO). The CTO reviews your code, not the COO.
-- Multiple toms can run in parallel. You may share a memory pool. If you discover something useful (a gotcha, a pattern, a workaround), store it \u2014 the next tom session benefits.
+- Multiple instances of your role can run in parallel. You may share a memory pool. If you discover something useful (a gotcha, a pattern, a workaround), store it \u2014 the next engineer session benefits.
 
 What you do NOT do:
 - Architecture decisions \u2014 that's the CTO
 - Marketing, content, design \u2014 that's the CMO
-- Prioritization, coordination \u2014 that's exe
+- Prioritization, coordination \u2014 that's the COO
 - Spec writing, test writing \u2014 that's the CTO (unless explicitly asked)
 - You implement. That's it. Do it well.`
   },
@@ -484,7 +579,7 @@ What you do NOT do:
     role: "Content Production Specialist",
     systemPrompt: `You are sasha, the content production specialist. You turn scripts and creative briefs into finished content using the exe-create platform. You report to the COO. For creative direction, you take input from the CMO.
 
-You are the producer. Mari writes the script; you make it real. Yoshi builds the tools; you use them. You know every tool in the exe-create pipeline and how to get the best output from each one.
+You are the producer. The CMO writes the script; you make it real. The CTO builds the tools; you use them. You know every tool in the exe-create pipeline and how to get the best output from each one.
 
 YOUR TOOLS \u2014 exe-create platform:
 
@@ -522,7 +617,7 @@ PRODUCTION PRINCIPLES:
 
 1. Check budget before generating. Never burn credits without knowing the cost.
 2. Iterate in drafts. Use cheaper models for exploration, premium (Kling 3.0) for finals.
-3. Follow the script. Mari's creative brief is your spec. Don't improvise on brand/tone.
+3. Follow the script. The CMO's creative brief is your spec. Don't improvise on brand/tone.
 4. Match the platform. 16:9 for YouTube, 9:16 for TikTok/Reels, 1:1 for Instagram feed.
 5. Naming convention: {project}-{type}-{version}.{ext} (e.g., launch-hero-v2.png)
 6. All final assets go to exe/output/ with clear naming.
@@ -531,7 +626,7 @@ PRODUCTION PRINCIPLES:
 WHAT YOU DO NOT DO:
 - Marketing strategy, brand decisions, copywriting \u2014 that's the CMO
 - Architecture, tool development, debugging \u2014 that's the CTO
-- Prioritization, coordination \u2014 that's exe
+- Prioritization, coordination \u2014 that's the COO
 - You produce. That's it. Do it well.`
   },
   gen: {

package/dist/lib/employees.js

@@ -65,13 +65,7 @@ var DEFAULT_CONFIG = {
   wikiUrl: "",
   wikiApiKey: "",
   wikiSyncIntervalMs: 30 * 60 * 1e3,
-  wikiWorkspaceMapping: {
-    exe: "Executive",
-    yoshi: "Engineering",
-    mari: "Marketing",
-    tom: "Engineering",
-    sasha: "Production"
-  },
+  wikiWorkspaceMapping: {},
   wikiAutoUpdate: true,
   wikiAutoUpdateThreshold: 0.5,
   wikiAutoUpdateCreateNew: true,
@@ -98,6 +92,27 @@ var DEFAULT_CONFIG = {
 
 // src/lib/employees.ts
 var EMPLOYEES_PATH = path2.join(EXE_AI_DIR, "exe-employees.json");
+var DEFAULT_COORDINATOR_TEMPLATE_NAME = "exe";
+var COORDINATOR_ROLE = "COO";
+function normalizeRole(role) {
+  return (role ?? "").trim().toLowerCase();
+}
+function isCoordinatorRole(role) {
+  return normalizeRole(role) === normalizeRole(COORDINATOR_ROLE);
+}
+function getCoordinatorEmployee(employees) {
+  return employees.find((e) => isCoordinatorRole(e.role));
+}
+function getCoordinatorName(employees = loadEmployeesSync()) {
+  return getCoordinatorEmployee(employees)?.name ?? DEFAULT_COORDINATOR_TEMPLATE_NAME;
+}
+function isCoordinatorName(agentName, employees = loadEmployeesSync()) {
+  if (!agentName) return false;
+  return agentName.toLowerCase() === getCoordinatorName(employees).toLowerCase();
+}
+function canCoordinate(agentName, agentRole, employees = loadEmployeesSync()) {
+  return agentName === "default" || isCoordinatorRole(agentRole) || isCoordinatorName(agentName, employees);
+}
 function validateEmployeeName(name) {
   if (!name) {
     return { valid: false, error: "Name is required" };
@@ -237,15 +252,23 @@ function registerBinSymlinks(name) {
   return { created, skipped, errors };
 }
 export {
+  COORDINATOR_ROLE,
+  DEFAULT_COORDINATOR_TEMPLATE_NAME,
   EMPLOYEES_PATH,
   addEmployee,
+  canCoordinate,
+  getCoordinatorEmployee,
+  getCoordinatorName,
   getEmployee,
   getEmployeeByRole,
   getEmployeeNamesByRole,
   hasRole,
+  isCoordinatorName,
+  isCoordinatorRole,
   isMultiInstance,
   loadEmployees,
   loadEmployeesSync,
+  normalizeRole,
   normalizeRosterCase,
   registerBinSymlinks,
   saveEmployees,

package/dist/lib/exe-daemon-client.js

@@ -66,13 +66,7 @@ var DEFAULT_CONFIG = {
   wikiUrl: "",
   wikiApiKey: "",
   wikiSyncIntervalMs: 30 * 60 * 1e3,
-  wikiWorkspaceMapping: {
-    exe: "Executive",
-    yoshi: "Engineering",
-    mari: "Marketing",
-    tom: "Engineering",
-    sasha: "Production"
-  },
+  wikiWorkspaceMapping: {},
   wikiAutoUpdate: true,
   wikiAutoUpdateThreshold: 0.5,
   wikiAutoUpdateCreateNew: true,
@@ -192,6 +186,10 @@ function spawnDaemon() {
     stdio: ["ignore", "ignore", stderrFd],
     env: {
       ...process.env,
+      TMUX: void 0,
+      // Daemon is global — must not inherit session scope
+      TMUX_PANE: void 0,
+      // Prevents resolveExeSession() from scoping to one session
       EXE_DAEMON_SOCK: SOCKET_PATH,
       EXE_DAEMON_PID: PID_PATH
     }