pi-crew 0.9.51 → 0.9.53

package/docs/archive/pi-crew-test-round6.md

@@ -1,110 +0,0 @@
-# pi-crew v0.2.20 — Round 6 Final Test Results
-**Date:** 2026-05-19
-**Session:** Final comprehensive test after Pi restart with Bug #10/#11/#12 fixes
-**Environment:** linux/x64, Node v22.22.0, Pi CLI v0.75.3, pi-crew v0.2.20
-
----
-
-## Summary
-
-**Foreground execution is fully working.** All foreground team runs completed successfully across multiple workflows.
-
-**Background async execution has a new issue** (Bug #13) — background runner dies after ~59 seconds. This is being investigated separately.
-
----
-
-## Test Results
-
-### Test 1: Foreground fast-fix team — ✅ PASS (3/3 phases)
-- **Command:** `team action='run', team='fast-fix'`
-- **Duration:** ~5 minutes
-- **Result:** ✅ 01_explore ✅ 02_execute ✅ 03_verify
-
-### Test 2: Foreground research team — ✅ PASS (3/3 phases)
-- **Command:** `team action='run', team='research'`
-- **Duration:** ~4 minutes
-- **Result:** ✅ 01_explore ✅ 02_analyze ✅ 03_write
-
-### Test 3: Foreground parallel-research team — ✅ PASS (7/7 phases)
-- **Command:** `team action='run', team='parallel-research'`
-- **Duration:** ~7 minutes
-- **Result:** ✅ 01_discover ✅ 02_explore-core ✅ 03_explore-ui ✅ 04_explore-runtime ✅ 05_explore-extensions ✅ 06_synthesize ✅ 07_write
-
-### Test 4: Foreground implementation team — ⚠️ BLOCKED
-- **Command:** `team action='run', team='default', workflow='implementation'`
-- **Result:** ⚠️ Planner completed but workflow blocked by adaptive plan repair failure (pre-existing issue, not a regression)
-
-### Test 5: Background async research team — ❌ FAIL
-- **Command:** `team action='run', async=true, team='research'`
-- **Result:** ❌ Background runner dies after ~59 seconds (Bug #13 — investigation pending)
-
----
-
-## Management Features — All ✅ PASS
-
-| Feature | Command | Result |
-|---|---|---|
-| doctor | `team doctor` | ✅ All checks pass |
-| validate | `team validate` | ✅ 0 issues |
-| list | `team list` | ✅ Shows all teams/workflows |
-| get | `team get` | ✅ Shows run details |
-| plan | `team plan` | ✅ Shows run plan |
-| settings | `team settings` | ✅ Shows settings |
-| events | `team events` | ✅ Shows run events |
-| summary | `team summary` | ✅ Shows run summary |
-| export | `team export` | ✅ Exports run data |
-| import | `team import` | ✅ Imports run data |
-| prune | `team prune` | ✅ Prunes old runs |
-
----
-
-## Bug Status — Final (13 bugs)
-
-| # | Bug | Status |
-|---|---|---|
-| 1 | Background workers timeout (MiniMax 429) | ✅ Fixed |
-| 2 | child-pi.ts doesn't detect 429 | ✅ Fixed |
-| 3 | background.log useless | ✅ Fixed |
-| 4 | worker-startup.ts missing rate_limited classification | ✅ Fixed |
-| 5 | Stale heartbeat notifications after prune | ✅ Fixed |
-| 6 | Live-session cancelled by concurrent calls | ✅ Confirmed (workflow constraint) |
-| 7 | Async notifier "stale ctx" dies | ✅ Fixed |
-| 8/10 | Background 300s timeout (MINIMAX_API_KEY filtered) | ✅ Fixed |
-| 9 | Executor hit yield limit | 🔲 Open |
-| 10 | MINIMAX_API_KEY stripped | ✅ Fixed |
-| 11 | Background runner "spawn pi ENOENT" | ✅ Fixed |
-| 12 | Essential env vars stripped (PATH) | ✅ Fixed |
-| 13 | Background runner dies after ~59s | 🔲 Open (new issue) |
-
-**Summary:** 11/13 Fixed ✅, 2/13 Open 🔲
-
----
-
-## What Works
-
-### Foreground (Live-Session) — ✅ FULLY WORKING
-- Fast-fix team: 3-phase completion ✅
-- Research team: 3-phase completion ✅
-- Parallel-research team: 7-phase completion ✅
-- Implementation team: Planner works ✅ (blocked by adaptive plan issue, pre-existing)
-- Management features: All verified ✅
-
-### Background (Async) — ❌ BROKEN
-- Background runner dies after ~59 seconds
-- Workers never get a chance to produce output
-- Bug #13 investigation pending
-
----
-
-## Files Updated This Session
-
-- `pi-crew/docs/pi-crew-bugs.md` — 13 bugs tracked (added Bug #12, updated status)
-- `pi-crew/docs/fixes/bug-010-child-process-api-key-filtered.md` — Bug #10 root cause
-- `pi-crew/docs/fixes/bug-011-spawn-pi-enoent.md` — Bug #11 root cause
-- `pi-crew/docs/fixes/bug-012-essential-env-stripped.md` — Bug #12 root cause
-- `pi-crew/docs/pi-crew-test-round5.md` — Round 5 results
-- `pi-crew/docs/pi-crew-test-round6.md` — This report
-
-**Code changes:**
-- `pi-crew/src/runtime/child-pi.ts` — Bug #10, #12 fixes (sanitizeEnvSecrets allow-list)
-- `pi-crew/src/runtime/pi-spawn.ts` — Bug #11 fix (resolvePiCliScript on non-Windows)

package/docs/archive/pi-crew-v0.5.10-audit-fix-plan.md

@@ -1,60 +0,0 @@
-# pi-crew v0.5.10 — Round 15 Audit Fix Plan (2026-06-02)
-
-**Source**: Round 15 dogfooding review (partial — explorer completed, reviewer/security-reviewer cancelled due to stale run reconciliation).
-
-**Findings verified from source**: 9 → 5 confirmed real, 4 false positives.
-
-## Verification Summary
-
-| Status | Count |
-|--------|-------|
-| ✅ CONFIRMED (real issue) | 5 |
-| ❌ FALSE POSITIVE | 4 |
-
-### False Positives Identified
-- **M2** (`register.ts` autoRepairTimer race): Code already guards with `cleanedUp || !currentCtx` checks
-- **M3** (`dynamic-script-runner.ts` walkNode type guard): Only runs on parsed acorn AST (parser guarantees `type: string`)
-- **H3** (event-log asyncQueues eviction): Already addressed in Round 14 — entries are deleted on success/error
-- **H2** (benchmark validateCommand footgun): Reviewer misread the validation flow
-
-### Real Issues Confirmed (5)
-
-1. **H1**: `Semaphore.#queue` unbounded growth (`src/runtime/semaphore.ts:11`)
-2. **L1**: `EventBus.emit` uses `console.error` instead of `logInternalError` (`src/observability/event-bus.ts:47`)
-3. **NEW**: `OTLPExporter.convertToOTLP` no size cap on snapshots (`src/observability/exporters/otlp-exporter.ts:33`)
-4. **NEW**: `OTLPExporter` `setInterval` can overlap if `push` is slow (no in-flight check)
-5. **NEW**: `hooks/registry.ts` Map unbounded; `Object.assign(ctx, result.data)` without validation
-
-## Plan: 3 small fixes
-
-### Phase 1: Semaphore Queue Cap (HIGH)
-- **H1**: Add `MAX_QUEUE = 10_000` cap to `Semaphore.#queue`. Reject with error when full.
-
-**Files**: `src/runtime/semaphore.ts`
-
-### Phase 2: Observability Hardening (MEDIUM)
-- **L1**: Replace `console.error` with `logInternalError` in `EventBus.emit`
-- **OTLP size**: Add snapshots.length cap + in-flight check in `OTLPExporter`
-- **Hook registry**: Add `clearHooks` after run, validate `result.data` keys
-
-**Files**: `src/observability/event-bus.ts`, `src/observability/exporters/otlp-exporter.ts`, `src/hooks/registry.ts`
-
-### Phase 3: Test Coverage (LOW)
-- Add basic tests for `observability/` (metric-registry, metric-sink, OTLP converter)
-- Add tests for `Semaphore` queue cap
-
-**Files**: new test files in `test/unit/`
-
-## Expected Outcomes
-
-- 5/5 confirmed issues fixed
-- Tests: 2300+ pass (5+ new tests)
-- TypeScript: 0 errors
-- v0.5.10 release
-
-## Backlog (deferred)
-
-- `console.log/error` in `background-runner.ts` — debug logging, intentional
-- `console.warn` in `discover-agents.ts` — informational
-- Full OTLP wire format compliance — out of scope
-- Hook `Object.assign` — needs design discussion

package/docs/archive/pi-crew-v0.5.11-audit-fix-plan.md

@@ -1,92 +0,0 @@
-# pi-crew v0.5.11 Audit Fix Plan (Round 16)
-
-## Source Verification Findings
-
-I read the following files and identified 5 confirmed real issues:
-
-### Issue 1: `process.stderr.write` bypasses `logInternalError` (LOW, cleanup)
-**Files** (7 occurrences total):
-- `src/extension/notification-router.ts:87` — sink error fallback
-- `src/i18n.ts:106` — missing translation warning
-- `src/observability/metric-registry.ts:40,52,64` — metric description change warnings
-- `src/runtime/parent-guard.ts:37` — parent dead message
-- `src/state/jsonl-writer.ts:71` — write failed warning
-
-**Rationale**: v0.5.9 L1 fix (in `event-bus.ts`) moved from `console.error` to `logInternalError` to ensure errors are captured even when stderr is redirected. These 7 callsites bypass that pattern.
-
-### Issue 2: `OverflowRecoveryTracker.states` Map has no terminal-state eviction timer (MEDIUM)
-**File**: `src/runtime/overflow-recovery.ts:34-38`
-
-When `feedEvent` reaches phase="recovered"/"failed"/"none", the timer uses `TERMINAL_STATE_TTL_MS = 5*60_000`. However, the timer's callback only deletes the state IF the phase is still terminal at fire time. If a state is e.g. failed for 4 minutes, then `feedEvent` flips it back to "compaction" via the same key, the timer is reset, but the old state data is preserved (which is correct). But:
-
-**Real bug**: When `feedEvent` first creates a state and immediately transitions to terminal phase, the timer fires after 5 min, deletes the state, and the timer's own reference is removed. **However**, if a new `feedEvent` arrives AFTER the timer has fired (i.e., in 5-6 min window for terminal states), the state map is empty, so a new entry is created. This is fine.
-
-**Actual real bug**: Looking at `dispose()` — it calls `for (const timer of this.timers.values()) clearTimeout(timer)`, which is correct. So the issue is just: `states` Map can grow to N concurrent tasks. The terminal-state TTL handles cleanup. This is OK.
-
-**Conclusion**: No real bug here, but I should add a "MAX_TRACKED_STATES" cap as a defensive measure.
-
-### Issue 3: `AutoResumeController` race on rapid `scheduleResume` calls (LOW)
-**File**: `src/runtime/auto-resume.ts:51-71`
-
-`cancelResume()` clears the timer, but if `cancelResume` is called between `setTimeout` and the callback executing, the callback's `if (!this.cancelled)` check handles it. However, `cancelled` is a separate boolean from `timerId !== null`. The flow is:
-
-1. `scheduleResume` → `cancelled = false`, `timerId = setTimeout(...)`
-2. `cancelResume` → `clearTimeout(timerId)`, `cancelled = true`
-3. `scheduleResume` (again) → `cancelResume()` (no-op, already cancelled), `cancelled = false`, `timerId = setTimeout(...)`
-
-This is correct. **No real bug.**
-
-### Issue 4: `OverflowRecoveryTracker` callback exception in `feedEvent` is silent (LOW)
-**File**: `src/runtime/overflow-recovery.ts:113-117`
-
-```ts
-if (previousPhase !== phase && this.callbacks.onPhaseChange) {
-    try {
-        this.callbacks.onPhaseChange(state, previousPhase);
-    } catch (error) {
-        logInternalError("overflow-recovery.onPhaseChange", error, `taskId=${taskId}`);
-    }
-}
-```
-
-This is properly wrapped in try/catch. **No bug.**
-
-### Issue 5: `NotificationRouter.evictSeenIfNeeded` only fires on enqueue (MEDIUM)
-**File**: `src/extension/notification-router.ts:65-75`
-
-The eviction runs on every `enqueue` call. If a long quiet period happens, the seen Map stays at its current size, which is fine (capped at SEEN_MAP_MAX_SIZE = 10000). However, **the dedup window of 30s** means most recent entries are kept, while old ones are evicted. This is correct.
-
-**Real issue**: `seenCleanupCounter` is declared at line 60 but **never used**! It's dead code. Should either be wired in or removed.
-
-**File**: `src/extension/notification-router.ts:60`
-
-```ts
-private seenCleanupCounter = 0;  // ← declared, never used
-```
-
-This is dead code that should be removed for code quality.
-
-## Plan (5 phases)
-
-### Phase 1: L1 cleanup (continued)
-Replace 7 `process.stderr.write` calls with `logInternalError`:
-- `src/extension/notification-router.ts:87`
-- `src/i18n.ts:106`
-- `src/observability/metric-registry.ts:40,52,64`
-- `src/runtime/parent-guard.ts:37`
-- `src/state/jsonl-writer.ts:71`
-
-**Note**: `internal-error.ts:5` itself uses `console.error` — that's the implementation, leave it.
-
-### Phase 2: Remove dead code
-- `src/extension/notification-router.ts:60` — unused `seenCleanupCounter`
-
-### Phase 3: Defensive MAX_TRACKED_STATES cap
-- `src/runtime/overflow-recovery.ts:34` — add `MAX_TRACKED_STATES = 5000` cap to `states` Map
-
-### Phase 4: New test coverage
-- `test/unit/notification-router.test.ts` — new test file
-- `test/unit/overflow-recovery.test.ts` — new test file
-- `test/unit/auto-resume.test.ts` — new test file
-
-### Phase 5: Release v0.5.11

package/docs/archive/pi-crew-v0.5.12-audit-fix-plan.md

@@ -1,76 +0,0 @@
-# pi-crew v0.5.12 Audit Fix Plan (Round 17)
-
-## Source Verification Findings
-
-I read the following files and identified 4 confirmed real issues + test coverage gaps.
-
-### Issue 1: Signal listeners stack up on registerCleanupHandler (HIGH)
-**File**: `src/extension/crew-cleanup.ts:81-82`
-
-```ts
-process.on("SIGTERM", () => { void handleSignal("SIGTERM"); });
-process.on("SIGHUP", () => { void handleSignal("SIGHUP"); });
-```
-
-These listeners are added every time `registerCleanupHandler(pi)` is called. If the extension is reloaded (e.g., in dev mode, or via `pi install --reload`), the listeners stack up. This causes:
-- Memory leak (closures over `handleSignal`)
-- Multiple cleanup invocations on shutdown → multiple SIGTERM to children
-- Confusing logs ("Received SIGTERM - starting cleanup" repeated)
-
-**Fix**: Make the signal handlers idempotent. Use a module-level `signalHandlersRegistered` flag, or use `process.once` instead of `process.on`. Better: register only once at module load.
-
-### Issue 2: Unhandled promise rejection in signal handler (MEDIUM)
-**File**: `src/extension/crew-cleanup.ts:81-82`
-
-```ts
-process.on("SIGTERM", () => { void handleSignal("SIGTERM"); });
-```
-
-If `handleSignal` throws or rejects, the unhandled rejection is silently swallowed (because `void` discards the promise). This violates our "log all errors" pattern from v0.5.9 L1.
-
-**Fix**: Wrap with `.catch()` and `logInternalError`.
-
-### Issue 3: console.error bypasses logInternalError in 4 files (MEDIUM, L1 continued)
-**Files** (7 occurrences total):
-- `src/extension/crew-cleanup.ts:59` (cleanup error)
-- `src/extension/crew-cleanup.ts:84` (kill process error)
-- `src/extension/crew-cleanup.ts:103` (temp cleanup error)
-- `src/extension/async-notifier.ts:124` (notifier error)
-- `src/runtime/async-runner.ts:166` (spawn failed)
-- `src/runtime/hidden-handoff.ts:244` (handoff failed)
-- `src/runtime/crew-hooks.ts:167,172` (hook error)
-
-**Rationale**: v0.5.9 L1 fix (in `event-bus.ts`) and v0.5.11 round 16 cleanup moved from `console.error` to `logInternalError` to ensure errors are captured even when stderr is redirected. These 8 callsites bypass that pattern.
-
-**Note**: `internal-error.ts:5` itself uses `console.error` — that's the implementation, leave it. `background-runner.ts:146` overrides `console.error` for testing — also leave.
-
-### Issue 4: Test coverage gaps in security/runtime code (LOW)
-- `test/unit/crew-cleanup.test.ts` — does not exist
-- `test/unit/async-notifier.test.ts` — does not exist
-- `test/unit/pi-spawn.test.ts` — does not exist (security-critical!)
-- `test/unit/live-agent-manager.test.ts` — does not exist
-- `test/unit/crew-hooks.test.ts` — does not exist
-
-## Plan (5 phases)
-
-### Phase 1: Fix signal handler stacking
-- Use module-level flag to register signal handlers only once
-- Wrap with `.catch()` to log promise rejections
-
-### Phase 2: L1 cleanup in 4 files
-Replace 8 `console.error` calls with `logInternalError`:
-- crew-cleanup.ts (3 calls)
-- async-notifier.ts (1 call)
-- async-runner.ts (1 call)
-- hidden-handoff.ts (1 call)
-- crew-hooks.ts (2 calls)
-
-### Phase 3: Test coverage for security-critical modules
-- `test/unit/crew-cleanup.test.ts` — test signal handler idempotency, cleanup logic
-- `test/unit/pi-spawn.test.ts` — test `isWithinAllowedPrefixes`, `validateExplicitBin`
-
-### Phase 4: Test coverage for runtime modules
-- `test/unit/async-notifier.test.ts` — test isCurrent guard, generation check
-- `test/unit/live-agent-manager.test.ts` — test eviction logic
-
-### Phase 5: Release v0.5.12

package/docs/archive/pi-crew-v0.5.13-audit-fix-plan.md

@@ -1,75 +0,0 @@
-# pi-crew v0.5.13 Audit Fix Plan (Round 18)
-
-## Source Verification Findings
-
-I read the following files and identified 4 confirmed real issues:
-
-### Issue 1: `benchmark-runner.ts` uses `execSync` instead of `execFileSync` (HIGH security)
-**File**: `src/benchmark/benchmark-runner.ts:4,110,119,128`
-
-```ts
-import { execSync } from "child_process";
-// ...
-output = execSync(judge.command, { ... });
-```
-
-`execSync(command, ...)` invokes a shell to parse the command, even when `validateCommand` is run first. The `validateCommand` function only checks for shell metacharacters in the *arguments* (after the first space), but:
-- It does not escape/quote arguments safely
-- A bug in `validateCommand` or a clever input could bypass
-- `cwd: process.cwd()` could be inherited from a parent context
-- Best practice: use `execFileSync` with `command.split(' ')[0]` and the rest as args, so no shell is invoked
-
-**Fix**: Switch to `execFileSync` with command split into program + args. Keep `validateCommand` as defense-in-depth but no longer rely on it alone.
-
-### Issue 2: `BM25Search.df()` is O(N) per call and called inside the search loop (MEDIUM performance)
-**File**: `src/utils/bm25-search.ts:47-65, 75-104`
-
-The `df()` function is called for every query term in the search loop, and itself iterates over all documents. This means:
-- For a query with `Q` terms and `N` documents, `df()` is called `Q * N` times
-- Each `df()` call iterates over `N` documents and `field_count` fields
-- Total complexity: **O(Q² * N² * field_count)**
-
-This is quadratic when it should be linear. Document frequencies don't change between `search()` calls for the same document set, so they should be cached.
-
-**Fix**: Precompute `df` once in the constructor (or lazily on first search) and cache it as a Map<term, number>. Re-compute only when documents change.
-
-### Issue 3: `SharedScanCache.set()` LRU eviction is by insertion order, not access order (LOW)
-**File**: `src/utils/scan-cache.ts:62-69`
-
-The eviction policy evicts the *oldest inserted* entry, not the *least recently accessed*. So if a frequently-updated entry is inserted, then later entries are inserted, the frequently-updated one (which is the *same* Map key) won't be moved to the end of the insertion order — it stays at the head and is the next to be evicted.
-
-This is a minor issue because:
-- In practice, scan cache entries are short-lived (TTL=1s by default)
-- The eviction only matters when entries hit the `maxEntries` cap
-
-**Fix**: Either document the limitation or implement proper LRU. For now, document it.
-
-### Issue 4: `bm25-search.ts` has no tests (LOW coverage)
-**File**: `test/unit/bm25-search.test.ts` — does not exist
-
-BM25Search is a non-trivial search algorithm. Currently zero test coverage. Should add tests for:
-- Basic search returns relevant results
-- Field weighting affects ranking
-- minScore threshold
-- limit cap
-- Empty query returns empty results
-- df() precomputation (after Issue 2 fix)
-
-## Plan (4 phases)
-
-### Phase 1: Switch `benchmark-runner.ts` to `execFileSync`
-- Replace `execSync(judge.command, ...)` with `execFileSync(program, args, ...)`
-- Keep `validateCommand` as defense-in-depth
-- Add new tests for benchmark-runner
-
-### Phase 2: Precompute `df` in BM25Search
-- Cache `df` map per corpus
-- Invalidate when documents change (or recompute on construction)
-- Add tests to verify behavior unchanged
-
-### Phase 3: Add tests for scan-cache, benchmark, bm25-search
-- `test/unit/scan-cache.test.ts`
-- `test/unit/benchmark.test.ts`
-- `test/unit/bm25-search.test.ts`
-
-### Phase 4: Release v0.5.13

package/docs/archive/pi-crew-v0.5.14-audit-fix-plan.md

@@ -1,75 +0,0 @@
-# pi-crew v0.5.14 Audit Fix Plan (Round 19)
-
-## Source Verification Findings
-
-I read the following files and identified 5 confirmed real issues:
-
-### Issue 1: `checkpoint.ts` lacks path validation for runId/taskId (MEDIUM security)
-**File**: `src/runtime/checkpoint.ts:133-200`
-
-The `saveCheckpoint(runId, taskId, ...)`, `loadCheckpoint(runId, taskId)`, `deleteCheckpoint(runId, taskId)`, `listCheckpoints(runId)`, `hasCheckpoint(runId, taskId)` functions all build paths like:
-
-```ts
-const stateRoot = path.join(process.cwd(), ".crew/state/runs", runId);
-const checkpointPath = path.join(stateRoot, "checkpoints", `${taskId}.json`);
-```
-
-If `runId` or `taskId` contains `../`, an attacker (or a bug) could write to arbitrary paths outside `.crew/`. The other modules (e.g., `state-store.ts`) use `assertSafePathId` and `resolveContainedRelativePath` to defend against this, but `checkpoint.ts` does not.
-
-**Note**: These functions are not currently used in production code (only in tests), so the attack surface is small. But the issue should be fixed for defense-in-depth.
-
-**Fix**: Use `assertSafePathId(runId)` and `assertSafePathId(taskId)` from `utils/safe-paths.ts`.
-
-### Issue 2: `subagent-manager.ts` busy-polls blocked runs (MEDIUM performance)
-**File**: `src/runtime/subagent-manager.ts:323-356, 358-389`
-
-`pollRunToTerminal` and `scheduleBlockedTerminalPoll` use `setTimeout` to poll the run manifest every `pollIntervalMs` (default 1000ms). For long-running tasks (hours), this means thousands of `loadRunManifestById` calls.
-
-Each call does:
-- File stat
-- File read
-- JSON parse
-
-**Fix**: Use `fs.watch()` to be notified of manifest changes instead of polling. This is event-driven and only fires when the file actually changes.
-
-### Issue 3: `subagent-manager.ts:waitForRecord` busy-loops with 100ms sleep (LOW performance)
-**File**: `src/runtime/subagent-manager.ts:217-225`
-
-When `record.promise` is undefined (just created), the function busy-loops with 100ms `setTimeout`. This works but is inefficient.
-
-**Fix**: Use an event emitter or a promise that's resolved when the record transitions to terminal state.
-
-### Issue 4: `subagent-manager.ts:scheduleStuckBlockedNotify` timer holds strong ref to `record` (LOW memory)
-**File**: `src/runtime/subagent-manager.ts:393-407`
-
-The timer closure captures `record` strongly. If the agent is removed (via `removeAgent` or similar), the timer still holds a reference until it fires.
-
-**Fix**: Add `removeAgent(id)` method that clears the timer.
-
-### Issue 5: Test coverage gaps for subagent-manager, paths, checkpoint (LOW)
-- `test/unit/subagent-manager.test.ts` — does not exist
-- `test/unit/paths.test.ts` — does not exist
-- `test/unit/checkpoint.test.ts` — exists but no path-traversal tests
-
-## Plan (5 phases)
-
-### Phase 1: Path validation in checkpoint.ts
-- Use `assertSafePathId` from `utils/safe-paths.ts`
-- Update `saveCheckpoint`, `loadCheckpoint`, `deleteCheckpoint`, `listCheckpoints`, `hasCheckpoint`
-
-### Phase 2: Add tests for path validation
-- Test that `saveCheckpoint` rejects `../etc/passwd`
-- Test that `loadCheckpoint` rejects path-traversal IDs
-
-### Phase 3: Test coverage for subagent-manager
-- Test spawn, abort, waitForAll
-- Test path validation
-- Test concurrent limits
-- Test cleanup of controllers
-
-### Phase 4: Test coverage for paths
-- Test findRepoRoot with various project markers
-- Test cache TTL
-- Test projectPiRoot / projectCrewRoot
-
-### Phase 5: Release v0.5.14

package/docs/archive/pi-crew-v0.5.16-audit-fix-plan.md

@@ -1,35 +0,0 @@
-# Round 22 Audit Fix Plan (Defensive Caps)
-
-## Findings
-
-### Issue 1: `autoRecoveryLast` Map grows unboundedly (MEDIUM, MEMORY)
-- **File**: `src/extension/register.ts:484`
-- **What**: Module-level `Map<string, number>` keyed by `${kind}_${runId}`. Holds cooldown timestamps for "recovery notifications" (5-minute gate per key).
-- **Bug**: Entries are NEVER removed during a session. Each run contributes up to 4 keys (one per `maybeNotifyHealth` kind). Long-running pi sessions that run 1000+ teams accumulate 4000+ entries (~32KB).
-- **Severity**: MEDIUM — silent memory growth in long-running process. Not a security issue.
-- **Fix**: Add `AUTO_RECOVERY_LAST_MAX_ENTRIES` cap. Evict oldest insertion (matches the 5-min cooldown gate semantics — once the gate has expired, the entry is irrelevant). The eviction loop runs on each `set()` to amortize the cost.
-
-### Issue 2: `agentEventSeqCache` Map grows unboundedly (MEDIUM, MEMORY)
-- **File**: `src/runtime/crew-agent-records.ts:265`
-- **What**: Module-level `Map<string, { size, mtimeMs, seq }>` keyed by `filePath` (each agent event log). Caches the `.seq` sidecar value.
-- **Bug**: Entries are NEVER removed. Each new agent task creates a new event log file, adding a cache entry. A long-running pi-crew process that spawns 1000s of agents accumulates 1000s of entries.
-- **Severity**: MEDIUM — silent memory growth. Plus, stale entries mask filesystem changes (mtime/size won't reflect a re-created file).
-- **Fix**: Add `AGENT_EVENT_SEQ_CACHE_MAX_ENTRIES` cap. Evict oldest insertion first (mirrors the `asyncAgentReaderCache` pattern at line 134-136 in the same file).
-
-## Plan (2 phases)
-
-### Phase 1: `autoRecoveryLast` defensive cap
-- `src/extension/register.ts:484` — add `AUTO_RECOVERY_LAST_MAX_ENTRIES = 1000` constant
-- Modify the `set()` site at line 1534 to evict oldest entries before inserting when size > cap
-- Add test in `test/unit/auto-recovery-cap.test.ts`
-
-### Phase 2: `agentEventSeqCache` defensive cap
-- `src/runtime/crew-agent-records.ts:265` — add `AGENT_EVENT_SEQ_CACHE_MAX_ENTRIES = 1000` constant
-- Add helper function `setAgentEventSeqCache()` that wraps the `.set()` and evicts oldest entries
-- Add test in `test/unit/crew-agent-records.test.ts` (or new file)
-
-## Expected impact
-- 2 new tests, 0 regressions
-- Total: 2 MEDIUM memory-leak fixes
-- No public API changes
-- Pattern: follows existing `NotificationRouter.SEEN_MAP_MAX_SIZE` and `asyncAgentReaderCache` patterns in the codebase

package/docs/archive/pi-crew-v0.5.17-audit-fix-plan.md

@@ -1,80 +0,0 @@
-# Round 23 Audit Findings (Resource Cleanup)
-
-## Skill: iterative-audit (Pattern #7: Resource Cleanup)
-
-## Findings
-
-### Issue 1: OTLP exporter `inFlight` push not awaited on dispose (LOW)
-- **File**: `src/observability/exporters/otlp-exporter.ts:80-86, 127-130`
-- **What**: When `dispose()` is called, the interval timer is cleared but the in-flight `push()` continues to run until the 10s fetch timeout. The result is lost (not awaited).
-- **Severity**: LOW — bounded by 10s fetch timeout. Not a real leak, just orphaned work.
-- **Fix**: Make `dispose()` async. Await the in-flight push before returning.
-- **Test**: 1 new test verifies `dispose()` waits for the in-flight push.
-
-## Patterns surveyed (all VERIFIED clean from source)
-
-### setInterval / setTimeout cleanup
-| File | Resource | Cleanup | Status |
-|------|----------|---------|--------|
-| `register.ts:411` | `autoRepairTimer` | cleared on line 308, 402, 1102 | OK |
-| `register.ts:442` | `tempReconcileTimer` | cleared on line 308, 402, 1102 | OK |
-| `result-watcher.ts:80` | `pollTimer` | cleared in `stopPolling()` | OK |
-| `result-watcher.ts:96` | `restartTimer` | cleared in `scheduleRestart()` and `stop()` | OK |
-| `async-notifier.ts:101` | `state.interval` | cleared in `stopAsyncRunNotifier()` | OK |
-| `subagent-tools.ts:228` | `timer` | cleanup function returned to caller | OK |
-| `team-tool.ts:160` | `timer` | `stop()` method clears it | OK |
-| `live-conversation-overlay.ts:55` | `pollTimer` | cleared in `close()` / `dispose()` | OK |
-| `loaders.ts:127` | `timer` | cleared in `dispose()` | OK |
-| `theme-adapter.ts:145` | `pollTimer` | cleared in unsubscribe (line 169) | OK |
-| `delivery-coordinator.ts:169` | `ttlTimer` | cleared in `dispose()` | OK |
-| `parent-guard.ts:61` | `guardInterval` | cleared in `stopParentGuard()` | OK |
-| `scheduler.ts:88` | `t` (timer) | cleared on job removal | OK |
-| `otlp-exporter.ts:80` | `timer` | cleared in `dispose()` (Round 23: also awaits inFlight) | OK |
-| `team-runner.ts:67` | `interval` | local scope (per-run) | OK |
-| `metric-sink.ts:68` | `timer` | cleared in `dispose()` (also closes fd) | OK |
-| `handoff-manager.ts:203` | `cleanupTimer` | cleared in `dispose()` (also clears Maps) | OK |
-| `live-session-runtime.ts:487` | `controlTimer` | cleared in `finally` block | OK |
-| `budget-tracker.ts:231` | `abortInterval` | cleared on abort/exhausted | OK |
-| `background-runner.ts:52, 74` | `interval` | local scope (process entry point) | OK |
-
-### process.on() signal handler registration
-| File | Handlers | Guard | Status |
-|------|----------|-------|--------|
-| `crew-cleanup.ts:79, 84` | SIGTERM, SIGHUP | `signalHandlersRegistered` flag (Round 16) | OK |
-| `background-runner.ts:107, 148, 175, 181, 194, 198` | many | process entry point (registered once per process) | OK |
-| `event-log.ts:490-492` | exit, SIGTERM, SIGINT | module-level (ESM caches) | OK |
-| `atomic-write.ts:265-267` | exit, SIGTERM, SIGINT | module-level (ESM caches) | OK |
-
-### File watchers
-| File | Watcher | Cleanup | Status |
-|------|---------|---------|--------|
-| `register.ts:682, 686` | `crewWatcher`, `userCrewWatcher` | `closeWatcher()` in cleanup paths | OK |
-| `result-watcher.ts` | `watcher` | `closeWatcher()` in `stop()` | OK |
-
-### Event listeners
-| File | Listener | Cleanup | Status |
-|------|----------|---------|--------|
-| `event-bus.ts:on()` | deduped via Set | cleanup function returned | OK |
-| `run-event-bus.ts:onAny()` etc. | deduped via Sets | cleanup function returned | OK |
-| `phase-tracker.ts:dispose()` | EventEmitter | `removeAllListeners()` | OK |
-| `team-tool.ts:72` | signal listener | `removeEventListener` in `finally` | OK |
-
-### AbortController
-| File | Controller | Cleanup | Status |
-|------|-----------|---------|--------|
-| `team-tool.ts:68` | per-tool | aborted via signal listener, removed in `finally` | OK |
-| `subagent-manager.ts:290` | per-run | cleaned in `cleanupRunSignal()` | OK |
-| `cancellation-token.ts:17` | per-token | aborted via `#controller.abort()` | OK |
-| `otlp-exporter.ts:106` | per-push | cleared in `finally` block | OK (also: dispose awaits inFlight) |
-
-## Plan (1 phase)
-
-### Phase 1: OTLP exporter `dispose()` awaits inFlight
-- `src/observability/exporters/otlp-exporter.ts:127-130` — make `dispose()` async, await `this.inFlight`
-- 1 new test in `test/unit/otlp-exporter.test.ts`
-
-## Expected impact
-- 1 new test, 0 regressions
-- Total: 1 LOW severity improvement
-- No public API change (callers that don't await still get synchronous timer clear)
-- Pattern: matches the existing `await` patterns elsewhere in the codebase