@kodevibe/harness 0.9.0 → 0.9.1

package/README.ko.md

@@ -9,83 +9,33 @@
 [![CI](https://github.com/AIDD-Projects/harness/actions/workflows/ci.yml/badge.svg)](https://github.com/AIDD-Projects/harness/actions/workflows/ci.yml)
 [![License: MIT](https://img.shields.io/badge/License-MIT-yellow.svg)](https://opensource.org/licenses/MIT)
 
-**모든 개발자의 AI를 하나의 프로젝트 방향으로 정렬합니다.**
+> **AI 코딩 에이전트는 세션이 끝나면 모든 것을 잊습니다. kode:harness는 목표, 결정, 실패, 프로젝트 방향을 기억하게 합니다.**
 
-kode:harness는 **harness engineering** 원칙을 기반으로 합니다. 멀티 개발자와 엔터프라이즈급 환경, 그리고 solo 개발 흐름까지 고려한 AI 개발 엔지니어링 방식을 제품 형태로 제공하는 구조입니다.
-
-> **v0.9.0** — 네이밍 재설계 (스킬/에이전트 이름 직관화), 6개 IDE 지원, Navigation Dispatcher, 5개 파이프라인 (🟢🔵🔴🟡🟣), Crew Artifact Integration.
-
----
-
-## Harness에서 Enterprise Harness Engineering으로
-
-AI "harness" — LLM 코딩 에이전트를 안내하는 구조화된 마크다운 파일 — 는 AI 기반 개발의 기본 패턴이 되었습니다. BMAD, gstack, GSD 같은 프레임워크가 **1인 개발자**를 위해 이 접근법을 개척했습니다.
-
-이 접근은 harness 엔지니어링을 1인 도구 수준에서 멀티 개발자 팀과 solo 개발자까지 포괄하는 **엔터프라이즈급 방향 관리 기법**으로 확장합니다. **kode:harness**는 이 접근을 제품 형태로 구현한 실행 프레임워크입니다.
-
-| | 기존 Harness | kode:harness + harness engineering |
-|---|---|---|
-| 대상 | 1인 개발자 | **멀티 개발자 팀** |
-| 초점 | AI가 무엇을 하는지 | **AI가 어디로 가는지** |
-| 방향 관리 | ❌ | ✅ Direction Guard + pivot + Decision Log |
-| 팀 상태 공유 | ❌ | ✅ 공유/개인 상태 분리 |
-| 토큰 예산 | 200+ 파일 | **~25개 파일 (~17K 토큰)** — 소형 LLM도 작동 |
-
-## 어떤 문제를 해결하나요?
-
-혼자 개발할 때는 AI 코딩 어시스턴트의 방향이 일관됩니다. 하지만 **기업 팀**에서는 각 개발자가 독립된 AI 세션을 실행하고, 각 AI는 제각각 다른 방향으로 흘러갑니다.
-
-- 개발자 A의 AI → 마이크로서비스로 리팩토링
-- 개발자 B의 AI → 모놀리스를 강화
-- 개발자 C의 AI → 이미 결정된 사항을 다시 논의
-
-공유된 방향 관리 없이는 **여러 개발자의 AI가 프로젝트를 분리시킵니다.**
-
-kode:harness는 모든 개발자의 AI에게 동일한 목표·비목표·결정사항·프로젝트 상태를 제공하여, 누가 코딩하든 어떤 IDE를 쓰든 **하나의 방향**으로 수렴하게 합니다.
-
-## 핵심 설계 원칙
-
-> **경량성**: Claude Sonnet이나 GPT-4o 같은 대형 LLM뿐 아니라, 프라이빗 망의 소형 LLM(GPT OSS 120B급, 로컬 LLM 등)도 kode:harness 파일을 읽고 프로젝트 방향을 유지할 수 있어야 합니다. BMAD의 200개 이상 파일 대비 **~25개 파일, ~17K 토큰**으로 동일한 효과를 달성합니다.
-
----
-
-## 주요 기능
-
-| 기능 | 설명 |
-|------|------|
-| 🧭 **Direction Guard** | 모든 코딩 요청을 프로젝트 목표/비목표와 대조 후 실행 |
-| 🧭 **Navigation Dispatcher** | Turn-by-Turn 네비게이션으로 5개 파이프라인을 따라 다음 단계 프롬프트를 자동 안내 |
-| 🟢🔵🔴🟡🟣 **5개 파이프라인** | New Dev → Continue → Bug Fix → Direction Change → Crew-Driven |
-| 🟣 **Crew Artifact Integration** | 외부 기획 도구 산출물(PRD, Architecture, ARB Checklist)을 직접 읽기 — 수동 복사 불필요 |
-| 📝 **State Files** | LLM 세션 간 프로젝트 지식을 유지하는 5개 마크다운 파일 |
-| 🛠️ **Skills** | 기획, 리뷰, 디버깅, 방향 전환을 위한 단계별 절차 10개 |
-| 🤖 **Agents** | 워크플로를 강제하는 역할 기반 페르소나 4개 |
-| ⚠️ **Failure Patterns** | 동일 실수 반복을 방지하는 프로젝트별 실패 기록 |
-| 📝 **Decision Log** | 결정의 이유를 기록해 LLM이 확정된 사항을 재논의하지 않도록 방지 |
+AI 코딩 에이전트를 위한 프로덕션급 가드레일. 컨텍스트 부패를 방지하고, 프로젝트 방향을 강제하며, 세션 간 상태를 유지합니다. **Copilot, Claude, Cursor, Codex, Windsurf, Gemini** 지원. 의존성 제로.
 
 ---
 
 ## 빠른 시작
 
 ```bash
-# Solo 모드 (기본)
-npx @kodevibe/harness init
-
-# Team 모드 (멀티 개발자)
-npx @kodevibe/harness init --team
+npx @kodevibe/harness init          # IDE 선택
 ```
 
-프롬프트에서 IDE를 선택하면 현재 디렉토리에 파일이 설치됩니다.
-
-설치 후, LLM에게 `setup` 스킬을 실행하도록 요청하세요:
-
+```bash
+# 그 후 AI 에이전트에게:
 > "setup을 실행해서 이 프로젝트를 온보딩해줘."
+```
 
-코드베이스를 스캔하고 5개 State 파일을 자동으로 채웁니다.
+끝입니다. 이제 AI는 영속적인 메모리, 방향 가드레일, 자기 교정 루프를 갖게 됩니다.
 
-### 비대화형 모드
+<details>
+<summary>추가 설치 옵션</summary>
 
 ```bash
+# Team 모드 (멀티 개발자 방향 정렬)
+npx @kodevibe/harness init --team
+
+# 비대화형 (CI/스크립트)
 npx @kodevibe/harness init --ide vscode
 npx @kodevibe/harness init --ide claude
 npx @kodevibe/harness init --ide cursor
@@ -94,8 +44,6 @@ npx @kodevibe/harness init --ide windsurf
 npx @kodevibe/harness init --ide antigravity
 ```
 
-### 옵션
-
 | 플래그 | 설명 |
 |--------|------|
 | `--ide <이름>` | 대상 IDE: `vscode`, `claude`, `cursor`, `codex`, `windsurf`, `antigravity` |
@@ -106,14 +54,58 @@ npx @kodevibe/harness init --ide antigravity
 | `--overwrite` | 기존 파일 덮어쓰기 (state 파일 포함) |
 | `--version` | 버전 번호 표시 |
 
-### 헬스체크
+</details>
 
-```bash
-# kode:harness 파일 설치 상태 확인
-npx @kodevibe/harness doctor
+---
+
+## 문제: 컨텍스트 부패 (Context Rot)
+
+AI 코딩 에이전트는 매 세션 제로에서 시작합니다. 세션 3에서는 세션 1의 아키텍처 결정을 잊고, 세션 10에서는 이미 확정된 사항을 다시 논의하며 자신의 이전 작업과 모순됩니다.
+
+팀에서는 더 심각합니다 — 개발자 A의 AI는 마이크로서비스로 리팩토링하고, 개발자 B의 AI는 모놀리스를 강화합니다. **공유 가드레일 없이는 AI 에이전트가 프로젝트를 분리시킵니다.**
+
+kode:harness는 세 가지 메커니즘으로 해결합니다:
+
+| 메커니즘 | 방지하는 문제 |
+|---------|-------------|
+| **상태 영속성** | AI가 세션 간 목표, 결정, 진행 상황을 잊는 것 |
+| **방향 가드** | AI가 프로젝트 목표에서 이탈하거나 과거 결정과 모순되는 것 |
+| **실패 패턴** | AI가 세션 간 같은 실수를 반복하는 것 |
+
+---
 
-# State 파일에 실제 내용이 있는지 검증 (플레이스홀더가 아닌지)
-npx @kodevibe/harness validate
+## 왜 그냥 ...을 쓰면 안 되나요?
+
+| 접근법 | 한계 | kode:harness 차이점 |
+|--------|------|---------------------|
+| **`.cursorrules` / `copilot-instructions.md`** | 정적. 상태 영속성 없음, 자기 교정 없음, 세션 간 기억 없음. | 매 세션 업데이트되는 살아있는 state 파일. Direction Guard가 매 요청을 목표와 대조. |
+| **LangChain / CrewAI** | AI 앱 구축용 런타임 오케스트레이션. AI 코딩 에이전트 방향 관리용이 아님. | IDE 안에서 작동하는 마크다운 네이티브 가드레일. 런타임 없음, SDK 없음. |
+| **BMAD / gstack / GSD** | 1인 개발자용. 200+ 파일. 방향 관리 없음. | ~25개 파일 (~17K 토큰). Direction Guard + Decision Log. 멀티 개발자 팀 지원. |
+| **"조심하면 되지"** | 잊을 때까지만 동작. LLM은 과거 세션에서 배우지 않음. | 자동화: `wrap-up`이 교훈 캡처, `debug`가 실패 추적, `reviewer`가 state 감사. |
+
+---
+
+## 주요 기능
+
+| 기능 | 설명 |
+|------|------|
+| 🛡️ **Direction Guard** | 모든 코딩 요청을 프로젝트 목표/비목표와 대조 후 실행 |
+| 🧭 **Navigation Dispatcher** | 5개 파이프라인을 따라 다음 단계 프롬프트를 자동 안내 |
+| 📝 **상태 영속성** | LLM 세션 간 프로젝트 지식을 유지하는 5개 마크다운 파일 |
+| 🔄 **5개 파이프라인** | 🟢 신규 → 🔵 계속 → 🔴 버그 수정 → 🟡 방향 전환 → 🟣 Crew 기반 |
+| 🛠️ **10개 스킬** | 단계별 절차: setup, debug, breakdown, review, pivot 등 |
+| 🤖 **4개 에이전트** | 역할 기반 페르소나: pm, reviewer, lead, architect |
+| ⚠️ **실패 패턴** | 세션 간 같은 실수를 방지하는 프로젝트별 실패 기록 |
+| 📋 **Decision Log** | 결정의 이유를 기록해 LLM이 확정된 사항을 재논의하지 않도록 방지 |
+| 🟣 **Crew Artifact Integration** | 외부 기획 산출물 (PRD, Architecture, ARB Checklist) 직접 읽기 |
+
+---
+
+## 헬스체크
+
+```bash
+npx @kodevibe/harness doctor    # 파일 설치 상태 확인
+npx @kodevibe/harness validate  # state 파일에 실제 내용 확인
 ```
 
 ---
@@ -267,14 +259,13 @@ npx @kodevibe/harness init --team
 
 ---
 
-## 왜 kode:harness인가?
+## 왜 만들었나
 
-### 핵심 통찰
+기존 AI 코딩 프레임워크는 **AI가 무엇을 하는지** — 코드 생성, 테스트 실행, 배포에 집중합니다. 하지만 진짜 문제는 능력이 아닙니다. **방향**입니다.
 
-기존 AI 코딩 프레임워크는 **AI가 무엇을 하는지**(코드 생성, 테스트 실행, 배포)에 집중합니다.
-kode:harness는 **AI가 어디로 가는지** — 모든 개발자의 AI가 같은 방향으로 움직이는지에 집중합니다.
+혼자 개발하면 방향이 일관됩니다. 하지만 팀에서는 각 개발자의 AI가 독립적으로 이탈합니다. 그리고 혼자 개발해도 세션 간 방향을 잃습니다 — 우리가 **컨텍스트 부패(Context Rot)**라 부르는 현상입니다. AI는 아키텍처 결정을 잊고, 확정된 사항을 재논의하며, 자신의 이전 작업과 모순됩니다.
 
-이것은 개별 AI가 제멋대로 움직이는 것과, harness 기반 방향 관리 기법이 팀 전체를 한 방향으로 이끄는 것의 차이입니다.
+kode:harness는 **AI가 어디로 가는지**에 집중합니다. 개발자, IDE, 시간을 넘어 모든 AI 세션에 동일한 목표, 결정, 프로젝트 상태를 제공합니다. 이 근간이 되는 원칙이 **harness engineering** — 어떤 LLM이든 읽을 수 있는 경량 마크다운 네이티브 가드레일입니다.
 
 ### Crew Artifact Integration (🟣 파이프라인)
 
@@ -292,7 +283,7 @@ Bootstrap이 `docs/crew/`, `docs/PM/`, `docs/Analyst/`, `docs/ARB/`에서 crew
 
 원본 crew 문서는 **절대 수정되지 않습니다**. 인덱스와 트래커만 생성됩니다.
 
-### 비교
+### 다른 프레임워크와의 비교
 
 | | BMAD v6.2.2 | gstack v0.15.1 | GSD v1.33.0 | **kode:harness** |
 |---|---|---|---|---|

package/README.md

@@ -9,67 +9,33 @@
 [![CI](https://github.com/AIDD-Projects/harness/actions/workflows/ci.yml/badge.svg)](https://github.com/AIDD-Projects/harness/actions/workflows/ci.yml)
 [![License: MIT](https://img.shields.io/badge/License-MIT-yellow.svg)](https://opensource.org/licenses/MIT)
 
-**Keep every developer's AI aligned on one project direction.**
+> **Your AI coding agent forgets everything between sessions. kode:harness makes it remember — goals, decisions, failures, and project direction.**
 
-kode:harness is built on **harness engineering** for multi-developer, enterprise-grade AI-assisted development.
+Production-grade guardrails for AI coding agents. Prevents context rot, enforces project direction, and persists state across sessions. Works with **Copilot, Claude, Cursor, Codex, Windsurf, and Gemini**. Zero dependencies.
 
-> **v0.9.0** — Naming redesign (clearer skill/agent names), 6 IDE support, Navigation Dispatcher, 5 Pipelines (🟢🔵🔴🟡🟣), Crew Artifact Integration.
-
-## From Harness to Enterprise Harness Engineering
-
-The concept of an AI "harness" — structured markdown files that guide LLM coding agents — has become a foundational pattern in AI-assisted development. Frameworks like BMAD, gstack, and GSD pioneered this approach for **solo developers**.
-
-This approach takes harness engineering beyond solo tooling. It evolves the harness concept into an **enterprise-grade direction management method** for both multi-developer teams and solo developers. **kode:harness** is the product form of that approach.
-
-| | Traditional Harness | kode:harness + harness engineering |
-|---|---|---|
-| Target | Solo developer | **Multi-developer teams** |
-| Focus | What the AI does | **Where the AI is going** |
-| Direction management | ❌ | ✅ Direction Guard + pivot + Decision Log |
-| Team state sharing | ❌ | ✅ Shared/personal state separation |
-| Token budget | 200+ files | **~25 files (~17K tokens)** — works with small LLMs too |
-
-## The Problem
-
-When one developer uses an AI coding assistant, direction stays consistent. But in **enterprise teams**, each developer runs their own AI sessions — and each AI drifts independently. Developer A's AI refactors toward microservices while Developer B's AI doubles down on the monolith. Without shared direction management, **AI agents across multiple developers pull the project apart.**
-
-kode:harness solves this. It gives every developer's AI the same goals, non-goals, decisions, and project state — so all AI sessions converge on **one direction**, regardless of who's coding or which IDE they use.
-
-## What It Does
-
-kode:harness manages your **project's direction** — goals, decisions, scope — so LLM coding agents stay aligned **across developers and sessions**. Zero dependencies, 6 IDE support, native format generation. The underlying approach is harness engineering for multi-developer and enterprise-grade execution.
-
-- **Direction Guard** — Every coding request is checked against project goals/non-goals before execution
-- **Navigation Dispatcher** — 🧭 Turn-by-Turn navigation guides developers through 5 pipelines with explicit next-step prompts
-- **5 Pipelines** — 🟢 New Dev → 🟕 Continue → 🟤 Bug Fix → 🟡 Direction Change → 🟣 Crew-Driven (external planning artifact integration)
-- **Crew Artifact Integration** — Reads external planning output (PRD, Architecture, ARB Checklist) directly — no manual copy needed
-- **State Files** — 5 markdown files that persist project knowledge across LLM sessions
-- **Skills** — Step-by-step procedures for planning, review, debugging, and direction changes
-- **Agents** — Role-based personas that enforce the workflow (pm, reviewer, lead)
-- **Failure Patterns** — Project-specific failure log that prevents repeat mistakes
-- **Decision Log** — Records why decisions were made so LLMs don't re-debate settled choices
+---
 
 ## Quick Start
 
 ```bash
-# Solo mode (default)
-npx @kodevibe/harness init
-
-# Team mode (multi-developer)
-npx @kodevibe/harness init --team
+npx @kodevibe/harness init          # pick your IDE
 ```
 
-Select your IDE when prompted. Files are installed into the current directory.
-
-After installation, ask your LLM to run the `setup` skill:
-
+```bash
+# Then tell your AI agent:
 > "Run setup to onboard this project."
+```
 
-This scans your codebase and fills all 5 state files automatically.
+That's it. Your AI now has persistent memory, direction guardrails, and self-correction loops.
 
-### Non-interactive
+<details>
+<summary>More install options</summary>
 
 ```bash
+# Team mode (multi-developer direction alignment)
+npx @kodevibe/harness init --team
+
+# Non-interactive (CI/scripts)
 npx @kodevibe/harness init --ide vscode
 npx @kodevibe/harness init --ide claude
 npx @kodevibe/harness init --ide cursor
@@ -78,8 +44,6 @@ npx @kodevibe/harness init --ide windsurf
 npx @kodevibe/harness init --ide antigravity
 ```
 
-### Options
-
 | Flag | Description |
 |------|-------------|
 | `--ide <name>` | Target IDE: `vscode`, `claude`, `cursor`, `codex`, `windsurf`, `antigravity` |
@@ -90,28 +54,59 @@ npx @kodevibe/harness init --ide antigravity
 | `--overwrite` | Overwrite existing files (including state files) |
 | `--version` | Show version number |
 
-### Health Check
+</details>
 
-```bash
-# Verify kode:harness files are installed
-npx @kodevibe/harness doctor
+---
 
-# Verify state files have real content (not just placeholders)
-npx @kodevibe/harness validate
-```
+## The Problem: Context Rot
+
+Your AI coding agent starts every session from zero. By session 3, it's forgotten the architecture decisions from session 1. By session 10, it's re-debating settled choices and contradicting its own earlier work.
+
+In teams, it's worse — Developer A's AI refactors toward microservices while Developer B's AI doubles down on the monolith. **Without shared guardrails, AI agents pull the project apart.**
+
+kode:harness solves this with three mechanisms:
+
+| Mechanism | What it prevents |
+|-----------|-----------------|
+| **State Persistence** | AI forgetting goals, decisions, and progress between sessions |
+| **Direction Guard** | AI drifting away from project goals or contradicting past decisions |
+| **Failure Patterns** | AI repeating the same mistakes across sessions |
 
-### IDE Configuration (Optional)
+---
 
-Large projects with crew artifacts may require increased turn limits:
+## Why not just...?
 
-| IDE | Setting | Recommended |
-|-----|---------|-------------|
-| VS Code | `chat.agent.maxRequests` in settings.json | `100` |
-| Cursor | Auto-managed | Default OK |
-| Windsurf | Auto-managed | Default OK |
-| Claude Code | Terminal-based | Default OK |
+| Approach | Limitation | kode:harness difference |
+|----------|-----------|------------------------|
+| **`.cursorrules` / `copilot-instructions.md`** | Static. No state persistence, no self-correction, no cross-session memory. | Living state files that update every session. Direction Guard checks every request against goals. |
+| **LangChain / CrewAI** | Runtime orchestration for building AI apps. Not for directing AI coding agents. | Markdown-native guardrails that work inside your IDE. No runtime, no SDK. |
+| **BMAD / gstack / GSD** | Built for solo developers. 200+ files. No direction management. | ~25 files (~17K tokens). Direction Guard + Decision Log. Multi-developer team support. |
+| **"I'll just be careful"** | Works until you forget. LLMs don't learn from past sessions. | Automated: `wrap-up` captures lessons, `debug` tracks failures, `reviewer` audits state. |
 
-> This is only needed when running `setup` with crew artifacts on projects that have many existing frameworks. Normal coding/review operations work within default limits.
+---
+
+## What It Does
+
+| Feature | Description |
+|---------|-------------|
+| 🛡️ **Direction Guard** | Every coding request is checked against project goals/non-goals before execution |
+| 🧭 **Navigation Dispatcher** | Turn-by-Turn navigation through 5 pipelines with copy-paste next-step prompts |
+| 📝 **State Persistence** | 5 markdown files that persist project knowledge across LLM sessions |
+| 🔄 **5 Pipelines** | 🟢 New Dev → 🔵 Continue → 🔴 Bug Fix → 🟡 Direction Change → 🟣 Crew-Driven |
+| 🛠️ **10 Skills** | Step-by-step procedures: setup, debug, breakdown, review, pivot, and more |
+| 🤖 **4 Agents** | Role-based personas: pm, reviewer, lead, architect |
+| ⚠️ **Failure Patterns** | Project-specific failure log that prevents repeat mistakes across sessions |
+| 📋 **Decision Log** | Records why decisions were made so LLMs don't re-debate settled choices |
+| 🟣 **Crew Artifact Integration** | Reads external planning output (PRD, Architecture, ARB Checklist) directly |
+
+---
+
+## Health Check
+
+```bash
+npx @kodevibe/harness doctor    # verify files are installed
+npx @kodevibe/harness validate  # verify state files have real content
+```
 
 ## Supported IDEs
 
@@ -240,11 +235,13 @@ These 8 rules are enforced across all skills and agents. They form the quality b
 
 See [docs/reference.md](docs/reference.md) for detailed descriptions of every skill, agent, rule, and state file.
 
-## Why kode:harness?
+## Why We Built This
+
+Existing AI coding frameworks focus on **what the AI does** — generate code, run tests, deploy. But the real problem isn't capability. It's **direction**.
 
-### The Core Insight
+When one developer uses AI, direction stays consistent. But in teams, each developer's AI drifts independently. And even solo developers lose direction across sessions — what we call **Context Rot**. The AI forgets architecture decisions, re-debates settled choices, and contradicts its own earlier work.
 
-Existing AI coding frameworks focus on **what the AI does** (generate code, run tests, deploy). kode:harness focuses on **where the AI is going** — ensuring every developer's AI moves in the same direction. harness engineering is the discipline that keeps the whole team on course.
+kode:harness focuses on **where the AI is going**. It gives every AI session — across developers, across IDEs, across time — the same goals, decisions, and project state. The underlying discipline is **harness engineering**: lightweight, markdown-native guardrails that any LLM can read.
 
 ### Crew Artifact Integration (🟣 Pipeline)
 
@@ -262,7 +259,7 @@ Bootstrap auto-detects crew artifacts in `docs/crew/`, `docs/PM/`, `docs/Analyst
 
 Original crew documents are **never modified**. Only the index and tracker are created.
 
-### Comparison
+### How It Compares
 
 | | BMAD v6.2.2 | gstack v0.15.1 | GSD v1.33.0 | kode:harness |
 |---|---|---|---|---|

package/harness/agents/pm.md

@@ -63,6 +63,36 @@ Apply these insights when creating the implementation plan. If the memory file i
 
 > **Team Mode**: In Team mode, agent memory is personal (`.harness/agent-memory/`). Each developer accumulates their own planning insights.
 
+### Step 0.7: Feature Roadmap Planning (Draft & Correct)
+
+**Trigger**: `docs/project-brief.md`에 `## Feature Roadmap` 섹션이 없을 때
+
+<!-- CREW_MODE_START -->
+**Crew 파이프라인(🟣)**: FR목록이 이미 Roadmap 역할을 하므로 이 Step을 skip한다.
+<!-- CREW_MODE_END -->
+
+1. `docs/project-brief.md`의 Goals + `docs/dependency-map.md`의 현재 모듈 구조를 읽는다
+2. Phase 구조의 Feature Roadmap **초안**을 생성한다:
+   ```
+   ## Feature Roadmap
+   
+   ### Phase 1 — Core (Goal 달성 필수)
+   - [ ] F-001: [기능명] — [어떤 Goal에 대응하는지]
+   - [ ] F-002: ...
+   
+   ### Phase 2 — Enhancement (사용성/완성도)
+   - [ ] F-003: ...
+   
+   ### Phase 3 — Nice-to-have
+   - [ ] F-004: ...
+   ```
+3. 사용자에게 초안을 제시한다: **"이 Feature Roadmap을 검토하고, 추가/삭제/순서 변경을 알려주세요."**
+   > **물어보지 말고, 초안을 만들어서 교정받는다.** 빈 칸을 채우는 것보다 틀린 것을 고치는 것이 쉽다.
+4. 사용자 교정을 반영한 최종 Roadmap을 `docs/project-brief.md`에 `## Feature Roadmap` 섹션으로 기록한다
+5. Feature Roadmap이 확정되면 아래 "For New Feature" 절차로 진행한다
+
+> **pivot 이후**: pivot이 `project-brief.md`를 업데이트하면, pm은 변경된 Roadmap을 읽고 Checkpoint에서 반영한다.
+
 ### For New Feature
 
 1. Read `docs/project-brief.md` to understand project vision, goals, **non-goals**, and **Decision Log**
@@ -249,6 +279,50 @@ Use this format when Crew Artifact Index exists in project-brief.md. If no Artif
 ```
 <!-- CREW_MODE_END -->
 
+## Sprint Completion Checkpoint
+
+**Trigger**: 현재 Sprint의 모든 Story가 ✅ 완료되었을 때 (reviewer pass → pm checkpoint)
+
+이 절차는 Sprint 종료 시 자동으로 실행된다. "계속할까요?"가 아니라 **구체적 선택을 강제**한다.
+
+### 절차
+
+1. **진척 현황 읽기**:
+<!-- CREW_MODE_START -->
+   - 🟣 crew 파이프라인: `docs/project-brief.md`의 Validation Tracker에서 FR Coverage를 읽는다
+<!-- CREW_MODE_END -->
+   - 🟢🔵 no-crew 파이프라인: `docs/project-brief.md`의 Feature Roadmap을 읽는다
+
+2. **Phase별 진척 표시**:
+   ```
+   📊 Feature Roadmap Progress
+   Phase 1 (Core):        ████████░░ 4/5
+   Phase 2 (Enhancement): ░░░░░░░░░░ 0/3
+   Phase 3 (Nice-to-have): ░░░░░░░░░░ 0/2
+   ```
+
+3. **선택지 제시** (Yes/No 아님 — Selection Forcing):
+   ```
+   다음 Sprint에 포함할 기능을 선택하세요:
+
+   Phase 1 (Core) — 미완료:
+     [ ] F-005: [기능명]
+
+   Phase 2 (Enhancement):
+     [ ] F-006: [기능명]
+     [ ] F-007: [기능명]
+
+   🏁 마무리: 현재 상태로 프로젝트를 완료하고 wrap-up 진행
+   ```
+   > **"계속"은 선택지에 없다.** 사용자는 구체적 기능을 골라야 하거나, 명시적으로 "마무리"를 선택해야 한다.
+
+4. **사용자 선택에 따라 분기**:
+   - **기능 선택** → 선택된 기능으로 Sprint 계획 (위의 "For New Feature" 절차 진행)
+   - **"마무리" 선택** → 🧭 Next Step을 `wrap-up`으로 출력
+   - Feature Roadmap에 없는 기능 추가 요청 → Roadmap에 먼저 추가한 후 Sprint 계획
+
+5. **Roadmap 업데이트**: 완료된 기능의 체크박스를 `[x]`로 변경하고 `docs/project-brief.md`에 기록
+
 ### Architecture Query Response
 ```markdown
 ## Module: [name]

package/harness/core-rules.md

@@ -98,7 +98,7 @@ When a skill or agent reports STATUS: DONE, output the next step in this format:
 | `lead` (story started) | [Coding] | "S{N}-{M} 구현을 시작해줘" → 완료 후 **새 채팅**에서 `@reviewer` 호출 |
 | [Coding done] | `reviewer` | "S{N}-{M} 코드를 리뷰해줘" |
 | `reviewer` (pass, more stories) | Commit → `lead` | \"커밋 후 다음 Story는?\" |
-| `reviewer` (pass, all done) | Commit → `wrap-up` | \"커밋 후 세션 마무리해줘\" |
+| `reviewer` (pass, sprint all done) | Commit → `pm` checkpoint | \"커밋 후 Sprint 완료 — pm checkpoint 실행\" |
 | `reviewer` (STATE-AUDIT) | `wrap-up` | "state 파일을 정리하고 세션 마무리해줘" |
 | `debug` | `reviewer` | "수정한 코드를 리뷰해줘" |
 | `pivot` | `pm` | "변경된 방향에 맞춰 재계획해줘" |

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "@kodevibe/harness",
-  "version": "0.9.0",
+  "version": "0.9.1",
   "description": "kode:harness — harness engineering for keeping every developer's AI aligned on one project direction.",
   "keywords": [
     "llm",