@teammates/cli 0.1.0 → 0.2.0

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "@teammates/cli",
-  "version": "0.1.0",
+  "version": "0.2.0",
   "description": "Agent-agnostic CLI for teammates. Routes tasks, manages handoffs, and plugs into any coding agent backend.",
   "type": "module",
   "main": "dist/index.js",
@@ -16,7 +16,9 @@
     "build": "tsc",
     "dev": "tsc --watch",
     "test": "vitest run",
-    "test:watch": "vitest"
+    "test:coverage": "vitest run --coverage",
+    "test:watch": "vitest",
+    "typecheck": "tsc --noEmit"
   },
   "keywords": [
     "teammates",
@@ -28,11 +30,14 @@
   ],
   "license": "MIT",
   "dependencies": {
+    "@github/copilot-sdk": "file:../../../copilot-sdk/nodejs",
+    "@teammates/consolonia": "*",
     "chalk": "^5.6.2",
     "ora": "^9.3.0"
   },
   "devDependencies": {
-    "@types/node": "^20.0.0",
+    "@types/node": "^25.5.0",
+    "@vitest/coverage-v8": "^4.1.0",
     "typescript": "^5.5.0",
     "vitest": "^4.1.0"
   },

package/template/CROSS-TEAM.md

@@ -1,6 +1,6 @@
 # Cross-Team Notes
 
-Shared lessons that affect multiple teammates. Record here instead of duplicating across individual MEMORIES.md files.
+Shared lessons that affect multiple teammates. Record here instead of duplicating across individual WISDOM.md files.
 
 This file also serves as a **shared index** — teammates can add pointers to private docs in their folder that other teammates might find useful.
 
@@ -8,7 +8,7 @@ Reverse chronological. Tag affected teammates.
 
 ## Ownership Scopes
 
-Every teammate **owns everything** under their `.teammates/<name>/` folder — SOUL.md, MEMORIES.md, memory/, and any private docs they create. This is unconditional: no teammate needs permission to edit their own folder, and no other teammate should modify it.
+Every teammate **owns everything** under their `.teammates/<name>/` folder — SOUL.md, WISDOM.md, memory/, and any private docs they create. This is unconditional: no teammate needs permission to edit their own folder, and no other teammate should modify it.
 
 The **Boundary Rule** (see PROTOCOL.md) applies to the **codebase** — source code, configs, and shared framework files — not to a teammate's own `.teammates/<name>/` directory.
 

package/template/PROTOCOL.md

@@ -16,7 +16,7 @@ Individual teammates may define additional ethics in their SOUL.md specific to t
 
 **Never write code or modify files outside your ownership.** If a task requires changes to files you don't own, hand off that portion to the owning teammate. Design the behavior, write a spec if needed, then hand off — don't implement it yourself, even if the fix seems small or obvious. Your Boundaries section lists what you do NOT touch and who does.
 
-**Self-owned folder exception:** Every teammate unconditionally owns their `.teammates/<name>/` folder. You never need permission to edit your own SOUL.md, MEMORIES.md, memory logs, or private docs. The Boundary Rule applies to the **codebase** (source code, configs, shared framework files), not to your own teammate folder.
+**Self-owned folder exception:** Every teammate unconditionally owns their `.teammates/<name>/` folder. You never need permission to edit your own SOUL.md, WISDOM.md, memory files, or private docs. The Boundary Rule applies to the **codebase** (source code, configs, shared framework files), not to your own teammate folder.
 
 ### Cross-Domain Tasks
 
@@ -60,40 +60,97 @@ If the team includes a cross-cutting teammate (e.g., for quality/testing):
 - They advise on testing strategy but do not override domain decisions
 - They maintain quality metrics and benchmarks
 
+## Services
+
+Optional services are declared in `.teammates/services.json`. This file is checked into git so the entire team shares the same service configuration. Each key is a service name; the value is a config object (`{}` means installed with defaults).
+
+The CLI reads `services.json` to detect which services are available and injects their capabilities into teammate prompts automatically. Services are installed via the `/install` command.
+
 ## Memory
 
 ### How memory works
 
 Each session, every teammate wakes up fresh. Files are the only persistence layer — there is no RAM between sessions.
 
-At the start of each session, a teammate should read:
+Memory has three tiers:
+
+```
+Daily Logs  →  Memories  →  WISDOM
+(raw)          (typed)      (distilled)
+days           weeks        permanent
+```
 
-1. Their **SOUL.md** — identity, principles, boundaries
-2. Their **MEMORIES.md** — curated long-term knowledge
-3. Their **memory/YYYY-MM-DD.md** — today's and yesterday's daily logs
+### Session startup — read order
+
+At the start of each session, a teammate reads (in this order):
+
+1. **SOUL.md** — identity, principles, boundaries
+2. **WISDOM.md** — distilled principles from compacted memories
+3. **memory/YYYY-MM-DD.md** — today's and yesterday's daily logs
 4. **USER.md** — who the user is and how they prefer to work
+5. **memory/** typed files — browse or search on-demand as the task requires
+
+### Tier 1 — Daily Logs
 
-### Two layers of memory
+`memory/YYYY-MM-DD.md` — Append-only session notes. What was worked on, decided, what to pick up next. Start a new file each day. These are raw scratch — no frontmatter needed.
 
-- **MEMORIES.md** — Curated, durable knowledge: decisions, patterns, gotchas, bugs. Edit and refine over time. Remove entries that are no longer relevant.
-- **memory/YYYY-MM-DD.md** — Append-only daily logs. Capture what happened during a session: what was worked on, what was decided, what to pick up next. Start a new file each day.
+### Tier 2 — Typed Memories
+
+`memory/<type>_<topic>.md` — Individual files with frontmatter (`name`, `description`, `type`). Four types:
+
+| Type | When to save |
+|---|---|
+| `user` | User's role, preferences, knowledge level |
+| `feedback` | Corrections or guidance from the user |
+| `project` | Ongoing work, goals, deadlines, decisions |
+| `reference` | Pointers to external resources |
+
+See [TEMPLATE.md](TEMPLATE.md) for full format, body structure per type, and examples.
+
+### Tier 3 — Wisdom
+
+`WISDOM.md` — Distilled, high-signal principles derived from compacting multiple memories. Compact, stable, rarely changes. Read second (after SOUL.md).
+
+### Compaction — Memories → Wisdom
+
+Compaction distills typed memories into WISDOM.md entries. Run manually via `/compact` or automatically every 7 days.
+
+1. Review all typed memory files in `memory/`
+2. Identify patterns — recurring themes, reinforced feedback, confirmed lessons
+3. Distill into WISDOM.md entries — short, principled, event-agnostic
+4. Delete the source memory files that were fully absorbed
+5. Leave memories that are still active or evolving
+6. Update the "Last compacted" date in WISDOM.md
+
+A good wisdom entry is a **pattern** (not an incident), **principled** (states a rule), **compact** (1-3 sentences), and **actionable** (tells you what to do).
 
 ### When to write memory
 
-- Decisions, preferences, and durable facts go to **MEMORIES.md**
-- Day-to-day notes and running context go to **memory/YYYY-MM-DD.md**
-- If the user says "remember this," write it down immediately
-- Before ending a session, write anything worth preserving
+- User corrections and guidance → typed memory (`feedback`)
+- Decisions, deadlines, project context → typed memory (`project`)
+- User profile info → typed memory (`user`)
+- External resource locations → typed memory (`reference`)
+- Session notes and running context → daily log
+- If the user says "remember this," write it immediately
+
+### What NOT to save
+
+- Code patterns derivable from the code itself
+- Git history — use `git log` / `git blame`
+- Debugging solutions — the fix is in the code
+- Anything already in WISDOM.md
+- Ephemeral task details — use daily logs
 
 ### Sharing
 
-- Each teammate maintains their own MEMORIES.md and memory/ for domain-specific lessons
+- Each teammate maintains their own WISDOM.md and memory/ for domain-specific knowledge
 - **Cross-team lessons** go in [CROSS-TEAM.md](CROSS-TEAM.md) — one entry, tagged with affected teammates
-- Do NOT duplicate entries across multiple MEMORIES.md files
+- Wisdom is personal to each teammate — do not duplicate across teammates
+- **Private docs** — Teammates may create additional files and folders under their own `.teammates/<name>/` directory (e.g., `notes/`, `specs/`, `scratch/`). These are private by default. To make a doc visible to other teammates, add a pointer in [CROSS-TEAM.md](CROSS-TEAM.md) with a brief description of what it contains.
 
 ## Adding New Teammates
 
-1. Copy the SOUL.md and MEMORIES.md templates from [TEMPLATE.md](TEMPLATE.md) to a new folder under `.teammates/`
+1. Copy the SOUL.md and WISDOM.md templates from [TEMPLATE.md](TEMPLATE.md) to a new folder under `.teammates/`
 2. Fill in all sections with project-specific details
 3. Update README.md roster, last-active date, and routing guide
 4. Update existing teammates' SOUL.md ownership and boundary sections if domains shift

package/template/README.md

@@ -33,8 +33,8 @@
 Each teammate folder contains:
 
 - **SOUL.md** — Identity, continuity instructions, principles, boundaries, capabilities, and ownership
-- **MEMORIES.md** — Curated long-term lessons (reverse chronological)
-- **memory/** — Daily logs (`YYYY-MM-DD.md`), append-only, for session-level notes
+- **WISDOM.md** — Distilled principles from compacted memories (read second, after SOUL.md)
+- **memory/** — Daily logs (`YYYY-MM-DD.md`) and typed memory files (`<type>_<topic>.md`)
 - Additional files as needed (e.g., design docs, bug trackers)
 
 Root-level shared files:

package/template/TEMPLATE.md

@@ -1,6 +1,6 @@
 # New Teammate Template
 
-Copy the SOUL.md and MEMORIES.md structures below to `.teammates/<name>/` and fill in each file.
+Copy the SOUL.md and WISDOM.md structures below to `.teammates/<name>/` and fill in each file. Create an empty `memory/` directory for daily logs and typed memory files.
 
 ---
 
@@ -17,9 +17,10 @@ Copy the SOUL.md and MEMORIES.md structures below to `.teammates/<name>/` and fi
 
 Each session, you wake up fresh. These files _are_ your memory. Read them. Update them. They're how you persist.
 
-- Read your SOUL.md and MEMORIES.md at the start of every session.
+- Read your SOUL.md and WISDOM.md at the start of every session.
 - Read `memory/YYYY-MM-DD.md` for today and yesterday.
 - Read USER.md to understand who you're working with.
+- Browse `memory/` for typed memory files relevant to the current task (or use recall search if available).
 - Update your files as you learn. If you change SOUL.md, tell the user.
 - You may create additional private docs under your folder (e.g., `.teammates/<name>/notes/`, `.teammates/<name>/specs/`). To share a doc with other teammates, add a pointer to it in [CROSS-TEAM.md](../CROSS-TEAM.md).
 
@@ -31,7 +32,7 @@ Each session, you wake up fresh. These files _are_ your memory. Read them. Updat
 
 ## Boundaries
 
-**You unconditionally own everything under `.teammates/<name>/`** — your SOUL.md, MEMORIES.md, memory logs, and any private docs you create. No other teammate should modify your folder, and you never need permission to edit it.
+**You unconditionally own everything under `.teammates/<name>/`** — your SOUL.md, WISDOM.md, memory files, and any private docs you create. No other teammate should modify your folder, and you never need permission to edit it.
 
 **For the codebase** (source code, configs, shared framework files): if a task requires changes outside your ownership, hand off to the owning teammate. Design the behavior and write a spec if needed, but do not modify files you don't own — even if the change seems small.
 
@@ -77,33 +78,135 @@ Each session, you wake up fresh. These files _are_ your memory. Read them. Updat
 
 ---
 
-## MEMORIES.md Template
+## WISDOM.md Template
 
-```markdown
-# <Name> — Memories
+WISDOM.md contains distilled, high-signal principles derived from compacting multiple memories. This is the second file a teammate reads each session (after SOUL.md). It should be compact enough to read in a single pass.
 
-Curated long-term lessons, decisions, and patterns. Reverse chronological.
+```markdown
+# <Name> — Wisdom
 
-This file is for durable knowledge that stays relevant over time. For day-to-day notes, use `memory/YYYY-MM-DD.md`.
+Distilled principles. Read this first every session (after SOUL.md).
 
-Categories: Bug | Decision | Pattern | Gotcha | Optimization
+Last compacted: YYYY-MM-DD
 
-### YYYY-MM-DD: <Title>
-**Category:** <Category> | **Last updated:** YYYY-MM-DD
+---
 
-<What happened, what was learned, what to do differently.>
+_(No wisdom yet — principles emerge after the first compaction.)_
 ```
 
 ---
 
-## Daily Log Template
+## Memory Files
 
-Daily logs live at `.teammates/<name>/memory/YYYY-MM-DD.md`. They are append-only and capture what happened during a session.
+Memory lives in the `memory/` directory as individual files. There are two kinds:
+
+### Daily Logs
+
+Daily logs are append-only session notes at `memory/YYYY-MM-DD.md`. Start a new file each day.
 
 ```markdown
-# <Name> — YYYY-MM-DD
+# YYYY-MM-DD
 
 ## Notes
 
 - <What was worked on, what was decided, what to pick up next.>
 ```
+
+### Typed Memories
+
+Typed memories capture durable knowledge as individual files at `memory/<type>_<topic>.md`. Each file has frontmatter for searchability.
+
+**Types:**
+
+| Type | What to save | Body structure |
+|---|---|---|
+| `user` | User's role, goals, preferences, knowledge level | Free-form description of the user |
+| `feedback` | Corrections or guidance from the user | Rule, then **Why:** and **How to apply:** |
+| `project` | Ongoing work, goals, deadlines, decisions | Fact/decision, then **Why:** and **How to apply:** |
+| `reference` | Pointers to external resources | Resource location and when to use it |
+
+**Template:**
+
+```markdown
+---
+name: <memory name>
+description: <one-line description — used for relevance matching during search>
+type: <user | feedback | project | reference>
+---
+
+<memory content — structured per type (see table above)>
+```
+
+**Examples:**
+
+`memory/feedback_no_mocks.md`:
+```markdown
+---
+name: No mocks in integration tests
+description: Integration tests must use real services, not mocks — prior incident with mock/prod divergence
+type: feedback
+---
+
+Integration tests must hit a real database, not mocks.
+
+**Why:** Last quarter, mocked tests passed but the prod migration failed because mocks diverged from actual behavior.
+
+**How to apply:** When writing integration tests, always use the staging environment. Only use mocks for unit tests of pure logic.
+```
+
+`memory/reference_bug_tracker.md`:
+```markdown
+---
+name: Bug tracker location
+description: Pipeline bugs are tracked in Linear project INGEST
+type: reference
+---
+
+Pipeline bugs are tracked in the Linear project "INGEST". Check there for context on pipeline-related tickets.
+```
+
+### What NOT to save as a memory
+
+- Code patterns, conventions, or architecture — derive these from the current code
+- Git history or who-changed-what — use `git log` / `git blame`
+- Debugging solutions — the fix is in the code, the context is in the commit message
+- Anything already in WISDOM.md — memories get deleted after compaction
+- Ephemeral task details — use daily logs for in-progress work
+
+### Memory Index (optional)
+
+If the project uses `teammates-recall`, an optional `memory/INDEX.md` can serve as a lightweight pointer file listing all typed memory files with one-line descriptions. This aids recall indexing but is not required for the memory system to function.
+
+---
+
+## Compaction — Memories → Wisdom
+
+Compaction distills typed memories into WISDOM.md entries. Run it manually via `/compact` or automatically every 7 days.
+
+### Process
+
+1. **Review** all typed memory files in `memory/`
+2. **Identify patterns** — recurring themes, feedback that's been reinforced, lessons confirmed multiple times
+3. **Distill** into WISDOM.md entries — short, principled, event-agnostic. A wisdom entry should stand alone without needing the source memories for context
+4. **Delete** the source memory files that were fully absorbed
+5. **Leave** memories that are still active, evolving, or too recent to generalize
+6. **Update** the "Last compacted" date in WISDOM.md
+
+### What makes a good wisdom entry
+
+- **Pattern, not incident** — derived from multiple memories, not a single event
+- **Principled** — states a rule or heuristic, not a fact
+- **Compact** — 1-3 sentences. If it needs a paragraph, it's not distilled enough
+- **Actionable** — tells you what to do (or not do), not just what happened
+
+### Example compaction
+
+Three memories:
+- `feedback_no_mocks.md` — "Don't mock the database in tests"
+- `feedback_real_api.md` — "Use real API calls in integration tests"
+- `project_staging_env.md` — "Staging environment was set up for realistic testing"
+
+Become one wisdom entry:
+> **Test against reality** — Integration tests use real services, not mocks. Mock/prod divergence has caused incidents. Prefer the staging environment over in-process fakes.
+
+The three memory files are deleted. The wisdom entry persists.

package/template/example/SOUL.md

@@ -8,9 +8,10 @@ Atlas owns the backend API layer. They design and maintain REST endpoints, datab
 
 Each session, you wake up fresh. These files _are_ your memory. Read them. Update them. They're how you persist.
 
-- Read your SOUL.md and MEMORIES.md at the start of every session.
+- Read your SOUL.md and WISDOM.md at the start of every session.
 - Read `memory/YYYY-MM-DD.md` for today and yesterday.
 - Read USER.md to understand who you're working with.
+- Browse `memory/` for typed memory files relevant to the current task (or use recall search if available).
 - Update your files as you learn. If you change SOUL.md, tell the user.
 
 ## Core Principles

package/template/example/WISDOM.md

@@ -0,0 +1,9 @@
+# Atlas — Wisdom
+
+Distilled principles. Read this first every session (after SOUL.md).
+
+Last compacted: 2026-01-20
+
+---
+
+_(No wisdom yet — principles emerge after the first compaction.)_

package/dist/adapters/codex.d.ts

@@ -1,50 +0,0 @@
-/**
- * Codex adapter — runs each teammate as a `codex exec` subprocess.
- *
- * Uses the OpenAI Codex CLI in non-interactive mode:
- *   codex exec "<prompt>" --full-auto -C <cwd> -s <sandbox> -m <model>
- *
- * Each execution is stateless (no thread continuity). The teammate's full
- * identity, memory, and handoff context are injected into the prompt every time.
- *
- * Requirements:
- *   - `codex` CLI installed and on PATH
- *   - OPENAI_API_KEY or CODEX_API_KEY set in environment
- */
-import type { AgentAdapter } from "../adapter.js";
-import type { TeammateConfig, TaskResult, SandboxLevel } from "../types.js";
-export interface CodexAdapterOptions {
-    /** Codex model override (e.g. "o4-mini", "o3") */
-    model?: string;
-    /** Default sandbox level if teammate doesn't specify one */
-    defaultSandbox?: SandboxLevel;
-    /** Use --full-auto mode (default: true) */
-    fullAuto?: boolean;
-    /** Use --ephemeral to skip persisting session files (default: true) */
-    ephemeral?: boolean;
-    /** Additional CLI flags to pass to codex exec */
-    extraFlags?: string[];
-    /** Timeout in ms for codex exec (default: 300000 = 5 min) */
-    timeout?: number;
-    /** Path to codex binary (default: "codex") */
-    codexPath?: string;
-}
-export declare class CodexAdapter implements AgentAdapter {
-    readonly name = "codex";
-    private options;
-    constructor(options?: CodexAdapterOptions);
-    startSession(teammate: TeammateConfig): Promise<string>;
-    executeTask(sessionId: string, teammate: TeammateConfig, prompt: string): Promise<TaskResult>;
-    /**
-     * Spawn `codex exec` and capture its output.
-     * Prompt is passed via a temp file read with shell substitution.
-     */
-    private runCodex;
-    /** Build the argument list for codex exec */
-    private buildArgs;
-    /**
-     * Parse codex output into a TaskResult.
-     * Looks for changed files and handoff envelopes in the output.
-     */
-    private parseResult;
-}

package/dist/adapters/codex.js

@@ -1,213 +0,0 @@
-/**
- * Codex adapter — runs each teammate as a `codex exec` subprocess.
- *
- * Uses the OpenAI Codex CLI in non-interactive mode:
- *   codex exec "<prompt>" --full-auto -C <cwd> -s <sandbox> -m <model>
- *
- * Each execution is stateless (no thread continuity). The teammate's full
- * identity, memory, and handoff context are injected into the prompt every time.
- *
- * Requirements:
- *   - `codex` CLI installed and on PATH
- *   - OPENAI_API_KEY or CODEX_API_KEY set in environment
- */
-import { spawn } from "node:child_process";
-import { writeFile, unlink } from "node:fs/promises";
-import { tmpdir } from "node:os";
-import { join } from "node:path";
-import { randomUUID } from "node:crypto";
-import { buildTeammatePrompt } from "../adapter.js";
-let nextId = 1;
-export class CodexAdapter {
-    name = "codex";
-    options;
-    constructor(options = {}) {
-        this.options = {
-            model: options.model ?? "",
-            defaultSandbox: options.defaultSandbox ?? "workspace-write",
-            fullAuto: options.fullAuto ?? true,
-            ephemeral: options.ephemeral ?? true,
-            extraFlags: options.extraFlags ?? [],
-            timeout: options.timeout ?? 300_000,
-            codexPath: options.codexPath ?? "codex",
-        };
-    }
-    async startSession(teammate) {
-        // Codex exec is stateless — sessions are just logical IDs
-        return `codex-${teammate.name}-${nextId++}`;
-    }
-    async executeTask(sessionId, teammate, prompt) {
-        const fullPrompt = buildTeammatePrompt(teammate, prompt);
-        // Write prompt to a temp file to avoid shell escaping issues with long prompts
-        const promptFile = join(tmpdir(), `teammates-codex-${randomUUID()}.md`);
-        await writeFile(promptFile, fullPrompt, "utf-8");
-        try {
-            const output = await this.runCodex(teammate, promptFile);
-            return this.parseResult(teammate.name, output);
-        }
-        finally {
-            // Clean up temp file
-            await unlink(promptFile).catch(() => { });
-        }
-    }
-    /**
-     * Spawn `codex exec` and capture its output.
-     * Prompt is passed via a temp file read with shell substitution.
-     */
-    runCodex(teammate, promptFile) {
-        return new Promise((resolve, reject) => {
-            const args = this.buildArgs(teammate, promptFile);
-            const child = spawn(this.options.codexPath, args, {
-                cwd: teammate.cwd ?? process.cwd(),
-                env: { ...process.env },
-                stdio: ["ignore", "pipe", "pipe"],
-                timeout: this.options.timeout,
-                shell: true,
-            });
-            const stdout = [];
-            const stderr = [];
-            child.stdout.on("data", (chunk) => stdout.push(chunk));
-            child.stderr.on("data", (chunk) => {
-                stderr.push(chunk);
-                // Stream stderr to parent stderr for real-time progress
-                process.stderr.write(chunk);
-            });
-            child.on("close", (code) => {
-                const out = Buffer.concat(stdout).toString("utf-8");
-                const err = Buffer.concat(stderr).toString("utf-8");
-                if (code === 0) {
-                    resolve(out);
-                }
-                else {
-                    reject(new Error(`codex exec exited with code ${code}\nstderr: ${err}\nstdout: ${out}`));
-                }
-            });
-            child.on("error", (err) => {
-                reject(new Error(`Failed to spawn codex: ${err.message}`));
-            });
-        });
-    }
-    /** Build the argument list for codex exec */
-    buildArgs(teammate, promptFile) {
-        const args = ["exec"];
-        // Read prompt from file — avoids shell escaping issues
-        // Use shell substitution: $(cat <file>)
-        args.push(`"$(cat '${promptFile}')"`);
-        // Working directory
-        if (teammate.cwd) {
-            args.push("-C", teammate.cwd);
-        }
-        // Sandbox
-        const sandbox = teammate.sandbox ?? this.options.defaultSandbox;
-        args.push("-s", sandbox);
-        // Full auto
-        if (this.options.fullAuto) {
-            args.push("--full-auto");
-        }
-        // Ephemeral
-        if (this.options.ephemeral) {
-            args.push("--ephemeral");
-        }
-        // Model
-        if (this.options.model) {
-            args.push("-m", this.options.model);
-        }
-        // Extra flags
-        args.push(...this.options.extraFlags);
-        return args;
-    }
-    /**
-     * Parse codex output into a TaskResult.
-     * Looks for changed files and handoff envelopes in the output.
-     */
-    parseResult(teammateName, output) {
-        const changedFiles = parseChangedFiles(output);
-        const handoff = parseHandoffEnvelope(output);
-        const summary = extractSummary(output);
-        return {
-            teammate: teammateName,
-            success: true,
-            summary,
-            changedFiles,
-            handoff: handoff ?? undefined,
-            rawOutput: output,
-        };
-    }
-}
-/**
- * Extract file paths from codex output.
- * Looks for common patterns like "Created file: ...", "Modified: ...",
- * or git-style diff headers.
- */
-function parseChangedFiles(output) {
-    const files = new Set();
-    // Match diff headers: diff --git a/path b/path
-    for (const match of output.matchAll(/diff --git a\/(.+?) b\//g)) {
-        files.add(match[1]);
-    }
-    // Match "Created/Modified/Updated <path>" patterns
-    for (const match of output.matchAll(/(?:Created|Modified|Updated|Wrote|Edited)\s+(?:file:\s*)?[`"]?([^\s`"]+\.\w+)[`"]?/gi)) {
-        files.add(match[1]);
-    }
-    return Array.from(files);
-}
-/**
- * Look for a JSON handoff envelope in the output.
- * Teammates can request handoffs by including a fenced JSON block
- * with a "handoff" key:
- *
- * ```json
- * { "handoff": { "to": "tester", "task": "...", ... } }
- * ```
- */
-function parseHandoffEnvelope(output) {
-    // Look for ```json blocks containing "handoff"
-    const jsonBlocks = output.matchAll(/```json\s*\n([\s\S]*?)```/g);
-    for (const match of jsonBlocks) {
-        const block = match[1].trim();
-        if (!block.includes('"handoff"') && !block.includes('"to"'))
-            continue;
-        try {
-            const parsed = JSON.parse(block);
-            const envelope = parsed.handoff ?? parsed;
-            if (envelope.to && envelope.task) {
-                return {
-                    from: envelope.from ?? "",
-                    to: envelope.to,
-                    task: envelope.task,
-                    changedFiles: envelope.changedFiles ?? envelope.changed_files,
-                    acceptanceCriteria: envelope.acceptanceCriteria ?? envelope.acceptance_criteria,
-                    openQuestions: envelope.openQuestions ?? envelope.open_questions,
-                    context: envelope.context,
-                };
-            }
-        }
-        catch {
-            // Not valid JSON, skip
-        }
-    }
-    return null;
-}
-/**
- * Extract the first meaningful paragraph as a summary.
- * Falls back to the first 200 chars if no clear summary is found.
- */
-function extractSummary(output) {
-    // Look for a "## Summary" or "Summary:" section
-    const summaryMatch = output.match(/(?:##?\s*Summary|Summary:)\s*\n([\s\S]*?)(?:\n##|\n---|\n```|$)/i);
-    if (summaryMatch) {
-        const summary = summaryMatch[1].trim();
-        if (summary.length > 0)
-            return summary.slice(0, 500);
-    }
-    // Fall back to last non-empty paragraph (codex prints final message last)
-    const paragraphs = output
-        .split(/\n\s*\n/)
-        .map((p) => p.trim())
-        .filter((p) => p.length > 0 && !p.startsWith("```"));
-    if (paragraphs.length > 0) {
-        const last = paragraphs[paragraphs.length - 1];
-        return last.length > 500 ? last.slice(0, 497) + "..." : last;
-    }
-    return output.slice(0, 200).trim();
-}