k-harness 0.1.0

package/LICENSE

@@ -0,0 +1,21 @@
+MIT License
+
+Copyright (c) 2025 K-Harness Contributors
+
+Permission is hereby granted, free of charge, to any person obtaining a copy
+of this software and associated documentation files (the "Software"), to deal
+in the Software without restriction, including without limitation the rights
+to use, copy, modify, merge, publish, distribute, sublicense, and/or sell
+copies of the Software, and to permit persons to whom the Software is
+furnished to do so, subject to the following conditions:
+
+The above copyright notice and this permission notice shall be included in all
+copies or substantial portions of the Software.
+
+THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR
+IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY,
+FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT. IN NO EVENT SHALL THE
+AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER
+LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING FROM,
+OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS IN THE
+SOFTWARE.

package/README.md

@@ -0,0 +1,105 @@
+# K-Harness
+
+LLM Development Harness — IDE-agnostic rules, skills, and agents that prevent common AI coding failures.
+
+## What It Does
+
+K-Harness installs structured instruction files into your project that guide LLM coding agents (Copilot, Claude, Cursor, Codex, Windsurf) to avoid common mistakes:
+
+- **Iron Laws** — Hard rules the LLM must follow every session (mock sync, type checking, security)
+- **Skills** — Step-by-step procedures for specific tasks (debugging, code review, security checks)
+- **Agents** — Role-based personas (reviewer, sprint manager)
+- **Failure Patterns** — Project-specific failure log that prevents repeat mistakes
+- **State Tracking** — Sprint/Story state so the LLM knows what to work on
+
+## Quick Start
+
+```bash
+npx k-harness init
+```
+
+Select your IDE when prompted. Files are installed into the current directory.
+
+### Non-interactive
+
+```bash
+npx k-harness init --ide vscode
+npx k-harness init --ide claude
+npx k-harness init --ide cursor
+npx k-harness init --ide codex
+npx k-harness init --ide windsurf
+```
+
+### Options
+
+| Flag | Description |
+|------|-------------|
+| `--ide <name>` | Target IDE: `vscode`, `claude`, `cursor`, `codex`, `windsurf` |
+| `--dir <path>` | Target directory (default: current directory) |
+| `--overwrite` | Overwrite existing files |
+
+## Supported IDEs
+
+| IDE | Global Rules | File-Scoped Rules | Skills | Agents |
+|-----|-------------|-------------------|--------|--------|
+| **VS Code Copilot** | `.github/copilot-instructions.md` | `.vscode/instructions/*.instructions.md` | `.github/skills/*/SKILL.md` | `.github/agents/*.agent.md` |
+| **Claude Code** | `CLAUDE.md` | (merged into CLAUDE.md) | `.claude/skills/*/SKILL.md` | (merged into CLAUDE.md) |
+| **Cursor** | `.cursor/rules/core.mdc` | `.cursor/rules/*.mdc` | `.cursor/rules/*.mdc` | `.cursor/rules/*.mdc` |
+| **Codex** | `AGENTS.md` | (merged into AGENTS.md) | `.agents/skills/*/SKILL.md` | (merged into AGENTS.md) |
+| **Windsurf** | `.windsurfrules` | (merged) | (merged) | (merged) |
+
+All IDEs also get `project-state.md`, `failure-patterns.md`, `features.md`, and `project-brief.md` at the project root.
+
+## What Gets Installed
+
+### Rules (always active)
+- **Core Rules** — Architecture enforcement, Iron Laws, completion protocol, concreteness rules
+- **Testing Rules** — Mock synchronization, forbidden patterns (applied to test files)
+- **Backend Rules** — Dependency inversion, type safety, explicit staging (applied to source files)
+
+### Skills (on-demand procedures)
+- **test-integrity** — Verify mock/interface synchronization before committing
+- **security-checklist** — Pre-commit security risk scan
+- **investigate** — 4-phase systematic debugging (evidence → scope → fix → verify)
+
+### Agents (role-based personas)
+- **reviewer** — Code review: architecture, tests, security, failure pattern cross-check
+- **sprint-manager** — Sprint/Story state management, scope drift prevention
+
+### State Files
+- **project-state.md** — Current sprint, stories, and progress tracking
+- **failure-patterns.md** — Template for logging project-specific failure patterns
+
+## After Installation
+
+1. **Edit `project-state.md`** — Set up your first sprint and stories
+2. **Customize global rules** — Add your architecture, type rules, and directory structure
+3. **Log failures** — When an LLM makes a repeated mistake, record it in `failure-patterns.md`
+
+## Design Principles
+
+1. **State Injection** — Project state injected at every session start
+2. **Rigid Workflow** — Hard "do/don't" rules; soft suggestions get ignored by LLMs
+3. **Failure-Driven Rules** — Rules derived only from actual project failures
+4. **Completion Status Protocol** — DONE / BLOCKED / NEEDS_CONTEXT reporting
+5. **Scope Lock** — Escalate before modifying files outside current story scope
+
+## Research & Analysis
+
+```
+docs/
+├── analysis/           # Framework comparisons
+│   ├── comparison.md   # BMAD vs gstack
+│   ├── bmad-deep-dive.md
+│   └── gstack-deep-dive.md
+├── architecture/       # K-Harness design
+│   ├── design-principles.md
+│   ├── file-structure.md
+│   └── skill-spec.md
+└── case-study/
+    └── mcphub-lessons.md
+```
+
+## License
+
+MIT

package/bin/cli.js

@@ -0,0 +1,4 @@
+#!/usr/bin/env node
+
+const { run } = require('../src/init');
+run(process.argv.slice(2));

package/harness/agents/planner.md

@@ -0,0 +1,100 @@
+# Planner
+
+## Role
+
+Feature planning and dependency management.
+Combines PM (what to build), Analytics (what exists), and Architecture (how it connects) into one workflow.
+The Planner is the entry point for new features — use it BEFORE writing code.
+
+## Referenced Skills
+
+- feature-breakdown
+- impact-analysis
+
+## Referenced Files
+
+- project-brief.md — Project vision, goals, and non-goals
+- features.md — Feature registry
+- dependency-map.md
+- project-state.md
+- failure-patterns.md
+
+## Input
+
+One of:
+- **New Feature**: "I want to add [feature description]"
+- **Architecture Query**: "What depends on [module]?" / "Show me the current module map"
+- **Refactor Plan**: "I need to refactor [module/area]"
+
+## Procedure
+
+### For New Feature
+
+1. Read `project-brief.md` to understand project vision, goals, and **non-goals**
+2. **Direction Guard**: Verify the requested feature aligns with the project goals and does NOT fall into non-goals. If it conflicts, warn the user before proceeding.
+3. Read `features.md` to understand what already exists
+4. Read `dependency-map.md` to understand current architecture
+5. Read `project-state.md` for current Sprint context
+6. Identify which existing modules are affected
+7. Identify new modules that need to be created
+8. Run **feature-breakdown** skill to create ordered task list
+9. Run **impact-analysis** skill for each existing module being modified
+10. Check `failure-patterns.md` for relevant past mistakes
+11. Produce implementation plan (see Output Format)
+12. Update `project-state.md` with the new Story
+13. Update `features.md` with the new feature entry
+
+### For Architecture Query
+
+1. Read `dependency-map.md`
+2. Answer the query with specific module names, dependencies, and layer info
+3. If the query reveals missing entries in the map, flag them
+
+### For Refactor Plan
+
+1. Read `dependency-map.md` to map the blast radius
+2. Run **impact-analysis** skill on each module being refactored
+3. Identify safe refactoring order (leaf modules first, core modules last)
+4. Produce refactoring plan with rollback checkpoints
+
+## Output Format
+
+### New Feature Plan
+```markdown
+## Feature: [name]
+**Story**: S[sprint]-[number]
+**Scope**: [modules affected]
+**Risk**: Low | Medium | High
+
+### Architecture Impact
+- New modules: [list]
+- Modified modules: [list]
+- Unchanged dependents that need testing: [list]
+
+### Implementation Plan
+[Output from feature-breakdown skill]
+
+### Risk Notes
+- [Any failure patterns that apply]
+- [Any high-coupling areas to watch]
+
+### Dependency Map Changes
+[Additions/modifications to dependency-map.md]
+```
+
+### Architecture Query Response
+```markdown
+## Module: [name]
+- Layer: [domain | application | infrastructure | presentation]
+- Depends on: [list with reasons]
+- Depended by: [list with reasons]
+- Last changed: [Sprint/Story reference]
+```
+
+## Constraints
+
+- Never skip reading dependency-map.md — the plan is only as good as the map
+- If dependency-map.md is empty or outdated, report this FIRST
+- All plans must include test tasks (no code without tests)
+- If a feature affects 5+ modules, flag as High Risk
+- If the plan exceeds one Sprint's worth of work, suggest splitting into sub-features

package/harness/agents/reviewer.md

@@ -0,0 +1,86 @@
+# Reviewer
+
+## Role
+
+Review code changes before commit or PR for quality, security, and test integrity.
+Finds issues and auto-fixes where safe, escalates where not.
+
+## Referenced Skills
+
+- test-integrity — Mock synchronization verification
+- security-checklist — Security risk inspection
+- impact-analysis — Change blast radius assessment
+
+## Referenced Files
+
+- failure-patterns.md — Project failure patterns
+- project-state.md — Current Story scope
+- dependency-map.md — Module dependency graph
+
+## Procedure
+
+### Input
+
+Changed file list (user-provided or from `git diff --name-only`)
+
+### Steps
+
+**Step 1: Identify Change Scope**
+- Run `git diff --cached --stat` or `git diff --stat` to see changed files
+- Compare against current Story scope in project-state.md
+
+**Step 2: Architecture Rule Check**
+- [ ] No imports from infrastructure in domain layer
+- [ ] No business logic in presentation layer
+- [ ] Constructor parameters match actual source (FP-002)
+
+**Step 3: Test Integrity (test-integrity skill)**
+- [ ] Interface changes have synchronized mocks (FP-001)
+- [ ] New features have tests
+- [ ] Existing tests pass
+
+**Step 4: Security Check (security-checklist skill)**
+- [ ] No credentials, .env, or temp files in staging (FP-004)
+- [ ] No hardcoded API keys or passwords
+- [ ] No injection vulnerabilities (SQL, XSS)
+
+**Step 5: Failure Pattern Cross-Check**
+- Compare current changes against all FP-NNN items in failure-patterns.md
+- Warn if any pattern applies
+
+**Step 6: Feature Registry Check**
+- [ ] If a new feature was added, verify it is registered in features.md (Iron Law #7)
+- [ ] If feature files changed, verify features.md key files are up to date
+- [ ] If tests were added/removed, verify features.md test files column is accurate
+
+**Step 7: Dependency Map Check**
+- [ ] If new modules were added, verify they are registered in dependency-map.md (Iron Law #6)
+- [ ] If module interfaces changed, verify "Depends On" / "Depended By" columns are updated
+- [ ] If module was deleted/renamed, verify dependency-map.md is cleaned up
+- [ ] Run impact-analysis skill if interface changes affect 2+ dependent modules
+
+### Output Format
+
+```
+## Review Result
+
+### Auto-Fixed (AUTO-FIXED)
+- [file:line] description
+
+### Needs User Confirmation (ASK)
+- [file:line] issue → recommended fix
+
+### Passed Items
+- Architecture rules: ✅
+- Test integrity: ✅ / ⚠️ (detail)
+- Security check: ✅ / ❌ (detail)
+- Failure pattern check: ✅ / ⚠️ (FP-NNN)
+
+STATUS: DONE / DONE_WITH_CONCERNS / BLOCKED
+```
+
+## Constraints
+
+- Do not refactor beyond the review scope
+- Auto-apply security fixes but always record them in output
+- Escalate with NEEDS_CONTEXT after 3 uncertain judgments

package/harness/agents/sprint-manager.md

@@ -0,0 +1,73 @@
+# Sprint Manager
+
+## Role
+
+Manage Sprint/Story state, guide development sequence, and prevent scope drift.
+Keeps the LLM focused on the current work item.
+
+## Referenced Files
+
+- project-state.md — Current state (this is the core file)
+- failure-patterns.md — Recurring failure tracking
+
+## Procedure
+
+### Input
+
+User request: "next task", "current status", "story done", "new sprint", "scope check"
+
+### Handlers
+
+**Request: "current status" / "where are we"**
+1. Read project-state.md
+2. Summarize: current Sprint, in-progress Story, completed Stories
+3. Recommend next action
+
+**Request: "story done" / "S{N}-{M} done"**
+1. Update the Story status to `done` in project-state.md
+2. Add completion record to "Recent Changes" section
+3. Guide to next Story if available
+
+**Request: "new story" / "next task"**
+1. Find next `todo` Story in project-state.md
+2. Change its status to `in-progress`
+3. Specify Story scope (related files/directories)
+4. Alert relevant failure-patterns.md items
+
+**Request: "new sprint"**
+1. Check all Stories in current Sprint
+2. Warn if incomplete Stories exist
+3. Confirm new Sprint number and theme (user input)
+4. Update project-state.md
+
+**Scope Check (automatic)**
+- If user requests a file modification outside current Story scope:
+  - "This file is outside the current Story (S{N}-{M}) scope. Proceed?"
+  - Modify only after user approval
+
+### Output Format
+
+```
+## Sprint Status
+
+Sprint: {N} — {theme}
+Progress: {done}/{total} Stories
+
+| ID | Title | Status | Notes |
+|----|-------|--------|-------|
+| S{N}-1 | ... | ✅ done | |
+| S{N}-2 | ... | 🔄 in-progress | ← current |
+| S{N}-3 | ... | ⬜ todo | |
+
+**Next**: S{N}-2 — {description}
+**Scope**: {file/directory list}
+**Watch**: FP-{NNN} applies (description)
+
+STATUS: DONE
+```
+
+## Constraints
+
+- Do not modify code directly — manage state only
+- Only write to project-state.md; read-only for all other files
+- Always confirm with user before modifying scope boundaries

package/harness/backend-rules.md

@@ -0,0 +1,22 @@
+# Backend Code Rules
+
+## Required
+
+- Follow the project's architecture patterns strictly:
+  - Domain layer must not import from infrastructure.
+  - Application layer accesses data only through domain interfaces.
+  - Infrastructure implements domain interfaces.
+  - Presentation handles routing and DTO conversion only. No business logic.
+- Before calling any constructor, read the actual source file to verify parameters. Do not trust memory. (FP-002)
+
+## Forbidden
+
+- Importing infrastructure from domain (dependency inversion violation).
+- `any` type usage — when unavoidable, add `// eslint-disable-next-line` with reason comment.
+- Hardcoding environment variables in code. Use `process.env` with centralized config.
+- `git add .` or `git add -A` — use explicit per-file staging.
+
+## References
+
+- failure-patterns.md FP-002: Type confusion
+- failure-patterns.md FP-004: Unnecessary files committed

package/harness/core-rules.md

@@ -0,0 +1,76 @@
+# Project Instructions
+
+## Architecture
+
+<!-- TODO: Describe your project's architecture here.
+   Example:
+   TypeScript / Express / PostgreSQL
+   Hexagonal Architecture (Port + Adapter)
+-->
+
+## Directory Structure
+
+<!-- TODO: Map your directory structure.
+   Example:
+   src/
+   ├── domain/           # Entities, Repository interfaces
+   ├── application/      # Use Cases
+   ├── infrastructure/   # DB, HTTP adapters
+   ├── presentation/     # Controllers, DTOs
+   └── shared/           # Utils, types, errors
+-->
+
+## Core Type Rules
+
+<!-- TODO: Document type decisions that LLMs frequently get wrong.
+   Example:
+   - `ServerType` is a union type ("stdio" | "sse"), NOT an enum.
+   - `UserRole` is a union type ("admin" | "user"), NOT an enum.
+-->
+
+## Iron Laws
+
+1. **Mock Sync**: When you modify a repository/service interface, update corresponding mocks in the same commit.
+2. **Type Check**: Before calling a constructor or factory, read the actual source file to verify parameters. Do not rely on memory.
+3. **Scope Compliance**: Do not modify files outside the current Story scope (see project-state.md) without reporting first.
+4. **Security**: Never include credentials, passwords, or API keys in code or commits.
+5. **3-Failure Stop**: If the same approach fails 3 times, stop and report to the user.
+6. **Dependency Map**: When adding or modifying a module, update dependency-map.md in the same commit. Register new modules, update relationship columns.
+7. **Feature Registry**: When adding a new feature, register it in features.md in the same commit. Include key files and test files.
+8. **Session Handoff**: Before ending a chat session, update project-state.md Quick Summary. Never leave the project in an undocumented state.
+
+## Test Rules
+
+- New feature = New test. Do not commit feature code without tests.
+- Test command: `npm test` <!-- TODO: customize -->
+- Mock location: `tests/__mocks__/` <!-- TODO: customize -->
+
+## Completion Status Protocol
+
+Report completion using one of:
+- **DONE**: All steps completed. Present evidence (test results, file list, etc).
+- **DONE_WITH_CONCERNS**: Completed but with concerns. List each concern.
+- **BLOCKED**: Cannot proceed. Describe the cause and what was tried.
+- **NEEDS_CONTEXT**: Need more information. Describe exactly what is needed.
+
+## Concreteness Rules
+
+- When modifying files, specify exact paths and line numbers.
+- When tests fail, quote the test name and error message.
+- When type errors occur, specify expected type and actual type.
+
+## New Session Bootstrap
+
+When starting a NEW chat session, read these files in order before doing any work:
+1. `project-state.md` — Quick Summary tells you where we left off
+2. `features.md` — What features exist in this project
+3. `failure-patterns.md` — What mistakes to avoid
+4. `project-brief.md` — Project vision, goals, and non-goals
+
+## References
+
+- project-brief.md — Project vision, goals, non-goals (the "why")
+- features.md — Feature registry (the "what")
+- project-state.md — Sprint/Story tracking, module registry (the "where")
+- dependency-map.md — Module dependency graph (the "how")
+- failure-patterns.md — Log of known failure patterns (the "watch out")

package/harness/dependency-map.md

@@ -0,0 +1,44 @@
+# Dependency Map
+
+A living document of module relationships. Update whenever modules are added or modified.
+
+## Module Registry
+
+| Module | Layer | Purpose | Depends On | Depended By |
+|--------|-------|---------|------------|-------------|
+<!-- Example:
+| auth       | domain        | User authentication    | -              | api, admin    |
+| api        | presentation  | REST endpoints         | auth, services | frontend      |
+| services   | application   | Business logic         | auth, database | api           |
+| database   | infrastructure| Data persistence       | -              | services      |
+-->
+
+## Dependency Rules
+
+- **No circular dependencies**: If A depends on B, B must not depend on A.
+- **Layer direction**: domain → application → infrastructure/presentation (never reverse).
+- **Interface boundaries**: Modules communicate through interfaces, not concrete implementations.
+- **New module = new row**: Every new module must be registered here before implementation.
+
+## Change Impact Quick Reference
+
+When modifying a module:
+
+1. Find the module row above
+2. Check the **Depended By** column — these modules may break
+3. For each dependent module:
+   - Check if the change affects the public interface
+   - Update tests and mocks for all affected dependents
+4. Record the change in project-state.md
+
+## Interface Change Log
+
+<!-- Record interface changes as they happen.
+   Format:
+   | Date | Module | Change | Affected Modules | Status |
+   |------|--------|--------|------------------|--------|
+   | 2026-04-01 | auth | Added `resetPassword()` | api, admin | Updated |
+-->
+
+| Date | Module | Change | Affected Modules | Status |
+|------|--------|--------|------------------|--------|

package/harness/failure-patterns.md

@@ -0,0 +1,48 @@
+# Failure Patterns
+
+Record only actual failures from this project. No theories or assumptions.
+Keep resolved patterns for regression prevention.
+
+---
+
+## FP-001: Mock not updated when interface changed
+
+- **Occurred**: <!-- Sprint/Story where this happened -->
+- **Frequency**: 0
+- **Cause**: LLM treated interface change and mock update as separate tasks. Added method to interface but forgot to update the mock, causing test failures.
+- **Prevention**: Update mock in the same commit as the interface change.
+- **Applied in**: testing rules, test-integrity skill, reviewer agent
+- **Status**: Template — activate when first occurrence is logged
+
+---
+
+## FP-002: Type confusion (enum vs union, wrong parameter count)
+
+- **Occurred**: <!-- Sprint/Story where this happened -->
+- **Frequency**: 0
+- **Cause**: LLM does not retain type information across sessions. Used enum syntax for union types or called constructors with wrong parameter count.
+- **Prevention**: Document core types in global instructions. Read source file before calling constructors.
+- **Applied in**: global instructions, backend rules
+- **Status**: Template — activate when first occurrence is logged
+
+---
+
+## FP-003: Scope drift / ignoring instructions
+
+- **Occurred**: <!-- Sprint/Story where this happened -->
+- **Frequency**: 0
+- **Cause**: LLM lost track of current scope in large workflows. Skipped "report and wait for approval" steps.
+- **Prevention**: Track current Story in project-state.md. Sprint manager agent detects scope violations.
+- **Applied in**: sprint-manager agent, global instructions
+- **Status**: Template — activate when first occurrence is logged
+
+---
+
+## FP-004: Dangerous file committed
+
+- **Occurred**: <!-- Sprint/Story where this happened -->
+- **Frequency**: 0
+- **Cause**: LLM created temp files during work, then ran `git add .` which staged credentials or debug artifacts.
+- **Prevention**: Ban `git add .`. Run security-checklist skill before commits. Reviewer agent inspects staging area.
+- **Applied in**: security-checklist skill, reviewer agent, backend rules
+- **Status**: Template — activate when first occurrence is logged

package/harness/features.md

@@ -0,0 +1,38 @@
+# Feature Registry
+
+A living document of all features in this project. Update whenever features are added, modified, or deprecated.
+This is LLM's map to understand "what exists" — without this, features get forgotten as the project grows.
+
+## Feature List
+
+| Feature | Status | Key Files | Test Files | Owner |
+|---------|--------|-----------|------------|-------|
+<!-- Example:
+| User Auth       | ✅ done   | src/auth/login.ts, src/auth/jwt.ts     | tests/auth/login.test.ts      | - |
+| MCP Routing     | 🔧 active | src/router/index.ts, src/router/mcp.ts | tests/router/mcp.test.ts      | - |
+| Admin Dashboard | ⬜ planned | -                                       | -                             | - |
+| Legacy REST API | ❌ dropped | -                                       | -                             | - |
+-->
+
+## Status Legend
+
+- ✅ **done** — Feature complete with tests passing
+- 🔧 **active** — Currently being developed
+- ⬜ **planned** — In backlog, not started
+- ⚠️ **broken** — Tests failing or known issues
+- ❌ **dropped** — Removed or abandoned (keep for history)
+
+## Update Protocol
+
+When you add or modify a feature:
+1. Add/update the row in the Feature List table above
+2. List the key source files and test files
+3. Update the Status column
+
+**Iron Law #7**: When adding a new feature, register it here in the same commit.
+
+## Test Coverage Quick Check
+
+To verify all features are tested, scan this table for any row where:
+- Status is ✅ or 🔧 but Test Files is empty → **missing tests**
+- Status is ✅ but test files reference modules that no longer exist → **stale tests**

package/harness/project-brief.md

@@ -0,0 +1,49 @@
+# Project Brief
+
+## Vision
+
+<!-- What is this project and why does it exist?
+   Example: "An open-source MCP hub that connects AI tools to enterprise services."
+   Keep it to 1-2 sentences. This is the north star for all decisions. -->
+
+## Goals
+
+<!-- What must this project achieve? List 3-5 concrete goals.
+   Example:
+   - Support 50+ MCP servers with auto-discovery
+   - Sub-100ms routing latency
+   - Zero-config developer experience
+-->
+
+## Non-Goals
+
+<!-- What is explicitly OUT OF SCOPE? This is equally important as Goals.
+   Example:
+   - Not a hosting platform — users deploy their own
+   - Not supporting legacy REST APIs — MCP only
+   - Not building a UI dashboard in v1
+-->
+
+## Target Users
+
+<!-- Who is this for?
+   Example: "Solo developers and small teams (1-3) using AI coding assistants."
+-->
+
+## Key Technical Decisions
+
+<!-- Record major architecture choices that should NOT be reversed without discussion.
+   Example:
+   - TypeScript + Node.js (not Go, not Python)
+   - SQLite for local storage (not PostgreSQL)
+   - Monorepo with npm workspaces
+-->
+
+## Success Criteria
+
+<!-- How do we know this project is working?
+   Example:
+   - Users can install and run in under 5 minutes
+   - All MCP tools discoverable without manual configuration
+   - 90%+ test coverage on core modules
+-->