@selesai/code 0.12.0 → 0.13.1

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

@@ -0,0 +1,160 @@
+# 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

@@ -0,0 +1,113 @@
+# 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

@@ -0,0 +1,57 @@
+# 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

@@ -0,0 +1,202 @@
+# 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

@@ -0,0 +1,144 @@
+# 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.