k-harness 0.3.0 → 0.5.0

package/harness/project-brief.md

@@ -1,49 +1,69 @@
 # Project Brief
 
+> **Fill this out immediately after running `k-harness 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?
-   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. -->
+<!-- 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 goals.
-   Example:
+<!-- 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.
-   Example:
+   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?
-   Example: "Solo developers and small teams (1-3) using AI coding assistants."
+<!-- 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."
 -->
 
 ## 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
+<!-- Record foundational technology choices. Helps LLMs generate correct code.
+   Examples:
+   - Language: TypeScript 5.x (strict mode)
+   - Framework: Express + Prisma ORM
+   - Test runner: Vitest (not Jest)
+   - Database: PostgreSQL 16
+   - Architecture: Hexagonal (Port + Adapter)
+   - Language: Python 3.12, Framework: FastAPI, Tests: pytest
+   - Language: Go 1.22, no framework, Tests: go test
 -->
 
-## Success Criteria
+## 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:
 
-<!-- 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
+### [YYYY-MM-DD] [Decision Title]
+- **Change**: What changed
+- **Reason**: Why this decision was made
+- **Impact**: What was affected
+- **Alternatives Considered**: What else was considered and rejected
 -->

package/harness/project-state.md

@@ -25,7 +25,7 @@
 
 ## Module Registry
 
-<!-- Summary of current modules. Full details in dependency-map.md -->
+<!-- Summary of current modules. Full details in docs/dependency-map.md -->
 | Module | Layer | Status |
 |--------|-------|--------|
 <!-- Fill as modules are created -->
@@ -45,11 +45,11 @@
 Before ending a chat session, you MUST:
 1. Update the **Quick Summary** section above (3 lines)
 2. Update **Story Status** table with current progress
-3. Add any new failure patterns to `failure-patterns.md`
-4. Update `features.md` if any features were added/changed
+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. `project-state.md` (this file) — where we are
-2. `features.md` — what exists
-3. `failure-patterns.md` — what to watch out for
-4. `project-brief.md` — why we're building this
+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

package/harness/skills/bootstrap.md

@@ -0,0 +1,119 @@
+# Bootstrap
+
+## Purpose
+
+Onboard a new or existing project into K-Harness by filling state files automatically.
+Solves the cold-start problem: users don't know which `.md` files to fill or how.
+
+## When to Apply
+
+- Right after running `k-harness init` on a new project
+- When joining an existing project that has empty state files
+- When state files are outdated and need a refresh
+- When any agent reports "state files are empty"
+
+## Procedure
+
+### Phase 1: Project Discovery (read-only)
+
+1. **Scan project root** for configuration files:
+   - `package.json`, `tsconfig.json` → Node.js/TypeScript
+   - `go.mod`, `go.sum` → Go
+   - `requirements.txt`, `pyproject.toml`, `setup.py` → Python
+   - `pom.xml`, `build.gradle` → Java
+   - `Cargo.toml` → Rust
+   - `Gemfile` → Ruby
+2. **Scan directory structure**: List top-level directories and identify patterns
+   - `src/`, `lib/`, `app/` → source code
+   - `tests/`, `test/`, `__tests__/`, `spec/` → test directories
+   - `docs/` → documentation
+3. **Scan for existing tests**: Find test files and map them to source modules
+4. **Scan imports/dependencies**: Trace module relationships from import statements
+
+**Do NOT modify any code files in this phase.**
+
+### Phase 2: User Interview (interactive)
+
+Ask the user these questions (skip any already answered by Phase 1):
+
+1. "What does this project do? (one sentence)"
+2. "What are the top 3 goals of this project?"
+3. "What is explicitly OUT of scope? (non-goals)"
+4. "What architecture pattern are you using?" (show detected pattern if found)
+5. "Are there any type decisions or conventions the AI should know about?"
+
+### Phase 3: Fill State Files
+
+Using data from Phase 1 + Phase 2, fill the following files:
+
+**docs/project-brief.md**:
+- Project Name → from package.json name, go.mod module, or user input
+- Vision → from user answer #1
+- Goals → from user answer #2
+- Non-Goals → from user answer #3
+- Key Technical Decisions → from Phase 1 scan + user answer #4, #5
+
+**docs/features.md**:
+- Add one row per detected module/feature area
+- Status: `✅ done` for modules with passing tests, `🔧 active` for modules without tests
+- Key Files: actual file paths from scan
+- Test Files: actual test file paths from scan
+
+**docs/dependency-map.md**:
+- Add one row per module
+- Layer: inferred from directory structure (domain/application/infrastructure/presentation)
+- Depends On / Depended By: inferred from import scan
+
+**docs/project-state.md**:
+- Quick Summary: filled with current project state
+- Sprint 1 stories: based on what bootstrap discovered
+- Module Registry: summary from docs/dependency-map.md
+
+**docs/failure-patterns.md**:
+- Keep FP-001 through FP-004 as templates (Frequency: 0)
+- No changes unless user reports known issues
+
+### Phase 4: Verify
+
+1. Present a summary of all filled state files to the user
+2. Ask "Does this look correct? What should I change?"
+3. Apply corrections if any
+4. Report completion
+
+## Output Format
+
+```
+## Bootstrap Complete
+
+### Project: [name]
+### Tech Stack: [detected stack]
+### Modules Found: [count]
+### Features Mapped: [count]
+### Dependency Links: [count]
+
+### State Files Updated:
+- [x]docs/project-brief.md — [summary]
+- [x]docs/features.md — [N] features registered
+- [x]docs/dependency-map.md — [N] modules, [N] dependencies
+- [x]docs/project-state.md — Sprint 1 initialized
+- [ ]docs/failure-patterns.md — templates only (no changes)
+
+STATUS: DONE
+```
+
+## Rules
+
+- Never modify source code — this skill only writes to state files
+- Always show the user what was discovered BEFORE writing files
+- If the project has 0 source files, skip Phase 1 scan and go straight to Phase 2
+- If a state file already has content, ask before overwriting
+- Run this skill only once per project (or when explicitly requested for refresh)
+
+## Anti-patterns
+
+| Anti-pattern | Correct Approach |
+|---|---|
+| Guess module boundaries | Scan actual directory structure and imports |
+| Skip user interview | Phase 1 scan alone is insufficient — always confirm with user |
+| Overwrite existing state files silently | Ask before overwriting non-empty files |
+| Create perfect dependency map on first try | Start with what's detectable, refine over time |

package/harness/skills/feature-breakdown.md

@@ -15,7 +15,7 @@ Ensures bottom-up implementation: foundations first, then layers that depend on
 ## Procedure
 
 1. **Describe the feature** in one sentence
-2. **Read dependency-map.md** to understand current module relationships
+2. **Read docs/dependency-map.md** to understand current module relationships
 3. **Identify affected modules**: List every module that needs changes
 4. **Classify changes per module**:
    - NEW_MODULE: Entirely new module to create
@@ -41,24 +41,24 @@ Ensures bottom-up implementation: foundations first, then layers that depend on
 
 ### Wave 1 (no dependencies)
 - [ ] Task 1: [Module A] — Create entity + repository interface
-  - Files: src/domain/entities/X.ts, src/domain/repositories/XRepository.ts
-  - Tests: tests/domain/X.test.ts
+  - Files: <!-- list files to create/modify -->
+  - Tests: <!-- list test files -->
   - Depends on: none
 
 ### Wave 2 (depends on Wave 1)
 - [ ] Task 2: [Module B] — Implement use case
-  - Files: src/application/usecases/DoX.ts
-  - Tests: tests/application/DoX.test.ts
+  - Files: <!-- list files to create/modify -->
+  - Tests: <!-- list test files -->
   - Depends on: Task 1
 
 ### Wave 3 (depends on Wave 2)
-- [ ] Task 3: [Module C] — Add API endpoint
-  - Files: src/presentation/routes/x.ts, src/presentation/dto/XDto.ts
-  - Tests: tests/presentation/x.test.ts
+- [ ] Task 3: [Module C] — Add API endpoint / UI integration
+  - Files: <!-- list files to create/modify -->
+  - Tests: <!-- list test files -->
   - Depends on: Task 2
 
 ### Dependency Map Updates
-- [ ] Register Module A in dependency-map.md
+- [ ] Register Module A in docs/dependency-map.md
 - [ ] Update Module B's "Depends On" column
 ```
 
@@ -67,9 +67,17 @@ Ensures bottom-up implementation: foundations first, then layers that depend on
 - Never implement a module before its dependencies exist
 - Each task should be completable in one session
 - Every task must include its test files
-- New modules MUST be registered in dependency-map.md (Iron Law #6)
+- New modules MUST be registered in docs/dependency-map.md (Iron Law #6)
 - If a task exceeds Story scope, stop and report to user
 
+## State File Updates (mandatory)
+
+After completing the breakdown, update these files in the same session:
+
+- [ ] **docs/dependency-map.md**: Register all NEW_MODULE entries. Update "Depends On" / "Depended By" for INTERFACE_CHANGE entries.
+- [ ] **docs/features.md**: Add a new row for the feature with Status `🔧 active`, Key Files from Wave tasks, and Test Files.
+- [ ] **docs/project-state.md**: Add Stories to the Story Status table for each Wave.
+
 ## Anti-patterns
 
 | Anti-pattern | Correct Approach |
@@ -78,3 +86,4 @@ Ensures bottom-up implementation: foundations first, then layers that depend on
 | One giant task for the whole feature | Break into single-module tasks |
 | Skip dependency-map registration | Register immediately when creating module |
 | Tests "later" | Tests in the same task |
+| Produce breakdown but skip state file updates | State file updates are part of the breakdown, not a separate step |

package/harness/skills/impact-analysis.md

@@ -15,7 +15,7 @@ The most common cause of regressions in growing projects is changing one module
 ## Procedure
 
 1. **Identify the target module**: Which module are you about to change?
-2. **Read dependency-map.md**: Find the target module's row
+2. **Read docs/dependency-map.md**: Find the target module's row
 3. **List dependents**: Read the "Depended By" column — these are the blast radius
 4. **Check interface impact**: Does your change affect the module's public interface?
    - If NO (internal-only change) → proceed, but still run dependent tests
@@ -25,11 +25,11 @@ The most common cause of regressions in growing projects is changing one module
    - Identify which functions/types they use
    - Determine if the interface change breaks them
 6. **Plan updates**: Create a task list of all files that need modification
-7. **Verify scope**: Confirm all files are within the current Story scope (project-state.md)
+7. **Verify scope**: Confirm all files are within the current Story scope docs/project-state.md)
 
 ## Checklist
 
-- [ ] Target module identified in dependency-map.md
+- [ ] Target module identified in docs/dependency-map.md
 - [ ] All dependent modules listed
 - [ ] Interface vs internal change classified
 - [ ] Files importing from target module enumerated
@@ -57,6 +57,13 @@ Plan: 4 files to update, all within S3-2 scope
 → Tests fail in 3 modules, mock out of sync, 2 hours wasted
 ```
 
+## State File Updates (mandatory)
+
+After completing the analysis, update these files:
+
+- [ ] **docs/dependency-map.md**: Update the Interface Change Log table with: Date, Module, Change description, Affected Modules, Status.
+- [ ] **docs/project-state.md**: If scope exceeds current Story, add a note to Recent Changes.
+
 ## Related Failure Patterns
 
 - FP-001: Interface changed, mock not updated → Checklist item 5

package/harness/skills/investigate.md

@@ -27,7 +27,7 @@ Debug bugs systematically. Prevent "symptom patching" — fixing without underst
 
 1. Identify the module/directory containing the root cause
 2. Exclude files outside that scope from modification
-3. Check failure-patterns.md for matching patterns
+3. Check docs/failure-patterns.md for matching patterns
 
 ### Phase 3: Hypothesis + Fix
 
@@ -39,7 +39,7 @@ Debug bugs systematically. Prevent "symptom patching" — fixing without underst
 
 1. Run all related tests after the fix
 2. Add a regression test (prevent the same bug from recurring)
-3. Decide if the pattern should be recorded in failure-patterns.md
+3. Decide if the pattern should be recorded in docs/failure-patterns.md
 
 ## Checklist
 
@@ -67,6 +67,13 @@ Phase 4: Tests pass, null case test added
 → Root cause unknown, no reproduction conditions recorded, same error possible elsewhere
 ```
 
+## State File Updates (mandatory)
+
+After the fix is verified (Phase 4):
+
+- [ ] **docs/failure-patterns.md**: If the root cause is a repeatable pattern, add a new FP-NNN entry or increment the Frequency of an existing one. This is NOT optional.
+- [ ] **docs/project-state.md**: Add the fix to Recent Changes with the root cause hypothesis.
+
 ## Related Failure Patterns
 
 - FP-002: Type confusion → Phase 1 requires verifying actual types

package/harness/skills/learn.md

@@ -0,0 +1,113 @@
+# Learn
+
+## Purpose
+
+Capture lessons from the current session before ending.
+Updates docs/failure-patterns.md with new patterns and refreshes docs/project-state.md Quick Summary.
+This is K-Harness's memory mechanism — without it, the same mistakes repeat across sessions.
+
+## When to Apply
+
+- Before ending a chat session (recommended as the LAST skill invoked)
+- After a debugging session where a non-obvious fix was found
+- After a review revealed a repeated mistake
+- When the user explicitly asks to record a lesson
+
+## Procedure
+
+### Step 1: Review Session Activity
+
+1. Scan recent git changes: `git log --oneline -10` and `git diff --stat HEAD~3`
+2. Identify what was accomplished in this session
+3. Identify any errors, failures, or unexpected issues that occurred
+
+### Step 2: Failure Pattern Detection
+
+For each issue/error that occurred in this session:
+
+1. Read `docs/failure-patterns.md`
+2. Check if this matches an existing pattern (FP-NNN):
+   - **If match found**: Increment the Frequency counter, add the Sprint/Story to "Occurred"
+   - **If new pattern**: Assign next FP-NNN number, create a new entry using this format:
+
+```markdown
+## FP-NNN: [Short description]
+
+- **Occurred**: S[sprint]-[story]
+- **Frequency**: 1
+- **Cause**: [What went wrong and why]
+- **Prevention**: [Specific check to prevent recurrence]
+- **Applied in**: [Which skills/agents/rules should enforce this]
+- **Status**: Active
+```
+
+3. If the failure relates to a specific skill or agent, note it for that skill's checklist
+
+### Step 3: Update docs/project-state.md
+
+1. Update **Quick Summary** (3 lines):
+   - Line 1: What was accomplished in this session
+   - Line 2: What is currently in progress
+   - Line 3: What should be done next
+2. Update **Story Status** table if any stories changed
+3. Add to **Recent Changes** section with date and summary
+
+### Step 4: Update docs/features.md (if applicable)
+
+1. If new features were added → add row to Feature List
+2. If existing features were modified → update Key Files and Test Files columns
+3. If features were completed → update Status to `✅ done`
+
+### Step 5: Update Agent Memory (if applicable)
+
+If an agent (reviewer, planner, sprint-manager) was used in this session, update its memory file in `docs/agent-memory/`:
+
+1. Read `docs/agent-memory/{agent-name}.md`
+2. Add session-specific learnings to the appropriate section:
+   - **reviewer.md**: Review patterns, frequently missed items, statistics
+   - **planner.md**: Estimation accuracy, architecture insights, repeated patterns
+   - **sprint-manager.md**: Velocity data, scope drift incidents, sizing recommendations
+3. Keep entries concise — one line per learning
+4. If no agent was used in this session, skip this step
+
+### Step 6: Report
+
+Present a summary of all updates made.
+
+## Output Format
+
+```
+## Session Learn Complete
+
+### Lessons Captured:
+- [FP-NNN] (new/updated): [description]
+
+### State Files Updated:
+- [x]docs/project-state.md — Quick Summary refreshed
+- [x]docs/failure-patterns.md — [N] patterns added/updated
+- [x]docs/features.md — [N] features updated (if applicable)
+- [x] docs/agent-memory/{name}.md — [N] agents updated (if applicable)
+
+### Next Session Should:
+1. [recommended first action]
+2. [next priority]
+
+STATUS: DONE
+```
+
+## Rules
+
+- Never invent patterns that didn't actually occur — record only real failures
+- Keep failure pattern descriptions concise (1-2 sentences for Cause and Prevention)
+- If no failures occurred, skip Step 2 and just update state files
+- Do not modify source code — this skill only updates state files
+- Quick Summary must be exactly 3 lines — concise enough for the next session to scan instantly
+
+## Anti-patterns
+
+| Anti-pattern | Correct Approach |
+|---|---|
+| Record theoretical risks as failure patterns | Only record failures that actually happened |
+| Write vague descriptions ("something broke") | Be specific: file name, error message, root cause |
+| Skip this skill because "nothing went wrong" | Still update Quick Summary and Story Status |
+| Update docs/failure-patterns.md but not docs/project-state.md | Always update both — they serve different purposes |

package/harness/skills/pivot.md

@@ -0,0 +1,102 @@
+# Pivot
+
+## Purpose
+
+When a project direction changes — technology swap, scope expansion/reduction, architecture shift — this skill propagates the change across ALL state files consistently.
+Without this, direction changes create silent inconsistencies:docs/project-brief.md says "GraphQL" but docs/dependency-map.md still references REST modules.
+
+## When to Apply
+
+- Technology change: "Switch from REST to GraphQL", "Replace PostgreSQL with MongoDB"
+- Scope change: "Add real-time features", "Remove mobile support", "Downscope to MVP"
+- Architecture shift: "Move from monolith to microservices", "Switch from SSR to SPA"
+- Goal change: "Pivot from B2C to B2B", "Change target users"
+- Any time the user says "let's change direction", "pivot", "switch to", "drop [feature area]"
+
+## Procedure
+
+### Step 1: Capture the Change
+
+1. Ask the user to describe the change in one sentence
+2. Classify the change type:
+   - **Tech Swap**: Replacing one technology with another
+   - **Scope Change**: Adding or removing feature areas
+   - **Architecture Shift**: Changing system structure
+   - **Goal Pivot**: Changing project purpose or target
+
+### Step 2: Impact Scan
+
+Read ALL state files and identify what needs updating:
+
+1. **docs/project-brief.md**:
+   - Does Vision need rewording?
+   - Do Goals need updating?
+   - Do Non-Goals need updating?
+   - Do Key Technical Decisions need changing?
+   - Record the decision with reasoning in the Decision Log section
+
+2. **docs/features.md**:
+   - Which existing features are affected?
+   - Which features should be marked `⛔ dropped`?
+   - Are new features needed?
+
+3. **docs/dependency-map.md**:
+   - Which modules are obsoleted by this change?
+   - Which new modules are needed?
+   - Which dependency relationships change?
+
+4. **docs/project-state.md**:
+   - Which in-progress stories are affected?
+   - Does the current sprint goal change?
+   - Update Quick Summary to reflect the pivot
+
+5. **docs/failure-patterns.md**:
+   - Are any existing patterns invalidated by this change?
+   - Mark invalidated patterns as `Status: Obsolete (pivot: [reason])`
+
+### Step 3: Present Change Plan
+
+Before writing anything, present a summary to the user:
+
+```
+## Pivot: [one-sentence description]
+Type: [Tech Swap | Scope Change | Architecture Shift | Goal Pivot]
+
+### State File Changes:
+- docs/project-brief.md: [what changes]
+- docs/features.md: [N features affected, M dropped, K added]
+- docs/dependency-map.md: [N modules obsoleted, M added, K relationships changed]
+- docs/project-state.md: [N stories affected]
+- docs/failure-patterns.md: [N patterns obsoleted]
+
+### Confirm? (yes/no)
+```
+
+### Step 4: Execute Updates
+
+After user confirms, update ALL state files in order:
+
+1. **docs/project-brief.md** first (source of truth for direction)
+2. **docs/features.md** second (what we're building)
+3. **docs/dependency-map.md** third (how it connects)
+4. **docs/project-state.md** fourth (current work status)
+5. **docs/failure-patterns.md** last (historical patterns)
+
+### Step 5: Decision Log Entry
+
+Add an entry to the Decision Log section in docs/project-brief.md:
+
+```markdown
+### [YYYY-MM-DD] [Decision Title]
+- **Change**: [What changed]
+- **Reason**: [Why this decision was made]
+- **Impact**: [What was affected]
+- **Alternatives Considered**: [What else was considered and rejected]
+```
+
+## Rules
+
+- **Never skip the confirmation step** — the user must approve before any state file is written
+- **Never update partially** — if you update docs/project-brief.md, you MUST check and update all other state files too
+- **Preserve history** — mark dropped features as `⛔ dropped`, don't delete rows
+- **Record the why** — every pivot must have a Decision Log entry with reasoning

package/harness/skills/security-checklist.md

@@ -44,6 +44,12 @@ git add .
 const dbPassword = "super_secret_123";
 ```
 
+## State File Updates (mandatory)
+
+After completing the security check:
+
+- [ ] **docs/failure-patterns.md**: If a security issue was found (credentials staged, hardcoded secret), add a new FP-NNN entry or increment FP-004 Frequency.
+
 ## Related Failure Patterns
 
 - FP-004: Dangerous file committed → Checklist items 1, 4

package/harness/skills/test-integrity.md

@@ -41,6 +41,13 @@ Interface adds findByFilters() → Mock unchanged
 → Runtime error: method not found on mock object
 ```
 
+## State File Updates (mandatory)
+
+After synchronizing mocks:
+
+- [ ] **docs/failure-patterns.md**: If mock sync was missed and caused a test failure, increment FP-001 Frequency.
+- [ ] **docs/dependency-map.md**: If the interface change altered module relationships, update the relevant row.
+
 ## Related Failure Patterns
 
 - FP-001: Interface changed, mock not updated → Checklist item 1

package/harness/testing-rules.md

@@ -11,11 +11,11 @@
 ## Forbidden
 
 - Casting mocks with `any` type. Create mocks using the actual interface type.
-- Creating mocks with bare `jest.fn()` only. Set default return values with `mockResolvedValue` etc.
+- Creating mocks with no default return values. Always set sensible defaults (e.g. `mockResolvedValue`, stub returns).
 - Committing with `skip` or `only` left in test files.
-- Committing with `console.log` debugging statements.
+- Committing with debugging statements (e.g. `console.log`, `print`, `println`).
 
 ## References
 
 - test-integrity skill
-- failure-patterns.md FP-001: Mock not updated
+- docs/failure-patterns.md FP-001: Mock not updated

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "k-harness",
-  "version": "0.3.0",
+  "version": "0.5.0",
   "description": "LLM Development Harness — IDE-agnostic rules, skills, and agents that prevent common AI coding failures",
   "keywords": [
     "llm",
@@ -35,6 +35,9 @@
   "engines": {
     "node": ">=18.0.0"
   },
+  "scripts": {
+    "test": "node --test tests/*.test.js"
+  },
   "publishConfig": {
     "access": "public"
   }