@selesai/code 0.13.11 → 0.13.13

package/dist/extensions/pi-hermes-memory/docs/0.4/PLAN.md

@@ -1,160 +0,0 @@
-# v0.4 Plan: SQLite FTS5 Session Search + Hybrid Memory
-
-## Problem
-
-The current memory architecture has two scaling bottlenecks:
-
-1. **Memory capacity**: MEMORY.md is capped at 2,200 chars. Power users accumulate knowledge faster than consolidation can manage. Important facts get pruned.
-2. **No session history search**: Past conversations are stored as JSONL files in `~/.selesai/agent/sessions/<project>/`, but there's no way to search them. When the agent needs context from a previous session, it's gone forever.
-
-## Solution: Hybrid Memory Architecture
-
-### Core memory (always injected, unchanged)
-- `MEMORY.md` — 5,000 chars (up from 2,200)
-- `USER.md` — 5,000 chars (up from 1,375)
-- Still injected into every session via `<memory-context>` tags
-- Still human-readable, still editable
-
-### Extended memory (SQLite, searchable on demand)
-- `~/.selesai/agent/memory/sessions.db`
-- `memories` table — unlimited entries, searchable via FTS5
-- Agent uses `memory_search` tool to query when it needs context
-- Not automatically injected — agent must explicitly search
-
-### Session history (SQLite, searchable on demand)
-- Same `sessions.db` file
-- `sessions` + `messages` tables — all past conversations indexed
-- `session_fts` FTS5 index — full-text search across all sessions
-- Agent uses `session_search` tool to find relevant past context
-
-## Architecture
-
-```
-Session starts
-    ↓
-┌─────────────────────────────────────────────────┐
-│ System Prompt (always injected)                 │
-│ ┌─────────────────────────────────────────────┐ │
-│ │ <memory-context>                            │ │
-│ │ MEMORY (your personal notes) [5,000 chars]  │ │
-│ │ ═══ END MEMORY ═══                         │ │
-│ │ </memory-context>                           │ │
-│ │ <memory-context>                            │ │
-│ │ USER PROFILE [5,000 chars]                  │ │
-│ │ ═══ END MEMORY ═══                         │ │
-│ │ </memory-context>                           │ │
-│ │ <memory-context>                            │ │
-│ │ PROJECT MEMORY [5,000 chars]                │ │
-│ │ ═══ END MEMORY ═══                         │ │
-│ │ </memory-context>                           │ │
-│ └─────────────────────────────────────────────┘ │
-└─────────────────────────────────────────────────┘
-
-Agent has access to tools:
-    memory_search("prisma migration")
-        → Searches memories table (global + project)
-        → Returns top-10 relevant entries
-
-    session_search("how we fixed the test hang")
-        → Searches session history via FTS5
-        → Returns relevant conversation snippets
-```
-
-## Data Model
-
-```sql
--- Session metadata
-CREATE TABLE sessions (
-  id TEXT PRIMARY KEY,           -- UUID from JSONL
-  project TEXT NOT NULL,         -- decoded cwd path
-  started_at TEXT NOT NULL,      -- ISO timestamp
-  ended_at TEXT,                 -- ISO timestamp (null if still running)
-  message_count INTEGER DEFAULT 0
-);
-
--- All messages from all sessions
-CREATE TABLE messages (
-  id TEXT PRIMARY KEY,           -- message ID from JSONL
-  session_id TEXT NOT NULL REFERENCES sessions(id),
-  role TEXT NOT NULL,            -- 'user', 'assistant', 'system'
-  content TEXT NOT NULL,         -- extracted text content
-  timestamp TEXT NOT NULL,       -- ISO timestamp
-  tool_calls TEXT                -- JSON array of tool call names (for assistant messages)
-);
-
--- FTS5 index for full-text search across messages
-CREATE VIRTUAL TABLE message_fts USING fts5(
-  content,
-  content='messages',
-  content_rowid='rowid'
-);
-
--- Extended memory entries (beyond MEMORY.md limit)
-CREATE TABLE memories (
-  id INTEGER PRIMARY KEY AUTOINCREMENT,
-  project TEXT,                  -- NULL for global, project name for project-specific
-  target TEXT NOT NULL,          -- 'memory' or 'user'
-  content TEXT NOT NULL,
-  created DATE NOT NULL,
-  last_referenced DATE NOT NULL
-);
-
--- FTS5 index for memory search
-CREATE VIRTUAL TABLE memory_fts USING fts5(
-  content,
-  content='memories',
-  content_rowid='id'
-);
-```
-
-## Key Design Decisions
-
-### 1. Session indexing is lazy (on session end)
-- Don't parse JSONL files on every startup
-- Index a session when `session_shutdown` fires
-- Bulk import existing sessions via `/memory-index-sessions` command
-
-### 2. FTS5 for both memories and sessions
-- Keyword search is sufficient for v0.4
-- Embeddings deferred to v0.5+ if search quality isn't enough
-- `better-sqlite3` includes FTS5 by default
-
-### 3. Single DB file
-- `~/.selesai/agent/memory/sessions.db` stores everything
-- Memories + sessions + FTS indices in one file
-- Simple backup (copy one file), simple cleanup
-
-### 4. Agent-driven search
-- `memory_search` and `session_search` are LLM tools
-- Agent decides when to search (not automatic)
-- Avoids injecting irrelevant context into every session
-
-### 5. Char limit increase to 5,000
-- MEMORY.md: 2,200 → 5,000 chars
-- USER.md: 1,375 → 5,000 chars
-- Project MEMORY.md: 2,200 → 5,000 chars
-- More room for core memories before consolidation kicks in
-
-## Dependencies
-
-| Package | Purpose | Size |
-|---|---|---|
-| `better-sqlite3` | SQLite with FTS5 | ~1MB native addon |
-
-## Risks
-
-| Risk | Mitigation |
-|---|---|
-| `better-sqlite3` is a native C++ addon | Standard for dev tools; CI has build tools |
-| FTS5 search quality | Start with keyword search, add embeddings later if needed |
-| Session JSONL format changes | Parse defensively, skip unknown message types |
-| Large session history (1000+ sessions) | FTS5 handles this well; add pagination to results |
-| DB corruption | Atomic writes, WAL mode, backup before migrations |
-
-## Success Criteria
-
-1. `session_search("prisma migration")` returns relevant conversation snippets from past sessions
-2. `memory_search("auth setup")` returns relevant entries from extended memory store
-3. MEMORY.md limit raised to 5,000 chars without breaking existing functionality
-4. Existing session files indexed without data loss
-5. All tests pass, zero regressions

package/dist/extensions/pi-hermes-memory/docs/0.4/TASKS.md

@@ -1,113 +0,0 @@
-# v0.4 Tasks: SQLite FTS5 Session Search + Hybrid Memory
-
-## Status Legend
-- `[ ]` Not started
-- `[~]` In progress
-- `[x]` Done
-
----
-
-## Epic 1: SQLite Foundation ✅
-
-### Task 1.1: Install better-sqlite3 and create DB module
-- [x] Install `better-sqlite3` + `@types/better-sqlite3`
-- [x] Create `src/store/db.ts` — DatabaseManager class
-- [x] Create `tests/store/db.test.ts` — 14 tests passing
-
-### Task 1.2: Create schema and migrations
-- [x] Define schema in `src/store/schema.ts`
-- [x] Add triggers to keep FTS index in sync
-- [x] Test: schema creates cleanly on fresh DB, idempotent on existing DB
-
----
-
-## Epic 2: Session History Indexing ✅
-
-### Task 2.1: JSONL parser
-- [x] Create `src/store/session-parser.ts`
-- [x] Create `tests/store/session-parser.test.ts` — 14 tests passing
-
-### Task 2.2: Session indexer
-- [x] Create `src/store/session-indexer.ts`
-- [x] Create `tests/store/session-indexer.test.ts` — 12 tests passing
-
-### Task 2.3: /memory-index-sessions command
-- [x] Create `src/handlers/index-sessions.ts`
-- [x] Wire into `src/index.ts`
-
----
-
-## Epic 3: Session Search ✅
-
-### Task 3.1: Session search store
-- [x] Create `src/store/session-search.ts` — FTS5 search
-- [x] Create `tests/store/session-search.test.ts` — 11 tests passing
-
-### Task 3.2: session_search tool
-- [x] Create `src/tools/session-search-tool.ts`
-- [x] Register in `src/index.ts`
-
----
-
-## Epic 4: Extended Memory Store ✅
-
-### Task 4.1: SQLite memory store
-- [x] Create `src/store/sqlite-memory-store.ts`
-- [x] Create `tests/store/sqlite-memory-store.test.ts` — 19 tests passing
-
-### Task 4.2: memory_search tool
-- [x] Create `src/tools/memory-search-tool.ts`
-- [x] Register in `src/index.ts`
-
----
-
-## Epic 5: Char Limit Increase ✅
-
-### Task 5.1: Update defaults
-- [x] Update `src/constants.ts` — 5000 defaults
-- [x] Update `src/types.ts` — updated comments
-- [x] Update README configuration table
-
-### Task 5.2: Update tests
-- [x] Updated all tests that depend on char limits
-- [x] Verified consolidation still works at new limits
-
----
-
-## Epic 6: Integration & Polish ✅
-
-### Task 6.1: Wire everything into index.ts
-- [x] Initialize DatabaseManager on extension load
-- [x] Register `session_search` and `memory_search` tools
-- [x] Register `/memory-index-sessions` command
-- [x] Auto-index session on `session_shutdown` event
-
-### Task 6.2: Add session indexing to background review
-- [x] Auto-index on session_shutdown (indexes most recent session)
-
-### Task 6.3: Update README
-- [x] Added session history search and extended memory sections
-- [x] Updated char limits: 2200/1375 → 5000
-- [x] Updated configuration table and JSON example
-- [x] Updated Where Data Lives with sessions.db
-- [x] Updated Known Limitations
-
-### Task 6.4: Version bump & release
-- [x] Bump version to `0.4.0`
-- [x] Run full test suite — 272 tests passing
-- [x] Publish to npm
-- [x] Create GitHub release
-
----
-
-## Summary
-
-| Epic | Files Created | Tests |
-|---|---|---|
-| 1. SQLite Foundation | db.ts, schema.ts | 14 |
-| 2. Session Indexing | session-parser.ts, session-indexer.ts, index-sessions.ts | 26 |
-| 3. Session Search | session-search.ts, session-search-tool.ts | 11 |
-| 4. Extended Memory | sqlite-memory-store.ts, memory-search-tool.ts | 19 |
-| 5. Char Limits | constants.ts, types.ts | — |
-| 6. Integration | index.ts, README.md, learn-memory-tool skill | — |
-| **Total** | **12 new files** | **272 tests** |

package/dist/extensions/pi-hermes-memory/docs/0.6/CHANGELOG.md

@@ -1,57 +0,0 @@
-# v0.6.6 Changelog
-
-## Bug Fixes
-
-### Fix legacy SQLite upgrade error: `no such column: category`
-
-Some users upgrading from older versions had an existing `sessions.db` with a legacy
-`memories` table that did not include v0.6 failure-memory columns. During schema init,
-creating `idx_memories_category` failed and `/memory-index-sessions` crashed with:
-
-`❌ Session indexing failed: no such column: category`
-
-Fix:
-
-- Added automatic legacy schema migration in `DatabaseManager`
-- Detects missing `memories` columns and adds them idempotently:
-  - `category`
-  - `failure_reason`
-  - `tool_state`
-  - `corrected_to`
-- Retries schema initialization after migration
-- Added regression test: `should migrate legacy memories table without category column`
-
----
-
-# v0.6.5 Changelog
-
-## Bug Fixes
-
-### Auto-review no longer blocks interactive chat (#10)
-
-The background auto-review was `await`ing `pi.exec()` inside the `turn_end` handler, which
-blocked the chat from responding while the review subprocess ran. Fixed by making the
-review subprocess fire-and-forget — the turn_end handler returns immediately, and the
-subprocess completes asynchronously.
-
-- `pi.exec()` is no longer awaited — handler returns immediately
-- `reviewInProgress` guard resets in `.then()` / `.catch()` callbacks
-- Overlapping reviews are still prevented by the guard
-- Notifications are delivered via `.then()` callback once the subprocess completes
-
-### Auto-review failures on Windows no longer show errors (#9)
-
-On Windows git-bash, `pi exec` subprocesses could exit with code 1 producing
-`[hermes] auto-review failed (exit=1): unknown error` messages every few turns. Fixed by
-making auto-review truly best-effort — non-zero exit codes and spawn errors are silently
-ignored.
-
-- Suppressed error notifications for non-zero exit codes
-- Suppressed error notifications for subprocess failures (timeout, signal, spawn)
-- The next review cycle will retry automatically
-
-### Crash safety
-
-- Snapshot-building code (`getBranch()`, message parsing) is wrapped in a minimal try/catch
-  to handle expired sessions gracefully
-- Early return resets `reviewInProgress` guard to unblock future reviews

package/dist/extensions/pi-hermes-memory/docs/0.6/PLAN.md

@@ -1,202 +0,0 @@
-# v0.5 Plan: Failure Memory + Categories + Provenance
-
-## Overview
-
-Track **failures, corrections, and insights** as first-class memories with full provenance and category labels. Learn from failures like humans do.
-
-## Motivation
-
-From X/Twitter feedback:
-> "Memory gets much more useful when it stores failures, not just conversations. I'd want every recalled session to carry provenance: source, timestamp, tool state, and whether the old answer survived contact with reality."
-
-## Key Features
-
-### 1. Memory Categories
-
-Add category labels to differentiate memory types:
-
-| Category | What It Is | Example |
-|---|---|---|
-| `failure` | What didn't work | "Tried localStorage for tokens — XSS risk" |
-| `correction` | User corrected the agent | "Use pnpm, not npm" |
-| `insight` | Learning from experience | "Auth0 SDK handles refresh tokens automatically" |
-| `preference` | User preference | "Prefers dark theme" |
-| `convention` | Project convention | "Monorepo uses turborepo" |
-| `tool-quirk` | Tool-specific knowledge | "CI needs --frozen-lockfile" |
-
-### 2. Failure Memory Structure
-
-```typescript
-interface FailureMemory {
-  category: 'failure' | 'correction' | 'insight' | 'preference' | 'convention' | 'tool-quirk';
-  content: string;           // What was tried / what happened
-  failure_reason?: string;   // Why it failed (for failures)
-  tool_state?: string;       // Relevant tool state (error message, output)
-  corrected_to?: string;     // What worked instead (if known)
-  project: string;           // Which project
-  session_id?: string;       // Which session
-  timestamp: string;         // When it happened
-}
-```
-
-### 3. Auto-Detect Failures
-
-Detect failures from:
-- **Explicit corrections**: "that didn't work", "use X instead", "no, do it this way"
-- **Error messages**: stderr output, test failures, build errors
-- **Agent retries**: When the agent tries multiple approaches
-- **User feedback**: "this is wrong", "that's not right"
-
-### 4. Failure Injection into System Prompt
-
-Inject relevant recent failures into the system prompt at session start:
-
-```
-<memory-context>
-RECENT FAILURES & LESSONS (learn from these):
-• [failure] Tried: localStorage for JWT tokens — Failed: XSS vulnerability
-  → Corrected to: httpOnly cookies with SameSite=Strict
-• [correction] Use pnpm, not npm (corrected 2 days ago)
-• [insight] Auth0 SDK handles refresh tokens automatically — no manual implementation needed
-═══ END MEMORY ═══
-</memory-context>
-```
-
-**Injection rules:**
-- Only inject failures from last 7 days
-- Only inject failures relevant to current project (or global)
-- Max 5 failure entries to avoid prompt bloat
-- Separate `<memory-context>` block from regular memory
-
-### 5. Search with Categories
-
-Update `memory_search` tool to support category filtering:
-
-```
-memory_search("auth", category: "failure")   → Past auth failures
-memory_search("deploy", category: "convention") → Deploy conventions
-memory_search("typescript", category: "tool-quirk") → TS tool quirks
-```
-
-### 6. Store Failures in SQLite
-
-Failures stored in `memories` table with `target: 'failure'`:
-
-```sql
--- New target type
-target TEXT CHECK (target IN ('memory', 'user', 'failure'))
-
--- Content stored as JSON with category
-{
-  "category": "failure",
-  "content": "Tried localStorage for JWT tokens",
-  "failure_reason": "XSS vulnerability - tokens accessible via JS",
-  "tool_state": "Error: Token exposed in browser console",
-  "corrected_to": "httpOnly cookies with SameSite=Strict",
-  "project": "my-app",
-  "timestamp": "2026-05-03T10:30:00Z"
-}
-```
-
-### 7. Update Background Review Prompt
-
-Enhance the background review prompt to extract failures:
-
-```
-Review this conversation and extract:
-
-1. FAILURES: What was tried but didn't work?
-   - What was attempted
-   - Why it failed
-   - What error occurred
-   - What worked instead (if found)
-
-2. CORRECTIONS: Did the user correct the agent?
-   - What was wrong
-   - What is correct
-
-3. INSIGHTS: What was learned?
-   - New knowledge about tools, APIs, patterns
-   - Project-specific learnings
-
-4. CONVENTIONS: Any project conventions discovered?
-   - Coding style, naming, patterns
-   - Tool preferences
-```
-
-## Architecture Changes
-
-### Memory Store (`src/store/memory-store.ts`)
-
-```typescript
-// Add to MemoryStore class
-addFailure(content: string, options: {
-  category: MemoryCategory;
-  failureReason?: string;
-  toolState?: string;
-  correctedTo?: string;
-}): void;
-
-getFailureEntries(): string[];  // Returns recent failures for injection
-```
-
-### SQLite Memory Store (`src/store/sqlite-memory-store.ts`)
-
-```typescript
-// Update searchMemories to support category filter
-searchMemories(db, query, { project, target, category, limit })
-```
-
-### Memory Search Tool (`src/tools/memory-search-tool.ts`)
-
-```typescript
-// Add category parameter
-category: Type.Optional(StringEnum([
-  'failure', 'correction', 'insight', 'preference', 'convention', 'tool-quirk'
-] as const, { description: 'Filter by memory category.' }))
-```
-
-### Background Review (`src/handlers/background-review.ts`)
-
-- Extract failures during review
-- Store with category labels
-- Include failure context in review prompt
-
-### Correction Detector (`src/handlers/correction-detector.ts`)
-
-- Extract failure context when correction detected
-- Store what was wrong + what is correct
-
-### System Prompt Injection (`src/index.ts`)
-
-- Add separate `<memory-context>` block for failures
-- Inject only recent (7 days) and relevant (project match)
-- Max 5 entries
-
-## Files to Change
-
-| File | Change |
-|---|---|
-| `src/types.ts` | Add `MemoryCategory` type |
-| `src/constants.ts` | Update review prompt for failure extraction |
-| `src/store/memory-store.ts` | Add `addFailure()`, `getFailureEntries()` |
-| `src/store/sqlite-memory-store.ts` | Add category support to search |
-| `src/tools/memory-search-tool.ts` | Add category parameter |
-| `src/handlers/background-review.ts` | Extract failures during review |
-| `src/handlers/correction-detector.ts` | Store failure context on corrections |
-| `src/index.ts` | Inject failure memories into system prompt |
-| `tests/store/memory-store.test.ts` | Test failure storage |
-| `tests/store/sqlite-memory-store.test.ts` | Test category search |
-| `tests/tools/memory-search-tool.test.ts` | Test category parameter |
-
-## Complexity Assessment
-
-- **Effort**: Medium (2-3 hours)
-- **Risk**: Low (additive, no breaking changes)
-- **Tests**: ~15 new tests
-
-## Migration
-
-- Existing memories get `category: null` (no migration needed)
-- New memories get category assigned
-- Search works with or without category filter

package/dist/extensions/pi-hermes-memory/docs/0.6/TASKS.md

@@ -1,144 +0,0 @@
-# v0.5 Tasks: Failure Memory + Categories + Provenance
-
-## Status Legend
-- `[ ]` Not started
-- `[~]` In progress
-- `[x]` Done
-
----
-
-## Epic 1: Category Types & Schema
-
-### Task 1.1: Add MemoryCategory type
-- [ ] Add `MemoryCategory` type to `src/types.ts`
-- [ ] Categories: `failure`, `correction`, `insight`, `preference`, `convention`, `tool-quirk`
-
-### Task 1.2: Update SQLite schema
-- [ ] Update `src/store/schema.ts` — add `category` column to memories table
-- [ ] Add index on category for faster filtering
-
----
-
-## Epic 2: Failure Memory Store
-
-### Task 2.1: Update MemoryStore
-- [ ] Add `addFailure()` method to `src/store/memory-store.ts`
-- [ ] Store failures in MEMORY.md with category metadata
-- [ ] Add `getFailureEntries()` to retrieve recent failures (last 7 days)
-- [ ] Update `formatForSystemPrompt()` to include failure section
-
-### Task 2.2: Update SQLite Memory Store
-- [ ] Add category support to `src/store/sqlite-memory-store.ts`
-- [ ] Update `addMemory()` to accept category
-- [ ] Update `searchMemories()` to filter by category
-- [ ] Add `getRecentFailures()` method
-
-### Task 2.3: Tests
-- [ ] Test `addFailure()` in `tests/store/memory-store.test.ts`
-- [ ] Test category filtering in `tests/store/sqlite-memory-store.test.ts`
-- [ ] Test `getRecentFailures()` returns only last 7 days
-
----
-
-## Epic 3: Failure Detection
-
-### Task 3.1: Update Correction Detector
-- [ ] Update `src/handlers/correction-detector.ts`
-- [ ] Extract failure context when correction detected
-- [ ] Store: what was wrong, what is correct, category
-
-### Task 3.2: Update Background Review Prompt
-- [ ] Update `src/constants.ts` — enhance `CONSOLIDATION_PROMPT`
-- [ ] Add failure extraction instructions
-- [ ] Prompt to categorize findings (failure, correction, insight, etc.)
-
-### Task 3.3: Auto-Detect Failures in Conversation
-- [ ] Add failure pattern detection in `src/handlers/background-review.ts`
-- [ ] Detect: "that didn't work", "use X instead", error messages
-- [ ] Store failures with `tool_state` (error output)
-
-### Task 3.4: Tests
-- [ ] Test failure detection in `tests/handlers/correction-detector.test.ts`
-- [ ] Test failure extraction in `tests/handlers/background-review.test.ts`
-
----
-
-## Epic 4: Failure Injection
-
-### Task 4.1: Update System Prompt Injection
-- [ ] Update `src/index.ts` — add failure memory block
-- [ ] Separate `<memory-context>` block for failures
-- [ ] Only inject recent (7 days) and relevant (project match)
-- [ ] Max 5 failure entries
-
-### Task 4.2: Failure Injection Format
-- [ ] Format:
-  ```
-  RECENT FAILURES & LESSONS (learn from these):
-  • [failure] Tried: X — Failed: Y → Corrected to: Z
-  • [correction] Use X, not Y (corrected N days ago)
-  • [insight] Learned: X
-  ```
-
-### Task 4.3: Tests
-- [ ] Test failure injection in `tests/handlers/system-prompt.test.ts`
-- [ ] Test: only recent failures injected
-- [ ] Test: max 5 entries enforced
-
----
-
-## Epic 5: Search with Categories
-
-### Task 5.1: Update Memory Search Tool
-- [ ] Update `src/tools/memory-search-tool.ts`
-- [ ] Add `category` parameter using `StringEnum`
-- [ ] Categories: `failure`, `correction`, `insight`, `preference`, `convention`, `tool-quirk`
-
-### Task 5.2: Update Search Implementation
-- [ ] Update `src/store/sqlite-memory-store.ts` — `searchMemories()`
-- [ ] Filter by category when provided
-- [ ] Include category in search results
-
-### Task 5.3: Tests
-- [ ] Test category search in `tests/store/sqlite-memory-store.test.ts`
-- [ ] Test: `memory_search("auth", category: "failure")` returns failures only
-
----
-
-## Epic 6: Integration & Polish
-
-### Task 6.1: Wire Everything Together
-- [ ] Update `src/index.ts` — ensure all components work together
-- [ ] Test end-to-end flow: detect → store → inject → search
-
-### Task 6.2: Update README
-- [ ] Add "Learning from Failures" section
-- [ ] Document categories and how they work
-- [ ] Add examples of failure memory
-
-### Task 6.3: Version Bump
-- [ ] Bump to `0.5.5`
-- [ ] Run full test suite
-- [ ] Publish to npm
-
----
-
-## Summary
-
-| Epic | Files Changed | Tests |
-|---|---|---|
-| 1. Category Types | types.ts, schema.ts | 2 |
-| 2. Failure Store | memory-store.ts, sqlite-memory-store.ts | 6 |
-| 3. Failure Detection | correction-detector.ts, background-review.ts, constants.ts | 4 |
-| 4. Failure Injection | index.ts | 3 |
-| 5. Category Search | memory-search-tool.ts, sqlite-memory-store.ts | 3 |
-| 6. Integration | index.ts, README.md | — |
-| **Total** | **8 files** | **~18 tests** |
-
-## Implementation Order
-
-```
-Epic 1 (Types) → Epic 2 (Store) → Epic 3 (Detection) → Epic 4 (Injection) → Epic 5 (Search) → Epic 6 (Polish)
-```
-
-Each epic builds on the previous one. Epics 3-5 can be done in parallel after Epic 2.