pi-crew 0.9.51 → 0.9.53

package/docs/runtime-analysis-child-vs-live.md

@@ -1,171 +0,0 @@
-# pi-crew Runtime Analysis: child-process vs live-session
-
-> Date: 2026-05-12  
-> Status: Performance analysis — proposing a default runtime change
-
----
-
-## 1. Current problem
-
-pi-crew's default runtime is **child-process** — each worker spawns its own `pi` CLI child process. This causes:
-
-### 1.1 Memory
-
-| Scenario | child-process | live-session | Savings |
-|---|---|---|---|
-| 1 worker | ~150 MB added | ~15 MB added | **135 MB** |
-| 4 workers (parallel) | ~600 MB added | ~60 MB added | **540 MB** |
-| 8 workers (max cap) | ~1.2 GB added | ~120 MB added | **~1.1 GB** |
-
-**The parent Pi process already consumes ~308 MB.** Adding 4 child-process workers brings the total to **910 MB**, nearly 1 GB just to run a single team. A machine with 8 GB of RAM will start swapping.
-
-### 1.2 Startup latency
-
-| Stage | child-process | live-session |
-|---|---|---|
-| Process spawn | ~300ms | 0 |
-| Node.js bootstrap | ~500ms | 0 |
-| Pi CLI init + load extensions | ~1-2s | 0 |
-| pi-crew register() (runs again in child) | ~200ms | 0 |
-| createAgentSession() | ~100ms | ~100ms |
-| First LLM token | **2-4s total** | **200-500ms total** |
-
-**Each worker takes 2-4s to start.** A team implementation with 3 sequential phases × 2-4s = **6-12s just to spawn processes**, before any work even begins.
-
-### 1.3 CPU overhead
-
-- Each child process runs a separate V8 isolate → separate JIT compiler, separate GC
-- `pi-crew register()` runs **repeatedly** in each child (load config, register tools, bind extensions)
-- JSON parsing/redaction on child stdout → CPU cost per event
-
-### 1.4 Complexity
-
-- `child-pi.ts` = 461 lines just to manage the subprocess lifecycle
-- Hard kill timer (3s), post-exit stdio guard (3s), final drain (5s), response timeout (5 min)
-- Process tree kill (`taskkill /t /f` on Windows, `kill -pgid` on Unix)
-- Mock system for testing (`PI_TEAMS_MOCK_CHILD_PI`)
-
----
-
-## 2. live-session is ready
-
-pi-crew **has already implemented** a complete live-session runtime:
-
-- `src/runtime/live-session-runtime.ts` — 600 LOC, feature parity with child-process for most use cases
-- `src/runtime/runtime-resolver.ts` — `resolveCrewRuntime()` already handles auto/live-session/child-process
-- Soft turn limit + grace period (default 5) — **already present**, identical to pi-subagents3
-- Tool filtering — `filterActiveTools()` removes recursive tools
-- Yield/submit_result — custom tool + JSON event detection
-- Live agent control — steer, resume, real-time tool activity
-- Extension bridge — `buildExtensionBridge()` for extension-based APIs
-- Health diagnostics — `collectLiveSessionHealth()`, `formatLiveSessionDiagnostics()`
-
-### Current configuration must be set manually:
-
-```json
-// .pi/crew-config.json
-{
-  "runtime": {
-    "mode": "live-session"
-  }
-}
-```
-
-Or:
-```json
-{
-  "runtime": {
-    "mode": "auto",
-    "preferLiveSession": true
-  }
-}
-```
-
-**The current default is `"auto"` WITHOUT `preferLiveSession`** → it always falls back to child-process.
-
----
-
-## 3. Proposal
-
-### 3.1 Change the default: `preferLiveSession: true` when mode = "auto"
-
-Current `resolveCrewRuntime()`:
-
-```typescript
-// src/runtime/runtime-resolver.ts
-if (requestedMode === "live-session" || (requestedMode === "auto" && config.runtime?.preferLiveSession === true)) {
-    const live = await isLiveSessionRuntimeAvailable(1500, env);
-    if (live.available) return liveCaps(requestedMode);
-    // fallback to child-process
-}
-return childCaps(requestedMode);  // ← default: always child-process
-```
-
-**Proposed change:**
-
-```typescript
-if (requestedMode === "live-session" || requestedMode === "auto") {
-    const live = await isLiveSessionRuntimeAvailable(1500, env);
-    if (live.available) return liveCaps(requestedMode);
-    if (requestedMode === "live-session" && !config.runtime?.allowChildProcessFallback) 
-        return scaffoldCaps(requestedMode, live.reason, "blocked");
-    return { ...childCaps(requestedMode), fallback: "child-process", reason: live.reason };
-}
-```
-
-**In other words:** `"auto"` → try live-session first, fall back to child-process if the SDK is unavailable. Users can still force `child-process` if they want.
-
-### 3.2 Add an opt-out for risky tasks
-
-A task-level flag to force child-process for specific tasks:
-
-```json
-{
-  "runtime": {
-    "mode": "auto",
-    "preferLiveSession": true,
-    "riskyIsolation": "child-process"
-  }
-}
-```
-
-Tasks with the `executor` role, or tasks running in a worktree → automatically use child-process.
-
-### 3.3 Expected benefits
-
-| Metric | Before (child-process default) | After (live-session default) |
-|---|---|---|
-| **4-worker memory** | ~910 MB | ~370 MB |
-| **First token latency** | 2-4s/worker | 200-500ms/worker |
-| **Total startup (3 phases)** | 6-12s | 0.6-1.5s |
-| **Steering** | ❌ | ✅ |
-| **Resume** | ❌ | ✅ |
-| **Crash isolation** | ✅ | ❌ (fallback available) |
-| **Parent crash risk** | None | Low (session.abort handles most) |
-
-### 3.4 Risks and mitigations
-
-| Risk | Severity | Mitigation |
-|---|---|---|
-| Agent crash → parent crash | Medium | `try/catch` around `session.prompt()`, `AbortController` per-agent, cleanup on unhandled rejection |
-| Memory pressure (many sessions) | Low | Keep the `maxConcurrent` cap (default 4); the limit is sufficient |
-| Recursive team calls | Low | `filterActiveTools()` already removes recursive tools |
-| SDK unavailable (old Pi version) | Low | Auto-fallback to child-process |
-| Unhandled errors in session | Medium | Global `unhandledRejection` handler per-session |
-
----
-
-## 4. Conclusion
-
-**pi-crew is using an overly heavy runtime for most use cases.** child-process provides excellent crash isolation, but:
-
-- **9× the memory** compared to live-session
-- **8× the startup latency**
-- **No steer/resume** — loses interactive capability
-
-live-session **is already implemented**; only the default needs to change. The crash isolation trade-off is acceptable because:
-1. The Pi SDK `createAgentSession()` already handles most errors
-2. A child-process fallback is still available when needed
-3. The benefits (540 MB saved, 3s faster startup, steer/resume) outweigh the risks
-
-**Action:** Change the `resolveCrewRuntime()` default so `"auto"` prefers live-session, keeping child-process as a fallback.

package/docs/runtime-migration-in-process-analysis.md

@@ -1,250 +0,0 @@
-# Analysis: Migrating pi-crew fully to in-process execution
-
-> Date: 2026-05-12  
-> Question: What if we move entirely to in-process like pi-subagents3?
-
----
-
-## 1. Current state
-
-pi-crew has **3 runtime modes**, with child-process as the default:
-
-```
-scaffold      → no workers run (dry-run)
-child-process → spawn a `pi` CLI subprocess per worker (DEFAULT)
-live-session  → createAgentSession() in-process per worker
-```
-
-### Code related to child-process
-
-| File | LOC | Role |
-|---|---|---|
-| `child-pi.ts` | 461 | Subprocess lifecycle, stdout parsing, kill process tree |
-| `pi-args.ts` | 165 | Build CLI args for the child `pi` process |
-| `pi-spawn.ts` | 167 | Detect the `pi` binary path (local/global) |
-| `post-exit-stdio-guard.ts` | 86 | Drain child stdout after exit, hard kill timer |
-| `async-runner.ts` | 153 | Spawn background team runs (detached process) |
-| **Total** | **1,032** | **Code only used by child-process** |
-
-### Code related to live-session (already present)
-
-| File | LOC | Role |
-|---|---|---|
-| `live-session-runtime.ts` | 600 | In-process execution, soft turn limit, yield, custom tools |
-| `runtime-resolver.ts` | 92 | Auto-detect available runtime |
-| `task-runner/live-executor.ts` | 95 | Adapter: live-session → task-runner interface |
-
-### Files that use the child-process path
-
-- `task-runner.ts` — 8 references, ~120 lines of child-process-specific logic (heartbeat, progress, model retry)
-- `register.ts` — `terminateActiveChildPiProcesses()` cleanup
-- `doctor.ts` — diagnose child-process issues
-- `async-runner.ts` — spawn background team runs
-
-### Related tests
-
-- ~37 test files reference child-process / mock child
-- ~3 test files reference the live-session mock
-- All integration tests use `PI_TEAMS_MOCK_CHILD_PI` — **would need rewriting** if child-process is dropped
-
----
-
-## 2. If we move fully to in-process
-
-### 2.1 What we GAIN
-
-#### Immediate benefits
-
-| Metric | child-process | in-process | Improvement |
-|---|---|---|---|
-| Memory / worker | ~150 MB | ~15 MB | **10× lighter** |
-| 4 workers peak | ~600 MB added | ~60 MB added | **540 MB saved** |
-| Startup / worker | 2-4s | 200-500ms | **8× faster** |
-| Team startup (3 phases) | 6-12s overhead | ~1s overhead | **6-12× faster** |
-| Steering | ❌ | ✅ | **New feature** |
-| Resume | ❌ | ✅ | **New feature** |
-| Context inheritance | ❌ | ✅ (parentContext) | **New feature** |
-| Live tool activity | ❌ | ✅ | **New feature** |
-| Yield/submit_result | ✅ (JSON event) | ✅ (custom tool) | Parity |
-| Worktree isolation | ✅ | ✅ | Parity |
-
-#### Architectural benefits
-
-- **Delete ~1,000 LOC** of subprocess management code
-- Simplify `task-runner.ts` (remove 120 lines of child-process logic)
-- Remove `post-exit-stdio-guard.ts`, `pi-spawn.ts`, `pi-args.ts` subprocess overhead
-- Remove `responseTimeoutMs`, `hardKillMs`, `postExitStdioGuardMs` — no need to kill a process tree
-- **Zero npm dependencies for execution** (currently requires `jiti` for async-runner TypeScript loading)
-
-### 2.2 What we LOSE
-
-#### ❌ Process isolation — biggest loss
-
-```
-child-process:  worker crash → worker dies → parent continues
-in-process:     worker crash → can crash parent → entire team lost
-```
-
-The Pi SDK `createAgentSession()` handles most errors, but:
-- **Unhandled promise rejection** within a session
-- **Infinite loop** inside a custom tool
-- **OOM** — one session consuming all memory affects everything
-- **Node.js segfault** — rare, but when it happens = total death
-
-#### ❌ Async background team runs
-
-`async-runner.ts` spawns a **detached process** to run a team when the user closes the terminal. In-process cannot do this — the process dies when the terminal closes.
-
-**Solution:** Keep `async-runner.ts` specifically for background runs — it spawns the entire team runner, not individual workers.
-
-#### ❌ Simple depth guard
-
-`checkCrewDepth()` counts the `PI_CREW_PARENT_PID` env var. In-process has no process boundary → counting depth is harder. A global counter or thread-local equivalent is needed.
-
-#### ❌ 37+ test files need updating
-
-All integration tests use `PI_TEAMS_MOCK_CHILD_PI`. They would need to switch to `PI_CREW_MOCK_LIVE_SESSION` or have new mocks written.
-
-#### ❌ `_CrewRuntimeKind` type union
-
-`"scaffold" | "child-process" | "live-session"` → if child-process is dropped, only `"scaffold" | "in-process"` remains. Breaking change for config.
-
-### 2.3 Specific risks
-
-| Risk | Severity | Details |
-|---|---|---|
-| Parent crash | **Medium** | Unhandled error in agent session → parent dies. The Pi SDK wraps most of them but not 100%. |
-| Memory pressure | **Medium** | 4 in-process sessions + context windows can consume >500MB within the same heap. V8 GC pauses. |
-| Extension conflicts | **Low** | In-process extensions can conflict (global state, tool registry). Filtering exists but there are edge cases. |
-| Recursive team calls | **Low** | The `team` tool inside an agent session → infinite recursion. Already filtered but a guarantee is needed. |
-| Background runs | **Solved** | Keep `async-runner.ts` separate; it only spawns 1 detached process for the full team. |
-| Breaking config | **Low** | Users currently setting `mode: "child-process"` → need a migration path. |
-
----
-
-## 3. Two directions
-
-### Direction A: Drop child-process entirely (like pi-subagents3)
-
-```
-                 ┌─────────────────────────┐
-                 │   task-runner.ts         │
-                 │   runtime = "in-process" │
-                 ├─────────────────────────┤
-                 │ live-session-runtime.ts  │
-                 │ createAgentSession()     │
-                 │ session.prompt()         │
-                 │ session.steer()          │
-                 ├─────────────────────────┤
-                 │    Pi SDK (shared)       │
-                 └─────────────────────────┘
-```
-
-**Delete:** `child-pi.ts`, `pi-args.ts`, `pi-spawn.ts`, `post-exit-stdio-guard.ts` (~879 LOC)  
-**Keep:** `async-runner.ts` (for background team runs — spawns 1 process for the whole team, not per-worker)  
-**Change:** `task-runner.ts` → drop the child-process branch, use only live-session  
-**Change:** All 37+ test files  
-
-**Pros:** Clean architecture, simplest, lowest maintenance  
-**Cons:** Loses per-worker crash isolation; many tests need rewriting
-
-### Direction B: Live-session default + child-process opt-in (recommended)
-
-```
-                 ┌─────────────────────────────────┐
-                 │        task-runner.ts            │
-                 │   default: live-session          │
-                 │   opt-in: child-process          │
-                 │   background: async-runner       │
-                 ├──────────┬───────────────────────┤
-                 │ in-proc  │  child-process         │
-                 │ (fast)   │  (isolated, fallback)  │
-                 └──────────┴───────────────────────┘
-```
-
-**Change:** `runtime-resolver.ts` → `"auto"` prefers live-session  
-**Keep:** All child-process code (as fallback)  
-**Keep:** All tests  
-**Add:** Config `"riskyIsolation": true` so the executor role auto-uses child-process  
-
-**Pros:** Best of both worlds, zero breaking changes  
-**Cons:** Still maintaining 2 code paths
-
----
-
-## 4. Recommendation: Direction B
-
-**Do not drop child-process entirely** — too risky for production. Instead:
-
-### Step 1: Change the default runtime (fast, low risk)
-
-```typescript
-// runtime-resolver.ts
-// Before: "auto" → always child-process
-// After:  "auto" → try live-session, fall back to child-process
-
-export async function resolveCrewRuntime(config, env) {
-    const requestedMode = config.runtime?.mode ?? "auto";
-    if (requestedMode === "auto") {
-        const live = await isLiveSessionRuntimeAvailable(1500, env);
-        if (live.available) return liveCaps(requestedMode);
-        return { ...childCaps(requestedMode), fallback: "child-process", reason: live.reason };
-    }
-    // Explicit modes still work
-    if (requestedMode === "child-process") return childCaps(requestedMode);
-    if (requestedMode === "live-session") { /* ... */ }
-    // ...
-}
-```
-
-### Step 2: Add a per-role isolation policy
-
-```json
-// crew-config.json
-{
-  "runtime": {
-    "mode": "auto",
-    "isolationPolicy": {
-      "executor": "child-process",   // risky code changes → isolated
-      "test-engineer": "child-process", // test runs → isolated
-      "default": "in-process"         // everything else → fast
-    }
-  }
-}
-```
-
-### Step 3: Observability for in-process errors
-
-```typescript
-// Wrap session.prompt() with a global error handler
-process.on('unhandledRejection', (err) => {
-    logInternalError('live-session.unhandled', err);
-    // Don't crash — attempt recovery
-});
-```
-
-### Expected benefits of Direction B
-
-| | Current | After Step 1 | After Step 2 |
-|---|---|---|---|
-| **Default runtime** | child-process | live-session (auto) | live-session + per-role |
-| **Memory (4 workers)** | ~910 MB | ~370 MB | ~450 MB (mixed) |
-| **Startup** | 2-4s/worker | 200-500ms/worker | Mixed |
-| **Crash isolation** | ✅ all | ✅ fallback | ✅ risky roles |
-| **Steering** | ❌ | ✅ | ✅ |
-| **Breaking changes** | — | None | None |
-| **Code deleted** | — | 0 | 0 (keep fallback) |
-| **Tests to change** | — | 0 | 0 |
-
----
-
-## 5. Conclusion
-
-**Do not move 100% to in-process.** Reasons:
-
-1. **Crash isolation is too important** for executor/test-engineer roles — these agents run code, write files, and can infinite-loop
-2. **Background runs need a detached process** — impossible in-process
-3. **37+ test files need rewriting** — high migration cost
-4. **Breaking change** for users currently using `mode: "child-process"`
-
-**Instead: Change the default to live-session + keep child-process as a fallback/opt-in.** This is precisely the design already built into `resolveCrewRuntime()` — just flip the default in `"auto"` mode. Zero code deleted, zero breaking changes, and users choose isolation when they need it.

package/docs/skills/REFERENCE.md

@@ -1,138 +0,0 @@
-# pi-crew Skills Reference
-
-## Skill Chains
-
-### Bug Investigation
-
-```
-systematic-debugging (4 phases with refuse gate)
-    ↓
-verification-before-done (evidence before claim)
-    ↓
-post-mortem (RCA documentation)
-```
-
-### Multi-phase Work
-
-```
-orchestration (phase coordination)
-    ↓
-delegation-patterns (task splitting)
-    ↓
-verification-before-done (after each phase)
-```
-
-### Code Review (Quick)
-
-```
-scrutinize (outsider perspective + simpler alternative)
-```
-
-### Code Review (Deep)
-
-```
-scrutinize (outsider perspective)
-    ↓
-multi-perspective-review (8-pass deep review)
-    ↓
-secure-agent-orchestration-review (security focus)
-```
-
-### Multi-Round Audit (5-20 rounds)
-
-```
-iterative-audit (round planning, 7 patterns, diminishing-returns)
-    ↓
-multi-perspective-review (per round, optional)
-    ↓
-verification-before-done (per round)
-```
-
----
-
-## When to Invoke
-
-| Situation | Skill |
-|-----------|-------|
-| Bug / test failure / crash | `systematic-debugging` |
-| Before claiming done | `verification-before-done` |
-| Code review (quick) | `scrutinize` |
-| Code review (deep) | `multi-perspective-review` |
-| Multi-round audit (5-20 rounds) | `iterative-audit` |
-| Task delegation | `delegation-patterns` |
-| Complex multi-phase work | `orchestration` |
-| After bug is fixed | `post-mortem` |
-| Workspace safety | `workspace-isolation` |
-| Bash safety | `safe-bash` |
-
----
-
-## Skills Inventory
-
-### Core Discipline
-
-| Skill | Description |
-|-------|-------------|
-| `systematic-debugging` | Four-phase debugging with refuse gates, falsify-first discipline |
-| `verification-before-done` | Evidence before claims |
-| `orchestration` | Multi-phase coordination, 8 rules including "respawn not absorb" |
-
-### Documentation
-
-| Skill | Description |
-|-------|-------------|
-| `post-mortem` | Engineering RCA record |
-
-### Delegation
-
-| Skill | Description |
-|-------|-------------|
-| `delegation-patterns` | Task splitting patterns |
-| `requirements-to-task-packet` | Task packet creation |
-
-### Runtime/Safety
-
-| Skill | Description |
-|-------|-------------|
-| `workspace-isolation` | Security boundary enforcement |
-| `worktree-isolation` | Git worktree safety |
-| `safe-bash` | Bash command safety |
-| `state-mutation-locking` | State mutation protection |
-
-### Observability
-
-| Skill | Description |
-|-------|-------------|
-| `event-log-tracing` | JSONL event log analysis |
-| `runtime-state-reader` | Runtime state inspection |
-| `observability-reliability` | Reliability patterns |
-
----
-
-## Anti-patterns
-
-| Anti-pattern | Skill | Rule |
-|--------------|-------|------|
-| Proposing fix before reproducing | `systematic-debugging` | Refuse Gate |
-| Running proof before disproof | `systematic-debugging` | Phase 3 |
-| Claiming "tests pass" without fresh run | `verification-before-done` | Gate Function |
-| Reviewing diff-local without tracing path | `scrutinize` | Trace step |
-| Skipping simpler-alternative pass | `multi-perspective-review` | Pre-review |
-| Editing files yourself as orchestrator | `orchestration` | Rule 1 |
-| Dispatching serially when parallel possible | `orchestration` | Rule 3 |
-| Committing a red tree | `orchestration` | Rule 6 |
-| Absorbing subagent's broken work | `orchestration` | Rule 7 |
-| Rubber-stamp review | `multi-perspective-review` | Rules |
-
----
-
-## Key Enforcement Patterns (from 9arm)
-
-| Pattern | Implemented In |
-|---------|---------------|
-| **Refuse Gate** | `systematic-debugging` |
-| **Recite Ritual** | `systematic-debugging` (Invocation) |
-| **Falsify Before Proof** | `systematic-debugging` (Phase 3) |
-| **Simpler Alternative Pass** | `scrutinize`, `multi-perspective-review` |
-| **Required Inputs Gate** | `post-mortem` |
-| **Respawn Not Absorb** | `orchestration` (Rule 7) |

package/docs/stories/README.md

@@ -1,32 +0,0 @@
-# Stories
-
-Story-sized work packets for pi-crew development.
-
-## Status Values
-
-| Status | Meaning |
-|--------|---------|
-| planned | Accepted, not started |
-| in_progress | Actively being worked |
-| completed | Done with evidence |
-| blocked | Waiting on external input |
-
-## Active Stories
-
-| ID | Title | Lane | Status |
-|----|-------|------|--------|
-| US-DEPS-major-upgrade | Nâng cấp deps major (diff 5→9, TypeScript 7) | normal | planned |
-
-## Completed Stories (from review rounds)
-
-| ID | Title | Lane | Result |
-|----|-------|------|--------|
-| RR-001 | Depth guard for nested live-session | normal | commit 2640d5e |
-| RR-002 | Windows EBUSY retry | normal | commit ceb8c60 |
-| RR-003 | Harden live-session resource management | normal | commit c7bd455 |
-| RR-004 | Stale task/agent repair | normal | commit d6d466d |
-| RR-005 | Async runner child-process enforcement | high-risk | commit 2486051 |
-| RR-006 | Live-session resource leak fix | normal | commit 7a25644 |
-| RR-007 | Double cleanupTempDir guard | tiny | commit 5f47e92 |
-| RR-008 | Review round 8 (8 issues) | normal | commit 4e75ba8 |
-| RR-009 | Review round 9 (5 issues) | normal | commit f3d29cc |

package/docs/stories/US-DEPS-major-upgrade.md

@@ -1,62 +0,0 @@
-# US-DEPS-major-upgrade — Nâng cấp dependencies major
-
-- **Lane:** normal (Dependency) — có thể tách thành 2 patch độc lập
-- **Status:** planned
-- **Nguồn:** `docs/REVIEW-FINDINGS-2026-07.md` (F6)
-- **Ngày tạo:** 2026-07-09
-
-## Overview
-
-`npm outdated` (Node v22.14.0, v0.9.28) cho thấy 2 gói lệch **major**:
-
-| Gói | Current | Latest | Rủi ro |
-|-----|---------|--------|--------|
-| `diff` | 5.2.2 | 9.0.0 | API/ESM breaking |
-| `typescript` | 5.9.3 | 7.0.2 | compiler mới (native) |
-
-Cả hai KHÔNG gộp chung; mỗi cái là một patch riêng có validation độc lập.
-
-## Phần A — `diff` 5 → 9
-
-### Design
-- `diff` v6+ chuyển sang ESM-first và tinh chỉnh chữ ký hàm (`structuredPatch`, `diffLines`, `applyPatch`...). Cần rà soát mọi import.
-- Điểm chạm chính: `src/utils/conflict-detect.ts` (và bất kỳ nơi nào import `diff`).
-
-### Exec plan
-1. `git grep -n "from \"diff\"" src test` để liệt kê toàn bộ callsite.
-2. Đọc CHANGELOG của `diff` v6/v7/v8/v9, lập bảng breaking → mapping.
-3. `npm i diff@9`, sửa callsite theo API mới.
-4. Chạy `npm run typecheck` + test liên quan (`conflict-detect.test.ts`, `delta-conflict.test.ts`).
-
-### Validation
-- `npm run typecheck` → PASS
-- `node scripts/test-runner.mjs ... test/unit/conflict-detect.test.ts test/unit/delta-conflict.test.ts` → pass
-- `npm run test:unit` full → không hồi quy
-
-## Phần B — `typescript` 5.9 → 7.0
-
-### Design
-- TS 7.0 là compiler native (tsgo). Cần đánh giá:
-  - Tương thích flags trong `tsconfig.json` (`allowImportingTsExtensions`, `NodeNext`, `strict`).
-  - Tương thích với `tsx`/strip-types runtime path (index.ts import qua `--experimental-strip-types`).
-  - Khả năng phát sinh lỗi type mới do compiler chặt hơn.
-- Rủi ro cao hơn A; cân nhắc chờ hệ sinh thái ổn định (còn sớm giữa 2026).
-
-### Exec plan
-1. Thử trên nhánh riêng: `npm i -D typescript@7`.
-2. `npm run typecheck` — thu thập toàn bộ lỗi mới, phân loại.
-3. Nếu lỗi ít/định vị được → sửa; nếu diện rộng → hoãn, ghi decision.
-4. Xác nhận `tsx` + strip-types vẫn chạy (`node --experimental-strip-types -e "await import('./index.ts')"`).
-
-### Validation
-- `npm run typecheck` → PASS
-- `npm run test:unit` → không hồi quy
-- Cold-start bench (`npm run bench`) → không xấu đi
-
-## Rollback
-- Mỗi phần là 1 commit độc lập; revert commit tương ứng nếu hồi quy.
-- Giữ `package-lock.json` cũ để pin lại nhanh.
-
-## Ghi chú quyết định
-- Ưu tiên Phần A trước (rủi ro thấp hơn, phạm vi hẹp).
-- Phần B nên có `docs/decisions/` entry trước khi merge (thay đổi toolchain cốt lõi).

package/docs/stories/backlog.md

@@ -1,36 +0,0 @@
-# Story Backlog
-
-Candidate stories for future pi-crew development.
-
-## Epic: Reliability
-
-| ID | Title | Lane | Priority | Status |
-|----|-------|------|----------|--------|
-| US-001 | Lock-free event log rotation | normal | P2 | planned |
-| US-002 | Structured run-level lock cleanup | normal | P2 | planned |
-| US-003 | Dead letter queue for permanently failed tasks | normal | P3 | planned |
-
-## Epic: Performance
-
-| ID | Title | Lane | Priority | Status |
-|----|-------|------|----------|--------|
-| US-010 | Replace sleepSync busy-wait with proper async | normal | P3 | planned |
-| US-011 | Stream-based event log for large runs | normal | P3 | planned |
-| US-012 | Cache available models across runs | tiny | P3 | planned |
-
-## Epic: DX (Developer Experience)
-
-| ID | Title | Lane | Priority | Status |
-|----|-------|------|----------|--------|
-| US-020 | Interactive run dashboard in TUI | normal | P2 | planned |
-| US-021 | Run comparison (before/after) | normal | P3 | planned |
-| US-022 | Export run report as markdown | tiny | P3 | planned |
-
-## Epic: Integration
-
-| ID | Title | Lane | Priority | Status |
-|----|-------|------|----------|--------|
-| US-030 | Webhook notifications on run completion | normal | P3 | planned |
-| US-031 | GitHub Actions integration (report results as PR comment) | normal | P3 | planned |
-
-Create story packets from `docs/templates/story.md` when work is selected.