diff --git a/ACTION-PLAN.md b/ACTION-PLAN.md
deleted file mode 100644
index cbd03e72..00000000
--- a/ACTION-PLAN.md
+++ /dev/null
@@ -1,167 +0,0 @@
-# Action Plan: Issues & PRs Cleanup
-Generated: 2025-12-12
-
-## Phase 1: Immediate Cleanup (Today)
-
-### Close Obsolete PRs
-
-- [ ] **#255** - Close PR "Fix PM2 worker MODULE_NOT_FOUND"
-  - Reason: v7.1.0 removed PM2 entirely, this fix is no longer relevant
-  - Comment: Explain that v7.1.0 migration to Bun eliminated PM2 dependency
-
-- [ ] **#206** - Close or request update on "Harden worker startup"
-  - Reason: Contains PM2-specific code that no longer exists
-  - Comment: Ask author if they want to update for Bun architecture, otherwise close as obsolete
-
-### Close/Update Fixed Issues
-
-- [ ] **#213** - Comment and close "Windows endless process spawning"
-  - Reason: v7.1.0 Bun migration eliminated PM2 process management
-  - Comment: Ask user to verify fix on v7.1.0, explain PM2 removal resolved issue
-
-- [ ] **#229** - Close as duplicate
-  - Reason: Duplicate of #227 (upstream Claude Code bug)
-  - Comment: Direct to #227 for full details and workaround
-
-- [ ] **#211** - Answer and close "Cursor IDE support question"
-  - Reason: Product question, not a bug report
-  - Comment: Explain focus is Claude Code, but plugin architecture may allow future expansion
-
-### Critical Bug Follow-Up
-
-- [ ] **#254** - Follow up on "Worker API fetch failed"
-  - Current status: Asked about PM2 logs (pre-v7.1.0 comment)
-  - Action: Update comment asking:
-    - What version of claude-mem are you running?
-    - If pre-v7.1.0: Please upgrade to v7.1.0 which fixes PM2 issues
-    - If v7.1.0+: Run troubleshoot skill and share logs
-
-## Phase 2: High-Priority Merges (This Week)
-
-### Security & Critical Fixes
-
-- [ ] **#236** - Review and merge "Localhost-only binding" 🔒 PRIORITY
-  - Impact: Security improvement (fixes network exposure)
-  - Status: 156 additions, all tests pass (42/42)
-  - Action: Final review, merge, update CHANGELOG
-
-- [ ] **#212** - Review and merge "Windows path quoting fix"
-  - Impact: Fixes Windows usernames with spaces
-  - Status: 6 lines changed, minimal risk
-  - Action: Quick cross-platform test, merge
-
-### Major Features (Maintainer-Authored)
-
-- [ ] **#225** - Review and merge "Export/Import scripts"
-  - Impact: Enables backup/restore, partially addresses #233
-  - Status: 927 additions, extensively tested by maintainer
-  - Action: Final review, merge, update docs
-
-- [ ] **#250** - Review and merge "README translations"
-  - Impact: International user onboarding (22 languages)
-  - Status: 10,209 additions (massive but low-risk)
-  - Action: Spot-check a few translations, merge
-
-### User-Requested Features
-
-- [ ] **#252** - Test and merge "Execution traces" (addresses #194)
-  - Impact: Shows tools/skills/MCPs in UI bubbles
-  - Status: 383 additions, comprehensive implementation
-  - Action: Test database migration, API endpoints, UI display
-
-- [ ] **#251** - Test and merge "Plan file context" (addresses #180)
-  - Impact: Injects last plan file into context
-  - Status: 85 additions, follows existing patterns
-  - Action: Test with real plan files, verify toggle works
-
-## Phase 3: Review & Consider (Next Week)
-
-### Quality Enhancements
-
-- [ ] **#230** - Review "Multi-language support" (addresses #228)
-  - Impact: Observations/summaries in user's language
-  - Status: 157 additions, Korean screenshot provided
-  - Action: Review prompt changes carefully, test with multiple languages
-
-- [ ] **#226** - Review "CLAUDE_CONFIG_DIR support"
-  - Impact: Supports non-standard Claude installations
-  - Status: 10 additions, minimal change
-  - Action: Test with custom config directory, merge if working
-
-### Developer Experience
-
-- [ ] **#216** - Review "Makefile shortcuts"
-  - Impact: DX improvement for contributors
-  - Status: 1,085 additions
-  - Priority: Low (not urgent)
-  - Action: Review when time permits
-
-## Phase 4: Issue Follow-Ups (Ongoing)
-
-### Awaiting User Verification
-
-- [ ] **#209** - Follow up if no response on Windows worker startup
-  - Status: Already commented asking for v7.1.0 verification
-  - Action: Close if verified fixed, or investigate if still broken
-
-- [ ] **#231** - Follow up if no response on module resolution
-  - Status: Already commented asking for v7.1.0 verification
-  - Action: Close if verified fixed, or investigate if still broken
-
-### Upstream Bugs (Keep Open)
-
-- [ ] **#227** - Keep open as documented upstream bug
-  - Reason: Claude Code CLI uses invalid Windows paths
-  - Action: No action needed, workaround documented
-
-### Active Bugs (Investigate)
-
-- [ ] **#208** - Investigate "Windows console windows appearing"
-  - Priority: Medium (cosmetic but annoying)
-  - Action: Reproduce on Windows, identify root cause
-
-## Phase 5: Future Feature Planning
-
-### Feature Requests Without PRs
-
-- [ ] **#240** - Plan "Move MCP scaffolding to separate file"
-  - Type: Internal refactoring
-  - Priority: Low
-  - Action: Design approach when time permits
-
-- [ ] **#239** - Plan "Track git branch as metadata"
-  - Type: Context enhancement
-  - Priority: Medium
-  - Action: Design schema changes, discuss approach
-
-- [ ] **#215** - Plan "PreCompact event hook"
-  - Type: Power user feature
-  - Priority: Low
-  - Action: Evaluate use cases, design API
-
-- [ ] **#233** - Plan "Multi-device sync" (partial solution exists)
-  - Type: Major feature
-  - Note: PR #225 provides export/import, full sync is more complex
-  - Action: Determine if export/import is sufficient, or plan cloud sync
-
-## Summary
-
-### Quick Wins (Do Today)
-- Close 2 obsolete PRs (#255, #206)
-- Close 3 resolved/duplicate issues (#213, #229, #211)
-- Follow up on critical bug (#254)
-
-### High-Impact Merges (This Week)
-- Merge security fix (#236)
-- Merge 2 simple fixes (#212, #225)
-- Merge 2 major features (#250, #252, #251)
-
-### Expected Impact
-- **Security**: Localhost-only by default
-- **Functionality**: Export/import, execution traces, plan context
-- **UX**: Multi-language support, Windows fixes
-- **Clarity**: Clean backlog, remove PM2 confusion
-
----
-
-**Next Review**: After Phase 2 completion, reassess remaining items
diff --git a/SECURITY.md b/SECURITY.md
deleted file mode 100644
index 15449b08..00000000
--- a/SECURITY.md
+++ /dev/null
@@ -1,186 +0,0 @@
-# Security Policy
-
-## Reporting a Vulnerability
-
-If you discover a security vulnerability in claude-mem, please report it by:
-
-1. **DO NOT** create a public GitHub issue
-2. Email the maintainer directly with details
-3. Include steps to reproduce, impact assessment, and suggested fixes if possible
-
-We take security seriously and will respond to valid reports within 48 hours.
-
-## Security Measures
-
-### Command Injection Prevention
-
-Claude-mem executes system commands for git operations and process management. We have implemented comprehensive protections against command injection:
-
-#### Safe Command Execution
-- **Array-based Arguments:** All commands use array-based arguments to prevent shell interpretation
-- **No Shell Execution:** `shell: false` is explicitly set for all spawn operations involving user input
-- **Input Validation:** All user-controlled parameters are validated before use
-
-#### Example Safe Pattern
-```typescript
-// ✅ SAFE: Array-based arguments with validation
-if (!isValidBranchName(userInput)) {
-  throw new Error('Invalid input');
-}
-spawnSync('git', ['checkout', userInput], { shell: false });
-
-// ❌ UNSAFE: Never do this
-execSync(`git checkout ${userInput}`);
-```
-
-### Input Validation
-
-All user-controlled inputs are validated using whitelists and strict patterns:
-
-- **Branch Names:** Must match `/^[a-zA-Z0-9][a-zA-Z0-9._/-]*$/` and not contain `..`
-- **Port Numbers:** Must be numeric and within range 1024-65535
-- **File Paths:** All paths are joined using `path.join()` to prevent traversal
-
-### Process Management
-
-- **PID File Protection:** Process IDs are stored in user's data directory (`~/.claude-mem/`)
-- **Port Validation:** Worker port is validated before binding
-- **Health Checks:** Worker health is verified before processing requests
-
-### Privacy Controls
-
-Claude-mem includes dual-tag system for content privacy:
-
-- `<private>content</private>` - User-level privacy (prevents storage)
-- `<claude-mem-context>content</claude-mem-context>` - System-level tag (prevents recursive storage)
-
-Tags are stripped at the hook layer before data reaches worker/database.
-
-## Security Audit History
-
-### 2025-12-16: Command Injection Vulnerability (Issue #354)
-- **Severity:** CRITICAL
-- **Status:** RESOLVED
-- **Details:** See [SECURITY_AUDIT_REPORT.md](./SECURITY_AUDIT_REPORT.md)
-- **Affected Versions:** All versions prior to fix
-- **Fixed In:** Current version
-- **Vulnerabilities Found:** 3
-- **Vulnerabilities Fixed:** 3
-
-**Summary of Fixes:**
-1. Replaced string interpolation with array-based arguments in `BranchManager.ts`
-2. Added `isValidBranchName()` validation function
-3. Removed unnecessary shell usage in `bun-path.ts`
-4. Created comprehensive security test suite
-
-## Security Best Practices for Contributors
-
-### When Adding Command Execution
-
-1. **NEVER use shell with user input:**
-   ```typescript
-   // ❌ NEVER
-   execSync(`command ${userInput}`);
-   spawn('command', [...], { shell: true });
-
-   // ✅ ALWAYS
-   spawnSync('command', [userInput], { shell: false });
-   ```
-
-2. **ALWAYS validate user input:**
-   ```typescript
-   if (!isValidInput(userInput)) {
-     throw new Error('Invalid input');
-   }
-   ```
-
-3. **Use array-based arguments:**
-   ```typescript
-   // ❌ NEVER
-   execSync(`git ${command} ${arg}`);
-
-   // ✅ ALWAYS
-   spawnSync('git', [command, arg], { shell: false });
-   ```
-
-4. **Explicitly set shell: false:**
-   ```typescript
-   spawnSync('command', args, { shell: false });
-   ```
-
-### When Adding User Input
-
-1. **Whitelist validation** over blacklist
-2. **Strict regex patterns** for format validation
-3. **Type checking** for expected data types
-4. **Range validation** for numeric inputs
-5. **Length limits** for string inputs
-
-### Code Review Checklist
-
-Before submitting a PR with command execution or user input handling:
-
-- [ ] No `execSync` with string interpolation or template literals
-- [ ] No `shell: true` when user input is involved
-- [ ] All spawn/spawnSync calls use array arguments
-- [ ] Input validation is present for all user-controlled parameters
-- [ ] Security tests are added for new attack vectors
-- [ ] Code follows patterns in [SECURITY_AUDIT_REPORT.md](./SECURITY_AUDIT_REPORT.md)
-
-## Dependencies
-
-We regularly audit dependencies for vulnerabilities:
-
-- **npm audit:** Run before each release
-- **Dependabot:** Enabled for automatic security updates
-- **Manual Review:** Critical dependencies reviewed quarterly
-
-## Data Storage
-
-Claude-mem stores data locally in `~/.claude-mem/`:
-
-- **Database:** SQLite3 at `~/.claude-mem/claude-mem.db`
-- **Vector Store:** Chroma at `~/.claude-mem/chroma/`
-- **Logs:** `~/.claude-mem/logs/`
-- **Settings:** `~/.claude-mem/settings.json`
-
-All data remains on the user's machine. No telemetry or external data transmission.
-
-## Permissions
-
-Claude-mem requires:
-
-- **File System:** Read/write to `~/.claude-mem/` and `~/.claude/plugins/`
-- **Network:** HTTP server on localhost (default port 37777)
-- **Process Management:** Spawn worker processes, manage PIDs
-
-No elevated privileges (root/administrator) are required.
-
-## Secure Defaults
-
-- **Worker Host:** Binds to `127.0.0.1` by default (localhost only)
-- **Worker Port:** User-configurable, validates range 1024-65535
-- **Log Level:** INFO by default (no sensitive data in logs)
-- **Privacy Tags:** Auto-strips private content before storage
-
-## Updates
-
-Security patches are released as soon as possible after discovery. Users should:
-
-1. Keep claude-mem updated to the latest version
-2. Monitor GitHub releases for security announcements
-3. Review [CHANGELOG.md](./CHANGELOG.md) for security-related changes
-
-## Questions?
-
-For security-related questions (non-vulnerabilities), please:
-
-1. Check [SECURITY_AUDIT_REPORT.md](./SECURITY_AUDIT_REPORT.md) for technical details
-2. Review code comments in security-critical files
-3. Open a GitHub Discussion (not an Issue) for general security questions
-
----
-
-**Last Updated:** 2025-12-16
-**Last Audit:** 2025-12-16 (Issue #354)
-**Next Scheduled Audit:** 2025-03-16
diff --git a/SECURITY_AUDIT_REPORT.md b/SECURITY_AUDIT_REPORT.md
deleted file mode 100644
index 790f259f..00000000
--- a/SECURITY_AUDIT_REPORT.md
+++ /dev/null
@@ -1,403 +0,0 @@
-# Security Audit Report - Command Injection Prevention
-
-**Date:** 2025-12-16
-**Issue:** #354 - Command Injection Vulnerability
-**Severity:** CRITICAL
-**Status:** RESOLVED
-
-## Executive Summary
-
-A comprehensive security audit was conducted to identify and fix command injection vulnerabilities in the claude-mem codebase. The primary vulnerability was found in `BranchManager.ts` where user-supplied branch names were directly interpolated into shell commands without validation or sanitization.
-
-### Vulnerabilities Found: 3
-### Vulnerabilities Fixed: 3
-### Files Modified: 2
-### Tests Added: 1 comprehensive test suite
-
----
-
-## Critical Vulnerabilities (Fixed)
-
-### 1. BranchManager.ts - Command Injection via Branch Name
-
-**File:** `src/services/worker/BranchManager.ts`
-**Lines:** 156, 159, 164, 224 (original line numbers)
-**Severity:** CRITICAL
-**Attack Vector:** User-controlled branch name parameter
-
-#### Original Vulnerable Code:
-```typescript
-// VULNERABLE: Direct string interpolation
-function execGit(command: string): string {
-  return execSync(`git ${command}`, { ... });
-}
-
-// Called with user input:
-execGit(`checkout ${targetBranch}`);  // Line 156
-execGit(`checkout -b ${targetBranch} origin/${targetBranch}`);  // Line 159
-execGit(`pull origin ${targetBranch}`);  // Line 164
-execGit(`pull origin ${info.branch}`);  // Line 224
-```
-
-#### Exploitation Example:
-```bash
-targetBranch = "main; rm -rf /"
-# Results in: git checkout main; rm -rf /
-```
-
-#### Fix Applied:
-1. **Input Validation:** Added `isValidBranchName()` function to validate branch names using regex
-2. **Array-based Arguments:** Replaced `execSync` string interpolation with `spawnSync` array arguments
-3. **Shell Disabled:** Explicitly set `shell: false` to prevent shell interpretation
-
-```typescript
-// SECURE: Array-based arguments with validation
-function isValidBranchName(branchName: string): boolean {
-  if (!branchName || typeof branchName !== 'string') {
-    return false;
-  }
-  const validBranchRegex = /^[a-zA-Z0-9][a-zA-Z0-9._/-]*$/;
-  return validBranchRegex.test(branchName) && !branchName.includes('..');
-}
-
-function execGit(args: string[]): string {
-  const result = spawnSync('git', args, {
-    cwd: INSTALLED_PLUGIN_PATH,
-    encoding: 'utf-8',
-    timeout: GIT_COMMAND_TIMEOUT_MS,
-    windowsHide: true,
-    shell: false  // CRITICAL: Never use shell with user input
-  });
-  // ... error handling
-  return result.stdout.trim();
-}
-
-// Called with validated input:
-if (!isValidBranchName(targetBranch)) {
-  return { success: false, error: 'Invalid branch name' };
-}
-execGit(['checkout', targetBranch]);
-```
-
----
-
-### 2. BranchManager.ts - NPM Command Injection
-
-**File:** `src/services/worker/BranchManager.ts`
-**Lines:** 173, 231 (original line numbers)
-**Severity:** MEDIUM
-**Attack Vector:** Indirect (through branch switching workflow)
-
-#### Original Vulnerable Code:
-```typescript
-// VULNERABLE: Shell execution
-function execShell(command: string): string {
-  return execSync(command, { ... });
-}
-
-execShell('npm install', NPM_INSTALL_TIMEOUT_MS);
-```
-
-#### Fix Applied:
-Created dedicated `execNpm()` function using array-based arguments:
-
-```typescript
-function execNpm(args: string[], timeoutMs: number = NPM_INSTALL_TIMEOUT_MS): string {
-  const isWindows = process.platform === 'win32';
-  const npmCmd = isWindows ? 'npm.cmd' : 'npm';
-
-  const result = spawnSync(npmCmd, args, {
-    cwd: INSTALLED_PLUGIN_PATH,
-    encoding: 'utf-8',
-    timeout: timeoutMs,
-    windowsHide: true,
-    shell: false  // CRITICAL: Never use shell
-  });
-  // ... error handling
-  return result.stdout.trim();
-}
-
-execNpm(['install'], NPM_INSTALL_TIMEOUT_MS);
-```
-
----
-
-### 3. bun-path.ts - Unnecessary Shell Usage on Windows
-
-**File:** `src/utils/bun-path.ts`
-**Line:** 26 (original)
-**Severity:** LOW
-**Attack Vector:** None (command is hardcoded), but violates security best practices
-
-#### Original Code:
-```typescript
-const result = spawnSync('bun', ['--version'], {
-  encoding: 'utf-8',
-  stdio: ['pipe', 'pipe', 'pipe'],
-  shell: isWindows  // Unnecessary shell usage
-});
-```
-
-#### Fix Applied:
-```typescript
-const result = spawnSync('bun', ['--version'], {
-  encoding: 'utf-8',
-  stdio: ['pipe', 'pipe', 'pipe'],
-  shell: false  // SECURITY: No need for shell
-});
-```
-
----
-
-## Safe Code Patterns Verified
-
-The following files were audited and confirmed to be safe from command injection:
-
-### 1. ProcessManager.ts
-```typescript
-// SAFE: Array-based arguments, no user input
-const child = spawn(bunPath, [script], {
-  detached: true,
-  stdio: ['ignore', 'pipe', 'pipe'],
-  env: { ...process.env, CLAUDE_MEM_WORKER_PORT: String(port) },
-  cwd: MARKETPLACE_ROOT,
-  ...(isWindows && { windowsHide: true })
-});
-```
-
-**Why Safe:**
-- Uses array-based arguments
-- No shell execution
-- Port parameter is validated (lines 29-35) before use
-- `bunPath` comes from trusted utility function
-
-### 2. SDKAgent.ts
-```typescript
-// SAFE: Hardcoded command, no user input
-execSync(process.platform === 'win32' ? 'where claude' : 'which claude', {
-  encoding: 'utf8',
-  windowsHide: true
-})
-```
-
-**Why Safe:**
-- Command is completely hardcoded (no user input)
-- Used only for finding Claude executable in PATH
-
-### 3. paths.ts
-```typescript
-// SAFE: Hardcoded command, no user input
-const gitRoot = execSync('git rev-parse --show-toplevel', {
-  cwd: process.cwd(),
-  encoding: 'utf8',
-  stdio: ['pipe', 'pipe', 'ignore'],
-  windowsHide: true
-});
-```
-
-**Why Safe:**
-- Command is completely hardcoded
-- No user input in command or arguments
-- `cwd` is from `process.cwd()` (trusted source)
-
-### 4. worker-utils.ts
-```typescript
-// SAFE: Hardcoded arguments
-spawnSync('pm2', ['delete', 'claude-mem-worker'], { stdio: 'ignore' });
-```
-
-**Why Safe:**
-- Array-based arguments
-- All arguments are hardcoded strings
-- No user input
-
----
-
-## Security Test Suite
-
-Created comprehensive test suite at `tests/security/command-injection.test.ts` with:
-
-- **50+ test cases** covering various injection attempts
-- **Platform-specific tests** for Windows and Unix command separators
-- **Edge case testing** (Unicode control chars, URL encoding, long inputs)
-- **Regression tests** for Issue #354
-- **Code verification tests** to ensure no shell usage remains
-
-### Key Test Categories:
-
-1. **Branch Name Validation**
-   - Shell metacharacters (`; && || | & $ \` \n \r`)
-   - Directory traversal (`..`)
-   - Invalid starting characters (`. - /`)
-   - Valid branch names (main, beta, feature/*, etc.)
-
-2. **Command Array Safety**
-   - Verifies no string interpolation in git commands
-   - Verifies `shell: false` is set
-   - Verifies array-based arguments are used
-
-3. **Cross-platform Attacks**
-   - Windows-specific injections (`& type C:\...`)
-   - Unix-specific injections (`; cat /etc/shadow`)
-
-4. **Edge Cases**
-   - Null/undefined/empty inputs
-   - URL encoding attempts
-   - Unicode control characters
-   - Very long inputs (1000+ chars)
-
----
-
-## Security Best Practices Applied
-
-### 1. Never Use Shell with User Input
-```typescript
-// ❌ NEVER DO THIS
-execSync(`git ${userInput}`);
-spawn('git', [...], { shell: true });
-
-// ✅ ALWAYS DO THIS
-spawnSync('git', [userInput], { shell: false });
-```
-
-### 2. Always Validate User Input
-```typescript
-// ❌ NEVER DO THIS
-execGit(['checkout', targetBranch]);
-
-// ✅ ALWAYS DO THIS
-if (!isValidBranchName(targetBranch)) {
-  return { success: false, error: 'Invalid input' };
-}
-execGit(['checkout', targetBranch]);
-```
-
-### 3. Use Array-based Arguments
-```typescript
-// ❌ NEVER DO THIS
-execSync(`git checkout ${branch}`);
-
-// ✅ ALWAYS DO THIS
-spawnSync('git', ['checkout', branch], { shell: false });
-```
-
-### 4. Explicit shell: false
-```typescript
-// ❌ BAD (shell might be enabled by default in some cases)
-spawnSync('git', ['checkout', branch]);
-
-// ✅ GOOD (explicit is better)
-spawnSync('git', ['checkout', branch], { shell: false });
-```
-
----
-
-## Verification Steps
-
-### Manual Testing
-```bash
-# Run security test suite
-bun test tests/security/command-injection.test.ts
-
-# Expected result: All tests pass
-```
-
-### Code Review Checklist
-- [x] No `execSync` with string interpolation
-- [x] No `shell: true` with user input
-- [x] All spawn/spawnSync calls use array arguments
-- [x] Input validation on all user-controlled parameters
-- [x] Security test coverage for all attack vectors
-
-### Automated Scanning
-```bash
-# Check for potential vulnerabilities
-grep -rn "execSync.*\${" src/
-grep -rn "shell:\s*true" src/
-grep -rn "exec(\`" src/
-
-# Expected result: No matches (or only false positives in comments)
-```
-
----
-
-## Impact Assessment
-
-### Before Fix:
-- **Risk:** Remote code execution via branch name parameter
-- **Attack Surface:** Any UI or API endpoint accepting branch names
-- **Affected Functions:** `switchBranch()`, `pullUpdates()`
-- **Exploitability:** High (trivial to exploit)
-
-### After Fix:
-- **Risk:** None
-- **Attack Surface:** Zero (input validation + safe execution)
-- **Affected Functions:** All secured
-- **Exploitability:** None
-
----
-
-## Recommendations
-
-### Immediate Actions
-1. ✅ Apply all fixes from this audit
-2. ✅ Run security test suite
-3. ✅ Deploy to production immediately (critical security fix)
-
-### Long-term Actions
-1. **Code Review Process:**
-   - Add security checklist to PR template
-   - Require review of all `exec*` and `spawn*` calls
-   - Flag any `shell: true` usage for security review
-
-2. **Automated Scanning:**
-   - Add pre-commit hooks to detect unsafe patterns
-   - Integrate SAST (Static Application Security Testing) tools
-   - Run security tests in CI/CD pipeline
-
-3. **Developer Training:**
-   - Document secure coding practices for command execution
-   - Share this audit report with the team
-   - Add security section to CONTRIBUTING.md
-
-4. **Regular Audits:**
-   - Quarterly security audits of all exec/spawn usage
-   - Review any new dependencies for vulnerabilities
-   - Keep security test suite updated with new attack vectors
-
----
-
-## Files Modified
-
-### /src/services/worker/BranchManager.ts
-- Added `isValidBranchName()` validation function
-- Replaced `execGit()` with safe implementation using `spawnSync`
-- Replaced `execShell()` with `execNpm()` using safe implementation
-- Added validation to `switchBranch()` function
-- Added validation to `pullUpdates()` function
-- Updated all git command calls to use array arguments
-
-### /src/utils/bun-path.ts
-- Changed `shell: isWindows` to `shell: false`
-
-### /tests/security/command-injection.test.ts (NEW)
-- Comprehensive security test suite with 50+ test cases
-
----
-
-## Conclusion
-
-All command injection vulnerabilities have been identified and fixed. The codebase now follows security best practices for command execution:
-
-1. **No shell execution** with user input
-2. **Array-based arguments** for all external commands
-3. **Input validation** on all user-controlled parameters
-4. **Comprehensive test coverage** for security scenarios
-
-The risk of command injection is now **ELIMINATED** in the claude-mem codebase.
-
----
-
-**Audited by:** Agent A (AI Security Audit)
-**Date:** 2025-12-16
-**Next Audit:** Recommended within 3 months
diff --git a/docs/PM2-TO-BUN-MIGRATION.md b/docs/PM2-TO-BUN-MIGRATION.md
deleted file mode 100644
index 1e978cc2..00000000
--- a/docs/PM2-TO-BUN-MIGRATION.md
+++ /dev/null
@@ -1,1508 +0,0 @@
-# PM2 to Bun Migration: Complete Technical Documentation
-
-**Version**: 7.1.0
-**Date**: December 2025
-**Migration Type**: Process Management (PM2 → Bun) + Database Driver (better-sqlite3 → bun:sqlite)
-
----
-
-## Table of Contents
-
-1. [Executive Summary](#executive-summary)
-2. [Architecture Comparison](#architecture-comparison)
-3. [Migration Mechanics](#migration-mechanics)
-4. [User Experience Timeline](#user-experience-timeline)
-5. [Platform-Specific Behavior](#platform-specific-behavior)
-6. [Observable Changes](#observable-changes)
-7. [File System State](#file-system-state)
-8. [Edge Cases and Troubleshooting](#edge-cases-and-troubleshooting)
-9. [Developer Notes](#developer-notes)
-
----
-
-## Executive Summary
-
-Claude-mem version 7.0.10 introduces two major architectural migrations:
-
-1. **Process Management**: PM2 → Custom Bun-based ProcessManager
-2. **Database Driver**: better-sqlite3 npm package → bun:sqlite runtime module
-
-Both migrations are **automatic** and **transparent** to end users. The first time a hook fires after updating to 7.0.10+, the system performs a one-time cleanup of legacy PM2 processes and transitions to the new architecture.
-
-### Key Benefits
-
-- **Simplified Dependencies**: Removes PM2 and better-sqlite3 npm packages
-- **Improved Cross-Platform Support**: Better Windows compatibility
-- **Faster Installation**: No native module compilation required
-- **Built-in Runtime**: Leverages Bun's built-in process management and SQLite
-- **Reduced Complexity**: Custom ProcessManager is simpler than PM2 integration
-
-### Migration Impact
-
-- **Data Preservation**: User data, settings, and database remain unchanged
-- **Automatic Cleanup**: Old PM2 processes automatically terminated (all platforms)
-- **No User Action Required**: Migration happens automatically on first hook trigger
-- **Backward Compatible**: SQLite database format unchanged (only driver changed)
-
----
-
-## Architecture Comparison
-
-### Old System (PM2-based)
-
-#### Process Management (PM2)
-
-**Component**: PM2 (Process Manager 2)
-- **Package**: `pm2` npm dependency
-- **Process Name**: `claude-mem-worker`
-- **Management**: External PM2 daemon manages lifecycle
-- **Discovery**: `pm2 list`, `pm2 describe` commands
-- **Auto-restart**: PM2 automatically restarts on crash
-- **Logs**: `~/.pm2/logs/claude-mem-worker-*.log`
-- **PID File**: `~/.pm2/pids/claude-mem-worker.pid`
-
-**Lifecycle Commands**:
-```bash
-pm2 start <script>           # Start worker
-pm2 stop claude-mem-worker   # Stop worker
-pm2 restart claude-mem-worker # Restart worker
-pm2 delete claude-mem-worker  # Remove from PM2
-pm2 logs claude-mem-worker    # View logs
-```
-
-**Pain Points**:
-- Additional npm dependency required
-- PM2 daemon must be running
-- Potential conflicts with other PM2 processes
-- Windows compatibility issues
-- Complex configuration for simple use case
-
-#### Database Driver (better-sqlite3)
-
-**Component**: better-sqlite3
-- **Package**: `better-sqlite3` npm package (native module)
-- **Installation**: Requires native compilation (node-gyp)
-- **Windows**: Requires Visual Studio build tools + Python
-- **Import**: `import Database from 'better-sqlite3'`
-- **Verification**: Extensive checks in `smart-install.js`
-
-**Installation Requirements**:
-- Node.js development headers
-- C++ compiler (gcc/clang on Mac/Linux, MSVC on Windows)
-- Python (for node-gyp)
-- Windows: Visual Studio Build Tools
-
----
-
-### New System (Bun-based)
-
-#### Process Management (Custom ProcessManager)
-
-**Component**: Custom ProcessManager (`src/services/process/ProcessManager.ts`)
-- **Package**: Built-in Bun APIs (no external dependency)
-- **Process Spawn**: `Bun.spawn()` with detached mode
-- **Management**: Direct process control via PID file
-- **Discovery**: PID file + process existence check + HTTP health check
-- **Auto-restart**: Hook-triggered restart on failure detection
-- **Logs**: `~/.claude-mem/logs/worker-YYYY-MM-DD.log`
-- **PID File**: `~/.claude-mem/.worker.pid`
-- **Port File**: `~/.claude-mem/.worker.port` (new)
-
-**Lifecycle Commands**:
-```bash
-npm run worker:start    # Start worker
-npm run worker:stop     # Stop worker
-npm run worker:restart  # Restart worker
-npm run worker:status   # Check status
-npm run worker:logs     # View logs
-```
-
-**Core Mechanisms**:
-
-1. **PID File Management**:
-   - File: `~/.claude-mem/.worker.pid`
-   - Content: Process ID (e.g., "35557")
-   - Created: On worker start
-   - Deleted: On worker stop
-   - Validation: Process existence via `kill(pid, 0)` signal
-
-2. **Port File Management**:
-   - File: `~/.claude-mem/.worker.port`
-   - Content: Two lines (port number, PID)
-   - Purpose: Track port binding and validate PID match
-   - Created: After successful port binding
-   - Deleted: On worker stop
-
-3. **Health Checking**:
-   - Layer 1: PID file exists?
-   - Layer 2: Process alive? (`kill(pid, 0)`)
-   - Layer 3: HTTP health check (`GET /health`)
-   - All three must pass for "healthy" status
-
-4. **Port Validation**:
-   - Range: 1024-65535
-   - Validation: At ProcessManager.start() entry point
-   - Prevents: Invalid ports from reaching spawn logic
-
-**Advantages**:
-- No external dependencies
-- Simpler codebase (direct control)
-- Better error handling and validation
-- Platform-agnostic (Bun handles platform differences)
-- Cleaner separation of concerns
-
-#### Database Driver (bun:sqlite)
-
-**Component**: bun:sqlite
-- **Package**: Built into Bun runtime (no npm package)
-- **Installation**: None required (comes with Bun ≥1.0)
-- **Platform**: Works anywhere Bun works
-- **Import**: `import { Database } from 'bun:sqlite'`
-- **API**: Similar to better-sqlite3 (synchronous)
-
-**Installation Requirements**:
-- Bun ≥1.0 (automatically installed if missing)
-- No native compilation required
-- No platform-specific build tools needed
-
-**Compatibility**:
-- SQLite database format: **Unchanged**
-- Database file: `~/.claude-mem/claude-mem.db` (same location)
-- Query syntax: **Identical** (both use SQLite SQL)
-- API surface: **Similar** (both provide synchronous SQLite API)
-
----
-
-## Migration Mechanics
-
-### One-Time PM2 Cleanup
-
-The migration system uses a marker-based approach to perform PM2 cleanup exactly once.
-
-**Implementation**: `src/shared/worker-utils.ts:73-86`
-
-```typescript
-// Clean up legacy PM2 (one-time migration)
-const pm2MigratedMarker = join(DATA_DIR, '.pm2-migrated');
-
-if (!existsSync(pm2MigratedMarker)) {
-  try {
-    spawnSync('pm2', ['delete', 'claude-mem-worker'], { stdio: 'ignore' });
-    // Mark migration as complete
-    writeFileSync(pm2MigratedMarker, new Date().toISOString(), 'utf-8');
-    logger.debug('SYSTEM', 'PM2 cleanup completed and marked');
-  } catch {
-    // PM2 not installed or process doesn't exist - still mark as migrated
-    writeFileSync(pm2MigratedMarker, new Date().toISOString(), 'utf-8');
-  }
-}
-```
-
-### Migration Trigger Points
-
-**Hook Path** (where migration happens):
-1. SessionStart, UserPromptSubmit, PostToolUse hooks execute
-2. Hook calls `ensureWorkerRunning()` (`worker-utils.ts`)
-3. `ensureWorkerRunning()` determines worker not running (no PID file)
-4. Calls `startWorker()` (`worker-utils.ts`)
-5. `startWorker()` checks for migration marker
-6. **If marker missing**: Runs PM2 cleanup, creates marker
-7. **If marker exists**: Skips cleanup
-8. Proceeds to start new Bun-managed worker
-
-**CLI Path** (bypasses migration):
-1. User runs `npm run worker:start|stop|restart`
-2. CLI calls `ProcessManager.start|stop|restart()` directly
-3. ProcessManager methods do NOT check migration marker
-4. No PM2 cleanup attempted
-5. Direct Bun process management
-
-**Key Insight**: Migration only happens via hook path, not CLI path. This is intentional - CLI starts are explicit user actions, while hooks represent automatic background starts.
-
-### Migration Steps (First Hook Trigger)
-
-1. **Marker Check**:
-   - Check: `~/.claude-mem/.pm2-migrated` exists?
-   - Missing → Continue to cleanup
-   - Present → Skip to worker start
-
-2. **PM2 Cleanup Attempt**:
-   - Executed on all platforms (Mac/Linux/Windows)
-   - Safe due to try/catch error handling
-
-3. **PM2 Cleanup**:
-   - Execute: `pm2 delete claude-mem-worker`
-   - Ignore errors (PM2 might not be installed, process might not exist)
-   - This terminates the old PM2-managed worker
-
-4. **Marker Creation**:
-   - Write: ISO timestamp to `~/.claude-mem/.pm2-migrated`
-   - Purpose: Prevent repeated cleanup attempts
-   - Created even if PM2 cleanup failed
-
-5. **New Worker Start**:
-   - Spawn: New Bun-managed worker process
-   - Create: `.worker.pid` and `.worker.port` files
-   - Log: Worker startup in `~/.claude-mem/logs/`
-
-### Marker File
-
-**Location**: `~/.claude-mem/.pm2-migrated`
-
-**Content**: ISO 8601 timestamp
-```
-2025-12-13T00:18:39.673Z
-```
-
-**Purpose**:
-- One-time migration flag
-- Prevents repeated PM2 cleanup on every start
-- Persists across restarts and reboots
-
-**Lifecycle**:
-- Created: First hook trigger after update to 7.0.10+ (all platforms)
-- Updated: Never
-- Deleted: Never (user could manually delete to force re-migration)
-
-**Platform Behavior**:
-- **All Platforms**: Created on first hook trigger after update
-- **Cross-platform**: Same migration behavior on Mac/Linux/Windows
-
----
-
-## User Experience Timeline
-
-### Pre-Update State (Version < 7.0.10)
-
-**Process Management**:
-- Worker managed by PM2 daemon
-- Process name: `claude-mem-worker`
-- PID file: `~/.pm2/pids/claude-mem-worker.pid`
-- Logs: `~/.pm2/logs/claude-mem-worker-*.log`
-
-**Database**:
-- Driver: better-sqlite3 npm package
-- Database file: `~/.claude-mem/claude-mem.db`
-- Native module: Compiled during npm install
-
-**User Commands**:
-```bash
-pm2 list                     # See worker status
-pm2 logs claude-mem-worker   # View logs
-pm2 restart claude-mem-worker # Restart worker
-```
-
-### Update Process
-
-**Method 1: Automatic Update**
-1. Claude Code checks for plugin updates
-2. Downloads claude-mem 7.0.10+
-3. Syncs to `~/.claude/plugins/marketplaces/thedotmack/`
-4. New hook scripts deployed
-
-**Method 2: Manual Update**
-```bash
-cd ~/Scripts/claude-mem
-git pull origin main
-npm run build
-npm run sync-marketplace
-```
-
-**What Gets Updated**:
-- Hook scripts (6 files in `plugin/scripts/*-hook.js`)
-- Worker service code (bundled)
-- Skill definitions
-- Package metadata
-
-**What Doesn't Change**:
-- User data: `~/.claude-mem/claude-mem.db` (unchanged)
-- Settings: `~/.claude-mem/settings.json` (unchanged)
-- Chroma: `~/.claude-mem/chroma/` (unchanged)
-- Logs: `~/.claude-mem/logs/` (preserved)
-
-**Old Worker State During Update**:
-- Old PM2 worker may still be running
-- Running old code (pre-7.0.10)
-- Will continue until next hook trigger or manual stop
-
-### First Session After Update (Critical Migration Moment)
-
-**Trigger**: User opens Claude Code, any hook fires (SessionStart most common)
-
-**Step-by-Step Execution**:
-
-1. **Hook Execution** (using new 7.0.10 code):
-   ```
-   SessionStart hook fires
-   → Calls ensureWorkerRunning()
-   ```
-
-2. **Worker Status Check**:
-   ```
-   ensureWorkerRunning() checks:
-   - Does ~/.claude-mem/.worker.pid exist? NO
-   - Conclusion: Worker not running (from new system perspective)
-   ```
-
-3. **Start Worker Decision**:
-   ```
-   Worker not running → Call startWorker()
-   ```
-
-4. **Migration Check**:
-   ```
-   startWorker() checks:
-   - Marker: ~/.claude-mem/.pm2-migrated exists? NO
-   ```
-
-5. **PM2 Cleanup** (all platforms):
-   ```
-   Execute: pm2 delete claude-mem-worker
-   Result: Old PM2 worker terminated (if exists)
-   Create: ~/.claude-mem/.pm2-migrated with timestamp
-   Log: "PM2 cleanup completed and marked"
-   ```
-
-6. **New Worker Start**:
-   ```
-   Spawn: bun plugin/scripts/worker-cli.js start <port>
-   Create: ~/.claude-mem/.worker.pid (e.g., "35557")
-   Create: ~/.claude-mem/.worker.port (port + PID)
-   Log: Worker startup in ~/.claude-mem/logs/worker-YYYY-MM-DD.log
-   ```
-
-7. **Verification**:
-   ```
-   Check: Process exists (kill -0)
-   Check: HTTP health check (GET /health)
-   Result: Worker confirmed running
-   ```
-
-8. **Hook Completion**:
-   ```
-   Hook returns success
-   Claude Code session starts normally
-   ```
-
-**User Observable Behavior**:
-- Slight delay on first startup (PM2 cleanup + new worker spawn)
-- No error messages (cleanup failures silently handled)
-- Worker appears running via `npm run worker:status`
-- Old PM2 worker no longer in `pm2 list`
-
-**Timing**:
-- Total migration time: ~2-5 seconds
-- PM2 cleanup: ~1 second
-- New worker spawn: ~1-3 seconds
-- Health check: ~1 second
-
-### Subsequent Sessions (After Migration)
-
-**Every Hook Trigger**:
-
-1. **Hook Execution**:
-   ```
-   Any hook fires → ensureWorkerRunning()
-   ```
-
-2. **Worker Status Check**:
-   ```
-   Check 1: ~/.claude-mem/.worker.pid exists? YES
-   Check 2: Process alive (kill -0)? YES
-   Check 3: HTTP health check? SUCCESS
-   Result: Worker already running, done
-   ```
-
-3. **No Migration Logic**:
-   ```
-   startWorker() NOT called
-   Marker check NOT performed
-   PM2 cleanup NOT attempted
-   Fast path: ~50ms total
-   ```
-
-**If Worker Needs Restart**:
-
-```
-Scenario: Worker crashed, PID file stale
-
-Check 1: PID file exists? YES (35557)
-Check 2: Process alive? NO (process 35557 dead)
-Action: Call startWorker()
-Migration: Marker exists → skip PM2 cleanup
-Result: Spawn new worker immediately
-```
-
-**CLI Commands** (all sessions):
-```bash
-npm run worker:status   # Check: PID file + process + health
-npm run worker:restart  # Kill current, spawn new
-npm run worker:stop     # Kill current, delete PID files
-npm run worker:start    # Spawn new (if not running)
-npm run worker:logs     # tail -f logs/worker-YYYY-MM-DD.log
-```
-
-**Key Differences from First Session**:
-- No PM2 cleanup (marker exists)
-- No migration delay
-- Faster startup (~1-2 seconds vs ~2-5 seconds)
-
----
-
-## Platform-Specific Behavior
-
-### macOS (Darwin)
-
-**First Session After Update**:
-
-1. **Marker Check**:
-   ```
-   File: ~/.claude-mem/.pm2-migrated
-   Exists: NO
-   ```
-
-2. **PM2 Cleanup**:
-   ```bash
-   Command: pm2 delete claude-mem-worker
-
-   Possible Outcomes:
-   A) PM2 installed, process exists:
-      → Successfully deleted, exit code 0
-
-   B) PM2 installed, process doesn't exist:
-      → Error: "process claude-mem-worker not found"
-      → Exit code 1, error ignored
-
-   C) PM2 not installed:
-      → Error: "command not found: pm2"
-      → Error ignored (catch block)
-   ```
-
-3. **Marker Creation**:
-   ```
-   File: ~/.claude-mem/.pm2-migrated
-   Content: 2025-12-13T00:18:39.673Z
-   Created: Regardless of PM2 cleanup success/failure
-   ```
-
-4. **New Worker**:
-   ```bash
-   Spawn: bun plugin/scripts/worker-cli.js start 37777
-   Detached: true (process runs independently)
-   Stdout/Stderr: ~/.claude-mem/logs/worker-YYYY-MM-DD.log
-   ```
-
-**Subsequent Sessions**:
-- Marker exists → PM2 cleanup skipped
-- Standard ProcessManager flow
-- Fast startup (~50ms status check)
-
-**macOS-Specific Notes**:
-- POSIX signal handling (kill -0, SIGTERM work natively)
-- Bun fully supported on macOS
-- No platform-specific workarounds needed
-
-### Linux
-
-**Behavior**: Identical to macOS
-
-**First Session**:
-- Marker check → Missing
-- PM2 cleanup → Attempted
-- Marker created → `~/.claude-mem/.pm2-migrated`
-
-**Subsequent Sessions**:
-- Marker exists → Skip cleanup
-- Standard ProcessManager flow
-
-**Linux-Specific Notes**:
-- POSIX signal handling (same as macOS)
-- Systemd integration possible (not implemented)
-- Process management via standard Linux APIs
-
-**Distribution Compatibility**:
-- Ubuntu/Debian: Fully supported
-- RHEL/CentOS: Fully supported
-- Arch: Fully supported
-- Alpine: Bun may require glibc (not musl)
-
-### Windows
-
-**First Session After Update**:
-
-1. **Marker Check**:
-   ```
-   File: ~/.claude-mem/.pm2-migrated
-   Exists: NO
-   ```
-
-2. **PM2 Cleanup Attempt**:
-   ```
-   Execute: pm2 delete claude-mem-worker
-
-   Possible Outcomes:
-   A) PM2 installed, process exists:
-      → Successfully deleted, exit code 0
-
-   B) PM2 installed, process doesn't exist:
-      → Error: "process claude-mem-worker not found"
-      → Exit code 1, error ignored
-
-   C) PM2 not installed:
-      → Error: "command not found: pm2" (or pm2.cmd on Windows)
-      → Error ignored (catch block)
-
-   D) PM2.cmd exists but fails:
-      → Error caught and ignored
-   ```
-
-3. **Marker Creation**:
-   ```
-   File: ~/.claude-mem/.pm2-migrated
-   Content: 2025-12-13T00:18:39.673Z
-   Created: Regardless of PM2 cleanup success/failure
-   ```
-
-4. **New Worker**:
-   ```powershell
-   Spawn: bun plugin/scripts/worker-cli.js start 37777
-   Detached: true (Windows process detachment)
-   Stdout/Stderr: ~/.claude-mem/logs/worker-YYYY-MM-DD.log
-   ```
-
-**Subsequent Sessions**:
-- Marker exists → PM2 cleanup skipped
-- Standard ProcessManager flow
-- Fast startup (~50ms status check)
-
-**Windows-Specific Notes**:
-
-1. **PM2 Cleanup on Windows**:
-   - Now runs on Windows just like Mac/Linux
-   - Safe due to try/catch error handling
-   - Even if PM2 had issues historically, orphaned processes are cleaned up
-   - Quality migration: no garbage processes left behind
-
-2. **Signal Handling**:
-   - Windows doesn't support POSIX signals (SIGTERM, etc.)
-   - Bun abstracts this: `kill(pid, 0)` works on Windows
-   - Process termination uses Windows APIs internally
-
-3. **Path Separators**:
-   - Bun handles `~/.claude-mem/` on Windows (`C:\Users\<user>\.claude-mem\`)
-   - Path module ensures correct separators
-   - Works seamlessly across platforms
-
-4. **File Locking**:
-   - Windows file locking stricter than Unix
-   - SQLite database handles this (bun:sqlite)
-   - PID/port files use atomic writes
-
-**Windows Command Equivalents**:
-```powershell
-npm run worker:status   # Works (uses HTTP + process check)
-npm run worker:restart  # Works (Bun process management)
-npm run worker:logs     # Works (PowerShell compatible)
-```
-
-### Platform Comparison Table
-
-| Feature | macOS | Linux | Windows |
-|---------|-------|-------|---------|
-| PM2 Cleanup | ✅ Attempted | ✅ Attempted | ✅ Attempted |
-| Marker File | ✅ Created | ✅ Created | ✅ Created |
-| Process Signals | POSIX (native) | POSIX (native) | Bun abstraction |
-| Bun Support | ✅ Full | ✅ Full | ✅ Full |
-| PID File | ✅ Yes | ✅ Yes | ✅ Yes |
-| Port File | ✅ Yes | ✅ Yes | ✅ Yes |
-| Health Check | ✅ HTTP | ✅ HTTP | ✅ HTTP |
-| Migration Delay | ~2-5s first time | ~2-5s first time | ~2-5s first time |
-
----
-
-## Observable Changes
-
-### Command Changes
-
-**Old PM2 Commands** → **New Bun Commands**:
-
-| Old (PM2) | New (Bun) | Notes |
-|-----------|-----------|-------|
-| `pm2 list` | `npm run worker:status` | Shows worker status |
-| `pm2 start <script>` | `npm run worker:start` | Start worker |
-| `pm2 stop claude-mem-worker` | `npm run worker:stop` | Stop worker |
-| `pm2 restart claude-mem-worker` | `npm run worker:restart` | Restart worker |
-| `pm2 delete claude-mem-worker` | `npm run worker:stop` | Remove worker |
-| `pm2 logs claude-mem-worker` | `npm run worker:logs` | View logs |
-| `pm2 describe claude-mem-worker` | `npm run worker:status` | Detailed status |
-| `pm2 monit` | ❌ No equivalent | PM2-specific monitoring |
-
-**New Commands Work Everywhere**:
-- Cross-platform (Mac/Linux/Windows)
-- No PM2 installation required
-- Consistent behavior across platforms
-
-### File Location Changes
-
-**Logs**:
-```
-Old: ~/.pm2/logs/claude-mem-worker-out.log
-     ~/.pm2/logs/claude-mem-worker-error.log
-
-New: ~/.claude-mem/logs/worker-YYYY-MM-DD.log
-```
-
-**PID Files**:
-```
-Old: ~/.pm2/pids/claude-mem-worker.pid
-
-New: ~/.claude-mem/.worker.pid
-```
-
-**Process State**:
-```
-Old: PM2 daemon memory (pm2 save)
-
-New: ~/.claude-mem/.worker.pid
-     ~/.claude-mem/.worker.port
-     ~/.claude-mem/.pm2-migrated (all platforms)
-```
-
-**Database** (unchanged):
-```
-Same: ~/.claude-mem/claude-mem.db
-```
-
-### User-Visible Changes
-
-**Before Update**:
-```bash
-$ pm2 list
-┌────┬────────────────────┬─────────┬─────────┬──────────┐
-│ id │ name               │ status  │ restart │ uptime   │
-├────┼────────────────────┼─────────┼─────────┼──────────┤
-│ 0  │ claude-mem-worker  │ online  │ 0       │ 2d 5h    │
-└────┴────────────────────┴─────────┴─────────┴──────────┘
-
-$ pm2 logs claude-mem-worker
-[2025-12-12 10:00:00] Worker started on port 37777
-[2025-12-12 10:01:00] Processing observation #1234
-```
-
-**After Update**:
-```bash
-$ pm2 list
-┌────┬────────┬─────────┬─────────┬──────────┐
-│ id │ name   │ status  │ restart │ uptime   │
-├────┼────────┼─────────┼─────────┼──────────┤
-└────┴────────┴─────────┴─────────┴──────────┘
-# Empty - worker no longer managed by PM2
-
-$ npm run worker:status
-Worker is running
-PID: 35557
-Port: 37777
-Uptime: 2h 15m
-
-$ npm run worker:logs
-[2025-12-13 00:18:40] Worker started on port 37777
-[2025-12-13 00:19:00] Processing observation #1235
-```
-
-### Debugging Changes
-
-**Old System**:
-```bash
-# Get detailed process info
-pm2 describe claude-mem-worker
-
-# Show process tree
-pm2 prettylist
-
-# Flush logs
-pm2 flush
-
-# Monitor in real-time
-pm2 monit
-```
-
-**New System**:
-```bash
-# Get detailed process info
-npm run worker:status
-cat ~/.claude-mem/.worker.pid
-cat ~/.claude-mem/.worker.port
-
-# Show process info (direct)
-ps aux | grep worker-cli
-
-# View logs
-npm run worker:logs
-# Or directly:
-tail -f ~/.claude-mem/logs/worker-$(date +%Y-%m-%d).log
-
-# Check migration status
-ls -la ~/.claude-mem/.pm2-migrated
-cat ~/.claude-mem/.pm2-migrated
-```
-
-### Orphaned Files
-
-**After migration, these PM2 files may remain** (safe to delete):
-```
-~/.pm2/                    # Entire PM2 directory
-~/.pm2/logs/               # Old logs
-~/.pm2/pids/               # Old PID files
-~/.pm2/pm2.log             # PM2 daemon log
-~/.pm2/dump.pm2            # PM2 process dump
-```
-
-**Cleanup (optional)**:
-```bash
-# Remove PM2 entirely (if not used for other processes)
-pm2 kill
-rm -rf ~/.pm2
-
-# Or just remove claude-mem logs
-rm -f ~/.pm2/logs/claude-mem-worker-*.log
-rm -f ~/.pm2/pids/claude-mem-worker.pid
-```
-
----
-
-## File System State
-
-### PID File (`.worker.pid`)
-
-**Location**: `~/.claude-mem/.worker.pid`
-
-**Content**: Single line with process ID
-```
-35557
-```
-
-**Lifecycle**:
-```
-Worker Start:
-1. Spawn Bun process
-2. Get PID from spawn result
-3. Write PID to .worker.pid
-4. File created
-
-Worker Running:
-- File exists (read-only after creation)
-- Used for process checks
-
-Worker Stop:
-1. Read PID from .worker.pid
-2. Send SIGTERM to process
-3. Wait for graceful shutdown
-4. Delete .worker.pid
-5. File removed
-```
-
-**Validation**:
-```typescript
-// Check if worker is running
-const pidFile = join(DATA_DIR, '.worker.pid');
-if (!existsSync(pidFile)) return false;
-
-const pid = parseInt(readFileSync(pidFile, 'utf-8'));
-if (isNaN(pid)) return false;
-
-// Verify process exists
-try {
-  process.kill(pid, 0); // Signal 0 = existence check
-  return true; // Process exists
-} catch {
-  return false; // Process dead
-}
-```
-
-**Edge Cases**:
-- **Stale PID file**: Process died, file remains → Detected and cleaned up
-- **Corrupt PID file**: Non-numeric content → Treated as not running
-- **Missing PID file**: Worker not running → Start new worker
-
-### Port File (`.worker.port`)
-
-**Location**: `~/.claude-mem/.worker.port`
-
-**Content**: Two lines (port, PID)
-```
-37777
-35557
-```
-
-**Purpose**:
-1. Remember which port worker is using
-2. Validate port file matches current PID
-3. Prevent stale port information
-
-**Lifecycle**:
-```
-Worker Start:
-1. Spawn Bun process (PID: 35557)
-2. Worker binds to port (37777)
-3. Write port file:
-   Line 1: 37777
-   Line 2: 35557
-4. File created
-
-Worker Running:
-- File exists (read-only)
-- Used to get worker port
-
-Worker Stop:
-1. Read PID from .worker.pid
-2. Kill process
-3. Delete .worker.port
-4. Delete .worker.pid
-5. Files removed
-```
-
-**Validation**:
-```typescript
-// Get worker port with PID validation
-const portFile = join(DATA_DIR, '.worker.port');
-if (!existsSync(portFile)) return null;
-
-const [portStr, pidStr] = readFileSync(portFile, 'utf-8').split('\n');
-const port = parseInt(portStr);
-const filePid = parseInt(pidStr);
-
-// Check PID matches current worker
-const currentPid = getWorkerPid(); // Read from .worker.pid
-if (filePid !== currentPid) {
-  // PID mismatch - port file stale
-  unlinkSync(portFile);
-  return null;
-}
-
-return port;
-```
-
-**Why Two Files?**:
-- `.worker.pid`: Canonical source of truth (which process is worker)
-- `.worker.port`: Cached port info (avoid config file reads)
-- PID in port file: Validation (ensure port file matches current worker)
-
-### Migration Marker (`.pm2-migrated`)
-
-**Location**: `~/.claude-mem/.pm2-migrated`
-
-**Content**: ISO 8601 timestamp
-```
-2025-12-13T00:18:39.673Z
-```
-
-**Purpose**:
-- One-time migration flag
-- Prevents repeated PM2 cleanup
-- Debugging aid (when was migration performed)
-
-**Lifecycle**:
-```
-First Hook Trigger (All Platforms):
-1. Check: File exists? NO
-2. Execute: pm2 delete claude-mem-worker (errors ignored)
-3. Create: .pm2-migrated with timestamp
-4. File persists forever
-
-Subsequent Hook Triggers (All Platforms):
-1. Check: File exists? YES
-2. Action: Skip PM2 cleanup
-3. Continue: Start worker normally
-```
-
-**Platform Behavior**:
-- **All Platforms**: Consistent migration behavior
-- **Mac/Linux/Windows**: File created on first hook trigger
-
-**Manual Intervention**:
-```bash
-# Force re-migration (all platforms)
-rm ~/.claude-mem/.pm2-migrated
-# Next hook trigger will re-run PM2 cleanup
-
-# Check migration status
-ls -la ~/.claude-mem/.pm2-migrated  # Mac/Linux
-dir %USERPROFILE%\.claude-mem\.pm2-migrated  # Windows
-
-cat ~/.claude-mem/.pm2-migrated
-# Output: 2025-12-13T00:18:39.673Z
-```
-
-### File Permissions
-
-**PID and Port Files**:
-```bash
--rw-r--r--  1 user  staff  5 Dec 13 00:18 .worker.pid
--rw-r--r--  1 user  staff 11 Dec 13 00:18 .worker.port
-```
-- Readable by all (needed for status checks)
-- Writable by owner only
-
-**Migration Marker**:
-```bash
--rw-r--r--  1 user  staff 25 Dec 13 00:18 .pm2-migrated
-```
-- Readable by all
-- Writable by owner only
-- Content not sensitive (just timestamp)
-
-**Database**:
-```bash
--rw-r--r--  1 user  staff 10485760 Dec 13 00:20 claude-mem.db
-```
-- Readable/writable by owner
-- Contains user data (observations, sessions)
-
-### State Directory Structure
-
-**Before Migration** (PM2 system):
-```
-~/.claude-mem/
-├── claude-mem.db          # Database (unchanged)
-├── chroma/                # Vector embeddings (unchanged)
-├── logs/                  # Application logs (unchanged)
-└── settings.json          # User settings (unchanged)
-
-~/.pm2/
-├── logs/
-│   ├── claude-mem-worker-out.log
-│   └── claude-mem-worker-error.log
-├── pids/
-│   └── claude-mem-worker.pid
-└── pm2.log
-```
-
-**After Migration** (Bun system):
-```
-~/.claude-mem/
-├── claude-mem.db          # Database (same file)
-├── chroma/                # Vector embeddings (unchanged)
-├── logs/
-│   └── worker-2025-12-13.log  # New log format
-├── settings.json          # User settings (unchanged)
-├── .worker.pid            # ← NEW: Process ID
-├── .worker.port           # ← NEW: Port + PID
-└── .pm2-migrated          # ← NEW: Migration marker (all platforms)
-
-~/.pm2/                    # ← Orphaned (safe to delete)
-├── logs/                  # Old logs (no longer written)
-├── pids/                  # Old PID (no longer updated)
-└── pm2.log                # PM2 daemon log (not used)
-```
-
----
-
-## Edge Cases and Troubleshooting
-
-### Scenario 1: Migration Fails (PM2 Still Running)
-
-**Symptoms**:
-- `pm2 list` still shows `claude-mem-worker`
-- Port conflict errors in logs
-- Worker fails to start
-
-**Diagnosis**:
-```bash
-# Check if old PM2 worker running
-pm2 list
-
-# Check migration marker
-cat ~/.claude-mem/.pm2-migrated
-# If missing → migration not attempted or failed
-```
-
-**Causes**:
-1. PM2 cleanup threw exception (caught silently)
-2. PM2 process resurrection (if configured with `--watch`)
-3. User manually started PM2 worker after migration
-
-**Resolution**:
-```bash
-# Manual cleanup
-pm2 delete claude-mem-worker
-pm2 save  # Persist the deletion
-
-# Force re-migration (optional)
-rm ~/.claude-mem/.pm2-migrated
-
-# Restart worker
-npm run worker:restart
-```
-
-### Scenario 2: Stale PID File (Process Dead)
-
-**Symptoms**:
-- `npm run worker:status` shows "not running"
-- `.worker.pid` file exists
-- Process ID doesn't exist in `ps aux`
-
-**Diagnosis**:
-```bash
-# Check PID file
-cat ~/.claude-mem/.worker.pid
-# Example: 35557
-
-# Check if process exists
-ps aux | grep 35557
-# No result → process dead
-
-# Or use kill -0
-kill -0 35557 2>&1
-# Output: "No such process"
-```
-
-**Causes**:
-1. Worker crashed
-2. Process manually killed (`kill 35557`)
-3. System reboot (PID file persists across reboots)
-
-**Automatic Recovery**:
-```
-Next hook trigger:
-1. Read PID: 35557
-2. Check existence: Process dead
-3. Cleanup: Delete .worker.pid
-4. Action: Start new worker
-5. Result: Automatic recovery
-```
-
-**Manual Resolution**:
-```bash
-# Clean up stale files
-rm ~/.claude-mem/.worker.pid
-rm ~/.claude-mem/.worker.port
-
-# Start fresh worker
-npm run worker:start
-```
-
-### Scenario 3: Port File PID Mismatch
-
-**Symptoms**:
-- Worker running but port unknown
-- Port cache returns null
-- Settings updates don't find worker
-
-**Diagnosis**:
-```bash
-# Check PID file
-cat ~/.claude-mem/.worker.pid
-# Output: 36000
-
-# Check port file
-cat ~/.claude-mem/.worker.port
-# Output:
-# 37777
-# 35557  ← Different PID!
-```
-
-**Causes**:
-1. Worker restarted but port file not updated
-2. Race condition during restart
-3. Manual file modification
-
-**Automatic Recovery**:
-```typescript
-// Code handles this automatically
-const port = getWorkerPort();
-if (port === null) {
-  // PID mismatch detected, port file deleted
-  // Re-read from settings
-  return getPortFromSettings();
-}
-```
-
-**Manual Resolution**:
-```bash
-# Remove stale port file
-rm ~/.claude-mem/.worker.port
-
-# Port will be re-read from settings on next access
-```
-
-### Scenario 4: Simultaneous Hook Triggers (Race Condition)
-
-**Symptoms**:
-- Multiple worker processes spawned
-- Port binding failures
-- Duplicate entries in logs
-
-**Diagnosis**:
-```bash
-# Check for multiple workers
-ps aux | grep worker-cli
-# Shows 2+ worker processes
-
-# Check port binding
-lsof -i :37777
-# Shows which process has the port
-```
-
-**Cause**:
-- Two hooks fire simultaneously
-- Both check PID file (missing)
-- Both attempt to start worker
-- First succeeds, second fails (port in use)
-
-**Automatic Recovery**:
-```
-First worker:
-1. Spawns successfully
-2. Binds to port 37777
-3. Writes PID file
-4. Running
-
-Second worker:
-1. Spawns successfully
-2. Attempts to bind to port 37777
-3. Error: Address already in use
-4. Worker exits
-5. No PID file written (first worker owns it)
-
-Result: One worker running (correct state)
-```
-
-**Prevention**:
-```typescript
-// ProcessManager.start() checks if already running
-const isRunning = await this.isRunning();
-if (isRunning) {
-  return { success: true, pid: currentPid };
-}
-// Prevents double-start
-```
-
-### Scenario 5: Health Check Fails (Worker Running but Unhealthy)
-
-**Symptoms**:
-- Worker process exists
-- `npm run worker:status` shows "not running"
-- HTTP health check fails
-
-**Diagnosis**:
-```bash
-# Check process exists
-cat ~/.claude-mem/.worker.pid
-ps aux | grep $(cat ~/.claude-mem/.worker.pid)
-# Process is running
-
-# Check HTTP health
-curl http://localhost:37777/health
-# Connection refused or timeout
-```
-
-**Causes**:
-1. Worker startup incomplete (still initializing)
-2. Worker crashed after spawn (zombie process)
-3. Port binding failed but process didn't exit
-4. Firewall blocking localhost connections
-
-**Automatic Recovery**:
-```
-Hook health check:
-1. PID exists: YES
-2. Process alive: YES
-3. HTTP health: FAIL
-4. Action: Kill process, restart worker
-5. Result: Fresh worker spawned
-```
-
-**Manual Resolution**:
-```bash
-# Kill unhealthy worker
-kill $(cat ~/.claude-mem/.worker.pid)
-
-# Clean up state
-rm ~/.claude-mem/.worker.pid
-rm ~/.claude-mem/.worker.port
-
-# Start fresh
-npm run worker:start
-
-# Verify health
-curl http://localhost:37777/health
-# Should return: {"status":"healthy"}
-```
-
-### Scenario 6: Fresh Install (Never Had PM2)
-
-**Symptoms**:
-- User installs claude-mem 7.0.10+ for first time
-- No previous PM2 installation
-- Migration marker created but PM2 cleanup fails
-
-**Diagnosis**:
-```bash
-# Check PM2
-pm2 list
-# Output: command not found: pm2
-
-# Check marker
-cat ~/.claude-mem/.pm2-migrated
-# File exists (created despite PM2 not found)
-```
-
-**Expected Behavior**:
-```
-First hook trigger:
-1. Marker check: Missing
-2. PM2 cleanup: Attempted
-3. Error: "command not found: pm2"
-4. Catch block: Error ignored
-5. Marker creation: Success
-6. Worker start: Success
-
-Result: Normal startup, marker created, no issues
-```
-
-**No Action Needed**: This is expected and correct behavior.
-
-### Scenario 7: Manual Marker Deletion
-
-**Symptoms**:
-- User deletes `.pm2-migrated` file
-- Next hook trigger runs PM2 cleanup again
-
-**Diagnosis**:
-```bash
-# Check marker
-ls ~/.claude-mem/.pm2-migrated
-# File not found (user deleted it)
-```
-
-**Behavior**:
-```
-Next hook trigger:
-1. Marker check: Missing
-2. PM2 cleanup: Attempted
-3. Result: No PM2 worker exists (already cleaned)
-4. Error: "process claude-mem-worker not found"
-5. Catch block: Ignored
-6. Marker recreation: Success
-7. Worker start: Normal
-
-Result: No harm done, marker recreated
-```
-
-**Impact**: Minimal (one extra PM2 command execution, ~1 second delay)
-
-### Common Error Messages
-
-**Error**: `EADDRINUSE: address already in use`
-```
-Cause: Another process (or old worker) using port
-Resolution:
-1. Check: lsof -i :37777
-2. Kill: kill -9 <PID>
-3. Restart: npm run worker:restart
-```
-
-**Error**: `No such process`
-```
-Cause: PID file references dead process
-Resolution: Automatic cleanup on next hook trigger
-Manual: rm ~/.claude-mem/.worker.pid && npm run worker:start
-```
-
-**Error**: `pm2: command not found` (during migration)
-```
-Cause: PM2 not installed (fresh install or already uninstalled)
-Resolution: None needed (error is caught and ignored)
-Impact: Migration completes normally
-```
-
-**Error**: `Invalid port X. Must be between 1024 and 65535`
-```
-Cause: Port validation failed
-Resolution: Update settings to use valid port
-Command: Edit ~/.claude-mem/settings.json
-```
-
-**Error**: `Failed to bind to port`
-```
-Cause: Port already in use, or permission denied (<1024)
-Resolution:
-1. Check: lsof -i :<port>
-2. Change: Update CLAUDE_MEM_WORKER_PORT in settings
-3. Restart: npm run worker:restart
-```
-
----
-
-## Developer Notes
-
-### Testing the Migration
-
-**Test Environment Setup**:
-```bash
-# 1. Install old version (with PM2)
-git checkout <pre-7.0.10-tag>
-npm install
-npm run build
-npm run sync-marketplace
-
-# 2. Start PM2 worker
-pm2 start plugin/scripts/worker-cli.js --name claude-mem-worker
-
-# 3. Verify PM2 running
-pm2 list  # Should show claude-mem-worker
-
-# 4. Update to new version
-git checkout main
-npm install
-npm run build
-npm run sync-marketplace
-
-# 5. Trigger hook (simulate Claude Code session)
-# Open Claude Code, or manually trigger:
-node plugin/scripts/session-start-hook.js
-
-# 6. Verify migration
-pm2 list  # Should NOT show claude-mem-worker
-cat ~/.claude-mem/.pm2-migrated  # Should exist (all platforms)
-npm run worker:status  # Should show Bun worker running
-```
-
-**Automated Testing**:
-```bash
-# Run test suite (includes migration tests)
-npm test
-
-# Specific migration tests
-npm test -- src/services/process/ProcessManager.test.ts
-```
-
-### Architecture Decisions
-
-**Why Custom ProcessManager Instead of PM2?**:
-1. **Simplicity**: Direct control, no external daemon
-2. **Dependencies**: Remove npm dependency
-3. **Cross-platform**: Bun handles platform differences
-4. **Bundle Size**: Reduce plugin package size
-5. **Control**: Fine-grained error handling and validation
-
-**Why PID File Instead of PM2 Daemon?**:
-1. **Simplicity**: Filesystem-based state (no daemon)
-2. **Debugging**: Easy to inspect (cat .worker.pid)
-3. **Reliability**: No daemon failure scenarios
-4. **Unix Philosophy**: Simple, composable tools
-
-**Why One-Time Marker Instead of Always Running PM2 Delete?**:
-1. **Performance**: Avoid unnecessary process spawning
-2. **Idempotency**: Migration runs exactly once
-3. **Debugging**: Timestamp shows when migration occurred
-4. **Simplicity**: Clear migration state
-
-**Why Run PM2 Cleanup on All Platforms?**:
-1. **Quality Migration**: Clean up orphaned processes, even if PM2 had issues
-2. **Consistency**: Same behavior across all platforms
-3. **Safety**: Error handling already in place (try/catch)
-4. **No Downside**: If PM2 not installed, error is caught and ignored
-
-### Future Considerations
-
-**Potential Improvements**:
-1. **Systemd Integration** (Linux): Optional systemd unit file for system-level management
-2. **launchd Integration** (macOS): Optional launchd plist for startup on boot
-3. **Windows Service**: Optional Windows Service wrapper
-4. **Process Monitoring**: Built-in restart on crash (without waiting for hook)
-5. **Graceful Shutdown**: SIGTERM handler for clean database closing
-
-**Migration Cleanup** (future version):
-1. After ~6 months (all users migrated), remove PM2 cleanup code
-2. Remove `.pm2-migrated` marker file logic
-3. Simplify `startWorker()` function
-4. Keep ProcessManager as permanent architecture
-
-### Related Files
-
-**Core Implementation**:
-- `src/services/process/ProcessManager.ts` - Main process management
-- `src/shared/worker-utils.ts` - Worker utilities, migration logic
-- `src/cli/worker-cli.ts` - CLI commands
-
-**Database**:
-- `src/services/sqlite/Database.ts` - bun:sqlite integration
-- `src/types/database.ts` - Type definitions
-
-**Documentation**:
-- `docs/public/architecture/database.mdx` - Database architecture
-- `docs/public/architecture/overview.mdx` - System overview
-- `plugin/skills/troubleshoot/operations/worker.md` - Worker troubleshooting
-
-**Tests**:
-- `src/services/process/ProcessManager.test.ts` - Process management tests
-- `src/hooks/__tests__/full-lifecycle.test.ts` - Integration tests
-
-### Code References
-
-**Migration Marker Logic**:
-```typescript
-// src/shared/worker-utils.ts:74-86
-const pm2MigratedMarker = join(DATA_DIR, '.pm2-migrated');
-
-if (!existsSync(pm2MigratedMarker)) {
-  try {
-    spawnSync('pm2', ['delete', 'claude-mem-worker'], { stdio: 'ignore' });
-    writeFileSync(pm2MigratedMarker, new Date().toISOString(), 'utf-8');
-    logger.debug('SYSTEM', 'PM2 cleanup completed and marked');
-  } catch {
-    writeFileSync(pm2MigratedMarker, new Date().toISOString(), 'utf-8');
-  }
-}
-```
-
-**Port Validation**:
-```typescript
-// src/services/process/ProcessManager.ts:27-33
-if (isNaN(port) || port < 1024 || port > 65535) {
-  return {
-    success: false,
-    error: `Invalid port ${port}. Must be between 1024 and 65535`
-  };
-}
-```
-
-**Health Check Layers**:
-```typescript
-// src/shared/worker-utils.ts (conceptual)
-// Layer 1: PID file check
-const pidFile = join(DATA_DIR, '.worker.pid');
-if (!existsSync(pidFile)) return false;
-
-// Layer 2: Process existence check
-const pid = parseInt(readFileSync(pidFile, 'utf-8'));
-try {
-  process.kill(pid, 0);
-} catch {
-  return false;
-}
-
-// Layer 3: HTTP health check
-const response = await fetch(`http://localhost:${port}/health`);
-return response.ok;
-```
-
----
-
-## Summary
-
-The migration from PM2 to Bun-based ProcessManager is a **one-time, automatic, transparent** transition that:
-
-1. **Removes external dependencies** (PM2, better-sqlite3)
-2. **Simplifies architecture** (direct process control)
-3. **Improves cross-platform support** (especially Windows)
-4. **Preserves user data** (database, settings, logs unchanged)
-5. **Requires no user action** (automatic on first hook trigger)
-
-**Key Migration Moment**: First hook trigger after update to 7.0.10+
-**Duration**: ~2-5 seconds (one-time delay)
-**Impact**: Seamless transition, user-invisible
-**Rollback**: Not needed (migration is forward-only, safe)
-
-For most users, the migration will be completely transparent - they'll see no errors, no data loss, and experience improved reliability and simpler troubleshooting going forward.
diff --git a/docs/branch-switching-validation.md b/docs/branch-switching-validation.md
deleted file mode 100644
index 6d0cdc22..00000000
--- a/docs/branch-switching-validation.md
+++ /dev/null
@@ -1,113 +0,0 @@
-# Branch Switching Test Plan: feature/bun-executable
-
-## Overview
-This document validates that switching to the `feature/bun-executable` branch will be seamless for users.
-
-## Branch Switching Mechanism
-
-When a user switches branches via the Settings UI:
-
-1. **Branch Switch Request**: User selects `feature/bun-executable` from Settings UI
-2. **Validation**: SettingsRoutes validates branch name against allowed list
-3. **Git Operations**: BranchManager performs:
-   - Discard local changes (`git checkout -- .` and `git clean -fd`)
-   - Fetch from origin (`git fetch origin`)
-   - Checkout target branch (`git checkout feature/bun-executable`)
-   - Pull latest (`git pull origin feature/bun-executable`)
-4. **Install Dependencies**: 
-   - Clear install marker (`.install-version`)
-   - Run `npm install` (2 minute timeout)
-5. **Worker Restart**: Worker process exits and PM2/supervisor restarts it
-
-## Feature Branch Changes
-
-The `feature/bun-executable` branch makes these key changes:
-
-### Dependencies Removed
-- `better-sqlite3` → Uses Bun's built-in SQLite
-- `pm2` → Custom worker CLI with process management
-- `@types/better-sqlite3`
-
-### New Features
-- Auto-installation of Bun runtime in smart-install.js
-- Simplified worker management via worker-cli.js
-- No native module compilation required (better-sqlite3 removed)
-
-## Installation Validation
-
-### Current Branch → feature/bun-executable
-
-**Step 1: Branch Switch (BranchManager)**
-```bash
-git checkout feature/bun-executable
-git pull origin feature/bun-executable
-rm .install-version
-npm install  # ✅ Works - package.json is npm-compatible
-```
-
-**Step 2: First Hook Execution**
-```bash
-node plugin/scripts/context-hook.js
-  ↓
-Calls smart-install.js
-  ↓
-Checks if Bun installed → Auto-installs if missing
-  ↓
-Runs: bun install (if needed)
-```
-
-**Step 3: Worker Management**
-- Old: PM2 manages worker-service.cjs
-- New: worker-cli.js manages worker as background process
-- Transition: Automatic on first worker start command
-
-## Seamless Installation Checklist
-
-- [x] **Branch Validation**: `feature/bun-executable` added to allowedBranches list
-- [x] **npm install Compatible**: Feature branch package.json works with npm
-- [x] **No Breaking Changes**: No hooks that would fail on first run
-- [x] **Auto-Install**: smart-install.js automatically installs Bun if missing
-- [x] **Graceful Degradation**: Scripts fall back to node if Bun unavailable
-- [x] **No Manual Steps**: User just clicks "Switch Branch" in UI
-
-## Potential Issues & Mitigations
-
-### Issue 1: Bun Not in PATH After Install
-**Mitigation**: smart-install.js checks common Bun installation paths and provides clear instructions to user
-
-### Issue 2: PM2 vs Worker CLI Transition
-**Mitigation**: Old PM2 worker continues running, new worker CLI starts separately. User can manually stop old PM2 worker if needed.
-
-### Issue 3: Windows Compatibility
-**Mitigation**: Feature branch uses PowerShell installer for Windows, curl for Unix/macOS
-
-## Test Results
-
-### Unit Tests
-```bash
-✓ tests/branch-selector.test.ts (5 tests)
-  ✓ should allow main branch
-  ✓ should allow beta/7.0 branch
-  ✓ should allow feature/bun-executable branch
-  ✓ should reject invalid branch names
-  ✓ should have exactly 3 allowed branches
-```
-
-### Integration Tests
-```bash
-✓ All existing tests pass (42 tests)
-✓ No regressions introduced
-✓ TypeScript compilation successful
-```
-
-## Conclusion
-
-✅ **SEAMLESS INSTALLATION VALIDATED**
-
-The installation process is seamless because:
-1. Branch switching uses standard git operations
-2. `npm install` works on feature branch
-3. Bun auto-installs on first hook execution
-4. No manual intervention required
-5. Clear error messages if issues occur
-6. Backward compatible with existing installations
diff --git a/docs/context/SMART_INSTALL_ANALYSIS.md b/docs/context/SMART_INSTALL_ANALYSIS.md
deleted file mode 100644
index d62d83fb..00000000
--- a/docs/context/SMART_INSTALL_ANALYSIS.md
+++ /dev/null
@@ -1,561 +0,0 @@
-# Claude-Mem Smart Install & Plugin Hooks - Comprehensive Analysis
-
-**Generated:** 2025-12-09
-**Scope:** Smart install system, all plugin hooks, cross-platform compatibility, error handling, edge cases
-
----
-
-## Executive Summary
-
-This report provides a comprehensive analysis of claude-mem's smart install system and plugin hook infrastructure. The analysis focuses on cross-platform compatibility, error handling patterns, artificial blockers, and edge case handling.
-
-**Key Findings:**
-- ✅ Overall architecture is well-designed with clear separation of concerns
-- ⚠️ Multiple cross-platform compatibility issues identified
-- ⚠️ Several silent failure patterns that hinder debugging
-- ⚠️ Artificial blockers that could prevent legitimate use cases
-- ⚠️ Inconsistent timeout values across different components
-- ✅ No nested try-catch anti-patterns found
-
----
-
-## Architecture Overview
-
-### Smart Install System Flow
-
-```
-User Invokes Hook
-    ↓
-ensureWorkerRunning() [worker-utils.ts]
-    ↓
-isWorkerHealthy() → fetch /health endpoint
-    ↓
-    ├─ [HEALTHY] → Continue
-    └─ [UNHEALTHY] → startWorker()
-        ↓
-        ├─ [Windows] → PowerShell Start-Process (hidden window)
-        └─ [Unix] → Bun start ecosystem.config.cjs
-            ↓
-        Wait for health check (15 retries × 1000ms)
-            ↓
-            ├─ [SUCCESS] → Continue
-            └─ [FAILURE] → Throw error with manual recovery instructions
-```
-
-### Plugin Hook Lifecycle
-
-1. **SessionStart** (context-hook.ts + user-message-hook.ts)
-   - context-hook: Fetches context via HTTP/curl
-   - user-message-hook: Displays context to user via stderr
-
-2. **UserPromptSubmit** (new-hook.ts)
-   - Creates/retrieves SDK session
-   - Strips privacy tags from prompt
-   - Initializes session via HTTP
-
-3. **PostToolUse** (save-hook.ts)
-   - Filters skipped tools
-   - Sends observation to worker via HTTP
-
-4. **Stop** (summary-hook.ts)
-   - Parses transcript JSONL
-   - Extracts last user/assistant messages
-   - Requests summary generation via HTTP
-
-5. **SessionEnd** (cleanup-hook.ts)
-   - Marks session complete
-   - Fire-and-forget HTTP request
-
----
-
-## Cross-Platform Compatibility Issues
-
-### 🔴 CRITICAL: curl Dependency (context-hook.ts)
-
-**Location:** `src/hooks/context-hook.ts:32`
-
-```typescript
-const result = execSync(`curl -s "${url}"`, { encoding: "utf-8", timeout: 5000 });
-```
-
-**Issues:**
-1. **Windows Compatibility:** curl is not guaranteed to be available on Windows systems (though included in Windows 10 1803+, it may be missing on older systems or custom installations)
-2. **Error Handling:** No try-catch around execSync - will throw unhandled exception if curl fails
-3. **Redundancy:** Uses curl when JavaScript's native `fetch` is already used everywhere else in the codebase
-
-**Impact:** High - SessionStart hook will crash if curl is unavailable or returns non-zero exit code
-
-**Edge Cases:**
-- Corporate proxies blocking curl
-- Systems without curl in PATH
-- curl returning non-zero exit with valid output (warnings, etc.)
-
-**Recommendation:**
-```typescript
-// Replace curl with fetch (already used in user-message-hook.ts)
-const response = await fetch(url, { signal: AbortSignal.timeout(5000) });
-const result = await response.text();
-```
-
----
-
-### 🟡 MEDIUM: Platform-Specific Process Spawning (worker-utils.ts)
-
-**Location:** `src/shared/worker-utils.ts:55-93`
-
-**Windows Implementation:**
-```typescript
-spawnSync('powershell.exe', [
-  '-NoProfile',
-  '-NonInteractive',
-  '-Command',
-  `Start-Process -FilePath 'node' -ArgumentList '${workerScript}' -WorkingDirectory '${MARKETPLACE_ROOT}' -WindowStyle Hidden`
-])
-```
-
-**Issues:**
-1. **PowerShell Dependency:** Assumes PowerShell is available and in PATH
-2. **Command Injection Risk:** Worker script path inserted directly into command string without escaping
-3. **Process Monitoring:** Windows approach launches detached process with no Bun monitoring - harder to debug/restart
-4. **Health Check Timeout:** Comment says "Windows needs longer timeouts" but timeout is same for all platforms (500ms)
-
-**Edge Cases:**
-- Windows systems with PowerShell execution policy restrictions
-- Paths containing single quotes or special characters
-- Windows subsystem for Linux (WSL) environments
-- Wine/Proton compatibility layers
-
-**Unix Implementation:**
-```typescript
-const localBunBase = path.join(MARKETPLACE_ROOT, 'node_modules', '.bin', 'bun');
-const bunCommand = existsSync(localBunBase) ? localBunBase : 'bun';
-```
-
-**Issues:**
-1. **Bun Dependency:** Falls back to global bun if local not found, but doesn't verify it exists
-2. **Silent Failure:** If Bun not installed globally, spawnSync will fail with cryptic ENOENT error
-
-**Recommendation:**
-- Add bun existence check before spawn
-- Implement consistent process monitoring across platforms
-- Add path escaping for Windows command construction
-- Actually implement longer timeout for Windows if needed
-
----
-
-### 🟡 MEDIUM: Git Dependency (paths.ts)
-
-**Location:** `src/shared/paths.ts:89-97`
-
-```typescript
-export function getCurrentProjectName(): string {
-  try {
-    const gitRoot = execSync('git rev-parse --show-toplevel', {
-      cwd: process.cwd(),
-      encoding: 'utf8',
-      stdio: ['pipe', 'pipe', 'ignore']
-    }).trim();
-    return basename(gitRoot);
-  } catch {
-    return basename(process.cwd());
-  }
-}
-```
-
-**Issues:**
-1. **Git Assumption:** Assumes git is installed and available in PATH
-2. **Non-Git Projects:** Silently falls back to cwd basename, but this behavior is undocumented
-
-**Edge Cases:**
-- Projects not using git
-- Monorepos where cwd !== git root is desired
-- Systems without git installed
-
-**Status:** ✅ Already handled with fallback, but could benefit from debug logging
-
----
-
-## Error Handling Analysis
-
-### 🔴 CRITICAL: Silent Failures Without Logging
-
-#### 1. Settings File Loading (early-settings.ts:20-28)
-
-```typescript
-try {
-  if (existsSync(SETTINGS_PATH)) {
-    const data = JSON.parse(readFileSync(SETTINGS_PATH, 'utf-8'));
-    const fileValue = data.env?.[key];
-    if (fileValue !== undefined) return fileValue;
-  }
-} catch {
-  // Fail silently - fall through to env var
-}
-```
-
-**Problem:**
-- Invalid JSON in settings file fails silently
-- File read permission errors fail silently
-- Users have no way to know their settings file is being ignored
-
-**Impact:** High - Users may think settings are applied when they're actually using defaults
-
-**Recommendation:**
-```typescript
-} catch (error) {
-  logger.warn('SETTINGS', 'Failed to load settings file', { path: SETTINGS_PATH }, error);
-}
-```
-
----
-
-#### 2. Worker Startup Failure (worker-utils.ts:104-107)
-
-```typescript
-try {
-  // ... worker startup logic ...
-} catch (error) {
-  // Failed to start worker
-  return false;
-}
-```
-
-**Problem:**
-- Catches ALL errors during worker startup
-- Returns boolean with no information about what failed
-- User only gets generic error after all retries exhausted
-
-**Impact:** High - Makes debugging worker startup issues extremely difficult
-
-**Recommendation:**
-```typescript
-} catch (error) {
-  logger.error('WORKER', 'Failed to start worker', {}, error as Error);
-  return false;
-}
-```
-
----
-
-#### 3. Worker Health Check (worker-utils.ts:30-40)
-
-```typescript
-async function isWorkerHealthy(): Promise<boolean> {
-  try {
-    const port = getWorkerPort();
-    const response = await fetch(`http://127.0.0.1:${port}/health`, {
-      signal: AbortSignal.timeout(HEALTH_CHECK_TIMEOUT_MS)
-    });
-    return response.ok;
-  } catch {
-    return false;
-  }
-}
-```
-
-**Problem:**
-- Network errors, timeouts, and non-200 responses all indistinguishable
-- No logging at all - completely silent
-
-**Impact:** Medium - Hard to debug why health checks fail
-
-**Recommendation:**
-```typescript
-} catch (error) {
-  logger.debug('WORKER', 'Health check failed', { port }, error);
-  return false;
-}
-```
-
----
-
-#### 4. Tool Formatting (logger.ts:122-124)
-
-```typescript
-try {
-  const input = typeof toolInput === 'string' ? JSON.parse(toolInput) : toolInput;
-  // ...
-} catch {
-  return toolName;
-}
-```
-
-**Problem:**
-- Invalid JSON in tool input fails silently
-- Could mask data corruption issues
-
-**Impact:** Low - Only affects log formatting
-
-**Status:** ✅ Acceptable for log formatting, but could log at DEBUG level
-
----
-
-### 🟢 GOOD: No Nested Try-Catch Anti-Patterns
-
-Analysis confirmed zero instances of nested try-catch blocks. Error handling is consistently at single level per function.
-
----
-
-## Artificial Blockers & Unnecessary Checks
-
-### 🔴 CRITICAL: First-Run Detection (user-message-hook.ts:14-40)
-
-```typescript
-const nodeModulesPath = join(pluginDir, 'node_modules');
-
-if (!existsSync(nodeModulesPath)) {
-  // Show first-time setup message
-  console.error(`...`);
-  process.exit(3);
-}
-```
-
-**Problems:**
-1. **False Positive:** Will trigger if user manually deletes node_modules (e.g., for troubleshooting)
-2. **Installation Race:** Could fail if installation is still in progress
-3. **Hook-Level Check:** Runs on EVERY SessionStart, not just actual first run
-
-**Impact:** High - Prevents usage until node_modules exists, even if dependencies are installed elsewhere
-
-**Edge Cases:**
-- User runs `rm -rf node_modules` for troubleshooting
-- Package manager installation interrupted
-- Symlinked node_modules (some package managers)
-
-**Recommendation:**
-- Use a `.first-run-complete` marker file instead
-- Move check to npm postinstall script
-- Make check more robust (check for specific required modules)
-
----
-
-### 🟡 MEDIUM: Overly Specific Validation (paths.ts:117-119)
-
-```typescript
-if (!existsSync(join(commandsDir, 'save.md'))) {
-  throw new Error('Package commands directory missing required files');
-}
-```
-
-**Problem:**
-- Checks for ONE specific file to validate entire directory
-- Hardcoded filename could break if files reorganized
-- Error message doesn't specify what's missing
-
-**Impact:** Medium - Could prevent package from working after internal refactoring
-
-**Recommendation:**
-- Remove check entirely (let actual command invocation fail with better error)
-- Or check all required files if validation is critical
-
----
-
-### 🟡 MEDIUM: Duplicate Health Endpoints
-
-**Locations:**
-- `src/services/worker-service.ts:107` - `/api/health`
-- `src/services/worker/http/routes/ViewerRoutes.ts:27` - `/health`
-
-**Usage:**
-- `worker-utils.ts` uses `/health`
-- `mcp-server.ts` uses `/api/health`
-
-**Problem:**
-- Redundant endpoints doing the same thing
-- Inconsistent usage across codebase
-- Maintenance burden
-
-**Impact:** Low - Both work, but creates confusion
-
-**Recommendation:**
-- Standardize on `/api/health` (follows REST convention)
-- Remove `/health` endpoint
-- Update worker-utils.ts to use `/api/health`
-
----
-
-## Timeout Configuration Issues
-
-### Inconsistent Timeouts Across Components
-
-| Component | Timeout | Location | Purpose |
-|-----------|---------|----------|---------|
-| Health check | 500ms | worker-utils.ts:13 | Check if worker alive |
-| Worker startup wait | 1000ms | worker-utils.ts:14 | Wait between health checks |
-| Worker startup retries | 15x | worker-utils.ts:15 | Max retries (15s total) |
-| Hook HTTP requests | 2000ms | cleanup-hook.ts:61, save-hook.ts:70, summary-hook.ts:164 | Send data to worker |
-| New hook session init | 5000ms | new-hook.ts:129 | Initialize session |
-| Context hook fetch | 5000ms | context-hook.ts:32 | Fetch context via curl |
-| User message hook | 5000ms | user-message-hook.ts:52 | Fetch context display |
-
-**Problems:**
-1. **Health Check Too Aggressive:** 500ms may be too short for loaded systems or slow network
-2. **No Platform Adjustment:** Comment says "Windows needs longer timeouts" but values are same
-3. **Hook Timeout Variation:** Some hooks use 2s, others use 5s with no clear reasoning
-
-**Recommendations:**
-- Increase health check timeout to 1000ms minimum
-- Actually implement longer timeouts for Windows
-- Standardize hook timeouts to 5000ms across the board
-- Make timeouts configurable via settings
-
----
-
-## Edge Case Analysis
-
-### Handled Well ✅
-
-1. **JSONL Parsing:** summary-hook.ts continues on malformed lines (60-64, 117-121)
-2. **Git Not Available:** paths.ts falls back to cwd basename (89-97)
-3. **Settings File Missing:** early-settings.ts falls back to env vars and defaults (20-28)
-4. **Privacy Tags:** new-hook.ts handles fully-private prompts (99-109)
-5. **Tool Skipping:** save-hook.ts filters low-value tools (24-30)
-
-### Missing Edge Case Handling ⚠️
-
-1. **curl Failure:** context-hook.ts has no error handling for curl failures
-2. **Bun Not Installed:** worker-utils.ts assumes bun exists globally
-3. **PowerShell Restrictions:** worker-utils.ts doesn't check execution policy
-4. **Concurrent Worker Starts:** No locking to prevent multiple hooks from starting worker simultaneously
-5. **Port Already In Use:** No detection or recovery if worker port is taken
-6. **Zombie Processes:** Windows approach doesn't track PIDs, can't detect/kill zombies
-
----
-
-## Recommendations Summary
-
-### High Priority 🔴
-
-1. **Replace curl with fetch** in context-hook.ts
-   - Eliminates external dependency
-   - Consistent with rest of codebase
-   - Better error handling
-
-2. **Add logging to silent failures**
-   - early-settings.ts: Log when settings file fails to load
-   - worker-utils.ts: Log startup failures with details
-   - worker-utils.ts: Log health check failures at debug level
-
-3. **Fix first-run detection**
-   - Use marker file instead of node_modules check
-   - More reliable and intentional
-
-### Medium Priority 🟡
-
-4. **Verify Bun availability** before attempting to use it
-   - Check existence before spawn
-   - Provide clear error message if missing
-
-5. **Implement platform-specific timeouts**
-   - Actually use longer timeouts on Windows as comment suggests
-   - Make timeouts configurable
-
-6. **Standardize health endpoints**
-   - Remove duplicate `/health` endpoint
-   - Use `/api/health` everywhere
-
-7. **Add path escaping** for Windows PowerShell commands
-   - Prevent injection issues
-   - Handle paths with special characters
-
-### Low Priority 🟢
-
-8. **Standardize HTTP timeouts** across all hooks
-9. **Add concurrent startup protection** (locking mechanism)
-10. **Improve error messages** with actionable recovery steps
-
----
-
-## Testing Recommendations
-
-### Cross-Platform Testing Needed
-
-1. **Windows Environments:**
-   - Windows 10 (various versions)
-   - Windows 11
-   - Windows Server
-   - WSL/WSL2
-   - PowerShell execution policies (Restricted, RemoteSigned, Unrestricted)
-
-2. **Unix Environments:**
-   - macOS (Intel + Apple Silicon)
-   - Linux (Ubuntu, Fedora, Arch)
-   - FreeBSD
-
-3. **Edge Environments:**
-   - Docker containers
-   - CI/CD environments
-   - Systems without git installed
-   - Systems without curl (or with restricted curl)
-   - Corporate networks with proxies
-   - Low-spec systems (slow startup)
-
-### Test Scenarios
-
-1. **Cold Start:** First run with no existing data
-2. **Corrupt Settings:** Invalid JSON in settings.json
-3. **Missing Dependencies:** No Bun, no git, no curl
-4. **Port Conflicts:** Worker port already in use
-5. **Rapid Hook Invocations:** Multiple hooks trying to start worker simultaneously
-6. **Permission Issues:** Read-only filesystem, restricted execution
-7. **Network Issues:** Localhost blocked, slow network
-
----
-
-## Code Quality Assessment
-
-### Strengths ✅
-
-- Clean separation of concerns (hooks → worker → database)
-- No nested try-catch anti-patterns
-- Consistent use of modern async/await
-- Good use of TypeScript for type safety
-- Idempotent database operations
-- Clear documentation in critical sections
-
-### Weaknesses ⚠️
-
-- Silent failures hinder debugging
-- Inconsistent error handling patterns
-- Platform-specific code not fully tested/documented
-- Timeout configuration hardcoded and inconsistent
-- Some artificial blockers prevent legitimate use cases
-
-### Technical Debt
-
-- Duplicate health endpoints
-- curl dependency when fetch available
-- Bun dependency on Unix but not Windows (inconsistent monitoring)
-- First-run detection using node_modules existence
-- Hardcoded timeout values
-
----
-
-## Conclusion
-
-The claude-mem smart install and plugin hook system is architecturally sound with a well-designed separation of concerns. However, several cross-platform compatibility issues and silent failure patterns could cause problems in production, particularly on Windows systems or in edge case scenarios.
-
-The highest priority improvements are:
-1. Removing the curl dependency
-2. Adding proper logging to silent failures
-3. Fixing the fragile first-run detection
-4. Verifying external dependencies before use
-
-These changes would significantly improve debuggability and cross-platform reliability without requiring major architectural changes.
-
----
-
-**Analysis Methodology:**
-- Systematic review of all TypeScript source files
-- Static analysis of error handling patterns
-- Cross-platform compatibility assessment
-- Edge case identification through code path analysis
-- Comparison against best practices and KISS principles
-
-**Files Analyzed:**
-- src/hooks/*.ts (6 files)
-- src/services/worker-service.ts
-- src/services/worker/*.ts (10+ files)
-- src/servers/mcp-server.ts
-- src/shared/*.ts (worker-utils, early-settings, paths)
-- src/utils/*.ts (logger, silent-debug, tag-stripping)
diff --git a/docs/context/TEST_AUDIT_2025-12-13.md b/docs/context/TEST_AUDIT_2025-12-13.md
deleted file mode 100644
index 3ab64a8e..00000000
--- a/docs/context/TEST_AUDIT_2025-12-13.md
+++ /dev/null
@@ -1,386 +0,0 @@
-# Test Suite Audit Report
-**Date:** 2025-12-13
-**Auditor:** Code Quality Assurance Manager
-**Focus:** Recent bugfixes and regression prevention
-
----
-
-## Executive Summary
-
-The test suite has **critical gaps** in error handling coverage. While happy path tests exist, **zero tests verify that recent bugfixes actually prevent regressions**. The fish shell PATH bug (Issue #264), silent hook failures (observation 25389), and ChromaSync error standardization (observation 25458) are all unprotected by tests.
-
-**Risk Level:** HIGH - Recent bugfixes can silently regress without detection.
-
----
-
-## Coverage Analysis
-
-### What We Have ✅
-
-1. **Happy Path Tests** (`tests/happy-paths/`) - 6 files
-   - Basic success scenarios work
-   - Tool capture, search, session init/cleanup
-   - Good foundation but insufficient
-
-2. **Unit Tests**
-   - `bun-path.test.ts` - Tests PATH resolution logic
-   - `parser.test.ts` - SDK parser validation
-   - `strip-memory-tags.test.ts` - Privacy tag handling
-
-3. **Integration Test** (`full-lifecycle.test.ts`)
-   - ONE error recovery test (too shallow)
-   - Mostly happy paths
-   - All tests mock `fetch()` - never test real failures
-
-### What's Missing ❌
-
-## 1. Silent Hook Failures (CRITICAL GAP)
-
-**Issue:** Multiple hooks had no error logging until recently fixed
-
-**Fixed In:**
-- `save-hook.ts` (observation 25389) - Added `handleFetchError`/`handleWorkerError`
-- `new-hook.ts` - Added error handlers
-- `context-hook.ts` - Added error handlers
-
-**Test Gap:** ZERO tests verify hooks actually log errors when they fail
-
-**Created:** `/Users/alexnewman/Scripts/claude-mem/tests/error-handling/hook-error-logging.test.ts`
-
-**Tests:**
-- `handleFetchError()` logs with full context (status, hook, operation, tool, port)
-- `handleFetchError()` throws user-facing error with restart instructions
-- `handleWorkerError()` handles timeout/connection errors
-- Real hook scenarios (save-hook, new-hook, context-hook failures)
-- Error message quality (actionable, includes next steps)
-
-**Why This Matters:**
-If someone refactors hooks and removes error handlers, the system will silently fail again. These tests catch that regression immediately.
-
----
-
-## 2. ChromaSync Client Initialization (MEDIUM GAP)
-
-**Issue:** Standardized error messages across all client checks (observation 25458)
-
-**Code Locations:** ChromaSync.ts lines 140-145, 324-329, 504-509, 761-766
-
-**Test Gap:** NO tests verify error messages are consistent or fire correctly
-
-**Created:** `/Users/alexnewman/Scripts/claude-mem/tests/services/chroma-sync-errors.test.ts`
-
-**Tests:**
-- Calling methods before `ensureConnection()` throws correct message
-- All error messages include project name
-- Error messages are consistent across all 4 locations
-- Fail-fast behavior (no silent retries)
-- Error context preservation
-
-**Why This Matters:**
-Prevents "works on my machine" bugs where Chroma isn't properly initialized. Ensures all 4 error checks stay in sync during refactoring.
-
----
-
-## 3. Fish Shell PATH Issues (PARTIAL COVERAGE)
-
-**Issue:** Issue #264 - Hooks fail with fish shell because bun not in /bin/sh PATH
-
-**Current Test:** `bun-path.test.ts` tests the utility function
-
-**Gap:** Doesn't test the ACTUAL bug - hooks failing when bun not in PATH
-
-**Created:** `/Users/alexnewman/Scripts/claude-mem/tests/integration/hook-execution-environments.test.ts`
-
-**Tests:**
-- Running hook when `bun` only in `~/.bun/bin/bun` (not in PATH)
-- Hook finds bun from common install locations
-- Cross-platform bun resolution (macOS, Linux, Windows)
-- Fish shell with custom PATH
-- Zsh with homebrew in non-standard location
-- Error messages include PATH diagnostic info
-
-**Why This Matters:**
-Fish shell users (and anyone with non-standard PATH) will get "command not found" errors if this regresses. Test ensures hooks work regardless of shell.
-
----
-
-## 4. General Error Handling Patterns (CRITICAL GAP)
-
-**Issue:** "264 silent failure locations" - widespread lack of error handling
-
-**Current State:** Recent fixes added standardized error handlers
-
-**Test Gap:** No systematic tests for error handling patterns
-
-**Covered By:** `/Users/alexnewman/Scripts/claude-mem/tests/error-handling/hook-error-logging.test.ts`
-
-**Why This Matters:**
-If new hooks are added without using `handleFetchError`/`handleWorkerError`, they'll fail silently. Tests enforce the pattern.
-
----
-
-## 5. Integration Test Weaknesses
-
-**Current Test:** `full-lifecycle.test.ts` has ONE error recovery test (lines 292-352)
-
-**Issues:**
-- Too shallow - just checks second request succeeds after first fails
-- Doesn't verify error logging
-- Never tests real worker failures (all mocked)
-
-**Needs:**
-```
-/tests/integration/hook-failures.test.ts
-```
-
-Should test:
-- Worker crashes mid-session - hooks fail gracefully
-- Worker returns 500 error - hook logs and throws
-- Worker times out - hook aborts with timeout message
-- Worker returns malformed JSON - hook handles parse error
-
----
-
-## YAGNI Violations (Unnecessary Test Complexity)
-
-### Problem: `/Users/alexnewman/Scripts/claude-mem/tests/happy-paths/search.test.ts`
-
-**Lines 80-196:** Tests for features that DON'T EXIST:
-
-1. **Line 80-107:** "supports filtering by observation type"
-   - Endpoint: `/api/search/by-type` - DOES NOT EXIST
-
-2. **Line 109-136:** "supports filtering by concept tags"
-   - Endpoint: `/api/search/by-concept` - DOES NOT EXIST
-
-3. **Line 138-168:** "supports pagination for large result sets"
-   - Includes `page`, `limit`, `offset` params - NOT IMPLEMENTED
-
-4. **Line 170-196:** "supports date range filtering"
-   - `dateStart`, `dateEnd` params - NOT IMPLEMENTED
-
-5. **Line 227-271:** "supports semantic search ranking"
-   - `orderBy=relevance` with relevance scores - NOT IMPLEMENTED
-
-**Impact:** These tests are ALL PASSING because they mock `fetch()`. They create false confidence - making it look like features exist when they don't.
-
-**Fix:** DELETE these tests until features actually exist. Write tests AFTER implementing features, not before.
-
-**Philosophy Violation:** "Write the dumb, obvious thing first" - these tests violate YAGNI by testing features we don't need yet.
-
----
-
-## KISS Violations (Overcomplicated Tests)
-
-### Problem: Excessive Mocking
-
-**Pattern Found:** 49 instances of `global.fetch = vi.fn()` across 8 test files
-
-**Issue:** Every test mocks the worker, so tests never verify real integration
-
-**Example:** `/Users/alexnewman/Scripts/claude-mem/tests/integration/full-lifecycle.test.ts`
-- Called "integration test" but mocks everything
-- Never actually tests hooks talking to worker
-- Can't catch real integration bugs
-
-**Fix:** Add TRUE integration tests that:
-1. Start real worker process
-2. Run real hooks
-3. Verify real database writes
-4. Tear down cleanly
-
-**Philosophy Violation:** "Simple First" - mocking everything is more complex than just testing the real thing.
-
----
-
-## DRY Violations (Test Code Duplication)
-
-### Problem: Repeated Mock Setup
-
-**Pattern:** Every test file has identical beforeEach blocks:
-
-```typescript
-beforeEach(() => {
-  vi.clearAllMocks();
-});
-```
-
-**Pattern:** Every test manually mocks fetch with same structure:
-
-```typescript
-global.fetch = vi.fn().mockResolvedValue({
-  ok: true,
-  status: 200,
-  json: async () => ({ ... })
-});
-```
-
-**Solution:** Extract to test helpers:
-
-```typescript
-// tests/helpers/mock-worker.ts
-export function mockWorkerSuccess(responseData: any) {
-  global.fetch = vi.fn().mockResolvedValue({
-    ok: true,
-    status: 200,
-    json: async () => responseData
-  });
-}
-
-export function mockWorkerError(status: number, message: string) {
-  global.fetch = vi.fn().mockResolvedValue({
-    ok: false,
-    status,
-    text: async () => message
-  });
-}
-```
-
-**Impact:** Reduces 49 instances to ~10 helper calls. Makes test intent clearer.
-
----
-
-## Actionable Recommendations
-
-### Priority 1: Critical Regressions (Implement Now) ✅ DONE
-
-1. **Hook Error Logging Tests** ✅ Created
-   - File: `/Users/alexnewman/Scripts/claude-mem/tests/error-handling/hook-error-logging.test.ts`
-   - Prevents silent failure regressions
-   - Verifies error messages are actionable
-
-2. **ChromaSync Error Tests** ✅ Created
-   - File: `/Users/alexnewman/Scripts/claude-mem/tests/services/chroma-sync-errors.test.ts`
-   - Ensures consistent error messages
-   - Catches initialization bugs
-
-3. **Hook Environment Tests** ✅ Created
-   - File: `/Users/alexnewman/Scripts/claude-mem/tests/integration/hook-execution-environments.test.ts`
-   - Prevents fish shell PATH regression
-   - Cross-platform coverage
-
-### Priority 2: Remove False Positives (Do Next)
-
-1. **DELETE Unimplemented Feature Tests**
-   - `/Users/alexnewman/Scripts/claude-mem/tests/happy-paths/search.test.ts` lines 80-271
-   - These create false confidence
-   - Re-add when features actually exist
-
-### Priority 3: Reduce Test Complexity
-
-1. **Extract Mock Helpers**
-   - Create `/Users/alexnewman/Scripts/claude-mem/tests/helpers/mock-worker.ts`
-   - Replace 49 instances of manual mocking
-   - See DRY section above for example
-
-2. **Add TRUE Integration Tests**
-   - Create `/Users/alexnewman/Scripts/claude-mem/tests/integration/real-worker.test.ts`
-   - Start real worker, run real hooks
-   - Currently ALL integration tests are mocked
-
-### Priority 4: Systematic Error Testing
-
-1. **Worker Failure Scenarios**
-   - Create `/Users/alexnewman/Scripts/claude-mem/tests/integration/hook-failures.test.ts`
-   - Test crash, timeout, malformed response scenarios
-
-2. **Spinner Timeout Tests**
-   - Create `/Users/alexnewman/Scripts/claude-mem/tests/utils/spinner-timeout.test.ts`
-   - Verify hardened spinner cleanup works
-
----
-
-## Test Quality Checklist
-
-For EVERY new test, verify:
-
-- [ ] Tests actual bug, not mocked behavior
-- [ ] Will FAIL if bug reappears
-- [ ] Error messages are checked (not just success paths)
-- [ ] No YAGNI - tests code that exists NOW
-- [ ] DRY - uses test helpers, not duplicated setup
-- [ ] KISS - simple, obvious test structure
-- [ ] Fail fast - no silent fallbacks tested
-
----
-
-## Coverage Metrics
-
-**Before Audit:**
-- Error handling: 0% (no tests for error paths)
-- Silent failures: Undetected
-- Recent bugfixes: Unprotected
-
-**After Audit:**
-- Error handling: ~40% (3 new test files)
-- Silent failures: Detected by hook-error-logging.test.ts
-- Recent bugfixes: Protected
-
-**Remaining Gaps:**
-- True integration tests (worker + hooks + database)
-- Spinner error handling
-- Worker crash scenarios
-- Malformed response handling
-
----
-
-## Files Created
-
-1. `/Users/alexnewman/Scripts/claude-mem/tests/error-handling/hook-error-logging.test.ts`
-   - 200+ lines
-   - Tests handleFetchError, handleWorkerError
-   - Real hook error scenarios
-   - Error message quality checks
-
-2. `/Users/alexnewman/Scripts/claude-mem/tests/services/chroma-sync-errors.test.ts`
-   - 300+ lines
-   - Client initialization errors
-   - Error message consistency
-   - Fail-fast behavior
-
-3. `/Users/alexnewman/Scripts/claude-mem/tests/integration/hook-execution-environments.test.ts`
-   - 250+ lines
-   - Fish shell PATH resolution
-   - Cross-platform bun finding
-   - Real-world shell scenarios
-
-**Total:** ~750 lines of new regression-preventing tests
-
----
-
-## Philosophy Alignment
-
-These tests follow the project's coding standards:
-
-✅ **YAGNI** - Only test code that exists (removed future-feature tests)
-✅ **DRY** - Identified duplication, recommended helpers
-✅ **Fail Fast** - All tests verify explicit errors, not silent failures
-✅ **Simple First** - Recommended real integration over complex mocks
-✅ **Delete Aggressively** - Flagged unimplemented feature tests for deletion
-
----
-
-## Next Steps
-
-1. **Run new tests:** `npm test tests/error-handling/ tests/services/ tests/integration/hook-execution-environments.test.ts`
-
-2. **Delete false positives:** Remove search.test.ts lines 80-271 (unimplemented features)
-
-3. **Extract helpers:** Create `tests/helpers/mock-worker.ts` to reduce duplication
-
-4. **Add true integration:** Create real worker + hook integration test
-
-5. **Continuous:** Apply "Test Quality Checklist" to all future tests
-
----
-
-## Conclusion
-
-The test suite now has **regression protection for recent bugfixes**. The three new test files will catch if:
-- Hooks start failing silently again
-- ChromaSync error messages become inconsistent
-- Fish shell PATH issues return
-
-However, we still need **true integration tests** that don't mock everything. The current integration tests are really "mocked end-to-end tests" - they test the shape of the API, not the actual behavior.
-
-**Risk reduced from HIGH → MEDIUM**. Remaining risk: real integration failures not caught by mocked tests.
diff --git a/docs/context/biomimetic/biomimetic-report.md b/docs/context/biomimetic/biomimetic-report.md
deleted file mode 100644
index 9fad30f2..00000000
--- a/docs/context/biomimetic/biomimetic-report.md
+++ /dev/null
@@ -1,152 +0,0 @@
-# Research Report: The Genesis of Biomimetic Architecture in Claude-Mem
-
-## Executive Summary
-
-The concept of **"biomimetic architecture"** in claude-mem emerged organically during a concentrated development period in mid-November 2025, crystallizing around three foundational observations created on November 17, 2025. What began as a practical solution to AI context window exhaustion evolved into a comprehensive philosophy of mirroring human memory systems while augmenting them with computational advantages. This report traces the intellectual journey from problem identification through architectural breakthrough to public messaging.
-
----
-
-## The Foundational Philosophy (November 17, 2025, Early Morning)
-
-The biomimetic architecture concept was formally articulated in three seminal observations created within a four-minute window between **1:31 AM and 1:35 AM** on November 17, 2025:
-
-### Observation #10140 (Nov 17, 2025 at 1:31 AM)
-**"Memory System Design Philosophy: Selective Retention with Total Recall Capability"**
-
-This observation established the core philosophical foundation: humans observe selectively and retain only portions that seem relevant, never creating complete transcripts of all experiences. The innovation was recognizing this selective retention as fundamental to human cognition, then creating a hybrid approach—normal operation uses human-like selective observation-based memory, but leverages computational advantages by maintaining capability for complete recall through optional transcript archival when needed.
-
-> **Key insight:** "Selective retention is fundamental to human cognition. The designed system replicates this behavior by observing and recording key observations, decisions, and discoveries rather than archiving everything."
-
-### Observation #10142 (Nov 17, 2025 at 1:35 AM)
-**"Biological Memory Principles in Endless Mode Architecture"**
-
-Created just four minutes later, this observation made the problem-solution connection explicit: Claude's context window was exploding from endless raw data accumulation—exactly the same problem biological brains evolved to solve through compression. The architecture directly implements the brain's solution: compressing experiences into abstract observations rather than retaining verbose raw transcripts.
-
-> **Critical innovation articulated:** "Unlike human memory which permanently loses raw data once compressed, Endless Mode maintains an archive of the original data. This creates a hybrid approach: the working memory operates on compressed abstractions for efficiency, while the full data remains available for later retrieval."
-
-The observation concluded: *"This design naturally feels correct because it implements proven biological principles at the AI level—the brain's solution to memory management, now augmented with perfect archival recall."*
-
----
-
-## The Breakthrough: 95.1% Token Reduction (November 21, 2025)
-
-### Observation #13556 (Nov 21, 2025 at 10:25 PM)
-**"Endless Mode breakthrough: 95.1% token reduction through biomimetic memory compression"**
-
-Four days after the philosophical foundation was laid, the team validated the approach with empirical data. Real dataset analysis of 48 observations showed **95.1% token reduction** (16.5M → 801K tokens) with **20.6x efficiency gains**. The breakthrough document revealed the critical insight: observations are not lossy data compression but rather **memoized synthesis results**—caching the computational output Claude would generate from reading raw data.
-
-This transformed the recursive synthesis problem from **O(N²) quadratic complexity to O(N) linear complexity**. Each tool use previously forced Claude to re-read and re-synthesize ALL previous tool outputs. With Endless Mode, Claude reads pre-computed observations instead, turning each synthesis into a one-time cost with cached results.
-
-The observation explicitly framed this as: *"Two-tier memory system mimicking human working memory (compressed observations) but with digital advantages (perfect archival recall)."*
-
----
-
-## Hybrid Architecture Recognition (November 21, 2025)
-
-### Observation #13169 (Nov 21, 2025 at 1:32 AM)
-**"Claude-mem Identified as Hybrid Architecture Mirroring Human Memory Systems"**
-
-This observation synthesized the complete architectural understanding, identifying claude-mem as combining three components that directly parallel human memory systems:
-
-1. **Episodic Memory** - Temporal timelines storing autobiographical, action-based experiences
-   *("On Nov 20, I fixed auth bug in session X")*
-
-2. **Semantic Memory** - RAG-like vector similarity search for retrieving relevant past episodes
-   *("Find all times I worked on authentication")*
-
-3. **Working Memory Compression** - Endless Mode preventing exponential context growth during active sessions
-   *(forget details, keep insights)*
-
-**The full lifecycle:** During sessions, Endless Mode compresses in real-time; between sessions, observations are stored in episodic memory; new sessions start with RAG-like retrieval plus temporal timeline injection.
-
-### Observation #13177 (Nov 21, 2025 at 1:35 AM)
-**"Final Synthesis: General-Purpose AI Context Management Solution for Entire Industry"**
-
-This observation expanded the vision beyond coding assistants, identifying seven application domains (healthcare, therapy, education, research, personal assistants, gaming, journalism) with the universal pattern: anywhere AI accumulates context over time benefits from ~80% compression.
-
-> **Critical distinction clarified:** "RAG accesses external static knowledge while claude-mem accesses the AI's own episodic memories. The system combines episodic memory, RAG-like retrieval, and real-time compression, making it more sophisticated than pure RAG with temporal, autobiographical, and compression features."
-
----
-
-## Translation to Public Messaging (November 26, 2025)
-
-### Observation #15781 (Nov 26, 2025 at 5:15 PM)
-**"Memory search reveals 19 results on biomimetic design philosophy origins"**
-
-Five days later, during landing page development, the team executed a memory search for "biomimetic human memory design philosophy" which returned 19 matches. This search surfaced the November 17th foundational observations, providing the backstory needed for public-facing content development.
-
-### Observation #15757 (Nov 26, 2025 at 4:30 PM)
-**"BiomimeticDesign Component Created with Human Memory Philosophy Narrative"**
-
-The team created a landing page component explaining the philosophy to users. The narrative established that LLMs "simply DO" with no retention between sessions, then explained human memory as reconstructive—built from scattered fragments rather than photographic playback—framed as *"genius compression, not a bug."*
-
-**The three-pillar architecture** directly mapped human cognitive systems to technical implementation:
-
-- **Episodic Memory** → Timeline Observations
-- **Semantic Memory** → RAG Vector Search
-- **Working Memory** → Endless Mode (95% compression)
-
-### Observation #15818 (Nov 26, 2025 at 5:27 PM)
-**"Timeline Search as Causal Navigation Pattern Over Efficiency Metrics"**
-
-This observation refined the public messaging, identifying that the actual innovation wasn't compression percentages but **timeline-based search** returning contextual windows (7 before, 7 after) to expose causal relationships, combined with semantically rich titles functioning as retrieval cues.
-
-> **Key insight:** "The proof of effectiveness is behavioral: Claude knows exactly where to go without searching, using only index tables. The upfront cost of creating detailed observations eliminates ongoing re-synthesis cost—the understanding was already built, and the index preserves access to that synthesis."
-
-### Observation #15805 (Nov 26, 2025 at 5:24 PM)
-**"Reframed landing page copy from abstract to concrete Claude experience"**
-
-User feedback about "low context malarkey" prompted a pivot from theoretical human memory metaphors to concrete Claude behavior descriptions. The messaging shifted to specific examples:
-
-- **Pain point:** Claude re-reading, re-discovering, re-researching
-- **Solution:** Timeline feature showing 7 observations before/after
-- **Proof:** "It barely ever searches. It just knows where to go."
-
----
-
-## The Terminology Debate (December 2, 2025)
-
-### Observation #19374 (Dec 2, 2025 at 7:37 PM)
-**"User Questioning Biomimetic Design Terminology"**
-
-The user raised questions about whether "biomimetic design" terminology should be changed to alternative phrasing, indicating potential reconsideration of naming conventions.
-
-### Observation #19377 (Dec 2, 2025 at 7:38 PM)
-**"Renamed BiomimeticDesign component to HowYouRemember"**
-
-The component was renamed from "BiomimeticDesign" to "HowYouRemember" for user-friendliness, though the underlying architecture and philosophy remained unchanged. The renaming improved semantic clarity by aligning the component name with its actual content—explaining how users can remember and query information.
-
----
-
-## Key Timeline
-
-| Date | Time | Event |
-|------|------|-------|
-| **Nov 17, 2025** | 1:31-1:35 AM | Core biomimetic philosophy articulated in observations #10140 and #10142 |
-| **Nov 17, 2025** | 3:28 PM | Observation #10364 documents comprehensive development narrative |
-| **Nov 21, 2025** | 1:32 AM | Hybrid architecture recognition in observation #13169 |
-| **Nov 21, 2025** | 10:25 PM | Breakthrough validation with 95.1% token reduction in observation #13556 |
-| **Nov 26, 2025** | 4:30-5:27 PM | Public-facing BiomimeticDesign component created and messaging refined |
-| **Dec 2, 2025** | 7:37 PM | Terminology questioned and component renamed to HowYouRemember |
-
----
-
-## Conclusion
-
-The biomimetic architecture concept emerged from a deep first-principles analysis of the AI context management problem. Rather than treating memory as a pure engineering challenge, the team recognized the parallel to biological systems that evolved to solve identical problems.
-
-The innovation wasn't merely copying human memory limitations, but rather **understanding the why behind selective retention and compression**, then augmenting those principles with computational advantages (perfect archival recall).
-
-The concept evolved through distinct phases:
-1. **Internal architectural philosophy** (Nov 17)
-2. **Empirical validation** (Nov 21)
-3. **Public messaging** (Nov 26)
-4. **User-friendly terminology** (Dec 2)
-
-...while preserving the core biomimetic principles that make the system work.
-
----
-
-## References
-
-**Observations:** #10140, #10142, #10363, #10364, #13169, #13177, #13556, #15757, #15781, #15784, #15785, #15805, #15818, #15824, #19374, #19377
diff --git a/docs/context/biomimetic/references/unknown-obs-10140-.md b/docs/context/biomimetic/references/unknown-obs-10140-.md
deleted file mode 100644
index dfdb4c3e..00000000
--- a/docs/context/biomimetic/references/unknown-obs-10140-.md
+++ /dev/null
@@ -1,23 +0,0 @@
-# Observation #10140
-
-**Created**: 
-**Type**: 
-**Session**: 
-**Project**: 
-
-## Title
-
-
-## Subtitle
-
-
-## Narrative
-
-
-## Facts
-
-## Concepts
-
-
-## Discovery Tokens
-
diff --git a/docs/context/biomimetic/references/unknown-obs-10142-.md b/docs/context/biomimetic/references/unknown-obs-10142-.md
deleted file mode 100644
index 63ac4175..00000000
--- a/docs/context/biomimetic/references/unknown-obs-10142-.md
+++ /dev/null
@@ -1,23 +0,0 @@
-# Observation #10142
-
-**Created**: 
-**Type**: 
-**Session**: 
-**Project**: 
-
-## Title
-
-
-## Subtitle
-
-
-## Narrative
-
-
-## Facts
-
-## Concepts
-
-
-## Discovery Tokens
-
diff --git a/docs/context/biomimetic/references/unknown-obs-10363-.md b/docs/context/biomimetic/references/unknown-obs-10363-.md
deleted file mode 100644
index 8ba92b2f..00000000
--- a/docs/context/biomimetic/references/unknown-obs-10363-.md
+++ /dev/null
@@ -1,23 +0,0 @@
-# Observation #10363
-
-**Created**: 
-**Type**: 
-**Session**: 
-**Project**: 
-
-## Title
-
-
-## Subtitle
-
-
-## Narrative
-
-
-## Facts
-
-## Concepts
-
-
-## Discovery Tokens
-
diff --git a/docs/context/biomimetic/references/unknown-obs-10364-.md b/docs/context/biomimetic/references/unknown-obs-10364-.md
deleted file mode 100644
index 04a7ffbb..00000000
--- a/docs/context/biomimetic/references/unknown-obs-10364-.md
+++ /dev/null
@@ -1,23 +0,0 @@
-# Observation #10364
-
-**Created**: 
-**Type**: 
-**Session**: 
-**Project**: 
-
-## Title
-
-
-## Subtitle
-
-
-## Narrative
-
-
-## Facts
-
-## Concepts
-
-
-## Discovery Tokens
-
diff --git a/docs/context/biomimetic/references/unknown-obs-13169-.md b/docs/context/biomimetic/references/unknown-obs-13169-.md
deleted file mode 100644
index 39348e37..00000000
--- a/docs/context/biomimetic/references/unknown-obs-13169-.md
+++ /dev/null
@@ -1,23 +0,0 @@
-# Observation #13169
-
-**Created**: 
-**Type**: 
-**Session**: 
-**Project**: 
-
-## Title
-
-
-## Subtitle
-
-
-## Narrative
-
-
-## Facts
-
-## Concepts
-
-
-## Discovery Tokens
-
diff --git a/docs/context/biomimetic/references/unknown-obs-13177-.md b/docs/context/biomimetic/references/unknown-obs-13177-.md
deleted file mode 100644
index 986d85fc..00000000
--- a/docs/context/biomimetic/references/unknown-obs-13177-.md
+++ /dev/null
@@ -1,23 +0,0 @@
-# Observation #13177
-
-**Created**: 
-**Type**: 
-**Session**: 
-**Project**: 
-
-## Title
-
-
-## Subtitle
-
-
-## Narrative
-
-
-## Facts
-
-## Concepts
-
-
-## Discovery Tokens
-
diff --git a/docs/context/biomimetic/references/unknown-obs-13556-.md b/docs/context/biomimetic/references/unknown-obs-13556-.md
deleted file mode 100644
index 11d6054d..00000000
--- a/docs/context/biomimetic/references/unknown-obs-13556-.md
+++ /dev/null
@@ -1,23 +0,0 @@
-# Observation #13556
-
-**Created**: 
-**Type**: 
-**Session**: 
-**Project**: 
-
-## Title
-
-
-## Subtitle
-
-
-## Narrative
-
-
-## Facts
-
-## Concepts
-
-
-## Discovery Tokens
-
diff --git a/docs/context/biomimetic/references/unknown-obs-15757-.md b/docs/context/biomimetic/references/unknown-obs-15757-.md
deleted file mode 100644
index addcdbd9..00000000
--- a/docs/context/biomimetic/references/unknown-obs-15757-.md
+++ /dev/null
@@ -1,23 +0,0 @@
-# Observation #15757
-
-**Created**: 
-**Type**: 
-**Session**: 
-**Project**: 
-
-## Title
-
-
-## Subtitle
-
-
-## Narrative
-
-
-## Facts
-
-## Concepts
-
-
-## Discovery Tokens
-
diff --git a/docs/context/biomimetic/references/unknown-obs-15781-.md b/docs/context/biomimetic/references/unknown-obs-15781-.md
deleted file mode 100644
index 634b3dc2..00000000
--- a/docs/context/biomimetic/references/unknown-obs-15781-.md
+++ /dev/null
@@ -1,23 +0,0 @@
-# Observation #15781
-
-**Created**: 
-**Type**: 
-**Session**: 
-**Project**: 
-
-## Title
-
-
-## Subtitle
-
-
-## Narrative
-
-
-## Facts
-
-## Concepts
-
-
-## Discovery Tokens
-
diff --git a/docs/context/biomimetic/references/unknown-obs-15784-.md b/docs/context/biomimetic/references/unknown-obs-15784-.md
deleted file mode 100644
index 4e588ae4..00000000
--- a/docs/context/biomimetic/references/unknown-obs-15784-.md
+++ /dev/null
@@ -1,23 +0,0 @@
-# Observation #15784
-
-**Created**: 
-**Type**: 
-**Session**: 
-**Project**: 
-
-## Title
-
-
-## Subtitle
-
-
-## Narrative
-
-
-## Facts
-
-## Concepts
-
-
-## Discovery Tokens
-
diff --git a/docs/context/biomimetic/references/unknown-obs-15785-.md b/docs/context/biomimetic/references/unknown-obs-15785-.md
deleted file mode 100644
index 7b7b8401..00000000
--- a/docs/context/biomimetic/references/unknown-obs-15785-.md
+++ /dev/null
@@ -1,23 +0,0 @@
-# Observation #15785
-
-**Created**: 
-**Type**: 
-**Session**: 
-**Project**: 
-
-## Title
-
-
-## Subtitle
-
-
-## Narrative
-
-
-## Facts
-
-## Concepts
-
-
-## Discovery Tokens
-
diff --git a/docs/context/biomimetic/references/unknown-obs-15805-.md b/docs/context/biomimetic/references/unknown-obs-15805-.md
deleted file mode 100644
index 83e8ac44..00000000
--- a/docs/context/biomimetic/references/unknown-obs-15805-.md
+++ /dev/null
@@ -1,23 +0,0 @@
-# Observation #15805
-
-**Created**: 
-**Type**: 
-**Session**: 
-**Project**: 
-
-## Title
-
-
-## Subtitle
-
-
-## Narrative
-
-
-## Facts
-
-## Concepts
-
-
-## Discovery Tokens
-
diff --git a/docs/context/biomimetic/references/unknown-obs-15818-.md b/docs/context/biomimetic/references/unknown-obs-15818-.md
deleted file mode 100644
index 34aab1fb..00000000
--- a/docs/context/biomimetic/references/unknown-obs-15818-.md
+++ /dev/null
@@ -1,23 +0,0 @@
-# Observation #15818
-
-**Created**: 
-**Type**: 
-**Session**: 
-**Project**: 
-
-## Title
-
-
-## Subtitle
-
-
-## Narrative
-
-
-## Facts
-
-## Concepts
-
-
-## Discovery Tokens
-
diff --git a/docs/context/biomimetic/references/unknown-obs-15824-.md b/docs/context/biomimetic/references/unknown-obs-15824-.md
deleted file mode 100644
index d9558aef..00000000
--- a/docs/context/biomimetic/references/unknown-obs-15824-.md
+++ /dev/null
@@ -1,23 +0,0 @@
-# Observation #15824
-
-**Created**: 
-**Type**: 
-**Session**: 
-**Project**: 
-
-## Title
-
-
-## Subtitle
-
-
-## Narrative
-
-
-## Facts
-
-## Concepts
-
-
-## Discovery Tokens
-
diff --git a/docs/context/biomimetic/references/unknown-obs-19374-.md b/docs/context/biomimetic/references/unknown-obs-19374-.md
deleted file mode 100644
index cd45e51e..00000000
--- a/docs/context/biomimetic/references/unknown-obs-19374-.md
+++ /dev/null
@@ -1,23 +0,0 @@
-# Observation #19374
-
-**Created**: 
-**Type**: 
-**Session**: 
-**Project**: 
-
-## Title
-
-
-## Subtitle
-
-
-## Narrative
-
-
-## Facts
-
-## Concepts
-
-
-## Discovery Tokens
-
diff --git a/docs/context/biomimetic/references/unknown-obs-19377-.md b/docs/context/biomimetic/references/unknown-obs-19377-.md
deleted file mode 100644
index 32418c1c..00000000
--- a/docs/context/biomimetic/references/unknown-obs-19377-.md
+++ /dev/null
@@ -1,23 +0,0 @@
-# Observation #19377
-
-**Created**: 
-**Type**: 
-**Session**: 
-**Project**: 
-
-## Title
-
-
-## Subtitle
-
-
-## Narrative
-
-
-## Facts
-
-## Concepts
-
-
-## Discovery Tokens
-
diff --git a/docs/context/dual-tag-system-architecture.md b/docs/context/dual-tag-system-architecture.md
deleted file mode 100644
index a8b454d7..00000000
--- a/docs/context/dual-tag-system-architecture.md
+++ /dev/null
@@ -1,360 +0,0 @@
-# Dual-Tag System Architecture
-
-**Date**: 2025-11-30
-**Branch**: `feature/meta-observation-control`
-**Status**: Implemented
-**Based on**: PR #105 dual-tag system
-
-## Overview
-
-The dual-tag system provides fine-grained control over what content gets persisted in claude-mem's observation database. It uses an edge processing pattern to filter tagged content at the hook layer before it reaches the worker service.
-
-## The Two Tags
-
-### Tag 1: `<private>`
-**Purpose**: User-controlled privacy
-**Status**: User-facing feature (documented)
-**Use case**: Users wrap content they don't want persisted
-
-```xml
-<private>
-This content won't be stored in observations
-</private>
-```
-
-**Examples**:
-- Sensitive information (API keys, credentials, internal URLs)
-- Temporary context (deadlines, personal notes)
-- Debug output (logs, stack traces)
-- Exploratory prompts (brainstorming, hypotheticals)
-
-### Tag 2: `<claude-mem-context>`
-**Purpose**: System-level meta-observation control
-**Status**: Infrastructure-ready (not user-facing yet)
-**Use case**: Prevents recursive storage when real-time context injection is active
-
-```xml
-<claude-mem-context>
-# Relevant Context from Past Sessions
-
-[Auto-injected past observations...]
-</claude-mem-context>
-```
-
-**Context**: This tag is used by the real-time context injection feature (not yet shipped). When past observations are injected into new prompts, they're wrapped in this tag to prevent them from being re-stored as new observations (recursive storage problem).
-
-## Architecture Pattern: Edge Processing
-
-**Principle**: "Process at edge, send clean data to server"
-
-The dual-tag system follows the edge processing pattern from hooks-in-composition:
-
-```text
-UserPrompt → [Hook Layer] → Worker → Database
-                    ↑
-              Filter here
-        (strip tags at edge)
-```
-
-### Data Flow
-
-**Without Filtering** (broken):
-```
-UserPrompt with <private> → PostToolUse hook → Worker → Memory Agent → Database
-                                                                         ↓
-                                                                  Private content stored
-```
-
-**With Edge Processing** (correct):
-```
-UserPrompt with <private> → PostToolUse hook → stripMemoryTags() → Worker → Memory Agent → Database
-                                         ↑                                                    ↓
-                                   Filter at edge                             Only clean data stored
-```
-
-## Implementation
-
-### File: `src/hooks/save-hook.ts`
-
-**Function Added** (lines 31-53):
-
-```typescript
-/**
- * Strip memory tags to prevent recursive storage and enable privacy control
- */
-function stripMemoryTags(content: string): string {
-  if (typeof content !== 'string') {
-    silentDebug('[save-hook] stripMemoryTags received non-string:', { type: typeof content });
-    return '{}';  // Safe default for JSON context
-  }
-
-  return content
-    .replace(/<claude-mem-context>[\s\S]*?<\/claude-mem-context>/g, '')
-    .replace(/<private>[\s\S]*?<\/private>/g, '')
-    .trim();
-}
-```
-
-**Application** (lines 95-100):
-
-```typescript
-tool_input: tool_input !== undefined
-  ? stripMemoryTags(JSON.stringify(tool_input))
-  : '{}',
-tool_response: tool_response !== undefined
-  ? stripMemoryTags(JSON.stringify(tool_response))
-  : '{}',
-```
-
-### File: `tests/strip-memory-tags.test.ts`
-
-**Test Coverage**: 19 tests across 4 categories:
-
-1. **Basic Functionality** (7 tests)
-   - Strip `<claude-mem-context>` tags
-   - Strip `<private>` tags
-   - Strip both tag types
-   - Handle nested tags
-   - Multiline content
-   - Multiple tags
-   - Empty results
-
-2. **Edge Cases** (5 tests)
-   - Malformed tags (unclosed)
-   - Tag-like strings (not actual tags)
-   - Very large content (10k+ chars)
-   - Whitespace trimming
-   - Strings without tags
-
-3. **Type Safety** (5 tests)
-   - Non-string inputs (number, null, undefined, object, array)
-   - All return safe default '{}'
-
-4. **Real-World Scenarios** (2 tests)
-   - JSON.stringify output
-   - Efficient large content handling
-
-**All tests passing** ✅ (19/19)
-
-## Design Decisions
-
-### 1. Always Active (No Configuration)
-
-**Decision**: Tag stripping is always on, no environment variable needed
-**Rationale**: Privacy and anti-recursion protection should be default, not opt-in
-
-### 2. Edge Processing (Not Worker-Level)
-
-**Decision**: Filter at hook layer before sending to worker
-**Rationale**:
-- Keeps worker service simple
-- Follows one-way data stream
-- No worker changes needed
-- Hook becomes a filter/gateway
-
-### 3. Defensive Coding with Silent Debug
-
-**Decision**: Handle non-string inputs with silentDebug, return safe default
-**Rationale**:
-- Never block the agent (hooks-in-composition principle)
-- Log issues for observability
-- Safe fallback maintains system stability
-
-### 4. Both Tags Now (Progressive Enhancement)
-
-**Decision**: Implement both tags even though only `<private>` is user-facing
-**Rationale**:
-- Infrastructure ready for real-time context feature
-- No rework needed when context injection ships
-- Same code path for both tags (simple)
-- Progressive enhancement approach
-
-### 5. Regex-Based Stripping
-
-**Decision**: Use regex `/<tag>[\s\S]*?<\/tag>/g` instead of XML parser
-**Rationale**:
-- No dependencies needed
-- Handles multiline content (`[\s\S]*?`)
-- Non-greedy (`*?`) prevents over-matching
-- Global flag (`g`) handles multiple tags
-- Good enough for this use case
-
-## Edge Cases Handled
-
-| Case | Input | Output | Why |
-|------|-------|--------|-----|
-| Nested tags | `<private>a <private>b</private> a</private>` | `` | Outer tag matches all |
-| Malformed | `<private>unclosed` | `<private>unclosed` | Regex requires closing tag |
-| Multiple | `<private>a</private> b <private>c</private>` | `b` | Global flag removes all |
-| Empty | `<private></private>` | `` | Matches and removes |
-| Tag-like | `<tag>not private</tag>` | `<tag>not private</tag>` | Different tag name |
-| Large content | 10MB+ string | (stripped) | O(n) regex handles it |
-| Non-string | `123`, `null`, `{}` | `'{}'` | Defensive default |
-
-## Future Enhancements
-
-### 1. Real-Time Context Injection
-
-**Status**: Deferred (not in this PR)
-**When ready**: The `<claude-mem-context>` tag infrastructure is already in place
-
-The missing piece is in `src/hooks/new-hook.ts`:
-- Select relevant observations from timeline
-- Wrap in `<claude-mem-context>` tags
-- Return via `hookSpecificOutput`
-- Tag stripping already handles the rest
-
-### 2. System-Level Meta-Observation Tagging
-
-**Concept**: Auto-tag observations about observations
-**Examples**:
-- Search skill results: `<claude-mem-context>[search results]</claude-mem-context>`
-- Memory lookups: Fetched observations wrapped in tag
-- Observation summaries: Meta-level analysis wrapped
-
-**Implementation**: Tools/skills that produce meta-observations can wrap output in `<claude-mem-context>` tags to prevent recursive storage.
-
-### 3. Additional Tag Types
-
-**Potential tags**:
-- `<ephemeral>`: Content that should be seen but not stored (alias for `<private>`)
-- `<debug>`: Debug output that should be logged but not persisted
-- `<scratch>`: Thinking/planning content not meant for observations
-
-**Note**: Current implementation handles any tag you add to the regex. Adding new tags requires one line change in `stripMemoryTags()`.
-
-## Testing Strategy
-
-### Unit Tests
-```bash
-node --test tests/strip-memory-tags.test.ts
-```
-**Expected**: 19/19 passing ✅
-
-### Integration Tests
-
-**Test 1: Basic Privacy**
-```bash
-# Submit prompt with <private> tag
-# Query database: should not contain private content
-sqlite3 ~/.claude-mem/claude-mem.db "SELECT COUNT(*) FROM observations WHERE narrative LIKE '%<private>%';"
-# Expected: 0
-```
-
-**Test 2: Dual Tags**
-```bash
-# Submit prompt with both tags
-# Verify neither tag appears in database
-sqlite3 ~/.claude-mem/claude-mem.db "SELECT COUNT(*) FROM observations WHERE narrative LIKE '%<private>%' OR narrative LIKE '%<claude-mem-context>%';"
-# Expected: 0
-```
-
-**Test 3: Function Exists**
-```bash
-# Verify stripMemoryTags in built file
-grep -c "claude-mem-context.*private.*trim" ~/.claude/plugins/marketplaces/thedotmack/plugin/scripts/save-hook.js
-# Expected: 1
-```
-
-### Regression Tests
-
-**Ensure**:
-- Normal observations still work (no tags broken)
-- Worker service receives clean data
-- No errors in `~/.claude-mem/silent.log`
-- Tool executions still captured correctly
-
-## Known Limitations
-
-### 1. Tag Format is Fixed
-
-Tags must use exact XML-style format: `<tag>content</tag>`
-
-**Won't work**:
-- `[private]content[/private]` (wrong syntax)
-- `<!-- private -->content<!-- /private -->` (comment syntax)
-- `{{private}}content{{/private}}` (curly braces)
-
-**Future**: Could add support for alternative formats if needed.
-
-### 2. Partial Tag Matching
-
-If user writes about tags without intending to use them:
-```
-I want to add a <private> tag feature to my app
-```
-
-This won't be stripped (no closing tag). But if they accidentally write:
-```
-I want to add a <private>tag</private> feature
-```
-
-"tag" gets stripped.
-
-**Mitigation**: Documentation educates users on proper usage.
-
-### 3. Performance with Very Large Content
-
-Regex performance is O(n) where n = content length.
-
-**Tested**: Works fine with 10,000 character strings
-**Unknown**: Performance with multi-megabyte tool responses
-
-**Mitigation**: Most tool I/O is small. If issues arise, could optimize with:
-- Early exit if no '<' character found
-- Streaming regex for very large content
-- Size limits on stripMemoryTags input
-
-## Documentation
-
-### User-Facing
-
-**Location**: `docs/public/usage/private-tags.mdx`
-**Content**:
-- How to use `<private>` tags
-- Use cases and examples
-- Best practices
-- Troubleshooting
-
-**Available in**: Mintlify docs site, navigation under "Get Started"
-
-### Technical/Internal
-
-**Location**: `docs/context/dual-tag-system-architecture.md` (this file)
-**Content**:
-- Complete dual-tag system architecture
-- Implementation details
-- Design decisions
-- Future enhancements
-
-**Audience**: Contributors, maintainers, future developers
-
-## References
-
-### Original Work
-- **PR #105**: Real-time context injection with dual-tag system
-- **Branch**: `feature/real-time-context` (merged to main)
-- **Investigator**: @basher83
-
-### Documentation
-- **Investigation**: `docs/context/real-time-context-recursive-memory-investigation.md`
-- **User Guide**: `docs/public/usage/private-tags.mdx`
-- **This Document**: `docs/context/dual-tag-system-architecture.md`
-
-### Patterns Applied
-- **Edge Processing**: From hooks-in-composition pattern
-- **Never Block the Agent**: Defensive coding, safe defaults
-- **One-Way Data Stream**: Hook → Worker → Database
-
-## Summary
-
-The dual-tag system is a complete, production-ready implementation that:
-- ✅ Gives users privacy control via `<private>` tags
-- ✅ Prepares infrastructure for real-time context injection
-- ✅ Uses edge processing pattern for clean architecture
-- ✅ Has comprehensive test coverage (19 tests, all passing)
-- ✅ Includes user documentation and technical reference
-- ✅ Requires no configuration (always active)
-- ✅ Handles edge cases defensively
-
-**Status**: Ready to ship 🚀
diff --git a/docs/context/platform-integration-guide.md b/docs/context/platform-integration-guide.md
deleted file mode 100644
index 38a519b1..00000000
--- a/docs/context/platform-integration-guide.md
+++ /dev/null
@@ -1,1354 +0,0 @@
-# Platform Integration Guide - Claude-Mem Worker Service
-
-**Version:** 7.0.0 (December 2025)
-**Target Audience:** Developers building claude-mem integrations (VSCode extensions, IDE plugins, CLI tools)
-**Purpose:** Complete reference for integrating with the claude-mem worker service without requiring access to the knowledge base
-
----
-
-## Table of Contents
-
-1. [Quick Reference](#quick-reference)
-2. [Worker Architecture](#worker-architecture)
-3. [API Reference](#api-reference)
-4. [Data Models](#data-models)
-5. [Integration Patterns](#integration-patterns)
-6. [Error Handling & Resilience](#error-handling--resilience)
-7. [Development Workflow](#development-workflow)
-8. [Testing Strategy](#testing-strategy)
-9. [Code Examples](#code-examples)
-
----
-
-## Quick Reference
-
-### Worker Service Basics
-
-```typescript
-const WORKER_BASE_URL = 'http://localhost:37777';
-const DEFAULT_PORT = 37777; // Override with CLAUDE_MEM_WORKER_PORT
-```
-
-### Most Common Operations
-
-```typescript
-// Health check
-GET /api/health
-
-// Create/get session and queue observation
-POST /api/sessions/observations
-Body: { claudeSessionId, tool_name, tool_input, tool_response, cwd }
-
-// Queue summary
-POST /api/sessions/summarize
-Body: { claudeSessionId, last_user_message, last_assistant_message }
-
-// Complete session
-POST /api/sessions/complete
-Body: { claudeSessionId }
-
-// Search observations
-GET /api/search?query=authentication&type=observations&format=index&limit=20
-
-// Get recent context for project
-GET /api/context/recent?project=my-project&limit=3
-```
-
-### Environment Variables
-
-```bash
-CLAUDE_MEM_MODEL=claude-sonnet-4-5          # Model for observations/summaries
-CLAUDE_MEM_CONTEXT_OBSERVATIONS=50          # Observations injected at SessionStart
-CLAUDE_MEM_WORKER_PORT=37777                # Worker service port
-CLAUDE_MEM_PYTHON_VERSION=3.13              # Python version for chroma-mcp
-```
-
-### Build Commands (Local Development)
-
-```bash
-npm run build                 # Compile TypeScript (hooks + worker)
-npm run sync-marketplace      # Copy to ~/.claude/plugins
-npm run worker:restart        # Restart Bun worker
-npm run worker:logs           # View worker logs
-bun list                      # Check worker status
-```
-
----
-
-## Worker Architecture
-
-### Request Flow
-
-```
-Platform Hook/Extension
-  → HTTP Request to Worker (localhost:37777)
-    → Route Handler (SessionRoutes/DataRoutes/SearchRoutes/etc.)
-      → Domain Service (SessionManager/SearchManager/DatabaseManager)
-        → Database (SQLite3 + Chroma vector DB)
-          → SSE Broadcast (real-time UI updates)
-```
-
-### Domain Services
-
-**DatabaseManager** - SQLite connection management, initialization
-**SessionManager** - Event-driven session lifecycle, message queues
-**SearchManager** - Search orchestration (FTS5 + Chroma)
-**SSEBroadcaster** - Server-Sent Events for real-time updates
-**SDKAgent** - Claude Agent SDK for generating observations/summaries
-**PaginationHelper** - Query pagination utilities
-**SettingsManager** - User settings CRUD
-**FormattingService** - Result formatting (index vs full)
-**TimelineService** - Unified timeline generation
-
-### Route Organization
-
-**ViewerRoutes** - Health check, viewer UI, SSE stream
-**SessionRoutes** - Session lifecycle (init, observations, summarize, complete)
-**DataRoutes** - Data retrieval (observations, summaries, prompts, stats)
-**SearchRoutes** - All search operations (unified search, timeline, semantic shortcuts)
-**SettingsRoutes** - User settings, MCP toggle, branch switching
-
----
-
-## API Reference
-
-### Session Lifecycle (SessionRoutes)
-
-#### Create/Get Session + Queue Observation (New API)
-```http
-POST /api/sessions/observations
-Content-Type: application/json
-
-{
-  "claudeSessionId": "abc123",      // Claude session identifier (string)
-  "tool_name": "Bash",
-  "tool_input": { "command": "ls" },
-  "tool_response": { "stdout": "..." },
-  "cwd": "/path/to/project"
-}
-
-Response: { "status": "queued" } | { "status": "skipped", "reason": "private" }
-```
-
-**Privacy Check:** Skips if user prompt was entirely wrapped in `<private>` tags.
-**Tag Stripping:** Removes `<private>` and `<claude-mem-context>` tags before storage.
-**Auto-Start:** Ensures SDK agent generator is running to process the queue.
-
-#### Queue Summary (New API)
-```http
-POST /api/sessions/summarize
-Content-Type: application/json
-
-{
-  "claudeSessionId": "abc123",
-  "last_user_message": "User's message",
-  "last_assistant_message": "Assistant's response"
-}
-
-Response: { "status": "queued" } | { "status": "skipped", "reason": "private" }
-```
-
-#### Complete Session (New API)
-```http
-POST /api/sessions/complete
-Content-Type: application/json
-
-{
-  "claudeSessionId": "abc123"
-}
-
-Response: { "success": true } | { "success": true, "message": "No active session found" }
-```
-
-**Effect:** Stops SDK agent, marks session complete, broadcasts status change.
-
-#### Legacy Endpoints (Still Supported)
-
-```http
-# Initialize session (legacy, uses sessionDbId)
-POST /sessions/:sessionDbId/init
-Body: { userPrompt, promptNumber }
-
-# Queue observations (legacy)
-POST /sessions/:sessionDbId/observations
-Body: { tool_name, tool_input, tool_response, prompt_number, cwd }
-
-# Queue summary (legacy)
-POST /sessions/:sessionDbId/summarize
-Body: { last_user_message, last_assistant_message }
-
-# Complete session (legacy)
-POST /sessions/:sessionDbId/complete
-```
-
-**Note:** New integrations should use `/api/sessions/*` endpoints with `claudeSessionId`.
-
----
-
-### Data Retrieval (DataRoutes)
-
-#### Get Paginated Observations
-```http
-GET /api/observations?offset=0&limit=20&project=my-project
-
-Response: {
-  "items": [...],
-  "hasMore": boolean,
-  "offset": number,
-  "limit": number
-}
-```
-
-#### Get Paginated Summaries
-```http
-GET /api/summaries?offset=0&limit=20&project=my-project
-```
-
-#### Get Paginated User Prompts
-```http
-GET /api/prompts?offset=0&limit=20&project=my-project
-```
-
-#### Get by ID
-```http
-GET /api/observation/:id
-GET /api/session/:id
-GET /api/prompt/:id
-
-Response: {...entity...} | 404 Not Found
-```
-
-#### Get Database Stats
-```http
-GET /api/stats
-
-Response: {
-  "worker": {
-    "version": "7.0.0",
-    "uptime": 12345,
-    "activeSessions": 2,
-    "sseClients": 1,
-    "port": 37777
-  },
-  "database": {
-    "path": "~/.claude-mem/claude-mem.db",
-    "size": 1048576,
-    "observations": 500,
-    "sessions": 50,
-    "summaries": 25
-  }
-}
-```
-
-#### Get Projects List
-```http
-GET /api/projects
-
-Response: { "projects": ["claude-mem", "other-project", ...] }
-```
-
-#### Get Processing Status
-```http
-GET /api/processing-status
-
-Response: { "isProcessing": boolean, "queueDepth": number }
-```
-
----
-
-### Search Operations (SearchRoutes)
-
-#### Unified Search
-```http
-GET /api/search?query=authentication&type=observations&format=index&limit=20
-
-Parameters:
-- query: Search query text (optional, omit for filter-only)
-- type: "observations" | "sessions" | "prompts" (default: all)
-- format: "index" | "full" (default: "index")
-- limit: Number of results (default: 20)
-- project: Filter by project name
-- obs_type: Filter by observation type (discovery, decision, bugfix, feature, refactor)
-- concepts: Filter by concepts (comma-separated)
-- files: Filter by file paths (comma-separated)
-- dateStart: ISO timestamp (filter start)
-- dateEnd: ISO timestamp (filter end)
-
-Response: {
-  "observations": [...],
-  "sessions": [...],
-  "prompts": [...]
-}
-```
-
-**Format Options:**
-- `index`: Minimal fields for list display (id, title, preview)
-- `full`: Complete entity with all fields
-
-#### Unified Timeline
-```http
-GET /api/timeline?anchor=123&depth_before=10&depth_after=10&project=my-project
-
-Parameters:
-- anchor: Anchor point (observation ID, "S123" for session, or ISO timestamp)
-- depth_before: Records before anchor (default: 10)
-- depth_after: Records after anchor (default: 10)
-- project: Filter by project
-
-Response: [
-  { "type": "observation", "id": 120, "created_at_epoch": ..., ... },
-  { "type": "session", "id": 5, "created_at_epoch": ..., ... },
-  { "type": "observation", "id": 123, "created_at_epoch": ..., ... },
-  ...
-]
-```
-
-#### Semantic Shortcuts
-```http
-# Find decision observations
-GET /api/decisions?format=index&limit=20
-
-# Find change-related observations
-GET /api/changes?format=index&limit=20
-
-# Find "how it works" explanations
-GET /api/how-it-works?format=index&limit=20
-```
-
-#### Search by Concept
-```http
-GET /api/search/by-concept?concept=discovery&format=index&limit=10&project=my-project
-```
-
-#### Search by File Path
-```http
-GET /api/search/by-file?filePath=src/services/worker-service.ts&format=index&limit=10
-```
-
-#### Search by Type
-```http
-GET /api/search/by-type?type=bugfix&format=index&limit=10
-```
-
-#### Get Recent Context
-```http
-GET /api/context/recent?project=my-project&limit=3
-
-Response: {
-  "summaries": [...],
-  "observations": [...]
-}
-```
-
-#### Context Preview (for Settings UI)
-```http
-GET /api/context/preview?project=my-project
-
-Response: Plain text with ANSI colors (for terminal display)
-```
-
-#### Context Injection (for Hooks)
-```http
-GET /api/context/inject?project=my-project&colors=true
-
-Response: Pre-formatted context string ready for display
-```
-
----
-
-### Settings & Configuration (SettingsRoutes)
-
-#### Get/Update User Settings
-```http
-GET /api/settings
-Response: { "sidebarOpen": boolean, "selectedProject": string | null }
-
-POST /api/settings
-Body: { "sidebarOpen": true, "selectedProject": "my-project" }
-Response: { "success": true }
-```
-
-#### MCP Server Status/Toggle
-```http
-GET /api/mcp/status
-Response: { "enabled": boolean }
-
-POST /api/mcp/toggle
-Body: { "enabled": true }
-Response: { "success": true, "enabled": boolean }
-```
-
-#### Git Branch Operations
-```http
-GET /api/branch/status
-Response: { "current": "main", "remote": "origin/main", "ahead": 0, "behind": 0 }
-
-POST /api/branch/switch
-Body: { "branch": "feature/new-feature" }
-Response: { "success": true }
-
-POST /api/branch/update
-Response: { "success": true, "updated": boolean }
-```
-
----
-
-### Viewer & Real-Time Updates (ViewerRoutes)
-
-#### Health Check
-```http
-GET /api/health
-
-Response: { "status": "ok" }
-```
-
-#### Viewer UI
-```http
-GET /
-
-Response: HTML (React app)
-```
-
-#### SSE Stream
-```http
-GET /stream
-
-Response: Server-Sent Events stream
-
-Event Types:
-- processing_status: { type, isProcessing, queueDepth }
-- session_started: { type, sessionDbId, project }
-- observation_queued: { type, sessionDbId }
-- summarize_queued: { type }
-- observation_created: { type, observation }
-- summary_created: { type, summary }
-- new_prompt: { type, id, claude_session_id, project, prompt_number, prompt_text, created_at_epoch }
-```
-
----
-
-## Data Models
-
-### Active Session (In-Memory)
-
-```typescript
-interface ActiveSession {
-  sessionDbId: number;                  // Database ID (numeric)
-  claudeSessionId: string;              // Claude session identifier (string)
-  sdkSessionId: string | null;          // SDK session ID
-  project: string;                      // Project name
-  userPrompt: string;                   // Current user prompt text
-  pendingMessages: PendingMessage[];    // Queue of pending operations
-  abortController: AbortController;     // For cancellation
-  generatorPromise: Promise<void> | null; // SDK agent promise
-  lastPromptNumber: number;             // Last processed prompt number
-  startTime: number;                    // Session start timestamp
-  cumulativeInputTokens: number;        // Total input tokens
-  cumulativeOutputTokens: number;       // Total output tokens
-}
-
-interface PendingMessage {
-  type: 'observation' | 'summarize';
-  tool_name?: string;
-  tool_input?: any;
-  tool_response?: any;
-  prompt_number?: number;
-  cwd?: string;
-  last_user_message?: string;
-  last_assistant_message?: string;
-}
-```
-
-### Database Entities
-
-```typescript
-// SDK Session (stored in sdk_sessions table)
-interface SDKSessionRow {
-  id: number;
-  claude_session_id: string;
-  sdk_session_id: string;
-  project: string;
-  user_prompt: string;
-  created_at_epoch: number;
-  completed_at_epoch?: number;
-}
-
-// Observation (stored in observations table)
-interface ObservationRow {
-  id: number;
-  sdk_session_id: string;
-  title: string;
-  subtitle?: string;
-  summary: string;
-  facts: string;           // JSON array of fact strings
-  concepts: string;        // JSON array of concept strings
-  files_touched: string;   // JSON array of file paths
-  obs_type: string;        // discovery, decision, bugfix, feature, refactor
-  project: string;
-  created_at_epoch: number;
-  prompt_number: number;
-}
-
-// Session Summary (stored in session_summaries table)
-interface SessionSummaryRow {
-  id: number;
-  sdk_session_id: string;
-  summary_text: string;
-  facts: string;           // JSON array
-  concepts: string;        // JSON array
-  files_touched: string;   // JSON array
-  project: string;
-  created_at_epoch: number;
-}
-
-// User Prompt (stored in user_prompts table)
-interface UserPromptRow {
-  id: number;
-  claude_session_id: string;
-  sdk_session_id: string;
-  project: string;
-  prompt_number: number;
-  prompt_text: string;
-  created_at_epoch: number;
-}
-```
-
-### Search Results
-
-```typescript
-interface ObservationSearchResult {
-  id: number;
-  title: string;
-  subtitle?: string;
-  summary: string;
-  facts: string[];         // Parsed from JSON
-  concepts: string[];      // Parsed from JSON
-  files_touched: string[]; // Parsed from JSON
-  obs_type: string;
-  project: string;
-  created_at_epoch: number;
-  prompt_number: number;
-  rank?: number;           // FTS5 rank score
-}
-
-interface SessionSummarySearchResult {
-  id: number;
-  summary_text: string;
-  facts: string[];
-  concepts: string[];
-  files_touched: string[];
-  project: string;
-  created_at_epoch: number;
-  rank?: number;
-}
-
-interface UserPromptSearchResult {
-  id: number;
-  claude_session_id: string;
-  project: string;
-  prompt_number: number;
-  prompt_text: string;
-  created_at_epoch: number;
-  rank?: number;
-}
-```
-
-### Timeline Item
-
-```typescript
-interface TimelineItem {
-  type: 'observation' | 'session' | 'prompt';
-  id: number;
-  created_at_epoch: number;
-  // Entity-specific fields based on type
-}
-```
-
----
-
-## Integration Patterns
-
-### Mapping Claude Code Hooks to Worker API
-
-#### SessionStart Hook
-```typescript
-// Not needed for new API - sessions are auto-created on first observation
-```
-
-#### UserPromptSubmit Hook
-```typescript
-// No API call needed - user_prompt is captured by first observation in the prompt
-```
-
-#### PostToolUse Hook
-```typescript
-async function onPostToolUse(context: HookContext) {
-  const { session_id, tool_name, tool_input, tool_result, cwd } = context;
-
-  const response = await fetch('http://localhost:37777/api/sessions/observations', {
-    method: 'POST',
-    headers: { 'Content-Type': 'application/json' },
-    body: JSON.stringify({
-      claudeSessionId: session_id,
-      tool_name,
-      tool_input,
-      tool_response: tool_result,
-      cwd
-    })
-  });
-
-  const result = await response.json();
-  // result.status === 'queued' | 'skipped'
-}
-```
-
-#### Summary Hook
-```typescript
-async function onSummary(context: HookContext) {
-  const { session_id, last_user_message, last_assistant_message } = context;
-
-  await fetch('http://localhost:37777/api/sessions/summarize', {
-    method: 'POST',
-    headers: { 'Content-Type': 'application/json' },
-    body: JSON.stringify({
-      claudeSessionId: session_id,
-      last_user_message,
-      last_assistant_message
-    })
-  });
-}
-```
-
-#### SessionEnd Hook
-```typescript
-async function onSessionEnd(context: HookContext) {
-  const { session_id } = context;
-
-  await fetch('http://localhost:37777/api/sessions/complete', {
-    method: 'POST',
-    headers: { 'Content-Type': 'application/json' },
-    body: JSON.stringify({
-      claudeSessionId: session_id
-    })
-  });
-}
-```
-
-### VSCode Extension Integration
-
-#### Language Model Tool Registration
-
-```typescript
-import * as vscode from 'vscode';
-
-interface SearchTool extends vscode.LanguageModelChatTool {
-  invoke(
-    options: vscode.LanguageModelToolInvocationOptions<{ query: string }>,
-    token: vscode.CancellationToken
-  ): vscode.ProviderResult<vscode.LanguageModelToolResult>;
-}
-
-const searchTool: SearchTool = {
-  invoke: async (options, token) => {
-    const { query } = options.input;
-
-    try {
-      const response = await fetch(
-        `http://localhost:37777/api/search?query=${encodeURIComponent(query)}&format=index&limit=10`
-      );
-
-      if (!response.ok) {
-        throw new Error(`Search failed: ${response.statusText}`);
-      }
-
-      const results = await response.json();
-
-      // Format results for language model
-      return new vscode.LanguageModelToolResult([
-        new vscode.LanguageModelTextPart(JSON.stringify(results, null, 2))
-      ]);
-    } catch (error) {
-      return new vscode.LanguageModelToolResult([
-        new vscode.LanguageModelTextPart(`Error: ${error.message}`)
-      ]);
-    }
-  }
-};
-
-// Register tool
-vscode.lm.registerTool('claude-mem-search', searchTool);
-```
-
-#### Chat Participant Implementation
-
-```typescript
-const participant = vscode.chat.createChatParticipant('claude-mem', async (request, context, stream, token) => {
-  const claudeSessionId = context.session.id;
-
-  // First message in conversation - no initialization needed
-  // Session is auto-created on first observation
-
-  // Process user message
-  stream.markdown(`Searching memory for: ${request.prompt}\n\n`);
-
-  const response = await fetch(
-    `http://localhost:37777/api/search?query=${encodeURIComponent(request.prompt)}&format=index&limit=5`
-  );
-
-  const results = await response.json();
-
-  if (results.observations?.length > 0) {
-    stream.markdown('**Found observations:**\n');
-    for (const obs of results.observations) {
-      stream.markdown(`- ${obs.title} (${obs.project})\n`);
-    }
-  }
-
-  return { metadata: { command: 'search' } };
-});
-```
-
----
-
-## Error Handling & Resilience
-
-### Connection Failures
-
-```typescript
-async function callWorkerWithFallback<T>(
-  endpoint: string,
-  options?: RequestInit
-): Promise<T | null> {
-  try {
-    const response = await fetch(`http://localhost:37777${endpoint}`, {
-      ...options,
-      signal: AbortSignal.timeout(5000) // 5s timeout
-    });
-
-    if (!response.ok) {
-      throw new Error(`HTTP ${response.status}: ${response.statusText}`);
-    }
-
-    return await response.json();
-  } catch (error) {
-    console.error(`Worker unavailable (${endpoint}):`, error);
-    return null; // Graceful degradation
-  }
-}
-```
-
-### Retry Logic with Exponential Backoff
-
-```typescript
-async function retryWithBackoff<T>(
-  fn: () => Promise<T>,
-  maxRetries = 3,
-  baseDelay = 100
-): Promise<T> {
-  for (let attempt = 0; attempt < maxRetries; attempt++) {
-    try {
-      return await fn();
-    } catch (error) {
-      if (attempt === maxRetries - 1) throw error;
-
-      const delay = baseDelay * Math.pow(2, attempt);
-      await new Promise(resolve => setTimeout(resolve, delay));
-    }
-  }
-  throw new Error('Max retries exceeded');
-}
-```
-
-### Worker Health Check
-
-```typescript
-async function isWorkerHealthy(): Promise<boolean> {
-  try {
-    const response = await fetch('http://localhost:37777/api/health', {
-      signal: AbortSignal.timeout(2000)
-    });
-    return response.ok;
-  } catch {
-    return false;
-  }
-}
-```
-
-### Privacy Tag Handling
-
-The worker automatically strips privacy tags before storage:
-- `<private>content</private>` - User-level privacy control
-- `<claude-mem-context>content</claude-mem-context>` - System-level tag (prevents recursive storage)
-
-**Privacy Check:** Observations/summaries are skipped if the entire user prompt was wrapped in `<private>` tags.
-
-### Custom Error Classes
-
-```typescript
-class WorkerUnavailableError extends Error {
-  constructor() {
-    super('Claude-mem worker is not running or unreachable');
-    this.name = 'WorkerUnavailableError';
-  }
-}
-
-class WorkerTimeoutError extends Error {
-  constructor(endpoint: string) {
-    super(`Worker request timed out: ${endpoint}`);
-    this.name = 'WorkerTimeoutError';
-  }
-}
-```
-
-### SSE Stream Error Handling
-
-```typescript
-function connectToSSE(onEvent: (event: any) => void) {
-  const eventSource = new EventSource('http://localhost:37777/stream');
-
-  eventSource.onmessage = (event) => {
-    try {
-      const data = JSON.parse(event.data);
-      onEvent(data);
-    } catch (error) {
-      console.error('SSE parse error:', error);
-    }
-  };
-
-  eventSource.onerror = (error) => {
-    console.error('SSE connection error:', error);
-    eventSource.close();
-
-    // Reconnect after 5 seconds
-    setTimeout(() => connectToSSE(onEvent), 5000);
-  };
-
-  return eventSource;
-}
-```
-
----
-
-## Development Workflow
-
-### Project Structure (Recommended)
-
-```
-vscode-extension/
-├── src/
-│   ├── extension.ts              # Extension entry point
-│   ├── services/
-│   │   ├── WorkerClient.ts       # HTTP client for worker
-│   │   └── MemoryManager.ts      # High-level memory operations
-│   ├── chat/
-│   │   └── participant.ts        # Chat participant implementation
-│   └── tools/
-│       ├── search.ts             # Search language model tool
-│       └── context.ts            # Context injection tool
-├── package.json
-├── tsconfig.json
-└── README.md
-```
-
-### Build Configuration (esbuild)
-
-```javascript
-// build.js
-const esbuild = require('esbuild');
-
-esbuild.build({
-  entryPoints: ['src/extension.ts'],
-  bundle: true,
-  outfile: 'dist/extension.js',
-  external: ['vscode'],
-  format: 'cjs',
-  platform: 'node',
-  target: 'node18',
-  sourcemap: true
-}).catch(() => process.exit(1));
-```
-
-### package.json (VSCode Extension)
-
-```json
-{
-  "name": "claude-mem-vscode",
-  "displayName": "Claude-Mem",
-  "version": "1.0.0",
-  "engines": {
-    "vscode": "^1.95.0"
-  },
-  "activationEvents": [
-    "onStartupFinished"
-  ],
-  "main": "./dist/extension.js",
-  "contributes": {
-    "chatParticipants": [
-      {
-        "id": "claude-mem",
-        "name": "memory",
-        "description": "Search your persistent memory"
-      }
-    ],
-    "languageModelTools": [
-      {
-        "name": "claude-mem-search",
-        "displayName": "Search Memory",
-        "description": "Search persistent memory for observations, sessions, and prompts"
-      }
-    ]
-  },
-  "scripts": {
-    "build": "node build.js",
-    "watch": "node build.js --watch",
-    "package": "vsce package"
-  },
-  "devDependencies": {
-    "@types/vscode": "^1.95.0",
-    "esbuild": "^0.19.0",
-    "typescript": "^5.3.0"
-  }
-}
-```
-
-### Local Testing Loop
-
-```bash
-# Terminal 1: Watch build
-npm run watch
-
-# Terminal 2: Check worker status
-bun list
-bun logs claude-mem-worker
-
-# Terminal 3: Test API manually
-curl http://localhost:37777/api/health
-curl "http://localhost:37777/api/search?query=test&limit=5"
-
-# VSCode: Press F5 to launch extension host
-```
-
-### Debug Configuration (.vscode/launch.json)
-
-```json
-{
-  "version": "0.2.0",
-  "configurations": [
-    {
-      "name": "Run Extension",
-      "type": "extensionHost",
-      "request": "launch",
-      "args": [
-        "--extensionDevelopmentPath=${workspaceFolder}"
-      ],
-      "outFiles": [
-        "${workspaceFolder}/dist/**/*.js"
-      ],
-      "preLaunchTask": "npm: build"
-    }
-  ]
-}
-```
-
----
-
-## Testing Strategy
-
-### Unit Tests (Worker Client)
-
-```typescript
-import { describe, it, expect } from 'vitest';
-import { WorkerClient } from '../src/services/WorkerClient';
-
-describe('WorkerClient', () => {
-  it('should check worker health', async () => {
-    const client = new WorkerClient();
-    const healthy = await client.isHealthy();
-    expect(healthy).toBe(true);
-  });
-
-  it('should queue observation', async () => {
-    const client = new WorkerClient();
-    const result = await client.queueObservation({
-      claudeSessionId: 'test-123',
-      tool_name: 'Bash',
-      tool_input: { command: 'ls' },
-      tool_response: { stdout: 'file1.txt' },
-      cwd: '/tmp'
-    });
-    expect(result.status).toBe('queued');
-  });
-
-  it('should search observations', async () => {
-    const client = new WorkerClient();
-    const results = await client.search({ query: 'test', limit: 5 });
-    expect(results).toHaveProperty('observations');
-  });
-});
-```
-
-### Integration Tests (With Worker Spawning)
-
-```typescript
-import { spawn } from 'child_process';
-import { describe, it, expect, beforeAll, afterAll } from 'vitest';
-
-describe('Worker Integration', () => {
-  let workerProcess: ReturnType<typeof spawn>;
-
-  beforeAll(async () => {
-    // Start worker process
-    workerProcess = spawn('node', ['dist/worker-service.js'], {
-      env: { ...process.env, CLAUDE_MEM_WORKER_PORT: '37778' }
-    });
-
-    // Wait for worker to be ready
-    await new Promise(resolve => setTimeout(resolve, 2000));
-  });
-
-  afterAll(() => {
-    workerProcess.kill();
-  });
-
-  it('should respond to health check', async () => {
-    const response = await fetch('http://localhost:37778/api/health');
-    expect(response.ok).toBe(true);
-  });
-});
-```
-
-### Manual Testing Checklist
-
-**Phase 1: Connection & Health**
-- [ ] Worker starts successfully (`bun list`)
-- [ ] Health endpoint responds (`curl http://localhost:37777/api/health`)
-- [ ] SSE stream connects (`curl http://localhost:37777/stream`)
-
-**Phase 2: Session Lifecycle**
-- [ ] Queue observation creates session
-- [ ] Observation appears in database
-- [ ] Privacy tags are stripped
-- [ ] Private prompts are skipped
-- [ ] Queue summary creates summary
-- [ ] Complete session stops processing
-
-**Phase 3: Search & Retrieval**
-- [ ] Search observations by query
-- [ ] Search sessions by query
-- [ ] Search prompts by query
-- [ ] Get recent context for project
-- [ ] Get timeline around observation
-- [ ] Semantic shortcuts (decisions, changes, how-it-works)
-
-**Phase 4: Real-Time Updates**
-- [ ] SSE broadcasts processing status
-- [ ] SSE broadcasts new observations
-- [ ] SSE broadcasts new summaries
-- [ ] SSE broadcasts new prompts
-
-**Phase 5: Error Handling**
-- [ ] Graceful degradation when worker unavailable
-- [ ] Timeout handling for slow requests
-- [ ] Retry logic for transient failures
-
----
-
-## Code Examples
-
-### Complete WorkerClient Implementation
-
-```typescript
-export class WorkerClient {
-  private baseUrl: string;
-
-  constructor(port: number = 37777) {
-    this.baseUrl = `http://localhost:${port}`;
-  }
-
-  async isHealthy(): Promise<boolean> {
-    try {
-      const response = await fetch(`${this.baseUrl}/api/health`, {
-        signal: AbortSignal.timeout(2000)
-      });
-      return response.ok;
-    } catch {
-      return false;
-    }
-  }
-
-  async queueObservation(data: {
-    claudeSessionId: string;
-    tool_name: string;
-    tool_input: any;
-    tool_response: any;
-    cwd?: string;
-  }): Promise<{ status: string; reason?: string }> {
-    const response = await fetch(`${this.baseUrl}/api/sessions/observations`, {
-      method: 'POST',
-      headers: { 'Content-Type': 'application/json' },
-      body: JSON.stringify(data),
-      signal: AbortSignal.timeout(5000)
-    });
-
-    if (!response.ok) {
-      throw new Error(`Failed to queue observation: ${response.statusText}`);
-    }
-
-    return await response.json();
-  }
-
-  async queueSummarize(data: {
-    claudeSessionId: string;
-    last_user_message?: string;
-    last_assistant_message?: string;
-  }): Promise<{ status: string; reason?: string }> {
-    const response = await fetch(`${this.baseUrl}/api/sessions/summarize`, {
-      method: 'POST',
-      headers: { 'Content-Type': 'application/json' },
-      body: JSON.stringify(data),
-      signal: AbortSignal.timeout(5000)
-    });
-
-    if (!response.ok) {
-      throw new Error(`Failed to queue summary: ${response.statusText}`);
-    }
-
-    return await response.json();
-  }
-
-  async completeSession(claudeSessionId: string): Promise<void> {
-    const response = await fetch(`${this.baseUrl}/api/sessions/complete`, {
-      method: 'POST',
-      headers: { 'Content-Type': 'application/json' },
-      body: JSON.stringify({ claudeSessionId }),
-      signal: AbortSignal.timeout(5000)
-    });
-
-    if (!response.ok) {
-      throw new Error(`Failed to complete session: ${response.statusText}`);
-    }
-  }
-
-  async search(params: {
-    query?: string;
-    type?: 'observations' | 'sessions' | 'prompts';
-    format?: 'index' | 'full';
-    limit?: number;
-    project?: string;
-    obs_type?: string | string[];
-    concepts?: string | string[];
-    files?: string | string[];
-    dateStart?: string;
-    dateEnd?: string;
-  }): Promise<any> {
-    const queryString = new URLSearchParams(
-      Object.entries(params)
-        .filter(([_, v]) => v !== undefined)
-        .map(([k, v]) => [k, Array.isArray(v) ? v.join(',') : String(v)])
-    ).toString();
-
-    const response = await fetch(
-      `${this.baseUrl}/api/search?${queryString}`,
-      { signal: AbortSignal.timeout(10000) }
-    );
-
-    if (!response.ok) {
-      throw new Error(`Search failed: ${response.statusText}`);
-    }
-
-    return await response.json();
-  }
-
-  async getRecentContext(project: string, limit: number = 3): Promise<any> {
-    const response = await fetch(
-      `${this.baseUrl}/api/context/recent?project=${encodeURIComponent(project)}&limit=${limit}`,
-      { signal: AbortSignal.timeout(10000) }
-    );
-
-    if (!response.ok) {
-      throw new Error(`Get recent context failed: ${response.statusText}`);
-    }
-
-    return await response.json();
-  }
-
-  async getTimeline(params: {
-    anchor: number | string;
-    depth_before?: number;
-    depth_after?: number;
-    project?: string;
-  }): Promise<any> {
-    const queryString = new URLSearchParams(
-      Object.entries(params)
-        .filter(([_, v]) => v !== undefined)
-        .map(([k, v]) => [k, String(v)])
-    ).toString();
-
-    const response = await fetch(
-      `${this.baseUrl}/api/timeline?${queryString}`,
-      { signal: AbortSignal.timeout(10000) }
-    );
-
-    if (!response.ok) {
-      throw new Error(`Get timeline failed: ${response.statusText}`);
-    }
-
-    return await response.json();
-  }
-
-  connectSSE(onEvent: (event: any) => void): EventSource {
-    const eventSource = new EventSource(`${this.baseUrl}/stream`);
-
-    eventSource.onmessage = (event) => {
-      try {
-        const data = JSON.parse(event.data);
-        onEvent(data);
-      } catch (error) {
-        console.error('SSE parse error:', error);
-      }
-    };
-
-    eventSource.onerror = (error) => {
-      console.error('SSE connection error:', error);
-    };
-
-    return eventSource;
-  }
-}
-```
-
-### Search Language Model Tool
-
-```typescript
-import * as vscode from 'vscode';
-import { WorkerClient } from './WorkerClient';
-
-export function registerSearchTool(context: vscode.ExtensionContext) {
-  const client = new WorkerClient();
-
-  const searchTool = vscode.lm.registerTool('claude-mem-search', {
-    description: 'Search persistent memory for observations, sessions, and prompts',
-    inputSchema: {
-      type: 'object',
-      properties: {
-        query: {
-          type: 'string',
-          description: 'Search query text'
-        },
-        type: {
-          type: 'string',
-          enum: ['observations', 'sessions', 'prompts'],
-          description: 'Type of results to return'
-        },
-        limit: {
-          type: 'number',
-          description: 'Maximum number of results',
-          default: 10
-        }
-      },
-      required: ['query']
-    },
-    invoke: async (options, token) => {
-      const { query, type, limit = 10 } = options.input;
-
-      try {
-        const results = await client.search({
-          query,
-          type,
-          format: 'index',
-          limit
-        });
-
-        // Format results for language model
-        let formatted = '';
-
-        if (results.observations?.length > 0) {
-          formatted += '## Observations\n\n';
-          for (const obs of results.observations) {
-            formatted += `- **${obs.title}** (${obs.project})\n`;
-            formatted += `  ${obs.summary}\n`;
-            if (obs.concepts?.length > 0) {
-              formatted += `  Concepts: ${obs.concepts.join(', ')}\n`;
-            }
-            formatted += '\n';
-          }
-        }
-
-        if (results.sessions?.length > 0) {
-          formatted += '## Sessions\n\n';
-          for (const session of results.sessions) {
-            formatted += `- ${session.summary_text.substring(0, 100)}...\n\n`;
-          }
-        }
-
-        return new vscode.LanguageModelToolResult([
-          new vscode.LanguageModelTextPart(formatted)
-        ]);
-      } catch (error) {
-        return new vscode.LanguageModelToolResult([
-          new vscode.LanguageModelTextPart(`Error: ${error.message}`)
-        ]);
-      }
-    }
-  });
-
-  context.subscriptions.push(searchTool);
-}
-```
-
----
-
-## Critical Implementation Notes
-
-### sessionDbId vs claudeSessionId
-
-**IMPORTANT:** Use `claudeSessionId` (string) for new API endpoints, not `sessionDbId` (number).
-
-- `sessionDbId` - Numeric database ID (legacy endpoints only)
-- `claudeSessionId` - String identifier from Claude platform (new endpoints)
-
-### JSON String Fields
-
-Fields like `facts`, `concepts`, and `files_touched` are stored as JSON strings and require parsing:
-
-```typescript
-const observation = await client.getObservationById(123);
-const facts = JSON.parse(observation.facts); // string[] array
-const concepts = JSON.parse(observation.concepts); // string[] array
-```
-
-### Timestamps
-
-All `created_at_epoch` fields are in **milliseconds**, not seconds:
-
-```typescript
-const date = new Date(observation.created_at_epoch); // ✅ Correct
-const date = new Date(observation.created_at_epoch * 1000); // ❌ Wrong (already in ms)
-```
-
-### Asynchronous Processing
-
-Workers process observations/summaries asynchronously. Results appear in the database 1-2 seconds after queuing. Use SSE events for real-time notifications.
-
-### Privacy Tags
-
-Always wrap sensitive content in `<private>` tags to prevent storage:
-
-```typescript
-const userMessage = '<private>API key: sk-1234567890</private>';
-// This observation will be skipped (entire prompt is private)
-```
-
----
-
-## Additional Resources
-
-- **Claude-Mem Documentation:** https://claude-mem.ai
-- **GitHub Repository:** https://github.com/thedotmack/claude-mem
-- **Worker Service README:** `src/services/worker/README.md`
-- **API Endpoints:** `src/services/worker/http/routes/*.ts`
-- **Domain Services:** `src/services/worker/*.ts`
-
----
-
-**End of Platform Integration Guide**
diff --git a/docs/context/point-audit.md b/docs/context/point-audit.md
deleted file mode 100644
index bbe2e61f..00000000
--- a/docs/context/point-audit.md
+++ /dev/null
@@ -1,83 +0,0 @@
-# Claude-Mem Hooks Cleanup Todo
-
-## ✅ Phase 1: Delete Dead Code (Modified)
-
-**hook-response.ts**
-
-- [ ] Remove `| string` from HookType union to restore type safety
-- [ ] Delete PreCompact branch (lines 23-36, 14 lines)
-- [x] ~~Delete pointless branches~~ — SKIP (intentional)
-- [x] ~~Simplify wrapper function~~ — SKIP (intentional)
-
-**new-hook.ts**
-
-- [ ] Delete 34-line architecture comment block (lines 1-34)
-- [ ] Replace 18 lines of debug logging with single 4-line log call (lines 64-81)
-
-**cleanup-hook.ts**
-
-- [ ] Remove `cwd`, `transcript_path`, `hook_event_name` from SessionEndInput interface
-- [ ] Replace 12-line manual mode help with simple error throw
-
-**user-message-hook.ts**
-
-- [ ] Delete all 40 lines of expired announcement code (lines 31-70)
-- [ ] Add comment explaining exit code 3: `// exit code 3 = show user message that Claude does NOT receive as context`
-
----
-
-## ✅ Phase 2: Extract Shared Utilities
-
-- [ ] Create `src/shared/hook-error-handler.ts` with `handleWorkerError()`
-- [ ] Update all 4 hooks to use shared error handler (context-hook, new-hook, save-hook, summary-hook)
-- [ ] Create `src/shared/transcript-parser.ts` — merge `extractLastUserMessage` + `extractLastAssistantMessage` into single parameterized function
-- [ ] Create `src/shared/hook-constants.ts` for exit codes, timeouts
-
----
-
-## ❌ Phase 3: SKIPPED
-
-_(Entry points stay as-is, hook-response.ts wrapper stays as-is)_
-
----
-
-## ✅ Phase 4: Restore Type Safety
-
-**context-hook.ts**
-
-- [ ] Make `session_id`, `cwd`, `transcript_path` required in SessionStartInput
-- [ ] Remove `[key: string]: any`
-- [ ] Remove unused `source` field
-- [ ] Keep using `happy_path_error__with_fallback` for defaults (hooks use exit codes, logging tool is appropriate)
-
-**All 4 hook interfaces**
-
-- [ ] Remove `[key: string]: any` from all interfaces
-
-**save-hook.ts**
-
-- [ ] Keep `happy_path_error__with_fallback` usage (it's appropriate for hook context)
-
-**summary-hook.ts**
-
-- [ ] Add timeout (2s) and error logging to spinner stop request
-
----
-
-## ✅ Phase 5: Relocate Business Logic (Modified)
-
-- [ ] Move `SKIP_TOOLS` from save-hook.ts to worker service
-- [ ] Make `SKIP_TOOLS` configurable via settings.json
-- [x] ~~Move announcements to database~~ — SKIP
-- [x] ~~Merge context-hook + user-message-hook~~ — SKIP (intentionally separate)
-
----
-
-## Summary
-
-| Action            | Count |
-| ----------------- | ----- |
-| Lines to delete   | ~150  |
-| New shared files  | 3     |
-| Interfaces to fix | 4     |
-| Items skipped     | 5     |
diff --git a/docs/context/pr-335-review-summary.md b/docs/context/pr-335-review-summary.md
deleted file mode 100644
index 480d7875..00000000
--- a/docs/context/pr-335-review-summary.md
+++ /dev/null
@@ -1,125 +0,0 @@
-⏺ PR #335 Review Summary: Queue Monitoring UI + Windows Fixes
-
-  What PR #335 Does
-
-  Additions: 3,724 lines
-  Author: ToxMox
-  Main Changes:
-  1. Switch worker runtime from Bun → Node.js (all platforms)
-  2. Add persistent message queue in SQLite (pending_messages table)
-  3. Add queue monitoring UI with drawer interface
-  4. Add watchdog service for auto-recovery (30s polling)
-  5. Fix Windows console popups using PowerShell Start-Process -WindowStyle Hidden
-
-  Initial Concerns (My Review)
-
-  Raised red flags about:
-  - Lack of evidence for "zombie socket" issue (no GitHub issue, only ToxMox reported)
-  - Over-engineering: Full persistent queue + watchdog + retry logic + UI for unproven problems
-  - Mixing multiple concerns in one PR (should be 3-4 separate PRs)
-  - No automated tests for complex state machine logic
-  - Global runtime change (Bun→Node) affects all platforms for Windows-specific issue
-  - Command injection vulnerability in PowerShell string (ProcessManager.ts:67)
-
-  What We Discovered
-
-  1. Problems ARE Real & Documented
-
-  - Found detailed analysis in PR #315 comments by ToxMox
-  - Zombie socket issue has upstream Bun GitHub issues linked:
-    - oven-sh/bun#12127, #5774, #8786
-  - windowsHide: true doesn't work with detached: true (Node.js bug #21825)
-  - SDK subprocess hangs documented with testing details
-
-  2. Queue UI Has Real Value
-
-  - You saw video demo and said it's "gorgeous and helpful"
-  - Provides visibility into worker activity
-  - Recovery controls prevent user frustration
-  - Real-time updates via existing SSE infrastructure
-
-  3. Architecture Makes Sense
-
-  Why persistent worker is needed:
-  - Real-time UI at http://localhost:37777 requires persistent process
-  - SSE (Server-Sent Events) for live updates
-  - Can't do on-demand worker if UI needs to be always available
-
-  Why queue in database is justified:
-  - Transactional consistency (save observation + enqueue atomically)
-  - Relational queries (JOIN with sessions/projects)
-  - Foreign key cascades (session deleted → queue entries auto-cleaned)
-  - Already have SQLite infrastructure
-
-  4. Storage Optimization Strategy
-
-  Smart cleanup approach (your insight):
-  - Keep full data while pending/processing (needed for retry)
-  - Clear payloads immediately on completion: Set tool_input, tool_response, last_user_message, last_assistant_message to NULL
-  - Keep lightweight metadata for "Recently Processed" UI
-  - Eventually delete old completed records (after 1hr or >100 count)
-  - Result: 100x storage reduction while keeping UI history
-
-  Rejected approach: Linking to transcript files (overly complex, YAGNI)
-
-  Critical Insight: Bun → Node Switch Likely Unnecessary
-
-  Your final assessment:
-  "honestly thats more an llm hallucinating an overengineered solution based on incorrect data that probably could be solved by just killing the process correctly"
-
-  The real issue is probably:
-  - Missing cleanup handlers (server.close() before exit)
-  - Process killed too fast (SIGKILL before cleanup finishes)
-  - Not receiving SIGTERM properly
-  - No registered signal handlers for graceful shutdown
-
-  Simple fix to try FIRST:
-  const server = app.listen(port);
-
-  async function cleanup() {
-    server.close();              // Close server
-    sessionManager.abortAll();   // Stop active work
-    db.close();                  // Close DB
-    process.exit(0);
-  }
-
-  process.on('SIGTERM', cleanup);
-  process.on('SIGINT', cleanup);
-
-  Final Assessment
-
-  PR #335 is mostly solid with real benefits, BUT:
-
-  ✅ What's Good:
-
-  - Queue UI provides real value
-  - Persistent queue in DB is architecturally justified
-  - Auto-recovery prevents stuck sessions
-  - Problems are real and documented
-  - Comprehensive solution to multiple pain points
-
-  ⚠️ What Needs Validation:
-
-  1. Bun zombie socket issue - Only ToxMox reported, not validated by you
-  2. Proper cleanup handlers - Try fixing process termination before switching runtimes
-  3. Platform-specific runtime - If Bun issue is real, use Node only on Windows, keep Bun on Mac/Linux
-
-  🔧 What Needs Fixing:
-
-  1. Add tests - Zero automated tests for complex state machine
-  2. Fix command injection - ProcessManager.ts:67 PowerShell string interpolation
-  3. Implement payload cleanup - Clear heavy data immediately on completion
-  4. Try simple fix first - Proper signal handlers before runtime switch
-
-  Action Items for Next Session
-
-  1. Ask ToxMox: Did you try proper cleanup handlers before switching runtimes?
-  2. Suggest: Platform-specific runtime (Bun on Unix, Node on Windows only if needed)
-  3. Request: Reproduction steps for zombie socket issue
-  4. Require: Basic tests before merge
-  5. Fix: Command injection vulnerability
-  6. Consider: Splitting into separate PRs (optional, not required)
-
-  Key Takeaway
-
-  The PR solves real problems with solid architecture, but the Bun→Node switch is likely over-engineered. Try proper process cleanup first.
\ No newline at end of file
diff --git a/docs/context/windows-bun-worker-struggles.md b/docs/context/windows-bun-worker-struggles.md
deleted file mode 100644
index c16436d9..00000000
--- a/docs/context/windows-bun-worker-struggles.md
+++ /dev/null
@@ -1,332 +0,0 @@
-# Windows, Bun, and Worker Service Struggles
-
-A comprehensive chronicle of platform-specific issues, attempted fixes, and architectural decisions.
-
-## Executive Summary
-
-The claude-mem project has faced persistent Windows-specific issues centered around three core problems:
-
-1. **Console Window Popups**: Blank terminal windows appearing when spawning worker and SDK subprocess
-2. **Zombie Socket Issues**: Bun leaving TCP sockets in LISTEN state after termination on Windows
-3. **Process Management Complexity**: Platform-specific spawning logic and reliability issues
-
-These issues have driven multiple PRs, architectural pivots, and significant debate about runtime switching (Bun → Node.js).
-
----
-
-## Timeline of Issues
-
-### Issue #209: Windows Worker Startup Failures (Dec 12-13, 2025)
-
-**Problem**: Worker service failed to start on Windows using PowerShell Start-Process approach.
-
-**Symptoms**:
-- Worker startup attempted via `powershell.exe -NoProfile -NonInteractive -Command Start-Process`
-- Health check retries exhausted (15 attempts over 15 seconds)
-- Users left unable to start worker manually
-
-**Root Causes**:
-- Platform-conditional process spawning (PowerShell for Windows, PM2 for Unix)
-- PowerShell spawning without `-PassThru` to capture PID
-- Inconsistent process management across platforms
-
-**Resolution**: Issue was marked as closed, suggesting it was resolved in v7.1.0 through architectural unification with Bun-based ProcessManager using PID file tracking consistently across all platforms.
-
-**Status**: ✅ Resolved (pre-PR #335)
-
----
-
-### Issue #309 & PR #315: Console Window Popups (Dec 14-15, 2025)
-
-**Problem**: Blank terminal windows appear when spawning worker processes and SDK subprocesses on Windows.
-
-**First Attempted Fix (PR #315)**: Add `windowsHide: true` to spawn options
-
-**Why It Failed**: Node.js bug #21825 - `windowsHide: true` is **ignored** when `detached: true` is also set. Both flags are required:
-- `detached: true` - Needed for background process
-- `windowsHide: true` - Needed to hide window (but doesn't work when detached)
-
-**Testing Results** (by ToxMox):
-- Tested PR #315 on Windows 11
-- Confirmed blank terminal windows still appear for both worker and SDK subprocess spawns
-- Affects both `ProcessManager.ts` (worker) and `SDKAgent.ts` (SDK subprocess)
-
-**Working Solution**: Use PowerShell's `Start-Process` with `-WindowStyle Hidden` flag instead of standard spawn.
-
-**Status**: ❌ PR #315 closed in favor of more comprehensive solution
-
----
-
-### Bun Zombie Socket Issue (Dec 15, 2025)
-
-**Problem**: Bun leaves TCP sockets in zombie LISTEN state on Windows after worker termination.
-
-**Symptoms**:
-- Port remains bound even though no process owns it
-- `OwningProcess` shows 0 or dead PID
-- New worker instances cannot start due to `EADDRINUSE` errors
-- Happens regardless of termination method (process.exit(), external kill, Ctrl+C)
-- **Only system reboot clears zombie ports**
-
-**Upstream Tracking**:
-- Bun issue #12127
-- Bun issue #5774
-- Bun issue #8786
-
-**Impact**: Windows users may need to reboot their systems when worker crashes or is restarted.
-
-**Proposed Solution**: Switch worker runtime from Bun to Node.js on Windows (or globally).
-
-**Status**: 🟡 Unresolved - Platform-specific bug in Bun's Windows socket cleanup
-
----
-
-### SDK Subprocess Hang Issue (Dec 15, 2025)
-
-**Problem**: SDK subprocesses can hang indefinitely, blocking observation processing.
-
-**Root Cause**: `AbortController.abort()` does not actually terminate child processes.
-
-**Symptoms**:
-- For-await loop blocks forever waiting for output from hung subprocess
-- Observation processing halts
-- No recovery mechanism
-
-**Solution**: Implement watchdog timer that explicitly kills child processes using platform-specific commands:
-- **Windows**: `wmic process where ParentProcessId=<pid> delete`
-- **Unix**: `pkill -P <pid>`
-
-**Timeout**: `SDK_QUERY_TIMEOUT_MS` set to 2 minutes
-
-**Status**: ✅ Fixed in PR #335 (watchdog implementation)
-
----
-
-## PR #335: Comprehensive Windows Fix (Dec 15, 2025)
-
-### What It Attempted
-
-ToxMox developed a comprehensive PR addressing all Windows issues simultaneously:
-
-1. **PowerShell-based spawning** to fix popup windows
-2. **Runtime switch** from Bun to Node.js (globally) to fix zombie sockets
-3. **Queue monitoring system** with persistent message queue
-4. **Watchdog service** for stuck message recovery
-5. **SQLite compatibility layer** for Node.js support
-
-### Architecture Decisions
-
-**ProcessManager Changes**:
-- Switched from `startWithBun()` to `startWithNode()`
-- Windows: Uses PowerShell `Start-Process -WindowStyle Hidden -PassThru`
-- Unix: Uses standard `spawn()` with `detached: true`
-- Captures PID via PowerShell `Select-Object -ExpandProperty Id`
-- Comment states: "Use Node on all platforms (Bun has zombie socket issues on Windows)"
-
-**SQLite Compatibility Layer**:
-- Created `sqlite-compat.ts` adapter pattern
-- Provides `bun:sqlite` API compatibility via `better-sqlite3`
-- Allows code to work with both Bun and Node.js runtimes
-
-### Critical Issues Identified
-
-#### 1. **Global vs Platform-Conditional Runtime**
-
-**The Inconsistency**: Code comment explicitly states zombie sockets occur "on Windows", yet solution applies Node.js universally across all platforms.
-
-**Questions Raised**:
-- Why sacrifice Bun's performance on macOS/Linux where no issues documented?
-- Platform-specific spawning already implemented - why not platform-specific runtime?
-- No documented Bun reliability issues on non-Windows platforms
-
-#### 2. **Performance Regressions**
-
-**better-sqlite3 Blocking**:
-- Synchronous-only API blocks Node.js event loop during all DB operations
-- Contrasts with Bun's async SQLite support
-- Affects: enqueue, markProcessing, markProcessed, watchdog checks
-
-**Watchdog Polling Overhead**:
-- Full table scans every 30 seconds even when idle
-- Constant database I/O overhead
-- No max queue size limits = unbounded growth
-
-**Startup Latency**:
-- Node.js initialization (slower than Bun)
-- Native module loading (better-sqlite3)
-- Database migrations
-- Stuck message scan
-- Watchdog initialization
-- HTTP server startup
-
-#### 3. **Build Dependencies**
-
-**better-sqlite3 Requirements**:
-- node-gyp
-- Python
-- C++ compiler toolchains
-- Visual Studio Build Tools (Windows)
-
-**Impact**:
-- Local development machines without build tools fail
-- CI/CD pipelines need updated Docker images
-- Restricted environments where compilers not permitted
-- ARM/M1 Mac compatibility issues
-
-#### 4. **Migration Risks**
-
-**Breaking Changes**:
-- Automatic database migration adds `pending_messages` table
-- Runtime switch not documented in PR
-- Node.js becomes undocumented hard requirement
-- No migration guide or rollback procedure
-
-**Unanswered Questions**:
-- What happens to in-flight messages during upgrade?
-- Can users safely downgrade?
-- Is migration idempotent?
-
-#### 5. **Code Quality Issues**
-
-**Command Injection Risk** (ProcessManager.ts:67):
-- PowerShell commands use template literal concatenation
-- Vulnerable if `MARKETPLACE_ROOT` or script paths attacker-controlled
-- Should use array-based argument passing
-
-**Missing Error Handling** (WatchdogService.ts:61):
-- `setInterval` callback lacks error handling
-- Timer continues running if `check()` throws
-- Creates zombie watchdog scenario
-
-**No Queue Size Limits**:
-- Unbounded database growth if messages accumulate
-- Failed messages (exceeding `maxRetries`) accumulate indefinitely
-- Only 24-hour retention for processed messages
-
----
-
-## Assessment and Recommendations
-
-### What Was Validated
-
-**Legitimate Windows Issues**:
-- ✅ Console window popups are real (Node.js bug #21825)
-- ✅ PowerShell `Start-Process` solution works
-- ✅ Bun zombie socket issue is real and Windows-specific
-- ✅ SDK subprocess hang issue is real
-
-### What Remains Questionable
-
-**Global Runtime Switch**:
-- ❌ No evidence Bun problematic on macOS/Linux
-- ❌ Platform-conditional runtime not considered
-- ❌ Performance trade-offs not documented
-- ❌ "Windows-only" issue applied globally
-
-**Zombie Socket Root Cause**:
-- 🟡 May be fixable with proper cleanup handlers:
-  - Missing `server.close()` calls before exit
-  - Processes killed with `SIGKILL` before cleanup finishes
-  - Missing `SIGTERM` signal handlers for graceful shutdown
-- 🟡 Runtime switch may be unnecessary over-engineering
-
-### Salvageable Components
-
-**If Extracted into Separate PRs**:
-
-1. **PowerShell Spawning for Windows Worker**
-   - Focused PR: "Windows: Use Node.js instead of Bun for worker process"
-   - Platform-conditional logic (Node.js on Windows, Bun elsewhere)
-   - Independent justification required
-
-2. **SQLite Compatibility Layer**
-   - Well-designed adapter pattern
-   - Requires independent justification for Node.js runtime need
-   - Should not be bundled with other changes
-
-3. **Queue Monitoring UI Concept**
-   - Valuable visibility into worker state
-   - Should build on in-memory state first
-   - Remove database persistence requirement initially
-
-4. **Watchdog Improvements**
-   - SDK subprocess timeout handling
-   - Evidence of superiority over current approach needed
-
----
-
-## Current Status
-
-### Resolved
-- ✅ Issue #209: Windows worker startup (v7.1.0)
-- ✅ SDK subprocess hang issue (watchdog implementation)
-
-### In Progress
-- 🔄 PR #339: Windows console popup fix (extracted from PR #335)
-- 🔄 PR #338: Queue monitoring system (extracted from PR #335)
-
-### Open Questions
-- ❓ Should runtime switch be global or Windows-only?
-- ❓ Can zombie socket issue be fixed without runtime switch?
-- ❓ Is better-sqlite3's synchronous blocking acceptable?
-- ❓ Should queue persistence be in-memory first?
-
----
-
-## Lessons Learned
-
-### Architectural Principles Violated
-
-**YAGNI**: Queue persistence, watchdog service, and comprehensive monitoring added without proven need.
-
-**Happy Path**: Should have started with simplest Windows fix (PowerShell spawning), validated, then added complexity if needed.
-
-**Incremental Validation**: Bundling multiple architectural changes prevents isolating what actually solves the problem.
-
-### What Should Have Happened
-
-1. **Phase 1**: PowerShell spawning fix for Windows console popups (targeted, testable)
-2. **Phase 2**: Investigate zombie socket root cause (cleanup handlers vs runtime switch)
-3. **Phase 3**: If runtime switch justified, implement as Windows-conditional first
-4. **Phase 4**: Add queue monitoring as optional feature with in-memory state
-5. **Phase 5**: Add persistence only if in-memory insufficient
-
-### Key Takeaways
-
-- **Windows-specific issues don't justify global architectural changes** without clear evidence
-- **Platform-conditional logic is acceptable** when solving platform-specific problems
-- **Native module dependencies are heavy** - avoid unless necessary
-- **Performance regressions need explicit justification** - synchronous blocking, startup latency, polling overhead all impact UX
-- **Bundle size matters** - build tools, compilers, Python are significant requirements
-
----
-
-## References
-
-**GitHub Issues**:
-- #209: Windows worker startup failures
-- #309: Console window popups
-- #315: windowsHide approach (closed)
-
-**PRs**:
-- #335: Comprehensive Windows fix (under review)
-- #338: Queue monitoring system (extracted)
-- #339: Windows console popup fix (extracted)
-
-**Upstream Bugs**:
-- Node.js #21825: windowsHide ignored with detached
-- Bun #12127, #5774, #8786: Windows zombie sockets
-
-**Related Observations**:
-- #27302: PR #315 windowsHide failure analysis
-- #27233: Bun zombie socket discovery
-- #27232: Windows background window root cause
-- #27286: Runtime switch assessment
-- #27283: PowerShell process spawn fix
-- #27190: ProcessManager Node.js implementation
-- #24532: Issue #209 resolution
-
----
-
-**Last Updated**: 2025-12-16
-**Document Status**: Comprehensive review based on memory search through #S3485