engrm 0.1.0 → 0.2.0

package/PLAN.md

@@ -1,278 +0,0 @@
-# Implementation Plan — Engrm
-
-## Approach
-
-**Internal tooling first.** We're building this so our dev team can share project context across machines and developers. The public product comes later — first it needs to work for us.
-
-Built from scratch. claude-mem is a reference for how to hook into Claude Code (hooks, MCP registration, observation capture patterns) but no code is shared. This avoids AGPL licensing issues and lets us design the architecture around cross-device team memory from the start.
-
-## Component Architecture
-
-```
-engrm/
-├── src/
-│   ├── server.ts           # MCP protocol handler (entry point)
-│   ├── tools/              # MCP tool implementations
-│   │   ├── search.ts       # search() — hybrid local + remote, project-scoped
-│   │   ├── timeline.ts     # timeline() — chronological context
-│   │   ├── get.ts          # get_observations() — fetch by ID
-│   │   ├── save.ts         # save_observation() — manual save with quality scoring
-│   │   └── pin.ts          # pin_observation() — prevent aging
-│   ├── capture/            # Observation extraction
-│   │   ├── extractor.ts    # Extract observations from tool use
-│   │   ├── scrubber.ts     # Secret/PII scrubbing
-│   │   ├── quality.ts      # Quality scoring (0.0-1.0)
-│   │   └── dedup.ts        # Near-duplicate detection (title similarity)
-│   ├── storage/            # Local storage layer
-│   │   ├── sqlite.ts       # SQLite database (source of truth)
-│   │   ├── migrations.ts   # Schema migrations
-│   │   ├── outbox.ts       # Sync outbox queue
-│   │   └── projects.ts     # Project identity (git remote → canonical ID)
-│   ├── lifecycle/           # Observation lifecycle management
-│   │   ├── aging.ts        # Daily: active → aging after 30 days
-│   │   ├── compaction.ts   # Weekly: aging → archived, generate digests
-│   │   └── purge.ts        # Monthly: delete archived > 12 months
-│   ├── sync/               # Remote sync layer
-│   │   ├── client.ts       # Candengo Vector REST client
-│   │   └── engine.ts       # Sync engine (outbox flush, backfill, archival cleanup)
-│   ├── context/            # Context injection
-│   │   └── inject.ts       # Session start context builder
-│   └── config.ts           # Configuration management
-│
-├── hooks/                  # Claude Code hooks
-│   ├── post-tool-use.sh    # Observation capture
-│   └── stop.sh             # Session summary + sync flush
-│
-├── package.json
-├── tsconfig.json
-├── BRIEF.md
-├── SPEC.md
-├── PLAN.md                 # This file
-└── CLAUDE.md
-```
-
----
-
-## Phase 1: Local MCP Server + Provisioning (Weeks 1-2)
-
-**Goal**: Working MCP server with local SQLite storage, and a self-service provisioning flow so any developer can go from zero to working memory in under 2 minutes.
-
-### 1.1 MCP Server Core
-
-| Task | Description | Effort |
-|---|---|---|
-| Project scaffolding | TypeScript + Bun, MCP SDK, bun:sqlite | S |
-| SQLite schema + migrations | projects, observations, sessions, sync_outbox tables (see SPEC §1-2) | M |
-| Project identity detection | Auto-detect canonical project ID from git remote URL, normalise, store in projects table | M |
-| MCP tool: `save_observation` | Save to local SQLite with project FK, quality score, add to sync outbox | S |
-| MCP tool: `search` | Local SQLite FTS5 search, project-scoped by default, quality-weighted ranking | M |
-| MCP tool: `get_observations` | Fetch by IDs from local SQLite | S |
-| MCP tool: `timeline` | Chronological context around an observation | M |
-| MCP tool: `pin_observation` | Pin/unpin observations to prevent aging | XS |
-| Quality scoring | Score observations at capture time (0.0-1.0) based on type, content signals (see SPEC §2) | M |
-| Secret scrubber | Regex-based scrubbing of API keys, passwords, tokens before storage | M |
-| Relative file paths | Store file paths relative to project root, resolve at capture time | S |
-| Configuration | `~/.engrm/settings.json` — local paths, remote config | S |
-
-### 1.2 Self-Provisioning
-
-| Task | Description | Effort |
-|---|---|---|
-| Engrm landing page | `www.engrm.dev` — product page + signup + install instructions | M |
-| Account provisioning backend | Signup → create mem_accounts row, namespace, provision token | M |
-| Provision API endpoint | `POST /v1/mem/provision` — exchange token for permanent credentials | S |
-| `npx engrm init` | CLI command: redeem token, write settings, register MCP + hooks in Claude Code | M |
-| Team invite flow | Admin creates team → invite URL → member joins with team namespace pre-configured | M |
-| Self-hosted init path | `--url` flag for custom endpoints, `--manual` for air-gapped environments | S |
-
-### 1.3 Provisioning Flow
-
-```
-1. Developer visits www.engrm.dev
-2. Signs up (email or GitHub OAuth)
-3. Backend provisions account + namespace
-4. Page shows personalised install command:
-   npx engrm init --token=cmt_abc123...
-5. Developer runs command in terminal
-6. Plugin exchanges token → gets API key, endpoint, namespace
-7. Plugin writes settings.json, registers MCP server + hooks in Claude Code
-8. Next Claude Code session has memory
-```
-
-For teams: admin creates team at `www.engrm.dev/team`, shares invite link, team members get pre-configured for the shared namespace.
-
-**Deliverable**: A working MCP server that Claude Code can call, with self-service provisioning from candengo.com. Any developer can sign up and be running in under 2 minutes.
-
----
-
-## Phase 2: Claude Code Hooks (Week 3)
-
-**Goal**: Automatic observation capture from Claude Code sessions.
-
-| Task | Description | Effort |
-|---|---|---|
-| PostToolUse hook | Shell script that extracts observations from tool results | L |
-| Stop hook | Session summary generation, sync flush | M |
-| MCP server registration | `.mcp.json` config for Claude Code | XS |
-| Hooks registration | `hooks.json` for Claude Code | XS |
-| Context injection | Inject relevant history on session start (via MCP tool call) | M |
-| Observation quality filtering | Skip trivial tool uses (ls, cat of small files), focus on meaningful work | M |
-
-**Deliverable**: Claude Code automatically captures observations as you work. Session summaries on exit. Relevant history injected on start.
-
-### Observation Extraction Design
-
-This is the hardest problem. What makes a good observation?
-
-**Capture triggers** (PostToolUse):
-- File edits → what changed and why
-- Command execution with errors → what failed and how it was fixed
-- Multiple file reads in sequence → likely investigating something
-- Test runs → pass/fail context
-
-**Skip** (low signal):
-- Simple file reads (single `cat`)
-- `ls`, `pwd`, `git status` and similar navigation
-- Repeated identical tool calls
-
-**Extraction approach**: The hook sends the tool name + result summary to the MCP server. The server decides whether it's worth capturing based on the tool type and content. Quality score is assigned at capture time. Observations are batched per-session and deduplicated (title similarity > 0.8 against last 24h → merge into existing).
-
-### Observation Lifecycle + Deduplication
-
-| Task | Description | Effort |
-|---|---|---|
-| Deduplication on save | Check title similarity against last 24h for same project, merge if > 0.8 | M |
-| Aging job | Daily: move active observations older than 30 days to aging (0.7x search weight) | S |
-| Archival + compaction | Weekly: observations > 90 days grouped by session, summarised into digest | L |
-| Purge job | Monthly: delete archived observations > 12 months (keep digests + pinned) | S |
-| FTS5 index maintenance | Remove archived observations from FTS5 index during compaction | S |
-| Quota check | Count active+aging observations for free tier enforcement | S |
-
-**Why this matters now**: Without lifecycle management, a developer generating ~100 observations/day hits 10K in ~3 months. Search results degrade as old, irrelevant observations pollute rankings. Compaction turns 25 old observations from a debugging session into one useful digest. Aging reduces the weight of stale knowledge. The free tier stays usable because only active+aging observations count toward the 10K limit — compacted observations are free.
-
----
-
-## Phase 3: Cross-Device Sync + Team Memory (Weeks 4-6)
-
-**Goal**: Offline-first sync to Candengo Vector with team support from day one. Work on laptop, continue on desktop. Other developers' observations are searchable too.
-
-Team memory isn't a separate phase — it's the reason we're building this. User identity, attribution, and shared namespaces are built into the sync layer from the start.
-
-### 3.1 Candengo Vector API Prep
-
-| Task | Description | Effort |
-|---|---|---|
-| Metadata filtering on search API | `metadata_filters` param on `/v1/search` — filter by `project_canonical`, `user_id`, etc. | S |
-| Document listing by source_type | `GET /v1/documents?source_type=X` with pagination | S |
-| Document deletion by source_id | `DELETE /v1/documents/{source_id}` — needed for archival/compaction cleanup | S |
-| Device/user ID tracking in metadata | Accept `device_id`, `user_id` in metadata | XS |
-
-### 3.2 Sync Engine
-
-| Task | Description | Effort |
-|---|---|---|
-| Candengo Vector REST client | TypeScript HTTP client for `/v1/ingest`, `/v1/search`, `/v1/ingest/batch`, `/v1/documents/{id}` | M |
-| Fire-and-forget sync | On observation save → attempt immediate push | S |
-| Background sync timer | Every 30s → flush pending outbox items (batch of 50) | S |
-| Startup backfill | On boot → sync observations saved while offline (high-water-mark) | M |
-| Connectivity detection | Skip sync when offline, resume when connected | S |
-| Retry with exponential backoff | Failed syncs retry 30s, 60s, 120s, max 5min | S |
-| Observation → Candengo mapping | Map to ingest format with `project_canonical` in metadata, source_id = `{user}-{device}-obs-{id}` | M |
-| Archival sync | When compaction runs: delete archived source_ids from Vector, ingest digest | M |
-
-### 3.3 Team + Hybrid Search
-
-| Task | Description | Effort |
-|---|---|---|
-| Hybrid search orchestrator | Query local FTS5 + Candengo `/v1/search` in parallel, scoped by `project_canonical` | M |
-| Result merging + deduplication | Merge by source_id, weighted scoring (semantic × quality × lifecycle) | M |
-| Graceful degradation | Candengo unreachable → local-only search (transparent) | S |
-| Device ID generation | Auto-generate stable device ID on first run | XS |
-| User identity + attribution | `user_id` in all observations, "david/laptop" in results | S |
-| Source ID namespacing | `{user_id}-{device_id}-obs-{local_id}` prevents all collisions | S |
-| Visibility controls | `shared` / `personal` / `secret` flags | M |
-| Team search scope | Search own + team observations by default, filtered by `project_canonical` | M |
-| Cross-project search | Support `project: "*"` to search across all projects | S |
-
-**Deliverable**: Full cross-device team sync. Observations from any team member appear on any device within 30 seconds. Works offline, syncs when reconnected. Projects are matched across machines by git remote URL. New developer installs, connects to the shared namespace, and their agent has the full team knowledge base.
-
-### Backfill Strategy
-
-Instead of diffing all IDs on every startup (expensive at scale), use a high-water-mark:
-
-```
-1. Store last_synced_epoch locally
-2. On startup: SELECT * FROM observations WHERE created_at_epoch > last_synced_epoch
-3. Batch push missing observations
-4. Update last_synced_epoch
-```
-
-Simple, efficient, scales to any observation count.
-
----
-
-## Phase 4: Dogfood (Weeks 7-8)
-
-**Goal**: Run it internally on our projects (Candengo, Alchemy, AIMY). Fix what hurts.
-
-| Task | Description | Effort |
-|---|---|---|
-| Team onboarding | Install on all dev machines, shared Candengo Vector namespace | S |
-| Observation quality tuning | Adjust capture filters based on real usage — too noisy? too quiet? | M |
-| Search relevance tuning | Adjust scoring weights based on real queries | M |
-| Bug fixes from dogfooding | Whatever breaks | M |
-| Automated testing | Unit tests, sync integration tests | L |
-| Performance benchmarking | <50ms local search, <200ms remote search | M |
-
----
-
-## Phase 5: Public Launch (Weeks 9-10)
-
-| Task | Description | Effort |
-|---|---|---|
-| One-line installer | `npx engrm install` or similar | M |
-| CLI tool | `engrm status`, `search`, `sync` commands | M |
-| Documentation | Installation, configuration, usage guide | M |
-| GitHub repo (FSL-1.1-ALv2 license) | README, examples, contributing guide, LICENSE file | M |
-| Free tier limits enforcement | Observation count, device count checks against account tier | M |
-| Upgrade flow | In-plugin nudge when approaching limits, link to engrm.dev/upgrade | S |
-
-**Licensing**: Core client released under FSL-1.1-ALv2 (Functional Source License, Fair Source). Source-available — developers can read, modify, and self-host freely. The restriction: nobody can fork it and offer a competing hosted service. Each version converts to Apache 2.0 after 2 years. Sentinel (real-time AI audit) is proprietary, delivered from a separate private repo to paying customers only.
-
----
-
-## Effort Key
-
-| Size | Estimated Effort | Description |
-|---|---|---|
-| XS | < 2 hours | Trivial change, config, or wrapper |
-| S | 2-4 hours | Straightforward implementation |
-| M | 4-8 hours | Moderate complexity, some design decisions |
-| L | 1-2 days | Significant feature, requires careful design |
-
----
-
-## Dependencies & Critical Path
-
-```
-Phase 1 (Local MCP) ──→ Phase 2 (Hooks) ──→ Phase 3 (Sync + Team) ──→ Phase 4 (Dogfood) ──→ Phase 5 (Launch)
-```
-
-**Phase 1+2 are usable standalone** — local-only memory is already valuable.
-**Phase 3 is the whole point** — cross-device team sync is why we're building this.
-**Phase 4 is essential** — dogfooding on our own projects before releasing externally.
-
----
-
-## Risk Register
-
-| Risk | Impact | Likelihood | Mitigation |
-|---|---|---|---|
-| Observation quality too noisy | High | Medium | Quality scoring (0.0-1.0), skip below 0.1, deduplication on save, compaction at 90 days |
-| Observation volume exceeds quota | Medium | High | Lifecycle management: aging → archival → purge. Compaction summarises old sessions into digests. Only active+aging counts toward quota |
-| Project identity mismatch across machines | High | Medium | Canonical ID from normalised git remote URL. Fallback: `.engrm.json` in project root |
-| Search relevance degrades over time | High | Medium | Quality-weighted ranking, lifecycle scoring (aging=0.7x), project scoping, compaction removes noise |
-| Source ID collisions across devices | Medium | High | Source ID = `{user_id}-{device_id}-obs-{local_id}` — unique across all dimensions |
-| MCP protocol breaking changes | High | Low | Pin MCP SDK version, abstract protocol layer |
-| Secret leakage in observations | Critical | Medium | Multi-layer scrubbing, sensitivity classification, relative file paths only |
-| Sync conflicts | Medium | Low | Source ID namespacing — structurally impossible for two users to overwrite each other |

package/SENTINEL.md

@@ -1,293 +0,0 @@
-# Engrm Sentinel — Real-Time AI Audit for Coding Agents
-
-**Status**: Planned (Phase 5)
-**Target Launch**: April 22, 2026 (6 weeks from 2026-03-11)
-**Tier**: Pro + Team (paid upsell feature)
-
-## Executive Summary
-
-Sentinel is a real-time code validation layer that intercepts AI agent tool calls (file writes, edits) **before execution**, retrieves team-specific coding standards from Engrm's vector memory, and routes the diff through a configurable audit LLM for judgment. If the code violates team standards, Sentinel blocks the write and tells the agent exactly what to fix — the agent self-corrects automatically.
-
-No competitor offers this. Every existing AI code review tool (CodeRabbit, Qodo, Greptile, Ellipsis) operates at PR level — **after** code is written. Sentinel operates at the pre-execution level, preventing mistakes before they happen.
-
-## Market Gap
-
-```
-                    Static Standards          Dynamic RAG Standards
-                    ─────────────────         ──────────────────────
-PR-Level Review  │  CodeRabbit ($24)     │   Qodo ($30)
-                 │  Ellipsis ($20)       │   Greptile ($30)
-                 │  Sourcery ($12)       │
-                 │  Copilot ($19-39)     │
-─────────────────┼───────────────────────┼─────────────────────────
-Real-Time        │  decider/claude-hooks │
-Pre-Execution    │  trailofbits config   │   ← ENGRM SENTINEL
-Interception     │  (local-only, no RAG) │     (UNOCCUPIED)
-```
-
-### Competitive Research (March 2026)
-
-| Tool | Pricing | Timing | Custom Standards | RAG/Vector | Agent Hooks |
-|------|---------|--------|-----------------|------------|-------------|
-| CodeRabbit | $0-24/dev/mo | PR-level + IDE inline | Yes (.coderabbit.yml) | No | No |
-| Qodo | $0-30/dev/mo | PR-level + IDE | Yes (auto-generated) | Yes (proprietary) | No |
-| Greptile | $30/dev/mo | PR-level | Learns from PRs | Yes (AST + vector) | No |
-| Ellipsis | ~$20/dev/mo | PR-level | Yes (natural language) | No | No |
-| Cursor Bugbot | Included ($20-40/mo) | PR-level (background) | .cursor/rules | Proprietary | Cursor-only |
-| Copilot Review | $19-39/user/mo | PR-level | Repository rules | Proprietary | Copilot-only |
-| **Engrm Sentinel** | **$15-25/dev/mo** | **Pre-execution** | **Dynamic RAG** | **Hybrid FTS5+vec** | **Any MCP agent** |
-
-### GitHub Reference Implementations
-
-| Repo | Stars | Pattern | What We Learn |
-|------|-------|---------|--------------|
-| disler/claude-code-hooks-mastery | 3.3k | Builder/Validator agents, PostToolUse linting | Builder/Validator separation pattern |
-| trailofbits/claude-code-config | 1.6k | Security blocking hooks, anti-rationalization gate | Stop hook prompt checking for incomplete work |
-| qodo-ai/pr-agent | 10.5k | PR review tools, AGPL | PR compression for large diffs |
-| ChrisWiles/claude-code-showcase | 5.5k | Skills, agents, GitHub Actions | Skill evaluation hook as pattern |
-| decider/claude-hooks | 67 | Static rule enforcement | Hierarchical config (root + dir overrides) |
-| praneybehl/code-review-mcp | 29 | MCP server for multi-provider review | Stateless — no memory, no team sharing |
-
-**Key insight**: Every existing implementation is stateless. None retrieves project-specific standards from vector memory. None syncs findings across a team.
-
-## Architecture
-
-### Flow
-
-```
-Developer working with Claude Code...
-
-Claude tries to write a file
-    │
-    ▼
-PreToolUse(Write|Edit) fires → hooks/sentinel.ts
-    │
-    ├─ 1. SKIP CHECK
-    │     Is sentinel enabled? Is this file in skip_patterns?
-    │
-    ├─ 2. RETRIEVE STANDARDS
-    │     engrm search("auth middleware security")
-    │     → "Decision: all auth must use bcrypt, not MD5"
-    │     → "Bugfix: session tokens were stored unencrypted"
-    │     → "Standard: never log auth credentials"
-    │
-    ├─ 3. AUDIT LLM CALL
-    │     POST base_url/chat/completions
-    │     { model, messages: [system + standards + diff] }
-    │     temperature: 0, max_tokens: 150
-    │
-    ├─ 4a. PASS → exit 0 (Claude proceeds)
-    ├─ 4b. WARN → exit 0 + log observation
-    └─ 4c. BLOCK → exit 2 + stderr reason
-           (Claude receives error, self-corrects, retries)
-    │
-    ▼
-Finding saved as observation → syncs to team → future audits are smarter
-```
-
-### Dashboard → Server → Client Config Push
-
-```
-Dashboard (engrm.dev/sentinel)
-    │ POST /v1/mem/sentinel/config
-    ▼
-Candengo Vector (sync_events, record_type="sentinel_config")
-    │ GET /v1/sync/changes (existing pull loop, every 60s)
-    ▼
-Client (~/.engrm/settings.json → sentinel config merged)
-    │
-    ▼
-PreToolUse hook reads config on each invocation
-```
-
-### Provider Agnostic (OpenAI-Compatible API)
-
-All major LLM providers speak the same `POST /v1/chat/completions` format:
-
-| Provider | Base URL | Models | Cost/1K audits |
-|----------|----------|--------|---------------|
-| OpenAI | api.openai.com/v1 | gpt-4o-mini | ~$0.40 |
-| xAI/Grok | api.x.ai/v1 | grok-3-mini | ~$0.30 |
-| Mistral | api.mistral.ai/v1 | mistral-small | ~$0.20 |
-| Anthropic | via proxy | haiku-4.5 | ~$0.50 |
-| Local vLLM | 192.168.5.5:8000/v1 | devstral-24b | $0 |
-| Ollama | localhost:11434/v1 | llama3-8b | $0 |
-
-One client function, ~40 lines. No provider-specific code.
-
-## Config Schema
-
-```typescript
-interface SentinelConfig {
-  enabled: boolean;
-  mode: "advisory" | "blocking";           // WARN-only vs BLOCK+WARN
-  provider: "openai" | "xai" | "mistral" | "anthropic" | "custom";
-  base_url: string;                        // OpenAI-compatible endpoint
-  model: string;                           // e.g. "gpt-4o-mini"
-  api_key_env?: string;                    // Client-side env var name
-  encrypted_api_key?: string;              // Server-pushed, decrypted client-side
-  match_tools: string[];                   // ["Write", "Edit"] default
-  timeout_ms: number;                      // Max wait (default 8000)
-  skip_patterns: string[];                 // e.g. ["*.test.ts", "*.md"]
-  max_diff_lines: number;                  // Truncate large diffs (default 200)
-}
-```
-
-Stored in `~/.engrm/settings.json` under `sentinel` key. Pushed from dashboard via sync_events.
-
-## Standards
-
-Standards are **observations tagged as audit-relevant**. No separate schema needed.
-
-- Add `"standard"` to the observation type enum
-- Tag with `sentinel-standard` in concepts
-- Standards sync through the existing push/pull pipeline
-- Dashboard provides UI for creating/managing them
-- Every past decision, bugfix, and pattern is a potential standard — just tag it
-
-## Graceful Degradation
-
-Following the sqlite-vec precedent:
-
-| Failure | Behavior |
-|---------|----------|
-| LLM API down/timeout | exit 0 (allow), log warning |
-| No standards found | Skip audit, exit 0 |
-| Config not synced yet | Sentinel disabled by default |
-| API key missing | Skip audit, log once |
-| Free tier user | Sentinel hooks not registered |
-
-## Feedback Loop (The Moat)
-
-```
-Sentinel blocks a write
-  → Claude self-corrects
-  → Corrected code passes
-  → Block + correction saved as observation
-  → Observation syncs to all team members
-  → Future audits retrieve it as context
-  → Sentinel gets smarter over time
-```
-
-Static rules don't learn. Sentinel does. This is the competitive moat.
-
-## Pricing
-
-| Tier | Sentinel | Observations | Price |
-|------|----------|-------------|-------|
-| Free | Not available | 10K, 2 devices | $0 |
-| Pro | Advisory mode, 100 audits/day, own API keys | 50K, unlimited devices | $15/dev/mo |
-| Team | Full blocking + advisory, unlimited, dashboard config push, shared standards, audit heatmap | 100K, unlimited devices | $25/dev/mo |
-
-Users bring their own LLM API keys. Engrm's marginal cost per audit is near-zero (one vector search + config lookup).
-
-## Implementation Plan
-
-### Phase 1: Core Hook + Local Audit (Week 1)
-
-| Task | File | Effort |
-|------|------|--------|
-| Add `SentinelConfig` to config interface | `src/config.ts` | 1h |
-| Add `"standard"` to observation type enum | `src/types.ts` | 30m |
-| Create `src/sentinel/types.ts` | New | 30m |
-| Create `src/sentinel/llm-client.ts` (OpenAI-compatible) | New (~40 lines) | 1h |
-| Create `src/sentinel/prompts.ts` | New | 2h |
-| Create `src/sentinel/audit.ts` (orchestrator) | New | 3h |
-| Create `hooks/sentinel.ts` (PreToolUse hook) | New | 2h |
-| Register sentinel hook in `registerHooks()` | `src/register.ts` | 30m |
-| Tests | `src/sentinel/*.test.ts` | 3h |
-| Integration test (hook → local LLM) | Manual | 2h |
-
-### Phase 2: Dashboard Config Push (Week 2)
-
-| Task | Location | Effort |
-|------|----------|--------|
-| `POST /v1/mem/sentinel/config` endpoint | candengo-vector | 3h |
-| `GET /v1/mem/sentinel/config` endpoint | candengo-vector | 1h |
-| Store config in sync_events (record_type="sentinel_config") | candengo-vector | 2h |
-| Handle sentinel_config in pull loop | `src/sync/pull.ts` | 2h |
-| Dashboard: LLM provider config page | website/mem/sentinel.html | 4h |
-| Dashboard: standards manager (CRUD) | website/mem/sentinel.html | 4h |
-| API key encryption (server→client) | Both | 3h |
-
-### Phase 3: Standards Library + Feedback Loop (Week 3)
-
-| Task | Location | Effort |
-|------|----------|--------|
-| `POST /v1/mem/sentinel/standards` CRUD | candengo-vector | 3h |
-| Standards sync via pull loop | `src/sync/pull.ts` | 2h |
-| Save audit findings as observations | `src/sentinel/audit.ts` | 2h |
-| Dashboard: audit results + heatmap | candengo-vector website | 4h |
-| `engrm sentinel status` CLI | `src/cli.ts` | 1h |
-| `engrm sentinel test` CLI | `src/cli.ts` | 2h |
-
-### Phase 4: Polish + Tier Enforcement (Week 4)
-
-| Task | Effort |
-|------|--------|
-| Rate limiting (100/day pro, unlimited team) | 2h |
-| Tier check on hook registration | 1h |
-| Anti-rationalization gate (Stop hook, from TrailOfBits) | 3h |
-| Skip patterns, file-type filtering | 2h |
-| Docs + onboarding in dashboard | 3h |
-| Performance profiling (target: <3s/audit) | 2h |
-
-### Phase 5: Beta + Launch (Weeks 5-6)
-
-| Task | Effort |
-|------|--------|
-| Internal dogfood (Unimpossible team) | 1 week |
-| Bug fixes from dogfood | Variable |
-| Launch blog post + HN announcement | 1 day |
-| Waitlist conversion emails | 1 day |
-
-## Files to Create
-
-```
-src/sentinel/
-├── types.ts          # SentinelConfig, AuditResult, etc.
-├── llm-client.ts     # OpenAI-compatible API client (~40 lines)
-├── prompts.ts        # System prompt, audit request formatter, response parser
-├── audit.ts          # Orchestrator: search → LLM → decision → save finding
-└── *.test.ts         # Tests
-
-hooks/
-└── sentinel.ts       # PreToolUse hook (follows post-tool-use.ts pattern)
-```
-
-## Files to Modify
-
-```
-src/config.ts         # Add SentinelConfig to Config interface + defaults
-src/register.ts       # Register PreToolUse sentinel hook
-src/sync/pull.ts      # Handle record_type="sentinel_config" | "sentinel_standard"
-src/cli.ts            # Add `engrm sentinel status|test` commands
-```
-
-## Key Design Patterns to Follow
-
-| Pattern | Source | Application |
-|---------|--------|-------------|
-| Silent error handling | hooks/post-tool-use.ts | Never crash; exit 0 on any error |
-| Config merging | src/config.ts | Defaults → disk → sync override |
-| Reentrancy guards | src/sync/engine.ts | Prevent concurrent audits |
-| Graceful degradation | sqlite-vec integration | If unavailable, skip silently |
-| Observation pipeline | src/capture/ | Findings go through same scrub→quality→dedup→save flow |
-
-## References
-
-### Competitors
-- [CodeRabbit](https://www.coderabbit.ai/) — PR-level, $0-24/dev/mo
-- [Qodo](https://www.qodo.ai/) — Best RAG, PR-level, $0-30/dev/mo
-- [Greptile](https://www.greptile.com/) — Learns from PRs, $30/dev/mo
-- [Ellipsis](https://www.ellipsis.dev/) — PR-level, ~$20/dev/mo
-
-### GitHub Repos
-- [disler/claude-code-hooks-mastery](https://github.com/disler/claude-code-hooks-mastery) (3.3k★)
-- [trailofbits/claude-code-config](https://github.com/trailofbits/claude-code-config) (1.6k★)
-- [qodo-ai/pr-agent](https://github.com/qodo-ai/pr-agent) (10.5k★)
-- [praneybehl/code-review-mcp](https://github.com/praneybehl/code-review-mcp)
-
-### Claude Code Docs
-- [Hooks Reference](https://code.claude.com/docs/en/hooks)
-- [Hooks Guide](https://code.claude.com/docs/en/hooks-guide)