@kodevibe/harness 0.8.3

package/harness/dependency-map.md

@@ -0,0 +1,58 @@
+# Dependency Map
+
+A living document of module relationships. Update whenever modules are added or modified.
+
+## Module Registry
+
+| Module | Layer | Purpose | Depends On | Depended By | Owner |
+|--------|-------|---------|------------|-------------|-------|
+<!-- Example:
+| auth       | domain        | User authentication    | -              | api, admin    | Alice |
+| api        | presentation  | REST endpoints         | auth, services | frontend      | Bob   |
+| services   | application   | Business logic         | auth, database | api           | Alice |
+| database   | infrastructure| Data persistence       | -              | services      | Carol |
+-->
+<!-- Add new modules above this line -->
+
+## Dependency Rules
+
+- **No circular dependencies**: If A depends on B, B must not depend on A. Bidirectional check: for each row, verify the module does NOT appear in its own "Depends On" chain (A→B→C→A = circular).
+- **Layer direction**: domain → application → infrastructure/presentation (never reverse).
+  - `domain/` depends on nothing. No imports from application, infrastructure, or presentation.
+  - `application/` depends on domain only. Implements use cases using domain interfaces.
+  - `infrastructure/` implements domain interfaces. Can depend on domain and external libraries.
+  - `presentation/` depends on application. Handles routing, DTOs, controllers.
+  - `shared/` or `utils/` are cross-cutting. Any layer may depend on them, but they must NOT depend on any layer. Keep shared modules minimal.
+- **Interface boundaries**: Modules communicate through interfaces, not concrete implementations.
+- **New module = new row**: Every new module must be registered here before implementation (Iron Law #6).
+
+## 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 docs/project-state.md
+
+## Interface Change Log
+
+<!-- Record interface changes as they happen. This is MANDATORY for all interface changes (Iron Law #1).
+   **Who fills this**: The `impact-analysis` skill adds rows during planning/review. The `reviewer` agent verifies rows exist (Step 7).
+   After modifying any public interface (method signature, return type, parameters):
+   1. Add a row here immediately
+   2. Check "Affected Modules" by reading the Depended By column in Module Registry
+   3. Update mocks for all affected modules (run test-integrity skill)
+   4. Set Status to "In Progress" until all dependents are updated, then "Updated"
+
+   | Date | Module | Change | Affected Modules | Status |
+   |------|--------|--------|------------------|--------|
+   Example:
+   | 2025-01-15 | auth | Added resetPassword() | api, admin | Updated |
+   | 2025-01-20 | services | Changed getUser() return type | api | In Progress |
+-->
+
+| Date | Module | Change | Affected Modules | Status |
+|------|--------|--------|------------------|--------|

package/harness/failure-patterns.md

@@ -0,0 +1,63 @@
+# Failure Patterns
+
+Record only actual failures from this project. No theories or assumptions.
+Keep resolved patterns for regression prevention.
+**Resolution criteria**: A pattern is "Resolved" when Frequency stays at 0 for 3+ consecutive sprints after prevention was applied.
+
+**Valid Status values**:
+- `Template` — Pre-defined pattern, not yet observed in this project
+- `Active` — Observed at least once, prevention in effect
+- `Resolved` — Frequency 0 for 3+ sprints after prevention applied
+- `Obsolete (pivot: [reason])` — Invalidated by a direction change (set by `pivot` skill)
+
+---
+
+## 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
+
+<!-- Activation example: When this pattern first occurs, update like this:
+- **Occurred**: S1-2
+- **Frequency**: 1
+- **Status**: Active
+On subsequent occurrences, increment Frequency and append to Occurred (e.g., S1-2, S2-1) -->
+
+---
+
+## FP-002: Type confusion (wrong parameter count, wrong types)
+
+- **Occurred**: <!-- Sprint/Story where this happened -->
+- **Frequency**: 0
+- **Cause**: LLM does not retain type information across sessions. Called constructors with wrong parameter count, used wrong types (e.g., passed string where number expected), or confused similar type names.
+- **Concrete scenario**: `new UserService(repo)` but constructor requires `new UserService(repo, logger, config)` — LLM remembered only 1 of 3 parameters from previous session.
+- **Prevention**: Document core types in global instructions. Read source file before calling constructors (Iron Law #2).
+- **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.
+- **Concrete scenario**: Working on S1-002 (user auth), LLM noticed a bug in S1-001 (scaffolding) and fixed it without asking — breaking the unchanged module's tests.
+- **Prevention**: Track current Story in docs/project-state.md. Sprint manager agent detects scope violations. If root cause is in another module, STOP and ask user.
+- **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,53 @@
+# 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 | -                                       | -                             | - |
+-->
+<!-- Add new features above this line -->
+
+## 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)
+
+> **Note**: Feature status uses 🔧 (active) while Story status in project-state.md also uses 🔧 (active). These are aligned — when a Story is 🔧 active, its parent Feature should be 🔧 active too.
+
+## 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.
+
+**Write Precedence** (multiple skills update this file):
+1. **planner** — registers new features (⬜ planned) when creating implementation plans
+2. **sprint-manager** — updates Status to 🔧 active when a Story begins
+3. **reviewer** — updates Status to ✅ done when Story passes review, or ⚠️ broken if tests fail
+4. **learn** — finalizes Status at session end (conflict resolution: learn takes precedence)
+
+## Orphan Detection
+
+Periodically check for orphan features (features without active stories or stories without a parent feature):
+- If a Feature has Status 🔧 but no Story references it in project-state.md → stale, update to ⬜ or ❌
+- If a Story in project-state.md implements something not listed here → missing feature row, add it
+
+## 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,145 @@
+# Project Brief
+
+> **Fill this out immediately after running `musher init`.** The Planner agent uses this file for Direction Guard — without it, scope drift cannot be prevented.
+
+## Vision
+
+<!-- What is this project and why does it exist? Keep it to 1-2 sentences.
+   This is the north star for all decisions.
+   Examples:
+   - "An open-source MCP hub that connects AI tools to enterprise services."
+   - "A CLI tool that generates IDE-specific instruction files for LLM agents."
+   - "An e-commerce platform focused on local artisan products."
+-->
+
+## Goals
+
+<!-- What must this project achieve? List 3-5 concrete, measurable goals.
+   Examples:
+   - Support 50+ MCP servers with auto-discovery
+   - Sub-100ms routing latency
+   - Zero-config developer experience
+   - API coverage for all CRUD operations by v1.0
+-->
+
+## Non-Goals
+
+<!-- What is explicitly OUT OF SCOPE? This is equally important as Goals.
+   The Planner agent will WARN you when a requested feature falls here.
+   Examples:
+   - Not a hosting platform — users deploy their own
+   - Not supporting legacy REST APIs — MCP only
+   - Not building a UI dashboard in v1
+   - No mobile app — web only
+-->
+
+## Target Users
+
+<!-- Who is this for? Be specific.
+   Examples:
+   - "Solo developers and small teams (1-3) using AI coding assistants."
+   - "Enterprise teams migrating from monolith to microservices."
+   - "Data scientists who need reproducible ML pipelines."
+-->
+
+<!-- CREW_MODE_START -->
+## Crew Artifact Index
+
+<!-- 🟣 Pipeline only — auto-generated by bootstrap when crew artifacts are detected.
+   Maps original artifact documents so skills/agents can read them directly.
+   DO NOT summarize artifacts here — just index their locations.
+
+   **Detection**: bootstrap Phase 1.5 scans for artifact files in:
+   - docs/crew/
+   - docs/PM/
+   - User-provided custom paths
+   If ANY files are found, bootstrap populates this table and activates the 🟣 pipeline.
+   If NO crew artifacts are found, this section stays empty (🟢/🔵/🔴 pipelines).
+
+   | Artifact | Path | Role | Contains |
+   |----------|------|------|----------|
+   | Product Brief | docs/crew/product-brief.md | Analyst | 비전, 페르소나, KPI |
+   | PRD | docs/crew/prd.md | PM | FR-001~005, NFR, 우선순위 |
+   | Architecture | docs/crew/architecture.md | ARB | 인프라, 앱스택, 보안 |
+   | ARB Checklist | docs/crew/arb-checklist.md | ARB | 감사 결과 (Pass/Fail) |
+
+   How bootstrap populates this:
+   1. Detects artifact files in docs/crew/, docs/PM/, or user-provided paths
+   2. Creates one row per artifact with exact path
+   3. "Contains" column lists key sections (KPIs, FRs, NFRs, etc.)
+   If no crew artifacts exist, this section stays empty (🟢/🔵/🔴 pipelines).
+-->
+
+## Validation Tracker
+
+<!-- 🟣 Pipeline only — auto-generated by bootstrap, updated by learn/sprint-manager.
+   Tracks KPI coverage, FR coverage, and ARB Fail item resolution.
+   Initial state: All rows start with ⬜ (Not started). Story column empty until planner maps them.
+
+   **Status emojis for Validation Tracker** (simplified set — NOT the same as Story/Feature status):
+   - ⬜ Not started
+   - 🟡 In progress (Story mapped but not completed)
+   - ✅ Completed (Story done and verified)
+   Note: Story status uses ⬜/🔧/✅/🚫/❌ (see project-state.md). Feature status uses ⬜/🔧/✅/⚠️/❌ (see features.md). Validation Tracker uses a reduced set because it only tracks coverage, not development workflow.
+
+   **Write Precedence**: Multiple skills update the Validation Tracker:
+   1. `bootstrap` — creates initial structure (all ⬜)
+   2. `planner` — fills Story column (maps FR/KPI to Stories)
+   3. `learn` — updates Status (⬜→🟡 or 🟡→✅) based on session outcomes
+   If planner and learn both modify Status in the same session, learn’s update takes precedence (it captures the final session state).
+
+   ### KPI Coverage
+   | ID | KPI | Source | Story | Status |
+   |----|-----|--------|-------|--------|
+   (Example: | KPI-1 | 응답시간 < 200ms | product-brief.md | S1-004 | 🟡 |)
+
+   ### ARB Fail Resolution
+   | ID | Item | Severity | Story | Status |
+   |----|------|----------|-------|--------|
+   (Example: | ARB-F1 | SQL injection 취약점 | HIGH | S1-002 | ✅ |)
+
+   ### FR Coverage
+   | FR | Description | Priority | Stories | Status |
+   |----|-------------|----------|---------|--------|
+   (Example: | FR-001 | 사용자 로그인 | P0 | S1-001, S1-003 | ✅ |)
+
+   Status legend: ⬜ Not started, 🟡 In progress, ✅ Done
+   Update flow: bootstrap creates → planner fills Story column → learn updates Status
+-->
+<!-- CREW_MODE_END -->
+
+## Key Technical Decisions
+
+<!-- Record foundational technology choices AND workflow conventions.
+   Helps LLMs generate correct code and follow your team's workflow.
+
+   **Technology Stack** (fill all that apply):
+   - Language: <!-- e.g., TypeScript 5.x (strict mode), Python 3.12, Go 1.22 -->
+   - Framework: <!-- e.g., Express + Prisma ORM, Django 5.0, Spring Boot 3.x -->
+   - Test runner: <!-- e.g., Vitest (not Jest), pytest, JUnit 5 -->
+   - Database: <!-- e.g., PostgreSQL 16, MongoDB 7, SQLite -->
+   - Architecture: <!-- e.g., Hexagonal (Port + Adapter), Layered, Clean Architecture -->
+
+   **Workflow Conventions** (fill all that apply):
+   - Default branch: <!-- e.g., main, develop -->
+   - Git remote: <!-- e.g., origin, upstream -->
+   - Staging policy: <!-- e.g., explicit per-file staging (no git add .), allow git add . -->
+   - Branch strategy: <!-- e.g., feature branches (feature/S1-1-scaffolding), trunk-based, gitflow -->
+   - Commit message format: <!-- default: "S{N}-{M}: {description}" — Story ID prefix for traceability -->
+   - Push frequency: <!-- e.g., per Story completion, per session end, per sprint -->
+   - Pivot authority: <!-- e.g., team consensus, tech lead, solo developer -->
+   - Deploy method: <!-- e.g., npm publish, docker push, terraform apply -->
+-->
+
+## Decision Log
+
+<!-- Record WHY key decisions were made. The Planner uses this to avoid re-debating settled decisions.
+   Use the `pivot` skill to add entries here when direction changes.
+   Format:
+
+### [YYYY-MM-DD] [Decision Title]
+- **Change**: What changed
+- **Reason**: Why this decision was made
+- **Impact**: What was affected
+- **Alternatives Considered**: 1-2 bullet points on what was rejected and why
+-->

package/harness/project-state.md

@@ -0,0 +1,85 @@
+# Project State
+
+> **Keep this file under 200 lines.** When Story count exceeds 30, move completed stories (✅) to the Archive section at the bottom.
+
+## Quick Summary
+
+<!-- Update these 3 lines EVERY session end. Format strictly:
+   Line 1: ✅ Last session: [Story ID] [one-sentence what was done]
+   Line 2: 🔄 In progress: [Story ID] [current state with measurable progress]
+   Line 3: ➡️ Next: [specific action to take first]
+
+   ✅ Good examples:
+   ✅ Last session: S1-002 User authentication implemented (login + JWT)
+   🔄 In progress: S1-003 API endpoint tests (3/7 tests passing)
+   ➡️ Next: Complete remaining 4 tests, then start S1-004
+
+   ❌ Bad examples:
+   ✅ Last session: Did some work (too vague)
+   🔄 In progress: Stuff (no Story ID, no progress metric)
+   ➡️ Next: Continue (no specific action)
+
+   **Write Precedence**: Multiple skills update this file. Priority order:
+   1. `learn` (session end) — highest priority, overwrites Quick Summary
+   2. `sprint-manager` (story status changes) — updates Story Status table
+   3. `planner` (new stories) — adds rows to Story Status table
+   4. `investigate` (bug fixes) — adds to Recent Changes only
+   If conflicts: learn’s Quick Summary always wins (it captures final session state).
+-->
+
+## Current Sprint
+
+- Sprint: 1 — Initial Setup
+- Started: <!-- TODO: date -->
+- Branch: main
+
+## Story Status
+
+| ID | Title | Status | Assignee |
+|----|-------|--------|----------|
+| S1-1 | Project scaffolding | ⬜ todo | |
+| S1-2 | Core feature implementation | ⬜ todo | |
+| S1-3 | Test coverage | ⬜ todo | |
+
+<!-- Status legend: ⬜ todo, 🔧 active, ✅ done, 🚫 blocked, ❌ dropped -->
+
+## Module Registry
+
+<!-- Summary of current modules. Full details in docs/dependency-map.md -->
+| Module | Layer | Status |
+|--------|-------|--------|
+<!-- Fill as modules are created. Status: ⬜ planned, 🔧 active, ✅ stable -->
+
+## Technical Decisions
+
+<!-- Record key architectural decisions here. Detailed rationale goes in project-brief.md Decision Log. -->
+
+## Recent Changes
+
+<!-- Log recent completions here. Keep last 10 entries. Older entries can be deleted. -->
+
+---
+
+## Session Handoff Protocol
+
+Before ending a chat session, you MUST:
+1. Update the **Quick Summary** section above (3 lines: ✅/🔄/➡️ format)
+2. Update **Story Status** table with current progress
+3. Add any new failure patterns to `docs/failure-patterns.md`
+4. Update `docs/features.md` if any features were added/changed
+
+When starting a new chat session, read these files first:
+1. `docs/project-state.md` (this file) — where we are
+2. `docs/features.md` — what exists
+3. `docs/failure-patterns.md` — what to watch out for
+4. `docs/project-brief.md` — why we're building this
+
+---
+
+## Archive
+
+<!-- Move completed stories (✅) here when Story Status table exceeds 30 rows.
+   Keep the table format. Prefix with sprint number for reference.
+   | Sprint | ID | Title | Completed |
+   |--------|----|-------|-----------|
+-->