golem15/msd-core
4
0
Fork 0
Code Issues 1 Pull Requests Actions 3 Packages Projects Releases Wiki Activity

refactor: hard-fork GSD -> MSD (Make Software Done)

Browse Source 
Mechanical rename produced by scripts/msd-rename.cjs: gsd/Gsd/GSD -> msd/Msd/MSD
across contents and paths, upstream package/repo coordinates -> @golem15/msd-core
and golem15com/msd-core. Deep links into upstream history, sibling upstream
packages, the GSD-2 import feature, CHANGELOG.md and .changeset/ are kept as-is.

Hand edits on top: MSD block-letter banner and logos, LICENSE copyright line,
package/plugin identity, regenerated lockfile, install-tree fixtures, derived
registries and benchmark baseline; migration checksum baseline re-locked
(MSD keeps its own install state, so no install had applied the old sums);
sort-order and regex-escaped expectations in tests adjusted.
This commit is contained in:
Jakub Zych
2026-10-06 01:47:40 +02:00
parent fe069b2a56
commit a9a7a328e6
2763 changed files with 78465 additions and 78434 deletions
Download Patch File Download Diff File Expand all files Collapse all files

76
docs/ko-KR/AGENTS.md
View File

@@ -1,4 +1,4 @@
# GSD 에이전트 레퍼런스
# MSD 에이전트 레퍼런스
> 18개의 전문화된 에이전트 (v1.32 기준) — 역할, 도구, 생성 패턴, 관계를 모두 포함합니다. 아키텍처 맥락은 [Architecture](ARCHITECTURE.md)를 참조하세요.
@@ -6,7 +6,7 @@
## 개요
GSD는 멀티 에이전트 아키텍처를 사용합니다. 가벼운 오케스트레이터(워크플로우 파일)가 전문화된 에이전트를 새로운 컨텍스트 윈도우로 생성합니다. 각 에이전트는 집중된 역할, 제한된 도구 접근 권한을 가지며 특정 결과물을 생성합니다.
MSD는 멀티 에이전트 아키텍처를 사용합니다. 가벼운 오케스트레이터(워크플로우 파일)가 전문화된 에이전트를 새로운 컨텍스트 윈도우로 생성합니다. 각 에이전트는 집중된 역할, 제한된 도구 접근 권한을 가지며 특정 결과물을 생성합니다.
### 에이전트 카테고리
@@ -28,13 +28,13 @@ GSD는 멀티 에이전트 아키텍처를 사용합니다. 가벼운 오케스
## 에이전트 상세
### gsd-project-researcher
### msd-project-researcher
**역할:** 로드맵 생성 전에 도메인 생태계를 조사합니다.
| 속성 | 값 |
|----------|-------|
| **생성 주체** | `/gsd-new-project`, `/gsd-new-milestone` |
| **생성 주체** | `/msd-new-project`, `/msd-new-milestone` |
| **병렬성** | 4개 인스턴스 (stack, features, architecture, pitfalls) |
| **도구** | Read, Write, Bash, Grep, Glob, WebSearch, WebFetch, mcp (context7) |
| **모델 (balanced)** | Sonnet |
@@ -47,13 +47,13 @@ GSD는 멀티 에이전트 아키텍처를 사용합니다. 가벼운 오케스
---
### gsd-phase-researcher
### msd-phase-researcher
**역할:** 계획 수립 전에 특정 단계의 구현 방법을 조사합니다.
| 속성 | 값 |
|----------|-------|
| **생성 주체** | `/gsd-plan-phase` |
| **생성 주체** | `/msd-plan-phase` |
| **병렬성** | 4개 인스턴스 (project-researcher와 동일한 집중 영역) |
| **도구** | Read, Write, Bash, Grep, Glob, WebSearch, WebFetch, mcp (context7) |
| **모델 (balanced)** | Sonnet |
@@ -66,13 +66,13 @@ GSD는 멀티 에이전트 아키텍처를 사용합니다. 가벼운 오케스
---
### gsd-ui-researcher
### msd-ui-researcher
**역할:** 프론트엔드 단계를 위한 UI 디자인 계약서를 생성합니다.
| 속성 | 값 |
|----------|-------|
| **생성 주체** | `/gsd-ui-phase` |
| **생성 주체** | `/msd-ui-phase` |
| **병렬성** | 단일 인스턴스 |
| **도구** | Read, Write, Bash, Grep, Glob, WebSearch, WebFetch, mcp (context7) |
| **모델 (balanced)** | Sonnet |
@@ -87,7 +87,7 @@ GSD는 멀티 에이전트 아키텍처를 사용합니다. 가벼운 오케스
---
### gsd-assumptions-analyzer
### msd-assumptions-analyzer
**역할:** 단계에 대한 코드베이스를 심층 분석하고 증거, 신뢰 수준, 오류 시 결과를 포함한 구조화된 가정을 반환합니다.
@@ -110,7 +110,7 @@ GSD는 멀티 에이전트 아키텍처를 사용합니다. 가벼운 오케스
---
### gsd-advisor-researcher
### msd-advisor-researcher
**역할:** discuss-phase 어드바이저 모드에서 단일 회색 지대 결정을 조사하고 구조화된 비교 표를 반환합니다.
@@ -132,13 +132,13 @@ GSD는 멀티 에이전트 아키텍처를 사용합니다. 가벼운 오케스
---
### gsd-research-synthesizer
### msd-research-synthesizer
**역할:** 병렬 조사자들의 출력을 통합된 요약으로 합칩니다.
| 속성 | 값 |
|----------|-------|
| **생성 주체** | `/gsd-new-project` (4개 조사자 완료 후) |
| **생성 주체** | `/msd-new-project` (4개 조사자 완료 후) |
| **병렬성** | 단일 인스턴스 (조사자 이후 순차적) |
| **도구** | Read, Write, Bash |
| **모델 (balanced)** | Sonnet |
@@ -147,13 +147,13 @@ GSD는 멀티 에이전트 아키텍처를 사용합니다. 가벼운 오케스
---
### gsd-planner
### msd-planner
**역할:** 작업 분류, 의존성 분석, 목표 역방향 검증을 포함한 실행 가능한 단계 계획을 생성합니다.
| 속성 | 값 |
|----------|-------|
| **생성 주체** | `/gsd-plan-phase`, `/gsd-quick` |
| **생성 주체** | `/msd-plan-phase`, `/msd-quick` |
| **병렬성** | 단일 인스턴스 |
| **도구** | Read, Write, Bash, Glob, Grep, WebFetch, mcp (context7) |
| **모델 (balanced)** | Opus |
@@ -169,13 +169,13 @@ GSD는 멀티 에이전트 아키텍처를 사용합니다. 가벼운 오케스
---
### gsd-roadmapper
### msd-roadmapper
**역할:** 단계 분류 및 요구 사항 매핑을 포함한 프로젝트 로드맵을 생성합니다.
| 속성 | 값 |
|----------|-------|
| **생성 주체** | `/gsd-new-project` |
| **생성 주체** | `/msd-new-project` |
| **병렬성** | 단일 인스턴스 |
| **도구** | Read, Write, Bash, Glob, Grep |
| **모델 (balanced)** | Sonnet |
@@ -190,13 +190,13 @@ GSD는 멀티 에이전트 아키텍처를 사용합니다. 가벼운 오케스
---
### gsd-executor
### msd-executor
**역할:** 원자적 커밋, 이탈 처리, 체크포인트 프로토콜로 GSD 계획을 실행합니다.
**역할:** 원자적 커밋, 이탈 처리, 체크포인트 프로토콜로 MSD 계획을 실행합니다.
| 속성 | 값 |
|----------|-------|
| **생성 주체** | `/gsd-execute-phase`, `/gsd-quick` |
| **생성 주체** | `/msd-execute-phase`, `/msd-quick` |
| **병렬성** | 복수 (웨이브 내 병렬, 웨이브 간 순차적) |
| **도구** | Read, Write, Edit, Bash, Grep, Glob |
| **모델 (balanced)** | Sonnet |
@@ -213,13 +213,13 @@ GSD는 멀티 에이전트 아키텍처를 사용합니다. 가벼운 오케스
---
### gsd-plan-checker
### msd-plan-checker
**역할:** 실행 전에 계획이 단계 목표를 달성할 수 있는지 검증합니다.
| 속성 | 값 |
|----------|-------|
| **생성 주체** | `/gsd-plan-phase` (검증 루프, 최대 3회 반복) |
| **생성 주체** | `/msd-plan-phase` (검증 루프, 최대 3회 반복) |
| **병렬성** | 단일 인스턴스 (반복적) |
| **도구** | Read, Bash, Glob, Grep |
| **모델 (balanced)** | Sonnet |
@@ -238,13 +238,13 @@ GSD는 멀티 에이전트 아키텍처를 사용합니다. 가벼운 오케스
---
### gsd-integration-checker
### msd-integration-checker
**역할:** 단계 간 통합 및 엔드투엔드 흐름을 검증합니다.
| 속성 | 값 |
|----------|-------|
| **생성 주체** | `/gsd-audit-milestone` |
| **생성 주체** | `/msd-audit-milestone` |
| **병렬성** | 단일 인스턴스 |
| **도구** | Read, Bash, Grep, Glob |
| **모델 (balanced)** | Sonnet |
@@ -253,13 +253,13 @@ GSD는 멀티 에이전트 아키텍처를 사용합니다. 가벼운 오케스
---
### gsd-ui-checker
### msd-ui-checker
**역할:** 품질 차원에 대해 UI-SPEC.md 디자인 계약서를 검증합니다.
| 속성 | 값 |
|----------|-------|
| **생성 주체** | `/gsd-ui-phase` (검증 루프, 최대 2회 반복) |
| **생성 주체** | `/msd-ui-phase` (검증 루프, 최대 2회 반복) |
| **병렬성** | 단일 인스턴스 |
| **도구** | Read, Bash, Glob, Grep |
| **모델 (balanced)** | Sonnet |
@@ -268,13 +268,13 @@ GSD는 멀티 에이전트 아키텍처를 사용합니다. 가벼운 오케스
---
### gsd-verifier
### msd-verifier
**역할:** 목표 역방향 분석을 통해 단계 목표 달성 여부를 검증합니다.
| 속성 | 값 |
|----------|-------|
| **생성 주체** | `/gsd-execute-phase` (모든 executor 완료 후) |
| **생성 주체** | `/msd-execute-phase` (모든 executor 완료 후) |
| **병렬성** | 단일 인스턴스 |
| **도구** | Read, Write, Bash, Grep, Glob |
| **모델 (balanced)** | Sonnet |
@@ -284,17 +284,17 @@ GSD는 멀티 에이전트 아키텍처를 사용합니다. 가벼운 오케스
**핵심 동작.**
- 작업 완료 여부가 아닌 단계 목표에 대해 코드베이스를 확인합니다
- 구체적인 증거를 포함한 PASS/FAIL 결과를 제공합니다
- `/gsd-verify-work`가 처리할 문제를 기록합니다
- `/msd-verify-work`가 처리할 문제를 기록합니다
---
### gsd-nyquist-auditor
### msd-nyquist-auditor
**역할:** 테스트를 생성하여 Nyquist 검증 누락을 채웁니다.
| 속성 | 값 |
|----------|-------|
| **생성 주체** | `/gsd-validate-phase` |
| **생성 주체** | `/msd-validate-phase` |
| **병렬성** | 단일 인스턴스 |
| **도구** | Read, Write, Edit, Bash, Grep, Glob |
| **모델 (balanced)** | Sonnet |
@@ -307,13 +307,13 @@ GSD는 멀티 에이전트 아키텍처를 사용합니다. 가벼운 오케스
---
### gsd-ui-auditor
### msd-ui-auditor
**역할:** 구현된 프론트엔드 코드에 대한 사후 6기둥 시각적 감사를 수행합니다.
| 속성 | 값 |
|----------|-------|
| **생성 주체** | `/gsd-ui-review` |
| **생성 주체** | `/msd-ui-review` |
| **병렬성** | 단일 인스턴스 |
| **도구** | Read, Write, Bash, Grep, Glob |
| **모델 (balanced)** | Sonnet |
@@ -330,13 +330,13 @@ GSD는 멀티 에이전트 아키텍처를 사용합니다. 가벼운 오케스
---
### gsd-codebase-mapper
### msd-codebase-mapper
**역할:** 코드베이스를 탐색하고 구조화된 분석 문서를 작성합니다.
| 속성 | 값 |
|----------|-------|
| **생성 주체** | `/gsd-map-codebase` |
| **생성 주체** | `/msd-map-codebase` |
| **병렬성** | 4개 인스턴스 (tech, architecture, quality, concerns) |
| **도구** | Read, Bash, Grep, Glob, Write |
| **모델 (balanced)** | Haiku |
@@ -350,13 +350,13 @@ GSD는 멀티 에이전트 아키텍처를 사용합니다. 가벼운 오케스
---
### gsd-debugger
### msd-debugger
**역할:** 영구 상태를 활용한 과학적 방법으로 버그를 조사합니다.
| 속성 | 값 |
|----------|-------|
| **생성 주체** | `/gsd-debug`, `/gsd-verify-work` (실패 시) |
| **생성 주체** | `/msd-debug`, `/msd-verify-work` (실패 시) |
| **병렬성** | 단일 인스턴스 (대화형) |
| **도구** | Read, Write, Edit, Bash, Grep, Glob, WebSearch |
| **모델 (balanced)** | Sonnet |
@@ -375,13 +375,13 @@ GSD는 멀티 에이전트 아키텍처를 사용합니다. 가벼운 오케스
---
### gsd-user-profiler
### msd-user-profiler
**역할:** 8가지 행동 차원에 걸쳐 세션 메시지를 분석하여 점수화된 개발자 프로필을 생성합니다.
| 속성 | 값 |
|----------|-------|
| **생성 주체** | `/gsd-profile-user` |
| **생성 주체** | `/msd-profile-user` |
| **병렬성** | 단일 인스턴스 |
| **도구** | Read |
| **모델 (balanced)** | Sonnet |

204
docs/ko-KR/ARCHITECTURE.md
View File

@@ -1,4 +1,4 @@
# GSD Core 아키텍처
# MSD Core 아키텍처
> 기여자와 고급 사용자를 위한 시스템 아키텍처. 사용자 문서는 [기능 레퍼런스](FEATURES.md) 또는 [사용자 가이드](USER-GUIDE.md)를 참조하라.
@@ -21,7 +21,7 @@
## 시스템 개요
GSD Core는 사용자와 AI 코딩 에이전트(Claude Code, Kimi CLI, OpenCode, Kilo, Codex, Copilot, Antigravity, Trae, Cline, Augment Code) 사이에 위치하는 **메타 프롬프팅 프레임워크**이다. 다음을 제공한다:
MSD Core는 사용자와 AI 코딩 에이전트(Claude Code, Kimi CLI, OpenCode, Kilo, Codex, Copilot, Antigravity, Trae, Cline, Augment Code) 사이에 위치하는 **메타 프롬프팅 프레임워크**이다. 다음을 제공한다:
1. **컨텍스트 엔지니어링** — 작업별로 AI에게 필요한 모든 것을 제공하는 구조화된 결과물([컨텍스트 엔지니어링](explanation/context-engineering.md) 참조)
2. **다중 에이전트 오케스트레이션** — 신선한 컨텍스트 윈도우로 전문화된 에이전트를 생성하는 얇은 오케스트레이터([다중 에이전트 오케스트레이션](explanation/multi-agent-orchestration.md) 참조)
@@ -31,18 +31,18 @@ GSD Core는 사용자와 AI 코딩 에이전트(Claude Code, Kimi CLI, OpenCode,
```
┌──────────────────────────────────────────────────────┐
│ USER │
│ /gsd-command [args] │
│ /msd-command [args] │
└─────────────────────┬────────────────────────────────┘
│
┌─────────────────────▼────────────────────────────────┐
│ COMMAND LAYER │
│ commands/gsd/*.md — Prompt-based command files │
│ commands/msd/*.md — Prompt-based command files │
│ (Claude Code custom commands / Codex skills) │
└─────────────────────┬────────────────────────────────┘
│
┌─────────────────────▼────────────────────────────────┐
│ WORKFLOW LAYER │
│ gsd-core/workflows/*.md — Orchestration logic │
│ msd-core/workflows/*.md — Orchestration logic │
│ (Reads references, spawns agents, manages state) │
└──────┬──────────────┬─────────────────┬──────────────┘
│ │ │
@@ -54,7 +54,7 @@ GSD Core는 사용자와 AI 코딩 에이전트(Claude Code, Kimi CLI, OpenCode,
│ │ │
┌──────▼──────────────▼─────────────────▼──────────────┐
│ CLI TOOLS LAYER │
│ gsd-tools.cjs command families + domain modules │
│ msd-tools.cjs command families + domain modules │
│ command-routing-hub + observability seams │
└──────────────────────┬───────────────────────────────┘
│
@@ -75,9 +75,9 @@ GSD Core는 사용자와 AI 코딩 에이전트(Claude Code, Kimi CLI, OpenCode,
### 2. 얇은 오케스트레이터
워크플로우 파일(`gsd-core/workflows/*.md`)은 무거운 작업을 직접 수행하지 않는다. 오케스트레이터가 하는 것:
워크플로우 파일(`msd-core/workflows/*.md`)은 무거운 작업을 직접 수행하지 않는다. 오케스트레이터가 하는 것:
- `gsd-tools.cjs init <workflow>`로 컨텍스트 로드
- `msd-tools.cjs init <workflow>`로 컨텍스트 로드
- 집중된 프롬프트로 전문화된 에이전트 생성
- 결과 수집 및 다음 단계로 라우팅
- 단계 사이에 상태 업데이트
@@ -107,33 +107,33 @@ GSD Core는 사용자와 AI 코딩 에이전트(Claude Code, Kimi CLI, OpenCode,
## 컴포넌트 아키텍처
### Commands (`commands/gsd/*.md`)
### Commands (`commands/msd/*.md`)
사용자 대면 진입점. 각 파일은 YAML 전문(name, description, allowed-tools)과 워크플로우를 부트스트랩하는 프롬프트 본문을 포함한다. 명령어는 다음과 같이 설치된다:
- **Claude Code:** 커스텀 슬래시 명령어 (하이픈 형식, `/gsd-command-name`)
- **OpenCode / Kilo:** 슬래시 명령어 (하이픈 형식, `/gsd-command-name`)
- **Codex:** Skills (`$gsd-command-name`)
- **Copilot:** 슬래시 명령어 (하이픈 형식, `/gsd-command-name`)
- **Claude Code:** 커스텀 슬래시 명령어 (하이픈 형식, `/msd-command-name`)
- **OpenCode / Kilo:** 슬래시 명령어 (하이픈 형식, `/msd-command-name`)
- **Codex:** Skills (`$msd-command-name`)
- **Copilot:** 슬래시 명령어 (하이픈 형식, `/msd-command-name`)
- **Antigravity:** Skills
**전체 명령어 수:** 권위 있는 개수와 전체 목록은 [`docs/INVENTORY.md`](INVENTORY.md#commands)를 참조하라.
#### 2단계 계층적 라우팅 (v1.40, [#2792](https://github.com/open-gsd/gsd-core/issues/2792))
열망적 스킬 목록 토큰 비용을 낮게 유지하기 위해 v1.40은 구체적인 하위 스킬 위에 계층화된 여섯 개의 네임스페이스 **메타 스킬** (`gsd-workflow`, `gsd-project`, `gsd-quality`, `gsd-context`, `gsd-manage`, `gsd-ideate` — `commands/gsd/ns-*.md`에서 소싱되지만 호출 가능한 `name:`은 여기 표시된 간단한 형식)을 도입한다. 모델은 평평한 86개 스킬 목록(~2,150 토큰) 대신 6개의 네임스페이스 라우터(~120 토큰)를 보고, 네임스페이스를 선택한 다음 네임스페이스 라우터 본문에 내장된 라우팅 테이블을 통해 구체적인 하위 스킬로 라우팅한다. 네임스페이스 스킬은 **가산적**이다 — 모든 구체적인 명령어는 여전히 직접 호출 가능하다.
열망적 스킬 목록 토큰 비용을 낮게 유지하기 위해 v1.40은 구체적인 하위 스킬 위에 계층화된 여섯 개의 네임스페이스 **메타 스킬** (`msd-workflow`, `msd-project`, `msd-quality`, `msd-context`, `msd-manage`, `msd-ideate` — `commands/msd/ns-*.md`에서 소싱되지만 호출 가능한 `name:`은 여기 표시된 간단한 형식)을 도입한다. 모델은 평평한 86개 스킬 목록(~2,150 토큰) 대신 6개의 네임스페이스 라우터(~120 토큰)를 보고, 네임스페이스를 선택한 다음 네임스페이스 라우터 본문에 내장된 라우팅 테이블을 통해 구체적인 하위 스킬로 라우팅한다. 네임스페이스 스킬은 **가산적**이다 — 모든 구체적인 명령어는 여전히 직접 호출 가능하다.
라우터 설명은 ~40% 토큰 비용으로 프로세 대비 키워드 밀도 태그가 라우팅에서 더 뛰어나다는 Tool Attention 연구에 따라 도구당 파이프로 구분된 키워드 태그(≤ 60자)를 사용한다.
#### MCP 토큰 예산 상호작용
열망적 스킬 목록은 턴당 반복되는 두 가지 토큰 비용 중 하나이다. 다른 하나는 `.claude/settings.json`의 모든 활성화된 MCP 서버가 주입하는 MCP 도구 스키마이다. 무거운 MCP 서버(브라우저/playwright, Mac-tools, Windows-tools)는 각각 턴당 20k+ 토큰 비용이 들 수 있다 — 종종 `model_profile` 튜닝이 절약하는 것을 압도한다. 토글은 Claude Code 하니스(`.claude/settings.json`의 `enabledMcpjsonServers` / `disabledMcpjsonServers`)에 있으며 GSD 관심사가 아니다. 2단계 라우팅 계층(#2792)과 규율 있는 MCP 활성화를 함께 사용하는 것이 턴당 가장 큰 비용 레버이다. [`docs/USER-GUIDE.md`](USER-GUIDE.md)와 `references/context-budget.md`에서 감사 체크리스트를 참조하라.
열망적 스킬 목록은 턴당 반복되는 두 가지 토큰 비용 중 하나이다. 다른 하나는 `.claude/settings.json`의 모든 활성화된 MCP 서버가 주입하는 MCP 도구 스키마이다. 무거운 MCP 서버(브라우저/playwright, Mac-tools, Windows-tools)는 각각 턴당 20k+ 토큰 비용이 들 수 있다 — 종종 `model_profile` 튜닝이 절약하는 것을 압도한다. 토글은 Claude Code 하니스(`.claude/settings.json`의 `enabledMcpjsonServers` / `disabledMcpjsonServers`)에 있으며 MSD 관심사가 아니다. 2단계 라우팅 계층(#2792)과 규율 있는 MCP 활성화를 함께 사용하는 것이 턴당 가장 큰 비용 레버이다. [`docs/USER-GUIDE.md`](USER-GUIDE.md)와 `references/context-budget.md`에서 감사 체크리스트를 참조하라.
### Workflows (`gsd-core/workflows/*.md`)
### Workflows (`msd-core/workflows/*.md`)
명령어가 참조하는 오케스트레이션 로직. 다음을 포함하는 단계별 프로세스를 담는다:
- `gsd-tools.cjs init` 핸들러를 통한 컨텍스트 로딩
- `msd-tools.cjs init` 핸들러를 통한 컨텍스트 로딩
- 모델 해결을 포함한 에이전트 생성 지시
- 게이트/체크포인트 정의
- 상태 업데이트 패턴
@@ -143,7 +143,7 @@ GSD Core는 사용자와 AI 코딩 에이전트(Claude Code, Kimi CLI, OpenCode,
#### 워크플로우를 위한 점진적 공개
워크플로우 파일은 해당 `/gsd-*` 명령어가 호출될 때마다 Claude의 컨텍스트에 그대로 로드된다. 이 비용을 제한하기 위해 `tests/workflow-size-budget.test.cjs`가 시행하는 워크플로우 크기 예산은 에이전트 크기 예산 관례를 반영한다:
워크플로우 파일은 해당 `/msd-*` 명령어가 호출될 때마다 Claude의 컨텍스트에 그대로 로드된다. 이 비용을 제한하기 위해 `tests/workflow-size-budget.test.cjs`가 시행하는 워크플로우 크기 예산은 에이전트 크기 예산 관례를 반영한다:
| 등급 | 파일당 줄 제한 |
|-----------|--------------------|
@@ -151,7 +151,7 @@ GSD Core는 사용자와 AI 코딩 에이전트(Claude Code, Kimi CLI, OpenCode,
| `LARGE` | 1500 — 다단계 플래너 및 대형 기능 워크플로우 |
| `DEFAULT` | 1000 — 집중된 단일 목적 워크플로우 (목표 등급) |
`workflows/discuss-phase.md`는 discuss-phase 바이트 예산(#717; discuss-phase/modes 분할로 ≈32000 바이트 유지)에 따라 더 엄격한 상한을 유지한다. 워크플로우가 등급을 초과하면 모드별 본문은 `workflows/<workflow>/modes/<mode>.md`로, 템플릿은 `workflows/<workflow>/templates/`로, 공유 지식은 `gsd-core/references/`로 추출한다. 부모 파일은 현재 호출에 필요한 모드 및 템플릿 파일만 읽는 얇은 디스패처가 된다.
`workflows/discuss-phase.md`는 discuss-phase 바이트 예산(#717; discuss-phase/modes 분할로 ≈32000 바이트 유지)에 따라 더 엄격한 상한을 유지한다. 워크플로우가 등급을 초과하면 모드별 본문은 `workflows/<workflow>/modes/<mode>.md`로, 템플릿은 `workflows/<workflow>/templates/`로, 공유 지식은 `msd-core/references/`로 추출한다. 부모 파일은 현재 호출에 필요한 모드 및 템플릿 파일만 읽는 얇은 디스패처가 된다.
`workflows/discuss-phase/`가 이 패턴의 정규 예시이다 — 부모는 디스패치하고, modes/는 플래그별 동작(`power.md`, `all.md`, `auto.md`, `chain.md`, `text.md`, `batch.md`, `analyze.md`, `default.md`, `advisor.md`)을 담으며, templates/는 해당 출력 파일이 작성될 때만 읽히는 CONTEXT.md, DISCUSSION-LOG.md, checkpoint.json 스키마를 담는다.
@@ -166,7 +166,7 @@ GSD Core는 사용자와 AI 코딩 에이전트(Claude Code, Kimi CLI, OpenCode,
**전체 에이전트 수:** 33개
### References (`gsd-core/references/*.md`)
### References (`msd-core/references/*.md`)
워크플로우와 에이전트가 `@-reference`하는 공유 지식 문서([`docs/INVENTORY.md`](INVENTORY.md#references-41-shipped)에서 권위 있는 개수와 전체 목록 참조):
@@ -204,7 +204,7 @@ GSD Core는 사용자와 AI 코딩 에이전트(Claude Code, Kimi CLI, OpenCode,
**Thinking 모델 레퍼런스:**
GSD 워크플로우에 thinking 클래스 모델(o3, o4-mini, Gemini 2.5 Pro)을 통합하기 위한 레퍼런스:
MSD 워크플로우에 thinking 클래스 모델(o3, o4-mini, Gemini 2.5 Pro)을 통합하기 위한 레퍼런스:
- `thinking-models-debug.md` — 디버깅 워크플로우를 위한 thinking 모델 패턴
- `thinking-models-execution.md` — 실행 에이전트를 위한 thinking 모델 패턴
@@ -214,15 +214,15 @@ GSD 워크플로우에 thinking 클래스 모델(o3, o4-mini, Gemini 2.5 Pro)을
**모듈식 플래너 분해:**
플래너 에이전트(`agents/gsd-planner.md`)는 일부 런타임에서 부과하는 50K 문자 제한 이하로 유지하기 위해 단일 모놀리식 파일에서 핵심 에이전트 + 레퍼런스 모듈로 분해되었다:
플래너 에이전트(`agents/msd-planner.md`)는 일부 런타임에서 부과하는 50K 문자 제한 이하로 유지하기 위해 단일 모놀리식 파일에서 핵심 에이전트 + 레퍼런스 모듈로 분해되었다:
- `planner-gap-closure.md` — 갭 클로저 모드 동작 (VERIFICATION.md 읽기, 대상 재계획)
- `planner-reviews.md` — 교차 AI 리뷰 통합 (`/gsd-review`의 REVIEWS.md 읽기)
- `planner-reviews.md` — 교차 AI 리뷰 통합 (`/msd-review`의 REVIEWS.md 읽기)
- `planner-revision.md` — 반복적 개선을 위한 계획 수정 패턴
### Templates (`gsd-core/templates/`)
### Templates (`msd-core/templates/`)
모든 계획 결과물을 위한 마크다운 템플릿. `gsd-tools.cjs template fill` / `phase.scaffold`(와 최상위 `scaffold`)가 사전 구조화된 파일을 생성하는 데 사용:
모든 계획 결과물을 위한 마크다운 템플릿. `msd-tools.cjs template fill` / `phase.scaffold`(와 최상위 `scaffold`)가 사전 구조화된 파일을 생성하는 데 사용:
- `project.md`, `requirements.md`, `roadmap.md`, `state.md` — 핵심 프로젝트 파일
- `phase-prompt.md` — 단계 실행 프롬프트 템플릿
- `summary.md` (+ `summary-minimal.md`, `summary-standard.md`, `summary-complex.md`) — 세분화 인식 요약 템플릿
@@ -238,28 +238,28 @@ GSD 워크플로우에 thinking 클래스 모델(o3, o4-mini, Gemini 2.5 Pro)을
| 훅 | 이벤트 | 목적 |
|------|-------|---------|
| `gsd-statusline.js` | `statusLine` | 모델, 작업, 디렉터리, 컨텍스트 사용 바 표시 |
| `gsd-context-monitor.js` | `PostToolUse` / `AfterTool` | 잔여 35%/25% 시점에 에이전트 대면 컨텍스트 경고 주입 |
| `gsd-check-update.js` | `SessionStart` | 백그라운드 업데이트 확인을 위한 포어그라운드 트리거 |
| `gsd-check-update-worker.js` | (헬퍼) | `gsd-check-update.js`가 생성하는 백그라운드 워커; 직접 이벤트 등록 없음 |
| `gsd-prompt-guard.js` | `PreToolUse` | `.planning/` 쓰기에서 프롬프트 인젝션 패턴 스캔 (자문적) |
| `gsd-read-injection-scanner.js` | `PostToolUse` | 신뢰할 수 없는 콘텐츠에서 주입된 지시 사항을 위한 Read 도구 출력 스캔 |
| `gsd-workflow-guard.js` | `PreToolUse` | GSD 워크플로우 컨텍스트 외부의 파일 편집 감지 (자문적, `hooks.workflow_guard`를 통한 옵트인) |
| `gsd-secret-read-guard.js` | `PreToolUse` | Read / Grep / Bash로 `.env`, `.env.<suffix>`(`.env.example` 등 템플릿 제외), `.secrets`를 읽는 호출을 하드 차단. 설치 프로그램이 기록하던 `Read(.env*)` deny 규칙을 대체 (#4221) |
| `gsd-read-guard.js` | `PreToolUse` | 세션에서 아직 읽지 않은 파일에 Edit/Write를 방지하는 자문적 가드 |
| `gsd-session-state.sh` | `SessionStart` | 쉘 기반 런타임을 위한 세션 상태 추적 |
| `gsd-validate-commit.sh` | `PreToolUse` | 컨벤셔널 커밋 시행을 위한 커밋 검증 |
| `gsd-phase-boundary.sh` | `PostToolUse` | 워크플로우 전환을 위한 단계 경계 감지 |
| `msd-statusline.js` | `statusLine` | 모델, 작업, 디렉터리, 컨텍스트 사용 바 표시 |
| `msd-context-monitor.js` | `PostToolUse` / `AfterTool` | 잔여 35%/25% 시점에 에이전트 대면 컨텍스트 경고 주입 |
| `msd-check-update.js` | `SessionStart` | 백그라운드 업데이트 확인을 위한 포어그라운드 트리거 |
| `msd-check-update-worker.js` | (헬퍼) | `msd-check-update.js`가 생성하는 백그라운드 워커; 직접 이벤트 등록 없음 |
| `msd-prompt-guard.js` | `PreToolUse` | `.planning/` 쓰기에서 프롬프트 인젝션 패턴 스캔 (자문적) |
| `msd-read-injection-scanner.js` | `PostToolUse` | 신뢰할 수 없는 콘텐츠에서 주입된 지시 사항을 위한 Read 도구 출력 스캔 |
| `msd-workflow-guard.js` | `PreToolUse` | MSD 워크플로우 컨텍스트 외부의 파일 편집 감지 (자문적, `hooks.workflow_guard`를 통한 옵트인) |
| `msd-secret-read-guard.js` | `PreToolUse` | Read / Grep / Bash로 `.env`, `.env.<suffix>`(`.env.example` 등 템플릿 제외), `.secrets`를 읽는 호출을 하드 차단. 설치 프로그램이 기록하던 `Read(.env*)` deny 규칙을 대체 (#4221) |
| `msd-read-guard.js` | `PreToolUse` | 세션에서 아직 읽지 않은 파일에 Edit/Write를 방지하는 자문적 가드 |
| `msd-session-state.sh` | `SessionStart` | 쉘 기반 런타임을 위한 세션 상태 추적 |
| `msd-validate-commit.sh` | `PreToolUse` | 컨벤셔널 커밋 시행을 위한 커밋 검증 |
| `msd-phase-boundary.sh` | `PostToolUse` | 워크플로우 전환을 위한 단계 경계 감지 |
권위 있는 11개 훅 목록은 [`docs/INVENTORY.md`](INVENTORY.md#hooks-11-shipped)를 참조하라.
### Command Routing Hub (`gsd-core/bin/lib/command-routing-hub.cjs`)
### Command Routing Hub (`msd-core/bin/lib/command-routing-hub.cjs`)
CJS 명령어 패밀리 라우터는 `CommandRoutingHub`를 통해 디스패치한다. 허브는 no-throw 순수 결과 계약(`hub.dispatch()`는 내부 예외를 잡아 `{ ok: false, kind, ...typedPayload }`를 반환)과 닫힌 런타임 오류 분류(`UnknownCommand`, `InvalidArgs`, `HandlerRefusal`, `HandlerFailure`)를 소유한다. 라우터 어댑터는 얇은 CLI 번역기로 유지된다 — 허브를 구축하고, `dispatch`를 호출하고, 결과를 `output()`/`error()` 호출에 매핑한다. 런타임은 단일 경로이다(이중 런타임 모드 선택 없음). `docs/adr/0174-retire-gsd-sdk-package-boundary.md` 참조.
CJS 명령어 패밀리 라우터는 `CommandRoutingHub`를 통해 디스패치한다. 허브는 no-throw 순수 결과 계약(`hub.dispatch()`는 내부 예외를 잡아 `{ ok: false, kind, ...typedPayload }`를 반환)과 닫힌 런타임 오류 분류(`UnknownCommand`, `InvalidArgs`, `HandlerRefusal`, `HandlerFailure`)를 소유한다. 라우터 어댑터는 얇은 CLI 번역기로 유지된다 — 허브를 구축하고, `dispatch`를 호출하고, 결과를 `output()`/`error()` 호출에 매핑한다. 런타임은 단일 경로이다(이중 런타임 모드 선택 없음). `docs/adr/0174-retire-msd-sdk-package-boundary.md` 참조.
### CLI Tools (`gsd-core/bin/`)
### CLI Tools (`msd-core/bin/`)
`gsd-core/bin/lib/`에 걸쳐 분할된 도메인 모듈을 가진 Node.js CLI 유틸리티(`gsd-tools.cjs`)(권위 있는 목록은 [`docs/INVENTORY.md`](INVENTORY.md#cli-modules-33-shipped) 참조):
`msd-core/bin/lib/`에 걸쳐 분할된 도메인 모듈을 가진 Node.js CLI 유틸리티(`msd-tools.cjs`)(권위 있는 목록은 [`docs/INVENTORY.md`](INVENTORY.md#cli-modules-33-shipped) 참조):
| 모듈 | 책임 |
@@ -295,10 +295,10 @@ CJS 명령어 패밀리 라우터는 `CommandRoutingHub`를 통해 디스패치
```
오케스트레이터 (workflow .md)
│
├── 컨텍스트 로드: gsd-tools.cjs init <workflow> <phase>
├── 컨텍스트 로드: msd-tools.cjs init <workflow> <phase>
│ 반환 JSON: 프로젝트 정보, 설정, 상태, 단계 상세
│
├── 모델 해결: gsd-tools.cjs resolve-model <agent-name>
├── 모델 해결: msd-tools.cjs resolve-model <agent-name>
│ 반환: opus | sonnet | haiku | inherit
│
├── 에이전트 생성 (Task/SubAgent 호출)
@@ -309,28 +309,28 @@ CJS 명령어 패밀리 라우터는 `CommandRoutingHub`를 통해 디스패치
│
├── 결과 수집
│
└── 상태 업데이트: gsd-tools.cjs state update / state patch / state advance-plan
└── 상태 업데이트: msd-tools.cjs state update / state patch / state advance-plan
```
### 주요 에이전트 생성 범주
21개 주요 에이전트의 개념적 생성 패턴 분류. 권위 있는 31개 에이전트 목록(10개 고급/전문화 에이전트 포함: `gsd-pattern-mapper`, `gsd-code-reviewer`, `gsd-code-fixer`, `gsd-ai-researcher`, `gsd-domain-researcher`, `gsd-eval-planner`, `gsd-eval-auditor`, `gsd-framework-selector`, `gsd-debug-session-manager`, `gsd-intel-updater`)은 [`docs/INVENTORY.md`](INVENTORY.md#agents-31-shipped)를 참조하라.
21개 주요 에이전트의 개념적 생성 패턴 분류. 권위 있는 31개 에이전트 목록(10개 고급/전문화 에이전트 포함: `msd-pattern-mapper`, `msd-code-reviewer`, `msd-code-fixer`, `msd-ai-researcher`, `msd-domain-researcher`, `msd-eval-planner`, `msd-eval-auditor`, `msd-framework-selector`, `msd-debug-session-manager`, `msd-intel-updater`)은 [`docs/INVENTORY.md`](INVENTORY.md#agents-31-shipped)를 참조하라.
| 범주 | 에이전트 | 병렬성 |
| ---------------- | --------------------------------------------------------------------------------------- | ----------------------------------------------------------------------------------------- |
| **Researchers** | gsd-project-researcher, gsd-phase-researcher, gsd-ui-researcher, gsd-advisor-researcher | 4개 병렬 (stack, features, architecture, pitfalls); advisor는 discuss-phase 중 생성됨 |
| **Synthesizers** | gsd-research-synthesizer | 순차적 (리서처 완료 후) |
| **Planners** | gsd-planner, gsd-roadmapper | 순차적 |
| **Checkers** | gsd-plan-checker, gsd-integration-checker, gsd-ui-checker, gsd-nyquist-auditor | 순차적 (검증 루프, 최대 3회 반복) |
| **Executors** | gsd-executor | 웨이브 내 병렬, 웨이브 간 순차적 |
| **Verifiers** | gsd-verifier | 순차적 (모든 실행기 완료 후) |
| **Mappers** | gsd-codebase-mapper | 4개 병렬 (tech, arch, quality, concerns) |
| **Debuggers** | gsd-debugger | 순차적 (대화형) |
| **Auditors** | gsd-ui-auditor, gsd-security-auditor | 순차적 |
| **Doc Writers** | gsd-doc-writer, gsd-doc-verifier | 순차적 (writer 다음 verifier) |
| **Profilers** | gsd-user-profiler | 순차적 |
| **Analyzers** | gsd-assumptions-analyzer | 순차적 (discuss-phase 중) |
| **Researchers** | msd-project-researcher, msd-phase-researcher, msd-ui-researcher, msd-advisor-researcher | 4개 병렬 (stack, features, architecture, pitfalls); advisor는 discuss-phase 중 생성됨 |
| **Synthesizers** | msd-research-synthesizer | 순차적 (리서처 완료 후) |
| **Planners** | msd-planner, msd-roadmapper | 순차적 |
| **Checkers** | msd-plan-checker, msd-integration-checker, msd-ui-checker, msd-nyquist-auditor | 순차적 (검증 루프, 최대 3회 반복) |
| **Executors** | msd-executor | 웨이브 내 병렬, 웨이브 간 순차적 |
| **Verifiers** | msd-verifier | 순차적 (모든 실행기 완료 후) |
| **Mappers** | msd-codebase-mapper | 4개 병렬 (tech, arch, quality, concerns) |
| **Debuggers** | msd-debugger | 순차적 (대화형) |
| **Auditors** | msd-ui-auditor, msd-security-auditor | 순차적 |
| **Doc Writers** | msd-doc-writer, msd-doc-verifier | 순차적 (writer 다음 verifier) |
| **Profilers** | msd-user-profiler | 순차적 |
| **Analyzers** | msd-assumptions-analyzer | 순차적 (discuss-phase 중) |
### 웨이브 실행 모델
@@ -360,7 +360,7 @@ CJS 명령어 패밀리 라우터는 `CommandRoutingHub`를 통해 디스패치
- **실행기 에이전트**는 이전 웨이브 SUMMARY.md 파일들과 단계 CONTEXT.md/RESEARCH.md를 받아 단계 내 교차 계획 인식 가능
- **검증기 에이전트**는 모든 PLAN.md, SUMMARY.md, CONTEXT.md 파일들과 REQUIREMENTS.md를 받아 이력 인식 검증 가능
오케스트레이터는 config에서 `context_window`를 읽고(`gsd-tools.cjs config-get context_window`) 값이 >= 500,000일 때 조건부로 더 풍부한 컨텍스트를 포함한다. 표준 200K 윈도우에서는 최대 컨텍스트 효율성을 위해 캐시 친화적 순서로 잘린 버전의 프롬프트를 사용한다.
오케스트레이터는 config에서 `context_window`를 읽고(`msd-tools.cjs config-get context_window`) 값이 >= 500,000일 때 조건부로 더 풍부한 컨텍스트를 포함한다. 표준 200K 윈도우에서는 최대 컨텍스트 효율성을 위해 캐시 친화적 순서로 잘린 버전의 프롬프트를 사용한다.
#### 병렬 커밋 안전성
@@ -464,10 +464,10 @@ UI-SPEC.md (단계별) ───────────────────
```
~/.claude/ # Claude Code (전역 설치)
├── skills/gsd-*/SKILL.md # 전역 스킬 (권위 있는 목록: docs/INVENTORY.md)
├── commands/gsd/*.md # 로컬 Claude 설치는 전역 스킬 대신 슬래시 명령어 사용
├── gsd-core/
│ ├── bin/gsd-tools.cjs # CLI 유틸리티
├── skills/msd-*/SKILL.md # 전역 스킬 (권위 있는 목록: docs/INVENTORY.md)
├── commands/msd/*.md # 로컬 Claude 설치는 전역 스킬 대신 슬래시 명령어 사용
├── msd-core/
│ ├── bin/msd-tools.cjs # CLI 유틸리티
│ ├── bin/lib/*.cjs # 도메인 모듈 (권위 있는 목록: docs/INVENTORY.md)
│ ├── workflows/*.md # 워크플로우 정의 (권위 있는 목록: docs/INVENTORY.md)
│ ├── references/*.md # 공유 레퍼런스 문서 (권위 있는 목록: docs/INVENTORY.md)
@@ -505,14 +505,14 @@ UI-SPEC.md (단계별) ───────────────────
├── STATE.md # 살아있는 메모리: 위치, 결정, 차단, 메트릭
├── config.json # 워크플로우 설정
├── MILESTONES.md # 완료된 마일스톤 보관
├── research/ # /gsd-new-project의 도메인 리서치
├── research/ # /msd-new-project의 도메인 리서치
│ ├── SUMMARY.md
│ ├── STACK.md
│ ├── FEATURES.md
│ ├── ARCHITECTURE.md
│ └── PITFALLS.md
├── codebase/ # 브라운필드 매핑 (/gsd-map-codebase 또는 /gsd-onboard에서)
├── onboarding/ # 브라운필드 온보딩 요약 (/gsd-onboard에서)
├── codebase/ # 브라운필드 매핑 (/msd-map-codebase 또는 /msd-onboard에서)
├── onboarding/ # 브라운필드 온보딩 요약 (/msd-onboard에서)
│ ├── STACK.md # YAML 전문에 `last_mapped_commit` 포함
│ ├── ARCHITECTURE.md # 실행 후 드리프트 게이트를 위한 (#2003)
│ ├── CONVENTIONS.md
@@ -538,26 +538,26 @@ UI-SPEC.md (단계별) ───────────────────
├── todos/
│ ├── pending/ # 캡처된 아이디어
│ └── completed/ # 완료된 할 일
├── threads/ # 영구 컨텍스트 스레드 (/gsd-thread에서)
├── seeds/ # 미래 지향적 아이디어 (/gsd-capture --seed에서)
├── threads/ # 영구 컨텍스트 스레드 (/msd-thread에서)
├── seeds/ # 미래 지향적 아이디어 (/msd-capture --seed에서)
├── debug/ # 활성 디버그 세션
│ ├── *.md # 활성 세션
│ ├── resolved/ # 보관된 세션
│ └── knowledge-base.md # 영구 디버그 학습 내용
├── ui-reviews/ # /gsd-ui-review의 스크린샷 (gitignored)
├── ui-reviews/ # /msd-ui-review의 스크린샷 (gitignored)
└── continue-here.md # 컨텍스트 핸드오프 (pause-work에서)
```
### 실행 후 코드베이스 드리프트 게이트 (#2003)
`/gsd-execute-phase` 마지막 웨이브 커밋 후, 워크플로우는 비차단 `codebase_drift_gate` 단계를 실행한다(`schema_drift_gate`와 `verify_phase_goal` 사이). `last_mapped_commit..HEAD` diff를 `.planning/codebase/STRUCTURE.md`와 비교하고 네 종류의 구조적 요소를 집계한다:
`/msd-execute-phase` 마지막 웨이브 커밋 후, 워크플로우는 비차단 `codebase_drift_gate` 단계를 실행한다(`schema_drift_gate`와 `verify_phase_goal` 사이). `last_mapped_commit..HEAD` diff를 `.planning/codebase/STRUCTURE.md`와 비교하고 네 종류의 구조적 요소를 집계한다:
1. 매핑된 경로 외부의 새 디렉터리
2. `(packages|apps)/<name>/src/index.*`의 새 배럴 내보내기
3. 새 마이그레이션 파일
4. `routes/` 또는 `api/` 하위의 새 라우트 모듈
집계가 `workflow.drift_threshold`(기본값 3)를 충족하면, 게이트는 제안된 `/gsd-map-codebase --paths …` 명령어와 함께 **경고**하거나(기본값), `gsd-codebase-mapper`를 영향받은 경로로 범위 지정하여 생성함으로써 **자동 재매핑**한다(`workflow.drift_action = auto-remap`). 감지 또는 재매핑의 오류는 로그되고 단계는 계속된다 — 드리프트 감지는 검증을 실패시킬 수 없다.
집계가 `workflow.drift_threshold`(기본값 3)를 충족하면, 게이트는 제안된 `/msd-map-codebase --paths …` 명령어와 함께 **경고**하거나(기본값), `msd-codebase-mapper`를 영향받은 경로로 범위 지정하여 생성함으로써 **자동 재매핑**한다(`workflow.drift_action = auto-remap`). 감지 또는 재매핑의 오류는 로그되고 단계는 계속된다 — 드리프트 감지는 검증을 실패시킬 수 없다.
`last_mapped_commit`는 각 `.planning/codebase/*.md` 파일 상단의 YAML 전문에 있다; `bin/lib/drift.cjs`는 `readMappedCommit`와 `writeMappedCommit` 왕복 헬퍼를 제공한다.
@@ -581,15 +581,15 @@ UI-SPEC.md (단계별) ───────────────────
- Windsurf: Windsurf 규칙 참조를 사용한 skills-first
- Trae: `settings.json` 또는 훅 통합 없이 `~/.trae` / `./.trae`에 skills-first 설치
- Qwen Code: Qwen 브랜드 경로 및 프롬프트 재작성을 사용한 skills-first
- Hermes Agent: `skills/gsd/` 하의 범주 기반 스킬
- Hermes Agent: `skills/msd/` 하의 범주 기반 스킬
- CodeBuddy: CodeBuddy 경로 및 프롬프트 재작성을 사용한 skills-first
- Cline: 규칙 기반 통합을 위한 `.clinerules` 작성
- Augment Code: 전체 스킬 변환 및 설정 관리를 사용한 skills-first
5. **경로 정규화** — `~/.claude/` 경로를 런타임별 경로로 교체
6. **설정 통합** — 런타임의 `settings.json`에 훅 등록
7. **패치 백업** — v1.17부터 로컬 수정 파일을 `gsd-local-patches/`에 백업하여 `/gsd-update --reapply`에 사용
8. **매니페스트 추적** — 깔끔한 제거를 위해 `gsd-file-manifest.json` 작성
9. **제거 모드** — `--uninstall`로 모든 GSD 파일, 훅, 설정 제거
7. **패치 백업** — v1.17부터 로컬 수정 파일을 `msd-local-patches/`에 백업하여 `/msd-update --reapply`에 사용
8. **매니페스트 추적** — 깔끔한 제거를 위해 `msd-file-manifest.json` 작성
9. **제거 모드** — `--uninstall`로 모든 MSD 파일, 훅, 설정 제거
설치 시 파일 이동, 오래된 결과물 정리, 설정 재작성, 사용자 데이터 보존은 인스톨러 마이그레이션 모듈이 관리한다. [인스톨러 마이그레이션](../installer-migrations.md)과 [ADR 0008](../adr/0008-installer-migration-module.md)을 참조하라.
마이그레이션 모듈은 레거시 설치에 대한 게이트된 최초 기준선 스캔도 소유하며, 이후 마이그레이션이 무언가를 제거하거나 재작성하기 전에 알려진 런타임 설치 표면을 분류한다.
@@ -611,17 +611,17 @@ UI-SPEC.md (단계별) ───────────────────
```
런타임 엔진 (Claude Code / Antigravity CLI)
│
├── statusLine 이벤트 ──► gsd-statusline.js
├── statusLine 이벤트 ──► msd-statusline.js
│ 읽기: stdin (세션 JSON)
│ 쓰기: stdout (형식화된 상태), /tmp/claude-ctx-{session}.json (브리지)
│
├── PostToolUse/AfterTool 이벤트 ──► gsd-context-monitor.js
├── PostToolUse/AfterTool 이벤트 ──► msd-context-monitor.js
│ 읽기: stdin (도구 이벤트 JSON), /tmp/claude-ctx-{session}.json (브리지)
│ 쓰기: stdout (additionalContext 경고가 있는 hookSpecificOutput)
│
└── SessionStart 이벤트 ──► gsd-check-update.js
└── SessionStart 이벤트 ──► msd-check-update.js
읽기: VERSION 파일
쓰기: ~/.claude/cache/gsd-update-check.json (백그라운드 프로세스 생성)
쓰기: ~/.claude/cache/msd-update-check.json (백그라운드 프로세스 생성)
```
### 컨텍스트 모니터 임계값
@@ -648,15 +648,15 @@ UI-SPEC.md (단계별) ───────────────────
리서처 → 플래너 → 실행기 파이프라인은 슬롭스쿼팅(악의적인 설치 후 스크립트와 함께 선점 등록된 AI 환각 패키지 이름)에 대한 공급망 게이트를 포함한다.
**위협 모델:** GSD는 "리서처가 패키지를 명명"에서 "실행기가 `npm install`을 실행"까지의 전체 경로를 자동화한다. `npm view`를 통과하는 환각된 이름(등록만 증명, 적법성은 아님)은 이전에는 감지되지 않고 흘러갔을 것이다. AI가 생성한 패키지 참조의 ~20%가 환각되며; 그 이름의 ~43%가 프롬프트 전반에 걸쳐 일관되게 반복되어 선점 등록이 공격자에게 경제적으로 실현 가능하다.
**위협 모델:** MSD는 "리서처가 패키지를 명명"에서 "실행기가 `npm install`을 실행"까지의 전체 경로를 자동화한다. `npm view`를 통과하는 환각된 이름(등록만 증명, 적법성은 아님)은 이전에는 감지되지 않고 흘러갔을 것이다. AI가 생성한 패키지 참조의 ~20%가 환각되며; 그 이름의 ~43%가 프롬프트 전반에 걸쳐 일관되게 반복되어 선점 등록이 공격자에게 경제적으로 실현 가능하다.
**게이트 계층:**
| 계층 | 컴포넌트 | 동작 |
|-------|-----------|--------|
| 리서치 | `gsd-phase-researcher` | `gsd-tools query package-legitimacy check --ecosystem <npm\|pypi\|crates> <pkgs>` 실행; `## Package Legitimacy Audit` 테이블을 RESEARCH.md에 작성; RESEARCH.md가 작성되기 전에 `[SLOP]` 패키지 제거 |
| 계획 | `gsd-planner` | 감사 테이블 읽기; `[ASSUMED]` 또는 `[SUS]` 설치 작업 전에 `checkpoint:human-verify` 삽입; `<threat_model>`에 `T-{phase}-SC` STRIDE 공급망 행 추가 |
| 실행 | `gsd-executor` | RULE 3은 패키지 설치를 자동 수정 범위에서 제외; 실패한 설치는 체크포인트로 표시되며 절대 자동 대체하지 않음 |
| 리서치 | `msd-phase-researcher` | `msd-tools query package-legitimacy check --ecosystem <npm\|pypi\|crates> <pkgs>` 실행; `## Package Legitimacy Audit` 테이블을 RESEARCH.md에 작성; RESEARCH.md가 작성되기 전에 `[SLOP]` 패키지 제거 |
| 계획 | `msd-planner` | 감사 테이블 읽기; `[ASSUMED]` 또는 `[SUS]` 설치 작업 전에 `checkpoint:human-verify` 삽입; `<threat_model>`에 `T-{phase}-SC` STRIDE 공급망 행 추가 |
| 실행 | `msd-executor` | RULE 3은 패키지 설치를 자동 수정 범위에서 제외; 실패한 설치는 체크포인트로 표시되며 절대 자동 대체하지 않음 |
**클레임 출처 통합:** WebSearch를 통해 발견된 패키지 이름은 `npm view` 결과와 관계없이 `[ASSUMED]`(not `[VERIFIED]`)로 태그된다. 이는 설치 경계에서 출처 태그를 하드 게이트로 시행하여 기존 `[ASSUMED]` / `[VERIFIED]` / `[CITED]` 출처 시스템을 확장한다 — `[ASSUMED]`는 항상 PLAN.md에 `checkpoint:human-verify`를 생성한다.
@@ -672,25 +672,25 @@ UI-SPEC.md (단계별) ───────────────────
훅과 가드 계층이 더 광범위한 보안 접근 방식에 어떻게 맞는지에 대한 개념적 개요는 [보안 모델](explanation/security-model.md)을 참조하라.
**Prompt Guard** (`gsd-prompt-guard.js`):
**Prompt Guard** (`msd-prompt-guard.js`):
- `.planning/` 파일에 Write/Edit 시 트리거
- 프롬프트 인젝션 패턴 스캔 (역할 재정의, 지시 우회, system 태그 인젝션)
- 자문적 전용 — 탐지를 로그하며 차단하지 않음
- 패턴은 훅 독립성을 위해 인라인으로 포함됨 (`security.cjs`의 하위 집합)
**Workflow Guard** (`gsd-workflow-guard.js`):
**Workflow Guard** (`msd-workflow-guard.js`):
- `.planning/` 외부 파일에 Write/Edit 시 트리거
- GSD 워크플로우 컨텍스트 외부의 편집 감지 (활성 `/gsd-` 명령어 또는 Task 서브에이전트 없음)
- 상태 추적 변경을 위해 `/gsd-quick` 또는 `/gsd-fast` 사용 권고
- MSD 워크플로우 컨텍스트 외부의 편집 감지 (활성 `/msd-` 명령어 또는 Task 서브에이전트 없음)
- 상태 추적 변경을 위해 `/msd-quick` 또는 `/msd-fast` 사용 권고
- `hooks.workflow_guard: true`를 통한 옵트인 (기본값: false)
---
## 런타임 추상화
GSD는 통합된 명령어/워크플로우 아키텍처를 통해 여러 AI 코딩 런타임을 지원한다.
MSD는 통합된 명령어/워크플로우 아키텍처를 통해 여러 AI 코딩 런타임을 지원한다.
### 런타임 설치 계약 매트릭스
@@ -699,20 +699,20 @@ GSD는 통합된 명령어/워크플로우 아키텍처를 통해 여러 AI 코
| 런타임 | 전역 루트 | 로컬 루트 | 호출 표면 | 에이전트 표면 | 설정 및 훅 |
| --- | --- | --- | --- | --- | --- |
| Claude Code | `~/.claude` | `./.claude` | 전역 `skills/gsd-*/SKILL.md`; 로컬 `commands/gsd/*.md` | `agents/gsd-*.md` | `settings.json` 훅 및 statusLine 항목 |
| OpenCode | `~/.config/opencode` | `./.opencode` | `command/gsd-*.md` | `agents/gsd-*.md` | `opencode.json` 또는 `opencode.jsonc`; GSD 훅 없음 |
| Kilo | `~/.config/kilo` | `./.kilo` | `command/gsd-*.md` | `agents/gsd-*.md` | `kilo.json` 또는 `kilo.jsonc`; GSD 훅 없음 |
| Codex | `~/.codex` | `./.codex` | `skills/gsd-*/SKILL.md` | `agents/` 소스 마크다운 + 에이전트별 TOML | `config.toml` `[agents.gsd-*]`, `[features].hooks` (정규; 레거시 별칭 `codex_hooks`는 인식되며 재설치 시 마이그레이션됨, #3566), 훅 테이블 |
| GitHub Copilot | `~/.copilot` | `./.github` | `skills/gsd-*/SKILL.md` 및 `copilot-instructions.md` | `.agent.md` 파일 | GSD 훅 또는 statusline 없음 |
| Antigravity | 자동 감지: `~/.gemini/antigravity`, `~/.gemini/antigravity-ide`, 또는 `~/.gemini/antigravity-cli` | `./.agent` | `skills/gsd-*/SKILL.md` | `agents/gsd-*.md` | GSD가 설치 시 Gemini 스타일 `settings.json` 훅 항목 |
| Cursor | `~/.cursor` | `./.cursor` | `skills/gsd-*/SKILL.md` | `agents/gsd-*.md` | `rules/` 하의 규칙 참조; GSD 훅 없음 |
| Windsurf | `~/.codeium/windsurf` | `./.windsurf` | `skills/gsd-*/SKILL.md` | `agents/gsd-*.md` | `rules/` 하의 규칙 참조; GSD 훅 없음 |
| Augment Code | `~/.augment` | `./.augment` | `skills/gsd-*/SKILL.md` | `agents/gsd-*.md` | GSD 훅 또는 statusline 없음 |
| Trae | `~/.trae` | `./.trae` | `skills/gsd-*/SKILL.md` | `agents/gsd-*.md` | `rules/` 하의 규칙 참조; GSD 훅 없음 |
| Qwen Code | `~/.qwen` | `./.qwen` | `skills/gsd-*/SKILL.md` | `agents/gsd-*.md` | 지원되는 경우 공통 GSD 설정 및 훅 항목 |
| Hermes Agent | `~/.hermes` | `./.hermes` | `skills/gsd/DESCRIPTION.md` 및 `skills/gsd/gsd-*/SKILL.md` | `agents/gsd-*.md` | 지원되는 경우 공통 GSD 설정 및 훅 항목 |
| CodeBuddy | `~/.codebuddy` | `./.codebuddy` | `skills/gsd-*/SKILL.md` | `agents/gsd-*.md` | 지원되는 경우 공통 GSD 설정 및 훅 항목 |
| Cline | `~/.cline` | 프로젝트 루트 | `.clinerules` | 규칙만 | GSD 훅 또는 statusline 없음 |
| Claude Code | `~/.claude` | `./.claude` | 전역 `skills/msd-*/SKILL.md`; 로컬 `commands/msd/*.md` | `agents/msd-*.md` | `settings.json` 훅 및 statusLine 항목 |
| OpenCode | `~/.config/opencode` | `./.opencode` | `command/msd-*.md` | `agents/msd-*.md` | `opencode.json` 또는 `opencode.jsonc`; MSD 훅 없음 |
| Kilo | `~/.config/kilo` | `./.kilo` | `command/msd-*.md` | `agents/msd-*.md` | `kilo.json` 또는 `kilo.jsonc`; MSD 훅 없음 |
| Codex | `~/.codex` | `./.codex` | `skills/msd-*/SKILL.md` | `agents/` 소스 마크다운 + 에이전트별 TOML | `config.toml` `[agents.msd-*]`, `[features].hooks` (정규; 레거시 별칭 `codex_hooks`는 인식되며 재설치 시 마이그레이션됨, #3566), 훅 테이블 |
| GitHub Copilot | `~/.copilot` | `./.github` | `skills/msd-*/SKILL.md` 및 `copilot-instructions.md` | `.agent.md` 파일 | MSD 훅 또는 statusline 없음 |
| Antigravity | 자동 감지: `~/.gemini/antigravity`, `~/.gemini/antigravity-ide`, 또는 `~/.gemini/antigravity-cli` | `./.agent` | `skills/msd-*/SKILL.md` | `agents/msd-*.md` | MSD가 설치 시 Gemini 스타일 `settings.json` 훅 항목 |
| Cursor | `~/.cursor` | `./.cursor` | `skills/msd-*/SKILL.md` | `agents/msd-*.md` | `rules/` 하의 규칙 참조; MSD 훅 없음 |
| Windsurf | `~/.codeium/windsurf` | `./.windsurf` | `skills/msd-*/SKILL.md` | `agents/msd-*.md` | `rules/` 하의 규칙 참조; MSD 훅 없음 |
| Augment Code | `~/.augment` | `./.augment` | `skills/msd-*/SKILL.md` | `agents/msd-*.md` | MSD 훅 또는 statusline 없음 |
| Trae | `~/.trae` | `./.trae` | `skills/msd-*/SKILL.md` | `agents/msd-*.md` | `rules/` 하의 규칙 참조; MSD 훅 없음 |
| Qwen Code | `~/.qwen` | `./.qwen` | `skills/msd-*/SKILL.md` | `agents/msd-*.md` | 지원되는 경우 공통 MSD 설정 및 훅 항목 |
| Hermes Agent | `~/.hermes` | `./.hermes` | `skills/msd/DESCRIPTION.md` 및 `skills/msd/msd-*/SKILL.md` | `agents/msd-*.md` | 지원되는 경우 공통 MSD 설정 및 훅 항목 |
| CodeBuddy | `~/.codebuddy` | `./.codebuddy` | `skills/msd-*/SKILL.md` | `agents/msd-*.md` | 지원되는 경우 공통 MSD 설정 및 훅 항목 |
| Cline | `~/.cline` | 프로젝트 루트 | `.clinerules` | 규칙만 | MSD 훅 또는 statusline 없음 |
### 업스트림 계약 소스
@@ -731,7 +731,7 @@ GSD는 통합된 명령어/워크플로우 아키텍처를 통해 여러 AI 코
2. **훅 이벤트 이름** — Claude는 `PostToolUse`를 사용하고 Antigravity는 `AfterTool`을 사용한다
3. **에이전트 전문** — 각 런타임은 고유한 에이전트 정의 형식을 가진다
4. **경로 컨벤션** — 각 런타임은 서로 다른 디렉터리에 설정을 저장한다
5. **모델 참조** — `inherit` 프로필은 GSD가 런타임의 모델 선택에 위임하도록 한다
5. **모델 참조** — `inherit` 프로필은 MSD가 런타임의 모델 선택에 위임하도록 한다
인스톨러는 설치 시 모든 번역을 처리한다. 워크플로우와 에이전트는 Claude Code의 네이티브 형식으로 작성되어 배포 중에 변환된다.

238
docs/ko-KR/CLI-TOOLS.md
View File

@@ -1,25 +1,25 @@
# GSD CLI 도구 참조
# MSD CLI 도구 참조
> `gsd-tools` CLI(`gsd-core/bin/gsd-tools.cjs`)에 대한 참조입니다. 슬래시 명령 및 사용자 흐름은 [명령 참조](COMMANDS.md)를 확인하세요. [문서 인덱스](README.md)로 돌아가기.
> `msd-tools` CLI(`msd-core/bin/msd-tools.cjs`)에 대한 참조입니다. 슬래시 명령 및 사용자 흐름은 [명령 참조](COMMANDS.md)를 확인하세요. [문서 인덱스](README.md)로 돌아가기.
---
## 개요
`gsd-tools.cjs`는 GSD 명령, 워크플로우, 에이전트 전반에 걸쳐 설정 파싱, 모델 해석, 단계 조회, git 커밋, 요약 검증, 상태 관리, 템플릿 작업을 중앙에서 처리합니다.
`msd-tools.cjs`는 MSD 명령, 워크플로우, 에이전트 전반에 걸쳐 설정 파싱, 모델 해석, 단계 조회, git 커밋, 요약 검증, 상태 관리, 템플릿 작업을 중앙에서 처리합니다.
| | |
| ------------------ | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------ |
| **배포 경로** | `gsd-core/bin/gsd-tools.cjs` |
| **구현** | `gsd-core/bin/lib/` 아래 20개의 도메인 모듈 (해당 디렉토리가 기준) |
| **배포 경로** | `msd-core/bin/msd-tools.cjs` |
| **구현** | `msd-core/bin/lib/` 아래 20개의 도메인 모듈 (해당 디렉토리가 기준) |
| **상태** | 오케스트레이션, 워크플로우, 자동화를 위한 주요 런타임 명령 인터페이스. |
**사용법 (CJS):**
```bash
node gsd-tools.cjs <command> [args] [--raw] [--cwd <path>]
node msd-tools.cjs <command> [args] [--raw] [--cwd <path>]
```
**전역 플래그 (CJS):**
@@ -40,47 +40,47 @@ node gsd-tools.cjs <command> [args] [--raw] [--cwd <path>]
```bash
# 전체 프로젝트 설정 + 상태를 JSON으로 불러오기
node gsd-tools.cjs state load
node msd-tools.cjs state load
# STATE.md 프론트매터를 JSON으로 출력
node gsd-tools.cjs state json
node msd-tools.cjs state json
# 단일 필드 업데이트
node gsd-tools.cjs state update <field> <value>
node msd-tools.cjs state update <field> <value>
# STATE.md 내용 또는 특정 섹션 가져오기
node gsd-tools.cjs state get [section]
node msd-tools.cjs state get [section]
# 여러 필드 일괄 업데이트
node gsd-tools.cjs state patch --field1 val1 --field2 val2
node msd-tools.cjs state patch --field1 val1 --field2 val2
# 계획 카운터 증가
node gsd-tools.cjs state advance-plan
node msd-tools.cjs state advance-plan
# 실행 메트릭 기록
node gsd-tools.cjs state record-metric --phase N --plan M --duration Xmin [--tasks N] [--files N]
node msd-tools.cjs state record-metric --phase N --plan M --duration Xmin [--tasks N] [--files N]
# 진행률 바 재계산
node gsd-tools.cjs state update-progress
node msd-tools.cjs state update-progress
# 결정 사항 추가
node gsd-tools.cjs state add-decision --summary "..." [--phase N] [--rationale "..."]
node msd-tools.cjs state add-decision --summary "..." [--phase N] [--rationale "..."]
# 또는 파일에서:
node gsd-tools.cjs state add-decision --summary-file path [--rationale-file path]
node msd-tools.cjs state add-decision --summary-file path [--rationale-file path]
# 차단 항목 추가/해제
node gsd-tools.cjs state add-blocker --text "..."
node gsd-tools.cjs state resolve-blocker --text "..."
node msd-tools.cjs state add-blocker --text "..."
node msd-tools.cjs state resolve-blocker --text "..."
# 세션 연속성 기록
node gsd-tools.cjs state record-session --stopped-at "..." [--resume-file path]
node msd-tools.cjs state record-session --stopped-at "..." [--resume-file path]
# 단계 시작 — 새로운 단계의 STATE.md 상태/최근 활동 업데이트
node gsd-tools.cjs state begin-phase --phase N --name SLUG --plans COUNT
node msd-tools.cjs state begin-phase --phase N --name SLUG --plans COUNT
# 에이전트 발견 가능한 차단 신호 (discuss-phase / UI 흐름에서 사용)
node gsd-tools.cjs state signal-waiting --type TYPE --question "..." --options "A|B" --phase P
node gsd-tools.cjs state signal-resume
node msd-tools.cjs state signal-waiting --type TYPE --question "..." --options "A|B" --phase P
node msd-tools.cjs state signal-resume
```
### 상태 스냅샷
@@ -88,7 +88,7 @@ node gsd-tools.cjs state signal-resume
전체 STATE.md의 구조화된 파싱:
```bash
node gsd-tools.cjs state-snapshot
node msd-tools.cjs state-snapshot
```
반환 JSON 포함 항목: 현재 위치, 단계, 계획, 상태, 결정 사항, 차단 항목, 메트릭, 최근 활동.
@@ -101,28 +101,28 @@ node gsd-tools.cjs state-snapshot
```bash
# 번호로 단계 디렉토리 찾기
node gsd-tools.cjs find-phase <phase>
node msd-tools.cjs find-phase <phase>
# 삽입을 위한 다음 소수점 단계 번호 계산
node gsd-tools.cjs phase next-decimal <phase>
node msd-tools.cjs phase next-decimal <phase>
# 로드맵에 새 단계 추가 + 디렉토리 생성
node gsd-tools.cjs phase add <description>
node msd-tools.cjs phase add <description>
# 기존 단계 뒤에 소수점 단계 삽입
node gsd-tools.cjs phase insert <after> <description>
node msd-tools.cjs phase insert <after> <description>
# 단계 제거, 이후 번호 재지정
node gsd-tools.cjs phase remove <phase> [--force]
node msd-tools.cjs phase remove <phase> [--force]
# 단계 완료 표시, 상태 + 로드맵 업데이트
node gsd-tools.cjs phase complete <phase>
node msd-tools.cjs phase complete <phase>
# 웨이브 및 상태와 함께 계획 인덱싱
node gsd-tools.cjs phase-plan-index <phase>
node msd-tools.cjs phase-plan-index <phase>
# 필터링으로 단계 목록 표시
node gsd-tools.cjs phases list [--type planned|executed|all] [--phase N] [--include-archived]
node msd-tools.cjs phases list [--type planned|executed|all] [--phase N] [--include-archived]
```
---
@@ -133,13 +133,13 @@ node gsd-tools.cjs phases list [--type planned|executed|all] [--phase N] [--incl
```bash
# ROADMAP.md에서 단계 섹션 추출
node gsd-tools.cjs roadmap get-phase <phase>
node msd-tools.cjs roadmap get-phase <phase>
# 디스크 상태를 포함한 전체 로드맵 파싱
node gsd-tools.cjs roadmap analyze
node msd-tools.cjs roadmap analyze
# 디스크에서 진행 테이블 행 업데이트
node gsd-tools.cjs roadmap update-plan-progress <N>
node msd-tools.cjs roadmap update-plan-progress <N>
```
---
@@ -150,16 +150,16 @@ node gsd-tools.cjs roadmap update-plan-progress <N>
```bash
# 기본값으로 config.json 초기화
node gsd-tools.cjs config-ensure-section
node msd-tools.cjs config-ensure-section
# 설정 값 지정 (점 표기법)
node gsd-tools.cjs config-set <key> <value>
node msd-tools.cjs config-set <key> <value>
# 설정 값 가져오기
node gsd-tools.cjs config-get <key>
node msd-tools.cjs config-get <key>
# 모델 프로파일 설정
node gsd-tools.cjs config-set-model-profile <profile>
node msd-tools.cjs config-set-model-profile <profile>
```
---
@@ -168,13 +168,13 @@ node gsd-tools.cjs config-set-model-profile <profile>
```bash
# 현재 프로파일 기반으로 에이전트에 대한 모델 가져오기
node gsd-tools.cjs resolve-model <agent-name>
node msd-tools.cjs resolve-model <agent-name>
# 원시 출력은 선택된 모델 ID/티어를 반환합니다.
# JSON 출력은 프로파일도 포함하며, 활성 런타임이 지원하는 경우
# reasoning_effort도 포함합니다.
```
에이전트 이름: `gsd-planner`, `gsd-executor`, `gsd-phase-researcher`, `gsd-project-researcher`, `gsd-research-synthesizer`, `gsd-verifier`, `gsd-plan-checker`, `gsd-integration-checker`, `gsd-roadmapper`, `gsd-debugger`, `gsd-codebase-mapper`, `gsd-nyquist-auditor`
에이전트 이름: `msd-planner`, `msd-executor`, `msd-phase-researcher`, `msd-project-researcher`, `msd-research-synthesizer`, `msd-verifier`, `msd-plan-checker`, `msd-integration-checker`, `msd-roadmapper`, `msd-debugger`, `msd-codebase-mapper`, `msd-nyquist-auditor`
---
@@ -184,25 +184,25 @@ node gsd-tools.cjs resolve-model <agent-name>
```bash
# SUMMARY.md 파일 검증
node gsd-tools.cjs verify-summary <path> [--check-count N]
node msd-tools.cjs verify-summary <path> [--check-count N]
# PLAN.md 구조 + 태스크 확인
node gsd-tools.cjs verify plan-structure <file>
node msd-tools.cjs verify plan-structure <file>
# 모든 계획에 요약이 있는지 확인
node gsd-tools.cjs verify phase-completeness <phase>
node msd-tools.cjs verify phase-completeness <phase>
# @-참조 + 경로 확인
node gsd-tools.cjs verify references <file>
node msd-tools.cjs verify references <file>
# 커밋 해시 일괄 검증
node gsd-tools.cjs verify commits <hash1> [hash2] ...
node msd-tools.cjs verify commits <hash1> [hash2] ...
# must_haves.artifacts 확인
node gsd-tools.cjs verify artifacts <plan-file>
node msd-tools.cjs verify artifacts <plan-file>
# must_haves.key_links 확인
node gsd-tools.cjs verify key-links <plan-file>
node msd-tools.cjs verify key-links <plan-file>
```
---
@@ -213,19 +213,19 @@ node gsd-tools.cjs verify key-links <plan-file>
```bash
# 단계 번호 지정, 디스크/로드맵 동기화 확인
node gsd-tools.cjs validate consistency
node msd-tools.cjs validate consistency
# .planning/ 무결성 확인, 선택적 복구
node gsd-tools.cjs validate health [--repair]
node msd-tools.cjs validate health [--repair]
# 상태 표시줄 / 훅 호출자를 위한 컨텍스트 창 사용률 조회 (v1.40.0)
node gsd-tools.cjs validate context
node msd-tools.cjs validate context
# 타입이 지정된 JSON 인터페이스로서의 컨텍스트 사용률 (#455)
node gsd-tools.cjs validate context --json
node msd-tools.cjs validate context --json
```
`validate context`는 `utilization`, `status`(60% / 70% 임계값에서 `ok` / `warn` / `critical`), `suggestion` 문자열을 포함한 구조화된 봉투를 출력합니다. 동일한 데이터가 `/gsd-health --context`를 지원합니다.
`validate context`는 `utilization`, `status`(60% / 70% 임계값에서 `ok` / `warn` / `critical`), `suggestion` 문자열을 포함한 구조화된 봉투를 출력합니다. 동일한 데이터가 `/msd-health --context`를 지원합니다.
스크립트 및 테스트 어서션에서 타입이 지정된 IR을 직접 수신하려면 `--json`을 전달하세요.
---
@@ -236,10 +236,10 @@ node gsd-tools.cjs validate context --json
```bash
# 세분성에 따라 요약 템플릿 선택
node gsd-tools.cjs template select <type>
node msd-tools.cjs template select <type>
# 변수로 템플릿 채우기
node gsd-tools.cjs template fill <type> --phase N [--plan M] [--name "..."] [--type execute|tdd] [--wave N] [--fields '{json}']
node msd-tools.cjs template fill <type> --phase N [--plan M] [--name "..."] [--type execute|tdd] [--wave N] [--fields '{json}']
```
`fill`에 대한 템플릿 유형: `summary`, `plan`, `verification`
@@ -252,16 +252,16 @@ Markdown 파일에 대한 YAML 프론트매터 CRUD 작업.
```bash
# 프론트매터를 JSON으로 추출
node gsd-tools.cjs frontmatter get <file> [--field key]
node msd-tools.cjs frontmatter get <file> [--field key]
# 단일 필드 업데이트
node gsd-tools.cjs frontmatter set <file> --field key --value jsonVal
node msd-tools.cjs frontmatter set <file> --field key --value jsonVal
# JSON을 프론트매터에 병합
node gsd-tools.cjs frontmatter merge <file> --data '{json}'
node msd-tools.cjs frontmatter merge <file> --data '{json}'
# 필수 필드 검증
node gsd-tools.cjs frontmatter validate <file> --schema plan|summary|verification
node msd-tools.cjs frontmatter validate <file> --schema plan|summary|verification
```
---
@@ -272,48 +272,48 @@ node gsd-tools.cjs frontmatter validate <file> --schema plan|summary|verificatio
```bash
# CONTEXT.md 템플릿 생성
node gsd-tools.cjs scaffold context --phase N
node msd-tools.cjs scaffold context --phase N
# UAT.md 템플릿 생성
node gsd-tools.cjs scaffold uat --phase N
node msd-tools.cjs scaffold uat --phase N
# VERIFICATION.md 템플릿 생성
node gsd-tools.cjs scaffold verification --phase N
node msd-tools.cjs scaffold verification --phase N
# 단계 디렉토리 생성
node gsd-tools.cjs scaffold phase-dir --phase N --name "phase name"
node msd-tools.cjs scaffold phase-dir --phase N --name "phase name"
```
---
## Init 명령 (복합 컨텍스트 로딩)
하나의 호출로 특정 워크플로우에 필요한 모든 컨텍스트를 로드합니다. 프로젝트 정보, 설정, 상태, 워크플로우별 데이터가 포함된 JSON을 반환합니다. `init onboard [--fast] [--text]`는 `/gsd-onboard`를 위해 brownfield 신호, 계획 문서 후보, 코드베이스 맵 완성도, fast 맵 준비 상태, 텍스트 모드 라우팅, 부분 planning 상태, 온보딩 요약 상태를 반환합니다.
하나의 호출로 특정 워크플로우에 필요한 모든 컨텍스트를 로드합니다. 프로젝트 정보, 설정, 상태, 워크플로우별 데이터가 포함된 JSON을 반환합니다. `init onboard [--fast] [--text]`는 `/msd-onboard`를 위해 brownfield 신호, 계획 문서 후보, 코드베이스 맵 완성도, fast 맵 준비 상태, 텍스트 모드 라우팅, 부분 planning 상태, 온보딩 요약 상태를 반환합니다.
```bash
node gsd-tools.cjs init execute-phase <phase>
node gsd-tools.cjs init plan-phase <phase>
node gsd-tools.cjs init new-project
node gsd-tools.cjs init new-milestone
node gsd-tools.cjs init onboard [--fast] [--text]
node gsd-tools.cjs init quick <description>
node gsd-tools.cjs init resume
node gsd-tools.cjs init verify-work <phase>
node gsd-tools.cjs init phase-op <phase>
node gsd-tools.cjs init todos [area]
node gsd-tools.cjs init milestone-op
node gsd-tools.cjs init map-codebase
node gsd-tools.cjs init progress
node msd-tools.cjs init execute-phase <phase>
node msd-tools.cjs init plan-phase <phase>
node msd-tools.cjs init new-project
node msd-tools.cjs init new-milestone
node msd-tools.cjs init onboard [--fast] [--text]
node msd-tools.cjs init quick <description>
node msd-tools.cjs init resume
node msd-tools.cjs init verify-work <phase>
node msd-tools.cjs init phase-op <phase>
node msd-tools.cjs init todos [area]
node msd-tools.cjs init milestone-op
node msd-tools.cjs init map-codebase
node msd-tools.cjs init progress
# 워크스트림 범위 init (`--ws` 플래그)
node gsd-tools.cjs init execute-phase <phase> --ws <name>
node gsd-tools.cjs init plan-phase <phase> --ws <name>
node msd-tools.cjs init execute-phase <phase> --ws <name>
node msd-tools.cjs init plan-phase <phase> --ws <name>
```
**대용량 페이로드 처리:** 출력이 ~50KB를 초과하면 CLI가 임시 파일에 쓰고 `@file:/tmp/gsd-init-XXXXX.json`을 반환합니다. 워크플로우는 `@file:` 접두사를 확인하고 디스크에서 읽습니다:
**대용량 페이로드 처리:** 출력이 ~50KB를 초과하면 CLI가 임시 파일에 쓰고 `@file:/tmp/msd-init-XXXXX.json`을 반환합니다. 워크플로우는 `@file:` 접두사를 확인하고 디스크에서 읽습니다:
```bash
INIT=$(node gsd-tools.cjs init execute-phase "1")
INIT=$(node msd-tools.cjs init execute-phase "1")
if [[ "$INIT" == @file:* ]]; then INIT=$(cat "${INIT#@file:}"); fi
```
@@ -323,10 +323,10 @@ if [[ "$INIT" == @file:* ]]; then INIT=$(cat "${INIT#@file:}"); fi
```bash
# 마일스톤 아카이브
node gsd-tools.cjs milestone complete <version> (--confirm | --dry-run) [--name <name>] [--no-archive-phases] [--force] [--archive-quick]
node msd-tools.cjs milestone complete <version> (--confirm | --dry-run) [--name <name>] [--no-archive-phases] [--force] [--archive-quick]
# 요구사항을 완료로 표시
node gsd-tools.cjs requirements mark-complete <ids>
node msd-tools.cjs requirements mark-complete <ids>
# 허용 형식: REQ-01,REQ-02 또는 REQ-01 REQ-02 또는 [REQ-01, REQ-02]
```
@@ -338,10 +338,10 @@ node gsd-tools.cjs requirements mark-complete <ids>
```bash
# 원시 XML 스킬 블록 출력 (기본값 — 셸 확장에 안전)
node gsd-tools.cjs agent-skills <agent-type>
node msd-tools.cjs agent-skills <agent-type>
# 타입이 지정된 JSON 인터페이스 출력 (#455) — { agent_type, block, skills_count }
node gsd-tools.cjs agent-skills <agent-type> --json
node msd-tools.cjs agent-skills <agent-type> --json
```
`--json` 플래그는 구조화된 소비 및 테스트 어서션에 적합한 타입이 지정된 IR 객체를 반환하며, 기본값(플래그 없음)은 워크플로우 셸 확장이 의존하는 원시 XML 출력을 보존합니다.
@@ -354,13 +354,13 @@ node gsd-tools.cjs agent-skills <agent-type> --json
```bash
# 스킬 매니페스트 생성 (.claude/skill-manifest.json에 기록)
node gsd-tools.cjs skill-manifest
node msd-tools.cjs skill-manifest
# 사용자 정의 출력 경로로 생성
node gsd-tools.cjs skill-manifest --output <path>
node msd-tools.cjs skill-manifest --output <path>
```
사용 가능한 모든 GSD 스킬과 해당 메타데이터(이름, 설명, 파일 경로, 인수 힌트)의 JSON 매핑을 반환합니다. 반복적인 파일시스템 스캔을 방지하기 위해 설치 프로그램과 세션 시작 훅에서 사용됩니다.
사용 가능한 모든 MSD 스킬과 해당 메타데이터(이름, 설명, 파일 경로, 인수 힌트)의 JSON 매핑을 반환합니다. 반복적인 파일시스템 스캔을 방지하기 위해 설치 프로그램과 세션 시작 훅에서 사용됩니다.
---
@@ -368,54 +368,54 @@ node gsd-tools.cjs skill-manifest --output <path>
```bash
# 텍스트를 URL 안전 슬러그로 변환
node gsd-tools.cjs generate-slug "Some Text Here"
node msd-tools.cjs generate-slug "Some Text Here"
# → some-text-here
# 타임스탬프 가져오기
node gsd-tools.cjs current-timestamp [full|date|filename]
node msd-tools.cjs current-timestamp [full|date|filename]
# 보류 중인 할 일 카운트 및 목록
node gsd-tools.cjs list-todos [area]
node msd-tools.cjs list-todos [area]
# 파일/디렉토리 존재 여부 확인
node gsd-tools.cjs verify-path-exists <path>
node msd-tools.cjs verify-path-exists <path>
# 모든 SUMMARY.md 데이터 집계
node gsd-tools.cjs history-digest
node msd-tools.cjs history-digest
# SUMMARY.md에서 구조화된 데이터 추출
node gsd-tools.cjs summary-extract <path> [--fields field1,field2]
node msd-tools.cjs summary-extract <path> [--fields field1,field2]
# 프로젝트 통계
node gsd-tools.cjs stats [json|table]
node msd-tools.cjs stats [json|table]
# 진행률 렌더링 (사람이 읽을 수 있는 형태)
node gsd-tools.cjs progress [json|table|bar]
node msd-tools.cjs progress [json|table|bar]
# 타입이 지정된 JSON 인터페이스로서의 진행률 (#455)
node gsd-tools.cjs progress --json
node msd-tools.cjs progress --json
# 할 일 완료
node gsd-tools.cjs todo complete <filename> [--dry-run]
node msd-tools.cjs todo complete <filename> [--dry-run]
# UAT 감사 — 모든 단계에서 미해결 항목 스캔
node gsd-tools.cjs audit-uat
node msd-tools.cjs audit-uat
# 교차 아티팩트 감사 큐 — `.planning/`에서 미해결 감사 항목 스캔
node gsd-tools.cjs audit-open [--json]
node msd-tools.cjs audit-open [--json]
# GSD-2 프로젝트를 현재 구조로 역 마이그레이션 (`/gsd-import --from-gsd2` 지원)
node gsd-tools.cjs from-gsd2 [--path <dir>] [--force] [--dry-run]
# GSD-2 프로젝트를 현재 구조로 역 마이그레이션 (`/msd-import --from-gsd2` 지원)
node msd-tools.cjs from-gsd2 [--path <dir>] [--force] [--dry-run]
# 설정 확인과 함께 git 커밋
node gsd-tools.cjs commit <message> [--files f1 f2] [--amend] [--no-verify] [--respect-staged]
node msd-tools.cjs commit <message> [--files f1 f2] [--amend] [--no-verify] [--respect-staged]
```
> `--no-verify`: 사전 커밋 훅을 건너뜁니다. 병렬 실행기 에이전트가 웨이브 기반 실행 중에 빌드 잠금 충돌(예: Rust 프로젝트의 cargo lock 경쟁)을 방지하기 위해 사용합니다. 오케스트레이터는 각 웨이브 완료 후 훅을 한 번 실행합니다. 순차 실행 중에는 `--no-verify`를 사용하지 마세요 — 훅이 정상적으로 실행되도록 하세요.
> `--files <paths>` **스테이징 동작**: 기본적으로 `--files`는 커밋 전에 각 명명된 파일에 대해 `git add -- <path>`를 실행합니다. 이렇게 하면 `git add -p`를 통해 설정된 헝크별 스테이징이 덮어쓰여집니다. `--respect-staged`를 전달하면 `git add` 단계를 건너뛰고 요청된 경로 사양 내에서 이미 인덱스에 있는 것만 커밋합니다. 해당 범위 내에서 스테이징된 것이 없으면 명령은 오류 없이 `{ committed: false, reason: 'nothing staged' }`를 반환합니다. 커밋의 후행 `-- <paths>` 경로 사양은 두 모드 모두에서 적용되므로 `--files` 범위 외부에서 스테이징된 파일은 절대 포함되지 않습니다(#3061 불변식).
# 웹 검색 (Brave API 키 필요)
node gsd-tools.cjs websearch <query> [--limit N] [--freshness day|week|month]
node msd-tools.cjs websearch <query> [--limit N] [--freshness day|week|month]
```
---
@@ -426,22 +426,22 @@ node gsd-tools.cjs websearch <query> [--limit N] [--freshness day|week|month]
```bash
# 지식 그래프 빌드 또는 재빌드
node gsd-tools.cjs graphify build
node msd-tools.cjs graphify build
# 그래프에서 용어 검색
node gsd-tools.cjs graphify query <term>
node msd-tools.cjs graphify query <term>
# 그래프 신선도 및 통계 표시
node gsd-tools.cjs graphify status
node msd-tools.cjs graphify status
# 마지막 빌드 이후 변경 사항 표시
node gsd-tools.cjs graphify diff
node msd-tools.cjs graphify diff
# 현재 그래프의 명명된 스냅샷 기록
node gsd-tools.cjs graphify snapshot [name]
node msd-tools.cjs graphify snapshot [name]
```
사용자 대면 진입점: `/gsd-graphify` ([명령 참조](COMMANDS.md#gsd-graphify) 참조).
사용자 대면 진입점: `/msd-graphify` ([명령 참조](COMMANDS.md#msd-graphify) 참조).
---
@@ -465,30 +465,30 @@ node gsd-tools.cjs graphify snapshot [name]
| UAT | `lib/uat.cjs` | 교차 단계 UAT/검증 감사 |
| Profile Output | `lib/profile-output.cjs` | 개발자 프로파일 서식 지정 |
| Profile Pipeline | `lib/profile-pipeline.cjs` | 세션 분석 파이프라인 |
| Graphify | `lib/graphify.cjs` | 지식 그래프 빌드/쿼리/상태/diff/스냅샷 (`/gsd-graphify` 지원) |
| Learnings | `lib/learnings.cjs` | 단계/SUMMARY 아티팩트에서 학습 내용 추출 (`/gsd-extract-learnings` 지원) |
| Graphify | `lib/graphify.cjs` | 지식 그래프 빌드/쿼리/상태/diff/스냅샷 (`/msd-graphify` 지원) |
| Learnings | `lib/learnings.cjs` | 단계/SUMMARY 아티팩트에서 학습 내용 추출 (`/msd-extract-learnings` 지원) |
| Audit | `lib/audit.cjs` | 단계/마일스톤 감사 큐 핸들러; `audit-open` 헬퍼 |
| GSD2 Import | `lib/gsd2-import.cjs` | GSD-2 프로젝트에서 역 마이그레이션 임포터 (`/gsd-import --from-gsd2` 지원) |
| Intel | `lib/intel.cjs` | 쿼리 가능한 코드베이스 인텔리전스 인덱스 (`/gsd-map-codebase --query` 지원) |
| MSD2 Import | `lib/gsd2-import.cjs` | GSD-2 프로젝트에서 역 마이그레이션 임포터 (`/msd-import --from-gsd2` 지원) |
| Intel | `lib/intel.cjs` | 쿼리 가능한 코드베이스 인텔리전스 인덱스 (`/msd-map-codebase --query` 지원) |
---
## 리뷰어 CLI 라우팅
`review.models.<cli>`는 리뷰어 유형을 코드 리뷰 워크플로우가 호출하는 셸 명령에 매핑합니다. [`/gsd-config --integrations`](COMMANDS.md#gsd-config)를 통해 또는 직접 설정:
`review.models.<cli>`는 리뷰어 유형을 코드 리뷰 워크플로우가 호출하는 셸 명령에 매핑합니다. [`/msd-config --integrations`](COMMANDS.md#msd-config)를 통해 또는 직접 설정:
```bash
node gsd-tools.cjs config-set review.models.codex "codex exec --model gpt-5"
node gsd-tools.cjs config-set review.models.agy "gemini-3.1-pro-preview"
node gsd-tools.cjs config-set review.models.opencode "opencode run --model claude-sonnet-4"
node gsd-tools.cjs config-set review.models.claude "" # clear — fall back to session model
node msd-tools.cjs config-set review.models.codex "codex exec --model gpt-5"
node msd-tools.cjs config-set review.models.agy "gemini-3.1-pro-preview"
node msd-tools.cjs config-set review.models.opencode "opencode run --model claude-sonnet-4"
node msd-tools.cjs config-set review.models.claude "" # clear — fall back to session model
```
슬러그는 `[a-zA-Z0-9_-]+`에 대해 검증됩니다; 비어 있거나 경로를 포함하는 슬러그는 거부됩니다. 전체 필드 참조는 [`docs/CONFIGURATION.md`](CONFIGURATION.md#code-review-cli-routing)를 참조하세요.
## 시크릿 처리
`/gsd-settings`(`brave_search`, `firecrawl`, `exa_search`)를 통해 설정된 API 키는 `.planning/config.json`에 일반 텍스트로 기록되지만 모든 `config-set` / `config-get` 출력, 확인 테이블, 대화형 프롬프트에서 마스킹(`****<last-4>`)됩니다. 마스킹 구현은 `gsd-core/bin/lib/secrets.cjs`를 참조하세요. `config.json` 파일 자체가 보안 경계입니다 — 파일시스템 권한으로 보호하고 git에서 제외하세요(`.planning/`는 기본적으로 gitignore됩니다).
`/msd-settings`(`brave_search`, `firecrawl`, `exa_search`)를 통해 설정된 API 키는 `.planning/config.json`에 일반 텍스트로 기록되지만 모든 `config-set` / `config-get` 출력, 확인 테이블, 대화형 프롬프트에서 마스킹(`****<last-4>`)됩니다. 마스킹 구현은 `msd-core/bin/lib/secrets.cjs`를 참조하세요. `config.json` 파일 자체가 보안 경계입니다 — 파일시스템 권한으로 보호하고 git에서 제외하세요(`.planning/`는 기본적으로 gitignore됩니다).
---

682
docs/ko-KR/COMMANDS.md
View File

File diff suppressed because it is too large Load Diff

74
docs/ko-KR/CONFIGURATION.md
View File

@@ -1,4 +1,4 @@
# GSD 설정 레퍼런스
# MSD 설정 레퍼런스
> 전체 설정 스키마, 워크플로우 토글, 모델 프로필, git 브랜칭 옵션입니다. 기능에 대한 맥락은 [Feature Reference](FEATURES.md)를 참조하세요.
@@ -6,7 +6,7 @@
## 설정 파일
GSD는 프로젝트 설정을 `.planning/config.json`에 저장합니다. `/gsd-new-project` 실행 시 생성되며 `/gsd-settings`를 통해 업데이트할 수 있습니다.
MSD는 프로젝트 설정을 `.planning/config.json`에 저장합니다. `/msd-new-project` 실행 시 생성되며 `/msd-settings`를 통해 업데이트할 수 있습니다.
### 전체 스키마
@@ -50,8 +50,8 @@ GSD는 프로젝트 설정을 `.planning/config.json`에 저장합니다. `/gsd-
},
"git": {
"branching_strategy": "none",
"phase_branch_template": "gsd/phase-{phase}-{slug}",
"milestone_branch_template": "gsd/{milestone}-{slug}",
"phase_branch_template": "msd/phase-{phase}-{slug}",
"milestone_branch_template": "msd/{milestone}-{slug}",
"quick_branch_template": null
},
"gates": {
@@ -97,15 +97,15 @@ GSD는 프로젝트 설정을 `.planning/config.json`에 저장합니다. `/gsd-
| `workflow.auto_advance` | boolean | `false` | discuss → plan → execute를 중단 없이 자동으로 연결 |
| `workflow.nyquist_validation` | boolean | `true` | plan 단계 리서치 중 테스트 커버리지 매핑 |
| `workflow.ui_phase` | boolean | `true` | 프론트엔드 단계를 위한 UI 디자인 계약서 생성 |
| `workflow.ui_safety_gate` | boolean | `true` | plan 단계에서 프론트엔드 단계에 대해 /gsd-ui-phase 실행 여부 확인 |
| `workflow.ui_safety_gate` | boolean | `true` | plan 단계에서 프론트엔드 단계에 대해 /msd-ui-phase 실행 여부 확인 |
| `workflow.node_repair` | boolean | `true` | 검증 실패 시 자율적 태스크 복구 |
| `workflow.node_repair_budget` | number | `2` | 실패한 태스크당 최대 복구 시도 횟수 |
| `workflow.research_before_questions` | boolean | `false` | 토론 질문 후가 아닌 전에 리서치 실행 |
| `workflow.use_worktrees` | boolean | `true` | `false`이면 git worktree 격리 비활성화 (v1.31) |
| `workflow.discuss_mode` | string | `'discuss'` | `/gsd-discuss-phase`의 컨텍스트 수집 방식을 제어합니다. `'discuss'` (기본값)는 질문을 하나씩 합니다. `'assumptions'`는 코드베이스를 먼저 읽고 신뢰도 수준이 있는 구조화된 가정을 생성하여 틀린 부분만 수정하도록 요청합니다. v1.28에서 추가 |
| `workflow.skip_discuss` | boolean | `false` | `true`로 설정하면 `/gsd-autonomous`가 discuss 단계를 완전히 건너뛰고 ROADMAP 단계 목표로부터 최소한의 CONTEXT.md를 작성합니다. 개발자 선호사항이 PROJECT.md/REQUIREMENTS.md에 모두 캡처된 프로젝트에 유용합니다. v1.28에서 추가 |
| `workflow.discuss_mode` | string | `'discuss'` | `/msd-discuss-phase`의 컨텍스트 수집 방식을 제어합니다. `'discuss'` (기본값)는 질문을 하나씩 합니다. `'assumptions'`는 코드베이스를 먼저 읽고 신뢰도 수준이 있는 구조화된 가정을 생성하여 틀린 부분만 수정하도록 요청합니다. v1.28에서 추가 |
| `workflow.skip_discuss` | boolean | `false` | `true`로 설정하면 `/msd-autonomous`가 discuss 단계를 완전히 건너뛰고 ROADMAP 단계 목표로부터 최소한의 CONTEXT.md를 작성합니다. 개발자 선호사항이 PROJECT.md/REQUIREMENTS.md에 모두 캡처된 프로젝트에 유용합니다. v1.28에서 추가 |
| `workflow.text_mode` | boolean | `false` | AskUserQuestion TUI 메뉴를 일반 텍스트 번호 목록으로 대체합니다. TUI 메뉴가 렌더링되지 않는 Claude Code 원격 세션 (`/rc` 모드)에 필요합니다. discuss 단계에서 `--text` 플래그로 세션별 설정도 가능합니다. v1.28에서 추가 |
| `planner.stall_detection_enabled` | boolean | `true` | 표준 플래너, 청크형 개요/플랜별 플래너, 플랜 검사기, 수정 플래너의 제한된 정지 감지를 제어합니다. `gsd config-set planner.stall_detection_enabled false`로 설정하면 watchdog 폴링을 건너뛰고 각 에이전트를 런타임 네이티브 완료 메커니즘으로 기다립니다. **경고:** `false`는 런타임이 완료 전달을 잃을 때의 제한된 복구를 포기합니다. 기존 파일 시스템 폴백을 사용하려면 중단해야 할 수 있습니다. |
| `planner.stall_detection_enabled` | boolean | `true` | 표준 플래너, 청크형 개요/플랜별 플래너, 플랜 검사기, 수정 플래너의 제한된 정지 감지를 제어합니다. `msd config-set planner.stall_detection_enabled false`로 설정하면 watchdog 폴링을 건너뛰고 각 에이전트를 런타임 네이티브 완료 메커니즘으로 기다립니다. **경고:** `false`는 런타임이 완료 전달을 잃을 때의 제한된 복구를 포기합니다. 기존 파일 시스템 폴백을 사용하려면 중단해야 할 수 있습니다. |
### 권장 프리셋
@@ -122,7 +122,7 @@ GSD는 프로젝트 설정을 `.planning/config.json`에 저장합니다. `/gsd-
| 설정 | 타입 | 기본값 | 설명 |
|------|------|--------|------|
| `planning.commit_docs` | boolean | `true` | `.planning/` 파일을 git에 커밋할지 여부 |
| `planning.pr_strict` | boolean | `false` | `/gsd-pr-branch`의 필터 모드. `false`는 STATE.md, ROADMAP.md, MILESTONES.md, PROJECT.md, REQUIREMENTS.md, milestones/ 등 구조적 플래닝 상태를 PR 브랜치에 유지하고, `true`는 모든 `.planning/` 경로를 제거함 |
| `planning.pr_strict` | boolean | `false` | `/msd-pr-branch`의 필터 모드. `false`는 STATE.md, ROADMAP.md, MILESTONES.md, PROJECT.md, REQUIREMENTS.md, milestones/ 등 구조적 플래닝 상태를 PR 브랜치에 유지하고, `true`는 모든 `.planning/` 경로를 제거함 |
| `planning.search_gitignored` | boolean | `false` | 광범위한 검색에 `--no-ignore`를 추가하여 `.planning/`을 포함 |
### 자동 감지
@@ -136,9 +136,9 @@ GSD는 프로젝트 설정을 `.planning/config.json`에 저장합니다. `/gsd-
| 설정 | 타입 | 기본값 | 설명 |
|------|------|--------|------|
| `hooks.context_warnings` | boolean | `true` | context monitor 훅을 통해 컨텍스트 윈도우 사용 경고 표시 |
| `hooks.workflow_guard` | boolean | `false` | GSD 워크플로우 컨텍스트 밖에서 파일 편집이 발생할 때 경고 ((`/gsd-quick` 또는 `/gsd-fast` 사용 권고)) |
| `hooks.workflow_guard` | boolean | `false` | MSD 워크플로우 컨텍스트 밖에서 파일 편집이 발생할 때 경고 ((`/msd-quick` 또는 `/msd-fast` 사용 권고)) |
프롬프트 주입 방지 훅 (`gsd-prompt-guard.js`)은 항상 활성화되며 비활성화할 수 없습니다. 워크플로우 토글이 아닌 보안 기능입니다.
프롬프트 주입 방지 훅 (`msd-prompt-guard.js`)은 항상 활성화되며 비활성화할 수 없습니다. 워크플로우 토글이 아닌 보안 기능입니다.
### 플래닝 비공개 설정
@@ -170,9 +170,9 @@ GSD는 프로젝트 설정을 `.planning/config.json`에 저장합니다. `/gsd-
| 설정 | 타입 | 기본값 | 설명 |
|------|------|--------|------|
| `git.branching_strategy` | enum | `none` | `none`, `phase`, 또는 `milestone` |
| `git.phase_branch_template` | string | `gsd/phase-{phase}-{slug}` | phase 전략의 브랜치 이름 템플릿 |
| `git.milestone_branch_template` | string | `gsd/{milestone}-{slug}` | milestone 전략의 브랜치 이름 템플릿 |
| `git.quick_branch_template` | string 또는 null | `null` | `/gsd-quick` 태스크를 위한 선택적 브랜치 이름 템플릿 |
| `git.phase_branch_template` | string | `msd/phase-{phase}-{slug}` | phase 전략의 브랜치 이름 템플릿 |
| `git.milestone_branch_template` | string | `msd/{milestone}-{slug}` | milestone 전략의 브랜치 이름 템플릿 |
| `git.quick_branch_template` | string 또는 null | `null` | `/msd-quick` 태스크를 위한 선택적 브랜치 이름 템플릿 |
### 전략 비교
@@ -195,7 +195,7 @@ quick 태스크 브랜칭 예시:
```json
"git": {
"quick_branch_template": "gsd/quick-{num}-{slug}"
"quick_branch_template": "msd/quick-{num}-{slug}"
}
```
@@ -270,18 +270,18 @@ quick 태스크 브랜칭 예시:
| 에이전트 | `quality` | `balanced` | `budget` | `inherit` |
|---------|-----------|------------|----------|-----------|
| gsd-planner | Opus | Opus | Sonnet | Inherit |
| gsd-roadmapper | Opus | Sonnet | Sonnet | Inherit |
| gsd-executor | Opus | Sonnet | Sonnet | Inherit |
| gsd-phase-researcher | Opus | Sonnet | Haiku | Inherit |
| gsd-project-researcher | Opus | Sonnet | Haiku | Inherit |
| gsd-research-synthesizer | Sonnet | Sonnet | Haiku | Inherit |
| gsd-debugger | Opus | Sonnet | Sonnet | Inherit |
| gsd-codebase-mapper | Sonnet | Haiku | Haiku | Inherit |
| gsd-verifier | Sonnet | Sonnet | Haiku | Inherit |
| gsd-plan-checker | Sonnet | Sonnet | Haiku | Inherit |
| gsd-integration-checker | Sonnet | Sonnet | Haiku | Inherit |
| gsd-nyquist-auditor | Sonnet | Sonnet | Haiku | Inherit |
| msd-planner | Opus | Opus | Sonnet | Inherit |
| msd-roadmapper | Opus | Sonnet | Sonnet | Inherit |
| msd-executor | Opus | Sonnet | Sonnet | Inherit |
| msd-phase-researcher | Opus | Sonnet | Haiku | Inherit |
| msd-project-researcher | Opus | Sonnet | Haiku | Inherit |
| msd-research-synthesizer | Sonnet | Sonnet | Haiku | Inherit |
| msd-debugger | Opus | Sonnet | Sonnet | Inherit |
| msd-codebase-mapper | Sonnet | Haiku | Haiku | Inherit |
| msd-verifier | Sonnet | Sonnet | Haiku | Inherit |
| msd-plan-checker | Sonnet | Sonnet | Haiku | Inherit |
| msd-integration-checker | Sonnet | Sonnet | Haiku | Inherit |
| msd-nyquist-auditor | Sonnet | Sonnet | Haiku | Inherit |
### 에이전트별 재정의
@@ -291,8 +291,8 @@ quick 태스크 브랜칭 예시:
{
"model_profile": "balanced",
"model_overrides": {
"gsd-executor": "opus",
"gsd-planner": "haiku"
"msd-executor": "opus",
"msd-planner": "haiku"
}
}
```
@@ -301,7 +301,7 @@ quick 태스크 브랜칭 예시:
### 비 Claude 런타임 (Codex, OpenCode, Antigravity CLI, Kilo)
비 Claude 런타임에 GSD를 설치하면 인스톨러가 자동으로 `~/.gsd/defaults.json`에 `resolve_model_ids: "omit"`을 설정합니다. 이로 인해 GSD는 모든 에이전트에 빈 model 파라미터를 반환하며 각 에이전트는 런타임에 설정된 모델을 사용합니다. 기본 사용 시 추가 설정은 필요하지 않습니다.
비 Claude 런타임에 MSD를 설치하면 인스톨러가 자동으로 `~/.msd/defaults.json`에 `resolve_model_ids: "omit"`을 설정합니다. 이로 인해 MSD는 모든 에이전트에 빈 model 파라미터를 반환하며 각 에이전트는 런타임에 설정된 모델을 사용합니다. 기본 사용 시 추가 설정은 필요하지 않습니다.
에이전트마다 다른 모델을 사용하려면 런타임이 인식하는 완전히 정규화된 모델 ID로 `model_overrides`를 사용합니다.
@@ -309,10 +309,10 @@ quick 태스크 브랜칭 예시:
{
"resolve_model_ids": "omit",
"model_overrides": {
"gsd-planner": "o3",
"gsd-executor": "o4-mini",
"gsd-debugger": "o3",
"gsd-codebase-mapper": "o4-mini"
"msd-planner": "o3",
"msd-executor": "o4-mini",
"msd-debugger": "o3",
"msd-codebase-mapper": "o4-mini"
}
}
```
@@ -354,7 +354,7 @@ quick 태스크 브랜칭 예시:
| `CLAUDE_CONFIG_DIR` | 기본 설정 디렉토리 재정의 (`~/.claude/`) |
| `GEMINI_API_KEY` | context monitor가 훅 이벤트 이름을 전환하기 위해 감지 |
| `WSL_DISTRO_NAME` | 인스톨러가 WSL 경로 처리를 위해 감지 |
| `GSD_SKIP_SCHEMA_CHECK` | 스키마 드리프트 감지 바이패스 (v1.31) |
| `MSD_SKIP_SCHEMA_CHECK` | 스키마 드리프트 감지 바이패스 (v1.31) |
---
@@ -362,6 +362,6 @@ quick 태스크 브랜칭 예시:
향후 프로젝트를 위한 전역 기본값으로 설정을 저장할 수 있습니다.
**위치:** `~/.gsd/defaults.json`
**위치:** `~/.msd/defaults.json`
`/gsd-new-project`가 새 `config.json`을 생성할 때 전역 기본값을 읽어 초기 설정으로 병합합니다. 프로젝트별 설정은 항상 전역 설정보다 우선합니다.
`/msd-new-project`가 새 `config.json`을 생성할 때 전역 기본값을 읽어 초기 설정으로 병합합니다. 프로젝트별 설정은 항상 전역 설정보다 우선합니다.

302
docs/ko-KR/FEATURES.md
View File

@@ -1,4 +1,4 @@
# GSD 기능 참조
# MSD 기능 참조
> 기능 및 함수에 대한 완전한 문서와 요구사항입니다. 아키텍처 세부 사항은 [Architecture](ARCHITECTURE.md)를, 명령어 문법은 [Command Reference](COMMANDS.md)를 참조하세요.
@@ -110,7 +110,7 @@
### 1. Project Initialization
**명령어:** `/gsd-new-project [--auto @file.md]`
**명령어:** `/msd-new-project [--auto @file.md]`
**목적:** 사용자의 아이디어를 연구, 범위가 지정된 요구사항, 단계별 로드맵을 갖춘 완전히 구조화된 프로젝트로 전환합니다.
@@ -149,13 +149,13 @@
- 연구 에이전트는 현재 생태계 정보를 위한 웹 검색 기능을 갖추고 있습니다.
- 세분화 설정으로 페이즈 수를 제어합니다. `coarse`(3-5), `standard`(5-8), `fine`(8-12)
- `--auto` 모드는 대화형 질문 없이 제공된 문서에서 모든 정보를 추출합니다.
- 기존 코드베이스 컨텍스트(`/gsd-map-codebase`에서)가 있으면 로드됩니다.
- 기존 코드베이스 컨텍스트(`/msd-map-codebase`에서)가 있으면 로드됩니다.
---
### 2. Phase Discussion
**명령어:** `/gsd-discuss-phase [N] [--auto] [--batch]`
**명령어:** `/msd-discuss-phase [N] [--auto] [--batch]`
**목적:** 연구와 계획이 시작되기 전에 사용자의 구현 선호도와 결정을 캡처합니다. AI가 추측하게 만드는 회색 지대를 제거합니다.
@@ -182,7 +182,7 @@
### 3. UI Design Contract
**명령어:** `/gsd-ui-phase [N]`
**명령어:** `/msd-ui-phase [N]`
**목적:** 계획 전에 설계 결정을 확정하여 페이즈 내 모든 컴포넌트가 일관된 시각적 기준을 공유하도록 합니다.
@@ -215,7 +215,7 @@
### 4. Phase Planning
**명령어:** `/gsd-plan-phase [N] [--auto] [--skip-research] [--skip-verify]`
**명령어:** `/msd-plan-phase [N] [--auto] [--skip-research] [--skip-verify]`
**목적:** 구현 도메인을 연구하고 검증된 원자적 실행 계획을 생성합니다.
@@ -226,7 +226,7 @@
- REQ-PLAN-04: 모든 계획에 `read_first`와 `acceptance_criteria` 섹션을 포함해야 합니다.
- REQ-PLAN-05: `--skip-verify`가 설정되지 않은 경우 계획 검사기 검증 루프를 실행해야 합니다(최대 3회 반복).
- REQ-PLAN-06: 연구 단계를 건너뛰는 `--skip-research` 플래그를 지원해야 합니다.
- REQ-PLAN-07: 프론트엔드 페이즈가 감지되고 UI-SPEC.md가 없는 경우 `/gsd-ui-phase` 실행을 촉구해야 합니다(UI 안전 게이트).
- REQ-PLAN-07: 프론트엔드 페이즈가 감지되고 UI-SPEC.md가 없는 경우 `/msd-ui-phase` 실행을 촉구해야 합니다(UI 안전 게이트).
- REQ-PLAN-08: `workflow.nyquist_validation`이 활성화된 경우 Nyquist 유효성 검사 매핑을 포함해야 합니다.
- REQ-PLAN-09: 계획이 완료되기 전에 모든 페이즈 요구사항이 최소 하나의 계획에 포함되어 있는지 확인해야 합니다(요구사항 커버리지 게이트).
@@ -265,7 +265,7 @@
### 5. Phase Execution
**명령어:** `/gsd-execute-phase <N>`
**명령어:** `/msd-execute-phase <N>`
**목적:** 실행자별 새로운 컨텍스트 창을 사용한 웨이브 기반 병렬화로 페이즈의 모든 계획을 실행합니다.
@@ -309,7 +309,7 @@
### 6. Work Verification
**명령어:** `/gsd-verify-work [N]`
**명령어:** `/msd-verify-work [N]`
**목적:** 사용자 인수 테스트 — 각 결과물을 테스트하는 과정을 사용자와 함께 진행하고 실패를 자동으로 진단합니다.
@@ -327,7 +327,7 @@
### 6.5. Ship
**명령어:** `/gsd-ship [N] [--draft]`
**명령어:** `/msd-ship [N] [--draft]`
**목적:** 로컬 완료에서 병합된 PR로의 전환. 검증 통과 후 브랜치를 푸시하고, 계획 산출물에서 자동 생성된 본문으로 PR을 작성하며, 선택적으로 검토를 요청하고 STATE.md에 추적합니다.
@@ -346,7 +346,7 @@
### 7. UI Review
**명령어:** `/gsd-ui-review [N]`
**명령어:** `/msd-ui-review [N]`
**목적:** 구현된 프론트엔드 코드의 소급 6기둥 시각적 감사. 모든 프로젝트에서 독립적으로 작동합니다.
@@ -371,7 +371,7 @@
### 8. Milestone Management
**명령어:** `/gsd-audit-milestone`, `/gsd-complete-milestone`, `/gsd-new-milestone [name]`
**명령어:** `/msd-audit-milestone`, `/msd-complete-milestone`, `/msd-new-milestone [name]`
**목적:** 마일스톤 완료를 검증하고, 보관하고, 릴리스 태그를 지정하며, 다음 개발 주기를 시작합니다.
@@ -393,7 +393,7 @@
### 9. Phase Management
**명령어:** `/gsd-phase`, `/gsd-phase --insert [N]`, `/gsd-phase --remove [N]`
**명령어:** `/msd-phase`, `/msd-phase --insert [N]`, `/msd-phase --remove [N]`
**목적:** 개발 중 동적 로드맵 수정.
@@ -408,9 +408,9 @@
### 10. Quick Mode
**명령어:** `/gsd-quick [--full] [--discuss] [--research]`
**명령어:** `/msd-quick [--full] [--discuss] [--research]`
**목적:** GSD 보증을 제공하지만 더 빠른 경로로 임시 작업을 실행합니다.
**목적:** MSD 보증을 제공하지만 더 빠른 경로로 임시 작업을 실행합니다.
**요구사항.**
- REQ-QUICK-01: 자유형 작업 설명을 받아야 합니다.
@@ -427,7 +427,7 @@
### 11. Autonomous Mode
**명령어:** `/gsd-autonomous [--from N]`
**명령어:** `/msd-autonomous [--from N]`
**목적:** 나머지 모든 페이즈를 자율적으로 실행합니다 — 페이즈별로 논의 → 계획 → 실행.
@@ -442,13 +442,13 @@
### 12. Freeform Routing
**명령어:** `/gsd-fast`
**명령어:** `/msd-fast`
**목적:** 자유형 텍스트를 분석하고 적절한 GSD 명령어로 라우팅합니다.
**목적:** 자유형 텍스트를 분석하고 적절한 MSD 명령어로 라우팅합니다.
**요구사항.**
- REQ-DO-01: 자연어 입력에서 사용자 의도를 파악해야 합니다.
- REQ-DO-02: 의도를 가장 적합한 GSD 명령어에 매핑해야 합니다.
- REQ-DO-02: 의도를 가장 적합한 MSD 명령어에 매핑해야 합니다.
- REQ-DO-03: 실행 전에 라우팅을 사용자에게 확인해야 합니다.
- REQ-DO-04: 프로젝트가 존재하는 경우와 없는 경우를 다르게 처리해야 합니다.
@@ -456,7 +456,7 @@
### 13. Note Capture
**명령어:** `/gsd-capture`
**명령어:** `/msd-capture`
**목적:** 워크플로우를 방해하지 않고 아이디어를 즉시 캡처합니다. 타임스탬프가 있는 노트를 추가하거나, 모든 노트를 나열하거나, 노트를 구조화된 할 일로 승격합니다.
@@ -471,7 +471,7 @@
### 14. Auto-Advance (Next)
**명령어:** `/gsd-progress --next`
**명령어:** `/msd-progress --next`
**목적:** 현재 프로젝트 상태를 자동으로 감지하고 다음 논리적 워크플로우 단계로 진행합니다. 현재 어느 페이즈/단계에 있는지 기억할 필요가 없습니다.
@@ -479,18 +479,18 @@
- REQ-NEXT-01: STATE.md, ROADMAP.md, 페이즈 디렉토리를 읽어 현재 위치를 확인해야 합니다.
- REQ-NEXT-02: 논의, 계획, 실행, 검증 중 어느 것이 필요한지 감지해야 합니다.
- REQ-NEXT-03: 올바른 명령어를 자동으로 호출해야 합니다.
- REQ-NEXT-04: 프로젝트가 없으면 `/gsd-new-project`를 제안해야 합니다.
- REQ-NEXT-05: 모든 페이즈가 완료되면 `/gsd-complete-milestone`을 제안해야 합니다.
- REQ-NEXT-04: 프로젝트가 없으면 `/msd-new-project`를 제안해야 합니다.
- REQ-NEXT-05: 모든 페이즈가 완료되면 `/msd-complete-milestone`을 제안해야 합니다.
**상태 감지 로직.**
| 상태 | 액션 |
|-------|--------|
| `.planning/` 디렉토리 없음 | `/gsd-new-project` 제안 |
| 페이즈에 CONTEXT.md 없음 | `/gsd-discuss-phase` 실행 |
| 페이즈에 PLAN.md 파일 없음 | `/gsd-plan-phase` 실행 |
| 계획 있지만 SUMMARY.md 없음 | `/gsd-execute-phase` 실행 |
| 실행되었지만 VERIFICATION.md 없음 | `/gsd-verify-work` 실행 |
| 모든 페이즈 완료 | `/gsd-complete-milestone` 제안 |
| `.planning/` 디렉토리 없음 | `/msd-new-project` 제안 |
| 페이즈에 CONTEXT.md 없음 | `/msd-discuss-phase` 실행 |
| 페이즈에 PLAN.md 파일 없음 | `/msd-plan-phase` 실행 |
| 계획 있지만 SUMMARY.md 없음 | `/msd-execute-phase` 실행 |
| 실행되었지만 VERIFICATION.md 없음 | `/msd-verify-work` 실행 |
| 모든 페이즈 완료 | `/msd-complete-milestone` 제안 |
---
@@ -505,12 +505,12 @@
- REQ-NYQ-02: 각 요구사항을 특정 테스트 명령어에 매핑해야 합니다.
- REQ-NYQ-03: 웨이브 0 작업(구현 전에 필요한 테스트 스캐폴딩)을 식별해야 합니다.
- REQ-NYQ-04: 계획 검사기는 Nyquist 준수를 8번째 검증 차원으로 적용해야 합니다.
- REQ-NYQ-05: `/gsd-validate-phase`를 통한 소급 유효성 검사를 지원해야 합니다.
- REQ-NYQ-05: `/msd-validate-phase`를 통한 소급 유효성 검사를 지원해야 합니다.
- REQ-NYQ-06: `workflow.nyquist_validation: false`로 비활성화 가능해야 합니다.
**생성 산출물.** `{phase}-VALIDATION.md` — 테스트 커버리지 계약
**소급 유효성 검사(`/gsd-validate-phase [N]`).**
**소급 유효성 검사(`/msd-validate-phase [N]`).**
- 구현을 스캔하고 요구사항을 테스트에 매핑합니다.
- 요구사항에 자동화된 검증이 없는 갭을 식별합니다.
- 테스트 생성을 위한 감사자를 생성합니다(최대 3회 시도).
@@ -538,7 +538,7 @@
**요구사항.**
- REQ-POSTVER-01: 작업 완료가 아닌 페이즈 목표에 대해 확인해야 합니다.
- REQ-POSTVER-02: 합격/불합격 분석이 담긴 VERIFICATION.md를 생성해야 합니다.
- REQ-POSTVER-03: `/gsd-verify-work`가 처리할 문제를 기록해야 합니다.
- REQ-POSTVER-03: `/msd-verify-work`가 처리할 문제를 기록해야 합니다.
- REQ-POSTVER-04: `workflow.verifier: false`로 비활성화 가능해야 합니다.
---
@@ -559,7 +559,7 @@
### 19. Health Validation
**명령어:** `/gsd-health [--repair]`
**명령어:** `/msd-health [--repair]`
**목적:** `.planning/` 디렉토리 무결성을 검증하고 문제를 자동으로 복구합니다.
@@ -582,7 +582,7 @@
- REQ-REGR-03: 회귀는 실행 후 검증 전에 표시되어야 합니다.
- REQ-REGR-04: 어느 이전 페이즈의 테스트가 실패했는지 식별해야 합니다.
**실행 시점.** `/gsd-execute-phase` 중 검증자 단계 전에 자동으로 실행됩니다.
**실행 시점.** `/msd-execute-phase` 중 검증자 단계 전에 자동으로 실행됩니다.
---
@@ -596,7 +596,7 @@
- REQ-COVGATE-03: 포함되지 않은 요구사항은 계획 완료를 차단해야 합니다.
- REQ-COVGATE-04: 계획 커버리지가 없는 특정 요구사항을 보고해야 합니다.
**실행 시점.** `/gsd-plan-phase`의 계획 검사기 루프 후 자동으로 실행됩니다.
**실행 시점.** `/msd-plan-phase`의 계획 검사기 루프 후 자동으로 실행됩니다.
---
@@ -612,7 +612,7 @@
- REQ-CTX-03: 컨텍스트 모니터는 남은 용량 ≤25%(CRITICAL)에서 에이전트 대상 경고를 주입해야 합니다.
- REQ-CTX-04: 경고는 디바운스되어야 합니다(반복 경고 사이에 5회 도구 사용).
- REQ-CTX-05: 심각도 에스컬레이션(WARNING→CRITICAL)은 디바운스를 우회해야 합니다.
- REQ-CTX-06: 컨텍스트 모니터는 GSD 활성 프로젝트와 비활성 프로젝트를 구분해야 합니다.
- REQ-CTX-06: 컨텍스트 모니터는 MSD 활성 프로젝트와 비활성 프로젝트를 구분해야 합니다.
- REQ-CTX-07: 경고는 권고 사항이어야 하며 사용자 선호도를 재정의하는 명령적 지시가 되어서는 안 됩니다.
- REQ-CTX-08: 모든 훅은 자동으로 실패해야 하며 도구 실행을 차단해서는 안 됩니다.
@@ -624,7 +624,7 @@
### 23. Session Management
**명령어:** `/gsd-pause-work`, `/gsd-resume-work`, `/gsd-progress`
**명령어:** `/msd-pause-work`, `/msd-resume-work`, `/msd-progress`
**목적:** 컨텍스트 초기화와 세션 간에 프로젝트 연속성을 유지합니다.
@@ -641,7 +641,7 @@
### 24. Session Reporting
**명령어:** `/gsd-pause-work --report`
**명령어:** `/msd-pause-work --report`
**목적:** 수행된 작업, 달성된 결과, 예상 리소스 사용량을 캡처하는 구조화된 세션 후 요약 문서를 생성합니다.
@@ -680,7 +680,7 @@
### 26. Model Profiles
**명령어:** `/gsd-config --profile <quality|balanced|budget|inherit>`
**명령어:** `/msd-config --profile <quality|balanced|budget|inherit>`
**목적:** 각 에이전트가 사용하는 AI 모델을 제어하여 품질과 비용의 균형을 맞춥니다.
@@ -697,18 +697,18 @@
| 에이전트 | `quality` | `balanced` | `budget` | `inherit` |
|-------|-----------|------------|----------|-----------|
| gsd-planner | Opus | Opus | Sonnet | Inherit |
| gsd-roadmapper | Opus | Sonnet | Sonnet | Inherit |
| gsd-executor | Opus | Sonnet | Sonnet | Inherit |
| gsd-phase-researcher | Opus | Sonnet | Haiku | Inherit |
| gsd-project-researcher | Opus | Sonnet | Haiku | Inherit |
| gsd-research-synthesizer | Sonnet | Sonnet | Haiku | Inherit |
| gsd-debugger | Opus | Sonnet | Sonnet | Inherit |
| gsd-codebase-mapper | Sonnet | Haiku | Haiku | Inherit |
| gsd-verifier | Sonnet | Sonnet | Haiku | Inherit |
| gsd-plan-checker | Sonnet | Sonnet | Haiku | Inherit |
| gsd-integration-checker | Sonnet | Sonnet | Haiku | Inherit |
| gsd-nyquist-auditor | Sonnet | Sonnet | Haiku | Inherit |
| msd-planner | Opus | Opus | Sonnet | Inherit |
| msd-roadmapper | Opus | Sonnet | Sonnet | Inherit |
| msd-executor | Opus | Sonnet | Sonnet | Inherit |
| msd-phase-researcher | Opus | Sonnet | Haiku | Inherit |
| msd-project-researcher | Opus | Sonnet | Haiku | Inherit |
| msd-research-synthesizer | Sonnet | Sonnet | Haiku | Inherit |
| msd-debugger | Opus | Sonnet | Sonnet | Inherit |
| msd-codebase-mapper | Sonnet | Haiku | Haiku | Inherit |
| msd-verifier | Sonnet | Sonnet | Haiku | Inherit |
| msd-plan-checker | Sonnet | Sonnet | Haiku | Inherit |
| msd-integration-checker | Sonnet | Sonnet | Haiku | Inherit |
| msd-nyquist-auditor | Sonnet | Sonnet | Haiku | Inherit |
---
@@ -716,15 +716,15 @@
### 27. Codebase Mapping
**명령어:** `/gsd-map-codebase [area]`
**명령어:** `/msd-map-codebase [area]`
**목적:** 새 프로젝트 시작 전 또는 `/gsd-onboard`의 매핑 handoff로 기존 코드베이스를 분석하여 GSD가 무엇이 존재하는지 이해하도록 합니다.
**목적:** 새 프로젝트 시작 전 또는 `/msd-onboard`의 매핑 handoff로 기존 코드베이스를 분석하여 MSD가 무엇이 존재하는지 이해하도록 합니다.
**요구사항.**
- REQ-MAP-01: 각 분석 영역에 대한 병렬 매퍼 에이전트를 생성해야 합니다.
- REQ-MAP-02: `.planning/codebase/`에 구조화된 문서를 생성해야 합니다.
- REQ-MAP-03: 기술 스택, 아키텍처 패턴, 코딩 규범, 문제점을 감지해야 합니다.
- REQ-MAP-04: 이후 `/gsd-new-project`는 코드베이스 매핑을 로드하고 추가하는 내용에 대한 질문에 집중해야 합니다.
- REQ-MAP-04: 이후 `/msd-new-project`는 코드베이스 매핑을 로드하고 추가하는 내용에 대한 질문에 집중해야 합니다.
- REQ-MAP-05: 선택적 `[area]` 인수는 매핑 범위를 특정 영역으로 제한해야 합니다.
**생성 산출물.**
@@ -740,14 +740,14 @@
### 27b. Existing Codebase Onboarding
**명령어:** `/gsd-onboard [--fast] [--text]`
**명령어:** `/msd-onboard [--fast] [--text]`
**목적:** 기존 저장소의 최초 설정을 안내하고 brownfield 상태를 확인해 코드베이스 매핑, docs 수집, 프로젝트 초기화로 안전하게 handoff합니다.
**요구사항.**
- REQ-ONBOARD-01: 기존 코드, package manifest, planning 문서, 부분 `.planning/` 상태, 코드베이스 맵 누락을 감지해야 합니다.
- REQ-ONBOARD-02: 필요한 `.planning/codebase/` 맵 파일이 없는 brownfield에서는 `/gsd-map-codebase` 또는 `/gsd-map-codebase --fast`로 handoff해야 합니다. fast 맵 readiness는 부분 상태이며 `/gsd-new-project`에 충분한 것으로 취급해서는 안 됩니다.
- REQ-ONBOARD-03: ADR/PRD/SPEC/RFC 후보가 있고 project가 없으면 `/gsd-new-project` 전에 `/gsd-ingest-docs`를 제안해야 합니다.
- REQ-ONBOARD-02: 필요한 `.planning/codebase/` 맵 파일이 없는 brownfield에서는 `/msd-map-codebase` 또는 `/msd-map-codebase --fast`로 handoff해야 합니다. fast 맵 readiness는 부분 상태이며 `/msd-new-project`에 충분한 것으로 취급해서는 안 됩니다.
- REQ-ONBOARD-03: ADR/PRD/SPEC/RFC 후보가 있고 project가 없으면 `/msd-new-project` 전에 `/msd-ingest-docs`를 제안해야 합니다.
- REQ-ONBOARD-04: `PROJECT.md`, `REQUIREMENTS.md`, `ROADMAP.md`, `STATE.md`가 모두 있을 때까지 완료로 보고하지 않아야 합니다.
- REQ-ONBOARD-05: project setup 후에만 `.planning/onboarding/SUMMARY.md`를 만들거나 확인해야 합니다.
- REQ-ONBOARD-06: 대화형 메뉴가 없는 runtime을 위해 `--text` 번호형 plain-text gate를 지원해야 합니다.
@@ -755,8 +755,8 @@
**생성 산출물.**
| 산출물 | 설명 |
|----------|-------------|
| `.planning/codebase/` | `/gsd-map-codebase` handoff가 생성한 코드베이스 맵 |
| `.planning/PROJECT.md`, `REQUIREMENTS.md`, `ROADMAP.md`, `STATE.md` | `/gsd-new-project` 또는 `/gsd-ingest-docs`가 생성한 planning setup |
| `.planning/codebase/` | `/msd-map-codebase` handoff가 생성한 코드베이스 맵 |
| `.planning/PROJECT.md`, `REQUIREMENTS.md`, `ROADMAP.md`, `STATE.md` | `/msd-new-project` 또는 `/msd-ingest-docs`가 생성한 planning setup |
| `.planning/onboarding/SUMMARY.md` | Onboarding status, artifact index, next-command summary |
---
@@ -765,7 +765,7 @@
### 28. Debug System
**명령어:** `/gsd-debug [description]`
**명령어:** `/msd-debug [description]`
**목적:** 컨텍스트 초기화 전반에 걸쳐 영구적인 상태로 체계적인 디버깅을 수행합니다.
@@ -783,7 +783,7 @@
### 29. Todo Management
**명령어:** `/gsd-capture [desc]`, `/gsd-capture --list`
**명령어:** `/msd-capture [desc]`, `/msd-capture --list`
**목적:** 세션 중 나중에 처리할 아이디어와 작업을 캡처합니다.
@@ -797,7 +797,7 @@
### 30. Statistics Dashboard
**명령어:** `/gsd-stats`
**명령어:** `/msd-stats`
**목적:** 프로젝트 지표를 표시합니다 — 페이즈, 계획, 요구사항, git 히스토리, 타임라인.
@@ -811,29 +811,29 @@
### 31. Update System
**명령어:** `/gsd-update`
**명령어:** `/msd-update`
**목적:** 변경 로그 미리보기와 함께 GSD를 최신 버전으로 업데이트합니다.
**목적:** 변경 로그 미리보기와 함께 MSD를 최신 버전으로 업데이트합니다.
**요구사항.**
- REQ-UPDATE-01: npm을 통해 새 버전을 확인해야 합니다.
- REQ-UPDATE-02: 업데이트 전에 새 버전의 변경 로그를 표시해야 합니다.
- REQ-UPDATE-03: 런타임을 인식하고 올바른 디렉토리를 대상으로 해야 합니다.
- REQ-UPDATE-04: 로컬에서 수정된 파일을 `gsd-local-patches/`에 백업해야 합니다.
- REQ-UPDATE-05: `/gsd-update --reapply`는 업데이트 후 로컬 수정사항을 복원해야 합니다.
- REQ-UPDATE-04: 로컬에서 수정된 파일을 `msd-local-patches/`에 백업해야 합니다.
- REQ-UPDATE-05: `/msd-update --reapply`는 업데이트 후 로컬 수정사항을 복원해야 합니다.
---
### 32. Settings Management
**명령어:** `/gsd-settings`
**명령어:** `/msd-settings`
**목적:** 워크플로우 토글과 모델 프로파일의 대화형 구성.
**요구사항.**
- REQ-SETTINGS-01: 토글 옵션과 함께 현재 설정을 표시해야 합니다.
- REQ-SETTINGS-02: `.planning/config.json`을 업데이트해야 합니다.
- REQ-SETTINGS-03: 전역 기본값으로 저장하는 것을 지원해야 합니다(`~/.gsd/defaults.json`).
- REQ-SETTINGS-03: 전역 기본값으로 저장하는 것을 지원해야 합니다(`~/.msd/defaults.json`).
**구성 가능한 설정.**
| 설정 | 유형 | 기본값 | 설명 |
@@ -859,7 +859,7 @@
### 33. Test Generation
**명령어:** `/gsd-add-tests [N]`
**명령어:** `/msd-add-tests [N]`
**목적:** UAT 기준과 구현을 기반으로 완료된 페이즈에 대한 테스트를 생성합니다.
@@ -915,14 +915,14 @@ fix(03-01): correct auth token expiry
### 36. Multi-Runtime Support
**목적:** 여러 AI 코딩 에이전트 런타임에서 GSD를 실행합니다.
**목적:** 여러 AI 코딩 에이전트 런타임에서 MSD를 실행합니다.
**요구사항.**
- REQ-RUNTIME-01: Claude Code, OpenCode, Kilo, Codex, Copilot, Antigravity를 지원해야 합니다.
- REQ-RUNTIME-02: 설치 프로그램은 런타임별로 콘텐츠를 변환해야 합니다(도구 이름, 경로, 프론트매터).
- REQ-RUNTIME-03: 설치 프로그램은 대화형 및 비대화형(`--claude --global`) 모드를 모두 지원해야 합니다.
- REQ-RUNTIME-04: 설치 프로그램은 전역 및 로컬 설치를 모두 지원해야 합니다.
- REQ-RUNTIME-05: 제거는 다른 구성에 영향을 주지 않고 모든 GSD 파일을 깔끔하게 제거해야 합니다.
- REQ-RUNTIME-05: 제거는 다른 구성에 영향을 주지 않고 모든 MSD 파일을 깔끔하게 제거해야 합니다.
- REQ-RUNTIME-06: 설치 프로그램은 플랫폼 차이를 처리해야 합니다(Windows, macOS, Linux, WSL, Docker).
**런타임 변환.**
@@ -951,14 +951,14 @@ fix(03-01): correct auth token expiry
**상태표시줄 표시.**
```
[⬆ /gsd-update │] model │ [current task │] directory [█████░░░░░ 50%]
[⬆ /msd-update │] model │ [current task │] directory [█████░░░░░ 50%]
```
색상 코드: <50% 초록, <65% 노랑, <80% 주황, ≥80% 해골 이모지와 함께 빨강
### 38. Developer Profiling
**명령어:** `/gsd-profile-user [--questionnaire] [--refresh]`
**명령어:** `/msd-profile-user [--questionnaire] [--refresh]`
**목적:** Claude Code 세션 히스토리를 분석하여 8가지 차원에서 행동 프로파일을 구축하고, 개발자의 스타일에 맞게 Claude 응답을 개인화하는 산출물을 생성합니다.
@@ -983,7 +983,7 @@ fix(03-01): correct auth token expiry
**파이프라인 모듈.**
- `profile-pipeline.cjs` — 세션 스캐닝, 메시지 추출, 샘플링
- `profile-output.cjs` — 프로파일 렌더링, 설문지, 산출물 생성
- `gsd-user-profiler` 에이전트 — 세션 데이터에서 행동 분석
- `msd-user-profiler` 에이전트 — 세션 데이터에서 행동 분석
**요구사항.**
- REQ-PROF-01: 세션 분석은 최소 8가지 행동 차원을 다루어야 합니다.
@@ -1015,14 +1015,14 @@ fix(03-01): correct auth token expiry
### 40. Verification Debt Tracking
**명령어:** `/gsd-audit-uat`
**명령어:** `/msd-audit-uat`
**목적:** 프로젝트가 미결 테스트가 있는 페이즈를 넘어 진행할 때 UAT/검증 항목이 자동으로 누락되는 것을 방지합니다. 모든 이전 페이즈에 걸쳐 검증 부채를 표시하여 항목이 잊히지 않도록 합니다.
**구성 요소.**
**1. 교차 페이즈 상태 확인** (progress.md 1.6단계)
모든 `/gsd-progress` 호출은 현재 마일스톤의 모든 페이즈에서 미결 항목(pending, skipped, blocked, human_needed)을 스캔합니다. 실행 가능한 링크가 포함된 비차단 경고 섹션을 표시합니다.
모든 `/msd-progress` 호출은 현재 마일스톤의 모든 페이즈에서 미결 항목(pending, skipped, blocked, human_needed)을 스캔합니다. 실행 가능한 링크가 포함된 비차단 경고 섹션을 표시합니다.
**2. `status: partial`** (verify-work.md, UAT.md)
"세션 종료"와 "모든 테스트 해결" 사이를 구분하는 새 UAT 상태입니다. 테스트가 여전히 pending, blocked, 또는 이유 없이 skipped된 경우 `status: complete`를 방지합니다.
@@ -1037,12 +1037,12 @@ fix(03-01): correct auth token expiry
`phase complete` CLI는 JSON 출력에 검증 부채 경고를 반환합니다. 전환 워크플로우는 확인 전에 미결 항목을 표시합니다.
**요구사항.**
- REQ-DEBT-01: `/gsd-progress`에서 모든 이전 페이즈의 미결 UAT/검증 항목을 표시해야 합니다.
- REQ-DEBT-01: `/msd-progress`에서 모든 이전 페이즈의 미결 UAT/검증 항목을 표시해야 합니다.
- REQ-DEBT-02: 불완전한 테스트(partial)와 완료된 테스트(complete)를 구분해야 합니다.
- REQ-DEBT-03: 차단된 테스트를 `blocked_by` 태그로 분류해야 합니다.
- REQ-DEBT-04: human_needed 검증 항목을 추적 가능한 UAT 파일로 저장해야 합니다.
- REQ-DEBT-05: 검증 부채가 있을 때 페이즈 완료와 전환 중에 경고해야 합니다(비차단).
- REQ-DEBT-06: `/gsd-audit-uat`는 모든 페이즈를 스캔하고 테스트 가능성별로 항목을 분류하며 사람 테스트 계획을 생성해야 합니다.
- REQ-DEBT-06: `/msd-audit-uat`는 모든 페이즈를 스캔하고 테스트 가능성별로 항목을 분류하며 사람 테스트 계획을 생성해야 합니다.
---
@@ -1050,7 +1050,7 @@ fix(03-01): correct auth token expiry
### 41. Fast Mode
**명령어:** `/gsd-fast [task description]`
**명령어:** `/msd-fast [task description]`
**목적:** 하위 에이전트를 생성하거나 PLAN.md 파일을 생성하지 않고 인라인으로 간단한 작업을 실행합니다. 계획 오버헤드를 정당화하기에는 너무 작은 작업에 사용합니다: 오타 수정, 구성 변경, 작은 리팩터링, 잊혀진 커밋, 간단한 추가.
@@ -1060,15 +1060,15 @@ fix(03-01): correct auth token expiry
- REQ-FAST-03: 상태 일관성을 위해 `.planning/quick/`에 작업을 추적해야 합니다.
- REQ-FAST-04: 연구, 다단계 계획, 또는 검증이 필요한 작업에는 사용해서는 안 됩니다.
**`/gsd-quick`과 비교하여 사용 시점.**
- `/gsd-fast` — 2분 이내에 실행 가능한 한 문장 작업(오타, 구성 변경, 작은 추가)
- `/gsd-quick` — 연구, 다단계 계획, 또는 검증이 필요한 모든 것
**`/msd-quick`과 비교하여 사용 시점.**
- `/msd-fast` — 2분 이내에 실행 가능한 한 문장 작업(오타, 구성 변경, 작은 추가)
- `/msd-quick` — 연구, 다단계 계획, 또는 검증이 필요한 모든 것
---
### 42. Cross-AI Peer Review
**명령어:** `/gsd-review --phase N [--claude] [--codex] [--coderabbit] [--opencode] [--qwen] [--cursor] [--agy] [--antigravity] [--ollama] [--lm-studio] [--llama-cpp] [--kimi-code] [--all]`
**명령어:** `/msd-review --phase N [--claude] [--codex] [--coderabbit] [--opencode] [--qwen] [--cursor] [--agy] [--antigravity] [--ollama] [--lm-studio] [--llama-cpp] [--kimi-code] [--all]`
**목적:** 외부 AI CLI(Claude, Codex, CodeRabbit, OpenCode, Qwen Code, Cursor, Antigravity, Kimi Code)와 로컬 OpenAI 호환 서버(Ollama, LM Studio, llama.cpp)를 호출하여 페이즈 계획을 독립적으로 검토합니다. 검토자별 피드백이 담긴 구조화된 REVIEWS.md를 생성합니다.
@@ -1077,7 +1077,7 @@ fix(03-01): correct auth token expiry
- REQ-REVIEW-02: 페이즈 계획에서 구조화된 검토 프롬프트를 작성해야 합니다.
- REQ-REVIEW-03: 선택된 각 CLI를 독립적으로 호출해야 합니다.
- REQ-REVIEW-04: 응답을 수집하고 `REVIEWS.md`를 생성해야 합니다.
- REQ-REVIEW-05: 검토는 `/gsd-plan-phase --reviews`가 사용할 수 있어야 합니다.
- REQ-REVIEW-05: 검토는 `/msd-plan-phase --reviews`가 사용할 수 있어야 합니다.
**생성 산출물.** `{phase}-REVIEWS.md` — 검토자별 구조화된 피드백
@@ -1085,17 +1085,17 @@ fix(03-01): correct auth token expiry
### 43. Backlog Parking Lot
**명령어:** `/gsd-capture --backlog <description>`, `/gsd-review-backlog`, `/gsd-capture --seed <idea>`
**명령어:** `/msd-capture --backlog <description>`, `/msd-review-backlog`, `/msd-capture --seed <idea>`
**목적:** 아직 적극적인 계획에 준비되지 않은 아이디어를 캡처합니다. 백로그 항목은 활성 페이즈 순서 밖에 있기 위해 999.x 번호를 사용합니다. 시드는 올바른 마일스톤에서 자동으로 표시되는 트리거 조건이 있는 미래 지향적 아이디어입니다.
**요구사항.**
- REQ-BACKLOG-01: 백로그 항목은 활성 페이즈 순서 밖에 있기 위해 999.x 번호를 사용해야 합니다.
- REQ-BACKLOG-02: `/gsd-discuss-phase`와 `/gsd-plan-phase`가 작동할 수 있도록 페이즈 디렉토리를 즉시 생성해야 합니다.
- REQ-BACKLOG-03: `/gsd-review-backlog`는 항목별로 승격, 유지, 제거 액션을 지원해야 합니다.
- REQ-BACKLOG-02: `/msd-discuss-phase`와 `/msd-plan-phase`가 작동할 수 있도록 페이즈 디렉토리를 즉시 생성해야 합니다.
- REQ-BACKLOG-03: `/msd-review-backlog`는 항목별로 승격, 유지, 제거 액션을 지원해야 합니다.
- REQ-BACKLOG-04: 승격된 항목은 활성 마일스톤 순서로 번호가 다시 매겨져야 합니다.
- REQ-SEED-01: 시드는 표시 조건에 대한 전체 이유와 시기를 캡처해야 합니다.
- REQ-SEED-02: `/gsd-new-milestone`은 시드를 스캔하고 일치하는 항목을 표시해야 합니다.
- REQ-SEED-02: `/msd-new-milestone`은 시드를 스캔하고 일치하는 항목을 표시해야 합니다.
**생성 산출물.**
| 산출물 | 설명 |
@@ -1107,9 +1107,9 @@ fix(03-01): correct auth token expiry
### 44. Persistent Context Threads
**명령어:** `/gsd-thread [name | description]`
**명령어:** `/msd-thread [name | description]`
**목적:** 여러 세션에 걸쳐 있지만 특정 페이즈에 속하지 않는 작업을 위한 가벼운 교차 세션 지식 저장소입니다. `/gsd-pause-work`보다 더 가볍습니다 — 페이즈 상태나 계획 컨텍스트가 없습니다.
**목적:** 여러 세션에 걸쳐 있지만 특정 페이즈에 속하지 않는 작업을 위한 가벼운 교차 세션 지식 저장소입니다. `/msd-pause-work`보다 더 가볍습니다 — 페이즈 상태나 계획 컨텍스트가 없습니다.
**요구사항.**
- REQ-THREAD-01: 생성, 나열, 재개 모드를 지원해야 합니다.
@@ -1124,9 +1124,9 @@ fix(03-01): correct auth token expiry
### 45. PR Branch Filtering
**명령어:** `/gsd-pr-branch [target branch]`
**명령어:** `/msd-pr-branch [target branch]`
**목적:** `.planning/` 커밋을 필터링하여 풀 리퀘스트에 적합한 깔끔한 브랜치를 생성합니다. 검토자는 GSD 계획 산출물이 아닌 코드 변경사항만 봅니다.
**목적:** `.planning/` 커밋을 필터링하여 풀 리퀘스트에 적합한 깔끔한 브랜치를 생성합니다. 검토자는 MSD 계획 산출물이 아닌 코드 변경사항만 봅니다.
**요구사항.**
- REQ-PRBRANCH-01: `.planning/` 파일만 수정하는 커밋을 식별해야 합니다.
@@ -1137,7 +1137,7 @@ fix(03-01): correct auth token expiry
### 46. Security Hardening
**목적:** GSD 계획 산출물에 대한 심층 방어 보안. GSD가 LLM 시스템 프롬프트가 되는 마크다운 파일을 생성하기 때문에, 이 파일로 흘러드는 사용자 제어 텍스트는 잠재적인 간접 프롬프트 주입 벡터입니다.
**목적:** MSD 계획 산출물에 대한 심층 방어 보안. MSD가 LLM 시스템 프롬프트가 되는 마크다운 파일을 생성하기 때문에, 이 파일로 흘러드는 사용자 제어 텍스트는 잠재적인 간접 프롬프트 주입 벡터입니다.
**구성 요소.**
@@ -1148,11 +1148,11 @@ fix(03-01): correct auth token expiry
- 필드 이름 검증 — 구성 필드 이름을 통한 주입을 방지합니다.
- 셸 인수 검증 — 셸 보간 전에 사용자 텍스트를 살균합니다.
**2. 프롬프트 주입 가드 훅** (`gsd-prompt-guard.js`)
**2. 프롬프트 주입 가드 훅** (`msd-prompt-guard.js`)
`.planning/`을 대상으로 하는 Write/Edit 호출에서 주입 패턴을 스캔하는 PreToolUse 훅입니다. 정당한 작업을 차단하지 않고 인식을 위해 감지를 기록하는 권고 전용입니다.
**3. 워크플로우 가드 훅** (`gsd-workflow-guard.js`)
Claude가 GSD 워크플로우 컨텍스트 밖에서 파일 편집을 시도하는 것을 감지하는 PreToolUse 훅입니다. 직접 편집 대신 `/gsd-quick` 또는 `/gsd-fast` 사용을 권고합니다. `hooks.workflow_guard`로 구성 가능합니다(기본값: false).
**3. 워크플로우 가드 훅** (`msd-workflow-guard.js`)
Claude가 MSD 워크플로우 컨텍스트 밖에서 파일 편집을 시도하는 것을 감지하는 PreToolUse 훅입니다. 직접 편집 대신 `/msd-quick` 또는 `/msd-fast` 사용을 권고합니다. `hooks.workflow_guard`로 구성 가능합니다(기본값: false).
**4. CI 준비 주입 스캐너** (`prompt-injection-scan.security.test.cjs`)
모든 에이전트, 워크플로우, 명령어 파일에서 포함된 주입 벡터를 스캔하는 테스트 스위트입니다.
@@ -1179,7 +1179,7 @@ Claude가 GSD 워크플로우 컨텍스트 밖에서 파일 편집을 시도하
### 48. Discussion Audit Trail
**목적:** `/gsd-discuss-phase` 중에 `DISCUSSION-LOG.md`를 자동 생성하여 논의 중에 내려진 결정의 전체 감사 추적을 제공합니다.
**목적:** `/msd-discuss-phase` 중에 `DISCUSSION-LOG.md`를 자동 생성하여 논의 중에 내려진 결정의 전체 감사 추적을 제공합니다.
**요구사항.**
- REQ-DISCLOG-01: discuss-phase 중에 DISCUSSION-LOG.md를 자동 생성해야 합니다.
@@ -1192,9 +1192,9 @@ Claude가 GSD 워크플로우 컨텍스트 밖에서 파일 편집을 시도하
### 49. Forensics
**명령어:** `/gsd-forensics [description]`
**명령어:** `/msd-forensics [description]`
**목적:** 실패하거나 막힌 GSD 워크플로우의 사후 조사.
**목적:** 실패하거나 막힌 MSD 워크플로우의 사후 조사.
**요구사항.**
- REQ-FORENSICS-01: git 히스토리에서 이상(막힌 루프, 긴 간격, 반복된 커밋)을 분석해야 합니다.
@@ -1218,7 +1218,7 @@ Claude가 GSD 워크플로우 컨텍스트 밖에서 파일 편집을 시도하
### 50. Milestone Summary
**명령어:** `/gsd-milestone-summary [version]`
**명령어:** `/msd-milestone-summary [version]`
**목적:** 팀 온보딩을 위해 마일스톤 산출물에서 포괄적인 프로젝트 요약을 생성합니다.
@@ -1241,7 +1241,7 @@ Claude가 GSD 워크플로우 컨텍스트 밖에서 파일 편집을 시도하
### 51. Workstream Namespacing
**명령어:** `/gsd-workstreams`
**명령어:** `/msd-workstreams`
**목적:** 마일스톤의 다른 영역에서 동시 작업을 위한 병렬 워크스트림.
@@ -1257,14 +1257,14 @@ Claude가 GSD 워크플로우 컨텍스트 밖에서 파일 편집을 시도하
**프로세스.**
1. **생성** — 격리된 `.planning/workstreams/{name}/` 디렉토리로 명명된 워크스트림 초기화
2. **전환** — 이후 GSD 명령어를 위한 활성 워크스트림 컨텍스트 변경
2. **전환** — 이후 MSD 명령어를 위한 활성 워크스트림 컨텍스트 변경
3. **관리** — 워크스트림 나열, 상태 확인, 진행 상황 추적, 완료, 재개
---
### 52. Manager Dashboard
**명령어:** `/gsd-manager`
**명령어:** `/msd-manager`
**목적:** 하나의 터미널에서 여러 페이즈를 관리하는 대화형 명령 센터.
@@ -1284,7 +1284,7 @@ Claude가 GSD 워크플로우 컨텍스트 밖에서 파일 편집을 시도하
### 53. Assumptions Discussion Mode
**명령어:** `/gsd-discuss-phase` with `workflow.discuss_mode: 'assumptions'`
**명령어:** `/msd-discuss-phase` with `workflow.discuss_mode: 'assumptions'`
**목적:** 인터뷰 스타일 질문을 코드베이스 우선 가정 분석으로 대체합니다.
@@ -1310,26 +1310,26 @@ Claude가 GSD 워크플로우 컨텍스트 밖에서 파일 편집을 시도하
### 54. UI Phase Auto-Detection
**일부:** `/gsd-new-project` 및 `/gsd-progress`
**일부:** `/msd-new-project` 및 `/msd-progress`
**목적:** UI 중심 프로젝트를 자동으로 감지하고 `/gsd-ui-phase` 권장사항을 표시합니다.
**목적:** UI 중심 프로젝트를 자동으로 감지하고 `/msd-ui-phase` 권장사항을 표시합니다.
**요구사항.**
- REQ-UI-DETECT-01: 프로젝트 설명에서 UI 신호를 감지해야 합니다(키워드, 프레임워크 참조).
- REQ-UI-DETECT-02: 해당하는 경우 ROADMAP.md 페이즈에 `ui_hint`를 주석으로 추가해야 합니다.
- REQ-UI-DETECT-03: UI 중심 페이즈의 다음 단계에서 `/gsd-ui-phase`를 제안해야 합니다.
- REQ-UI-DETECT-04: `/gsd-ui-phase`를 필수로 만들어서는 안 됩니다.
- REQ-UI-DETECT-03: UI 중심 페이즈의 다음 단계에서 `/msd-ui-phase`를 제안해야 합니다.
- REQ-UI-DETECT-04: `/msd-ui-phase`를 필수로 만들어서는 안 됩니다.
**프로세스.**
1. **감지** — UI 신호(키워드, 프레임워크 참조)에 대한 프로젝트 설명 및 기술 스택 스캔
2. **주석** — ROADMAP.md의 해당 페이즈에 `ui_hint` 표시 추가
3. **표시** — UI 중심 페이즈의 다음 단계에 `/gsd-ui-phase` 권장사항 포함
3. **표시** — UI 중심 페이즈의 다음 단계에 `/msd-ui-phase` 권장사항 포함
---
### 55. Multi-Runtime Installer Selection
**일부:** `npx @opengsd/gsd-core`
**일부:** `npx @golem15/msd-core`
**목적:** 단일 대화형 설치 세션에서 여러 런타임을 선택합니다.
@@ -1340,7 +1340,7 @@ Claude가 GSD 워크플로우 컨텍스트 밖에서 파일 편집을 시도하
**프로세스.**
1. **감지** — 시스템에서 사용 가능한 AI CLI 런타임 식별
2. **프롬프트** — 런타임 선택을 위한 다중 선택 인터페이스 표시
3. **설치** — 단일 세션에서 선택된 모든 런타임에 GSD 구성
3. **설치** — 단일 세션에서 선택된 모든 런타임에 MSD 구성
---
@@ -1348,7 +1348,7 @@ Claude가 GSD 워크플로우 컨텍스트 밖에서 파일 편집을 시도하
### 56. Windsurf 런타임 지원
**대상:** `npx @opengsd/gsd-core`
**대상:** `npx @golem15/msd-core`
**목적:** Windsurf AI IDE 지원을 추가합니다.
@@ -1358,8 +1358,8 @@ Claude가 GSD 워크플로우 컨텍스트 밖에서 파일 편집을 시도하
**프로세스.**
1. **감지** — Windsurf 설치 상태 확인
2. **변환** — GSD 프롬프트를 Windsurf 규칙 형식으로 변환
3. **설치** — Windsurf 구성 디렉토리에 GSD 설정
2. **변환** — MSD 프롬프트를 Windsurf 규칙 형식으로 변환
3. **설치** — Windsurf 구성 디렉토리에 MSD 설정
---
@@ -1367,7 +1367,7 @@ Claude가 GSD 워크플로우 컨텍스트 밖에서 파일 편집을 시도하
**대상:** `docs/` 디렉토리
**목적:** GSD 문서를 포르투갈어, 한국어, 일본어로 제공합니다.
**목적:** MSD 문서를 포르투갈어, 한국어, 일본어로 제공합니다.
**요구사항.**
- REQ-I18N-01: 문서는 포르투갈어(pt), 한국어(ko), 일본어(ja)로 제공되어야 합니다.
@@ -1383,7 +1383,7 @@ Claude가 GSD 워크플로우 컨텍스트 밖에서 파일 편집을 시도하
### 59. 스키마 드리프트 감지
**명령어:** `/gsd-execute-phase` 실행 시 자동
**명령어:** `/msd-execute-phase` 실행 시 자동
**목적:** ORM 스키마 파일이 대응하는 마이그레이션 또는 push 명령 없이 수정된 경우를 감지하여 오탐 검증을 방지합니다.
@@ -1391,7 +1391,7 @@ Claude가 GSD 워크플로우 컨텍스트 밖에서 파일 편집을 시도하
- REQ-SCHEMA-01: 시스템은 ORM 스키마 파일(Prisma, Drizzle, Payload, Sanity, Mongoose) 수정을 감지해야 합니다.
- REQ-SCHEMA-02: 스키마 변경이 감지되면 대응하는 마이그레이션/push 명령의 존재를 확인해야 합니다.
- REQ-SCHEMA-03: 이중 방어를 구현해야 합니다: 계획 시점 주입 및 실행 시점 게이트.
- REQ-SCHEMA-04: 감지를 재정의하는 `GSD_SKIP_SCHEMA_CHECK` 환경 변수를 지원해야 합니다.
- REQ-SCHEMA-04: 감지를 재정의하는 `MSD_SKIP_SCHEMA_CHECK` 환경 변수를 지원해야 합니다.
- REQ-SCHEMA-05: 마이그레이션 없는 스키마 변경 시 오탐 검증을 방지해야 합니다.
**프로세스.**
@@ -1400,13 +1400,13 @@ Claude가 GSD 워크플로우 컨텍스트 밖에서 파일 편집을 시도하
3. **게이트** — 마이그레이션 없는 스키마 드리프트가 감지되면 실행 차단(실행 시점 게이트)
4. **주입** — 계획 생성 중 마이그레이션 리마인더 추가(계획 시점 주입)
**구성:** `GSD_SKIP_SCHEMA_CHECK` 환경 변수로 감지 바이패스.
**구성:** `MSD_SKIP_SCHEMA_CHECK` 환경 변수로 감지 바이패스.
---
### 60. 보안 시행
**명령어:** `/gsd-secure-phase <N>`
**명령어:** `/msd-secure-phase <N>`
**목적:** 페이즈 구현에 대한 위협 모델 기반 보안 검증.
@@ -1414,7 +1414,7 @@ Claude가 GSD 워크플로우 컨텍스트 밖에서 파일 편집을 시도하
- REQ-SEC-01: 시스템은 위협 모델 기반 검증(블라인드 스캔이 아닌)을 수행해야 합니다.
- REQ-SEC-02: 구성 가능한 OWASP ASVS 검증 레벨(1-3)을 지원해야 합니다.
- REQ-SEC-03: 구성 가능한 심각도 임계값에 따라 페이즈 진행을 차단해야 합니다.
- REQ-SEC-04: 분석을 위해 `gsd-security-auditor` 에이전트를 스폰해야 합니다.
- REQ-SEC-04: 분석을 위해 `msd-security-auditor` 에이전트를 스폰해야 합니다.
**생성 산출물.**
| 산출물 | 설명 |
@@ -1423,7 +1423,7 @@ Claude가 GSD 워크플로우 컨텍스트 밖에서 파일 편집을 시도하
**프로세스.**
1. **모델** — 페이즈 구현 컨텍스트에서 위협 모델 구축
2. **감사** — `gsd-security-auditor`를 스폰하여 위협 모델에 대해 검증
2. **감사** — `msd-security-auditor`를 스폰하여 위협 모델에 대해 검증
3. **게이트** — 발견 사항이 `security_block_on` 심각도 이상이면 페이즈 진행 차단
**구성:**
@@ -1437,13 +1437,13 @@ Claude가 GSD 워크플로우 컨텍스트 밖에서 파일 편집을 시도하
### 61. 문서 생성
**명령어:** `/gsd-docs-update`
**명령어:** `/msd-docs-update`
**목적:** 정확성 검사가 포함된 프로젝트 문서를 생성하고 검증합니다.
**요구사항.**
- REQ-DOCS-01: 시스템은 문서 생성을 위해 `gsd-doc-writer` 에이전트를 스폰해야 합니다.
- REQ-DOCS-02: 시스템은 정확성 검사를 위해 `gsd-doc-verifier` 에이전트를 스폰해야 합니다.
- REQ-DOCS-01: 시스템은 문서 생성을 위해 `msd-doc-writer` 에이전트를 스폰해야 합니다.
- REQ-DOCS-02: 시스템은 정확성 검사를 위해 `msd-doc-verifier` 에이전트를 스폰해야 합니다.
- REQ-DOCS-03: 시스템은 생성된 문서를 실제 구현에 대해 검증해야 합니다.
**생성 산출물.**
@@ -1452,15 +1452,15 @@ Claude가 GSD 워크플로우 컨텍스트 밖에서 파일 편집을 시도하
| 업데이트된 프로젝트 문서 | 생성 및 검증된 문서 파일 |
**프로세스.**
1. **생성** — `gsd-doc-writer`를 스폰하여 구현에서 문서 생성 또는 업데이트
2. **검증** — `gsd-doc-verifier`를 스폰하여 코드베이스에 대한 문서 정확성 검사
1. **생성** — `msd-doc-writer`를 스폰하여 구현에서 문서 생성 또는 업데이트
2. **검증** — `msd-doc-verifier`를 스폰하여 코드베이스에 대한 문서 정확성 검사
3. **출력** — 정확성 주석이 포함된 검증된 문서 생성
---
### 62. 디스커스 체인 모드
**플래그:** `/gsd-discuss-phase <N> --chain`
**플래그:** `/msd-discuss-phase <N> --chain`
**목적:** 수동 명령어 연속 실행을 줄이기 위해 discuss, plan, execute 페이즈를 하나의 플로우로 자동 체인합니다.
@@ -1478,7 +1478,7 @@ Claude가 GSD 워크플로우 컨텍스트 밖에서 파일 편집을 시도하
### 63. 단일 페이즈 자율 모드
**플래그:** `/gsd-autonomous --only N`
**플래그:** `/msd-autonomous --only N`
**목적:** 모든 남은 페이즈가 아닌 하나의 페이즈만 자율적으로 실행합니다.
@@ -1496,7 +1496,7 @@ Claude가 GSD 워크플로우 컨텍스트 밖에서 파일 편집을 시도하
### 64. 범위 축소 감지
**대상:** `/gsd-plan-phase`
**대상:** `/msd-plan-phase`
**목적:** 삼중 방어로 계획 생성 중 요구사항의 무단 삭제를 방지합니다.
@@ -1515,7 +1515,7 @@ Claude가 GSD 워크플로우 컨텍스트 밖에서 파일 편집을 시도하
### 65. 주장 출처 태깅
**대상:** `/gsd-plan-phase --research-phase`
**대상:** `/msd-plan-phase --research-phase`
**목적:** 연구 주장에 출처 증거를 태깅하고 가정을 별도로 기록합니다.
@@ -1569,20 +1569,20 @@ Claude가 GSD 워크플로우 컨텍스트 밖에서 파일 편집을 시도하
### 68. Claude Code 스킬 마이그레이션
**대상:** `npx @opengsd/gsd-core`
**대상:** `npx @golem15/msd-core`
**목적:** GSD 명령어를 하위 호환성을 유지하면서 Claude Code 2.1.88+ 스킬 형식으로 마이그레이션합니다.
**목적:** MSD 명령어를 하위 호환성을 유지하면서 Claude Code 2.1.88+ 스킬 형식으로 마이그레이션합니다.
**요구사항.**
- REQ-SKILLS-01: 설치 프로그램은 Claude Code 2.1.88+ 용 `skills/gsd-*/SKILL.md`를 작성해야 합니다.
- REQ-SKILLS-02: 설치 프로그램은 레거시 `commands/gsd/` 디렉토리를 자동 정리해야 합니다.
- REQ-SKILLS-03: 레거시 `commands/gsd/` 경로를 통해 이전 Claude Code 버전과의 하위 호환성을 유지해야 합니다.
- REQ-SKILLS-01: 설치 프로그램은 Claude Code 2.1.88+ 용 `skills/msd-*/SKILL.md`를 작성해야 합니다.
- REQ-SKILLS-02: 설치 프로그램은 레거시 `commands/msd/` 디렉토리를 자동 정리해야 합니다.
- REQ-SKILLS-03: 레거시 `commands/msd/` 경로를 통해 이전 Claude Code 버전과의 하위 호환성을 유지해야 합니다.
**프로세스.**
1. **감지** — Claude Code 버전을 확인하여 스킬 지원 여부 판단
2. **마이그레이션** — 각 GSD 명령어에 대해 `skills/gsd-*/SKILL.md` 파일 작성
3. **정리** — 스킬이 설치되면 레거시 `commands/gsd/` 디렉토리 제거
4. **폴백** — 이전 Claude Code 버전을 위한 레거시 `commands/gsd/` 경로 호환성 유지
2. **마이그레이션** — 각 MSD 명령어에 대해 `skills/msd-*/SKILL.md` 파일 작성
3. **정리** — 스킬이 설치되면 레거시 `commands/msd/` 디렉토리 제거
4. **폴백** — 이전 Claude Code 버전을 위한 레거시 `commands/msd/` 경로 호환성 유지
---
@@ -1614,7 +1614,7 @@ Claude가 GSD 워크플로우 컨텍스트 밖에서 파일 편집을 시도하
### 70. 자율 모드 `--to N` 플래그
**플래그:** `/gsd-autonomous --to N`
**플래그:** `/msd-autonomous --to N`
**목적:** 특정 페이즈 완료 후 자율 실행을 중단하여 부분적 자율 실행을 가능하게 합니다.
@@ -1632,7 +1632,7 @@ Claude가 GSD 워크플로우 컨텍스트 밖에서 파일 편집을 시도하
### 71. 리서치 게이트
**대상:** `/gsd-plan-phase`
**대상:** `/msd-plan-phase`
**목적:** RESEARCH.md에 미해결 오픈 질문이 있을 때 계획을 차단하여 불완전한 정보에 기반한 계획을 방지합니다.
@@ -1650,7 +1650,7 @@ Claude가 GSD 워크플로우 컨텍스트 밖에서 파일 편집을 시도하
### 72. 검증자 마일스톤 범위 필터링
**대상:** `/gsd-execute-phase` (검증자 단계)
**대상:** `/msd-execute-phase` (검증자 단계)
**목적:** 진정한 갭과 후속 페이즈로 연기된 항목을 구분하여 검증의 오탐을 줄입니다.
@@ -1699,7 +1699,7 @@ Claude가 GSD 워크플로우 컨텍스트 밖에서 파일 편집을 시도하
### 75. 디스커스 페이즈 `--power` 플래그
**플래그:** `/gsd-discuss-phase --power`
**플래그:** `/msd-discuss-phase --power`
**목적:** 디스커스 페이즈의 파일 기반 대량 질문 답변으로, 준비된 답변 파일에서 일괄 입력을 가능하게 합니다.
@@ -1712,7 +1712,7 @@ Claude가 GSD 워크플로우 컨텍스트 밖에서 파일 편집을 시도하
### 76. 디버그 `--diagnose` 플래그
**플래그:** `/gsd-debug --diagnose`
**플래그:** `/msd-debug --diagnose`
**목적:** 수정을 시도하지 않고 조사만 수행하는 진단 전용 모드.
@@ -1725,9 +1725,9 @@ Claude가 GSD 워크플로우 컨텍스트 밖에서 파일 편집을 시도하
### 77. 페이즈 의존성 분석
**명령어:** `/gsd-manager --analyze-deps`
**명령어:** `/msd-manager --analyze-deps`
**목적:** 페이즈 의존성을 감지하고 `/gsd-manager` 실행 전 ROADMAP.md에 `Depends on` 항목을 제안합니다.
**목적:** 페이즈 의존성을 감지하고 `/msd-manager` 실행 전 ROADMAP.md에 `Depends on` 항목을 제안합니다.
**요구사항.**
- REQ-DEP-01: 시스템은 페이즈 간 파일 겹침을 감지해야 합니다.
@@ -1741,7 +1741,7 @@ Claude가 GSD 워크플로우 컨텍스트 밖에서 파일 편집을 시도하
### 78. 안티패턴 심각도 레벨
**대상:** `/gsd-resume-work`
**대상:** `/msd-resume-work`
**목적:** 심각도 기반 안티패턴 강제를 통한 재개 시 필수 이해 검사.
@@ -1766,7 +1766,7 @@ Claude가 GSD 워크플로우 컨텍스트 밖에서 파일 편집을 시도하
### 80. 플래너 도달 가능성 검사
**대상:** `/gsd-plan-phase`
**대상:** `/msd-plan-phase`
**목적:** 실행에 커밋하기 전에 계획 단계가 달성 가능한지 검증합니다.
@@ -1778,7 +1778,7 @@ Claude가 GSD 워크플로우 컨텍스트 밖에서 파일 편집을 시도하
### 81. Playwright-MCP UI 검증
**대상:** `/gsd-verify-work` (선택 사항)
**대상:** `/msd-verify-work` (선택 사항)
**목적:** 검증 페이즈 중 Playwright-MCP를 사용한 자동 시각적 검증.
@@ -1791,7 +1791,7 @@ Claude가 GSD 워크플로우 컨텍스트 밖에서 파일 편집을 시도하
### 82. Pause-Work 확장
**대상:** `/gsd-pause-work`
**대상:** `/msd-pause-work`
**목적:** 더 풍부한 핸드오프 데이터로 비페이즈 컨텍스트를 지원하여 pause-work의 적용 범위를 확대합니다.
@@ -1832,9 +1832,9 @@ Claude가 GSD 워크플로우 컨텍스트 밖에서 파일 편집을 시도하
### 85. 신규 런타임 지원 (Trae, Cline, Augment Code)
**대상:** `npx @opengsd/gsd-core`
**대상:** `npx @golem15/msd-core`
**목적:** Trae IDE, Cline, Augment Code 런타임으로 GSD 설치를 확장합니다.
**목적:** Trae IDE, Cline, Augment Code 런타임으로 MSD 설치를 확장합니다.
**요구사항.**
- REQ-TRAE-01: 설치 프로그램은 Trae IDE 설치를 위한 `--trae` 플래그를 지원해야 합니다.

494
docs/ko-KR/INVENTORY.md
View File

@@ -1,64 +1,64 @@
# GSD 출시된 표면 인벤토리
# MSD 출시된 표면 인벤토리
> 출시된 모든 GSD 표면의 공식 목록: 명령어, 에이전트, 워크플로우, 레퍼런스, CLI 모듈, 훅. 광범위 문서(AGENTS.md, COMMANDS.md, ARCHITECTURE.md, CLI-TOOLS.md)와 파일시스템이 다를 경우, 이 파일과 저장소 트리를 진실의 원천으로 취급합니다.
> 출시된 모든 MSD 표면의 공식 목록: 명령어, 에이전트, 워크플로우, 레퍼런스, CLI 모듈, 훅. 광범위 문서(AGENTS.md, COMMANDS.md, ARCHITECTURE.md, CLI-TOOLS.md)와 파일시스템이 다를 경우, 이 파일과 저장소 트리를 진실의 원천으로 취급합니다.
## 이 파일 사용 방법
- 여기의 수량은 v1.36.0 핀 기준 파일시스템에서 도출된 것으로, 릴리스 사이에 변동될 수 있습니다. 최신 수량을 확인하려면 체크아웃에서 `ls commands/gsd/*.md | wc -l`, `ls agents/gsd-*.md | wc -l` 등을 실행하세요.
- 여기의 수량은 v1.36.0 핀 기준 파일시스템에서 도출된 것으로, 릴리스 사이에 변동될 수 있습니다. 최신 수량을 확인하려면 체크아웃에서 `ls commands/msd/*.md | wc -l`, `ls agents/msd-*.md | wc -l` 등을 실행하세요.
- 이 파일은 6개 패밀리(에이전트, 명령어, 워크플로우, 레퍼런스, CLI 모듈, 훅) 전반에 걸쳐 출시된 모든 표면을 열거합니다. 광범위 문서는 내러티브 또는 엄선된 하위 집합을 렌더링할 수 있습니다. 파일시스템과 불일치할 경우 이 파일과 디렉터리 목록이 권위 있는 출처입니다.
- v1.36.0 이후 추가된 새 표면은 먼저 여기에 기록된 후 광범위 문서로 전파되어야 합니다. `tests/inventory-manifest-sync.test.cjs`의 드리프트 제어 테스트가 파일시스템 대비 로스터 내용을 고정합니다.
이것은 출시된 모든 GSD Core 표면의 공식 목록입니다. 주제별 탐색은 [문서 색인](README.md)을 참조하세요.
이것은 출시된 모든 MSD Core 표면의 공식 목록입니다. 주제별 탐색은 [문서 색인](README.md)을 참조하세요.
---
## 에이전트 (33개 출시)
전체 목록은 `agents/gsd-*.md`에 있습니다. "주요 문서" 열은 [`docs/AGENTS.md`](AGENTS.md)에서 전체 역할 카드(*primary*), "고급 및 특수 에이전트" 섹션의 짧은 스텁(*advanced stub*), 또는 다루지 않음(*inventory only*)을 표시합니다.
전체 목록은 `agents/msd-*.md`에 있습니다. "주요 문서" 열은 [`docs/AGENTS.md`](AGENTS.md)에서 전체 역할 카드(*primary*), "고급 및 특수 에이전트" 섹션의 짧은 스텁(*advanced stub*), 또는 다루지 않음(*inventory only*)을 표시합니다.
| 에이전트 | 역할 (한 줄) | 생성자 | 주요 문서 |
|-------|-----------------|------------|-------------|
| gsd-project-researcher | 로드맵 생성 전 도메인 에코시스템 조사 (스택, 기능, 아키텍처, 함정). | `/gsd-new-project`, `/gsd-new-milestone` | primary |
| gsd-phase-researcher | 계획 전 특정 단계의 구현 방식 조사. | `/gsd-plan-phase` | primary |
| gsd-ui-researcher | 프론트엔드 단계용 UI 설계 계약 생성. | `/gsd-ui-phase` | primary |
| gsd-assumptions-analyzer | discuss-phase (가정 모드)를 위한 근거 기반 가정 생성. | `discuss-phase-assumptions` 워크플로우 | primary |
| gsd-advisor-researcher | discuss-phase 어드바이저 모드에서 단일 회색 지대 결정을 조사. | `discuss-phase` 워크플로우 (어드바이저 모드) | primary |
| gsd-research-synthesizer | 병렬 조사 결과를 통합 SUMMARY.md로 결합. | `/gsd-new-project` | primary |
| gsd-planner | 태스크 분해 및 목표 역방향 검증이 포함된 실행 가능한 단계 계획 생성. | `/gsd-plan-phase`, `/gsd-quick` | primary |
| gsd-roadmapper | 단계 분해 및 요구사항 매핑이 포함된 프로젝트 로드맵 생성. | `/gsd-new-project` | primary |
| gsd-executor | 원자적 커밋과 편차 처리로 GSD 계획 실행. | `/gsd-execute-phase`, `/gsd-quick` | primary |
| gsd-plan-checker | 계획이 단계 목표를 달성할지 검증 (8개 검증 차원). | `/gsd-plan-phase` (검증 루프) | primary |
| gsd-integration-checker | 단계 간 통합 및 엔드투엔드 플로우 검증. | `/gsd-audit-milestone` | primary |
| gsd-ui-checker | 품질 차원에 대한 UI-SPEC.md 설계 계약 검증. | `/gsd-ui-phase` (검증 루프) | primary |
| gsd-verifier | 목표 역방향 분석을 통한 단계 목표 달성 검증. | `/gsd-execute-phase` | primary |
| gsd-nyquist-auditor | 테스트 생성으로 나이퀴스트 검증 공백 채움. | `/gsd-validate-phase` | primary |
| gsd-ui-auditor | 구현된 프론트엔드 코드의 소급 6-기둥 시각 감사. | `/gsd-ui-review` | primary |
| gsd-codebase-mapper | 코드베이스 탐색 및 구조화된 분석 문서 작성. | `/gsd-map-codebase` | primary |
| gsd-debugger | 영속 상태를 사용하는 과학적 방법론으로 버그 조사. | `/gsd-debug`, `/gsd-verify-work` | primary |
| gsd-user-profiler | 8개 차원에서 개발자 행동 점수 산정. | `/gsd-profile-user` | primary |
| gsd-doc-writer | 프로젝트 문서 작성 및 업데이트. | `/gsd-docs-update` | primary |
| gsd-doc-verifier | 생성된 문서의 사실적 주장 검증. | `/gsd-docs-update` | primary |
| gsd-security-auditor | PLAN.md 위협 모델의 위협 완화 검증. | `/gsd-secure-phase` | primary |
| gsd-pattern-mapper | 새 파일을 가장 가까운 기존 유사체에 매핑; 플래너를 위한 PATTERNS.md 작성. | `/gsd-plan-phase` (조사와 계획 사이) | advanced stub |
| gsd-debug-session-manager | 격리된 컨텍스트에서 전체 `/gsd-debug` 체크포인트-및-연속 루프를 실행하여 메인 컨텍스트를 가볍게 유지. | `/gsd-debug` | advanced stub |
| gsd-code-reviewer | 버그, 보안 문제, 코드 품질 문제에 대해 소스 파일 검토; REVIEW.md 생성. | `/gsd-code-review` | advanced stub |
| gsd-code-fixer | REVIEW.md 결과에 수정 사항을 원자적 수정별 커밋으로 적용; REVIEW-FIX.md 생성. | `/gsd-code-review --fix` | advanced stub |
| gsd-ai-researcher | 선택한 AI 프레임워크의 공식 문서를 구현 준비 가이드로 조사 (AI-SPEC.md §3–§4b). | `/gsd-ai-integration-phase` | advanced stub |
| gsd-domain-researcher | AI 시스템을 위한 도메인 전문가 평가 기준 및 실패 모드 표면화 (AI-SPEC.md §1b). | `/gsd-ai-integration-phase` | advanced stub |
| gsd-eval-planner | AI 단계를 위한 구조화된 평가 전략 설계 (AI-SPEC.md §5–§7). | `/gsd-ai-integration-phase` | advanced stub |
| gsd-eval-auditor | AI 단계 평가 범위의 소급 감사; EVAL-REVIEW.md 생성 (COVERED/PARTIAL/MISSING). | `/gsd-eval-review` | advanced stub |
| gsd-framework-selector | AI/LLM 프레임워크를 점수 산정하고 추천하는 ≤6개 질문의 인터랙티브 결정 매트릭스. | `/gsd-ai-integration-phase` | advanced stub |
| gsd-intel-updater | 쿼리 가능한 코드베이스 지식 베이스로 사용되는 구조화된 인텔 파일(`.planning/intel/*.json`) 작성. | `/gsd-map-codebase --query` | advanced stub |
| gsd-doc-classifier | 단일 계획 문서를 ADR, PRD, SPEC, DOC, UNKNOWN으로 분류; 병렬로 생성되어 문서 코퍼스 처리. | `/gsd-ingest-docs` | advanced stub |
| gsd-doc-synthesizer | 분류된 계획 문서를 우선순위 규칙, 순환 감지, 세 버킷 충돌 보고서로 단일 통합 컨텍스트로 합성. | `/gsd-ingest-docs` | advanced stub |
| msd-project-researcher | 로드맵 생성 전 도메인 에코시스템 조사 (스택, 기능, 아키텍처, 함정). | `/msd-new-project`, `/msd-new-milestone` | primary |
| msd-phase-researcher | 계획 전 특정 단계의 구현 방식 조사. | `/msd-plan-phase` | primary |
| msd-ui-researcher | 프론트엔드 단계용 UI 설계 계약 생성. | `/msd-ui-phase` | primary |
| msd-assumptions-analyzer | discuss-phase (가정 모드)를 위한 근거 기반 가정 생성. | `discuss-phase-assumptions` 워크플로우 | primary |
| msd-advisor-researcher | discuss-phase 어드바이저 모드에서 단일 회색 지대 결정을 조사. | `discuss-phase` 워크플로우 (어드바이저 모드) | primary |
| msd-research-synthesizer | 병렬 조사 결과를 통합 SUMMARY.md로 결합. | `/msd-new-project` | primary |
| msd-planner | 태스크 분해 및 목표 역방향 검증이 포함된 실행 가능한 단계 계획 생성. | `/msd-plan-phase`, `/msd-quick` | primary |
| msd-roadmapper | 단계 분해 및 요구사항 매핑이 포함된 프로젝트 로드맵 생성. | `/msd-new-project` | primary |
| msd-executor | 원자적 커밋과 편차 처리로 MSD 계획 실행. | `/msd-execute-phase`, `/msd-quick` | primary |
| msd-plan-checker | 계획이 단계 목표를 달성할지 검증 (8개 검증 차원). | `/msd-plan-phase` (검증 루프) | primary |
| msd-integration-checker | 단계 간 통합 및 엔드투엔드 플로우 검증. | `/msd-audit-milestone` | primary |
| msd-ui-checker | 품질 차원에 대한 UI-SPEC.md 설계 계약 검증. | `/msd-ui-phase` (검증 루프) | primary |
| msd-verifier | 목표 역방향 분석을 통한 단계 목표 달성 검증. | `/msd-execute-phase` | primary |
| msd-nyquist-auditor | 테스트 생성으로 나이퀴스트 검증 공백 채움. | `/msd-validate-phase` | primary |
| msd-ui-auditor | 구현된 프론트엔드 코드의 소급 6-기둥 시각 감사. | `/msd-ui-review` | primary |
| msd-codebase-mapper | 코드베이스 탐색 및 구조화된 분석 문서 작성. | `/msd-map-codebase` | primary |
| msd-debugger | 영속 상태를 사용하는 과학적 방법론으로 버그 조사. | `/msd-debug`, `/msd-verify-work` | primary |
| msd-user-profiler | 8개 차원에서 개발자 행동 점수 산정. | `/msd-profile-user` | primary |
| msd-doc-writer | 프로젝트 문서 작성 및 업데이트. | `/msd-docs-update` | primary |
| msd-doc-verifier | 생성된 문서의 사실적 주장 검증. | `/msd-docs-update` | primary |
| msd-security-auditor | PLAN.md 위협 모델의 위협 완화 검증. | `/msd-secure-phase` | primary |
| msd-pattern-mapper | 새 파일을 가장 가까운 기존 유사체에 매핑; 플래너를 위한 PATTERNS.md 작성. | `/msd-plan-phase` (조사와 계획 사이) | advanced stub |
| msd-debug-session-manager | 격리된 컨텍스트에서 전체 `/msd-debug` 체크포인트-및-연속 루프를 실행하여 메인 컨텍스트를 가볍게 유지. | `/msd-debug` | advanced stub |
| msd-code-reviewer | 버그, 보안 문제, 코드 품질 문제에 대해 소스 파일 검토; REVIEW.md 생성. | `/msd-code-review` | advanced stub |
| msd-code-fixer | REVIEW.md 결과에 수정 사항을 원자적 수정별 커밋으로 적용; REVIEW-FIX.md 생성. | `/msd-code-review --fix` | advanced stub |
| msd-ai-researcher | 선택한 AI 프레임워크의 공식 문서를 구현 준비 가이드로 조사 (AI-SPEC.md §3–§4b). | `/msd-ai-integration-phase` | advanced stub |
| msd-domain-researcher | AI 시스템을 위한 도메인 전문가 평가 기준 및 실패 모드 표면화 (AI-SPEC.md §1b). | `/msd-ai-integration-phase` | advanced stub |
| msd-eval-planner | AI 단계를 위한 구조화된 평가 전략 설계 (AI-SPEC.md §5–§7). | `/msd-ai-integration-phase` | advanced stub |
| msd-eval-auditor | AI 단계 평가 범위의 소급 감사; EVAL-REVIEW.md 생성 (COVERED/PARTIAL/MISSING). | `/msd-eval-review` | advanced stub |
| msd-framework-selector | AI/LLM 프레임워크를 점수 산정하고 추천하는 ≤6개 질문의 인터랙티브 결정 매트릭스. | `/msd-ai-integration-phase` | advanced stub |
| msd-intel-updater | 쿼리 가능한 코드베이스 지식 베이스로 사용되는 구조화된 인텔 파일(`.planning/intel/*.json`) 작성. | `/msd-map-codebase --query` | advanced stub |
| msd-doc-classifier | 단일 계획 문서를 ADR, PRD, SPEC, DOC, UNKNOWN으로 분류; 병렬로 생성되어 문서 코퍼스 처리. | `/msd-ingest-docs` | advanced stub |
| msd-doc-synthesizer | 분류된 계획 문서를 우선순위 규칙, 순환 감지, 세 버킷 충돌 보고서로 단일 통합 컨텍스트로 합성. | `/msd-ingest-docs` | advanced stub |
**커버리지 참고.** `docs/AGENTS.md`는 21개 주요 에이전트에 대한 전체 역할 카드와 12개 고급 에이전트에 대한 간결한 스텁을 제공합니다. 해당 파일의 에이전트 도구 권한 요약은 주요 21개 에이전트만 다루며; 고급 에이전트의 도구 목록은 `agents/gsd-*.md`의 에이전트별 프론트매터에 기록됩니다.
**커버리지 참고.** `docs/AGENTS.md`는 21개 주요 에이전트에 대한 전체 역할 카드와 12개 고급 에이전트에 대한 간결한 스텁을 제공합니다. 해당 파일의 에이전트 도구 권한 요약은 주요 21개 에이전트만 다루며; 고급 에이전트의 도구 목록은 `agents/msd-*.md`의 에이전트별 프론트매터에 기록됩니다.
---
## 명령어 (67개 출시)
전체 목록은 `commands/gsd/*.md`에 있습니다. 아래 그룹화는 `docs/COMMANDS.md` 섹션 순서를 반영합니다. 각 행은 명령어 이름, 명령어의 프론트매터 `description:`에서 도출된 한 줄 역할, 소스 파일 링크를 포함합니다. `tests/command-count-sync.test.cjs`가 파일시스템 대비 수량을 고정합니다.
전체 목록은 `commands/msd/*.md`에 있습니다. 아래 그룹화는 `docs/COMMANDS.md` 섹션 순서를 반영합니다. 각 행은 명령어 이름, 명령어의 프론트매터 `description:`에서 도출된 한 줄 역할, 소스 파일 링크를 포함합니다. `tests/command-count-sync.test.cjs`가 파일시스템 대비 수량을 고정합니다.
### 네임스페이스 메타 스킬
@@ -66,199 +66,199 @@
| 명령어 | 역할 | 소스 |
|---------|------|--------|
| `/gsd-workflow` | 단계 파이프라인 라우터 — discuss / plan / execute / verify / phase / progress. | [commands/gsd/ns-workflow.md](../../commands/gsd/ns-workflow.md) |
| `/gsd-project` | 프로젝트 라이프사이클 라우터 — 마일스톤, 감사, 요약. | [commands/gsd/ns-project.md](../../commands/gsd/ns-project.md) |
| `/gsd-quality` | 품질 게이트 라우터 — 코드 리뷰, 디버그, 감사, 보안, 평가, UI. | [commands/gsd/ns-review.md](../../commands/gsd/ns-review.md) |
| `/gsd-context` | 코드베이스 인텔리전스 라우터 — 맵, 그래프화, 문서, 학습. | [commands/gsd/ns-context.md](../../commands/gsd/ns-context.md) |
| `/gsd-manage` | 관리 라우터 — 설정, 워크스페이스, 워크스트림, 스레드, 업데이트, 출시, 인박스. | [commands/gsd/ns-manage.md](../../commands/gsd/ns-manage.md) |
| `/gsd-ideate` | 탐색 및 캡처 라우터 — 탐색, 스케치, 스파이크, 스펙, 캡처. | [commands/gsd/ns-ideate.md](../../commands/gsd/ns-ideate.md) |
| `/msd-workflow` | 단계 파이프라인 라우터 — discuss / plan / execute / verify / phase / progress. | [commands/msd/ns-workflow.md](../../commands/msd/ns-workflow.md) |
| `/msd-project` | 프로젝트 라이프사이클 라우터 — 마일스톤, 감사, 요약. | [commands/msd/ns-project.md](../../commands/msd/ns-project.md) |
| `/msd-quality` | 품질 게이트 라우터 — 코드 리뷰, 디버그, 감사, 보안, 평가, UI. | [commands/msd/ns-review.md](../../commands/msd/ns-review.md) |
| `/msd-context` | 코드베이스 인텔리전스 라우터 — 맵, 그래프화, 문서, 학습. | [commands/msd/ns-context.md](../../commands/msd/ns-context.md) |
| `/msd-manage` | 관리 라우터 — 설정, 워크스페이스, 워크스트림, 스레드, 업데이트, 출시, 인박스. | [commands/msd/ns-manage.md](../../commands/msd/ns-manage.md) |
| `/msd-ideate` | 탐색 및 캡처 라우터 — 탐색, 스케치, 스파이크, 스펙, 캡처. | [commands/msd/ns-ideate.md](../../commands/msd/ns-ideate.md) |
### 핵심 워크플로우
| 명령어 | 역할 | 소스 |
|---------|------|--------|
| `/gsd-new-project` | 심층 컨텍스트 수집 및 PROJECT.md로 새 프로젝트 초기화. | [commands/gsd/new-project.md](../../commands/gsd/new-project.md) |
| `/gsd-onboard` | 기존 코드베이스를 매핑, 문서 수집, 프로젝트 설정, onboarding summary로 안내합니다. | [commands/gsd/onboard.md](../../commands/gsd/onboard.md) |
| `/gsd-workspace` | GSD 워크스페이스 관리 — 격리된 워크스페이스 환경을 생성(`--new`), 목록(`--list`), 또는 제거(`--remove`). | [commands/gsd/workspace.md](../../commands/gsd/workspace.md) |
| `/gsd-discuss-phase` | 계획 전 적응형 질문을 통한 단계 컨텍스트 수집. | [commands/gsd/discuss-phase.md](../../commands/gsd/discuss-phase.md) |
| `/gsd-mvp-phase` | 수직 MVP 슬라이스로 단계 계획 — 사용자 스토리, SPIDR 분할, 이후 plan-phase. | [commands/gsd/mvp-phase.md](../../commands/gsd/mvp-phase.md) |
| `/gsd-spec-phase` | 반증 가능한 요구사항을 담은 SPEC.md를 생성하는 소크라테스식 스펙 정제. | [commands/gsd/spec-phase.md](../../commands/gsd/spec-phase.md) |
| `/gsd-ui-phase` | 프론트엔드 단계용 UI 설계 계약(UI-SPEC.md) 생성. | [commands/gsd/ui-phase.md](../../commands/gsd/ui-phase.md) |
| `/gsd-ai-integration-phase` | 프레임워크 선택, 조사, 평가 계획을 통한 AI 설계 계약(AI-SPEC.md) 생성. | [commands/gsd/ai-integration-phase.md](../../commands/gsd/ai-integration-phase.md) |
| `/gsd-plan-phase` | 검증 루프가 포함된 상세 단계 계획(PLAN.md) 생성. | [commands/gsd/plan-phase.md](../../commands/gsd/plan-phase.md) |
| `/gsd-plan-review-convergence` | 교차 AI 계획 수렴 루프 — HIGH 우려사항이 없을 때까지 리뷰 피드백으로 재계획 (최대 3사이클). | [commands/gsd/plan-review-convergence.md](../../commands/gsd/plan-review-convergence.md) |
| `/gsd-ultraplan-phase` | [BETA] 계획 단계를 Claude Code의 ultraplan 클라우드에 오프로드 — 원격으로 초안 작성, 브라우저에서 검토, `/gsd-import`로 가져오기. Claude Code 전용. | [commands/gsd/ultraplan-phase.md](../../commands/gsd/ultraplan-phase.md) |
| `/gsd-spike` | 일회성 실험으로 아이디어를 빠르게 스파이크; `--wrap-up`으로 결과를 영구 스킬로 패키징. | [commands/gsd/spike.md](../../commands/gsd/spike.md) |
| `/gsd-sketch` | 일회성 HTML 목업을 사용한 UI/설계 아이디어 빠른 스케치; `--wrap-up`으로 결과 패키징. | [commands/gsd/sketch.md](../../commands/gsd/sketch.md) |
| `/gsd-execute-phase` | 웨이브 기반 병렬화로 단계의 모든 계획 실행. | [commands/gsd/execute-phase.md](../../commands/gsd/execute-phase.md) |
| `/gsd-verify-work` | 자동 진단을 포함한 대화형 UAT로 구축된 기능 검증. | [commands/gsd/verify-work.md](../../commands/gsd/verify-work.md) |
| `/gsd-ship` | 검증 후 PR 생성, 리뷰 실행, 병합 준비. | [commands/gsd/ship.md](../../commands/gsd/ship.md) |
| `/gsd-fast` | 하위 에이전트 없이, 계획 오버헤드 없이 인라인으로 사소한 태스크 실행. | [commands/gsd/fast.md](../../commands/gsd/fast.md) |
| `/gsd-quick` | GSD 보장(원자적 커밋, 상태 추적)으로 빠른 태스크 실행, 선택적 에이전트는 생략. | [commands/gsd/quick.md](../../commands/gsd/quick.md) |
| `/gsd-ui-review` | 구현된 프론트엔드 코드의 소급 6-기둥 시각 감사. | [commands/gsd/ui-review.md](../../commands/gsd/ui-review.md) |
| `/gsd-code-review` | 단계에서 변경된 소스 파일을 버그, 보안, 코드 품질 문제에 대해 검토; `--fix`로 결과 자동 적용. | [commands/gsd/code-review.md](../../commands/gsd/code-review.md) |
| `/gsd-eval-review` | 실행된 AI 단계의 평가 범위를 소급 감사; EVAL-REVIEW.md 생성. | [commands/gsd/eval-review.md](../../commands/gsd/eval-review.md) |
| `/msd-new-project` | 심층 컨텍스트 수집 및 PROJECT.md로 새 프로젝트 초기화. | [commands/msd/new-project.md](../../commands/msd/new-project.md) |
| `/msd-onboard` | 기존 코드베이스를 매핑, 문서 수집, 프로젝트 설정, onboarding summary로 안내합니다. | [commands/msd/onboard.md](../../commands/msd/onboard.md) |
| `/msd-workspace` | MSD 워크스페이스 관리 — 격리된 워크스페이스 환경을 생성(`--new`), 목록(`--list`), 또는 제거(`--remove`). | [commands/msd/workspace.md](../../commands/msd/workspace.md) |
| `/msd-discuss-phase` | 계획 전 적응형 질문을 통한 단계 컨텍스트 수집. | [commands/msd/discuss-phase.md](../../commands/msd/discuss-phase.md) |
| `/msd-mvp-phase` | 수직 MVP 슬라이스로 단계 계획 — 사용자 스토리, SPIDR 분할, 이후 plan-phase. | [commands/msd/mvp-phase.md](../../commands/msd/mvp-phase.md) |
| `/msd-spec-phase` | 반증 가능한 요구사항을 담은 SPEC.md를 생성하는 소크라테스식 스펙 정제. | [commands/msd/spec-phase.md](../../commands/msd/spec-phase.md) |
| `/msd-ui-phase` | 프론트엔드 단계용 UI 설계 계약(UI-SPEC.md) 생성. | [commands/msd/ui-phase.md](../../commands/msd/ui-phase.md) |
| `/msd-ai-integration-phase` | 프레임워크 선택, 조사, 평가 계획을 통한 AI 설계 계약(AI-SPEC.md) 생성. | [commands/msd/ai-integration-phase.md](../../commands/msd/ai-integration-phase.md) |
| `/msd-plan-phase` | 검증 루프가 포함된 상세 단계 계획(PLAN.md) 생성. | [commands/msd/plan-phase.md](../../commands/msd/plan-phase.md) |
| `/msd-plan-review-convergence` | 교차 AI 계획 수렴 루프 — HIGH 우려사항이 없을 때까지 리뷰 피드백으로 재계획 (최대 3사이클). | [commands/msd/plan-review-convergence.md](../../commands/msd/plan-review-convergence.md) |
| `/msd-ultraplan-phase` | [BETA] 계획 단계를 Claude Code의 ultraplan 클라우드에 오프로드 — 원격으로 초안 작성, 브라우저에서 검토, `/msd-import`로 가져오기. Claude Code 전용. | [commands/msd/ultraplan-phase.md](../../commands/msd/ultraplan-phase.md) |
| `/msd-spike` | 일회성 실험으로 아이디어를 빠르게 스파이크; `--wrap-up`으로 결과를 영구 스킬로 패키징. | [commands/msd/spike.md](../../commands/msd/spike.md) |
| `/msd-sketch` | 일회성 HTML 목업을 사용한 UI/설계 아이디어 빠른 스케치; `--wrap-up`으로 결과 패키징. | [commands/msd/sketch.md](../../commands/msd/sketch.md) |
| `/msd-execute-phase` | 웨이브 기반 병렬화로 단계의 모든 계획 실행. | [commands/msd/execute-phase.md](../../commands/msd/execute-phase.md) |
| `/msd-verify-work` | 자동 진단을 포함한 대화형 UAT로 구축된 기능 검증. | [commands/msd/verify-work.md](../../commands/msd/verify-work.md) |
| `/msd-ship` | 검증 후 PR 생성, 리뷰 실행, 병합 준비. | [commands/msd/ship.md](../../commands/msd/ship.md) |
| `/msd-fast` | 하위 에이전트 없이, 계획 오버헤드 없이 인라인으로 사소한 태스크 실행. | [commands/msd/fast.md](../../commands/msd/fast.md) |
| `/msd-quick` | MSD 보장(원자적 커밋, 상태 추적)으로 빠른 태스크 실행, 선택적 에이전트는 생략. | [commands/msd/quick.md](../../commands/msd/quick.md) |
| `/msd-ui-review` | 구현된 프론트엔드 코드의 소급 6-기둥 시각 감사. | [commands/msd/ui-review.md](../../commands/msd/ui-review.md) |
| `/msd-code-review` | 단계에서 변경된 소스 파일을 버그, 보안, 코드 품질 문제에 대해 검토; `--fix`로 결과 자동 적용. | [commands/msd/code-review.md](../../commands/msd/code-review.md) |
| `/msd-eval-review` | 실행된 AI 단계의 평가 범위를 소급 감사; EVAL-REVIEW.md 생성. | [commands/msd/eval-review.md](../../commands/msd/eval-review.md) |
### 단계 및 마일스톤 관리
| 명령어 | 역할 | 소스 |
|---------|------|--------|
| `/gsd-phase` | 단계 CRUD — ROADMAP.md에서 단계 추가(기본값), 삽입(`--insert`), 제거(`--remove`), 편집(`--edit`). | [commands/gsd/phase.md](../../commands/gsd/phase.md) |
| `/gsd-add-tests` | UAT 기준 및 구현에 기반한 완료된 단계의 테스트 생성. | [commands/gsd/add-tests.md](../../commands/gsd/add-tests.md) |
| `/gsd-validate-phase` | 완료된 단계의 나이퀴스트 검증 공백을 소급 감사 및 채움. | [commands/gsd/validate-phase.md](../../commands/gsd/validate-phase.md) |
| `/gsd-secure-phase` | 완료된 단계의 위협 완화를 소급 검증. | [commands/gsd/secure-phase.md](../../commands/gsd/secure-phase.md) |
| `/gsd-audit-milestone` | 아카이브 전 원래 의도 대비 마일스톤 완료 감사. | [commands/gsd/audit-milestone.md](../../commands/gsd/audit-milestone.md) |
| `/gsd-audit-uat` | 미완료된 모든 UAT 및 검증 항목의 단계 간 감사. | [commands/gsd/audit-uat.md](../../commands/gsd/audit-uat.md) |
| `/gsd-audit-fix` | 자율 감사-수정 파이프라인 — 문제 찾기, 분류, 수정, 테스트, 커밋. | [commands/gsd/audit-fix.md](../../commands/gsd/audit-fix.md) |
| `/gsd-complete-milestone` | 완료된 마일스톤 아카이브 및 다음 버전 준비. | [commands/gsd/complete-milestone.md](../../commands/gsd/complete-milestone.md) |
| `/gsd-new-milestone` | 새 마일스톤 사이클 시작 — PROJECT.md 업데이트 및 요구사항으로 라우팅. | [commands/gsd/new-milestone.md](../../commands/gsd/new-milestone.md) |
| `/gsd-milestone-summary` | 마일스톤 아티팩트로부터 포괄적인 프로젝트 요약 생성. | [commands/gsd/milestone-summary.md](../../commands/gsd/milestone-summary.md) |
| `/gsd-cleanup` | 완료된 마일스톤에서 누적된 단계 디렉터리 아카이브. | [commands/gsd/cleanup.md](../../commands/gsd/cleanup.md) |
| `/gsd-manager` | 하나의 터미널에서 여러 단계를 관리하는 인터랙티브 커맨드 센터. | [commands/gsd/manager.md](../../commands/gsd/manager.md) |
| `/gsd-workstreams` | 병렬 워크스트림 관리 — 목록, 생성, 전환, 상태, 진행도, 완료, 재개. | [commands/gsd/workstreams.md](../../commands/gsd/workstreams.md) |
| `/gsd-autonomous` | 나머지 모든 단계를 자율적으로 실행 — 단계별 discuss → plan → execute. | [commands/gsd/autonomous.md](../../commands/gsd/autonomous.md) |
| `/gsd-undo` | 안전한 git 되돌리기 — 단계 매니페스트를 사용하여 단계 또는 계획 커밋 롤백. | [commands/gsd/undo.md](../../commands/gsd/undo.md) |
| `/msd-phase` | 단계 CRUD — ROADMAP.md에서 단계 추가(기본값), 삽입(`--insert`), 제거(`--remove`), 편집(`--edit`). | [commands/msd/phase.md](../../commands/msd/phase.md) |
| `/msd-add-tests` | UAT 기준 및 구현에 기반한 완료된 단계의 테스트 생성. | [commands/msd/add-tests.md](../../commands/msd/add-tests.md) |
| `/msd-validate-phase` | 완료된 단계의 나이퀴스트 검증 공백을 소급 감사 및 채움. | [commands/msd/validate-phase.md](../../commands/msd/validate-phase.md) |
| `/msd-secure-phase` | 완료된 단계의 위협 완화를 소급 검증. | [commands/msd/secure-phase.md](../../commands/msd/secure-phase.md) |
| `/msd-audit-milestone` | 아카이브 전 원래 의도 대비 마일스톤 완료 감사. | [commands/msd/audit-milestone.md](../../commands/msd/audit-milestone.md) |
| `/msd-audit-uat` | 미완료된 모든 UAT 및 검증 항목의 단계 간 감사. | [commands/msd/audit-uat.md](../../commands/msd/audit-uat.md) |
| `/msd-audit-fix` | 자율 감사-수정 파이프라인 — 문제 찾기, 분류, 수정, 테스트, 커밋. | [commands/msd/audit-fix.md](../../commands/msd/audit-fix.md) |
| `/msd-complete-milestone` | 완료된 마일스톤 아카이브 및 다음 버전 준비. | [commands/msd/complete-milestone.md](../../commands/msd/complete-milestone.md) |
| `/msd-new-milestone` | 새 마일스톤 사이클 시작 — PROJECT.md 업데이트 및 요구사항으로 라우팅. | [commands/msd/new-milestone.md](../../commands/msd/new-milestone.md) |
| `/msd-milestone-summary` | 마일스톤 아티팩트로부터 포괄적인 프로젝트 요약 생성. | [commands/msd/milestone-summary.md](../../commands/msd/milestone-summary.md) |
| `/msd-cleanup` | 완료된 마일스톤에서 누적된 단계 디렉터리 아카이브. | [commands/msd/cleanup.md](../../commands/msd/cleanup.md) |
| `/msd-manager` | 하나의 터미널에서 여러 단계를 관리하는 인터랙티브 커맨드 센터. | [commands/msd/manager.md](../../commands/msd/manager.md) |
| `/msd-workstreams` | 병렬 워크스트림 관리 — 목록, 생성, 전환, 상태, 진행도, 완료, 재개. | [commands/msd/workstreams.md](../../commands/msd/workstreams.md) |
| `/msd-autonomous` | 나머지 모든 단계를 자율적으로 실행 — 단계별 discuss → plan → execute. | [commands/msd/autonomous.md](../../commands/msd/autonomous.md) |
| `/msd-undo` | 안전한 git 되돌리기 — 단계 매니페스트를 사용하여 단계 또는 계획 커밋 롤백. | [commands/msd/undo.md](../../commands/msd/undo.md) |
### 세션 및 탐색
| 명령어 | 역할 | 소스 |
|---------|------|--------|
| `/gsd-progress` | 프로젝트 진행도 확인, 컨텍스트 표시, 다음 액션으로 라우팅; `--next`로 자동 진행 또는 `--do`로 자유 형식 태스크 실행. | [commands/gsd/progress.md](../../commands/gsd/progress.md) |
| `/gsd-capture` | 아이디어, 태스크, 메모, 씨앗 캡처 — todo(기본값), `--note`, `--backlog`, `--seed`, 또는 `--list` 미완료 todo. | [commands/gsd/capture.md](../../commands/gsd/capture.md) |
| `/gsd-stats` | 프로젝트 통계 표시 — 단계, 계획, 요구사항, git 메트릭, 타임라인. | [commands/gsd/stats.md](../../commands/gsd/stats.md) |
| `/gsd-pause-work` | 단계 중간에 작업을 일시 중지할 때 컨텍스트 핸드오프 생성. | [commands/gsd/pause-work.md](../../commands/gsd/pause-work.md) |
| `/gsd-resume-work` | 이전 세션에서 전체 컨텍스트 복원으로 작업 재개. | [commands/gsd/resume-work.md](../../commands/gsd/resume-work.md) |
| `/gsd-explore` | 소크라테스식 아이디어 발상 및 라우팅 — 커밋 전 아이디어 심화 검토. | [commands/gsd/explore.md](../../commands/gsd/explore.md) |
| `/gsd-review-backlog` | 백로그 항목 검토 및 활성 마일스톤으로 승격. | [commands/gsd/review-backlog.md](../../commands/gsd/review-backlog.md) |
| `/gsd-thread` | 세션 간 작업을 위한 영속 컨텍스트 스레드 관리. | [commands/gsd/thread.md](../../commands/gsd/thread.md) |
| `/msd-progress` | 프로젝트 진행도 확인, 컨텍스트 표시, 다음 액션으로 라우팅; `--next`로 자동 진행 또는 `--do`로 자유 형식 태스크 실행. | [commands/msd/progress.md](../../commands/msd/progress.md) |
| `/msd-capture` | 아이디어, 태스크, 메모, 씨앗 캡처 — todo(기본값), `--note`, `--backlog`, `--seed`, 또는 `--list` 미완료 todo. | [commands/msd/capture.md](../../commands/msd/capture.md) |
| `/msd-stats` | 프로젝트 통계 표시 — 단계, 계획, 요구사항, git 메트릭, 타임라인. | [commands/msd/stats.md](../../commands/msd/stats.md) |
| `/msd-pause-work` | 단계 중간에 작업을 일시 중지할 때 컨텍스트 핸드오프 생성. | [commands/msd/pause-work.md](../../commands/msd/pause-work.md) |
| `/msd-resume-work` | 이전 세션에서 전체 컨텍스트 복원으로 작업 재개. | [commands/msd/resume-work.md](../../commands/msd/resume-work.md) |
| `/msd-explore` | 소크라테스식 아이디어 발상 및 라우팅 — 커밋 전 아이디어 심화 검토. | [commands/msd/explore.md](../../commands/msd/explore.md) |
| `/msd-review-backlog` | 백로그 항목 검토 및 활성 마일스톤으로 승격. | [commands/msd/review-backlog.md](../../commands/msd/review-backlog.md) |
| `/msd-thread` | 세션 간 작업을 위한 영속 컨텍스트 스레드 관리. | [commands/msd/thread.md](../../commands/msd/thread.md) |
### 코드베이스 인텔리전스
| 명령어 | 역할 | 소스 |
|---------|------|--------|
| `/gsd-map-codebase` | 병렬 매퍼 에이전트로 코드베이스 분석; 경량 스캔은 `--fast`, 인텔 쿼리는 `--query`. | [commands/gsd/map-codebase.md](../../commands/gsd/map-codebase.md) |
| `/gsd-graphify` | `.planning/graphs/`의 프로젝트 지식 그래프 구축, 쿼리, 검사. | [commands/gsd/graphify.md](../../commands/gsd/graphify.md) |
| `/gsd-extract-learnings` | 완료된 단계 아티팩트에서 결정, 교훈, 패턴, 놀라운 점 추출. | [commands/gsd/extract-learnings.md](../../commands/gsd/extract-learnings.md) |
| `/msd-map-codebase` | 병렬 매퍼 에이전트로 코드베이스 분석; 경량 스캔은 `--fast`, 인텔 쿼리는 `--query`. | [commands/msd/map-codebase.md](../../commands/msd/map-codebase.md) |
| `/msd-graphify` | `.planning/graphs/`의 프로젝트 지식 그래프 구축, 쿼리, 검사. | [commands/msd/graphify.md](../../commands/msd/graphify.md) |
| `/msd-extract-learnings` | 완료된 단계 아티팩트에서 결정, 교훈, 패턴, 놀라운 점 추출. | [commands/msd/extract-learnings.md](../../commands/msd/extract-learnings.md) |
### 리뷰, 디버그 및 복구
| 명령어 | 역할 | 소스 |
|---------|------|--------|
| `/gsd-review` | 외부 AI CLI에서 단계 계획의 교차 AI 피어 리뷰 요청. | [commands/gsd/review.md](../../commands/gsd/review.md) |
| `/gsd-debug` | 컨텍스트 재설정 전반에 걸쳐 영속 상태를 사용하는 체계적 디버깅. | [commands/gsd/debug.md](../../commands/gsd/debug.md) |
| `/gsd-forensics` | 실패한 GSD 워크플로우의 사후 조사 — git, 아티팩트, 상태 분석. | [commands/gsd/forensics.md](../../commands/gsd/forensics.md) |
| `/gsd-health` | 계획 디렉터리 상태를 진단하고 선택적으로 문제 수정. | [commands/gsd/health.md](../../commands/gsd/health.md) |
| `/gsd-import` | 프로젝트 결정에 대한 충돌 감지로 외부 계획 수집. | [commands/gsd/import.md](../../commands/gsd/import.md) |
| `/gsd-inbox` | 프로젝트 템플릿에 대한 모든 열린 GitHub 이슈 및 PR 분류 및 검토. | [commands/gsd/inbox.md](../../commands/gsd/inbox.md) |
| `/msd-review` | 외부 AI CLI에서 단계 계획의 교차 AI 피어 리뷰 요청. | [commands/msd/review.md](../../commands/msd/review.md) |
| `/msd-debug` | 컨텍스트 재설정 전반에 걸쳐 영속 상태를 사용하는 체계적 디버깅. | [commands/msd/debug.md](../../commands/msd/debug.md) |
| `/msd-forensics` | 실패한 MSD 워크플로우의 사후 조사 — git, 아티팩트, 상태 분석. | [commands/msd/forensics.md](../../commands/msd/forensics.md) |
| `/msd-health` | 계획 디렉터리 상태를 진단하고 선택적으로 문제 수정. | [commands/msd/health.md](../../commands/msd/health.md) |
| `/msd-import` | 프로젝트 결정에 대한 충돌 감지로 외부 계획 수집. | [commands/msd/import.md](../../commands/msd/import.md) |
| `/msd-inbox` | 프로젝트 템플릿에 대한 모든 열린 GitHub 이슈 및 PR 분류 및 검토. | [commands/msd/inbox.md](../../commands/msd/inbox.md) |
### 문서, 프로필 및 유틸리티
| 명령어 | 역할 | 소스 |
|---------|------|--------|
| `/gsd-docs-update` | 코드베이스에 대해 검증된 프로젝트 문서 생성 또는 업데이트. | [commands/gsd/docs-update.md](../../commands/gsd/docs-update.md) |
| `/gsd-ingest-docs` | 혼합 ADR/PRD/SPEC/DOC가 있는 저장소를 스캔하고 분류, 합성, 충돌 보고서로 전체 `.planning/` 설정을 부트스트랩 또는 병합. | [commands/gsd/ingest-docs.md](../../commands/gsd/ingest-docs.md) |
| `/gsd-profile-user` | 개발자 행동 프로필 및 Claude 검색 가능한 아티팩트 생성. | [commands/gsd/profile-user.md](../../commands/gsd/profile-user.md) |
| `/gsd-settings` | GSD 워크플로우 토글 및 모델 프로필 구성. | [commands/gsd/settings.md](../../commands/gsd/settings.md) |
| `/gsd-config` | GSD 설정 구성 — 워크플로우 토글(기본값), 고급 설정(`--advanced`), 통합(`--integrations`), 또는 모델 프로필(`--profile`). | [commands/gsd/config.md](../../commands/gsd/config.md) |
| `/gsd-pr-branch` | `.planning/` 커밋을 필터링하여 깔끔한 PR 브랜치 생성. | [commands/gsd/pr-branch.md](../../commands/gsd/pr-branch.md) |
| `/gsd-surface` | 표면화할 스킬 토글 — 재설치 없이 프로필 적용, 목록 보기, 클러스터 비활성화. | [commands/gsd/surface.md](../../commands/gsd/surface.md) |
| `/gsd-update` | GSD를 최신 버전으로 업데이트; `--sync`로 런타임 간 스킬 동기화 또는 `--reapply`로 로컬 패치 재적용. | [commands/gsd/update.md](../../commands/gsd/update.md) |
| `/gsd-help` | 사용 가능한 GSD 명령어 및 사용 가이드 표시. | [commands/gsd/help.md](../../commands/gsd/help.md) |
| `/msd-docs-update` | 코드베이스에 대해 검증된 프로젝트 문서 생성 또는 업데이트. | [commands/msd/docs-update.md](../../commands/msd/docs-update.md) |
| `/msd-ingest-docs` | 혼합 ADR/PRD/SPEC/DOC가 있는 저장소를 스캔하고 분류, 합성, 충돌 보고서로 전체 `.planning/` 설정을 부트스트랩 또는 병합. | [commands/msd/ingest-docs.md](../../commands/msd/ingest-docs.md) |
| `/msd-profile-user` | 개발자 행동 프로필 및 Claude 검색 가능한 아티팩트 생성. | [commands/msd/profile-user.md](../../commands/msd/profile-user.md) |
| `/msd-settings` | MSD 워크플로우 토글 및 모델 프로필 구성. | [commands/msd/settings.md](../../commands/msd/settings.md) |
| `/msd-config` | MSD 설정 구성 — 워크플로우 토글(기본값), 고급 설정(`--advanced`), 통합(`--integrations`), 또는 모델 프로필(`--profile`). | [commands/msd/config.md](../../commands/msd/config.md) |
| `/msd-pr-branch` | `.planning/` 커밋을 필터링하여 깔끔한 PR 브랜치 생성. | [commands/msd/pr-branch.md](../../commands/msd/pr-branch.md) |
| `/msd-surface` | 표면화할 스킬 토글 — 재설치 없이 프로필 적용, 목록 보기, 클러스터 비활성화. | [commands/msd/surface.md](../../commands/msd/surface.md) |
| `/msd-update` | MSD를 최신 버전으로 업데이트; `--sync`로 런타임 간 스킬 동기화 또는 `--reapply`로 로컬 패치 재적용. | [commands/msd/update.md](../../commands/msd/update.md) |
| `/msd-help` | 사용 가능한 MSD 명령어 및 사용 가이드 표시. | [commands/msd/help.md](../../commands/msd/help.md) |
---
## 워크플로우 (88개 출시)
전체 목록은 `gsd-core/workflows/*.md`에 있습니다. 워크플로우는 명령어가 내부적으로 참조하는 얇은 오케스트레이터입니다; 대부분은 최종 사용자가 직접 읽지 않습니다. 아래 행은 각 워크플로우 파일을 역할(`<purpose>` 블록에서 도출)과, 해당하는 경우 호출 명령어에 매핑합니다.
전체 목록은 `msd-core/workflows/*.md`에 있습니다. 워크플로우는 명령어가 내부적으로 참조하는 얇은 오케스트레이터입니다; 대부분은 최종 사용자가 직접 읽지 않습니다. 아래 행은 각 워크플로우 파일을 역할(`<purpose>` 블록에서 도출)과, 해당하는 경우 호출 명령어에 매핑합니다.
| 워크플로우 | 역할 | 호출자 |
|----------|------|------------|
| `add-backlog.md` | 999.x 번호 체계를 사용하여 ROADMAP.md에 백로그 항목 추가. | `/gsd-capture --backlog` |
| `add-phase.md` | 로드맵의 현재 마일스톤 끝에 새 정수 단계 추가. | `/gsd-phase` (기본값) |
| `add-tests.md` | 완료된 단계의 아티팩트를 기반으로 단위 및 E2E 테스트 생성. | `/gsd-add-tests` |
| `add-todo.md` | 세션 중 발생하는 아이디어나 태스크를 구조화된 todo로 캡처. | `/gsd-capture` (기본값) |
| `ai-integration-phase.md` | 프레임워크 선택 → AI 조사 → 도메인 조사 → 평가 계획을 AI-SPEC.md로 오케스트레이션. | `/gsd-ai-integration-phase` |
| `analyze-dependencies.md` | 파일 겹침 및 의미론적 의존성에 대한 ROADMAP.md 단계 분석; `Depends on` 엣지 제안. | `/gsd-manager --analyze-deps` |
| `audit-fix.md` | 자율 감사-수정 파이프라인 — 감사 실행, 파싱, 분류, 수정, 테스트, 커밋. | `/gsd-audit-fix` |
| `audit-milestone.md` | 단계 검증을 집계하여 마일스톤이 완료 정의를 충족했는지 확인. | `/gsd-audit-milestone` |
| `audit-uat.md` | UAT 및 검증 파일의 단계 간 감사; 우선순위화된 미완료 항목 목록 생성. | `/gsd-audit-uat` |
| `autonomous.md` | 마일스톤 단계를 자율적으로 구동 — 나머지 모두, 범위, 또는 단일 단계. | `/gsd-autonomous` |
| `check-todos.md` | 미완료 todo 목록, 선택 허용, 컨텍스트 로드, 적절한 액션으로 라우팅. | `/gsd-capture --list` |
| `cleanup.md` | 완료된 마일스톤에서 누적된 단계 디렉터리 아카이브. | `/gsd-cleanup` |
| `code-review-fix.md` | gsd-code-fixer를 통해 수정별 원자적 커밋으로 REVIEW.md의 문제 자동 수정. | `/gsd-code-review --fix` |
| `code-review.md` | gsd-code-reviewer를 통한 단계 소스 변경 검토; REVIEW.md 생성. | `/gsd-code-review` |
| `complete-milestone.md` | 출시된 버전을 완료로 표시 — MILESTONES.md 항목, PROJECT.md 발전, 태그. | `/gsd-complete-milestone` |
| `diagnose-issues.md` | UAT 공백 조사 및 근본 원인 찾기를 위한 병렬 디버그 에이전트 오케스트레이션. | `/gsd-verify-work` (자동 진단) |
| `discuss-phase-assumptions.md` | 가정 모드 discuss — 코드베이스 우선 분석을 통한 구현 결정 추출. | `/gsd-discuss-phase` (`discuss_mode=assumptions`일 때) |
| `discuss-phase-power.md` | 파워 유저 discuss — 모든 질문을 JSON 상태 파일 + HTML UI로 사전 생성. | `/gsd-discuss-phase --power` |
| `discuss-phase.md` | 반복적인 회색 지대 토론을 통한 구현 결정 추출. | `/gsd-discuss-phase` |
| `mvp-phase.md` | 수직 MVP 슬라이스로 단계 계획 — 사용자 스토리, SPIDR 분할, 이후 plan-phase. | `/gsd-mvp-phase` |
| `do.md` | 사용자의 자유 형식 텍스트를 가장 적합한 GSD 명령어로 라우팅. | `/gsd-progress --do` |
| `docs-update.md` | 표준 및 수작업 프로젝트 문서 생성, 업데이트, 검증. | `/gsd-docs-update` |
| `edit-phase.md` | ROADMAP.md에서 기존 단계의 임의 필드를 번호와 위치를 유지한 채 인플레이스 편집. | `/gsd-phase --edit` |
| `eval-review.md` | 구현된 AI 단계의 평가 범위에 대한 소급 감사. | `/gsd-eval-review` |
| `execute-phase.md` | 웨이브 기반 병렬 실행으로 단계의 모든 계획 실행. | `/gsd-execute-phase` |
| `add-backlog.md` | 999.x 번호 체계를 사용하여 ROADMAP.md에 백로그 항목 추가. | `/msd-capture --backlog` |
| `add-phase.md` | 로드맵의 현재 마일스톤 끝에 새 정수 단계 추가. | `/msd-phase` (기본값) |
| `add-tests.md` | 완료된 단계의 아티팩트를 기반으로 단위 및 E2E 테스트 생성. | `/msd-add-tests` |
| `add-todo.md` | 세션 중 발생하는 아이디어나 태스크를 구조화된 todo로 캡처. | `/msd-capture` (기본값) |
| `ai-integration-phase.md` | 프레임워크 선택 → AI 조사 → 도메인 조사 → 평가 계획을 AI-SPEC.md로 오케스트레이션. | `/msd-ai-integration-phase` |
| `analyze-dependencies.md` | 파일 겹침 및 의미론적 의존성에 대한 ROADMAP.md 단계 분석; `Depends on` 엣지 제안. | `/msd-manager --analyze-deps` |
| `audit-fix.md` | 자율 감사-수정 파이프라인 — 감사 실행, 파싱, 분류, 수정, 테스트, 커밋. | `/msd-audit-fix` |
| `audit-milestone.md` | 단계 검증을 집계하여 마일스톤이 완료 정의를 충족했는지 확인. | `/msd-audit-milestone` |
| `audit-uat.md` | UAT 및 검증 파일의 단계 간 감사; 우선순위화된 미완료 항목 목록 생성. | `/msd-audit-uat` |
| `autonomous.md` | 마일스톤 단계를 자율적으로 구동 — 나머지 모두, 범위, 또는 단일 단계. | `/msd-autonomous` |
| `check-todos.md` | 미완료 todo 목록, 선택 허용, 컨텍스트 로드, 적절한 액션으로 라우팅. | `/msd-capture --list` |
| `cleanup.md` | 완료된 마일스톤에서 누적된 단계 디렉터리 아카이브. | `/msd-cleanup` |
| `code-review-fix.md` | msd-code-fixer를 통해 수정별 원자적 커밋으로 REVIEW.md의 문제 자동 수정. | `/msd-code-review --fix` |
| `code-review.md` | msd-code-reviewer를 통한 단계 소스 변경 검토; REVIEW.md 생성. | `/msd-code-review` |
| `complete-milestone.md` | 출시된 버전을 완료로 표시 — MILESTONES.md 항목, PROJECT.md 발전, 태그. | `/msd-complete-milestone` |
| `diagnose-issues.md` | UAT 공백 조사 및 근본 원인 찾기를 위한 병렬 디버그 에이전트 오케스트레이션. | `/msd-verify-work` (자동 진단) |
| `discuss-phase-assumptions.md` | 가정 모드 discuss — 코드베이스 우선 분석을 통한 구현 결정 추출. | `/msd-discuss-phase` (`discuss_mode=assumptions`일 때) |
| `discuss-phase-power.md` | 파워 유저 discuss — 모든 질문을 JSON 상태 파일 + HTML UI로 사전 생성. | `/msd-discuss-phase --power` |
| `discuss-phase.md` | 반복적인 회색 지대 토론을 통한 구현 결정 추출. | `/msd-discuss-phase` |
| `mvp-phase.md` | 수직 MVP 슬라이스로 단계 계획 — 사용자 스토리, SPIDR 분할, 이후 plan-phase. | `/msd-mvp-phase` |
| `do.md` | 사용자의 자유 형식 텍스트를 가장 적합한 MSD 명령어로 라우팅. | `/msd-progress --do` |
| `docs-update.md` | 표준 및 수작업 프로젝트 문서 생성, 업데이트, 검증. | `/msd-docs-update` |
| `edit-phase.md` | ROADMAP.md에서 기존 단계의 임의 필드를 번호와 위치를 유지한 채 인플레이스 편집. | `/msd-phase --edit` |
| `eval-review.md` | 구현된 AI 단계의 평가 범위에 대한 소급 감사. | `/msd-eval-review` |
| `execute-phase.md` | 웨이브 기반 병렬 실행으로 단계의 모든 계획 실행. | `/msd-execute-phase` |
| `execute-plan.md` | 단계 프롬프트(PLAN.md)를 실행하고 결과 요약(SUMMARY.md) 생성. | `execute-phase.md` (계획별 하위 에이전트) |
| `explore.md` | 소크라테스식 아이디어 발상 — 탐색적 질문으로 개발자 안내. | `/gsd-explore` |
| `debug.md` | 체계적 디버깅 — 하위 명령어 라우팅, 세션 생성, gsd-debug-session-manager 위임. | `/gsd-debug` |
| `extract-learnings.md` | 완료된 단계 아티팩트에서 결정, 교훈, 패턴, 놀라운 점 추출. | `/gsd-extract-learnings` |
| `fast.md` | 하위 에이전트 오버헤드 없이 사소한 태스크 인라인 실행. | `/gsd-fast` |
| `forensics.md` | 실패한 워크플로우의 포렌식 조사 — git, 아티팩트, 상태 분석. | `/gsd-forensics` |
| `explore.md` | 소크라테스식 아이디어 발상 — 탐색적 질문으로 개발자 안내. | `/msd-explore` |
| `debug.md` | 체계적 디버깅 — 하위 명령어 라우팅, 세션 생성, msd-debug-session-manager 위임. | `/msd-debug` |
| `extract-learnings.md` | 완료된 단계 아티팩트에서 결정, 교훈, 패턴, 놀라운 점 추출. | `/msd-extract-learnings` |
| `fast.md` | 하위 에이전트 오버헤드 없이 사소한 태스크 인라인 실행. | `/msd-fast` |
| `forensics.md` | 실패한 워크플로우의 포렌식 조사 — git, 아티팩트, 상태 분석. | `/msd-forensics` |
| `graduation.md` | 단계 간 반복되는 LEARNINGS.md 항목을 클러스터링하고 HITL 승격 후보 표면화. | `transition.md` (graduation_scan 단계) |
| `health.md` | `.planning/` 디렉터리 무결성 검증 및 실행 가능한 문제 보고. | `/gsd-health` |
| `help.md` | 전체 GSD Core 명령어 참조 표시. | `/gsd-help` |
| `import.md` | 기존 프로젝트 결정에 대한 충돌 감지로 외부 계획 수집. | `/gsd-import` |
| `inbox.md` | 프로젝트 기여 템플릿에 대한 열린 GitHub 이슈 및 PR 분류. | `/gsd-inbox` |
| `ingest-docs.md` | 혼합 계획 문서에 대한 저장소 스캔; 분류, 합성, 충돌 보고서로 `.planning/`에 부트스트랩 또는 병합. | `/gsd-ingest-docs` |
| `insert-phase.md` | 마일스톤 중간에 발견된 긴급 작업을 위한 소수점 단계 삽입. | `/gsd-phase --insert` |
| `list-phase-assumptions.md` | 계획 전 Claude의 단계에 대한 가정 표면화. | `/gsd-discuss-phase --assumptions` |
| `list-workspaces.md` | `~/gsd-workspaces/`에서 찾은 모든 GSD 워크스페이스를 상태와 함께 목록. | `/gsd-workspace --list` |
| `manager.md` | 인터랙티브 마일스톤 커맨드 센터 — 대시보드, 인라인 discuss, 백그라운드 plan/execute. | `/gsd-manager` |
| `map-codebase.md` | 병렬 코드베이스 매퍼 에이전트를 오케스트레이션하여 `.planning/codebase/` 문서 생성. | `/gsd-map-codebase` |
| `milestone-summary.md` | 마일스톤 아티팩트에서 온보딩 및 검토용 마일스톤 요약 합성. | `/gsd-milestone-summary` |
| `new-milestone.md` | 새 마일스톤 사이클 시작 — 프로젝트 컨텍스트 로드, 목표 수집, PROJECT.md/STATE.md 업데이트. | `/gsd-new-milestone` |
| `new-project.md` | 통합 새 프로젝트 플로우 — 질문, 조사(선택), 요구사항, 로드맵. | `/gsd-new-project` |
| `onboard.md` | Brownfield 온보딩 오케스트레이션 — 코드베이스 매핑, 문서 수집, planning 초기화, 다음 단계 요약. | `/gsd-onboard` |
| `new-workspace.md` | 저장소 워크트리/클론과 독립적인 `.planning/`이 포함된 격리된 워크스페이스 생성. | `/gsd-workspace --new` |
| `next.md` | 현재 프로젝트 상태를 감지하고 다음 논리적 단계로 자동 진행. | `/gsd-progress --next` |
| `health.md` | `.planning/` 디렉터리 무결성 검증 및 실행 가능한 문제 보고. | `/msd-health` |
| `help.md` | 전체 MSD Core 명령어 참조 표시. | `/msd-help` |
| `import.md` | 기존 프로젝트 결정에 대한 충돌 감지로 외부 계획 수집. | `/msd-import` |
| `inbox.md` | 프로젝트 기여 템플릿에 대한 열린 GitHub 이슈 및 PR 분류. | `/msd-inbox` |
| `ingest-docs.md` | 혼합 계획 문서에 대한 저장소 스캔; 분류, 합성, 충돌 보고서로 `.planning/`에 부트스트랩 또는 병합. | `/msd-ingest-docs` |
| `insert-phase.md` | 마일스톤 중간에 발견된 긴급 작업을 위한 소수점 단계 삽입. | `/msd-phase --insert` |
| `list-phase-assumptions.md` | 계획 전 Claude의 단계에 대한 가정 표면화. | `/msd-discuss-phase --assumptions` |
| `list-workspaces.md` | `~/msd-workspaces/`에서 찾은 모든 MSD 워크스페이스를 상태와 함께 목록. | `/msd-workspace --list` |
| `manager.md` | 인터랙티브 마일스톤 커맨드 센터 — 대시보드, 인라인 discuss, 백그라운드 plan/execute. | `/msd-manager` |
| `map-codebase.md` | 병렬 코드베이스 매퍼 에이전트를 오케스트레이션하여 `.planning/codebase/` 문서 생성. | `/msd-map-codebase` |
| `milestone-summary.md` | 마일스톤 아티팩트에서 온보딩 및 검토용 마일스톤 요약 합성. | `/msd-milestone-summary` |
| `new-milestone.md` | 새 마일스톤 사이클 시작 — 프로젝트 컨텍스트 로드, 목표 수집, PROJECT.md/STATE.md 업데이트. | `/msd-new-milestone` |
| `new-project.md` | 통합 새 프로젝트 플로우 — 질문, 조사(선택), 요구사항, 로드맵. | `/msd-new-project` |
| `onboard.md` | Brownfield 온보딩 오케스트레이션 — 코드베이스 매핑, 문서 수집, planning 초기화, 다음 단계 요약. | `/msd-onboard` |
| `new-workspace.md` | 저장소 워크트리/클론과 독립적인 `.planning/`이 포함된 격리된 워크스페이스 생성. | `/msd-workspace --new` |
| `next.md` | 현재 프로젝트 상태를 감지하고 다음 논리적 단계로 자동 진행. | `/msd-progress --next` |
| `node-repair.md` | 실패한 태스크 검증을 위한 자율 수리 오퍼레이터; `execute-plan`에 의해 호출. | `execute-plan.md` (복구) |
| `note.md` | 마찰 없는 아이디어 캡처 — 단일 Write 호출, 단일 확인 줄. | `/gsd-capture --note` |
| `pause-work.md` | 구조화된 `.planning/HANDOFF.json` 및 `.continue-here.md` 핸드오프 파일 생성. | `/gsd-pause-work` |
| `plan-phase.md` | 통합 조사 및 검증 루프로 실행 가능한 PLAN.md 파일 생성. | `/gsd-plan-phase`, `/gsd-quick` |
| `plan-review-convergence.md` | 교차 AI 계획 수렴 루프 — HIGH 우려사항이 없을 때까지 리뷰 피드백으로 재계획. | `/gsd-plan-review-convergence` |
| `plant-seed.md` | 트리거 조건이 포함된 구조화된 씨앗 파일로 미래 지향적인 아이디어 캡처. | `/gsd-capture --seed` |
| `pr-branch.md` | `.planning/` 커밋을 필터링하여 풀 리퀘스트를 위한 깔끔한 브랜치 생성. | `/gsd-pr-branch` |
| `profile-user.md` | 전체 개발자 프로파일링 플로우 오케스트레이션 — 동의, 세션 스캔, 프로필 생성. | `/gsd-profile-user` |
| `progress.md` | 진행도 렌더링 — 프로젝트 컨텍스트, 위치, 다음 액션 라우팅. | `/gsd-progress` |
| `quick.md` | GSD 보장(원자적 커밋, 상태 추적)으로 빠른 태스크 실행. | `/gsd-quick` |
| `reapply-patches.md` | GSD 업데이트 후 로컬 수정 사항 재적용. | `/gsd-update --reapply` |
| `remove-phase.md` | 로드맵에서 미래 단계를 제거하고 후속 단계 번호 재지정. | `/gsd-phase --remove` |
| `remove-workspace.md` | GSD 워크스페이스 제거 및 워크트리 정리. | `/gsd-workspace --remove` |
| `resume-project.md` | 작업 재개 — STATE.md, HANDOFF.json, 아티팩트에서 전체 컨텍스트 복원. | `/gsd-resume-work` |
| `review.md` | 외부 CLI를 통한 교차 AI 계획 리뷰; REVIEWS.md 생성. | `/gsd-review` |
| `scan.md` | 신속한 단일 포커스 코드베이스 스캔 — map-codebase의 경량 대안. | `/gsd-map-codebase --fast` |
| `secure-phase.md` | 완료된 단계에 대한 소급 위협 완화 감사. | `/gsd-secure-phase` |
| `session-report.md` | 세션 보고서 — 토큰 사용량, 작업 요약, 결과. | `/gsd-pause-work --report` |
| `settings.md` | GSD 워크플로우 토글 및 모델 프로필 구성. | `/gsd-settings`, `/gsd-config --profile` |
| `settings-advanced.md` | GSD 파워 유저 설정 구성 — 계획 바운스, 타임아웃, 브랜치 템플릿, 교차 AI 실행, 런타임 설정. | `/gsd-config --advanced` |
| `settings-integrations.md` | 타사 API 키(Brave/Firecrawl/Exa), `review.models.<cli>` CLI 라우팅, 마스킹된(`****<last-4>`) 표시로 `agent_skills.<agent-type>` 주입 구성. | `/gsd-config --integrations` |
| `ship.md` | 검증 후 PR 생성, 리뷰 실행, 병합 준비. | `/gsd-ship` |
| `sketch.md` | 스케치당 2-3개 변형으로 일회성 HTML 목업을 통한 설계 방향 탐색. | `/gsd-sketch` |
| `sketch-wrap-up.md` | 스케치 결과를 큐레이션하고 영구 `sketch-findings-[project]` 스킬로 패키징. | `/gsd-sketch --wrap-up` |
| `spec-phase.md` | 모호성 점수가 포함된 소크라테스식 스펙 정제; SPEC.md 생성. | `/gsd-spec-phase` |
| `spike.md` | 포커스된 일회성 실험을 통한 빠른 실현 가능성 검증. | `/gsd-spike` |
| `spike-wrap-up.md` | 스파이크 결과를 큐레이션하고 영구 `spike-findings-[project]` 스킬로 패키징. | `/gsd-spike --wrap-up` |
| `stats.md` | 프로젝트 통계 렌더링 — 단계, 계획, 요구사항, git 메트릭. | `/gsd-stats` |
| `sync-skills.md` | 교차 런타임 GSD 스킬 동기화 — 런타임 루트 간 `gsd-*` 스킬 디렉터리 비교 및 적용. | `/gsd-update --sync` |
| `transition.md` | 단계 경계 전환 워크플로우 — 워크스트림 확인, 상태 진행. | `execute-phase.md`, `/gsd-progress --next` |
| `ui-phase.md` | gsd-ui-researcher를 통한 UI-SPEC.md 설계 계약 생성. | `/gsd-ui-phase` |
| `ui-review.md` | gsd-ui-auditor를 통한 소급 6-기둥 시각 감사. | `/gsd-ui-review` |
| `ultraplan-phase.md` | [BETA] 계획을 Claude Code의 ultraplan 클라우드에 오프로드; 원격으로 초안 작성 후 `/gsd-import`로 가져오기. | `/gsd-ultraplan-phase` |
| `undo.md` | 안전한 git 되돌리기 — 단계 매니페스트를 사용한 단계 또는 계획 커밋. | `/gsd-undo` |
| `thread.md` | 세션 간 작업을 위한 영속 컨텍스트 스레드 생성, 목록, 닫기, 재개. | `/gsd-thread` |
| `update.md` | 체인지로그 표시와 함께 GSD를 최신 버전으로 업데이트. | `/gsd-update` |
| `validate-phase.md` | 완료된 단계의 나이퀴스트 검증 공백을 소급 감사 및 채움. | `/gsd-validate-phase` |
| `verify-work.md` | 자동 진단이 포함된 대화형 UAT — UAT.md 및 수정 계획 생성. | `/gsd-verify-work` |
| `note.md` | 마찰 없는 아이디어 캡처 — 단일 Write 호출, 단일 확인 줄. | `/msd-capture --note` |
| `pause-work.md` | 구조화된 `.planning/HANDOFF.json` 및 `.continue-here.md` 핸드오프 파일 생성. | `/msd-pause-work` |
| `plan-phase.md` | 통합 조사 및 검증 루프로 실행 가능한 PLAN.md 파일 생성. | `/msd-plan-phase`, `/msd-quick` |
| `plan-review-convergence.md` | 교차 AI 계획 수렴 루프 — HIGH 우려사항이 없을 때까지 리뷰 피드백으로 재계획. | `/msd-plan-review-convergence` |
| `plant-seed.md` | 트리거 조건이 포함된 구조화된 씨앗 파일로 미래 지향적인 아이디어 캡처. | `/msd-capture --seed` |
| `pr-branch.md` | `.planning/` 커밋을 필터링하여 풀 리퀘스트를 위한 깔끔한 브랜치 생성. | `/msd-pr-branch` |
| `profile-user.md` | 전체 개발자 프로파일링 플로우 오케스트레이션 — 동의, 세션 스캔, 프로필 생성. | `/msd-profile-user` |
| `progress.md` | 진행도 렌더링 — 프로젝트 컨텍스트, 위치, 다음 액션 라우팅. | `/msd-progress` |
| `quick.md` | MSD 보장(원자적 커밋, 상태 추적)으로 빠른 태스크 실행. | `/msd-quick` |
| `reapply-patches.md` | MSD 업데이트 후 로컬 수정 사항 재적용. | `/msd-update --reapply` |
| `remove-phase.md` | 로드맵에서 미래 단계를 제거하고 후속 단계 번호 재지정. | `/msd-phase --remove` |
| `remove-workspace.md` | MSD 워크스페이스 제거 및 워크트리 정리. | `/msd-workspace --remove` |
| `resume-project.md` | 작업 재개 — STATE.md, HANDOFF.json, 아티팩트에서 전체 컨텍스트 복원. | `/msd-resume-work` |
| `review.md` | 외부 CLI를 통한 교차 AI 계획 리뷰; REVIEWS.md 생성. | `/msd-review` |
| `scan.md` | 신속한 단일 포커스 코드베이스 스캔 — map-codebase의 경량 대안. | `/msd-map-codebase --fast` |
| `secure-phase.md` | 완료된 단계에 대한 소급 위협 완화 감사. | `/msd-secure-phase` |
| `session-report.md` | 세션 보고서 — 토큰 사용량, 작업 요약, 결과. | `/msd-pause-work --report` |
| `settings.md` | MSD 워크플로우 토글 및 모델 프로필 구성. | `/msd-settings`, `/msd-config --profile` |
| `settings-advanced.md` | MSD 파워 유저 설정 구성 — 계획 바운스, 타임아웃, 브랜치 템플릿, 교차 AI 실행, 런타임 설정. | `/msd-config --advanced` |
| `settings-integrations.md` | 타사 API 키(Brave/Firecrawl/Exa), `review.models.<cli>` CLI 라우팅, 마스킹된(`****<last-4>`) 표시로 `agent_skills.<agent-type>` 주입 구성. | `/msd-config --integrations` |
| `ship.md` | 검증 후 PR 생성, 리뷰 실행, 병합 준비. | `/msd-ship` |
| `sketch.md` | 스케치당 2-3개 변형으로 일회성 HTML 목업을 통한 설계 방향 탐색. | `/msd-sketch` |
| `sketch-wrap-up.md` | 스케치 결과를 큐레이션하고 영구 `sketch-findings-[project]` 스킬로 패키징. | `/msd-sketch --wrap-up` |
| `spec-phase.md` | 모호성 점수가 포함된 소크라테스식 스펙 정제; SPEC.md 생성. | `/msd-spec-phase` |
| `spike.md` | 포커스된 일회성 실험을 통한 빠른 실현 가능성 검증. | `/msd-spike` |
| `spike-wrap-up.md` | 스파이크 결과를 큐레이션하고 영구 `spike-findings-[project]` 스킬로 패키징. | `/msd-spike --wrap-up` |
| `stats.md` | 프로젝트 통계 렌더링 — 단계, 계획, 요구사항, git 메트릭. | `/msd-stats` |
| `sync-skills.md` | 교차 런타임 MSD 스킬 동기화 — 런타임 루트 간 `msd-*` 스킬 디렉터리 비교 및 적용. | `/msd-update --sync` |
| `transition.md` | 단계 경계 전환 워크플로우 — 워크스트림 확인, 상태 진행. | `execute-phase.md`, `/msd-progress --next` |
| `ui-phase.md` | msd-ui-researcher를 통한 UI-SPEC.md 설계 계약 생성. | `/msd-ui-phase` |
| `ui-review.md` | msd-ui-auditor를 통한 소급 6-기둥 시각 감사. | `/msd-ui-review` |
| `ultraplan-phase.md` | [BETA] 계획을 Claude Code의 ultraplan 클라우드에 오프로드; 원격으로 초안 작성 후 `/msd-import`로 가져오기. | `/msd-ultraplan-phase` |
| `undo.md` | 안전한 git 되돌리기 — 단계 매니페스트를 사용한 단계 또는 계획 커밋. | `/msd-undo` |
| `thread.md` | 세션 간 작업을 위한 영속 컨텍스트 스레드 생성, 목록, 닫기, 재개. | `/msd-thread` |
| `update.md` | 체인지로그 표시와 함께 MSD를 최신 버전으로 업데이트. | `/msd-update` |
| `validate-phase.md` | 완료된 단계의 나이퀴스트 검증 공백을 소급 감사 및 채움. | `/msd-validate-phase` |
| `verify-work.md` | 자동 진단이 포함된 대화형 UAT — UAT.md 및 수정 계획 생성. | `/msd-verify-work` |
> **참고:** 일부 워크플로우는 직접적인 사용자 대면 명령어가 없습니다(예: `execute-plan.md`, `transition.md`, `node-repair.md`, `diagnose-issues.md`) — 이들은 오케스트레이터 워크플로우에 의해 내부적으로 호출됩니다.
@@ -266,7 +266,7 @@
## 레퍼런스 (62개 출시)
전체 목록은 `gsd-core/references/*.md`에 있습니다. 레퍼런스는 워크플로우와 에이전트가 `@-참조`하는 공유 지식 문서입니다. 아래 그룹화는 [`docs/ARCHITECTURE.md`](ARCHITECTURE.md#references-gsd-corereferencesmd) — 코어, 워크플로우, 씽킹 모델 클러스터, 모듈식 플래너 분해에 일치합니다.
전체 목록은 `msd-core/references/*.md`에 있습니다. 레퍼런스는 워크플로우와 에이전트가 `@-참조`하는 공유 지식 문서입니다. 아래 그룹화는 [`docs/ARCHITECTURE.md`](ARCHITECTURE.md#references-msd-corereferencesmd) — 코어, 워크플로우, 씽킹 모델 클러스터, 모듈식 플래너 분해에 일치합니다.
### 코어 레퍼런스
@@ -278,7 +278,7 @@
| `model-profile-resolution.md` | 모델 해석 알고리즘 문서. |
| `verification-patterns.md` | 다양한 아티팩트 유형 검증 방법. |
| `verification-overrides.md` | 아티팩트별 검증 재정의 규칙. |
| `verifier-phase-gates.md` | gsd-verifier가 즉시 로드하는 검증 시점 게이트(폐기된 verify-phase 워크플로우에서 이전, #1892): 의사결정 커버리지 검증(#2492), 테스트 품질 감사, 인프라 페이즈 human-verification 스코핑(#2504). | |
| `verifier-phase-gates.md` | msd-verifier가 즉시 로드하는 검증 시점 게이트(폐기된 verify-phase 워크플로우에서 이전, #1892): 의사결정 커버리지 검증(#2492), 테스트 품질 감사, 인프라 페이즈 human-verification 스코핑(#2504). | |
| `planning-config.md` | 전체 설정 스키마 및 동작. |
| `git-integration.md` | Git 커밋, 브랜칭, 히스토리 패턴. |
| `git-planning-commit.md` | 계획 디렉터리 커밋 관례. |
@@ -286,7 +286,7 @@
| `tdd.md` | 테스트 주도 개발 통합 패턴. |
| `ui-brand.md` | 시각적 출력 포매팅 패턴. |
| `common-bug-patterns.md` | 코드 리뷰 및 검증을 위한 일반적인 버그 패턴. |
| `debugger-philosophy.md` | `gsd-debugger`가 로드하는 상시 디버깅 원칙. |
| `debugger-philosophy.md` | `msd-debugger`가 로드하는 상시 디버깅 원칙. |
| `mandatory-initial-read.md` | 에이전트 프롬프트에 주입되는 공유 필수 읽기 상용구. |
| `project-skills-discovery.md` | 에이전트 프롬프트에 주입되는 공유 프로젝트 스킬 발견 상용구. |
@@ -311,9 +311,9 @@
| `thinking-partner.md` | 결정 시점에서의 조건부 씽킹 파트너 활성화. |
| `autonomous-smart-discuss.md` | 자율 모드를 위한 스마트 discuss 로직. |
| `ios-scaffold.md` | iOS 애플리케이션 스캐폴딩 패턴. |
| `ai-evals.md` | `/gsd-ai-integration-phase`를 위한 AI 평가 설계 레퍼런스. |
| `ai-frameworks.md` | `gsd-framework-selector`를 위한 AI 프레임워크 결정 매트릭스 레퍼런스. |
| `executor-examples.md` | gsd-executor 에이전트를 위한 작업 예시. |
| `ai-evals.md` | `/msd-ai-integration-phase`를 위한 AI 평가 설계 레퍼런스. |
| `ai-frameworks.md` | `msd-framework-selector`를 위한 AI 프레임워크 결정 매트릭스 레퍼런스. |
| `executor-examples.md` | msd-executor 에이전트를 위한 작업 예시. |
| `doc-conflict-engine.md` | ingest/import 워크플로우를 위한 공유 충돌 감지 계약. |
| `execute-mvp-tdd.md` | MVP+TDD 하의 execute-phase 런타임 게이트 시맨틱 — 태스크 전 실패 테스트 검증, 단계 말 차단 리뷰. |
| `mvp-concepts.md` | 6개 MVP 관련 레퍼런스 파일에 대한 교차 참조 색인; 각 파일의 목적과 어떤 워크플로우가 로드하는지 매핑. |
@@ -321,7 +321,7 @@
### 스케치 레퍼런스
`/gsd-sketch` 워크플로우 및 그 wrap-up 동반자에 의해 사용되는 레퍼런스.
`/msd-sketch` 워크플로우 및 그 wrap-up 동반자에 의해 사용되는 레퍼런스.
| 레퍼런스 | 역할 |
|-----------|------|
@@ -332,7 +332,7 @@
### 씽킹 모델 레퍼런스
씽킹 클래스 모델(o3, o4-mini, Gemini 2.5 Pro)을 GSD 워크플로우에 통합하기 위한 레퍼런스.
씽킹 클래스 모델(o3, o4-mini, Gemini 2.5 Pro)을 MSD 워크플로우에 통합하기 위한 레퍼런스.
| 레퍼런스 | 역할 |
|-----------|------|
@@ -344,14 +344,14 @@
### 모듈식 플래너 분해
`gsd-planner` 에이전트는 런타임 문자 제한에 맞추기 위해 코어 에이전트와 레퍼런스 모듈로 분해됩니다.
`msd-planner` 에이전트는 런타임 문자 제한에 맞추기 위해 코어 에이전트와 레퍼런스 모듈로 분해됩니다.
| 레퍼런스 | 역할 |
|-----------|------|
| `planner-antipatterns.md` | 플래너 안티패턴 및 구체성 예시. |
| `planner-chunked.md` | Windows stdio 멈춤 완화를 위한 청크 모드 반환 형식(`## OUTLINE COMPLETE`, `## PLAN COMPLETE`). |
| `planner-gap-closure.md` | 공백 채움 모드 동작(VERIFICATION.md 읽기, 타겟 재계획). |
| `planner-reviews.md` | 교차 AI 리뷰 통합(`/gsd-review`에서 REVIEWS.md 읽기). |
| `planner-reviews.md` | 교차 AI 리뷰 통합(`/msd-review`에서 REVIEWS.md 읽기). |
| `planner-revision.md` | 반복적 정제를 위한 계획 수정 패턴. |
| `planner-source-audit.md` | 플래너 소스 감사 및 권한 제한 규칙. |
| `planner-mvp-mode.md` | MVP 모드를 위한 수직 슬라이스 계획 규칙. |
@@ -362,26 +362,26 @@
| `user-story-template.md` | MVP 계획을 위한 사용자 스토리 형식 — "As a / I want to / So that" 구조화된 필드. |
| `spidr-splitting.md` | MVP 모드에서 큰 사용자 스토리 처리를 위한 SPIDR 분할 분해 규칙. |
> **하위 디렉터리:** `gsd-core/references/few-shot-examples/`에는 특정 에이전트에서 참조되는 추가 퓨샷 예시(`plan-checker.md`, `verifier.md`)가 포함되어 있습니다. 이들은 62개 최상위 레퍼런스 수에 포함되지 않습니다.
> **하위 디렉터리:** `msd-core/references/few-shot-examples/`에는 특정 에이전트에서 참조되는 추가 퓨샷 예시(`plan-checker.md`, `verifier.md`)가 포함되어 있습니다. 이들은 62개 최상위 레퍼런스 수에 포함되지 않습니다.
---
## CLI 모듈 (81개 출시)
전체 목록: `gsd-core/bin/lib/*.cjs`.
전체 목록: `msd-core/bin/lib/*.cjs`.
| 모듈 | 책임 |
|--------|----------------|
| `active-workstream-store.cjs` | 워크스트림 소스 우선순위 및 선택(CLI `--ws` > `GSD_WORKSTREAM` 환경 변수 > 저장된 포인터); 이름 검증 및 환경 전파 |
| `active-workstream-store.cjs` | 워크스트림 소스 우선순위 및 선택(CLI `--ws` > `MSD_WORKSTREAM` 환경 변수 > 저장된 포인터); 이름 검증 및 환경 전파 |
| `adr-parser.cjs` | plan-phase 수집 익스프레스 경로를 위한 ADR 결정 파서; 섹션 동의어 정규화, 상태/결정/범위 펜스 파싱, 상태 거부 게이트 적용 |
| `agent-command-router.cjs` | `gsd-tools agent`를 위한 얇은 CJS 하위 명령어 라우터 어댑터 |
| `artifacts.cjs` | 표준 아티팩트 레지스트리 — 알려진 `.planning/` 루트 파일 이름; `gsd-health` W019 린트에 사용 |
| `agent-command-router.cjs` | `msd-tools agent`를 위한 얇은 CJS 하위 명령어 라우터 어댑터 |
| `artifacts.cjs` | 표준 아티팩트 레지스트리 — 알려진 `.planning/` 루트 파일 이름; `msd-health` W019 린트에 사용 |
| `audit.cjs` | 감사 디스패치, 열린 감사 세션, 감사 스토리지 헬퍼 |
| `check-command-router.cjs` | `gsd-tools check`를 위한 얇은 CJS 하위 명령어 라우터 어댑터 |
| `check-command-router.cjs` | `msd-tools check`를 위한 얇은 CJS 하위 명령어 라우터 어댑터 |
| `cjs-command-router-adapter.cjs` | 매니페스트 기반 CJS 명령어 패밀리 라우터를 위한 공유 호환성 어댑터 |
| `clock.cjs` | 결정론적 잠금 테스트를 위한 주입 가능한 클록 심(now/sleep) |
| `clusters.cjs` | 런타임 표면 모듈을 위한 스킬 클러스터 정의(ADR-0011 Phase 2) |
| `code-review-flags.cjs` | `/gsd-code-review`를 위한 타입 플래그 파서; `parseCodeReviewFlags(argv)` (→ `{ fix, all, auto, depth, files }`) 및 `resolveCodeReviewWorkflow(flags)` (→ `'code-review.md' \| 'code-review-fix.md'`) 내보내기; `--fix`/`--all`/`--auto` 라우팅을 위한 표준 디스패치 심 |
| `code-review-flags.cjs` | `/msd-code-review`를 위한 타입 플래그 파서; `parseCodeReviewFlags(argv)` (→ `{ fix, all, auto, depth, files }`) 및 `resolveCodeReviewWorkflow(flags)` (→ `'code-review.md' \| 'code-review-fix.md'`) 내보내기; `--fix`/`--all`/`--auto` 라우팅을 위한 표준 디스패치 심 |
| `command-aliases.cjs` | 매니페스트 기반 패밀리 라우터를 위한 별칭/하위 명령어 메타데이터 |
| `command-arg-projection.cjs` | 명령어 패밀리 라우터 전반에 공유되는 타입 플래그 및 위치 인수 프로젝션 헬퍼 |
| `command-routing-hub.cjs` | 모든 명령어 패밀리 라우터를 위한 모드 결정(SDK vs CJS), 오류 분류, 예외 없음 계약을 집중화하는 순수 결과 디스패치 허브(#3788) |
@@ -390,63 +390,63 @@
| `config.cjs` | `config.json` 읽기/쓰기, 섹션 초기화; `config-schema.cjs`에서 유효성 검사기 가져옴 |
| `config-types.cjs` | `model_policy` 설정 블록을 위한 TypeScript 타입 정의 — `ModelPolicyConfig`, `TierEntry`, `RuntimeTiers`; 게시 시 `src/config-types.cts`에서 컴파일됨(ADR-457) |
| `configuration.cjs` | 설정 모듈 — 표준 설정 로딩, 레거시 키 정규화, 기본값 병합, 명시적 온디스크 마이그레이션; SDK 및 CJS 소비자 모두를 위한 진실 소스 |
| `context-utilization.cjs` | `gsd-health --context`를 위한 순수 분류기 — (tokensUsed, contextWindow)를 60%/70% 파단점 임계값에 대한 `{ percent, state }` 트리아지 결과로 변환(#2792) |
| `context-utilization.cjs` | `msd-health --context`를 위한 순수 분류기 — (tokensUsed, contextWindow)를 60%/70% 파단점 임계값에 대한 `{ percent, state }` 트리아지 결과로 변환(#2792) |
| `core.cjs` | 오류 처리, 출력 포매팅, 공유 유틸리티, 런타임 폴백; 계획 워크스페이스 헬퍼를 위한 호환성 재내보내기 |
| `decisions.cjs` | CONTEXT.md `<decisions>` 블록 파싱; 숫자형(D-42) 및 영숫자형(D-INFRA-01) ID 허용; `{id, text, category, tags, trackable}` 반환 |
| `docs.cjs` | 문서 업데이트 워크플로우 초기화, 마크다운 스캔, 모노레포 감지 |
| `drift.cjs` | 실행 후 코드베이스 구조 드리프트 감지기(#2003): 파일 변경을 new-dir/barrel/migration/route 카테고리로 분류하고 `last_mapped_commit` 프론트매터를 왕복 처리 |
| `fallow-runner.cjs` | `/gsd-code-review`를 위한 Fallow 감사 어댑터: 바이너리 해석(`node_modules/.bin` 이후 `PATH`), 실행 가능한 누락 바이너리 오류, 구조적 결과 정규화 |
| `fallow-runner.cjs` | `/msd-code-review`를 위한 Fallow 감사 어댑터: 바이너리 해석(`node_modules/.bin` 이후 `PATH`), 실행 가능한 누락 바이너리 오류, 구조적 결과 정규화 |
| `frontmatter.cjs` | YAML 프론트매터 CRUD 작업 |
| `gap-checker.cjs` | 계획 후 공백 분석(#2493): REQUIREMENTS.md + CONTEXT.md 결정 대 PLAN.md 커버리지 보고서(`gsd-tools gap-analysis`) |
| `graphify.cjs` | `/gsd-graphify`를 위한 지식 그래프 빌드/쿼리/상태/비교 |
| `gsd2-import.cjs` | `/gsd-import --from-gsd2`를 위한 외부 계획 수집 |
| `init-command-router.cjs` | `gsd-tools init`을 위한 얇은 CJS 하위 명령어 라우터 어댑터 |
| `gap-checker.cjs` | 계획 후 공백 분석(#2493): REQUIREMENTS.md + CONTEXT.md 결정 대 PLAN.md 커버리지 보고서(`msd-tools gap-analysis`) |
| `graphify.cjs` | `/msd-graphify`를 위한 지식 그래프 빌드/쿼리/상태/비교 |
| `gsd2-import.cjs` | `/msd-import --from-gsd2`를 위한 외부 계획 수집 |
| `init-command-router.cjs` | `msd-tools init`을 위한 얇은 CJS 하위 명령어 라우터 어댑터 |
| `init.cjs` | 각 워크플로우 유형을 위한 복합 컨텍스트 로딩 |
| `install-profiles.cjs` | `--minimal` 설치를 위한 설치 프로필 허용 목록 + 스킬 스테이징(#2762); 런타임 설정 디렉터리에 어떤 `gsd-*` 스킬/에이전트가 배치되는지에 대한 단일 진실 소스 |
| `install-profiles.cjs` | `--minimal` 설치를 위한 설치 프로필 허용 목록 + 스킬 스테이징(#2762); 런타임 설정 디렉터리에 어떤 `msd-*` 스킬/에이전트가 배치되는지에 대한 단일 진실 소스 |
| `installer-migration-authoring.cjs` | 레코드 메타데이터, 명시적 범위, 소유권 증거, 런타임 계약 인용을 위한 설치 마이그레이션 저작 가드레일 |
| `installer-migration-report.cjs` | 설치/업데이트 통합을 위한 설치 마이그레이션 보고서 프로젝션 및 차단 액션 가드 |
| `installer-migrations.cjs` | 설치 마이그레이션 계획, 아티팩트 분류, 설치 상태 지속성, 저널 적용, 롤백 헬퍼 |
| `intel.cjs` | `/gsd-map-codebase --query` 및 `gsd-intel-updater`를 지원하는 코드베이스 인텔 스토어 |
| `learnings.cjs` | `/gsd-extract-learnings`를 위한 단계 간 학습 추출 |
| `intel.cjs` | `/msd-map-codebase --query` 및 `msd-intel-updater`를 지원하는 코드베이스 인텔 스토어 |
| `learnings.cjs` | `/msd-extract-learnings`를 위한 단계 간 학습 추출 |
| `milestone.cjs` | 마일스톤 아카이브, 요구사항 마킹 |
| `model-catalog.cjs` | 공유 모델 카탈로그 JSON에 대한 CJS 어댑터; 모든 CLI 소비자를 위한 표준 런타임 티어 기본값, 에이전트 프로필 맵, 별칭 맵, 라우팅 메타데이터 내보내기 |
| `model-profiles.cjs` | `model-catalog.cjs`에서 파생된 하위 호환 프로필 헬퍼; 더 이상 자체 모델 테이블을 소유하지 않음 |
| `package-identity.cjs` | GSD의 게시된 패키지 좌표(npm 이름, bin 이름, 저장소 슬러그, 체인지로그 URL, 수동 설치 명령어)를 위한 생성된 단일 소스, package.json에서 파생; 업데이트 워커, `check-latest-version`, 설치 프로그램에서 읽음(#498) |
| `phase-command-router.cjs` | `gsd-tools phase`를 위한 얇은 CJS 하위 명령어 라우터 어댑터 |
| `package-identity.cjs` | MSD의 게시된 패키지 좌표(npm 이름, bin 이름, 저장소 슬러그, 체인지로그 URL, 수동 설치 명령어)를 위한 생성된 단일 소스, package.json에서 파생; 업데이트 워커, `check-latest-version`, 설치 프로그램에서 읽음(#498) |
| `phase-command-router.cjs` | `msd-tools phase`를 위한 얇은 CJS 하위 명령어 라우터 어댑터 |
| `phase-lifecycle.cjs` | 단계 라이프사이클 SDK 핸들러에서 추출된 순수 계산 단계 라이프사이클 헬퍼 |
| `phase.cjs` | 단계 디렉터리 작업, 소수점 번호 체계, 계획 인덱싱 |
| `phases-command-router.cjs` | `gsd-tools phases`를 위한 얇은 CJS 하위 명령어 라우터 어댑터 |
| `phases-command-router.cjs` | `msd-tools phases`를 위한 얇은 CJS 하위 명령어 라우터 어댑터 |
| `plan-scan.cjs` | 플랫 및 중첩 레이아웃에서 계획 및 요약 파일을 감지하는 표준 단계 계획 스캐너(k014) |
| `planning-workspace.cjs` | 계획 경로/워크스트림 심(`planningDir`, `planningPaths`, 활성 워크스트림 라우팅, `.planning/.lock` 오케스트레이션) |
| `project-root.cjs` | 4가지 휴리스틱(자체 `.planning/` 가드, `sub_repos` 설정, `multiRepo` 플래그, `.git` 휴리스틱)을 사용하여 시작 디렉터리에서 프로젝트 루트 해석 |
| `profile-output.cjs` | 프로필 렌더링, USER-PROFILE.md 및 dev-preferences.md 생성 |
| `profile-pipeline.cjs` | 사용자 행동 프로파일링 데이터 파이프라인, 세션 파일 스캔 |
| `prompt-budget.cjs` | 리뷰 프롬프트를 위한 순수 토큰 예산 계산 — 토큰 추정, 결정론적 트림 우선순위 적용(헤드 수축 PROJECT.md, 비례 계획 잘라내기, 컨텍스트/조사/요구사항 삭제, 하드 실패 가드), `review.max_prompt_tokens`를 위한 구조화된 메타데이터 반환(#3081) |
| `review-reviewer-selection.cjs` | `/gsd-review` 기본 리뷰어 정책 및 우선순위를 위한 리뷰어 선택/정규화 헬퍼 |
| `roadmap-command-router.cjs` | `gsd-tools roadmap`을 위한 얇은 CJS 하위 명령어 라우터 어댑터 |
| `review-reviewer-selection.cjs` | `/msd-review` 기본 리뷰어 정책 및 우선순위를 위한 리뷰어 선택/정규화 헬퍼 |
| `roadmap-command-router.cjs` | `msd-tools roadmap`을 위한 얇은 CJS 하위 명령어 라우터 어댑터 |
| `roadmap-upgrade.cjs` | 레거시 `Phase N` 항목을 마일스톤 접두사 `Phase M-NN` 관례로 변환하는 마이그레이션 도구; 드라이런 기본값 및 원자적 롤백이 있는 `computeMigrationPlan` + `applyMigration` |
| `roadmap.cjs` | ROADMAP.md 파싱, 단계 추출, 계획 진행도 |
| `runtime-artifact-layout.cjs` | 런타임 아티팩트 레이아웃 모듈 — 지원되는 각 런타임의 아티팩트 디렉터리 형태(명령어, 에이전트, 스킬) 해석; 런타임별 아티팩트 배치를 위한 단일 진실 소스(#3663) |
| `runtime-name-policy.cjs` | 런타임 이름 정규화 정책 — 경로 구성 및 표시에 사용되는 런타임 식별자를 위한 표준 토큰 위생 처리 |
| `runtime-homes.cjs` | 표준 런타임 → 전역 설정/스킬 디렉터리 매핑; Hermes 중첩 레이아웃 및 Cline 규칙 기반 제외를 포함한 15개 런타임에 대한 일급 지원(#3126) |
| `runtime-slash.cjs` | 런타임 인식 슬래시 명령어 포매터 — 사용자 대면 출력 및 영속 아티팩트에서 `/gsd-<cmd>`(스킬 기반 런타임) 및 `$gsd-<cmd>`(codex) 내보내기를 위한 단일 진실 소스(#3584) |
| `runtime-slash.cjs` | 런타임 인식 슬래시 명령어 포매터 — 사용자 대면 출력 및 영속 아티팩트에서 `/msd-<cmd>`(스킬 기반 런타임) 및 `$msd-<cmd>`(codex) 내보내기를 위한 단일 진실 소스(#3584) |
| `schema-detect.cjs` | ORM 패턴 스키마 드리프트 감지(Prisma, Drizzle, Supabase, TypeORM, Payload); `detectSchemaFiles`, `detectSchemaOrm`, `checkSchemaDrift`, `SCHEMA_PATTERNS`, `ORM_INFO` 내보내기 |
| `secrets.cjs` | 통합 키를 위한 시크릿 설정 마스킹 관례(`****<last-4>`); `SECRET_CONFIG_KEYS`, `isSecretKey`, `maskSecret`, `maskIfSecret` 내보내기 |
| `semver-compare.cjs` | 업데이트 확인 훅, 상태라인 개발 설치 감지, 체인지셋 추출 범위 로직에서 사용되는 공유 semver 비교 정책 헬퍼(`compareSemverCore`, 안정적인 트리플릿 검증, 정규화된 튜플 파싱)(#10) |
| `security.cjs` | 경로 순회 방지, 프롬프트 주입 감지, 안전한 JSON/셸 헬퍼 |
| `shell-command-projection.cjs` | 관리형 훅 직렬화를 위한 런타임 인식 셸 명령어 프로젝션: 런타임/플랫폼별 PowerShell 호출 연산자 사용 결정 및 Windows 스크립트 경로 토큰 정규화 |
| `state-command-router.cjs` | `gsd-tools state`를 위한 얇은 CJS 하위 명령어 라우터 어댑터 |
| `state-command-router.cjs` | `msd-tools state`를 위한 얇은 CJS 하위 명령어 라우터 어댑터 |
| `state.cjs` | STATE.md 파싱, 업데이트, 진행, 메트릭 |
| `state-document.cjs` | 순수 STATE.md 필드 추출, 교체, 상태 정규화, 진행도 계산 변환 |
| `surface.cjs` | 런타임 표면 모듈 — 설치 시 프로필 마커와 독립적으로 런타임 활성화/비활성화 표면 상태 관리(ADR-0011 Phase 2) |
| `task-command-router.cjs` | `gsd-tools task`를 위한 얇은 CJS 하위 명령어 라우터 어댑터 |
| `task-command-router.cjs` | `msd-tools task`를 위한 얇은 CJS 하위 명령어 라우터 어댑터 |
| `template.cjs` | 변수 치환을 통한 템플릿 선택 및 채우기 |
| `uat.cjs` | UAT 파일 파싱, 검증 부채 추적, audit-uat 지원 |
| `ui-safety-gate.cjs` | 셸 없는 단어 경계 UI 토큰 감지기(#3706, #3718); stdin에서 단계 섹션 텍스트를 읽어 0(UI 발견) 또는 1(UI 없음) 종료; GSD 설치 프로그램이 `$RUNTIME_DIR`에 배포하도록 `gsd-core/bin/lib/`에도 배포 |
| `update-context.cjs` | `/gsd-update`를 위한 순수 설치 컨텍스트 해석기 — update.md bash에서 포팅된 런타임/범위/설정 디렉터리/버전 감지(LOCAL/GLOBAL/UNKNOWN); `gsd-tools update-context` 지원(#498) |
| `validate-command-router.cjs` | `gsd-tools validate`를 위한 얇은 CJS 하위 명령어 라우터 어댑터 |
| `ui-safety-gate.cjs` | 셸 없는 단어 경계 UI 토큰 감지기(#3706, #3718); stdin에서 단계 섹션 텍스트를 읽어 0(UI 발견) 또는 1(UI 없음) 종료; MSD 설치 프로그램이 `$RUNTIME_DIR`에 배포하도록 `msd-core/bin/lib/`에도 배포 |
| `update-context.cjs` | `/msd-update`를 위한 순수 설치 컨텍스트 해석기 — update.md bash에서 포팅된 런타임/범위/설정 디렉터리/버전 감지(LOCAL/GLOBAL/UNKNOWN); `msd-tools update-context` 지원(#498) |
| `validate-command-router.cjs` | `msd-tools validate`를 위한 얇은 CJS 하위 명령어 라우터 어댑터 |
| `validate.cjs` | 순수 단계 변형 정규화 헬퍼(`phaseVariants`, `buildRoadmapPhaseVariants`, `buildNotStartedPhaseVariants`), W006/W007 확인을 위해 `verify.cjs`에서 사용; I/O 없음, 비동기 없음 |
| `verify-command-router.cjs` | `gsd-tools verify`를 위한 얇은 CJS 하위 명령어 라우터 어댑터 |
| `verify-command-router.cjs` | `msd-tools verify`를 위한 얇은 CJS 하위 명령어 라우터 어댑터 |
| `verify.cjs` | 계획 구조, 단계 완전성, 레퍼런스, 커밋 검증 |
| `workstream-inventory-builder.cjs` | 순수 워크스트림 인벤토리 프로젝션 빌더 |
| `workstream-inventory.cjs` | 공유 워크스트림 인벤토리 프로젝션: 상태 필드, 단계/계획/요약 수, 로드맵 단계 수, 활성 마커 — `workstream-inventory-builder.cjs`에 순수 프로젝션을 위임하는 얇은 오케스트레이터 |
@@ -464,23 +464,23 @@
| 훅 | 이벤트 | 목적 |
|------|-------|---------|
| `gsd-statusline.js` | `statusLine` | 모델, 태스크, 디렉터리, 컨텍스트 사용량 표시 |
| `gsd-context-monitor.js` | `PostToolUse` / `AfterTool` | 35%/25% 남은 시점에 에이전트 대면 컨텍스트 경고 주입 |
| `gsd-check-update.js` | `SessionStart` | 새 GSD 버전 백그라운드 확인 |
| `gsd-check-update-worker.js` | (worker) | check-update를 위한 백그라운드 워커 헬퍼 |
| `gsd-update-banner.js` | `SessionStart` | GSD 상태라인을 사용하지 않을 때 업데이트 가용성을 표면화하는 옵트인 배너(PR #2795) |
| `gsd-prompt-guard.js` | `PreToolUse` | `.planning/` 쓰기에서 프롬프트 주입 패턴 스캔 (어드바이저리) |
| `gsd-workflow-guard.js` | `PreToolUse` | GSD 워크플로우 컨텍스트 외부의 파일 편집 감지 (어드바이저리, 옵트인) |
| `gsd-read-guard.js` | `PreToolUse` | 읽지 않은 파일에 대한 Edit/Write를 방지하는 어드바이저리 가드 |
| `gsd-read-injection-scanner.js` | `PostToolUse` | 도구 Read 결과에서 프롬프트 주입 패턴 스캔 (v1.36+, PR #2201) |
| `gsd-worktree-path-guard.js` | `PreToolUse` | 워크트리 루트 외부의 절대 경로로 Edit/Write/MultiEdit를 하드 차단 (PR #579, #260) |
| `gsd-agent-isolation-guard.js` | `PreToolUse` | 프로젝트의 해석된 디스패치 격리가 `harness-worktree`일 때 하네스 격리 매개변수가 누락된 executor `Agent()` 디스패치를 하드 차단 (#3045) |
| `gsd-write-guard.js` | `PreToolUse` | 큐레이션된 `.planning/` 아티팩트(ROADMAP.md, 마일스톤 로드맵, STATE.md)를 치명적으로 축소하는 전체 파일 `Write`를 하드 차단. 일회용 센티널 `.planning/.gsd-allow-shrink`(워크플로 단계) 또는 `GSD_ALLOW_PLANNING_SHRINK=1`(대화형)로 우회 가능 (#2255, #973의 수정 3) |
| `gsd-secret-read-guard.js` | `PreToolUse` | Read / Grep / Bash로 `.env`, `.env.<suffix>`(`.env.example` 등 템플릿 제외), `.secrets`를 읽는 호출을 하드 차단. 설치 프로그램이 기록하던 `Read(.env*)` deny 규칙을 대체 (#4221) |
| `gsd-session-state.sh` | `SessionStart` | 셸 기반 런타임을 위한 세션 상태 추적 |
| `gsd-validate-commit.sh` | `PreToolUse` | 컨벤셔널 커밋 적용을 위한 커밋 검증 |
| `gsd-phase-boundary.sh` | `PostToolUse` | 워크플로우 전환을 위한 단계 경계 감지 |
| `gsd-graphify-update.sh` | `PostToolUse` | 메인 HEAD 진행 후 지식 그래프 자동 재빌드 (옵트인, 기본 비활성화 — #3347) |
| `msd-statusline.js` | `statusLine` | 모델, 태스크, 디렉터리, 컨텍스트 사용량 표시 |
| `msd-context-monitor.js` | `PostToolUse` / `AfterTool` | 35%/25% 남은 시점에 에이전트 대면 컨텍스트 경고 주입 |
| `msd-check-update.js` | `SessionStart` | 새 MSD 버전 백그라운드 확인 |
| `msd-check-update-worker.js` | (worker) | check-update를 위한 백그라운드 워커 헬퍼 |
| `msd-update-banner.js` | `SessionStart` | MSD 상태라인을 사용하지 않을 때 업데이트 가용성을 표면화하는 옵트인 배너(PR #2795) |
| `msd-prompt-guard.js` | `PreToolUse` | `.planning/` 쓰기에서 프롬프트 주입 패턴 스캔 (어드바이저리) |
| `msd-workflow-guard.js` | `PreToolUse` | MSD 워크플로우 컨텍스트 외부의 파일 편집 감지 (어드바이저리, 옵트인) |
| `msd-read-guard.js` | `PreToolUse` | 읽지 않은 파일에 대한 Edit/Write를 방지하는 어드바이저리 가드 |
| `msd-read-injection-scanner.js` | `PostToolUse` | 도구 Read 결과에서 프롬프트 주입 패턴 스캔 (v1.36+, PR #2201) |
| `msd-worktree-path-guard.js` | `PreToolUse` | 워크트리 루트 외부의 절대 경로로 Edit/Write/MultiEdit를 하드 차단 (PR #579, #260) |
| `msd-agent-isolation-guard.js` | `PreToolUse` | 프로젝트의 해석된 디스패치 격리가 `harness-worktree`일 때 하네스 격리 매개변수가 누락된 executor `Agent()` 디스패치를 하드 차단 (#3045) |
| `msd-write-guard.js` | `PreToolUse` | 큐레이션된 `.planning/` 아티팩트(ROADMAP.md, 마일스톤 로드맵, STATE.md)를 치명적으로 축소하는 전체 파일 `Write`를 하드 차단. 일회용 센티널 `.planning/.msd-allow-shrink`(워크플로 단계) 또는 `MSD_ALLOW_PLANNING_SHRINK=1`(대화형)로 우회 가능 (#2255, #973의 수정 3) |
| `msd-secret-read-guard.js` | `PreToolUse` | Read / Grep / Bash로 `.env`, `.env.<suffix>`(`.env.example` 등 템플릿 제외), `.secrets`를 읽는 호출을 하드 차단. 설치 프로그램이 기록하던 `Read(.env*)` deny 규칙을 대체 (#4221) |
| `msd-session-state.sh` | `SessionStart` | 셸 기반 런타임을 위한 세션 상태 추적 |
| `msd-validate-commit.sh` | `PreToolUse` | 컨벤셔널 커밋 적용을 위한 커밋 검증 |
| `msd-phase-boundary.sh` | `PostToolUse` | 워크플로우 전환을 위한 단계 경계 감지 |
| `msd-graphify-update.sh` | `PostToolUse` | 메인 HEAD 진행 후 지식 그래프 자동 재빌드 (옵트인, 기본 비활성화 — #3347) |
---

22
docs/ko-KR/README.md
View File

@@ -1,4 +1,4 @@
# GSD Core 문서
# MSD Core 문서
문서는 네 가지 유형으로 구성됩니다. **튜토리얼**은 직접 해보며 배우고, **how-to 가이드**는 특정 작업을 해결하며, **레퍼런스**는 권위 있는 사실을 제시하고, **설명**은 개념과 설계 결정을 탐구합니다.
@@ -9,7 +9,7 @@
## 튜토리얼
- [첫 번째 프로젝트](tutorials/your-first-project.md) — 설치부터 첫 단계 출시까지, 확실한 한 가지 경로
- [기존 코드베이스 온보딩](tutorials/onboarding-an-existing-codebase.md) — 기존 저장소에 GSD Core 적용하기
- [기존 코드베이스 온보딩](tutorials/onboarding-an-existing-codebase.md) — 기존 저장소에 MSD Core 적용하기
---
@@ -21,17 +21,17 @@
- [단계 실행하기](how-to/execute-a-phase.md) — 새 컨텍스트 서브에이전트로 병렬 웨이브 실행
- [검증 및 출시](how-to/verify-and-ship.md) — 완료된 작업 검토, 오류 진단, PR 생성
- [단계 자율 실행하기](how-to/run-phases-autonomously.md) — 무인 단계 실행을 위한 자율 모드 사용
- [빠른 임시 작업 처리](how-to/handle-quick-and-fast-tasks.md) — 단계 루프 외 임시 작업에 `/gsd-quick`과 `/gsd-fast` 활용
- [빠른 임시 작업 처리](how-to/handle-quick-and-fast-tasks.md) — 단계 루프 외 임시 작업에 `/msd-quick`과 `/msd-fast` 활용
- [모델 프로필 설정](how-to/configure-model-profiles.md) — 고품질, 균형, 예산 모델 티어 전환
- [크로스 AI 리뷰 설정](how-to/set-up-cross-ai-review.md) — 주 에이전트가 생성한 코드를 두 번째 AI가 검토하도록 설정
- [워크스트림으로 병렬 작업](how-to/work-in-parallel-with-workstreams.md) — 워크스트림을 사용해 독립적인 작업 라인 동시 실행
- [워크스페이스로 작업 격리](how-to/isolate-work-with-workspaces.md) — 워크스페이스로 실험적이거나 위험한 변경 사항 샌드박스 처리
- [실패한 실행 디버깅](how-to/debug-a-failed-execution.md) — 깨지거나 불완전한 단계 실행 진단 및 복구
- [스파이크와 스케치](how-to/spike-and-sketch.md) — 플랜 확정 전 탐색 작업에 `/gsd-spike`와 `/gsd-sketch` 활용
- [스파이크와 스케치](how-to/spike-and-sketch.md) — 플랜 확정 전 탐색 작업에 `/msd-spike`와 `/msd-sketch` 활용
- [UI 단계 설계](how-to/design-a-ui-phase.md) — 프론트엔드 및 시각적 작업에 UI 단계 루프 활용
- [트래커 이슈로 GSD 구동](how-to/drive-gsd-from-a-tracker-issue.md) — GitHub, Linear, Jira 이슈에서 단계 시작
- [GSD 2에서 마이그레이션](how-to/migrate-from-gsd-2.md) — 기존 GSD 2 프로젝트를 GSD Core로 업그레이드
- [GSD 업데이트](how-to/update-gsd.md) — 설치 프로그램을 재실행해 최신 릴리스 적용
- [트래커 이슈로 MSD 구동](how-to/drive-msd-from-a-tracker-issue.md) — GitHub, Linear, Jira 이슈에서 단계 시작
- [GSD 2에서 마이그레이션](how-to/migrate-from-gsd-2.md) — 기존 GSD 2 프로젝트를 MSD Core로 업그레이드
- [MSD 업데이트](how-to/update-msd.md) — 설치 프로그램을 재실행해 최신 릴리스 적용
- [복구 및 문제 해결](how-to/recover-and-troubleshoot.md) — 일반적인 문제 해결, 컨텍스트 재구축, 제거
---
@@ -40,7 +40,7 @@
- [명령어](COMMANDS.md) — 플래그와 예제가 포함된 모든 명령어
- [설정](CONFIGURATION.md) — 전체 설정 스키마, 모델 프로필, git 브랜칭 전략
- [CLI 도구](CLI-TOOLS.md) — 워크플로우와 에이전트를 위한 `gsd-tools.cjs` 프로그래밍 API
- [CLI 도구](CLI-TOOLS.md) — 워크플로우와 에이전트를 위한 `msd-tools.cjs` 프로그래밍 API
- [기능](FEATURES.md) — 전체 기능 색인
- [인벤토리](INVENTORY.md) — 설치된 스킬과 서피스 맵
- [STATE.md 스키마](reference/state-md.md) — `.planning/STATE.md` 필드별 레퍼런스
@@ -52,14 +52,14 @@
## 설명
- [컨텍스트 엔지니어링](explanation/context-engineering.md) — 컨텍스트 rot가 형성되는 방식과 GSD Core의 방지 방법
- [컨텍스트 엔지니어링](explanation/context-engineering.md) — 컨텍스트 rot가 형성되는 방식과 MSD Core의 방지 방법
- [단계 루프](explanation/the-phase-loop.md) — 논의 → 기획 → 실행 → 검증 → 출시 사이클의 설계 근거
- [멀티 에이전트 오케스트레이션](explanation/multi-agent-orchestration.md) — 서브에이전트의 생성, 범위 지정, 조율 방식
- [보안 모델](explanation/security-model.md) — 신뢰 경계, 권한, 안전한 자동화
- [아키텍처](ARCHITECTURE.md) — 시스템 아키텍처, 에이전트 모델, 데이터 흐름
- [논의 모드](workflow-discuss-mode.md) — `/gsd-discuss-phase`의 가정 모드와 인터뷰 모드
- [논의 모드](workflow-discuss-mode.md) — `/msd-discuss-phase`의 가정 모드와 인터뷰 모드
- [컨텍스트 모니터링](context-monitor.md) — 컨텍스트 창 모니터링 훅 아키텍처
- [이슈 기반 오케스트레이션](issue-driven-orchestration.md) — 기존 프리미티브를 사용해 트래커 이슈로 GSD를 구동하는 레시피
- [이슈 기반 오케스트레이션](issue-driven-orchestration.md) — 기존 프리미티브를 사용해 트래커 이슈로 MSD를 구동하는 레시피
---

350
docs/ko-KR/USER-GUIDE.md
View File

@@ -1,8 +1,8 @@
# GSD 사용자 가이드
# MSD 사용자 가이드
GSD Core의 설명형 동반 가이드 — 여기서 방향을 잡은 후 전용 문서로 이동하세요.
MSD Core의 설명형 동반 가이드 — 여기서 방향을 잡은 후 전용 문서로 이동하세요.
> **GSD Core의 문서는 [Diataxis](https://diataxis.fr) 방식으로 구성되어 있습니다.**
> **MSD Core의 문서는 [Diataxis](https://diataxis.fr) 방식으로 구성되어 있습니다.**
> 목적별 탐색: [튜토리얼](README.md#tutorials) · [사용 방법 가이드](README.md#how-to-guides) · [레퍼런스](README.md#reference) · [설명](README.md#explanation) · [문서 인덱스](README.md)
---
@@ -10,7 +10,7 @@ GSD Core의 설명형 동반 가이드 — 여기서 방향을 잡은 후 전용
## 목차
- [슬래시 명령어 형식](#슬래시-명령어-형식)
- [네임스페이스 라우팅 입문](#네임스페이스-라우팅-입문-gsdnamespace-v140)
- [네임스페이스 라우팅 입문](#네임스페이스-라우팅-입문-msdnamespace-v140)
- [프로젝트 생명주기 개요](#프로젝트-생명주기-개요)
- [워크플로우 다이어그램](#워크플로우-다이어그램)
- [UI 설계 계약](#ui-설계-계약)
@@ -24,41 +24,41 @@ GSD Core의 설명형 동반 가이드 — 여기서 방향을 잡은 후 전용
- [프로젝트 파일 구조](#프로젝트-파일-구조)
- [관련 문서](#관련-문서)
GitHub / Linear / Jira 이슈에서 GSD를 직접 구동하는 방법은
GitHub / Linear / Jira 이슈에서 MSD를 직접 구동하는 방법은
[이슈 기반 오케스트레이션](issue-driven-orchestration.md) 가이드를 참조하세요 —
트래커 이슈를 workspace → discuss → plan → execute → verify → review → ship
루프에 매핑하는 레시피이며, 기존 GSD 프리미티브를 활용합니다.
루프에 매핑하는 레시피이며, 기존 MSD 프리미티브를 활용합니다.
---
## 슬래시 명령어 형식
GSD는 지원되는 모든 런타임에 **동일한 스킬 세트**를 제공하며, 하이픈 형식의 슬래시 표기를 사용합니다:
MSD는 지원되는 모든 런타임에 **동일한 스킬 세트**를 제공하며, 하이픈 형식의 슬래시 표기를 사용합니다:
- **하이픈 형식** — `/gsd-command-name` — Claude Code, Copilot, OpenCode, Kilo, Cursor, Windsurf, Augment, Antigravity, Trae에서 사용됩니다.
- **하이픈 형식** — `/msd-command-name` — Claude Code, Copilot, OpenCode, Kilo, Cursor, Windsurf, Augment, Antigravity, Trae에서 사용됩니다.
설치 프로그램은 사용자가 대상으로 하는 각 런타임의 명령어 디렉터리에 이 형식을 작성합니다.
## 네임스페이스 라우팅 입문 (`gsd:<namespace>`, v1.40)
## 네임스페이스 라우팅 입문 (`msd:<namespace>`, v1.40)
v1.40은 계층적 라우팅의 1단계 진입점으로 여섯 개의 **네임스페이스 메타스킬**을 제공합니다 — 이 스킬들은 열심히 스킬 목록을 나열하는 토큰 비용을 낮게 유지합니다(6개 라우터에 ~120 토큰 vs 86개 스킬 평면 목록에 ~2,150 토큰). 모든 구체적인 서브스킬은 여전히 직접 호출할 수 있습니다. 각 네임스페이스 라우터의 본문에는 사용자의 의도를 올바른 구체적 서브스킬로 매핑하는 라우팅 테이블이 포함되어 있습니다.
| 네임스페이스 | 라우터 | 라우팅 대상 |
|-----------|--------|-----------|
| 단계 파이프라인 | `/gsd-workflow` | discuss / plan / execute / verify / phase / progress |
| 프로젝트 생명주기 | `/gsd-project` | milestones, audits, summary |
| 품질 게이트 | `/gsd-quality` | code review, debug, audit, security, eval, ui |
| 코드베이스 인텔리전스 | `/gsd-context` | map, graphify, docs, learnings |
| 관리 | `/gsd-manage` | config, workspace, workstreams, thread, update, ship, inbox |
| 탐색 및 캡처 | `/gsd-ideate` | explore, sketch, spike, spec, capture |
| 단계 파이프라인 | `/msd-workflow` | discuss / plan / execute / verify / phase / progress |
| 프로젝트 생명주기 | `/msd-project` | milestones, audits, summary |
| 품질 게이트 | `/msd-quality` | code review, debug, audit, security, eval, ui |
| 코드베이스 인텔리전스 | `/msd-context` | map, graphify, docs, learnings |
| 관리 | `/msd-manage` | config, workspace, workstreams, thread, update, ship, inbox |
| 탐색 및 캡처 | `/msd-ideate` | explore, sketch, spike, spec, capture |
네임스페이스 라우터를 직접 입력할 필요는 거의 없습니다. 이들의 가치는 모델이 올바른 서브스킬을 찾는 데 사용하는 라우팅 레이어에 있습니다 — 시스템 프롬프트가 86개 대신 6개 항목을 나열할 수 있도록 존재합니다. 구체적인 명령어를 이미 알고 있다면(예: `/gsd-plan-phase`) 직접 호출하세요.
네임스페이스 라우터를 직접 입력할 필요는 거의 없습니다. 이들의 가치는 모델이 올바른 서브스킬을 찾는 데 사용하는 라우팅 레이어에 있습니다 — 시스템 프롬프트가 86개 대신 6개 항목을 나열할 수 있도록 존재합니다. 구체적인 명령어를 이미 알고 있다면(예: `/msd-plan-phase`) 직접 호출하세요.
---
## 프로젝트 생명주기 개요
GSD 핵심 루프는 **discuss → plan → execute → verify → ship**이며, 단계별로 반복됩니다. 전체 단계별 안내 — 출력 예시, 생성되는 파일, 사용 가능한 모든 플래그 포함 — 는 전용 튜토리얼에 있습니다.
MSD 핵심 루프는 **discuss → plan → execute → verify → ship**이며, 단계별로 반복됩니다. 전체 단계별 안내 — 출력 예시, 생성되는 파일, 사용 가능한 모든 플래그 포함 — 는 전용 튜토리얼에 있습니다.
[첫 번째 프로젝트](tutorials/your-first-project.md)를 참조하세요.
@@ -68,12 +68,12 @@ GSD 핵심 루프는 **discuss → plan → execute → verify → ship**이며,
| 플래그 | 명령어 | 사용 시점 |
| ---- | ------- | ----------- |
| `--auto` | `/gsd-new-project` | 대화형 질문을 건너뛰고 PRD 파일에서 가져오기 |
| `--research` | `/gsd-quick` | 임시 작업에 리서치 에이전트 추가 |
| `--validate` | `/gsd-quick` | 계획 검사 및 실행 후 검증 추가 |
| `--chain` | `/gsd-discuss-phase` | 중단 없이 discuss → plan → execute 자동 연결 |
| `--skip-research` | `/gsd-plan-phase` | 도메인이 이미 익숙할 때 리서치 에이전트 건너뛰기 |
| `--draft` | `/gsd-ship` | 검토 준비 대신 초안 PR 생성 |
| `--auto` | `/msd-new-project` | 대화형 질문을 건너뛰고 PRD 파일에서 가져오기 |
| `--research` | `/msd-quick` | 임시 작업에 리서치 에이전트 추가 |
| `--validate` | `/msd-quick` | 계획 검사 및 실행 후 검증 추가 |
| `--chain` | `/msd-discuss-phase` | 중단 없이 discuss → plan → execute 자동 연결 |
| `--skip-research` | `/msd-plan-phase` | 도메인이 이미 익숙할 때 리서치 에이전트 건너뛰기 |
| `--draft` | `/msd-ship` | 검토 준비 대신 초안 PR 생성 |
모든 플래그가 포함된 전체 명령어 레퍼런스는 [`docs/COMMANDS.md`](COMMANDS.md)를 참조하세요. 구성 옵션(모델 프로필, 워크플로우 에이전트, git 브랜치)은 [`docs/CONFIGURATION.md`](CONFIGURATION.md)를 참조하세요.
@@ -86,7 +86,7 @@ GSD 핵심 루프는 **discuss → plan → execute → verify → ship**이며,
```text
┌──────────────────────────────────────────────────┐
│ NEW PROJECT │
│ /gsd-new-project │
│ /msd-new-project │
│ Questions -> Research -> Requirements -> Roadmap│
└─────────────────────────┬────────────────────────┘
│
@@ -94,27 +94,27 @@ GSD 핵심 루프는 **discuss → plan → execute → verify → ship**이며,
│ FOR EACH PHASE: │
│ │
│ ┌────────────────────┐ │
│ │ /gsd-discuss-phase │ │ <- Lock in preferences
│ │ /msd-discuss-phase │ │ <- Lock in preferences
│ └──────────┬─────────┘ │
│ │ │
│ ┌──────────▼─────────┐ │
│ │ /gsd-ui-phase │ │ <- Design contract (frontend)
│ │ /msd-ui-phase │ │ <- Design contract (frontend)
│ └──────────┬─────────┘ │
│ │ │
│ ┌──────────▼─────────┐ │
│ │ /gsd-plan-phase │ │ <- Research + Plan + Verify
│ │ /msd-plan-phase │ │ <- Research + Plan + Verify
│ └──────────┬─────────┘ │
│ │ │
│ ┌──────────▼─────────┐ │
│ │ /gsd-execute-phase │ │ <- Parallel execution
│ │ /msd-execute-phase │ │ <- Parallel execution
│ └──────────┬─────────┘ │
│ │ │
│ ┌──────────▼─────────┐ │
│ │ /gsd-verify-work │ │ <- Manual UAT
│ │ /msd-verify-work │ │ <- Manual UAT
│ └──────────┬─────────┘ │
│ │ │
│ ┌──────────▼─────────┐ │
│ │ /gsd-ship │ │ <- Create PR (optional)
│ │ /msd-ship │ │ <- Create PR (optional)
│ └──────────┬─────────┘ │
│ │ │
│ Next Phase?────────────┘
@@ -122,8 +122,8 @@ GSD 핵심 루프는 **discuss → plan → execute → verify → ship**이며,
└─────────────┼──────────────┘
│
┌───────────────▼──────────────┐
│ /gsd-audit-milestone │
│ /gsd-complete-milestone │
│ /msd-audit-milestone │
│ /msd-complete-milestone │
└───────────────┬──────────────┘
│
Another milestone?
@@ -131,14 +131,14 @@ GSD 핵심 루프는 **discuss → plan → execute → verify → ship**이며,
Yes No -> Done!
│
┌───────▼──────────────┐
│ /gsd-new-milestone │
│ /msd-new-milestone │
└──────────────────────┘
```
### 계획 에이전트 조정
```text
/gsd-plan-phase N
/msd-plan-phase N
│
├── Phase Researcher (x4 parallel)
│ ├── Stack researcher
@@ -171,18 +171,18 @@ GSD 핵심 루프는 **discuss → plan → execute → verify → ship**이며,
### 검증 아키텍처 (나이퀴스트 레이어)
계획 단계 리서치 시, GSD는 코드 작성 전에 자동화된 테스트 커버리지를 각 단계 요구사항에 매핑합니다. 리서처는 기존 테스트 인프라를 감지하고, 각 요구사항을 특정 테스트 명령어에 매핑하며, 구현 시작 전에 생성해야 할 테스트 스캐폴딩(Wave 0 작업)을 식별합니다. 계획 검사기는 이를 8번째 검증 차원으로 적용합니다: 작업에 자동화된 검증 명령어가 없는 계획은 승인되지 않습니다.
계획 단계 리서치 시, MSD는 코드 작성 전에 자동화된 테스트 커버리지를 각 단계 요구사항에 매핑합니다. 리서처는 기존 테스트 인프라를 감지하고, 각 요구사항을 특정 테스트 명령어에 매핑하며, 구현 시작 전에 생성해야 할 테스트 스캐폴딩(Wave 0 작업)을 식별합니다. 계획 검사기는 이를 8번째 검증 차원으로 적용합니다: 작업에 자동화된 검증 명령어가 없는 계획은 승인되지 않습니다.
**출력:** `{phase}-VALIDATION.md` — 단계의 피드백 계약.
**비활성화:** 테스트 인프라가 초점이 아닌 빠른 프로토타이핑 단계에서는 `/gsd-settings`에서 `workflow.nyquist_validation: false`로 설정하세요.
**비활성화:** 테스트 인프라가 초점이 아닌 빠른 프로토타이핑 단계에서는 `/msd-settings`에서 `workflow.nyquist_validation: false`로 설정하세요.
### 소급 검증 (`/gsd-validate-phase`)
### 소급 검증 (`/msd-validate-phase`)
나이퀴스트 검증이 생기기 전에 실행된 단계, 또는 전통적인 테스트 슈트만 있는 기존 코드베이스에 대해 소급 감사 및 커버리지 간격을 채우세요:
```text
/gsd-validate-phase N
/msd-validate-phase N
|
+-- Detect state (VALIDATION.md exists? SUMMARY.md exists?)
|
@@ -204,9 +204,9 @@ GSD 핵심 루프는 **discuss → plan → execute → verify → ship**이며,
### 가정 논의 모드
기본적으로 `/gsd-discuss-phase`는 구현 선호도에 대한 개방형 질문을 합니다. 가정 모드는 이를 반전합니다: GSD가 먼저 코드베이스를 읽고, 단계 구축 방법에 대한 구조화된 가정을 표시하며, 수정 사항만 요청합니다.
기본적으로 `/msd-discuss-phase`는 구현 선호도에 대한 개방형 질문을 합니다. 가정 모드는 이를 반전합니다: MSD가 먼저 코드베이스를 읽고, 단계 구축 방법에 대한 구조화된 가정을 표시하며, 수정 사항만 요청합니다.
**활성화:** `/gsd-settings`를 통해 `workflow.discuss_mode`를 `'assumptions'`으로 설정하세요.
**활성화:** `/msd-settings`를 통해 `workflow.discuss_mode`를 `'assumptions'`으로 설정하세요.
전체 discuss 모드 레퍼런스는 [docs/workflow-discuss-mode.md](workflow-discuss-mode.md)를 참조하세요.
@@ -214,18 +214,18 @@ GSD 핵심 루프는 **discuss → plan → execute → verify → ship**이며,
discuss 단계는 `<decisions>` 블록 아래 CONTEXT.md에 구현 결정을 번호 매긴 글머리로 캡처합니다(`- **D-01:** …`). 두 개의 게이트는 해당 결정이 계획과 배포된 코드에 반영되도록 보장합니다.
**계획 단계 번역 게이트 (차단).** 계획 후, GSD는 추적 가능한 모든 결정이 최소한 하나의 계획의 `must_haves`, `truths`, 또는 본문에 나타날 때까지 단계를 계획된 것으로 표시하기를 거부합니다.
**계획 단계 번역 게이트 (차단).** 계획 후, MSD는 추적 가능한 모든 결정이 최소한 하나의 계획의 `must_haves`, `truths`, 또는 본문에 나타날 때까지 단계를 계획된 것으로 표시하기를 거부합니다.
**검증 단계 유효성 검사 게이트 (비차단).** 검증 중에 GSD는 추적 가능한 각 결정에 대해 계획, SUMMARY.md, 수정된 파일, 최근 커밋 메시지를 검색합니다. 누락된 항목은 경고 섹션으로 VERIFICATION.md에 기록되며, 검증 상태는 변경되지 않습니다.
**검증 단계 유효성 검사 게이트 (비차단).** 검증 중에 MSD는 추적 가능한 각 결정에 대해 계획, SUMMARY.md, 수정된 파일, 최근 커밋 메시지를 검색합니다. 누락된 항목은 경고 섹션으로 VERIFICATION.md에 기록되며, 검증 상태는 변경되지 않습니다.
**결정 제외.** `<decisions>` 내부의 `### Claude's Discretion` 제목 아래로 이동하거나 태그를 지정하세요: `- **D-08 [informational]:** …`, `- **D-09 [folded]:** …`, `- **D-10 [deferred]:** …`.
**게이트 비활성화.** `.planning/config.json`에서 `workflow.context_coverage_gate: false`로 설정하세요(또는 `/gsd-settings`를 통해). 기본값은 `true`입니다.
**게이트 비활성화.** `.planning/config.json`에서 `workflow.context_coverage_gate: false`로 설정하세요(또는 `/msd-settings`를 통해). 기본값은 `true`입니다.
### 실행 웨이브 조정
```text
/gsd-execute-phase N
/msd-execute-phase N
│
├── Analyze plan dependencies
│
@@ -241,14 +241,14 @@ discuss 단계는 `<decisions>` 블록 아래 CONTEXT.md에 구현 결정을 번
├── Test quality audit (disabled tests, circular patterns, assertion strength)
│
├── PASS -> VERIFICATION.md (success)
└── FAIL -> Issues logged for /gsd-verify-work
└── FAIL -> Issues logged for /msd-verify-work
```
---
## UI 설계 계약
AI가 생성한 프런트엔드가 시각적으로 일관되지 않은 이유는 Claude Code가 UI에 능숙하지 않아서가 아니라, 실행 전에 설계 계약이 존재하지 않았기 때문입니다. `/gsd-ui-phase`는 계획 전에 설계 계약을 고정하고, `/gsd-ui-review`는 실행 후 결과를 감사합니다.
AI가 생성한 프런트엔드가 시각적으로 일관되지 않은 이유는 Claude Code가 UI에 능숙하지 않아서가 아니라, 실행 전에 설계 계약이 존재하지 않았기 때문입니다. `/msd-ui-phase`는 계획 전에 설계 계약을 고정하고, `/msd-ui-review`는 실행 후 결과를 감사합니다.
전체 워크플로우, 구성, shadcn 초기화, 레지스트리 안전 게이트는 [UI 단계 설계](how-to/design-a-ui-phase.md)를 참조하세요.
@@ -256,33 +256,33 @@ AI가 생성한 프런트엔드가 시각적으로 일관되지 않은 이유는
| 명령어 | 설명 |
| -------------------- | -------------------------------------------------------- |
| `/gsd-ui-phase [N]` | 프런트엔드 단계를 위한 UI-SPEC.md 설계 계약 생성 |
| `/gsd-ui-review [N]` | 구현된 UI의 소급 6-기둥 시각 감사 |
| `/msd-ui-phase [N]` | 프런트엔드 단계를 위한 UI-SPEC.md 설계 계약 생성 |
| `/msd-ui-review [N]` | 구현된 UI의 소급 6-기둥 시각 감사 |
| 설정 | 기본값 | 설명 |
| ------------------------- | ------- | ----------------------------------------------------------- |
| `workflow.ui_phase` | `true` | 프런트엔드 단계를 위한 UI 설계 계약 생성 |
| `workflow.ui_safety_gate` | `true` | 계획 단계에서 프런트엔드 단계에 대해 /gsd-ui-phase 실행 유도 |
| `workflow.ui_safety_gate` | `true` | 계획 단계에서 프런트엔드 단계에 대해 /msd-ui-phase 실행 유도 |
---
## 스파이킹 및 스케칭
계획 전에 기술적 타당성을 검증하려면 `/gsd-spike`를, 설계 전에 시각적 방향을 탐색하려면 `/gsd-sketch`를 사용하세요. 두 명령어 모두 `.planning/`에 아티팩트를 저장하고 마무리 동반 명령어를 통해 프로젝트 스킬 시스템과 통합됩니다.
계획 전에 기술적 타당성을 검증하려면 `/msd-spike`를, 설계 전에 시각적 방향을 탐색하려면 `/msd-sketch`를 사용하세요. 두 명령어 모두 `.planning/`에 아티팩트를 저장하고 마무리 동반 명령어를 통해 프로젝트 스킬 시스템과 통합됩니다.
전체 워크플로우와 흐름 다이어그램은 [스파이크 및 스케치](how-to/spike-and-sketch.md)를 참조하세요.
**일반적인 흐름:**
```bash
/gsd-spike "SSE vs WebSocket" # Validate the approach
/gsd-spike --wrap-up # Package learnings
/msd-spike "SSE vs WebSocket" # Validate the approach
/msd-spike --wrap-up # Package learnings
/gsd-sketch "real-time feed UI" # Explore the design
/gsd-sketch --wrap-up # Package decisions
/msd-sketch "real-time feed UI" # Explore the design
/msd-sketch --wrap-up # Package decisions
/gsd-discuss-phase N # Lock in preferences (now informed by spike + sketch)
/gsd-plan-phase N # Plan with confidence
/msd-discuss-phase N # Lock in preferences (now informed by spike + sketch)
/msd-plan-phase N # Plan with confidence
```
---
@@ -294,35 +294,35 @@ AI가 생성한 프런트엔드가 시각적으로 일관되지 않은 이유는
활성 계획에 준비되지 않은 아이디어는 999.x 번호를 사용하여 백로그에 넣어 활성 단계 순서 외부에 보관합니다.
```bash
/gsd-capture --backlog "GraphQL API layer" # Creates 999.1-graphql-api-layer/
/gsd-capture --backlog "Mobile responsive" # Creates 999.2-mobile-responsive/
/msd-capture --backlog "GraphQL API layer" # Creates 999.1-graphql-api-layer/
/msd-capture --backlog "Mobile responsive" # Creates 999.2-mobile-responsive/
```
백로그 항목은 전체 단계 디렉터리를 갖추므로, `/gsd-discuss-phase 999.1`로 아이디어를 더 탐색하거나 준비가 되면 `/gsd-plan-phase 999.1`을 사용할 수 있습니다.
백로그 항목은 전체 단계 디렉터리를 갖추므로, `/msd-discuss-phase 999.1`로 아이디어를 더 탐색하거나 준비가 되면 `/msd-plan-phase 999.1`을 사용할 수 있습니다.
**검토 및 승격**은 `/gsd-review-backlog`으로 합니다 — 모든 백로그 항목을 표시하고 승격(활성 순서로 이동), 유지(백로그에 남기기), 제거(삭제) 중 선택할 수 있습니다.
**검토 및 승격**은 `/msd-review-backlog`으로 합니다 — 모든 백로그 항목을 표시하고 승격(활성 순서로 이동), 유지(백로그에 남기기), 제거(삭제) 중 선택할 수 있습니다.
### 씨드
씨드는 트리거 조건이 있는 미래 지향적 아이디어입니다. 백로그 항목과 달리, 씨드는 적절한 마일스톤이 도래하면 자동으로 표시됩니다.
```bash
/gsd-capture --seed "Add real-time collab when WebSocket infra is in place"
/msd-capture --seed "Add real-time collab when WebSocket infra is in place"
```
`/gsd-new-milestone`은 모든 씨드를 스캔하고 매칭 항목을 표시합니다. **저장소:** `.planning/seeds/SEED-NNN-slug.md`
`/msd-new-milestone`은 모든 씨드를 스캔하고 매칭 항목을 표시합니다. **저장소:** `.planning/seeds/SEED-NNN-slug.md`
### 지속적 컨텍스트 스레드
스레드는 여러 세션에 걸쳐 있지만 특정 단계에 속하지 않는 작업을 위한 경량 세션 간 지식 저장소입니다.
```bash
/gsd-thread # List all threads
/gsd-thread fix-deploy-key-auth # Resume existing thread
/gsd-thread "Investigate TCP timeout" # Create new thread
/msd-thread # List all threads
/msd-thread fix-deploy-key-auth # Resume existing thread
/msd-thread "Investigate TCP timeout" # Create new thread
```
스레드가 성숙해지면 단계(`/gsd-phase`) 또는 백로그 항목(`/gsd-capture --backlog`)으로 승격할 수 있습니다. **저장소:** `.planning/threads/{slug}.md`
스레드가 성숙해지면 단계(`/msd-phase`) 또는 백로그 항목(`/msd-capture --backlog`)으로 승격할 수 있습니다. **저장소:** `.planning/threads/{slug}.md`
---
@@ -336,19 +336,19 @@ AI가 생성한 프런트엔드가 시각적으로 일관되지 않은 이유는
| 명령어 | 목적 |
| ---------------------------------- | ---------------------------------------------------- |
| `/gsd-workstreams create <name>` | 격리된 계획 상태로 새 워크스트림 생성 |
| `/gsd-workstreams switch <name>` | 활성 컨텍스트를 다른 워크스트림으로 전환 |
| `/gsd-workstreams list` | 모든 워크스트림과 활성 상태 표시 |
| `/gsd-workstreams complete <name>` | 워크스트림을 완료로 표시하고 상태 아카이브 |
| `/msd-workstreams create <name>` | 격리된 계획 상태로 새 워크스트림 생성 |
| `/msd-workstreams switch <name>` | 활성 컨텍스트를 다른 워크스트림으로 전환 |
| `/msd-workstreams list` | 모든 워크스트림과 활성 상태 표시 |
| `/msd-workstreams complete <name>` | 워크스트림을 완료로 표시하고 상태 아카이브 |
```bash
# Workspace example — feature branch isolation
/gsd-workspace --new --name feature-b --repos .
cd ~/gsd-workspaces/feature-b
/gsd-new-project
/msd-workspace --new --name feature-b --repos .
cd ~/msd-workspaces/feature-b
/msd-new-project
/gsd-workspace --list
/gsd-workspace --remove feature-b
/msd-workspace --list
/msd-workspace --remove feature-b
```
---
@@ -357,7 +357,7 @@ cd ~/gsd-workspaces/feature-b
### 심층 방어 (v1.27)
GSD는 LLM 시스템 프롬프트가 되는 마크다운 파일을 생성합니다. 즉, 계획 아티팩트로 유입되는 사용자 제어 텍스트는 잠재적인 간접 프롬프트 인젝션 벡터입니다. v1.27은 중앙화된 보안 강화를 도입했습니다:
MSD는 LLM 시스템 프롬프트가 되는 마크다운 파일을 생성합니다. 즉, 계획 아티팩트로 유입되는 사용자 제어 텍스트는 잠재적인 간접 프롬프트 인젝션 벡터입니다. v1.27은 중앙화된 보안 강화를 도입했습니다:
**경로 순회 방지:** 모든 사용자가 제공한 파일 경로(`--text-file`, `--prd`)는 프로젝트 디렉터리 내에서 확인됩니다. macOS `/var` → `/private/var` 심볼릭 링크 확인이 처리됩니다.
@@ -365,8 +365,8 @@ GSD는 LLM 시스템 프롬프트가 되는 마크다운 파일을 생성합니
**런타임 훅:**
- `gsd-prompt-guard.js` — `.planning/`에 대한 Write/Edit 호출에서 인젝션 패턴 스캔 (항상 활성, 자문 전용)
- `gsd-workflow-guard.js` — GSD 워크플로우 컨텍스트 외부에서 파일 편집 시 경고 (`hooks.workflow_guard`를 통한 옵트인)
- `msd-prompt-guard.js` — `.planning/`에 대한 Write/Edit 호출에서 인젝션 패턴 스캔 (항상 활성, 자문 전용)
- `msd-workflow-guard.js` — MSD 워크플로우 컨텍스트 외부에서 파일 편집 시 경고 (`hooks.workflow_guard`를 통한 옵트인)
**CI 스캐너:** `prompt-injection-scan.security.test.cjs`는 모든 에이전트, 워크플로우, 명령어 파일에서 삽입된 인젝션 벡터를 스캔합니다.
@@ -396,7 +396,7 @@ AI 코딩 도구는 패키지 이름을 환각합니다. 공격자는 npm, PyPI,
**적법성 판정:**
| 판정 | 의미 | GSD 조치 |
| 판정 | 의미 | MSD 조치 |
|---------|---------|------------|
| `[OK]` | 모든 적법성 검사 통과 | 진행 — 체크포인트 없음 |
| `[SUS]` | 의심스러운 신호 | 표시됨; 계획자가 `checkpoint:human-verify` 추가 |
@@ -416,17 +416,17 @@ pip install slopcheck
단계 실행 후 UAT 전에 구조화된 코드 리뷰를 실행하세요. 전체 워크플로우는 [크로스 AI 리뷰 설정](how-to/set-up-cross-ai-review.md)을 참조하세요.
```bash
/gsd-code-review 3 # Review all changed files in phase 3
/gsd-code-review 3 --depth=deep # Deep cross-file review
/gsd-code-review 3 --fix # Fix Critical + Warning findings atomically
/gsd-code-review 3 --fix --auto # Fix and re-review until clean (max 3 iterations)
/gsd-audit-fix # Audit + classify + fix (medium+ severity, max 5)
/msd-code-review 3 # Review all changed files in phase 3
/msd-code-review 3 --depth=deep # Deep cross-file review
/msd-code-review 3 --fix # Fix Critical + Warning findings atomically
/msd-code-review 3 --fix --auto # Fix and re-review until clean (max 3 iterations)
/msd-audit-fix # Audit + classify + fix (medium+ severity, max 5)
```
리뷰 단계는 실행 후, UAT 전에 삽입됩니다:
```text
/gsd-execute-phase N -> /gsd-code-review N -> /gsd-code-review N --fix -> /gsd-verify-work N
/msd-execute-phase N -> /msd-code-review N -> /msd-code-review N --fix -> /msd-verify-work N
```
---
@@ -445,26 +445,26 @@ pip install slopcheck
```bash
claude --dangerously-skip-permissions
/gsd-new-project # Answer questions, configure, approve roadmap
/msd-new-project # Answer questions, configure, approve roadmap
/clear
/gsd-discuss-phase 1 # Lock in your preferences
/gsd-ui-phase 1 # Design contract (frontend phases)
/gsd-plan-phase 1 # Research + plan + verify
/gsd-execute-phase 1 # Parallel execution
/gsd-verify-work 1 # Manual UAT
/gsd-ship 1 # Create PR from verified work
/gsd-ui-review 1 # Visual audit (frontend phases)
/msd-discuss-phase 1 # Lock in your preferences
/msd-ui-phase 1 # Design contract (frontend phases)
/msd-plan-phase 1 # Research + plan + verify
/msd-execute-phase 1 # Parallel execution
/msd-verify-work 1 # Manual UAT
/msd-ship 1 # Create PR from verified work
/msd-ui-review 1 # Visual audit (frontend phases)
/clear
/gsd-progress --next # Auto-detect and run next step
/msd-progress --next # Auto-detect and run next step
...
/gsd-audit-milestone # Check everything shipped
/gsd-complete-milestone # Archive, tag, done
/gsd-pause-work --report # Generate session summary
/msd-audit-milestone # Check everything shipped
/msd-complete-milestone # Archive, tag, done
/msd-pause-work --report # Generate session summary
```
> [!CAUTION]
> **The permissions flag is optional.** It skips per-file confirmation while
> GSD's sub-agents read and write files. Use it only in low-stakes or
> MSD's sub-agents read and write files. Use it only in low-stakes or
> throwaway contexts. To keep confirmations enabled, start with `claude` instead.
> For real work, read the [security model](../explanation/security-model.md) first.
@@ -472,24 +472,24 @@ claude --dangerously-skip-permissions
### 기존 문서로 새 프로젝트
```bash
/gsd-new-project --auto @prd.md # Auto-runs research/requirements/roadmap from your doc
/msd-new-project --auto @prd.md # Auto-runs research/requirements/roadmap from your doc
/clear
/gsd-discuss-phase 1 # Normal flow from here
/msd-discuss-phase 1 # Normal flow from here
```
### 기존 코드베이스
```bash
/gsd-onboard # Safely map, ingest docs, and initialize planning
# Follow printed handoff commands, then rerun /gsd-onboard
/msd-onboard # Safely map, ingest docs, and initialize planning
# Follow printed handoff commands, then rerun /msd-onboard
# (normal phase workflow from here)
```
**실행 후 드리프트 감지 (#2003).** 매 `/gsd-execute-phase` 후, GSD는 단계가 `.planning/codebase/STRUCTURE.md`를 오래되게 만들 만큼 충분한 구조적 변경을 도입했는지 확인합니다. 다음으로 동작을 변경할 수 있습니다:
**실행 후 드리프트 감지 (#2003).** 매 `/msd-execute-phase` 후, MSD는 단계가 `.planning/codebase/STRUCTURE.md`를 오래되게 만들 만큼 충분한 구조적 변경을 도입했는지 확인합니다. 다음으로 동작을 변경할 수 있습니다:
```bash
/gsd-settings workflow.drift_action auto-remap # remap automatically
/gsd-settings workflow.drift_threshold 5 # tune sensitivity
/msd-settings workflow.drift_action auto-remap # remap automatically
/msd-settings workflow.drift_threshold 5 # tune sensitivity
```
### 계획 드리프트 가드
@@ -505,40 +505,40 @@ claude --dangerously-skip-permissions
**needs-acknowledgement 동작.** 가드가 누락된 심볼을 발견하면, 하드 차단 대신 계획 검토 출력에 `needs-acknowledgement` 알림을 표시합니다. 승인 후 진행하거나(심볼이 의도적으로 새로운 것일 수 있음) 계획 수정을 요청할 수 있습니다. 가드는 계획을 자동으로 거부하지 않으며 — 사람의 결정을 위한 신호를 표시합니다.
**인텔 없이 작동.** 기본적으로 가드는 `grep`/`ripgrep`을 사용하여 소스 파일을 검색합니다 — 사전 인덱싱이 필요하지 않습니다. `intel.enabled: true`로 `/gsd-map-codebase`를 실행했다면 `plan_review.source_grounding_authority: intel`로 설정하여 더 빠른 사전 빌드 `api-map.json` 인덱스를 사용하세요.
**인텔 없이 작동.** 기본적으로 가드는 `grep`/`ripgrep`을 사용하여 소스 파일을 검색합니다 — 사전 인덱싱이 필요하지 않습니다. `intel.enabled: true`로 `/msd-map-codebase`를 실행했다면 `plan_review.source_grounding_authority: intel`로 설정하여 더 빠른 사전 빌드 `api-map.json` 인덱스를 사용하세요.
```bash
# Enable/disable (default: on)
/gsd-settings plan_review.source_grounding true
/gsd-settings plan_review.source_grounding false
/msd-settings plan_review.source_grounding true
/msd-settings plan_review.source_grounding false
# Switch resolver authority
/gsd-settings plan_review.source_grounding_authority grep # live grep (default)
/gsd-settings plan_review.source_grounding_authority intel # pre-indexed api-map.json
/msd-settings plan_review.source_grounding_authority grep # live grep (default)
/msd-settings plan_review.source_grounding_authority intel # pre-indexed api-map.json
```
프로젝트 설정 시(`/gsd-new-project`가 워크플로우 선호도 중 질문) 또는 `/gsd-settings`를 통해 언제든지 전환 가능합니다(계획 섹션 → 드리프트 가드).
프로젝트 설정 시(`/msd-new-project`가 워크플로우 선호도 중 질문) 또는 `/msd-settings`를 통해 언제든지 전환 가능합니다(계획 섹션 → 드리프트 가드).
### 빠른 버그 수정
```bash
/gsd-quick
/msd-quick
> "Fix the login button not responding on mobile Safari"
```
### 휴식 후 재개
```bash
/gsd-progress # See where you left off and what's next
/msd-progress # See where you left off and what's next
# or
/gsd-resume-work # Full context restoration from last session
/msd-resume-work # Full context restoration from last session
```
### 릴리스 준비
```bash
/gsd-audit-milestone # Check requirements coverage, detect stubs
/gsd-complete-milestone # Archive, tag, done
/msd-audit-milestone # Check requirements coverage, detect stubs
/msd-complete-milestone # Archive, tag, done
```
### 속도 vs 품질 프리셋
@@ -549,15 +549,15 @@ claude --dangerously-skip-permissions
| 일반 개발 | `interactive` | `standard` | `balanced` | on | on | on |
| 프로덕션 | `interactive` | `fine` | `quality` | on | on | on |
**자율 모드에서 discuss 단계 건너뛰기:** `yolo` 모드로 실행할 때는 `/gsd-settings`를 통해 `workflow.skip_discuss: true`로 설정하세요.
**자율 모드에서 discuss 단계 건너뛰기:** `yolo` 모드로 실행할 때는 `/msd-settings`를 통해 `workflow.skip_discuss: true`로 설정하세요.
### 마일스톤 중간 범위 변경
```bash
/gsd-phase # Append a new phase to the roadmap (default mode)
/gsd-phase --insert 3 # Insert urgent work between phases 3 and 4
/gsd-phase --remove 7 # Descope phase 7 and renumber
/gsd-phase --edit 4 # Edit any field of phase 4 in place
/msd-phase # Append a new phase to the roadmap (default mode)
/msd-phase --insert 3 # Insert urgent work between phases 3 and 4
/msd-phase --remove 7 # Descope phase 7 and renumber
/msd-phase --edit 4 # Edit any field of phase 4 in place
```
---
@@ -566,29 +566,29 @@ claude --dangerously-skip-permissions
포괄적인 문제 해결 가이드는 [복구 및 문제 해결](how-to/recover-and-troubleshoot.md)을 참조하세요. 가장 일반적인 문제들이 아래에 요약되어 있습니다.
### 프로그래밍 방식 CLI (`gsd-tools query` vs `gsd-tools.cjs`)
### 프로그래밍 방식 CLI (`msd-tools query` vs `msd-tools.cjs`)
자동화를 위해서는 등록된 서브명령어와 함께 **`gsd-tools query`**를 사용하세요([CLI-TOOLS.md — SDK 및 프로그래밍 방식 액세스](CLI-TOOLS.md#sdk-and-programmatic-access)와 QUERY-HANDLERS.md 참조). 레거시 `node $HOME/.claude/gsd-core/bin/gsd-tools.cjs` CLI도 계속 지원됩니다.
자동화를 위해서는 등록된 서브명령어와 함께 **`msd-tools query`**를 사용하세요([CLI-TOOLS.md — SDK 및 프로그래밍 방식 액세스](CLI-TOOLS.md#sdk-and-programmatic-access)와 QUERY-HANDLERS.md 참조). 레거시 `node $HOME/.claude/msd-core/bin/msd-tools.cjs` CLI도 계속 지원됩니다.
### STATE.md 동기화 오류
```bash
node "$HOME/.claude/gsd-core/bin/gsd-tools.cjs" state validate # Detect drift
node "$HOME/.claude/gsd-core/bin/gsd-tools.cjs" state sync --verify # Preview changes
node "$HOME/.claude/gsd-core/bin/gsd-tools.cjs" state sync # Reconstruct STATE.md
node "$HOME/.claude/msd-core/bin/msd-tools.cjs" state validate # Detect drift
node "$HOME/.claude/msd-core/bin/msd-tools.cjs" state sync --verify # Preview changes
node "$HOME/.claude/msd-core/bin/msd-tools.cjs" state sync # Reconstruct STATE.md
```
### "Spawning..." 이후 명령어가 멈춘 것처럼 보일 때
GSD 서브에이전트는 별도의 컨텍스트 창에서 실행됩니다 — 진행 중에는 부모 세션에서 보이지 않습니다. 세션을 중단하지 마세요. 결과를 기다리세요; 리서치 및 계획 에이전트는 일반적으로 1~5분이 소요됩니다.
MSD 서브에이전트는 별도의 컨텍스트 창에서 실행됩니다 — 진행 중에는 부모 세션에서 보이지 않습니다. 세션을 중단하지 마세요. 결과를 기다리세요; 리서치 및 계획 에이전트는 일반적으로 1~5분이 소요됩니다.
### 긴 세션 중 컨텍스트 저하
주요 명령어 사이에 컨텍스트 창을 지우세요: Claude Code에서 `/clear`. GSD는 새로운 컨텍스트를 중심으로 설계되었습니다 — 모든 서브에이전트는 새로운 200K 창을 받습니다. 지운 후 상태를 복원하려면 `/gsd-resume-work` 또는 `/gsd-progress`를 사용하세요.
주요 명령어 사이에 컨텍스트 창을 지우세요: Claude Code에서 `/clear`. MSD는 새로운 컨텍스트를 중심으로 설계되었습니다 — 모든 서브에이전트는 새로운 200K 창을 받습니다. 지운 후 상태를 복원하려면 `/msd-resume-work` 또는 `/msd-progress`를 사용하세요.
### 계획이 잘못되거나 정렬되지 않은 것 같을 때
계획 전에 `/gsd-discuss-phase [N]`을 실행하세요. 대부분의 계획 품질 문제는 `CONTEXT.md`가 방지했을 가정을 Claude가 만들어서 발생합니다.
계획 전에 `/msd-discuss-phase [N]`을 실행하세요. 대부분의 계획 품질 문제는 `CONTEXT.md`가 방지했을 가정을 Claude가 만들어서 발생합니다.
### 실행 실패 또는 스텁 생성
@@ -596,11 +596,11 @@ GSD 서브에이전트는 별도의 컨텍스트 창에서 실행됩니다 —
### 현재 위치를 놓쳤을 때
`/gsd-progress`를 실행하세요. 모든 상태 파일을 읽고 정확히 어디에 있는지, 다음에 무엇을 해야 하는지 알려줍니다.
`/msd-progress`를 실행하세요. 모든 상태 파일을 읽고 정확히 어디에 있는지, 다음에 무엇을 해야 하는지 알려줍니다.
### 모델 비용이 너무 높을 때
예산 프로필로 전환하세요: `/gsd-config --profile budget`. 도메인이 익숙하다면 `/gsd-settings`를 통해 리서치 및 계획 검사 에이전트를 비활성화하세요.
예산 프로필로 전환하세요: `/msd-config --profile budget`. 도메인이 익숙하다면 `/msd-settings`를 통해 리서치 및 계획 검사 에이전트를 비활성화하세요.
### 단계별 모델 비용 조정 (`models`) — v1.40에서 추가됨
@@ -626,7 +626,7 @@ GSD 서브에이전트는 별도의 컨텍스트 창에서 실행됩니다 —
{
"models": { "research": "sonnet" },
"model_overrides": {
"gsd-codebase-mapper": "haiku"
"msd-codebase-mapper": "haiku"
}
}
```
@@ -656,7 +656,7 @@ GSD 서브에이전트는 별도의 컨텍스트 창에서 실행됩니다 —
`model_profile` 또는 `models.<phase_type>`을 조정하기 전에, 하네스에서 어떤 **MCP 서버**가 활성화되어 있는지 감사하세요. 활성화된 모든 MCP 서버는 모든 턴에 도구 스키마를 주입합니다 — 대형 서버는 각각 20k+ 토큰을 소비할 수 있습니다.
이것은 **하네스 설정**이며, GSD 설정이 아닙니다. 토글은 `.claude/settings.json`에 있습니다:
이것은 **하네스 설정**이며, MSD 설정이 아닙니다. 토글은 `.claude/settings.json`에 있습니다:
```json
{
@@ -673,13 +673,13 @@ GSD 서브에이전트는 별도의 컨텍스트 창에서 실행됩니다 —
비활성화된 서버는 이후 모든 턴에서 스키마를 제거합니다. MCP 정리는 `model_profile` 조정과 **복합**됩니다 — 두 레버는 가산적이며, MCP 절약은 오케스트레이터가 생성하는 모든 서브에이전트에서 즉시 나타납니다.
전체 감사, 하네스 레퍼런스, `model_profile`과의 구성 노트는 번들된 `context-budget.md` 레퍼런스의 [MCP 도구 스키마 비용](../../gsd-core/references/context-budget.md#mcp-tool-schema-cost-harness-concern)을 참조하세요.
전체 감사, 하네스 레퍼런스, `model_profile`과의 구성 노트는 번들된 `context-budget.md` 레퍼런스의 [MCP 도구 스키마 비용](../../msd-core/references/context-budget.md#mcp-tool-schema-cost-harness-concern)을 참조하세요.
### 비 Claude 런타임 사용 (Codex, OpenCode, Antigravity CLI, Kilo)
> **Codex CLI 최소 지원 버전: `0.130.0`** (이슈 [#3562](https://github.com/open-gsd/gsd-core/issues/3562)).
비 Claude 런타임용으로 GSD를 설치했다면, 설치 프로그램이 이미 모델 해석을 구성했습니다. 수동 설정이 필요하지 않습니다 — `resolve_model_ids: "omit"`이 자동으로 설정되어 GSD가 Anthropic 모델 ID 해석을 건너뛰고 런타임이 자체 기본 모델을 선택하도록 합니다.
비 Claude 런타임용으로 MSD를 설치했다면, 설치 프로그램이 이미 모델 해석을 구성했습니다. 수동 설정이 필요하지 않습니다 — `resolve_model_ids: "omit"`이 자동으로 설정되어 MSD가 Anthropic 모델 ID 해석을 건너뛰고 런타임이 자체 기본 모델을 선택하도록 합니다.
비 Claude 런타임에서 다른 모델을 할당하려면:
@@ -687,9 +687,9 @@ GSD 서브에이전트는 별도의 컨텍스트 창에서 실행됩니다 —
{
"resolve_model_ids": "omit",
"model_overrides": {
"gsd-planner": "o3",
"gsd-executor": "o4-mini",
"gsd-debugger": "o3"
"msd-planner": "o3",
"msd-executor": "o4-mini",
"msd-debugger": "o3"
}
}
```
@@ -707,9 +707,9 @@ GSD 서브에이전트는 별도의 컨텍스트 창에서 실행됩니다 —
### 수동 설치 / Node.js 없는 설정
GSD 설치 프로그램을 실행할 수 없다면, `agents/`의 소스 파일을 직접 사용할 수 없습니다 — 이는 Claude Code의 네이티브 frontmatter 형식입니다. OpenCode의 경우 두 가지 변환이 필요합니다:
MSD 설치 프로그램을 실행할 수 없다면, `agents/`의 소스 파일을 직접 사용할 수 없습니다 — 이는 Claude Code의 네이티브 frontmatter 형식입니다. OpenCode의 경우 두 가지 변환이 필요합니다:
| 필드 | GSD 소스 형식 | OpenCode 유효 형식 | 조치 |
| 필드 | MSD 소스 형식 | OpenCode 유효 형식 | 조치 |
|---|---|---|---|
| `tools:` | `Read, Bash, Grep` (콤마 문자열) | frontmatter 필드가 아님 | `tools:` 줄 전체 제거 |
| `color:` | 일반 CSS 색상 이름 | 16진수 또는 OpenCode 의미 이름 | 16진수로 변환하거나 제거 |
@@ -717,26 +717,26 @@ GSD 설치 프로그램을 실행할 수 없다면, `agents/`의 소스 파일
**대안:** Node.js가 있는 모든 머신에서 설치 프로그램 실행:
```bash
npx @opengsd/gsd-core@latest --opencode --global
npx @golem15/msd-core@latest --opencode --global
```
### Cline용 설치
```bash
npx @opengsd/gsd-core --cline --global # applies to all projects
npx @opengsd/gsd-core --cline --local # this project only
npx @golem15/msd-core --cline --global # applies to all projects
npx @golem15/msd-core --cline --local # this project only
```
### CodeBuddy용 설치
```bash
npx @opengsd/gsd-core --codebuddy --global
npx @golem15/msd-core --codebuddy --global
```
### Qwen Code용 설치
```bash
npx @opengsd/gsd-core --qwen --global
npx @golem15/msd-core --qwen --global
```
### 프리릴리스 에디션 설치
@@ -744,7 +744,7 @@ npx @opengsd/gsd-core --qwen --global
설치 프로그램 실행 전에 런타임의 `*_CONFIG_DIR` 환경 변수를 프리릴리스 디렉터리로 설정하세요:
```bash
WINDSURF_CONFIG_DIR=~/.codeium/windsurf-next npx @opengsd/gsd-core@latest --windsurf --global
WINDSURF_CONFIG_DIR=~/.codeium/windsurf-next npx @golem15/msd-core@latest --windsurf --global
```
**지원 런타임의 환경 변수 레퍼런스:**
@@ -767,23 +767,23 @@ WINDSURF_CONFIG_DIR=~/.codeium/windsurf-next npx @opengsd/gsd-core@latest --wind
### 비 Anthropic 프로바이더와 Claude Code 사용
`inherit` 프로필로 전환하세요: `/gsd-config --profile inherit`. 이렇게 하면 모든 에이전트가 현재 세션 모델을 사용합니다.
`inherit` 프로필로 전환하세요: `/msd-config --profile inherit`. 이렇게 하면 모든 에이전트가 현재 세션 모델을 사용합니다.
### 민감/비공개 프로젝트 작업
`/gsd-new-project` 중 또는 `/gsd-settings`를 통해 `commit_docs: false`로 설정하세요. `.planning/`을 `.gitignore`에 추가하세요.
`/msd-new-project` 중 또는 `/msd-settings`를 통해 `commit_docs: false`로 설정하세요. `.planning/`을 `.gitignore`에 추가하세요.
### GSD 업데이트가 로컬 변경사항을 덮어씀
### MSD 업데이트가 로컬 변경사항을 덮어씀
v1.17부터 설치 프로그램은 로컬에서 수정된 파일을 `gsd-local-patches/`에 백업합니다. 변경사항을 다시 병합하려면 `/gsd-update --reapply`를 실행하세요.
v1.17부터 설치 프로그램은 로컬에서 수정된 파일을 `msd-local-patches/`에 백업합니다. 변경사항을 다시 병합하려면 `/msd-update --reapply`를 실행하세요.
### npm을 통해 업데이트할 수 없음
단계별 수동 업데이트 절차는 [docs/manual-update.md](../manual-update.md)를 참조하세요.
### 워크플로우 진단 (`/gsd-forensics`)
### 워크플로우 진단 (`/msd-forensics`)
워크플로우가 명확하지 않은 방식으로 실패하면 `/gsd-forensics`를 실행하여 git 히스토리 이상, 아티팩트 무결성, 상태 불일치를 포함한 진단 보고서를 생성하세요. 출력은 `.planning/forensics/`로 이동합니다.
워크플로우가 명확하지 않은 방식으로 실패하면 `/msd-forensics`를 실행하여 git 히스토리 이상, 아티팩트 무결성, 상태 불일치를 포함한 진단 보고서를 생성하세요. 출력은 `.planning/forensics/`로 이동합니다.
### 실행기 서브에이전트가 Bash 명령어에서 "Permission denied" 발생
@@ -812,14 +812,14 @@ v1.17부터 설치 프로그램은 로컬에서 수정된 파일을 `gsd-local-p
### 병렬 실행으로 빌드 잠금 오류 발생
GSD는 v1.26부터 이를 자동으로 처리합니다. 이전 버전을 사용 중이라면 프로젝트의 `CLAUDE.md`에 다음을 추가하세요:
MSD는 v1.26부터 이를 자동으로 처리합니다. 이전 버전을 사용 중이라면 프로젝트의 `CLAUDE.md`에 다음을 추가하세요:
```markdown
## Git Commit Rules for Agents
All subagent/executor commits MUST use `--no-verify`.
```
병렬 실행을 완전히 비활성화하려면: `/gsd-settings` → `parallelization.enabled`를 `false`로 설정하세요.
병렬 실행을 완전히 비활성화하려면: `/msd-settings` → `parallelization.enabled`를 `false`로 설정하세요.
---
@@ -827,19 +827,19 @@ All subagent/executor commits MUST use `--no-verify`.
| 문제 | 해결책 |
| ------------------------------------ | ------------------------------------------------------------------------ |
| 컨텍스트 손실 / 새 세션 | `/gsd-resume-work` 또는 `/gsd-progress` |
| 컨텍스트 손실 / 새 세션 | `/msd-resume-work` 또는 `/msd-progress` |
| 단계가 잘못됨 | 단계 커밋을 `git revert`한 후 재계획 |
| 범위 변경 필요 | `/gsd-phase` (기본), `/gsd-phase --insert`, 또는 `/gsd-phase --remove` |
| 무언가 고장남 | `/gsd-debug "description"` (수정 없이 분석만 하려면 `--diagnose` 추가) |
| 범위 변경 필요 | `/msd-phase` (기본), `/msd-phase --insert`, 또는 `/msd-phase --remove` |
| 무언가 고장남 | `/msd-debug "description"` (수정 없이 분석만 하려면 `--diagnose` 추가) |
| STATE.md 동기화 오류 | `state validate` 후 `state sync` |
| 워크플로우 상태가 손상된 것 같음 | `/gsd-forensics` |
| 빠른 목표 수정 | `/gsd-quick` |
| 계획이 비전과 맞지 않음 | `/gsd-discuss-phase [N]` 후 재계획 |
| 비용이 높아짐 | `/gsd-config --profile budget` 및 `/gsd-settings`로 에이전트 끄기 |
| 업데이트가 로컬 변경사항을 손상시킴 | `/gsd-update --reapply` |
| 이해관계자를 위한 세션 요약 필요 | `/gsd-pause-work --report` |
| 다음 단계를 모름 | `/gsd-progress --next` |
| 병렬 실행 빌드 오류 | GSD 업데이트 또는 `parallelization.enabled: false` 설정 |
| 워크플로우 상태가 손상된 것 같음 | `/msd-forensics` |
| 빠른 목표 수정 | `/msd-quick` |
| 계획이 비전과 맞지 않음 | `/msd-discuss-phase [N]` 후 재계획 |
| 비용이 높아짐 | `/msd-config --profile budget` 및 `/msd-settings`로 에이전트 끄기 |
| 업데이트가 로컬 변경사항을 손상시킴 | `/msd-update --reapply` |
| 이해관계자를 위한 세션 요약 필요 | `/msd-pause-work --report` |
| 다음 단계를 모름 | `/msd-progress --next` |
| 병렬 실행 빌드 오류 | MSD 업데이트 또는 `parallelization.enabled: false` 설정 |
---
@@ -853,24 +853,24 @@ All subagent/executor commits MUST use `--no-verify`.
STATE.md # Decisions, blockers, session memory
config.json # Workflow configuration
MILESTONES.md # Completed milestone archive
HANDOFF.json # Structured session handoff (from /gsd-pause-work)
research/ # Domain research from /gsd-new-project
reports/ # Session reports (from /gsd-pause-work --report)
HANDOFF.json # Structured session handoff (from /msd-pause-work)
research/ # Domain research from /msd-new-project
reports/ # Session reports (from /msd-pause-work --report)
todos/
pending/ # Captured ideas awaiting work
completed/ # Completed todos
debug/ # Active debug sessions
resolved/ # Archived debug sessions
spikes/ # Feasibility experiments (from /gsd-spike)
spikes/ # Feasibility experiments (from /msd-spike)
NNN-name/ # Experiment code + README with verdict
MANIFEST.md # Index of all spikes
sketches/ # HTML mockups (from /gsd-sketch)
sketches/ # HTML mockups (from /msd-sketch)
NNN-name/ # index.html (2-3 variants) + README
themes/
default.css # Shared CSS variables for all sketches
MANIFEST.md # Index of all sketches with winners
codebase/ # Brownfield codebase mapping (from /gsd-map-codebase or /gsd-onboard)
onboarding/ # Brownfield onboarding summary (from /gsd-onboard)
codebase/ # Brownfield codebase mapping (from /msd-map-codebase or /msd-onboard)
onboarding/ # Brownfield onboarding summary (from /msd-onboard)
phases/
XX-phase-name/
XX-YY-PLAN.md # Atomic execution plans
@@ -878,9 +878,9 @@ All subagent/executor commits MUST use `--no-verify`.
CONTEXT.md # Your implementation preferences
RESEARCH.md # Ecosystem research findings
VERIFICATION.md # Post-execution verification results
XX-UI-SPEC.md # UI design contract (from /gsd-ui-phase)
XX-UI-REVIEW.md # Visual audit scores (from /gsd-ui-review)
ui-reviews/ # Screenshots from /gsd-ui-review (gitignored)
XX-UI-SPEC.md # UI design contract (from /msd-ui-phase)
XX-UI-REVIEW.md # Visual audit scores (from /msd-ui-review)
ui-reviews/ # Screenshots from /msd-ui-review (gitignored)
```
---

14
docs/ko-KR/context-monitor.md
View File

@@ -19,7 +19,7 @@
|-------|-----------|----------------|
| Normal | > 35% | 경고 없음 |
| WARNING | <= 35% | 현재 작업 마무리, 새로운 복잡한 작업 시작 금지 |
| CRITICAL | <= 25% | 즉시 중단 후 상태 저장 (`/gsd-pause-work`) |
| CRITICAL | <= 25% | 즉시 중단 후 상태 저장 (`/msd-pause-work`) |
## Debounce
@@ -31,13 +31,13 @@
## 아키텍처
```
Statusline Hook (gsd-statusline.js)
Statusline Hook (msd-statusline.js)
| 기록
v
/tmp/claude-ctx-{session_id}.json
^ 읽기
|
Context Monitor (gsd-context-monitor.js, PostToolUse/AfterTool)
Context Monitor (msd-context-monitor.js, PostToolUse/AfterTool)
| 주입
v
additionalContext -> 에이전트가 경고를 받음
@@ -54,15 +54,15 @@ additionalContext -> 에이전트가 경고를 받음
}
```
## GSD와의 통합
## MSD와의 통합
GSD의 `/gsd-pause-work` 명령어는 실행 상태를 저장한다. WARNING 메시지는 해당 명령어 사용을 권장하며 CRITICAL 메시지는 즉각적인 상태 저장을 지시한다.
MSD의 `/msd-pause-work` 명령어는 실행 상태를 저장한다. WARNING 메시지는 해당 명령어 사용을 권장하며 CRITICAL 메시지는 즉각적인 상태 저장을 지시한다.
## 설정
두 훅 모두 `npx @opengsd/gsd-core` 설치 중에 자동으로 등록된다 — 정상적인 상황에서는 수동 단계가 필요하지 않다. 훅 설정 상세, 임계값 재정의, 수동 등록 예시는 [설정](CONFIGURATION.md)을 참조하라.
두 훅 모두 `npx @golem15/msd-core` 설치 중에 자동으로 등록된다 — 정상적인 상황에서는 수동 단계가 필요하지 않다. 훅 설정 상세, 임계값 재정의, 수동 등록 예시는 [설정](CONFIGURATION.md)을 참조하라.
간략한 참고: statusline 훅은 `settings.json`에 `statusLine`으로 등록된다; context monitor(`gsd-context-monitor.js`)는 `PostToolUse` 훅으로 등록된다(Antigravity CLI의 경우 `AfterTool`). 두 항목 모두 설치 프로그램을 실행한 절대 Node 실행 경로를 사용한다. Windows PowerShell에서는 인용된 실행 경로 앞에 `&`를 붙인다.
간략한 참고: statusline 훅은 `settings.json`에 `statusLine`으로 등록된다; context monitor(`msd-context-monitor.js`)는 `PostToolUse` 훅으로 등록된다(Antigravity CLI의 경우 `AfterTool`). 두 항목 모두 설치 프로그램을 실행한 절대 Node 실행 경로를 사용한다. Windows PowerShell에서는 인용된 실행 경로 앞에 `&`를 붙인다.
## 안전성

18
docs/ko-KR/explanation/context-engineering.md
View File

@@ -1,6 +1,6 @@
# 컨텍스트 엔지니어링
> GSD Core가 존재하는 이유와 해결하고자 하는 문제.
> MSD Core가 존재하는 이유와 해결하고자 하는 문제.
---
@@ -23,15 +23,15 @@
---
## GSD Core의 답: 신선한 컨텍스트 서브에이전트
## MSD Core의 답: 신선한 컨텍스트 서브에이전트
GSD Core의 핵심적인 통찰은 코딩 세션에서 이루어지는 작업의 *대부분*이 메인 컨텍스트에서 이루어질 필요가 없다는 것이다. 리서치, 계획 수립, 코드 작성, 검증은 각각 독립적이고 범위가 한정된 작업들이다. 각각을 깔끔하고 신중하게 범위가 지정된 컨텍스트 윈도우로 시작하는 전문화된 서브에이전트에게 넘기고 — 결과를 효율적으로 유지되는 얇은 오케스트레이터에게 보고할 수 있다.
MSD Core의 핵심적인 통찰은 코딩 세션에서 이루어지는 작업의 *대부분*이 메인 컨텍스트에서 이루어질 필요가 없다는 것이다. 리서치, 계획 수립, 코드 작성, 검증은 각각 독립적이고 범위가 한정된 작업들이다. 각각을 깔끔하고 신중하게 범위가 지정된 컨텍스트 윈도우로 시작하는 전문화된 서브에이전트에게 넘기고 — 결과를 효율적으로 유지되는 얇은 오케스트레이터에게 보고할 수 있다.
이것은 컨텍스트 부패를 위한 임시방편이 아니다. 구조적인 해결책이다.
오케스트레이터 — 메인 세션 — 는 소스 파일을 직접 다루지 않는다. 에이전트를 생성하고, 결과를 수집하며, 공유 상태를 업데이트하고, 다음 단계로 라우팅한다. 오케스트레이터가 스스로 하는 작업이 매우 적기 때문에 컨텍스트 윈도우가 느리고 예측 가능하게 증가한다. 무거운 작업은 각각 신선하게 시작하고, 자신의 작업에 필요한 정확한 컨텍스트만 받고, 완료 시 종료하는 에이전트에서 수행된다.
실제로 어떤 의미인지 생각해보자. `/gsd-plan-phase`를 실행하면 오케스트레이터는:
실제로 어떤 의미인지 생각해보자. `/msd-plan-phase`를 실행하면 오케스트레이터는:
1. 압축된 JSON 컨텍스트 페이로드(프로젝트 요약, 단계 목표, 관련 설정)를 로드한다.
2. 200k 토큰의 깨끗한 윈도우로 리서처 에이전트를 생성한다.
@@ -44,11 +44,11 @@ GSD Core의 핵심적인 통찰은 코딩 세션에서 이루어지는 작업의
## 명세 주도 개발과 메타 프롬프팅
컨텍스트 엔지니어링만으로는 충분하지 않다. 에이전트가 신선하게 시작하더라도 모호한 지시 사항을 받으면 모호한 결과물을 생성한다. GSD Core는 신선한 컨텍스트 서브에이전트와 두 가지 보완적인 원칙을 함께 사용한다.
컨텍스트 엔지니어링만으로는 충분하지 않다. 에이전트가 신선하게 시작하더라도 모호한 지시 사항을 받으면 모호한 결과물을 생성한다. MSD Core는 신선한 컨텍스트 서브에이전트와 두 가지 보완적인 원칙을 함께 사용한다.
**명세 주도 개발**은 모든 단계가 실행 전에 구조화된 결과물을 생성한다는 것을 의미한다. `CONTEXT.md`는 논의 단계의 구현 결정 사항들을 캡처한다. `RESEARCH.md`는 리서처가 발견한 내용을 기록한다. `PLAN.md`는 명시적인 수락 기준을 가진 개별적인 의존성 순서의 작업들로 작업을 분해한다. 실행 에이전트가 파일에 손을 대는 시점에는 긴 대화의 재해석이 아닌 정확한 명세를 가지고 있다.
**메타 프롬프팅**은 에이전트 정의 자체가 애드혹 지시 사항이 아닌 신중하게 설계된 프롬프트라는 것을 의미한다. `gsd-core/workflows/`와 `agents/`의 파일들은 작업의 범위를 지정하는 방법, 무엇을 검증해야 하는지, 언제 사람에게 체크포인트를 요청해야 하는지에 대한 소중한 지식을 담고 있다. 사용자는 매 세션마다 이 지식을 다시 설명할 필요가 없다; 그것은 시스템 자체의 프롬프트에 이미 내장되어 있다.
**메타 프롬프팅**은 에이전트 정의 자체가 애드혹 지시 사항이 아닌 신중하게 설계된 프롬프트라는 것을 의미한다. `msd-core/workflows/`와 `agents/`의 파일들은 작업의 범위를 지정하는 방법, 무엇을 검증해야 하는지, 언제 사람에게 체크포인트를 요청해야 하는지에 대한 소중한 지식을 담고 있다. 사용자는 매 세션마다 이 지식을 다시 설명할 필요가 없다; 그것은 시스템 자체의 프롬프트에 이미 내장되어 있다.
이 조합은 의도적이다. 신선한 컨텍스트는 각 에이전트가 명확하게 추론하도록 보장한다. 명세 주도 결과물은 각 에이전트가 *올바른* 것에 대해 추론하도록 보장한다. 메타 프롬프팅은 각 에이전트가 *어떻게* 잘 추론해야 하는지 알도록 보장한다.
@@ -56,7 +56,7 @@ GSD Core의 핵심적인 통찰은 코딩 세션에서 이루어지는 작업의
## `.planning/`의 역할
컨텍스트 엔지니어링은 지식이 컨텍스트 리셋을 통해 살아남아야 한다는 것을 요구한다. GSD Core는 이를 위해 파일 시스템을 사용한다. 모든 의미 있는 출력물은 사람이 읽을 수 있는 마크다운 또는 JSON으로 `.planning/`에 작성된다. 이것은 다음을 의미한다.
컨텍스트 엔지니어링은 지식이 컨텍스트 리셋을 통해 살아남아야 한다는 것을 요구한다. MSD Core는 이를 위해 파일 시스템을 사용한다. 모든 의미 있는 출력물은 사람이 읽을 수 있는 마크다운 또는 JSON으로 `.planning/`에 작성된다. 이것은 다음을 의미한다.
- 세션을 다시 시작하거나 모델이 충돌해도 작업이 손실되지 않는다.
- 모든 이후 에이전트는 공유 대화 이력에 의존하지 않고 이전 결과물을 직접 읽을 수 있다.
@@ -70,11 +70,11 @@ GSD Core의 핵심적인 통찰은 코딩 세션에서 이루어지는 작업의
여기서 트레이드오프에 대한 솔직함이 중요하다.
**오버헤드.** 단계 루프는 실제 마찰을 야기한다. `/gsd-discuss-phase`, `/gsd-plan-phase`, `/gsd-execute-phase`를 별도의 단계로 실행하는 것은 단순 세션에 "이 기능을 작성해줘"라고 입력하는 것보다 더 많은 경과 시간이 걸린다. 작고 잘 이해된 변경의 경우 그 오버헤드는 정당화되지 않는다.
**오버헤드.** 단계 루프는 실제 마찰을 야기한다. `/msd-discuss-phase`, `/msd-plan-phase`, `/msd-execute-phase`를 별도의 단계로 실행하는 것은 단순 세션에 "이 기능을 작성해줘"라고 입력하는 것보다 더 많은 경과 시간이 걸린다. 작고 잘 이해된 변경의 경우 그 오버헤드는 정당화되지 않는다.
**지연.** 신선한 컨텍스트로 여러 서브에이전트를 생성하는 것은 단일 인-컨텍스트 편집보다 느리다. 리서치, 계획 수립, 실행 각각에 왕복 비용이 발생한다.
**단순한 작업에 대한 의례.** 변수 이름을 바꾸거나, 오타를 수정하거나, 누락된 임포트를 추가해야 할 때 단계 루프는 과도하다. GSD Core는 전체 단계를 필요로 하지 않는 임시 작업을 위해 `/gsd-quick`과 `/gsd-fast`를 제공한다. [빠른 작업 처리하기](../how-to/handle-quick-and-fast-tasks.md)를 참조하라.
**단순한 작업에 대한 의례.** 변수 이름을 바꾸거나, 오타를 수정하거나, 누락된 임포트를 추가해야 할 때 단계 루프는 과도하다. MSD Core는 전체 단계를 필요로 하지 않는 임시 작업을 위해 `/msd-quick`과 `/msd-fast`를 제공한다. [빠른 작업 처리하기](../how-to/handle-quick-and-fast-tasks.md)를 참조하라.
단계 루프는 컨텍스트 부패가 실제 위험인 만큼 복잡한 작업 — 다중 파일 기능, 횡단 관심사 리팩터링, 몇 시간 또는 여러 세션에 걸친 작업 — 에서 그 가치를 발휘한다. 그 외의 경우에는 더 가벼운 기본 도구를 사용하라.

40
docs/ko-KR/explanation/multi-agent-orchestration.md
View File

@@ -1,6 +1,6 @@
# GSD Core의 다중 에이전트 오케스트레이션
# MSD Core의 다중 에이전트 오케스트레이션
> **설명** — 이 문서는 GSD Core가 다중 에이전트 오케스트레이션을 중심으로
> **설명** — 이 문서는 MSD Core가 다중 에이전트 오케스트레이션을 중심으로
> 설계된 *이유*와 *구성 요소들이 어떻게 맞물리는지*를 설명한다. 단계별
> 가이드가 아니다. 설정에 대해서는
> [모델 프로필 설정](../how-to/configure-model-profiles.md)과
@@ -13,23 +13,23 @@
AI 코딩 에이전트는 저하된다. 모델이 나빠지기 때문이 아니라 *컨텍스트 윈도우가 채워지기* 때문이다. 대화가 길어질수록 초반의 결정들과 코드가 중간 단계들의 노이즈에 밀려나거나 희석된다. 복잡한 작업에서 다섯 번째 파일을 작성할 때쯤 에이전트는 첫 번째 메시지에서 명시된 제약 조건을 이미 잊었을 수도 있다. 이를 *컨텍스트 부패*라고 부르기도 한다.
GSD Core의 다중 에이전트 설계는 그 문제에 대한 직접적인 대응이다. 하나의 장시간 실행 에이전트가 전체 세션을 담당하는 대신, 얇은 오케스트레이터가 **신선한 200K 토큰 컨텍스트 윈도우**와 *자신의 특정 작업을 수행하는 데 필요한 결과물만* 갖고 시작하는 단수명 전문화 에이전트들을 생성한다. 오케스트레이터 자신은 절대 무거운 작업을 하지 않는다; 컨텍스트를 로드하고, 적합한 에이전트를 생성하고, 결과를 수집하고, `.planning/`의 공유 상태를 업데이트한다.
MSD Core의 다중 에이전트 설계는 그 문제에 대한 직접적인 대응이다. 하나의 장시간 실행 에이전트가 전체 세션을 담당하는 대신, 얇은 오케스트레이터가 **신선한 200K 토큰 컨텍스트 윈도우**와 *자신의 특정 작업을 수행하는 데 필요한 결과물만* 갖고 시작하는 단수명 전문화 에이전트들을 생성한다. 오케스트레이터 자신은 절대 무거운 작업을 하지 않는다; 컨텍스트를 로드하고, 적합한 에이전트를 생성하고, 결과를 수집하고, `.planning/`의 공유 상태를 업데이트한다.
---
## 오케스트레이터 → 에이전트 패턴
`gsd-core/workflows/`의 모든 워크플로우는 동일한 형태를 따른다:
`msd-core/workflows/`의 모든 워크플로우는 동일한 형태를 따른다:
```text
오케스트레이터 (워크플로우 .md 파일)
│
├── 컨텍스트 로드
│ gsd-tools.cjs init <workflow> <phase>
│ msd-tools.cjs init <workflow> <phase>
│ → JSON: 프로젝트 정보, 설정, 상태, 단계 상세
│
├── 모델 해결
│ gsd-tools.cjs resolve-model <agent-name>
│ msd-tools.cjs resolve-model <agent-name>
│ → opus | sonnet | haiku | inherit
│
├── 전문화 에이전트 생성 (Task/SubAgent 호출)
@@ -41,25 +41,25 @@ GSD Core의 다중 에이전트 설계는 그 문제에 대한 직접적인 대
├── 결과 수집
│
└── 상태 업데이트
gsd-tools.cjs state update / state patch / state advance-plan
msd-tools.cjs state update / state patch / state advance-plan
```
오케스트레이터는 의도적으로 얇다. 도메인에 대해 추론하지 않고, 코드를 작성하지 않으며, 다음 단계로 라우팅하는 것 이상으로 결과를 해석하지 않는다. 그 경계는 각 계층의 책임을 명확하게 유지하고 오케스트레이터의 컨텍스트가 도메인 노이즈를 축적하는 것을 방지한다.
### 에이전트 목록
GSD Core의 에이전트들은 리서치 → 계획 → 실행 → 검증 파이프라인에 매핑되는 기능 범주로 나뉜다:
MSD Core의 에이전트들은 리서치 → 계획 → 실행 → 검증 파이프라인에 매핑되는 기능 범주로 나뉜다:
| 범주 | 에이전트 | 일반적인 병렬성 |
|---|---|---|
| 리서처 | `gsd-project-researcher`, `gsd-phase-researcher`, `gsd-ui-researcher`, `gsd-advisor-researcher` | 4개 병렬 (스택, 기능, 아키텍처, 함정) |
| 합성기 | `gsd-research-synthesizer` | 리서처 완료 후 순차적 |
| 플래너 | `gsd-planner`, `gsd-roadmapper` | 순차적 |
| 검사기 | `gsd-plan-checker`, `gsd-integration-checker`, `gsd-ui-checker`, `gsd-nyquist-auditor` | 순차적, 최대 3번 수정 반복 |
| 실행기 | `gsd-executor` | 웨이브 내 병렬, 웨이브 간 순차적 |
| 검증기 | `gsd-verifier` | 모든 실행기 완료 후 순차적 |
| 매퍼 | `gsd-codebase-mapper` | 4개 병렬 하위 프로브 |
| 감사기 | `gsd-ui-auditor`, `gsd-security-auditor` | 순차적 |
| 리서처 | `msd-project-researcher`, `msd-phase-researcher`, `msd-ui-researcher`, `msd-advisor-researcher` | 4개 병렬 (스택, 기능, 아키텍처, 함정) |
| 합성기 | `msd-research-synthesizer` | 리서처 완료 후 순차적 |
| 플래너 | `msd-planner`, `msd-roadmapper` | 순차적 |
| 검사기 | `msd-plan-checker`, `msd-integration-checker`, `msd-ui-checker`, `msd-nyquist-auditor` | 순차적, 최대 3번 수정 반복 |
| 실행기 | `msd-executor` | 웨이브 내 병렬, 웨이브 간 순차적 |
| 검증기 | `msd-verifier` | 모든 실행기 완료 후 순차적 |
| 매퍼 | `msd-codebase-mapper` | 4개 병렬 하위 프로브 |
| 감사기 | `msd-ui-auditor`, `msd-security-auditor` | 순차적 |
각 에이전트 정의(`agents/*.md`)는 허용된 도구 접근, 목적, 터미널 출력 색상을 선언한다. 파일을 읽고 단일 출력 문서를 작성하기만 하면 되는 에이전트는 정확히 그런 권한만 받는다 — Bash 실행 없음, 광범위한 상태 접근 없음. 그 제약은 의도적이다: 에이전트가 예상치 못하게 행동할 경우 영향 범위를 작게 유지한다.
@@ -69,7 +69,7 @@ GSD Core의 에이전트들은 리서치 → 계획 → 실행 → 검증 파이
## 웨이브 기반 병렬 실행
다중 에이전트 설계의 가장 눈에 띄는 표현은 `/gsd-execute-phase`가 서로 의존관계가 있는 계획들의 집합을 처리하는 방식이다.
다중 에이전트 설계의 가장 눈에 띄는 표현은 `/msd-execute-phase`가 서로 의존관계가 있는 계획들의 집합을 처리하는 방식이다.
실행기를 생성하기 전에 오케스트레이터는 **웨이브 분석**을 수행한다: 각 `PLAN.md` 파일의 의존성 선언을 읽고 계획들을 웨이브로 그룹화한다. 선언된 의존성이 없는 계획들은 웨이브 1을 형성하고 병렬로 실행된다. 웨이브 1에 의존하는 계획들은 웨이브 2를 형성하고, 계속해서 이어진다.
@@ -121,7 +121,7 @@ GSD Core의 에이전트들은 리서치 → 계획 → 실행 → 검증 파이
**컨텍스트 격리.** 각 에이전트는 필요한 것만 받는다. 리서처는 프로젝트 설명과 도메인 질문들을 받는다; 전체 계획 이력은 받지 않는다. 검증기는 모든 계획과 요약을 받는다; 원시 리서치는 받지 않는다. 격리는 각 에이전트의 컨텍스트를 다른 파이프라인 단계들의 노이즈로 희석되지 않고 신호로 밀도 있게 유지한다.
**세션 간 컨텍스트 위생.** 모든 상태가 사람이 읽을 수 있는 마크다운과 JSON으로 `.planning/`에 저장되기 때문에(에이전트의 컨텍스트 윈도우가 아닌), GSD 워크플로우는 컨텍스트 리셋(`/clear`), 탭 전환, 며칠간의 휴식을 견뎌낸다. 다음 에이전트는 항상 긴 대화의 재구성된 기억이 아닌 영속적이고 검증된 결과물에서 시작한다.
**세션 간 컨텍스트 위생.** 모든 상태가 사람이 읽을 수 있는 마크다운과 JSON으로 `.planning/`에 저장되기 때문에(에이전트의 컨텍스트 윈도우가 아닌), MSD 워크플로우는 컨텍스트 리셋(`/clear`), 탭 전환, 며칠간의 휴식을 견뎌낸다. 다음 에이전트는 항상 긴 대화의 재구성된 기억이 아닌 영속적이고 검증된 결과물에서 시작한다.
---
@@ -129,11 +129,11 @@ GSD Core의 에이전트들은 리서치 → 계획 → 실행 → 검증 파이
다중 에이전트 오케스트레이션은 비용이 없지 않다.
**조율 오버헤드.** 각 에이전트 생성은 왕복이다: 오케스트레이터가 프롬프트를 형식화하고, 컨텍스트를 넘기고, 서브에이전트가 완료될 때까지 기다리고(일반적으로 1-5분), 결과를 파싱해야 한다. 하나의 컨텍스트에서 작동하는 단일 능력 있는 에이전트는 단순한 작업에서 더 빨리 완료될 것이다. GSD는 의존성이 허용되는 모든 곳에서 병렬성을 기본값으로 만들어 이를 완화한다 — `plan-phase`의 네 리서처들은 순차적이 아닌 동시에 실행된다.
**조율 오버헤드.** 각 에이전트 생성은 왕복이다: 오케스트레이터가 프롬프트를 형식화하고, 컨텍스트를 넘기고, 서브에이전트가 완료될 때까지 기다리고(일반적으로 1-5분), 결과를 파싱해야 한다. 하나의 컨텍스트에서 작동하는 단일 능력 있는 에이전트는 단순한 작업에서 더 빨리 완료될 것이다. MSD는 의존성이 허용되는 모든 곳에서 병렬성을 기본값으로 만들어 이를 완화한다 — `plan-phase`의 네 리서처들은 순차적이 아닌 동시에 실행된다.
**실행 중 불투명성.** 서브에이전트가 실행되는 동안 그 작업은 부모 세션에서 보이지 않는다. 실시간 진행 스트림이 없다. 이것은 신선한 컨텍스트 설계의 의도적인 결과이다: 서브에이전트가 자체 컨텍스트 윈도우에서 작동하고 있다. 오케스트레이터는 생성 라인에 활성 표시를 보여줌으로써("서브에이전트에서 실행됨 — 반환될 때까지 출력 없음") 기대치를 설정한다.
**컨텍스트 스티칭 비용.** 각 에이전트에 적합한 결과물들을 패키징하려면 오케스트레이터가 컨텍스트 페이로드를 조립하고 전송하는 데 토큰을 소비해야 한다. 이것이 격리의 비용이다. `gsd-tools.cjs init` 핸들러는 완전성과 토큰 예산의 균형을 맞추는 JSON 페이로드를 생성하며, 반복 호출에서 캐시에 도달하도록 캐시 친화적 순서를 적용한다.
**컨텍스트 스티칭 비용.** 각 에이전트에 적합한 결과물들을 패키징하려면 오케스트레이터가 컨텍스트 페이로드를 조립하고 전송하는 데 토큰을 소비해야 한다. 이것이 격리의 비용이다. `msd-tools.cjs init` 핸들러는 완전성과 토큰 예산의 균형을 맞추는 JSON 페이로드를 생성하며, 반복 호출에서 캐시에 도달하도록 캐시 친화적 순서를 적용한다.
**모델 비용 증폭.** Opus 등급으로 다섯 개의 에이전트를 병렬로 실행하는 것은 하나를 실행하는 것보다 더 비용이 많이 든다. 모델 프로필 시스템(`model_profiles.md`, `model-profiles.cjs`에 의해 에이전트별로 해결됨)을 사용하면 덜 중요한 에이전트에 더 저렴한 등급을 할당할 수 있다. `dynamic_routing` 기능은 모든 에이전트를 더 저렴한 등급에서 시작하고 소프트 실패 시에만 에스컬레이션함으로써 비용을 더 줄여준다. 전체 옵션은 [설정](../CONFIGURATION.md)을 참조하라.

40
docs/ko-KR/explanation/security-model.md
View File

@@ -1,8 +1,8 @@
# GSD Core 보안 모델
# MSD Core 보안 모델
> **설명** — 이 문서는 GSD Core가 현재의 보안 자세를 갖는 *이유*와 *계층들이
> **설명** — 이 문서는 MSD Core가 현재의 보안 자세를 갖는 *이유*와 *계층들이
> 어떻게 맞물리는지*를 설명한다. 모든 훅 파라미터에 대한 레퍼런스가 아니다.
> `/gsd-secure-phase` 명령과 옵션에 대해서는 [명령어](../COMMANDS.md)를 참조하라.
> `/msd-secure-phase` 명령과 옵션에 대해서는 [명령어](../COMMANDS.md)를 참조하라.
> 구현 수준의 훅 아키텍처에 대해서는
> [아키텍처 § 훅 시스템](../ARCHITECTURE.md#hook-system)을 참조하라.
> 조직 전반의 보안 기준선(스캐너 제어, 인시던트 체크리스트, 소유권 모델)에 대해서는
@@ -12,9 +12,9 @@
## AI 기반 개발에 전용 보안 자세가 필요한 이유
일반적인 코드 에디터는 사용자를 대신하여 임의의 패키지를 실행하지 않는다. GSD Core는 그렇게 한다. 리서치 → 계획 → 실행 파이프라인은 "패키지 이름 지정"에서 "`npm install <package>` 실행"까지, "계획 결과물 작성"에서 "해당 결과물을 LLM 시스템 프롬프트로 사용"까지의 전체 경로를 자동화한다. 각 자동화 단계는 루프에서 사람을 제거한다 — 그리고 각 제거는 잠재적인 공격 표면이다.
일반적인 코드 에디터는 사용자를 대신하여 임의의 패키지를 실행하지 않는다. MSD Core는 그렇게 한다. 리서치 → 계획 → 실행 파이프라인은 "패키지 이름 지정"에서 "`npm install <package>` 실행"까지, "계획 결과물 작성"에서 "해당 결과물을 LLM 시스템 프롬프트로 사용"까지의 전체 경로를 자동화한다. 각 자동화 단계는 루프에서 사람을 제거한다 — 그리고 각 제거는 잠재적인 공격 표면이다.
GSD Core의 보안 모델은 하나의 조직 원칙을 중심으로 구축된다: **심층 방어(defence in depth)**. 어떤 단일 제어도 완벽하다고 가정하지 않는다. 여러 겹치는 계층이 각각 고유한 종류의 위험을 줄이며, 함께 공격 표면을 완전히 제거하지는 않지만 악용하기 상당히 더 어렵게 만든다. 이 문서 끝의 솔직한 요약은 시스템이 방어할 수 없는 것을 설명한다.
MSD Core의 보안 모델은 하나의 조직 원칙을 중심으로 구축된다: **심층 방어(defence in depth)**. 어떤 단일 제어도 완벽하다고 가정하지 않는다. 여러 겹치는 계층이 각각 고유한 종류의 위험을 줄이며, 함께 공격 표면을 완전히 제거하지는 않지만 악용하기 상당히 더 어렵게 만든다. 이 문서 끝의 솔직한 요약은 시스템이 방어할 수 없는 것을 설명한다.
---
@@ -24,17 +24,17 @@ GSD Core의 보안 모델은 하나의 조직 원칙을 중심으로 구축된
AI 모델은 패키지 이름을 환각한다. 이것은 변두리 실패 모드가 아니다: 2025년 연구에서 AI가 생성한 패키지 참조의 약 20%가 합법적인 패키지와 대응되지 않는 환각된 이름으로 문서화되었다. 그 환각된 이름들의 일부 — 같은 연구에서 약 43% — 는 프롬프트 전반에 걸쳐 일관되게 반복되며, 이는 공격자가 AI 도구들이 일반적으로 생성하는 이름을 관찰하고 악의적인 설치 후 스크립트로 npm, PyPI, 또는 crates.io에 해당 이름들을 선점 등록할 수 있다는 것을 의미한다. 이 기법을 *슬롭스쿼팅(slopsquatting)*이라고 한다.
슬롭스쿼팅의 교활한 특성은 `npm view`를 통과하는 환각된 이름이 *합법적으로 보인다*는 것이다. 레지스트리 항목은 누군가가 이름을 등록했다는 것만 증명한다 — AI가 말한 것을 패키지가 한다거나, 합법적인 사용자가 있다거나, 설치 스크립트가 안전하다는 것은 증명하지 않는다. 게이트 없이는 환각된 이름이 GSD의 리서처 → 플래너 → 실행기 파이프라인을 통해 감지되지 않고 흐르다가 결국 사용자의 기계에서 `npm install <attacker-package>`로 실행될 것이다.
슬롭스쿼팅의 교활한 특성은 `npm view`를 통과하는 환각된 이름이 *합법적으로 보인다*는 것이다. 레지스트리 항목은 누군가가 이름을 등록했다는 것만 증명한다 — AI가 말한 것을 패키지가 한다거나, 합법적인 사용자가 있다거나, 설치 스크립트가 안전하다는 것은 증명하지 않는다. 게이트 없이는 환각된 이름이 MSD의 리서처 → 플래너 → 실행기 파이프라인을 통해 감지되지 않고 흐르다가 결국 사용자의 기계에서 `npm install <attacker-package>`로 실행될 것이다.
### 게이트 작동 방식
게이트는 세 가지 파이프라인 단계에 걸쳐 작동한다:
**리서치 단계.** `gsd-phase-researcher`가 외부 패키지를 추천할 때 각 패키지에 대해 `gsd-tools query package-legitimacy check --ecosystem <npm|pypi|crates> <pkgs>`을 실행한다. 결과는 `RESEARCH.md`의 `## Package Legitimacy Audit` 테이블에 작성된다. `[SLOP]`로 태그된 패키지들(높은 신뢰도의 환각 또는 공격자가 등록)은 파일이 저장되기 전에 **`RESEARCH.md`에서 완전히 제거된다**. 이런 패키지들은 절대 플래너에게 도달하지 않는다.
**리서치 단계.** `msd-phase-researcher`가 외부 패키지를 추천할 때 각 패키지에 대해 `msd-tools query package-legitimacy check --ecosystem <npm|pypi|crates> <pkgs>`을 실행한다. 결과는 `RESEARCH.md`의 `## Package Legitimacy Audit` 테이블에 작성된다. `[SLOP]`로 태그된 패키지들(높은 신뢰도의 환각 또는 공격자가 등록)은 파일이 저장되기 전에 **`RESEARCH.md`에서 완전히 제거된다**. 이런 패키지들은 절대 플래너에게 도달하지 않는다.
**계획 단계.** `gsd-planner`는 감사 테이블을 읽는다. `[SUS]`(의심스러움: 최근 등록, 낮은 다운로드 수, 소스 저장소 없음, 또는 인기 있는 패키지와 가까운 명명 패턴)나 `[ASSUMED]`(직접 레지스트리 검증이 아닌 WebSearch에서 출처)로 태그된 모든 패키지에 대해, 플래너는 설치 단계 전에 **`checkpoint:human-verify` 작업을 삽입한다**. 체크포인트에는 레지스트리 페이지로의 직접 링크와 살펴봐야 할 구체적인 항목들이 포함된다: 유지관리자 이력, 이슈 트래커 활동, 의심스러운 설치 스크립트의 부재.
**계획 단계.** `msd-planner`는 감사 테이블을 읽는다. `[SUS]`(의심스러움: 최근 등록, 낮은 다운로드 수, 소스 저장소 없음, 또는 인기 있는 패키지와 가까운 명명 패턴)나 `[ASSUMED]`(직접 레지스트리 검증이 아닌 WebSearch에서 출처)로 태그된 모든 패키지에 대해, 플래너는 설치 단계 전에 **`checkpoint:human-verify` 작업을 삽입한다**. 체크포인트에는 레지스트리 페이지로의 직접 링크와 살펴봐야 할 구체적인 항목들이 포함된다: 유지관리자 이력, 이슈 트래커 활동, 의심스러운 설치 스크립트의 부재.
**실행 단계.** 설치가 실패하면 `gsd-executor`는 **체크포인트를 표시하고 중지한다**. 대체 패키지 이름을 조용히 시도하지 않는다 — 그 자체가 악의적일 수 있다. 이는 실행기 동작의 명시적인 규칙이다(실행기 에이전트 정의의 RULE 3).
**실행 단계.** 설치가 실패하면 `msd-executor`는 **체크포인트를 표시하고 중지한다**. 대체 패키지 이름을 조용히 시도하지 않는다 — 그 자체가 악의적일 수 있다. 이는 실행기 동작의 명시적인 규칙이다(실행기 에이전트 정의의 RULE 3).
### WebSearch 패키지가 항상 `[ASSUMED]`인 이유
@@ -52,7 +52,7 @@ WebSearch를 통해 발견된 패키지 이름은 `npm view`가 성공하는지
### 정상적인 성능 저하
`slopcheck`을 사용할 수 없는 경우(설치되지 않았거나 리서치 시점에 pip 설치 실패), GSD는 가장 엄격한 폴백을 적용한다: **모든 추천 패키지가 `[ASSUMED]`로 태그되고**, 플래너는 모든 설치에 `checkpoint:human-verify` 작업을 게이트로 건다. 리서치와 계획 수립은 정상적으로 진행된다 — 시스템은 누락된 도구 의존성으로 인해 하드 실패하지 않는다. 이것은 의도적으로 정상 흐름보다 더 엄격하다: slopcheck 사용 불가는 모든 패키지 설치에 사람 체크포인트를 받는다는 것을 의미한다.
`slopcheck`을 사용할 수 없는 경우(설치되지 않았거나 리서치 시점에 pip 설치 실패), MSD는 가장 엄격한 폴백을 적용한다: **모든 추천 패키지가 `[ASSUMED]`로 태그되고**, 플래너는 모든 설치에 `checkpoint:human-verify` 작업을 게이트로 건다. 리서치와 계획 수립은 정상적으로 진행된다 — 시스템은 누락된 도구 의존성으로 인해 하드 실패하지 않는다. 이것은 의도적으로 정상 흐름보다 더 엄격하다: slopcheck 사용 불가는 모든 패키지 설치에 사람 체크포인트를 받는다는 것을 의미한다.
`slopcheck` 도구는 MIT 라이선스이며 pip으로 설치 가능하다. 유지 관리가 중단되더라도 `[ASSUMED]`-게이트 폴백은 사람 체크포인트 커버리지가 유지되도록 보장한다.
@@ -62,36 +62,36 @@ WebSearch를 통해 발견된 패키지 이름은 `npm view`가 성공하는지
### 위협
GSD Core는 LLM 시스템 프롬프트가 되는 마크다운 파일을 생성한다. 리서치 파이프라인은 외부 웹 콘텐츠를 읽는다; 계획 파이프라인은 사용자가 제공한 텍스트(`--text-file`, `--prd`)를 통합한다; 실행 파이프라인은 에이전트 컨텍스트로 나중에 다시 읽히는 계획 결과물을 작성한다. 이런 결과물들에 흐르는 사용자가 제어하는 텍스트는 잠재적인 **간접 프롬프트 인젝션** 벡터이다 — 시스템 프롬프트 안에 들어가면 에이전트의 지시 사항을 재정의하거나 정보를 유출하려는 공격자가 제어하는 문자열.
MSD Core는 LLM 시스템 프롬프트가 되는 마크다운 파일을 생성한다. 리서치 파이프라인은 외부 웹 콘텐츠를 읽는다; 계획 파이프라인은 사용자가 제공한 텍스트(`--text-file`, `--prd`)를 통합한다; 실행 파이프라인은 에이전트 컨텍스트로 나중에 다시 읽히는 계획 결과물을 작성한다. 이런 결과물들에 흐르는 사용자가 제어하는 텍스트는 잠재적인 **간접 프롬프트 인젝션** 벡터이다 — 시스템 프롬프트 안에 들어가면 에이전트의 지시 사항을 재정의하거나 정보를 유출하려는 공격자가 제어하는 문자열.
### 방어 작동 방식
GSD Core는 세 가지 수준에서 프롬프트 인젝션을 다룬다.
MSD Core는 세 가지 수준에서 프롬프트 인젝션을 다룬다.
**입력 유효성 검사(`security.cjs`).** `gsd-core/bin/lib/security.cjs` 모듈은 중앙 보안 유틸리티이다. 다음을 제공한다:
**입력 유효성 검사(`security.cjs`).** `msd-core/bin/lib/security.cjs` 모듈은 중앙 보안 유틸리티이다. 다음을 제공한다:
- 경로 탐색 방지: 사용자가 제공한 파일 경로(`--text-file`, `--prd`)가 프로젝트 디렉터리 내에서 해결되도록 유효성이 검사되며, macOS의 `/var` → `/private/var` 심링크 해결이 명시적으로 처리된다
- 프롬프트 인젝션 탐지: 알려진 인젝션 패턴(역할 재정의, 지시 우회, 시스템 태그 인젝션)이 사용자가 제공한 텍스트에서 계획 결과물에 들어가기 전에 스캔된다
- 안전한 JSON 파싱: 제작된 JSON 페이로드를 통한 프로토타입 오염 공격을 방지하는 래퍼
- 쉘 인수 유효성 검사: 하위 쉘 명령에 전달되는 인수가 사용 전에 유효성이 검사된다
**런타임 훅: `gsd-prompt-guard.js`.** 이 훅은 `.planning/` 파일을 대상으로 하는 모든 Write 또는 Edit 호출에서 실행된다. 작성되는 콘텐츠를 `security.cjs`와 동일한 인젝션 패턴으로 스캔한다(독립성을 위해 훅에 직접 인라인된 하위 집합 — 훅은 모듈 경로가 변경되더라도 실행되도록 모듈을 `require()`하지 않는다). 탐지는 **자문적 전용**이다: 훅은 결과를 로그하지만 쓰기를 차단하지 않는다. 이유는 합법적인 계획 쓰기에 대한 오탐지 차단이 이차 스캔 계층에서 놓친 인젝션보다 더 방해가 될 것이기 때문이다.
**런타임 훅: `msd-prompt-guard.js`.** 이 훅은 `.planning/` 파일을 대상으로 하는 모든 Write 또는 Edit 호출에서 실행된다. 작성되는 콘텐츠를 `security.cjs`와 동일한 인젝션 패턴으로 스캔한다(독립성을 위해 훅에 직접 인라인된 하위 집합 — 훅은 모듈 경로가 변경되더라도 실행되도록 모듈을 `require()`하지 않는다). 탐지는 **자문적 전용**이다: 훅은 결과를 로그하지만 쓰기를 차단하지 않는다. 이유는 합법적인 계획 쓰기에 대한 오탐지 차단이 이차 스캔 계층에서 놓친 인젝션보다 더 방해가 될 것이기 때문이다.
**런타임 훅: `gsd-read-injection-scanner.js`.** 이 훅은 모든 Read 도구 호출의 출력에서 실행된다. 방금 읽은 *콘텐츠*를 신뢰할 수 없는 콘텐츠의 주입된 지시 사항으로 스캔한다 — 공격자가 GSD가 에이전트 컨텍스트에 통합하려는 파일에 지시 사항을 내장한 경우를 잡아낸다.
**런타임 훅: `msd-read-injection-scanner.js`.** 이 훅은 모든 Read 도구 호출의 출력에서 실행된다. 방금 읽은 *콘텐츠*를 신뢰할 수 없는 콘텐츠의 주입된 지시 사항으로 스캔한다 — 공격자가 MSD가 에이전트 컨텍스트에 통합하려는 파일에 지시 사항을 내장한 경우를 잡아낸다.
**CI 스캐너.** `prompt-injection-scan.security.test.cjs`는 테스트 스위트의 일부로 내장된 인젝션 벡터가 있는지 모든 에이전트, 워크플로우, 명령 파일을 스캔한다. 이는 GSD 소스 자체의 인젝션 시도를 잡아낸다 — 예를 들어 워크플로우 파일을 수정하여 역할 재정의 지시 사항을 추가하는 공급망 공격.
**CI 스캐너.** `prompt-injection-scan.security.test.cjs`는 테스트 스위트의 일부로 내장된 인젝션 벡터가 있는지 모든 에이전트, 워크플로우, 명령 파일을 스캔한다. 이는 MSD 소스 자체의 인젝션 시도를 잡아낸다 — 예를 들어 워크플로우 파일을 수정하여 역할 재정의 지시 사항을 추가하는 공급망 공격.
### 읽기 인젝션 스캐너 vs 프롬프트 가드
두 훅은 보완적인 표면을 커버한다. `gsd-prompt-guard.js`는 *계획 결과물에 대한 쓰기*를 감시한다 — 심어지는 인젝션을 잡는다. `gsd-read-injection-scanner.js`는 *모든 파일의 읽기*를 감시한다 — 외부 콘텐츠(의존성의 README, 타사 설정 파일, 사용자가 제공한 문서)에서 수집되는 인젝션을 잡는다. 함께 수집 → 저장 → 재독 수명 주기를 괄호로 묶는다.
두 훅은 보완적인 표면을 커버한다. `msd-prompt-guard.js`는 *계획 결과물에 대한 쓰기*를 감시한다 — 심어지는 인젝션을 잡는다. `msd-read-injection-scanner.js`는 *모든 파일의 읽기*를 감시한다 — 외부 콘텐츠(의존성의 README, 타사 설정 파일, 사용자가 제공한 문서)에서 수집되는 인젝션을 잡는다. 함께 수집 → 저장 → 재독 수명 주기를 괄호로 묶는다.
---
## 계층 3 — 저장소 및 의존성 무결성
GSD의 런타임 동작 상류에서 `open-gsd` 조직은 저장소와 패키지 수준에서 제어를 시행한다. 이것들은 [`docs/security/baseline.md`](../../security/baseline.md)에 완전히 문서화되어 있으며 완전성을 위해 여기에 요약된다.
MSD의 런타임 동작 상류에서 `open-gsd` 조직은 저장소와 패키지 수준에서 제어를 시행한다. 이것들은 [`docs/security/baseline.md`](../../security/baseline.md)에 완전히 문서화되어 있으며 완전성을 위해 여기에 요약된다.
**의존성 무결성.** 모든 타사 의존성은 `package-lock.json`을 통해 고정되고 설치 전에 공개된 체크섬에 대해 검증된다. `scripts/check-npm-integrity.cjs` 게이트는 CI 시점에 유효하지 않은 버전, 누락된 패키지, 불필요한 패키지를 탐지한다. 이는 GSD 자체 의존성에 대한 의존성 혼동 및 오타스쿼팅 공격을 완화한다.
**의존성 무결성.** 모든 타사 의존성은 `package-lock.json`을 통해 고정되고 설치 전에 공개된 체크섬에 대해 검증된다. `scripts/check-npm-integrity.cjs` 게이트는 CI 시점에 유효하지 않은 버전, 누락된 패키지, 불필요한 패키지를 탐지한다. 이는 MSD 자체 의존성에 대한 의존성 혼동 및 오타스쿼팅 공격을 완화한다.
**비밀 스캔.** 모든 커밋과 PR은 하드코딩된 비밀이 있는지 스캔된다. 의도적인 테스트 픽스처는 프로젝트 표준 제외 문법으로 주석을 달아야 한다(주석 형식은 `SECURITY.md` 참조). 주석이 없는 억제는 CI를 실패시킨다.
@@ -117,7 +117,7 @@ GSD의 런타임 동작 상류에서 `open-gsd` 조직은 저장소와 패키지
## Related
- [명령어](../COMMANDS.md) — 보안 관련 플래그가 있는 `/gsd-secure-phase`와 `/gsd-code-review` 포함
- [명령어](../COMMANDS.md) — 보안 관련 플래그가 있는 `/msd-secure-phase`와 `/msd-code-review` 포함
- [아키텍처 § 훅 시스템](../ARCHITECTURE.md#hook-system) — 모든 훅, 이벤트 트리거, 안전 속성에 대한 구현 상세
- [SECURITY.md](../../../SECURITY.md) — 취약점 신고, 조직 전반 보안 기준선, 비밀 스캔 제외 거버넌스, 의존성 무결성 검증
- [문서 인덱스](../README.md)

10
docs/ko-KR/explanation/the-phase-loop.md
View File

@@ -1,12 +1,12 @@
# 단계 루프
> GSD Core가 작업을 조직하는 방식의 핵심 멘탈 모델.
> MSD Core가 작업을 조직하는 방식의 핵심 멘탈 모델.
---
## 루프란 무엇인가
GSD Core는 모든 개발 작업을 반복되는 사이클로 구조화한다.
MSD Core는 모든 개발 작업을 반복되는 사이클로 구조화한다.
```text
논의 → (UI 디자인) → 계획 → 실행 → 검증 → 출시
@@ -30,7 +30,7 @@ GSD Core는 모든 개발 작업을 반복되는 사이클로 구조화한다.
### UI 디자인(선택적)
시각적 컴포넌트가 있는 단계의 경우, 논의와 계획 사이에 선택적인 `/gsd-ui-phase` 단계가 있다. 코드 작성 전에 레이아웃, 인터랙션, 시각적 동작을 설명하는 디자인 계약인 `UI-SPEC.md`를 생성한다. UI가 복잡하여 디자인의 모호함이 다양한 구현 선택을 만들어낼 만큼 복잡할 때 이 단계를 실행할 가치가 있다. 명확한 디자인 계약은 재구현보다 훨씬 비용이 저렴하다.
시각적 컴포넌트가 있는 단계의 경우, 논의와 계획 사이에 선택적인 `/msd-ui-phase` 단계가 있다. 코드 작성 전에 레이아웃, 인터랙션, 시각적 동작을 설명하는 디자인 계약인 `UI-SPEC.md`를 생성한다. UI가 복잡하여 디자인의 모호함이 다양한 구현 선택을 만들어낼 만큼 복잡할 때 이 단계를 실행할 가치가 있다. 명확한 디자인 계약은 재구현보다 훨씬 비용이 저렴하다.
### 계획(Plan)
@@ -87,7 +87,7 @@ GSD Core는 모든 개발 작업을 반복되는 사이클로 구조화한다.
- 실행이 수십 개가 아니라 소수의 겹치지 않는 계획들로 병렬화될 수 있다.
- 검증기가 전체 코드베이스를 읽지 않고도 확인할 수 있는 명확하고 테스트 가능한 완료 정의가 있다.
구체적으로: "HMAC-SHA256 서명 검증 미들웨어 추가"는 좋은 단계 범위이다. "인증 시스템 구축"은 일반적으로 아니다 — 거의 항상 별도의 단계로 더 잘 처리될 여러 독립적인 관심사들을 포함한다. "README의 오타 수정"은 루프가 가치를 추가하는 임계값 아래이다; 대신 `/gsd-quick`을 사용하라.
구체적으로: "HMAC-SHA256 서명 검증 미들웨어 추가"는 좋은 단계 범위이다. "인증 시스템 구축"은 일반적으로 아니다 — 거의 항상 별도의 단계로 더 잘 처리될 여러 독립적인 관심사들을 포함한다. "README의 오타 수정"은 루프가 가치를 추가하는 임계값 아래이다; 대신 `/msd-quick`을 사용하라.
의심스러울 때는 분할하라. 더 작은 단계는 더 빨리 완료되고, 더 자신 있게 검증되고, 설계 결정이 잘못된 것으로 판명될 경우 방향을 수정하기 더 쉽다.
@@ -113,7 +113,7 @@ GSD Core는 모든 개발 작업을 반복되는 사이클로 구조화한다.
루프가 잘 작동할 때 리듬처럼 느껴진다: 각 단계가 이전 단계가 자신의 역할을 했기 때문에 명확한, 집중적이고 범위가 한정된 작업의 박자. 오버헤드는 실재하지만, 전면 부담된다 — 수 시간의 재작업이 아니라 몇 분의 계획으로 지불된다.
루프가 정당화되는 임계값 아래의 작업을 위해 GSD Core는 더 가벼운 기본 도구들을 제공한다. 단계 루프는 하나의 도구이지, 유일한 도구가 아니다.
루프가 정당화되는 임계값 아래의 작업을 위해 MSD Core는 더 가벼운 기본 도구들을 제공한다. 단계 루프는 하나의 도구이지, 유일한 도구가 아니다.
---

48
docs/ko-KR/how-to/configure-model-profiles.md
View File

@@ -6,7 +6,7 @@
## 네 가지 프로파일 (`adaptive`와 `inherit` 포함)
`.planning/config.json`에서 `model_profile`을 설정하거나 `/gsd-config --profile <name>`을 사용하세요:
`.planning/config.json`에서 `model_profile`을 설정하거나 `/msd-config --profile <name>`을 사용하세요:
| 프로파일 | 플래너 | 실행자 | 리서처 | 검증자 | 사용 시기 |
|---------|---------|----------|-------------|----------|----------|
@@ -16,15 +16,15 @@
| `adaptive` | Opus | Sonnet | Sonnet | Sonnet | 런타임 간 자주 전환할 때 사용; 다른 티어와 동일하게 런타임 인식 프로파일로 해결됨 |
| `inherit` | (세션 모델) | (세션 모델) | (세션 모델) | (세션 모델) | 비 Anthropic 프로바이더(OpenRouter, 로컬 모델) — 모든 에이전트가 현재 세션 모델을 따름 |
위 테이블은 대표적인 하위 집합을 보여줍니다. 출시된 33개 에이전트 모두 `gsd-core/bin/shared/model-catalog.json`에 명시적인 프로파일별 티어 할당이 있습니다. 전체 테이블은 설정 참조의 [모델 프로파일](../CONFIGURATION.md#model-profiles)을 참고하세요.
위 테이블은 대표적인 하위 집합을 보여줍니다. 출시된 33개 에이전트 모두 `msd-core/bin/shared/model-catalog.json`에 명시적인 프로파일별 티어 할당이 있습니다. 전체 테이블은 설정 참조의 [모델 프로파일](../CONFIGURATION.md#model-profiles)을 참고하세요.
**명령으로 빠르게 전환:**
```bash
/gsd-config --profile balanced # 일반 개발
/gsd-config --profile budget # 프로토타이핑 또는 고비용 페이즈
/gsd-config --profile quality # 프로덕션 릴리스
/gsd-config --profile inherit # OpenRouter, 로컬 모델
/msd-config --profile balanced # 일반 개발
/msd-config --profile budget # 프로토타이핑 또는 고비용 페이즈
/msd-config --profile quality # 프로덕션 릴리스
/msd-config --profile inherit # OpenRouter, 로컬 모델
```
**또는 `.planning/config.json` 직접 편집:**
@@ -45,20 +45,20 @@
{
"model_profile": "balanced",
"model_overrides": {
"gsd-executor": "opus",
"gsd-codebase-mapper": "haiku"
"msd-executor": "opus",
"msd-codebase-mapper": "haiku"
}
}
```
유효한 값: `opus`, `sonnet`, `haiku`, `inherit`, 또는 완전히 정규화된 모델 ID (예: `"openai/o3"`, `"google/gemini-2.5-pro"`).
`model_overrides`는 `.planning/config.json`에서 프로젝트별로 설정하거나 `~/.gsd/defaults.json`에서 전역으로 설정할 수 있습니다. 충돌 시 프로젝트별 항목이 우선하며, 충돌하지 않는 전역 항목은 보존됩니다.
`model_overrides`는 `.planning/config.json`에서 프로젝트별로 설정하거나 `~/.msd/defaults.json`에서 전역으로 설정할 수 있습니다. 충돌 시 프로젝트별 항목이 우선하며, 충돌하지 않는 전역 항목은 보존됩니다.
**Codex와 OpenCode의 중요 사항:** 이러한 런타임은 설치 시 해결된 모델을 각 에이전트의 정적 설정에 임베드합니다. `model_overrides` 편집 후 변경 사항이 적용되도록 인스톨러를 다시 실행하세요:
```bash
npx @opengsd/gsd-core@latest --codex --global # 또는 --opencode, --kilo 등
npx @golem15/msd-core@latest --codex --global # 또는 --opencode, --kilo 등
```
---
@@ -85,11 +85,11 @@ npx @opengsd/gsd-core@latest --codex --global # 또는 --opencode, --kilo 등
| 페이즈 유형 | 포함된 에이전트 |
|---|---|
| `planning` | `gsd-planner`, `gsd-roadmapper`, `gsd-pattern-mapper` |
| `research` | `gsd-phase-researcher`, `gsd-project-researcher`, `gsd-research-synthesizer`, `gsd-codebase-mapper`, `gsd-ui-researcher` |
| `execution` | `gsd-executor`, `gsd-debugger`, `gsd-doc-writer` |
| `verification` | `gsd-verifier`, `gsd-plan-checker`, `gsd-integration-checker`, `gsd-nyquist-auditor`, `gsd-ui-checker`, `gsd-ui-auditor`, `gsd-doc-verifier`, `gsd-code-reviewer` |
| `discuss` | `gsd-assumptions-analyzer` |
| `planning` | `msd-planner`, `msd-roadmapper`, `msd-pattern-mapper` |
| `research` | `msd-phase-researcher`, `msd-project-researcher`, `msd-research-synthesizer`, `msd-codebase-mapper`, `msd-ui-researcher` |
| `execution` | `msd-executor`, `msd-debugger`, `msd-doc-writer` |
| `verification` | `msd-verifier`, `msd-plan-checker`, `msd-integration-checker`, `msd-nyquist-auditor`, `msd-ui-checker`, `msd-ui-auditor`, `msd-doc-verifier`, `msd-code-reviewer` |
| `discuss` | `msd-assumptions-analyzer` |
| `completion` | 예약됨 — 현재 서브에이전트 없음; 향후 호환성을 위해 스키마에서 허용 |
`models` 블록은 티어 별칭만 허용합니다(`opus`, `sonnet`, `haiku`, `inherit`). 완전히 정규화된 모델 ID는 에이전트별 `model_overrides`를 사용하세요.
@@ -103,12 +103,12 @@ npx @opengsd/gsd-core@latest --codex --global # 또는 --opencode, --kilo 등
"research": "sonnet"
},
"model_overrides": {
"gsd-codebase-mapper": "haiku"
"msd-codebase-mapper": "haiku"
}
}
```
5개의 리서치 에이전트 모두 `sonnet`으로 해결되지만, `gsd-codebase-mapper`는 `haiku`로 고정됩니다.
5개의 리서치 에이전트 모두 `sonnet`으로 해결되지만, `msd-codebase-mapper`는 `haiku`로 고정됩니다.
---
@@ -131,7 +131,7 @@ npx @opengsd/gsd-core@latest --codex --global # 또는 --opencode, --kilo 등
}
```
각 에이전트에는 기본 티어(`light`, `standard`, `heavy`)가 있습니다. 첫 번째 시도에서 GSD는 `tier_models[default_tier]`를 선택합니다. 오케스트레이터가 소프트 실패(검증 불확실, 플랜 체크 플래그 등)를 감지하면 한 티어 위로 에이전트를 재실행합니다. `max_escalations`는 총 재시도 횟수를 제한합니다.
각 에이전트에는 기본 티어(`light`, `standard`, `heavy`)가 있습니다. 첫 번째 시도에서 MSD는 `tier_models[default_tier]`를 선택합니다. 오케스트레이터가 소프트 실패(검증 불확실, 플랜 체크 플래그 등)를 감지하면 한 티어 위로 에이전트를 재실행합니다. `max_escalations`는 총 재시도 횟수를 제한합니다.
이미 `heavy`에 있는 에이전트는 더 이상 에스컬레이션할 수 없습니다.
@@ -152,9 +152,9 @@ npx @opengsd/gsd-core@latest --codex --global # 또는 --opencode, --kilo 등
---
## 비 Anthropic 런타임에서 GSD 사용
## 비 Anthropic 런타임에서 MSD 사용
Codex, OpenCode, Antigravity CLI, 또는 Kilo용으로 GSD를 설치한 경우 인스톨러가 이미 설정에 `resolve_model_ids: "omit"`을 설정했습니다. 이는 GSD가 Anthropic 모델 ID 해결을 건너뛰고 런타임이 자체 기본 모델을 선택하도록 합니다. 기본 사용 시 수동 설정이 필요 없습니다.
Codex, OpenCode, Antigravity CLI, 또는 Kilo용으로 MSD를 설치한 경우 인스톨러가 이미 설정에 `resolve_model_ids: "omit"`을 설정했습니다. 이는 MSD가 Anthropic 모델 ID 해결을 건너뛰고 런타임이 자체 기본 모델을 선택하도록 합니다. 기본 사용 시 수동 설정이 필요 없습니다.
**Codex에서 티어별 모델을 원하는 경우:**
@@ -165,7 +165,7 @@ Codex, OpenCode, Antigravity CLI, 또는 Kilo용으로 GSD를 설치한 경우
}
```
GSD는 각 티어 별칭을 런타임 티어 맵에 정의된 Codex 네이티브 모델 및 추론 노력으로 해결합니다.
MSD는 각 티어 별칭을 런타임 티어 맵에 정의된 Codex 네이티브 모델 및 추론 노력으로 해결합니다.
**비 Claude 런타임에서 에이전트별 모델 ID를 원하는 경우:**
@@ -173,9 +173,9 @@ GSD는 각 티어 별칭을 런타임 티어 맵에 정의된 Codex 네이티브
{
"resolve_model_ids": "omit",
"model_overrides": {
"gsd-planner": "o3",
"gsd-executor": "o4-mini",
"gsd-debugger": "o3"
"msd-planner": "o3",
"msd-executor": "o4-mini",
"msd-debugger": "o3"
}
}
```

54
docs/ko-KR/how-to/debug-a-failed-execution.md
View File

@@ -2,7 +2,7 @@
**목표:** 페이즈 실행이 실패하거나, 멈추거나, 불완전한 결과를 생성했을 때 — 이미 성공한 작업을 잃거나 반복하지 않고 깔끔하게 복구하고 재개합니다.
**사전 조건:** `/gsd-execute-phase N`을 실행했는데 `VERIFICATION.md` 작성 전에 실행이 중단된 경우, 또는 예상치 못한 출력, 누락된 파일, 멈춘 스피너가 보이는 경우.
**사전 조건:** `/msd-execute-phase N`을 실행했는데 `VERIFICATION.md` 작성 전에 실행이 중단된 경우, 또는 예상치 못한 출력, 누락된 파일, 멈춘 스피너가 보이는 경우.
---
@@ -12,15 +12,15 @@
### "Spawning…"만 표시되고 1~5분 후에도 출력이 없는 경우
이것은 정상 동작이며 멈춤이 아닙니다. GSD 서브에이전트는 격리된 컨텍스트 창에서 실행됩니다. 스폰 라인의 활성 상태 메모가 이를 확인해 줍니다. 세션을 중단하지 마세요.
이것은 정상 동작이며 멈춤이 아닙니다. MSD 서브에이전트는 격리된 컨텍스트 창에서 실행됩니다. 스폰 라인의 활성 상태 메모가 이를 확인해 줍니다. 세션을 중단하지 마세요.
10분 이상 결과가 없다면 Claude Code 사이드바를 확인하세요. 에이전트 작업이 완료된 것으로 표시되지만 출력이 나타나지 않았다면 컨텍스트 전환에서 결과가 손실되었을 수 있습니다 — 동일한 명령을 다시 실행합니다:
```bash
/gsd-execute-phase 1
/msd-execute-phase 1
```
GSD는 실행자를 디스패치하기 전에 `SUMMARY.md` 파일이 있는지 확인합니다. 이미 `SUMMARY.md`가 있는 플랜은 자동으로 건너뜁니다.
MSD는 실행자를 디스패치하기 전에 `SUMMARY.md` 파일이 있는지 확인합니다. 이미 `SUMMARY.md`가 있는 플랜은 자동으로 건너뜁니다.
### 실행이 오류 메시지와 함께 파동 중간에 중단된 경우
@@ -34,7 +34,7 @@ git log --oneline -20
### 실행자가 코드를 커밋했지만 SUMMARY.md를 작성하지 않은 경우
GSD는 다음 실행 시 이를 감지하고 세 가지 옵션이 있는 안전 재개 게이트를 표시합니다:
MSD는 다음 실행 시 이를 감지하고 세 가지 옵션이 있는 안전 재개 게이트를 표시합니다:
- **수동으로 마무리** — 커밋을 직접 검사하고 `SUMMARY.md`를 작성한 후 재실행합니다.
- **처음부터 재실행** — 새 실행자를 디스패치하기 전에 부분 커밋을 되돌리거나 대체합니다.
@@ -44,12 +44,12 @@ GSD는 다음 실행 시 이를 감지하고 세 가지 옵션이 있는 안전
## 근본 원인 진단
### `/gsd-debug --diagnose` 실행
### `/msd-debug --diagnose` 실행
실행이 잘못된 출력, 스텁 코드, 또는 검증 실패를 생성한 경우 수정을 적용하지 않고 조사만 하는 진단 모드를 사용합니다:
```bash
/gsd-debug --diagnose "Phase 2 executor produced stubs instead of real code"
/msd-debug --diagnose "Phase 2 executor produced stubs instead of real code"
```
`--diagnose`는 파일을 건드리지 않고 근본 원인에서 멈춥니다. 나중에 조사를 이어갈 수 있도록 `.planning/debug/<slug>.md`에 세션 파일을 생성합니다.
@@ -57,36 +57,36 @@ GSD는 다음 실행 시 이를 감지하고 세 가지 옵션이 있는 안전
수정도 적용하는 전체 디버그 세션을 시작하려면:
```bash
/gsd-debug "Login middleware not handling 401 correctly after phase 3"
/msd-debug "Login middleware not handling 401 correctly after phase 3"
```
GSD는 증상을 수집하고, 과학적 방법을 사용한 구조화된 조사를 실행하며, 수정안을 제안합니다. 설정에서 `tdd_mode: true`가 지정된 경우 수정을 적용하기 전에 실패하는 테스트를 요구합니다.
MSD는 증상을 수집하고, 과학적 방법을 사용한 구조화된 조사를 실행하며, 수정안을 제안합니다. 설정에서 `tdd_mode: true`가 지정된 경우 수정을 적용하기 전에 실패하는 테스트를 요구합니다.
### 활성 디버그 세션 확인
```bash
/gsd-debug list
/msd-debug list
```
현재 가설과 다음 조치를 포함한 모든 열린 세션을 표시합니다. 특정 세션을 재개하려면:
```bash
/gsd-debug continue <slug>
/msd-debug continue <slug>
```
---
## `/gsd-forensics`로 사후 분석 실행
## `/msd-forensics`로 사후 분석 실행
오류 출력에서 원인이 명확하지 않은 경우 — 예를 들어, 플랜이 존재하지 않는 파일을 참조하거나, 실행이 예상치 못한 결과를 생성하거나, 상태가 손상된 것 같은 경우 — 포렌식 조사를 실행합니다:
```bash
/gsd-forensics "Phase 3 execution stalled after wave 1"
/msd-forensics "Phase 3 execution stalled after wave 1"
```
GSD는 git 히스토리, `.planning/` 아티팩트 완전성, STATE.md 일관성, 커밋되지 않은 작업, 고아 워크트리를 분석합니다. `.planning/forensics/report-<timestamp>.md`에 구조화된 보고서를 작성하고 권장 복구 단계를 제시합니다.
MSD는 git 히스토리, `.planning/` 아티팩트 완전성, STATE.md 일관성, 커밋되지 않은 작업, 고아 워크트리를 분석합니다. `.planning/forensics/report-<timestamp>.md`에 구조화된 보고서를 작성하고 권장 복구 단계를 제시합니다.
`/gsd-forensics`는 읽기 전용으로 프로젝트 파일을 절대 수정하지 않습니다.
`/msd-forensics`는 읽기 전용으로 프로젝트 파일을 절대 수정하지 않습니다.
**감지 항목:**
@@ -103,46 +103,46 @@ GSD는 git 히스토리, `.planning/` 아티팩트 완전성, STATE.md 일관성
근본적인 문제가 해결되면 실행 명령을 다시 실행합니다:
```bash
/gsd-execute-phase 1
/msd-execute-phase 1
```
GSD는 이미 `SUMMARY.md`가 존재하는 플랜을 건너뛰고 나머지 플랜에 대해서만 실행자를 디스패치합니다.
MSD는 이미 `SUMMARY.md`가 존재하는 플랜을 건너뛰고 나머지 플랜에 대해서만 실행자를 디스패치합니다.
특정 파동만 재실행해야 하는 경우:
```bash
/gsd-execute-phase 1 --wave 2
/msd-execute-phase 1 --wave 2
```
---
## `/gsd-undo`로 롤백
## `/msd-undo`로 롤백
실행이 전적으로 버리고 싶은 코드를 생성한 경우, 수동 `git revert` 대신 플랜 매니페스트를 사용하여 롤백합니다:
### 단일 플랜 롤백
```bash
/gsd-undo --plan 03-02
/msd-undo --plan 03-02
```
페이즈 `3`의 플랜 `02`에 대한 모든 커밋을 되돌립니다. GSD는 변경 사항을 작성하기 전에 확인 게이트를 표시합니다.
페이즈 `3`의 플랜 `02`에 대한 모든 커밋을 되돌립니다. MSD는 변경 사항을 작성하기 전에 확인 게이트를 표시합니다.
### 전체 페이즈 롤백
```bash
/gsd-undo --phase 03
/msd-undo --phase 03
```
페이즈 `3`의 모든 커밋을 되돌립니다. GSD는 이후 페이즈가 이 페이즈에 의존하는지 확인하고 진행 전에 경고합니다.
페이즈 `3`의 모든 커밋을 되돌립니다. MSD는 이후 페이즈가 이 페이즈에 의존하는지 확인하고 진행 전에 경고합니다.
### 최근 커밋에서 대화식으로 선택
```bash
/gsd-undo --last 5
/msd-undo --last 5
```
가장 최근 GSD 커밋 다섯 개를 표시하고 어떤 것을 되돌릴지 선택할 수 있게 합니다.
가장 최근 MSD 커밋 다섯 개를 표시하고 어떤 것을 되돌릴지 선택할 수 있게 합니다.
---
@@ -151,7 +151,7 @@ GSD는 이미 `SUMMARY.md`가 존재하는 플랜을 건너뛰고 나머지 플
컨텍스트 초기화나 새 세션 후 프로젝트로 돌아온 경우:
```bash
/gsd-resume-work
/msd-resume-work
```
마지막 핸드오프의 전체 세션 컨텍스트(현재 페이즈, 블로커, 실행이 중단된 위치)를 복원합니다.
@@ -159,7 +159,7 @@ GSD는 이미 `SUMMARY.md`가 존재하는 플랜을 건너뛰고 나머지 플
또는 현재 위치를 확인하고 다음 올바른 단계로 자동 진행하려면:
```bash
/gsd-progress --next
/msd-progress --next
```
---

52
docs/ko-KR/how-to/design-a-ui-phase.md
View File

@@ -2,13 +2,13 @@
**목표:** 플래너가 작업을 작성하기 전에 간격, 색상, 타이포그래피, 카피라이팅 결정을 확정하는 잠긴 UI 디자인 계약(`UI-SPEC.md`)을 생성하여 실행 중 임의적인 스타일링 선택으로 인한 시각적 불일관성을 방지합니다.
**사전 조건:** `.planning/ROADMAP.md`가 존재해야 합니다. 페이즈에 프론트엔드 또는 UI 작업이 있어야 합니다. 먼저 `/gsd-discuss-phase N`을 실행하는 것을 강력히 권장합니다 — UI 연구자는 `CONTEXT.md`를 읽어 이미 결정된 사항을 다시 묻지 않습니다.
**사전 조건:** `.planning/ROADMAP.md`가 존재해야 합니다. 페이즈에 프론트엔드 또는 UI 작업이 있어야 합니다. 먼저 `/msd-discuss-phase N`을 실행하는 것을 강력히 권장합니다 — UI 연구자는 `CONTEXT.md`를 읽어 이미 결정된 사항을 다시 묻지 않습니다.
---
## 이 페이즈에 UI 계약이 필요한지 결정
모든 페이즈가 `/gsd-ui-phase`를 필요로 하지는 않습니다. 다음 경우에 사용합니다:
모든 페이즈가 `/msd-ui-phase`를 필요로 하지는 않습니다. 다음 경우에 사용합니다:
- 페이즈가 새로운 UI 표면(페이지, 흐름, 레이아웃)을 도입할 때
- 여러 컴포넌트를 빌드하며 시각적 일관성이 중요할 때
@@ -20,22 +20,22 @@
- 페이즈가 순전히 백엔드, 인프라, 또는 사용자 대면 출력이 없는 데이터 작업일 때
- 이전 페이즈에서 이미 `UI-SPEC.md`가 존재하고 이 페이즈가 새로운 표면을 도입하지 않고 동일한 시각적 패턴 위에 빌드될 때
확신이 없으면 안전 게이트가 프롬프트를 표시합니다: `workflow.ui_safety_gate`가 활성화된 경우(기본값), `/gsd-plan-phase`는 프론트엔드 작업을 감지했지만 `UI-SPEC.md`가 없을 때 경고하고 먼저 `/gsd-ui-phase`를 실행할지 물어봅니다.
확신이 없으면 안전 게이트가 프롬프트를 표시합니다: `workflow.ui_safety_gate`가 활성화된 경우(기본값), `/msd-plan-phase`는 프론트엔드 작업을 감지했지만 `UI-SPEC.md`가 없을 때 경고하고 먼저 `/msd-ui-phase`를 실행할지 물어봅니다.
---
## UI 디자인 계약 실행
```bash
/gsd-ui-phase 2
/msd-ui-phase 2
```
페이즈 번호가 지정되지 않으면 GSD Core는 현재 페이즈를 대상으로 합니다.
페이즈 번호가 지정되지 않으면 MSD Core는 현재 페이즈를 대상으로 합니다.
명령은 두 단계로 실행됩니다:
1. **`gsd-ui-researcher`** — `CONTEXT.md`, `RESEARCH.md`, `REQUIREMENTS.md`에서 기존 결정을 읽고, 디자인 시스템 상태(shadcn `components.json`, Tailwind 설정, 기존 토큰)를 감지하며, 간격, 색상, 타이포그래피, 카피라이팅, 레지스트리 안전성 다섯 영역에 걸쳐 답하지 않은 디자인 질문만 묻습니다.
2. **`gsd-ui-checker`** — 결과로 생성된 `UI-SPEC.md`를 일곱 가지 차원에서 검증합니다. 문제가 발견되면 수정 루프가 플래그된 항목만을 대상으로 연구자를 다시 실행합니다(최대 두 번 반복).
1. **`msd-ui-researcher`** — `CONTEXT.md`, `RESEARCH.md`, `REQUIREMENTS.md`에서 기존 결정을 읽고, 디자인 시스템 상태(shadcn `components.json`, Tailwind 설정, 기존 토큰)를 감지하며, 간격, 색상, 타이포그래피, 카피라이팅, 레지스트리 안전성 다섯 영역에 걸쳐 답하지 않은 디자인 질문만 묻습니다.
2. **`msd-ui-checker`** — 결과로 생성된 `UI-SPEC.md`를 일곱 가지 차원에서 검증합니다. 문제가 발견되면 수정 루프가 플래그된 항목만을 대상으로 연구자를 다시 실행합니다(최대 두 번 반복).
**출력:** `.planning/phases/{phase-dir}/`의 `{padded_phase}-UI-SPEC.md`.
@@ -53,7 +53,7 @@
| **카피라이팅** | CTA 레이블, 빈 상태 메시지, 오류 상태 복사, 로딩 인디케이터 |
| **레지스트리 안전성** | shadcn 컴포넌트 검사 프로토콜(아래 참조) |
체커는 일곱 가지 차원(카피라이팅, 시각적, 색상, 타이포그래피, 간격, 레지스트리 안전, 인벤토리 출처)에 대해 스펙을 검증하며 각 차원마다 PASS, FLAG 또는 BLOCK을 반환합니다. (1~4점으로 채점하는 6가지 기둥 루브릭은 이 체커가 아니라 `/gsd-ui-review`의 소급 감사에 속합니다.)
체커는 일곱 가지 차원(카피라이팅, 시각적, 색상, 타이포그래피, 간격, 레지스트리 안전, 인벤토리 출처)에 대해 스펙을 검증하며 각 차원마다 PASS, FLAG 또는 BLOCK을 반환합니다. (1~4점으로 채점하는 6가지 기둥 루브릭은 이 체커가 아니라 `/msd-ui-review`의 소급 감사에 속합니다.)
---
@@ -69,7 +69,7 @@ React, Next.js, Vite 프로젝트에서 `components.json`이 없으면 연구자
npx shadcn init --preset <paste>
```
프리셋 문자열은 페이즈와 마일스톤 간에 재현 가능한 GSD Core 계획 아티팩트가 됩니다.
프리셋 문자열은 페이즈와 마일스톤 간에 재현 가능한 MSD Core 계획 아티팩트가 됩니다.
---
@@ -82,13 +82,13 @@ npx shadcn view <component> # 설치 전 소스 검사
npx shadcn diff <component> # 공식 레지스트리와 비교
```
레지스트리 안전성이 처리되지 않으면 체커가 스펙을 BLOCKED로 표시합니다. 프로젝트에서 shadcn을 사용하지 않거나 대체 검토 프로세스가 있는 경우 `/gsd-settings`를 통해 게이트를 비활성화합니다.
레지스트리 안전성이 처리되지 않으면 체커가 스펙을 BLOCKED로 표시합니다. 프로젝트에서 shadcn을 사용하지 않거나 대체 검토 프로세스가 있는 경우 `/msd-settings`를 통해 게이트를 비활성화합니다.
---
## 스케치 결과를 초안으로 활용
이미 `/gsd-sketch --wrap-up`을 실행한 경우, UI 연구자는 `.claude/skills/sketch-findings-[project]/`를 자동으로 로드합니다. 사전 검증된 결정(레이아웃, 팔레트, 타이포그래피, 간격)은 확정된 것으로 처리됩니다 — 연구자가 다시 묻지 않습니다. 실행 시작 시 메모가 표시됩니다:
이미 `/msd-sketch --wrap-up`을 실행한 경우, UI 연구자는 `.claude/skills/sketch-findings-[project]/`를 자동으로 로드합니다. 사전 검증된 결정(레이아웃, 팔레트, 타이포그래피, 간격)은 확정된 것으로 처리됩니다 — 연구자가 다시 묻지 않습니다. 실행 시작 시 메모가 표시됩니다:
```text
⚡ Sketch findings detected: .claude/skills/sketch-findings-[project]/SKILL.md
@@ -96,20 +96,20 @@ npx shadcn diff <component> # 공식 레지스트리와 비교
as locked — not re-asked.
```
`/gsd-ui-phase` 전에 `/gsd-sketch --wrap-up`을 실행하는 주된 이유입니다: 대화식 디자인 탐색을 계약 입력으로 바인딩합니다.
`/msd-ui-phase` 전에 `/msd-sketch --wrap-up`을 실행하는 주된 이유입니다: 대화식 디자인 탐색을 계약 입력으로 바인딩합니다.
---
## `/gsd-ui-review`로 소급 시각적 감사
## `/msd-ui-review`로 소급 시각적 감사
`/gsd-ui-review`는 실행 전이 아닌 실행 후에 실행됩니다. UI-SPEC(또는 스펙이 없을 때는 추상적인 6가지 기둥 기준)에 대해 구현된 프론트엔드를 감사하는 데 사용합니다.
`/msd-ui-review`는 실행 전이 아닌 실행 후에 실행됩니다. UI-SPEC(또는 스펙이 없을 때는 추상적인 6가지 기둥 기준)에 대해 구현된 프론트엔드를 감사하는 데 사용합니다.
```bash
/gsd-ui-review # 현재 페이즈 감사
/gsd-ui-review 3 # 특정 페이즈 3 감사
/msd-ui-review # 현재 페이즈 감사
/msd-ui-review 3 # 특정 페이즈 3 감사
```
프론트엔드 코드가 있는 모든 프로젝트에서 작동합니다 — GSD 프로젝트 초기화가 필요하지 않습니다.
프론트엔드 코드가 있는 모든 프로젝트에서 작동합니다 — MSD 프로젝트 초기화가 필요하지 않습니다.
**검사 항목(6가지 기둥, 각 1~4점 채점):**
@@ -120,24 +120,24 @@ npx shadcn diff <component> # 공식 레지스트리와 비교
5. 간격 — 그리드 정렬, 토큰 일관성
6. 경험 디자인 — 로딩, 오류, 빈 상태 커버리지
**출력:** 점수와 우선순위 상위 세 가지 수정 사항이 포함된 `{padded_phase}-UI-REVIEW.md`. `gsd-browser`와 같은 브라우저 MCP 서버가 구성된 경우 감사는 시각적 증거와 함께 스크린샷도 캡처합니다.
**출력:** 점수와 우선순위 상위 세 가지 수정 사항이 포함된 `{padded_phase}-UI-REVIEW.md`. `msd-browser`와 같은 브라우저 MCP 서버가 구성된 경우 감사는 시각적 증거와 함께 스크린샷도 캡처합니다.
**스크린샷 저장:** 스크린샷은 `.planning/ui-reviews/`에 저장됩니다. 바이너리 파일이 git에 올라가지 않도록 `.gitignore`가 자동으로 생성됩니다. 스크린샷은 `/gsd-complete-milestone` 중에 정리됩니다.
**스크린샷 저장:** 스크린샷은 `.planning/ui-reviews/`에 저장됩니다. 바이너리 파일이 git에 올라가지 않도록 `.gitignore`가 자동으로 생성됩니다. 스크린샷은 `/msd-complete-milestone` 중에 정리됩니다.
---
## 페이즈 생명주기에서 권장 위치
```text
/gsd-discuss-phase N ← 구현 선호도 확정
/gsd-ui-phase N ← 디자인 계약 확정 (프론트엔드 페이즈)
/gsd-plan-phase N ← 연구 + 계획 (UI-SPEC.md를 컨텍스트로 읽음)
/gsd-execute-phase N ← 병렬 실행
/gsd-verify-work N ← 수동 UAT
/gsd-ui-review N ← 소급 시각적 감사 (선택 사항이지만 권장)
/msd-discuss-phase N ← 구현 선호도 확정
/msd-ui-phase N ← 디자인 계약 확정 (프론트엔드 페이즈)
/msd-plan-phase N ← 연구 + 계획 (UI-SPEC.md를 컨텍스트로 읽음)
/msd-execute-phase N ← 병렬 실행
/msd-verify-work N ← 수동 UAT
/msd-ui-review N ← 소급 시각적 감사 (선택 사항이지만 권장)
```
`/gsd-ui-phase`는 토론과 계획 사이에 위치합니다. 플래너가 `UI-SPEC.md`를 디자인 컨텍스트로 읽기 때문입니다 — `PLAN.md`의 작업은 스펙이 확정한 간격 토큰, 색상 변수, 카피라이팅 결정을 참조합니다.
`/msd-ui-phase`는 토론과 계획 사이에 위치합니다. 플래너가 `UI-SPEC.md`를 디자인 컨텍스트로 읽기 때문입니다 — `PLAN.md`의 작업은 스펙이 확정한 간격 토큰, 색상 변수, 카피라이팅 결정을 참조합니다.
---

32
docs/ko-KR/how-to/discuss-a-phase.md
View File

@@ -2,18 +2,18 @@
**목표:** 기획이 시작되기 전에 페이즈에 필요한 구현 결정을 수집합니다. 이를 통해 리서처와 플래너가 다시 질문하지 않고도 작업할 수 있습니다.
**전제 조건:** `.planning/ROADMAP.md`가 존재해야 합니다. 없다면 먼저 `/gsd-new-project`를 실행하세요.
**전제 조건:** `.planning/ROADMAP.md`가 존재해야 합니다. 없다면 먼저 `/msd-new-project`를 실행하세요.
---
## 논의 모드 선택
GSD Core는 두 가지 모드를 제공합니다. 코드베이스에 대한 이해도에 따라 선택하세요.
MSD Core는 두 가지 모드를 제공합니다. 코드베이스에 대한 이해도에 따라 선택하세요.
**구현 방향을 직접 표현하고 싶은 경우** (인터뷰 모드, 기본값):
```bash
/gsd-discuss-phase 2
/msd-discuss-phase 2
```
Claude는 페이즈 범위의 모호한 영역을 파악하고, 논의할 항목을 선택하도록 안내한 후 각 영역당 약 4개의 질문을 순서대로 처리합니다.
@@ -21,8 +21,8 @@ Claude는 페이즈 범위의 모호한 영역을 파악하고, 논의할 항목
**코드베이스에 명확한 패턴이 있고 대부분의 질문이 자명한 경우** (가정 모드):
```bash
node gsd-tools.cjs config-set workflow.discuss_mode assumptions
/gsd-discuss-phase 2
node msd-tools.cjs config-set workflow.discuss_mode assumptions
/msd-discuss-phase 2
```
Claude는 서브에이전트를 통해 관련 코드베이스 파일 5~15개를 읽고, 근거와 신뢰도와 함께 가정을 형성하여 확인 또는 수정을 위해 제시합니다. 일반적으로 15~20번의 상호작용 대신 2~4번의 상호작용으로 처리됩니다.
@@ -30,7 +30,7 @@ Claude는 서브에이전트를 통해 관련 코드베이스 파일 5~15개를
돌아가려면:
```bash
node gsd-tools.cjs config-set workflow.discuss_mode discuss
node msd-tools.cjs config-set workflow.discuss_mode discuss
```
각 모드의 전체 비교 및 시간을 절약할 수 있는 경우에 대해서는 [논의 모드 설명](../workflow-discuss-mode.md)을 참고하세요.
@@ -42,7 +42,7 @@ node gsd-tools.cjs config-set workflow.discuss_mode discuss
기본적으로 Claude는 모호한 영역을 제시하고 다룰 항목을 묻습니다. 선택 프롬프트 없이 모든 항목을 처리하려면:
```bash
/gsd-discuss-phase 2 --all
/msd-discuss-phase 2 --all
```
---
@@ -52,7 +52,7 @@ node gsd-tools.cjs config-set workflow.discuss_mode discuss
**페이즈가 충분히 이해된 상태이고 Claude가 질문 없이 권장 기본값을 선택하길 원하는 경우:**
```bash
/gsd-discuss-phase 3 --auto
/msd-discuss-phase 3 --auto
```
Claude는 모든 질문에 권장 답변을 선택하고 선택 사항을 기록합니다. 결정이 낮은 위험을 가지거나 이전 페이즈에 이미 암시된 페이즈에 사용하세요.
@@ -60,7 +60,7 @@ Claude는 모든 질문에 권장 답변을 선택하고 선택 사항을 기록
**원격 세션 제약이 있는 경우 (TUI 메뉴 없음):**
```bash
/gsd-discuss-phase 2 --text
/msd-discuss-phase 2 --text
```
모든 프롬프트가 대화형 선택기 대신 일반 텍스트 번호 목록으로 렌더링됩니다.
@@ -72,7 +72,7 @@ Claude는 모든 질문에 권장 답변을 선택하고 선택 사항을 기록
한 번에 하나씩이 아닌 여러 질문을 동시에 답변하고 싶다면:
```bash
/gsd-discuss-phase 2 --batch
/msd-discuss-phase 2 --batch
```
Claude는 한 번에 2~5개의 질문을 묶어서 처리합니다.
@@ -84,7 +84,7 @@ Claude는 한 번에 2~5개의 질문을 묶어서 처리합니다.
결정하기 전에 옵션 비교표를 원한다면:
```bash
/gsd-discuss-phase 2 --analyze
/msd-discuss-phase 2 --analyze
```
---
@@ -94,7 +94,7 @@ Claude는 한 번에 2~5개의 질문을 묶어서 처리합니다.
답변 파일을 미리 준비한 경우 한 번에 모든 결정을 적용하려면:
```bash
/gsd-discuss-phase 1 --power
/msd-discuss-phase 1 --power
```
---
@@ -104,7 +104,7 @@ Claude는 한 번에 2~5개의 질문을 묶어서 처리합니다.
**논의 세션에 앞서 Claude가 무엇을 가정하고 어떻게 행동할지 미리 확인하고 싶은 경우** — 논의 시간을 투자하기 전에 정렬 상태를 검증하는 데 유용합니다:
```bash
/gsd-discuss-phase 3 --assumptions
/msd-discuss-phase 3 --assumptions
```
Claude는 가정 사항(코드베이스 근거 및 신뢰도 포함)을 출력하고 종료합니다. CONTEXT.md는 작성되지 않습니다. 출력을 검토한 후 수정이 필요한 경우 일반 논의 또는 가정 모드 세션을 실행하세요.
@@ -132,9 +132,9 @@ Claude는 가정 사항(코드베이스 근거 및 신뢰도 포함)을 출력
## 결정 사항이 기획에 반영되는 방식
다음에 `/gsd-plan-phase`를 실행할 때 플래너는 CONTEXT.md를 읽어 어떤 결정이 확정되었는지 파악합니다. 이미 답변된 질문은 다시 묻지 않습니다. 리서처는 무엇을 조사해야 할지 알기 위해 먼저 읽습니다.
다음에 `/msd-plan-phase`를 실행할 때 플래너는 CONTEXT.md를 읽어 어떤 결정이 확정되었는지 파악합니다. 이미 답변된 질문은 다시 묻지 않습니다. 리서처는 무엇을 조사해야 할지 알기 위해 먼저 읽습니다.
**`/gsd-plan-phase` 실행 시 CONTEXT.md가 없는 경우**, 컨텍스트 없이 계속하거나(계획은 리서치와 요구 사항만 사용, 설계 선호도 없음) 먼저 `/gsd-discuss-phase`를 실행하는 선택지가 제공됩니다.
**`/msd-plan-phase` 실행 시 CONTEXT.md가 없는 경우**, 컨텍스트 없이 계속하거나(계획은 리서치와 요구 사항만 사용, 설계 선호도 없음) 먼저 `/msd-discuss-phase`를 실행하는 선택지가 제공됩니다.
---
@@ -143,7 +143,7 @@ Claude는 가정 사항(코드베이스 근거 및 신뢰도 포함)을 출력
discuss-phase를 완전히 건너뛰고 바로 기획으로 이동합니다:
```bash
/gsd-plan-phase 1 --prd path/to/prd.md
/msd-plan-phase 1 --prd path/to/prd.md
```
플래너는 PRD에서 CONTEXT.md를 합성하고 모든 요구 사항을 확정된 결정으로 처리합니다.

68
docs/ko-KR/how-to/drive-gsd-from-a-tracker-issue.md → docs/ko-KR/how-to/drive-msd-from-a-tracker-issue.md
View File

@@ -1,8 +1,8 @@
# 트래커 이슈에서 GSD Core를 구동하는 방법
# 트래커 이슈에서 MSD Core를 구동하는 방법
**목표:** 사용자 정의 스크립트나 트래커 통합 없이 GSD Core에 이미 존재하는 명령만으로 단일의 명확히 범위가 정해진 GitHub, Linear, 또는 Jira 이슈를 격리된 워크스페이스에서 병합된 PR까지 전체 GSD 파이프라인을 통해 진행합니다.
**목표:** 사용자 정의 스크립트나 트래커 통합 없이 MSD Core에 이미 존재하는 명령만으로 단일의 명확히 범위가 정해진 GitHub, Linear, 또는 Jira 이슈를 격리된 워크스페이스에서 병합된 PR까지 전체 MSD 파이프라인을 통해 진행합니다.
**사전 조건:** GSD Core가 설치되어 있어야 합니다. 이슈는 범위가 한정되고, 관찰 가능한 수락 기준이 있으며, 상위 블로커가 없어야 합니다.
**사전 조건:** MSD Core가 설치되어 있어야 합니다. 이슈는 범위가 한정되고, 관찰 가능한 수락 기준이 있으며, 상위 블로커가 없어야 합니다.
이 패턴의 개념과 설계 근거는 [이슈 기반 오케스트레이션 설명](../issue-driven-orchestration.md)을 참조하세요.
@@ -16,13 +16,13 @@
- **이슈가 독립적인 새 작업** → 페이즈를 추가합니다:
```bash
/gsd-phase "Description matching the issue title"
/msd-phase "Description matching the issue title"
```
- **이슈가 긴급하고 기존 페이즈 사이에 삽입해야 함** → 소수점 페이즈 삽입:
```bash
/gsd-phase --insert 3 "Fix: description from issue"
/msd-phase --insert 3 "Fix: description from issue"
```
트래커 이슈 URL을 복사하세요. 3단계에서 `CONTEXT.md`에 붙여넣어 컨텍스트 압축 후에도 추적 가능성이 유지되도록 합니다.
@@ -34,13 +34,13 @@
모든 이슈는 자체 워크스페이스를 가집니다 — 독립적인 `.planning/` 디렉터리가 있는 git 워크트리. 부분 작업, 중단된 플랜, 탐색적 커밋은 `main` 밖에 유지됩니다.
```bash
/gsd-workspace --new --name my-issue-slug --repos . --strategy worktree
/msd-workspace --new --name my-issue-slug --repos . --strategy worktree
```
계속하기 전에 워크스페이스 디렉터리로 이동합니다:
```bash
cd ~/gsd-workspaces/my-issue-slug
cd ~/msd-workspaces/my-issue-slug
```
---
@@ -50,15 +50,15 @@ cd ~/gsd-workspaces/my-issue-slug
계획이 이루어지기 전에 구현 결정을 확정하기 위해 discuss-phase를 실행합니다. 세션이 열리면 트래커 이슈 URL을 토론에 붙여넣어 `CONTEXT.md`에 캡처되도록 합니다.
```bash
/gsd-discuss-phase N
/msd-discuss-phase N
```
GSD는 이슈 범위의 모호성 — 오류 처리, 엣지 케이스, 인터페이스 계약, 기술 선택 — 에 대해 물어봅니다. 귀하의 답변이 다음에 나올 플랜을 형성합니다.
MSD는 이슈 범위의 모호성 — 오류 처리, 엣지 케이스, 인터페이스 계약, 기술 선택 — 에 대해 물어봅니다. 귀하의 답변이 다음에 나올 플랜을 형성합니다.
이미 모든 답을 알고 빠르게 진행하고 싶다면:
```bash
/gsd-discuss-phase N --auto
/msd-discuss-phase N --auto
```
---
@@ -66,22 +66,22 @@ GSD는 이슈 범위의 모호성 — 오류 처리, 엣지 케이스, 인터페
## 4단계: 페이즈 계획
```bash
/gsd-plan-phase N
/msd-plan-phase N
```
GSD는 연구 에이전트를 스폰하고, `CONTEXT.md` 결정(이슈 URL 포함)을 읽으며, 원자적인 `PLAN.md` 파일을 생성합니다. 플랜 체커가 저장 전에 각 플랜을 검증합니다.
MSD는 연구 에이전트를 스폰하고, `CONTEXT.md` 결정(이슈 URL 포함)을 읽으며, 원자적인 `PLAN.md` 파일을 생성합니다. 플랜 체커가 저장 전에 각 플랜을 검증합니다.
실행 전에 외부 AI CLI의 동료 검토를 원한다면(중요한 변경에 권장):
```bash
/gsd-review --phase N
/gsd-plan-phase N --reviews
/msd-review --phase N
/msd-plan-phase N --reviews
```
또는 HIGH 우려 사항이 없을 때까지 전체 플랜-검토-수렴 루프를 실행합니다:
```bash
/gsd-plan-review-convergence N
/msd-plan-review-convergence N
```
---
@@ -91,19 +91,19 @@ GSD는 연구 에이전트를 스폰하고, `CONTEXT.md` 결정(이슈 URL 포
대화식, 페이즈 단위 실행:
```bash
/gsd-execute-phase N
/msd-execute-phase N
```
모든 나머지 페이즈를 자동으로 실행:
```bash
/gsd-autonomous
/msd-autonomous
```
진행 상황을 보고 페이즈 전반에 걸쳐 작업을 디스패치할 수 있는 대화식 대시보드:
```bash
/gsd-manager
/msd-manager
```
세 가지 접근 방식 모두 `STATE.md`를 업데이트하고, 각 작업을 원자적으로 커밋하며, 페이즈 후 검증기를 실행합니다.
@@ -113,10 +113,10 @@ GSD는 연구 에이전트를 스폰하고, `CONTEXT.md` 결정(이슈 URL 포
## 6단계: 작업 검증
```bash
/gsd-verify-work N
/msd-verify-work N
```
GSD는 페이즈 목표(트래커 이슈를 반영)의 수락 기준을 하나씩 안내합니다. 무언가 실패하면 GSD가 근본 원인을 진단하고 수정 플랜을 만듭니다. 모든 검사가 통과될 때까지 실행과 검증을 반복합니다.
MSD는 페이즈 목표(트래커 이슈를 반영)의 수락 기준을 하나씩 안내합니다. 무언가 실패하면 MSD가 근본 원인을 진단하고 수정 플랜을 만듭니다. 모든 검사가 통과될 때까지 실행과 검증을 반복합니다.
코드가 올바르게 보여도 `verification_failed`를 블로커로 취급하세요 — 실패는 보통 원래 이슈에서 놓친 수락 기준을 드러냅니다.
@@ -127,17 +127,17 @@ GSD는 페이즈 목표(트래커 이슈를 반영)의 수락 기준을 하나
PR을 열기 전에 코드 검토를 실행합니다:
```bash
/gsd-code-review N
/gsd-code-review N --fix
/msd-code-review N
/msd-code-review N --fix
```
그다음 PR을 생성합니다:
```bash
/gsd-ship N
/msd-ship N
```
GSD는 계획 아티팩트에서 PR 본문을 조립합니다: 페이즈 목표, 변경 사항 요약, 충족된 요구 사항, 검증 상태, 주요 결정. PR이 병합될 때 트래커 이슈가 자동으로 닫히도록 PR 본문에 `Closes #NNN` 또는 `Fixes #NNN`을 포함하세요(또는 `/gsd-config`를 통해 설정).
MSD는 계획 아티팩트에서 PR 본문을 조립합니다: 페이즈 목표, 변경 사항 요약, 충족된 요구 사항, 검증 상태, 주요 결정. PR이 병합될 때 트래커 이슈가 자동으로 닫히도록 PR 본문에 `Closes #NNN` 또는 `Fixes #NNN`을 포함하세요(또는 `/msd-config`를 통해 설정).
---
@@ -146,12 +146,12 @@ GSD는 계획 아티팩트에서 PR 본문을 조립합니다: 페이즈 목표,
이슈 작업 중 관련 작업을 자주 발견하게 됩니다. 컨텍스트를 잃지 않고 캡처합니다:
```bash
/gsd-capture "Follow-up: description of discovered work" # 할 일로 추가
/gsd-capture --seed "Idea worth a future phase" # 다음 마일스톤을 위해 보존
/gsd-capture --backlog "Not urgent but worth tracking" # 백로그에 저장
/msd-capture "Follow-up: description of discovered work" # 할 일로 추가
/msd-capture --seed "Idea worth a future phase" # 다음 마일스톤을 위해 보존
/msd-capture --backlog "Not urgent but worth tracking" # 백로그에 저장
```
GSD는 트래커에 자동으로 게시하지 않습니다. 캡처된 후속 작업에서 트래커 이슈를 생성하는 것은 별도의 수동 단계입니다 — 이는 검토 루프에 사람이 참여하도록 유지합니다.
MSD는 트래커에 자동으로 게시하지 않습니다. 캡처된 후속 작업에서 트래커 이슈를 생성하는 것은 별도의 수동 단계입니다 — 이는 검토 루프에 사람이 참여하도록 유지합니다.
---
@@ -159,12 +159,12 @@ GSD는 트래커에 자동으로 게시하지 않습니다. 캡처된 후속 작
| 상황 | 할 일 |
|-----------|-----------|
| 이슈가 매우 작음(오타, 설정 변경) | 워크스페이스 + 논의 + 계획 건너뜀; 대신 `/gsd-quick` 사용 |
| 이슈에 여러 독립적인 하위 작업이 있음 | `/gsd-manager`를 사용하여 플랜 전반에 걸쳐 실행 병렬화 |
| 이슈가 다른 이슈에 의해 차단됨 | 상위 블로커가 해결될 때까지 시작하지 않음; GSD에는 자동 의존성 폴러가 없음 |
| 실행 중간에 이슈 범위가 예상보다 큰 것으로 드러남 | 중단하고, `/gsd-phase --insert N`을 실행하여 하위 페이즈 추가 후 계속 |
| 대화식 논의를 건너뛰고 싶음 | `/gsd-discuss-phase`와 함께 `--auto` 플래그 사용, 또는 프로젝트 전체 자동화를 위해 `workflow.skip_discuss: true` 설정 |
| 여러 이슈가 일관된 릴리즈를 형성 | `/gsd-new-milestone`으로 그룹화하고 `/gsd-autonomous`로 순서대로 실행 |
| 이슈가 매우 작음(오타, 설정 변경) | 워크스페이스 + 논의 + 계획 건너뜀; 대신 `/msd-quick` 사용 |
| 이슈에 여러 독립적인 하위 작업이 있음 | `/msd-manager`를 사용하여 플랜 전반에 걸쳐 실행 병렬화 |
| 이슈가 다른 이슈에 의해 차단됨 | 상위 블로커가 해결될 때까지 시작하지 않음; MSD에는 자동 의존성 폴러가 없음 |
| 실행 중간에 이슈 범위가 예상보다 큰 것으로 드러남 | 중단하고, `/msd-phase --insert N`을 실행하여 하위 페이즈 추가 후 계속 |
| 대화식 논의를 건너뛰고 싶음 | `/msd-discuss-phase`와 함께 `--auto` 플래그 사용, 또는 프로젝트 전체 자동화를 위해 `workflow.skip_discuss: true` 설정 |
| 여러 이슈가 일관된 릴리즈를 형성 | `/msd-new-milestone`으로 그룹화하고 `/msd-autonomous`로 순서대로 실행 |
---

24
docs/ko-KR/how-to/execute-a-phase.md
View File

@@ -2,19 +2,19 @@
**목표:** 기획된 페이즈를 웨이브 기반 병렬 실행으로 처리하고 각 계획을 원자적 git 커밋으로 완료합니다.
**전제 조건:** 페이즈에 최소 하나의 `PLAN.md` 파일이 있어야 합니다. 기획이 아직 완료되지 않았다면 먼저 `/gsd-plan-phase N`을 실행하세요 — [페이즈 기획](plan-a-phase.md)을 참고하세요.
**전제 조건:** 페이즈에 최소 하나의 `PLAN.md` 파일이 있어야 합니다. 기획이 아직 완료되지 않았다면 먼저 `/msd-plan-phase N`을 실행하세요 — [페이즈 기획](plan-a-phase.md)을 참고하세요.
---
## 전체 페이즈 실행
```bash
/gsd-execute-phase 1
/msd-execute-phase 1
```
GSD는 페이즈의 계획 파일을 읽고 의존성 웨이브로 그룹화한 후 계획당 새 실행자 에이전트를 실행합니다. 각 실행자는 다음 웨이브가 시작되기 전에 작업을 원자적으로 커밋합니다.
MSD는 페이즈의 계획 파일을 읽고 의존성 웨이브로 그룹화한 후 계획당 새 실행자 에이전트를 실행합니다. 각 실행자는 다음 웨이브가 시작되기 전에 작업을 원자적으로 커밋합니다.
에이전트가 실행되기 전에 GSD는 웨이브 테이블을 출력합니다:
에이전트가 실행되기 전에 MSD는 웨이브 테이블을 출력합니다:
```
## Execution Plan
@@ -38,24 +38,24 @@ Phase 1: Core middleware — 3 plans across 2 wave(s)
예를 들어 웨이브 2로 넘어가기 전 웨이브 1 출력을 검사하고 싶은 경우 `--wave N`을 사용하세요:
```bash
/gsd-execute-phase 1 --wave 2
/msd-execute-phase 1 --wave 2
```
GSD는 웨이브 2 계획만 실행합니다. 먼저 이전 웨이브가 완료되었는지 확인하며, 웨이브 1 계획이 아직 미완료인 경우 이전 웨이브를 먼저 완료하도록 알립니다.
MSD는 웨이브 2 계획만 실행합니다. 먼저 이전 웨이브가 완료되었는지 확인하며, 웨이브 1 계획이 아직 미완료인 경우 이전 웨이브를 먼저 완료하도록 알립니다.
---
## 중단된 실행 재개
실행이 도중에 중단된 경우(할당량 오류, 네트워크 끊김, 세션 충돌 등) 웨이브 레벨 진행 상황은 보존됩니다. GSD는 각 계획의 `SUMMARY.md` 파일을 확인합니다. 이미 파일이 있는 계획은 재실행 시 자동으로 건너뜁니다:
실행이 도중에 중단된 경우(할당량 오류, 네트워크 끊김, 세션 충돌 등) 웨이브 레벨 진행 상황은 보존됩니다. MSD는 각 계획의 `SUMMARY.md` 파일을 확인합니다. 이미 파일이 있는 계획은 재실행 시 자동으로 건너뜁니다:
```bash
/gsd-execute-phase 1
/msd-execute-phase 1
```
GSD는 `SUMMARY.md`가 이미 존재하는 계획을 건너뛰고 첫 번째 미완료 계획에서 재개합니다.
MSD는 `SUMMARY.md`가 이미 존재하는 계획을 건너뛰고 첫 번째 미완료 계획에서 재개합니다.
**커밋은 존재하지만 `SUMMARY.md`가 없는 경우**(실행자가 커밋했지만 세션이 종료되기 전 요약을 작성하지 못한 경우), GSD는 안전 재개 게이트를 표시하고 세 가지 옵션을 제공합니다:
**커밋은 존재하지만 `SUMMARY.md`가 없는 경우**(실행자가 커밋했지만 세션이 종료되기 전 요약을 작성하지 못한 경우), MSD는 안전 재개 게이트를 표시하고 세 가지 옵션을 제공합니다:
- `수동으로 마무리` — 커밋을 검사하고 `SUMMARY.md`를 작성한 후 재실행
- `처음부터 재실행` — 부분 커밋을 되돌리거나 대체한 후 새 실행자 실행
@@ -88,13 +88,13 @@ Git 히스토리에는 각 실행자의 태스크당 커밋 하나와 오케스
`workflow.cross_ai_command`에 설정된 외부 AI CLI(Codex, Antigravity 등)에 실행을 위임하려면:
```bash
/gsd-execute-phase 2 --cross-ai
/msd-execute-phase 2 --cross-ai
```
설정에 크로스 AI가 활성화된 경우에도 로컬 실행을 강제하려면:
```bash
/gsd-execute-phase 2 --no-cross-ai
/msd-execute-phase 2 --no-cross-ai
```
---

56
docs/ko-KR/how-to/handle-quick-and-fast-tasks.md
View File

@@ -1,6 +1,6 @@
# 빠른 작업과 간단한 작업을 처리하는 방법
모든 작업이 페이즈 안에 맞는 것은 아닙니다. GSD는 전체 discuss → plan → execute → verify 루프가 필요 없는 작업을 위한 두 가지 경량 명령을 제공합니다.
모든 작업이 페이즈 안에 맞는 것은 아닙니다. MSD는 전체 discuss → plan → execute → verify 루프가 필요 없는 작업을 위한 두 가지 경량 명령을 제공합니다.
전체 페이즈 파이프라인이 오버헤드를 감당할 가치가 있는 경우에 대한 맥락은 [컨텍스트 엔지니어링](../explanation/context-engineering.md)을 참고하세요.
@@ -10,30 +10,30 @@
| 상황 | 명령 |
|-----------|---------|
| 버그 수정, 소규모 기능 추가, 또는 단일 사소한 수정으로 요약할 수 없는 작업 | `/gsd-quick` |
| 오타 수정, 설정 값 업데이트, `.gitignore` 항목 추가, 또는 ≤ 3개 파일을 터치하고 1분 이내에 완료되는 변경 | `/gsd-fast` |
| 작업에 미지수가 있거나 리서치가 필요하거나 여러 파일을 터치할 경우 | `--research`와 함께 `/gsd-quick` |
| 버그 수정, 소규모 기능 추가, 또는 단일 사소한 수정으로 요약할 수 없는 작업 | `/msd-quick` |
| 오타 수정, 설정 값 업데이트, `.gitignore` 항목 추가, 또는 ≤ 3개 파일을 터치하고 1분 이내에 완료되는 변경 | `/msd-fast` |
| 작업에 미지수가 있거나 리서치가 필요하거나 여러 파일을 터치할 경우 | `--research`와 함께 `/msd-quick` |
**경험 법칙:** 작업이 사소한지에 대해 잠시라도 망설인다면 `/gsd-quick`을 사용하세요. `/gsd-fast`는 범위가 사소하지 않아 보이면 자동으로 `/gsd-quick`으로 리디렉션합니다.
**경험 법칙:** 작업이 사소한지에 대해 잠시라도 망설인다면 `/msd-quick`을 사용하세요. `/msd-fast`는 범위가 사소하지 않아 보이면 자동으로 `/msd-quick`으로 리디렉션합니다.
---
## `/gsd-quick` — GSD 보장이 있는 임시 작업
## `/msd-quick` — MSD 보장이 있는 임시 작업
`/gsd-quick`은 전체 페이즈와 동일한 원자적 커밋 및 STATE.md 추적 보장으로 플래너와 실행자를 실행하지만, 페이즈 오버헤드 없이 진행합니다(ROADMAP 항목 없음, discuss-phase 없음, 여러 계획에 걸친 웨이브 조정 없음).
`/msd-quick`은 전체 페이즈와 동일한 원자적 커밋 및 STATE.md 추적 보장으로 플래너와 실행자를 실행하지만, 페이즈 오버헤드 없이 진행합니다(ROADMAP 항목 없음, discuss-phase 없음, 여러 계획에 걸친 웨이브 조정 없음).
### 기본 사용
```bash
/gsd-quick
/msd-quick
```
GSD가 태스크 설명을 묻고 계획 및 실행합니다. 산출물은 `.planning/quick/`에 저장됩니다.
MSD가 태스크 설명을 묻고 계획 및 실행합니다. 산출물은 `.planning/quick/`에 저장됩니다.
설명을 직접 전달할 수도 있습니다:
```bash
/gsd-quick "Fix the login button not responding on mobile Safari"
/msd-quick "Fix the login button not responding on mobile Safari"
```
### 플래그
@@ -50,9 +50,9 @@ GSD가 태스크 설명을 묻고 계획 및 실행합니다. 산출물은 `.pla
플래그는 자유롭게 조합할 수 있습니다:
```bash
/gsd-quick --research --validate # 리서치 + 플랜 체킹 + 검증, 논의 없음
/gsd-quick --discuss # 기획 전 모호한 영역만 표시
/gsd-quick --full # 전체 품질 파이프라인
/msd-quick --research --validate # 리서치 + 플랜 체킹 + 검증, 논의 없음
/msd-quick --discuss # 기획 전 모호한 영역만 표시
/msd-quick --full # 전체 품질 파이프라인
```
### 플래그 추가 시기
@@ -65,38 +65,38 @@ GSD가 태스크 설명을 묻고 계획 및 실행합니다. 산출물은 `.pla
### 빠른 작업 목록 및 재개
```bash
/gsd-quick list # 상태별 모든 빠른 작업 표시
/gsd-quick status my-task-slug # 특정 작업 상태 표시
/gsd-quick resume my-task-slug # 중단된 작업 재개
/msd-quick list # 상태별 모든 빠른 작업 표시
/msd-quick status my-task-slug # 특정 작업 상태 표시
/msd-quick resume my-task-slug # 중단된 작업 재개
```
---
## `/gsd-fast` — 인라인 사소한 편집
## `/msd-fast` — 인라인 사소한 편집
`/gsd-fast`는 현재 컨텍스트에서 직접 작업을 수행합니다. 서브에이전트, `PLAN.md`, 리서치가 없습니다. 스스로 1분 이내에 할 수 있는 변경에만 적합합니다.
`/msd-fast`는 현재 컨텍스트에서 직접 작업을 수행합니다. 서브에이전트, `PLAN.md`, 리서치가 없습니다. 스스로 1분 이내에 할 수 있는 변경에만 적합합니다.
```bash
/gsd-fast "fix typo in README"
/gsd-fast "add .env to .gitignore"
/msd-fast "fix typo in README"
/msd-fast "add .env to .gitignore"
```
설명을 생략하면 GSD가 묻습니다.
설명을 생략하면 MSD가 묻습니다.
`/gsd-fast`는 진행 전에 작업이 실제로 사소한지 확인합니다. 범위가 너무 크다고 판단하면 중단하고 리디렉션합니다:
`/msd-fast`는 진행 전에 작업이 실제로 사소한지 확인합니다. 범위가 너무 크다고 판단하면 중단하고 리디렉션합니다:
```text
This looks like it needs planning. Use /gsd-quick instead:
/gsd-quick "your task description"
This looks like it needs planning. Use /msd-quick instead:
/msd-quick "your task description"
```
변경 후 `/gsd-fast`는 원자적으로 커밋하고, `.planning/STATE.md`에 `Quick Tasks Completed` 테이블이 있으면 행을 추가합니다.
변경 후 `/msd-fast`는 원자적으로 커밋하고, `.planning/STATE.md`에 `Quick Tasks Completed` 테이블이 있으면 행을 추가합니다.
---
## `/gsd-quick`이 `/gsd-fast`와 다른 점
## `/msd-quick`이 `/msd-fast`와 다른 점
| 기능 | `/gsd-fast` | `/gsd-quick` |
| 기능 | `/msd-fast` | `/msd-quick` |
|------------|------------|--------------|
| 서브에이전트 플래너 | 없음 | 있음 |
| 서브에이전트 실행자 | 없음 | 있음 |
@@ -109,7 +109,7 @@ This looks like it needs planning. Use /gsd-quick instead:
| STATE.md 추적 | 테이블이 있으면 행 추가 | 항상 업데이트됨 |
| `.planning/quick/` 산출물 | 없음 | 있음 |
핵심 차이는 서브에이전트 격리입니다. `/gsd-quick`은 별도의 컨텍스트 창에서 새 플래너와 실행자를 실행하므로 작업이 적절히 기획되고 커밋이 태스크당 원자적이며 오케스트레이터가 결과를 검증할 수 있습니다. `/gsd-fast`는 현재 컨텍스트 창만 사용하며 이러한 것이 필요하지 않을 만큼 사소한 변경에 의도적으로 제한됩니다.
핵심 차이는 서브에이전트 격리입니다. `/msd-quick`은 별도의 컨텍스트 창에서 새 플래너와 실행자를 실행하므로 작업이 적절히 기획되고 커밋이 태스크당 원자적이며 오케스트레이터가 결과를 검증할 수 있습니다. `/msd-fast`는 현재 컨텍스트 창만 사용하며 이러한 것이 필요하지 않을 만큼 사소한 변경에 의도적으로 제한됩니다.
---

92
docs/ko-KR/how-to/install-on-your-runtime.md
View File

@@ -1,6 +1,6 @@
# GSD Core를 런타임에 설치하는 방법
# MSD Core를 런타임에 설치하는 방법
GSD Core(`@opengsd/gsd-core`)를 매일 사용하는 AI 코딩 런타임에 설치합니다. 이 가이드는 지원되는 각 런타임의 표준 설치 경로를 안내하고, Node.js가 없는 환경에서의 수동 설치 방법도 다룹니다.
MSD Core(`@golem15/msd-core`)를 매일 사용하는 AI 코딩 런타임에 설치합니다. 이 가이드는 지원되는 각 런타임의 표준 설치 경로를 안내하고, Node.js가 없는 환경에서의 수동 설치 방법도 다룹니다.
**필요 사항:** Node.js 18 이상 및 npm(또는 npx). Node.js가 없는 경우 [Node.js 없이 설치하기](#nodejs-없이-설치하기)로 이동하세요.
@@ -8,7 +8,7 @@ GSD Core(`@opengsd/gsd-core`)를 매일 사용하는 AI 코딩 런타임에 설
## 인스톨러가 필요한 이유
GSD Core는 Claude Code의 네이티브 frontmatter 형식으로 에이전트 및 명령 파일을 제공합니다. 각 지원 런타임은 서로 다른 스키마, 디렉터리 구조, 명령 호출 문법을 요구합니다. 인스톨러는 필요한 변환을 수행합니다. 예를 들어 OpenCode용 도구 목록 및 색상 값 변환, Codex용 TOML 에이전트 항목 작성 등입니다.
MSD Core는 Claude Code의 네이티브 frontmatter 형식으로 에이전트 및 명령 파일을 제공합니다. 각 지원 런타임은 서로 다른 스키마, 디렉터리 구조, 명령 호출 문법을 요구합니다. 인스톨러는 필요한 변환을 수행합니다. 예를 들어 OpenCode용 도구 목록 및 색상 값 변환, Codex용 TOML 에이전트 항목 작성 등입니다.
**`agents/` 또는 `commands/`에서 파일을 직접 복사하지 마세요.** 그렇게 하면 변환을 우회하게 되어 스키마 유효성 검사 오류나 누락된 명령이 발생합니다.
@@ -19,7 +19,7 @@ GSD Core는 Claude Code의 네이티브 frontmatter 형식으로 에이전트
임의의 디렉터리에서 인스톨러를 실행합니다. 런타임과 전역 설치(모든 프로젝트) 또는 로컬 설치(이 프로젝트만) 여부를 묻습니다.
```bash
npx @opengsd/gsd-core@latest
npx @golem15/msd-core@latest
```
신규 설치 또는 런타임 전환 후 인스톨러를 재실행할 때 필요한 명령은 이것뿐입니다.
@@ -31,17 +31,17 @@ npx @opengsd/gsd-core@latest
### Claude Code
```bash
npx @opengsd/gsd-core@latest --claude --global
npx @golem15/msd-core@latest --claude --global
```
스킬은 `~/.claude/`에 저장됩니다. 다음 Claude Code 세션에서 `/gsd-*` 슬래시 명령으로 명령이 나타납니다. Claude Code를 재시작하여 적용하세요.
스킬은 `~/.claude/`에 저장됩니다. 다음 Claude Code 세션에서 `/msd-*` 슬래시 명령으로 명령이 나타납니다. Claude Code를 재시작하여 적용하세요.
**`--global`과 `--local` 두 범위 모두에 설치하는 경우.** 이는 지원되는 구성입니다(프로젝트마다 서로 다른 커스터마이징이 필요한 경우가 있기 때문입니다). 하지만 Claude Code 자체의 트리거 해석 규칙 — 개인 범위가 프로젝트 범위보다 우선하고, 스킬이 동일한 이름의 명령보다 우선함 — 은 모두 같은 방향을 가리킵니다: 전역 스킬이 항상 `/gsd-<name>` 트리거에서 로컬 명령을 이깁니다. GSD Core는 이를 감지하여 설치 완료 직후 어떤 범위가 우선하는지 출력합니다(동일한 사실이 `/gsd-health`의 진단 코드 `W028`로도 표시됩니다). 이는 경고일 뿐 실패가 아닙니다 — 설치 자체는 계속 성공합니다. **전역** 범위에서는, 승리한 스킬의 워크플로 스펙 참조가 실행 시점에 작업 디렉터리를 기준으로 우선 해석되므로, Claude Code가 실제로 호출하는 것이 전역 스킬이더라도 자체 `.claude/gsd-core/`를 가진 프로젝트는 여전히 자신의 스펙을 얻습니다.
**`--global`과 `--local` 두 범위 모두에 설치하는 경우.** 이는 지원되는 구성입니다(프로젝트마다 서로 다른 커스터마이징이 필요한 경우가 있기 때문입니다). 하지만 Claude Code 자체의 트리거 해석 규칙 — 개인 범위가 프로젝트 범위보다 우선하고, 스킬이 동일한 이름의 명령보다 우선함 — 은 모두 같은 방향을 가리킵니다: 전역 스킬이 항상 `/msd-<name>` 트리거에서 로컬 명령을 이깁니다. MSD Core는 이를 감지하여 설치 완료 직후 어떤 범위가 우선하는지 출력합니다(동일한 사실이 `/msd-health`의 진단 코드 `W028`로도 표시됩니다). 이는 경고일 뿐 실패가 아닙니다 — 설치 자체는 계속 성공합니다. **전역** 범위에서는, 승리한 스킬의 워크플로 스펙 참조가 실행 시점에 작업 디렉터리를 기준으로 우선 해석되므로, Claude Code가 실제로 호출하는 것이 전역 스킬이더라도 자체 `.claude/msd-core/`를 가진 프로젝트는 여전히 자신의 스펙을 얻습니다.
**설치 디렉터리 재정의:**
```bash
CLAUDE_CONFIG_DIR=~/.claude-alt npx @opengsd/gsd-core@latest --claude --global
CLAUDE_CONFIG_DIR=~/.claude-alt npx @golem15/msd-core@latest --claude --global
```
---
@@ -49,7 +49,7 @@ CLAUDE_CONFIG_DIR=~/.claude-alt npx @opengsd/gsd-core@latest --claude --global
### OpenCode
```bash
npx @opengsd/gsd-core@latest --opencode --global
npx @golem15/msd-core@latest --opencode --global
```
스킬은 `~/.config/opencode/`(XDG) 또는 `~/.opencode/`에 저장됩니다. 인스톨러는 에이전트 frontmatter를 OpenCode 스키마로 변환합니다(`tools:` 필드 제거, 색상 값을 hex로 변환). 변경 내용을 이해하려면 [Node.js 없이 설치하기 — OpenCode 변환](#opencode--필수-변환)을 참고하세요.
@@ -57,7 +57,7 @@ npx @opengsd/gsd-core@latest --opencode --global
**설치 디렉터리 재정의:**
```bash
OPENCODE_CONFIG_DIR=~/.config/opencode-alt npx @opengsd/gsd-core@latest --opencode --global
OPENCODE_CONFIG_DIR=~/.config/opencode-alt npx @golem15/msd-core@latest --opencode --global
```
---
@@ -65,7 +65,7 @@ OPENCODE_CONFIG_DIR=~/.config/opencode-alt npx @opengsd/gsd-core@latest --openco
### Kilo
```bash
npx @opengsd/gsd-core@latest --kilo --global
npx @golem15/msd-core@latest --kilo --global
```
스킬은 `~/.config/kilo/`(XDG) 또는 `~/.kilo/`에 저장됩니다. OpenCode 스타일의 플랫 마크다운 명령 형식을 사용합니다.
@@ -73,7 +73,7 @@ npx @opengsd/gsd-core@latest --kilo --global
**설치 디렉터리 재정의:**
```bash
KILO_CONFIG_DIR=~/.config/kilo-alt npx @opengsd/gsd-core@latest --kilo --global
KILO_CONFIG_DIR=~/.config/kilo-alt npx @golem15/msd-core@latest --kilo --global
```
---
@@ -81,10 +81,10 @@ KILO_CONFIG_DIR=~/.config/kilo-alt npx @opengsd/gsd-core@latest --kilo --global
### Codex
```bash
npx @opengsd/gsd-core@latest --codex --global
npx @golem15/msd-core@latest --codex --global
```
스킬은 `~/.codex/skills/gsd-*/SKILL.md`에 저장됩니다. 에이전트는 `config.toml`에 에이전트별 TOML 항목으로 작성됩니다. 설치 후 Codex를 재시작하거나 `codex --reload`를 실행하세요.
스킬은 `~/.codex/skills/msd-*/SKILL.md`에 저장됩니다. 에이전트는 `config.toml`에 에이전트별 TOML 항목으로 작성됩니다. 설치 후 Codex를 재시작하거나 `codex --reload`를 실행하세요.
**최소 지원 버전:** Codex CLI 0.130.0. 이전 버전은 추가 스킬 루트 스캔으로 중복 목록이 발생할 수 있습니다.
@@ -93,15 +93,15 @@ npx @opengsd/gsd-core@latest --codex --global
### GitHub Copilot
```bash
npx @opengsd/gsd-core@latest --copilot --global
npx @golem15/msd-core@latest --copilot --global
```
스킬은 `~/.copilot/`에 저장됩니다. GSD는 에이전트 `.md` 파일 및 저장소 지시 파일로 설치됩니다.
스킬은 `~/.copilot/`에 저장됩니다. MSD는 에이전트 `.md` 파일 및 저장소 지시 파일로 설치됩니다.
**설치 디렉터리 재정의:**
```bash
COPILOT_CONFIG_DIR=~/.copilot-alt npx @opengsd/gsd-core@latest --copilot --global
COPILOT_CONFIG_DIR=~/.copilot-alt npx @golem15/msd-core@latest --copilot --global
```
---
@@ -109,15 +109,15 @@ COPILOT_CONFIG_DIR=~/.copilot-alt npx @opengsd/gsd-core@latest --copilot --globa
### Cursor
```bash
npx @opengsd/gsd-core@latest --cursor --global
npx @golem15/msd-core@latest --cursor --global
```
스킬은 `~/.cursor/`에 저장됩니다. GSD는 스킬, 에이전트, 규칙 참조를 설치합니다.
스킬은 `~/.cursor/`에 저장됩니다. MSD는 스킬, 에이전트, 규칙 참조를 설치합니다.
**설치 디렉터리 재정의:**
```bash
CURSOR_CONFIG_DIR=~/.cursor-alt npx @opengsd/gsd-core@latest --cursor --global
CURSOR_CONFIG_DIR=~/.cursor-alt npx @golem15/msd-core@latest --cursor --global
```
---
@@ -125,29 +125,29 @@ CURSOR_CONFIG_DIR=~/.cursor-alt npx @opengsd/gsd-core@latest --cursor --global
### Windsurf
```bash
npx @opengsd/gsd-core@latest --windsurf --global
npx @golem15/msd-core@latest --windsurf --global
```
스킬은 `~/.codeium/windsurf/`에 저장됩니다. GSD는 스킬, 에이전트, 워크스페이스 규칙을 설치합니다.
스킬은 `~/.codeium/windsurf/`에 저장됩니다. MSD는 스킬, 에이전트, 워크스페이스 규칙을 설치합니다.
**설치 디렉터리 재정의:**
```bash
WINDSURF_CONFIG_DIR=~/.codeium/windsurf-alt npx @opengsd/gsd-core@latest --windsurf --global
WINDSURF_CONFIG_DIR=~/.codeium/windsurf-alt npx @golem15/msd-core@latest --windsurf --global
```
---
### Cline
Cline은 규칙 기반 통합을 사용합니다. GSD는 슬래시 명령이 아닌 `.clinerules`로 설치됩니다.
Cline은 규칙 기반 통합을 사용합니다. MSD는 슬래시 명령이 아닌 `.clinerules`로 설치됩니다.
```bash
# 전역 설치 (모든 프로젝트)
npx @opengsd/gsd-core@latest --cline --global
npx @golem15/msd-core@latest --cline --global
# 로컬 설치 (이 프로젝트만)
npx @opengsd/gsd-core@latest --cline --local
npx @golem15/msd-core@latest --cline --local
```
전역 설치는 `~/.cline/`에 저장됩니다. 로컬 설치는 `./.cline/`에 저장됩니다. 규칙은 Cline에 의해 자동으로 로드되며 커스텀 슬래시 명령은 등록되지 않습니다.
@@ -157,10 +157,10 @@ npx @opengsd/gsd-core@latest --cline --local
### CodeBuddy
```bash
npx @opengsd/gsd-core@latest --codebuddy --global
npx @golem15/msd-core@latest --codebuddy --global
```
스킬은 `~/.codebuddy/skills/gsd-*/SKILL.md`에 저장됩니다.
스킬은 `~/.codebuddy/skills/msd-*/SKILL.md`에 저장됩니다.
---
@@ -169,15 +169,15 @@ npx @opengsd/gsd-core@latest --codebuddy --global
Qwen Code는 Claude Code 2.1.88+와 동일한 오픈 스킬 표준을 사용합니다.
```bash
npx @opengsd/gsd-core@latest --qwen --global
npx @golem15/msd-core@latest --qwen --global
```
스킬은 `~/.qwen/skills/gsd-*/SKILL.md`에 저장됩니다.
스킬은 `~/.qwen/skills/msd-*/SKILL.md`에 저장됩니다.
**설치 디렉터리 재정의:**
```bash
QWEN_CONFIG_DIR=~/.qwen-alt npx @opengsd/gsd-core@latest --qwen --global
QWEN_CONFIG_DIR=~/.qwen-alt npx @golem15/msd-core@latest --qwen --global
```
---
@@ -185,17 +185,17 @@ QWEN_CONFIG_DIR=~/.qwen-alt npx @opengsd/gsd-core@latest --qwen --global
### Augment Code
```bash
npx @opengsd/gsd-core@latest --augment --global
npx @golem15/msd-core@latest --augment --global
```
스킬은 `~/.augment/`에 저장됩니다. GSD는 스킬과 에이전트를 설치합니다. 훅 또는 상태 표시줄 소유권은 없습니다.
스킬은 `~/.augment/`에 저장됩니다. MSD는 스킬과 에이전트를 설치합니다. 훅 또는 상태 표시줄 소유권은 없습니다.
---
### Antigravity
```bash
npx @opengsd/gsd-core@latest --antigravity --global
npx @golem15/msd-core@latest --antigravity --global
```
인스톨러는 Antigravity 설정 디렉터리(`~/.gemini/antigravity`, `~/.gemini/antigravity-ide`, 또는 `~/.gemini/antigravity-cli`)를 자동으로 감지합니다. Gemini 호환 설정 정책을 사용합니다.
@@ -203,7 +203,7 @@ npx @opengsd/gsd-core@latest --antigravity --global
**설치 디렉터리 재정의:**
```bash
ANTIGRAVITY_CONFIG_DIR=~/.gemini/antigravity-alt npx @opengsd/gsd-core@latest --antigravity --global
ANTIGRAVITY_CONFIG_DIR=~/.gemini/antigravity-alt npx @golem15/msd-core@latest --antigravity --global
```
---
@@ -211,19 +211,19 @@ ANTIGRAVITY_CONFIG_DIR=~/.gemini/antigravity-alt npx @opengsd/gsd-core@latest --
### Trae
```bash
npx @opengsd/gsd-core@latest --trae --global
npx @golem15/msd-core@latest --trae --global
```
스킬은 `~/.trae/`에 저장됩니다. GSD는 스킬, 에이전트, 규칙 참조를 설치합니다.
스킬은 `~/.trae/`에 저장됩니다. MSD는 스킬, 에이전트, 규칙 참조를 설치합니다.
---
## 로컬 설치 vs 전역 설치
위의 모든 예시는 사용자 계정 전체에 GSD를 한 번 설치하는 `--global`을 사용합니다. 단일 프로젝트로 범위를 제한하려면 `--global`을 `--local`로 바꾸세요:
위의 모든 예시는 사용자 계정 전체에 MSD를 한 번 설치하는 `--global`을 사용합니다. 단일 프로젝트로 범위를 제한하려면 `--global`을 `--local`로 바꾸세요:
```bash
npx @opengsd/gsd-core@latest --claude --local
npx @golem15/msd-core@latest --claude --local
```
로컬 설치는 프로젝트 루트의 `.claude/` 디렉터리에 작성됩니다. 둘 다 존재하는 경우 로컬 설치 설정이 전역 설정보다 우선합니다.
@@ -235,10 +235,10 @@ npx @opengsd/gsd-core@latest --claude --local
런타임의 프리릴리스 에디션(Windsurf Next, Cursor Nightly, VS Code Insiders, Codex 프리뷰 채널 등)은 인접한 설정 디렉터리에서 읽습니다. 인스톨러 실행 전에 해당하는 `*_CONFIG_DIR` 환경 변수를 설정하세요:
```bash
WINDSURF_CONFIG_DIR=~/.codeium/windsurf-next npx @opengsd/gsd-core@latest --windsurf --global
WINDSURF_CONFIG_DIR=~/.codeium/windsurf-next npx @golem15/msd-core@latest --windsurf --global
```
인스톨러 프롬프트에서 해당하는 안정적인 런타임을 선택하세요. GSD는 프리릴리스 에디션을 별도의 명명된 런타임으로 열거하지 않습니다. 이 환경 변수 메커니즘을 통한 지원은 최선의 방식이며 릴리스 CI에서 별도로 테스트되지 않습니다.
인스톨러 프롬프트에서 해당하는 안정적인 런타임을 선택하세요. MSD는 프리릴리스 에디션을 별도의 명명된 런타임으로 열거하지 않습니다. 이 환경 변수 메커니즘을 통한 지원은 최선의 방식이며 릴리스 CI에서 별도로 테스트되지 않습니다.
---
@@ -249,11 +249,11 @@ WINDSURF_CONFIG_DIR=~/.codeium/windsurf-next npx @opengsd/gsd-core@latest --wind
**옵션 A — Node.js가 있는 다른 머신 사용.** WSL, Linux VM, CI 러너, Docker 컨테이너 등 Node.js가 있는 어떤 머신이든 사용 가능합니다. 그곳에서 인스톨러를 실행한 후 출력 디렉터리를 대상 머신으로 복사하세요. OpenCode의 경우:
```bash
npx @opengsd/gsd-core@latest --opencode --global
npx @golem15/msd-core@latest --opencode --global
# 그 다음 ~/.config/opencode/agents/ 를 Windows 머신으로 복사
```
**옵션 B — 소스 파일 수동 변환.** 에이전트 소스 파일은 GSD Core 저장소의 `agents/`에 있으며 Claude Code의 네이티브 frontmatter 형식입니다. 각 런타임은 다른 구조를 요구합니다. 런타임별 정확한 필드 변환에 대해서는 사용자 가이드의 [수동 설치 / Node.js 없는 설정](../USER-GUIDE.md#manual-install--no-nodejs-setup)을 참고하세요. OpenCode 변환 전체를 다루며 다른 런타임용 인스톨러의 `convert*Frontmatter` 함수를 안내합니다.
**옵션 B — 소스 파일 수동 변환.** 에이전트 소스 파일은 MSD Core 저장소의 `agents/`에 있으며 Claude Code의 네이티브 frontmatter 형식입니다. 각 런타임은 다른 구조를 요구합니다. 런타임별 정확한 필드 변환에 대해서는 사용자 가이드의 [수동 설치 / Node.js 없는 설정](../USER-GUIDE.md#manual-install--no-nodejs-setup)을 참고하세요. OpenCode 변환 전체를 다루며 다른 런타임용 인스톨러의 `convert*Frontmatter` 함수를 안내합니다.
---
@@ -262,8 +262,8 @@ npx @opengsd/gsd-core@latest --opencode --global
새 명령과 에이전트를 적용하려면 런타임을 재시작하세요. 그런 다음 새 프로젝트를 시작하거나 기존 저장소를 온보딩합니다:
```bash
/gsd-new-project # 그린필드 프로젝트
/gsd-onboard # 기존 코드베이스
/msd-new-project # 그린필드 프로젝트
/msd-onboard # 기존 코드베이스
```
재시작 후 명령을 찾을 수 없다면 설치 디렉터리가 런타임이 기대하는 설정 경로와 일치하는지 확인하세요. 위의 프리릴리스 에디션 섹션에서 가장 흔한 불일치 사례를 다룹니다.
@@ -273,6 +273,6 @@ npx @opengsd/gsd-core@latest --opencode --global
## 관련 문서
- [첫 번째 프로젝트](../tutorials/your-first-project.md)
- [GSD Core 업데이트](update-gsd.md)
- [MSD Core 업데이트](update-msd.md)
- [설정](../CONFIGURATION.md)
- [문서 목차](../README.md)

52
docs/ko-KR/how-to/isolate-work-with-workspaces.md
View File

@@ -1,6 +1,6 @@
# 워크스페이스로 작업을 격리하는 방법
**목표:** 피처 브랜치나 멀티 저장소 작업을 위해 별도의 git 워크트리, 독립적인 `.planning/` 루트, 그리고 선택적으로 여러 저장소를 포함하는 완전히 격리된 GSD 환경을 만듭니다.
**목표:** 피처 브랜치나 멀티 저장소 작업을 위해 별도의 git 워크트리, 독립적인 `.planning/` 루트, 그리고 선택적으로 여러 저장소를 포함하는 완전히 격리된 MSD 환경을 만듭니다.
**사전 조건:** `git`이 설치되어 있고 저장소가 워크트리를 지원해야 합니다. 멀티 저장소 워크스페이스의 경우 대상 저장소가 로컬 머신에 존재하거나 경로로 접근 가능해야 합니다.
@@ -14,13 +14,13 @@
- 멤버 저장소를 추적하는 자체 `WORKSPACE.md` 매니페스트
- 지정된 저장소의 git 워크트리(기본값) 또는 전체 클론이며 전용 브랜치(기본값: `workspace/<name>`)로 체크아웃됨
워크스페이스는 기본적으로 `~/gsd-workspaces/<name>/` 아래에 위치합니다.
워크스페이스는 기본적으로 `~/msd-workspaces/<name>/` 아래에 위치합니다.
```
~/gsd-workspaces/
~/msd-workspaces/
└── feature-b/
├── WORKSPACE.md ← 매니페스트
├── .planning/ ← 완전히 독립된 GSD 상태
├── .planning/ ← 완전히 독립된 MSD 상태
│ ├── PROJECT.md
│ ├── ROADMAP.md
│ └── ...
@@ -35,15 +35,15 @@
## 여러 저장소에 대한 워크스페이스 생성
```bash
/gsd-workspace --new --name feature-b --repos hr-ui,ZeymoAPI
/msd-workspace --new --name feature-b --repos hr-ui,ZeymoAPI
```
GSD는 `~/gsd-workspaces/feature-b/` 내에 `hr-ui`와 `ZeymoAPI`의 워크트리를 생성하고, 각각에서 `workspace/feature-b` 브랜치를 체크아웃하며, `WORKSPACE.md`를 작성하고 `/gsd-new-project`를 위한 빈 `.planning/` 디렉터리를 생성합니다.
MSD는 `~/msd-workspaces/feature-b/` 내에 `hr-ui`와 `ZeymoAPI`의 워크트리를 생성하고, 각각에서 `workspace/feature-b` 브랜치를 체크아웃하며, `WORKSPACE.md`를 작성하고 `/msd-new-project`를 위한 빈 `.planning/` 디렉터리를 생성합니다.
위치를 사용자 정의하려면:
```bash
/gsd-workspace --new --name feature-b --repos hr-ui,ZeymoAPI --path /projects/feature-b
/msd-workspace --new --name feature-b --repos hr-ui,ZeymoAPI --path /projects/feature-b
```
---
@@ -53,15 +53,15 @@ GSD는 `~/gsd-workspaces/feature-b/` 내에 `hr-ui`와 `ZeymoAPI`의 워크트
단일 저장소에서 피처 브랜치 격리가 필요할 때 — 독립적인 브랜치, 독립적인 `.planning/`, 메인에서의 상태 유입 없음:
```bash
/gsd-workspace --new --name payments-rework --repos .
/msd-workspace --new --name payments-rework --repos .
```
`.`은 GSD에게 현재 저장소의 워크트리를 생성하도록 지시합니다. 워크트리는 `workspace/payments-rework`로 체크아웃됩니다.
`.`은 MSD에게 현재 저장소의 워크트리를 생성하도록 지시합니다. 워크트리는 `workspace/payments-rework`로 체크아웃됩니다.
워크트리 대신 전체 클론을 강제하려면:
```bash
/gsd-workspace --new --name payments-rework --repos . --strategy clone
/msd-workspace --new --name payments-rework --repos . --strategy clone
```
---
@@ -69,7 +69,7 @@ GSD는 `~/gsd-workspaces/feature-b/` 내에 `hr-ui`와 `ZeymoAPI`의 워크트
## 브랜치 명시적 지정
```bash
/gsd-workspace --new --name payments-rework --repos . --branch feature/payments-v2
/msd-workspace --new --name payments-rework --repos . --branch feature/payments-v2
```
`--branch` 플래그는 워크스페이스의 모든 저장소에 대한 브랜치 이름을 설정합니다. 기본값은 `workspace/<name>`입니다.
@@ -79,43 +79,43 @@ GSD는 `~/gsd-workspaces/feature-b/` 내에 `hr-ui`와 `ZeymoAPI`의 워크트
## 대화형 질문 건너뛰기
```bash
/gsd-workspace --new --name payments-rework --repos . --auto
/msd-workspace --new --name payments-rework --repos . --auto
```
GSD는 프롬프트 없이 모든 기본값을 수락합니다.
MSD는 프롬프트 없이 모든 기본값을 수락합니다.
---
## 워크스페이스 내에서 GSD 초기화
## 워크스페이스 내에서 MSD 초기화
워크스페이스를 생성한 후 그 안으로 이동하고 GSD 프로젝트를 초기화합니다:
워크스페이스를 생성한 후 그 안으로 이동하고 MSD 프로젝트를 초기화합니다:
```bash
cd ~/gsd-workspaces/feature-b
/gsd-new-project
cd ~/msd-workspaces/feature-b
/msd-new-project
```
워크스페이스 내의 `.planning/` 디렉터리가 해당 디렉터리에서 실행되는 모든 후속 GSD 명령의 루트입니다. 이것은 소스 저장소에 존재하는 어떠한 `.planning/`과도 완전히 분리되어 있습니다.
워크스페이스 내의 `.planning/` 디렉터리가 해당 디렉터리에서 실행되는 모든 후속 MSD 명령의 루트입니다. 이것은 소스 저장소에 존재하는 어떠한 `.planning/`과도 완전히 분리되어 있습니다.
---
## 워크스페이스 목록 보기
```bash
/gsd-workspace --list
/msd-workspace --list
```
모든 활성 GSD 워크스페이스와 상태를 출력합니다.
모든 활성 MSD 워크스페이스와 상태를 출력합니다.
---
## 워크스페이스 제거
```bash
/gsd-workspace --remove feature-b
/msd-workspace --remove feature-b
```
GSD는 git 워크트리를 제거하고 워크스페이스 디렉터리를 정리합니다. 이 작업은 원격 저장소에서 브랜치를 삭제하지 않으며 로컬 워크트리와 워크스페이스 디렉터리만 제거합니다.
MSD는 git 워크트리를 제거하고 워크스페이스 디렉터리를 정리합니다. 이 작업은 원격 저장소에서 브랜치를 삭제하지 않으며 로컬 워크트리와 워크스페이스 디렉터리만 제거합니다.
---
@@ -123,15 +123,15 @@ GSD는 git 워크트리를 제거하고 워크스페이스 디렉터리를 정
워크스페이스를 선택할 때:
- **여러 저장소**(예: API 저장소와 함께 출시되는 UI 저장소)를 하나의 GSD 프로젝트 아래서 조율해야 할 때
- **여러 저장소**(예: API 저장소와 함께 출시되는 UI 저장소)를 하나의 MSD 프로젝트 아래서 조율해야 할 때
- 피처별로 자체 브랜치, 잠금 파일, 빌드 아티팩트를 가진 **별도의 git 워크트리**가 필요할 때 — 한 환경에서의 빌드와 의존성 설치가 다른 환경에 영향을 주지 않도록
- 메인 저장소의 `.planning/` 하위 디렉터리가 아닌 **완전히 독립적인 `.planning/` 루트**를 원할 때
- 각 트래커 이슈가 워크스페이스에 매핑되는 이슈 기반 워크플로를 따를 때([트래커 이슈에서 GSD 구동](drive-gsd-from-a-tracker-issue.md) 참조)
- 각 트래커 이슈가 워크스페이스에 매핑되는 이슈 기반 워크플로를 따를 때([트래커 이슈에서 MSD 구동](drive-msd-from-a-tracker-issue.md) 참조)
[워크스트림](work-in-parallel-with-workstreams.md)을 선택할 때:
- 모든 작업이 **하나의 저장소**에 있고 같은 git 히스토리를 공유할 때
- 서로의 `STATE.md` 파일 간의 컨텍스트 유입 없이 서로 다른 관심 영역(API, UI, 인프라)에 대해 동시에 `/gsd-plan-phase` 또는 `/gsd-discuss-phase`를 실행하고 싶을 때
- 서로의 `STATE.md` 파일 간의 컨텍스트 유입 없이 서로 다른 관심 영역(API, UI, 인프라)에 대해 동시에 `/msd-plan-phase` 또는 `/msd-discuss-phase`를 실행하고 싶을 때
- 관심사별로 별도의 워크트리가 필요하지 않고 계획 컨텍스트 전환으로 충분할 때
---
@@ -139,6 +139,6 @@ GSD는 git 워크트리를 제거하고 워크스페이스 디렉터리를 정
## 관련 문서
- [워크스트림으로 병렬 작업](work-in-parallel-with-workstreams.md)
- [트래커 이슈에서 GSD 구동](drive-gsd-from-a-tracker-issue.md)
- [트래커 이슈에서 MSD 구동](drive-msd-from-a-tracker-issue.md)
- [명령 참조](../COMMANDS.md)
- [문서 인덱스](../README.md)

62
docs/ko-KR/how-to/migrate-from-gsd-2.md
View File

@@ -1,22 +1,22 @@
# GSD-2에서 마이그레이션하는 방법
**목표:** 이전 GSD-2 프로젝트(`.gsd/` 디렉터리 레이아웃)를 GSD Core(`.planning/` 레이아웃)로 이전하고, 선택적으로 저장소에 있는 기존 ADR, PRD, 또는 스펙 문서를 새 계획 구조에 통합합니다.
**목표:** 이전 GSD-2 프로젝트(`.gsd/` 디렉터리 레이아웃)를 MSD Core(`.planning/` 레이아웃)로 이전하고, 선택적으로 저장소에 있는 기존 ADR, PRD, 또는 스펙 문서를 새 계획 구조에 통합합니다.
**사전 조건:** GSD Core가 설치되어 있어야 합니다. GSD-2 프로젝트 디렉터리가 디스크에 있어야 합니다.
**사전 조건:** MSD Core가 설치되어 있어야 합니다. GSD-2 프로젝트 디렉터리가 디스크에 있어야 합니다.
---
## 마이그레이션 대상 이해
GSD-2는 `.gsd/` 디렉터리를 계획 루트로 사용했습니다. GSD Core는 `.planning/`을 사용합니다. 마이그레이션은 이를 역전합니다: `.gsd/` 아티팩트를 읽고 모든 GSD Core 명령이 기대하는 표준 `.planning/` 구조로 작성합니다.
GSD-2는 `.gsd/` 디렉터리를 계획 루트로 사용했습니다. MSD Core는 `.planning/`을 사용합니다. 마이그레이션은 이를 역전합니다: `.gsd/` 아티팩트를 읽고 모든 MSD Core 명령이 기대하는 표준 `.planning/` 구조로 작성합니다.
| GSD-2에 존재하는 것 | `/gsd-import --from-gsd2`가 생성하는 것 |
| GSD-2에 존재하는 것 | `/msd-import --from-gsd2`가 생성하는 것 |
|----------------------|-----------------------------------------|
| `.gsd/PROJECT.md` | `.planning/PROJECT.md` |
| `.gsd/ROADMAP.md` | `.planning/ROADMAP.md` |
| `.gsd/STATE.md` | `.planning/STATE.md` |
| `.gsd/phases/` 디렉터리 | `.planning/phases/` 디렉터리 |
| 페이즈 `PLAN.md` 파일 | GSD Core `{NN}-{MM}-PLAN.md` 파일 (이름 변경 적용) |
| 페이즈 `PLAN.md` 파일 | MSD Core `{NN}-{MM}-PLAN.md` 파일 (이름 변경 적용) |
충돌 감지는 파일이 작성되기 전에 실행됩니다. 대상 디렉터리에 이미 `PROJECT.md`가 있고 가져오는 콘텐츠와 모순되면 마이그레이션은 BLOCKER 게이트에서 중단하고 해결할 충돌 목록을 표시합니다.
@@ -27,15 +27,15 @@ GSD-2는 `.gsd/` 디렉터리를 계획 루트로 사용했습니다. GSD Core
### 현재 디렉터리 마이그레이션
```bash
/gsd-import --from-gsd2
/msd-import --from-gsd2
```
GSD는 현재 작업 디렉터리의 `.gsd/`를 읽고 마이그레이션된 아티팩트를 `.planning/`에 작성합니다.
MSD는 현재 작업 디렉터리의 `.gsd/`를 읽고 마이그레이션된 아티팩트를 `.planning/`에 작성합니다.
### 다른 경로에서 마이그레이션
```bash
/gsd-import --from-gsd2 --path ~/projects/old-project
/msd-import --from-gsd2 --path ~/projects/old-project
```
GSD-2 프로젝트가 현재 작업 디렉터리가 아닌 경우 `--path`를 사용합니다.
@@ -46,7 +46,7 @@ GSD-2 프로젝트가 현재 작업 디렉터리가 아닌 경우 `--path`를
충돌 감지에서 블로커가 발견되면 — 예를 들어, 기존 `.planning/PROJECT.md`와 모순되는 GSD-2 기술 스택 선언 — 충돌 보고서를 출력하고 파일을 작성하지 않고 중단합니다.
보고서를 읽고 모순을 해결한 후(소스 문서 또는 기존 계획 아티팩트 편집), `/gsd-import --from-gsd2`를 다시 실행합니다. 마이그레이션은 완전히 통과될 때까지 안전하게 재실행할 수 있습니다.
보고서를 읽고 모순을 해결한 후(소스 문서 또는 기존 계획 아티팩트 편집), `/msd-import --from-gsd2`를 다시 실행합니다. 마이그레이션은 완전히 통과될 때까지 안전하게 재실행할 수 있습니다.
---
@@ -55,30 +55,30 @@ GSD-2 프로젝트가 현재 작업 디렉터리가 아닌 경우 `--path`를
전체 GSD-2 프로젝트가 아닌 독립형 플랜 문서(팀 계획 문서, 마크다운 스펙, 내보낸 작업 목록)가 있는 경우 `--from`을 사용합니다:
```bash
/gsd-import --from /tmp/team-plan.md
/msd-import --from /tmp/team-plan.md
```
GSD는 동일한 충돌 감지 패스를 수행하고, 콘텐츠를 GSD Core `PLAN.md` 형식으로 변환하며, 플랜 체커로 결과를 검증합니다. 검증 후 대상 파일명과 다음 단계가 표시됩니다.
MSD는 동일한 충돌 감지 패스를 수행하고, 콘텐츠를 MSD Core `PLAN.md` 형식으로 변환하며, 플랜 체커로 결과를 검증합니다. 검증 후 대상 파일명과 다음 단계가 표시됩니다.
---
## 기존 문서 통합
저장소에 이미 ADR(아키텍처 결정 기록), PRD, 또는 사양 문서가 있는 경우 마이그레이션 후 `/gsd-ingest-docs`를 사용하여 `.planning/` 구조에 합성합니다:
저장소에 이미 ADR(아키텍처 결정 기록), PRD, 또는 사양 문서가 있는 경우 마이그레이션 후 `/msd-ingest-docs`를 사용하여 `.planning/` 구조에 합성합니다:
### 전체 저장소 스캔(모드 자동 감지)
```bash
/gsd-ingest-docs
/msd-ingest-docs
```
`.planning/`이 이미 있는 경우(예: 방금 실행한 마이그레이션에서) GSD는 기본적으로 병합 모드를 사용합니다 — 기존 내용을 덮어쓰지 않고 가져온 문서와 함께 합성합니다.
`.planning/`이 이미 있는 경우(예: 방금 실행한 마이그레이션에서) MSD는 기본적으로 병합 모드를 사용합니다 — 기존 내용을 덮어쓰지 않고 가져온 문서와 함께 합성합니다.
### 특정 디렉터리로 범위 지정
```bash
/gsd-ingest-docs docs/
/gsd-ingest-docs docs/adr/
/msd-ingest-docs docs/
/msd-ingest-docs docs/adr/
```
### 명시적 우선순위 매니페스트 사용
@@ -86,7 +86,7 @@ GSD는 동일한 충돌 감지 패스를 수행하고, 콘텐츠를 GSD Core `PL
문서 유형이 혼합되거나 충돌 시 어떤 문서가 우선순위를 가질지 제어하고 싶을 때:
```bash
/gsd-ingest-docs --manifest ingest.yaml
/msd-ingest-docs --manifest ingest.yaml
```
매니페스트는 문서당 `{path, type, precedence?}`를 나열하는 YAML 파일입니다. 예상 형태는 [명령 참조](../COMMANDS.md)의 `--manifest` 플래그 설명을 참조하세요.
@@ -94,11 +94,11 @@ GSD는 동일한 충돌 감지 패스를 수행하고, 콘텐츠를 GSD Core `PL
### 특정 모드 강제
```bash
/gsd-ingest-docs --mode merge # 기존 .planning/에 병합
/gsd-ingest-docs --mode new # 처음부터 부트스트랩 (덮어쓰기)
/msd-ingest-docs --mode merge # 기존 .planning/에 병합
/msd-ingest-docs --mode new # 처음부터 부트스트랩 (덮어쓰기)
```
**출력:** `/gsd-ingest-docs`는 항상 세 가지 버킷(자동 해결, 경쟁 변형, 미해결 블로커)이 있는 `INGEST-CONFLICTS.md`를 생성합니다. 모든 인제스트 실행 후 이 파일을 검토하세요. LOCKED vs LOCKED ADR 모순에서만 하드 중단이 발생합니다. 다른 모든 것은 자동으로 버려지지 않고 검토를 위해 표시됩니다.
**출력:** `/msd-ingest-docs`는 항상 세 가지 버킷(자동 해결, 경쟁 변형, 미해결 블로커)이 있는 `INGEST-CONFLICTS.md`를 생성합니다. 모든 인제스트 실행 후 이 파일을 검토하세요. LOCKED vs LOCKED ADR 모순에서만 하드 중단이 발생합니다. 다른 모든 것은 자동으로 버려지지 않고 검토를 위해 표시됩니다.
---
@@ -107,19 +107,19 @@ GSD는 동일한 충돌 감지 패스를 수행하고, 콘텐츠를 GSD Core `PL
마이그레이션과 문서 인제스트가 완료되면 프로젝트 상태가 일관성 있는지 확인합니다:
```bash
/gsd-health
/gsd-health --repair
/msd-health
/msd-health --repair
```
`/gsd-health`는 `.planning/` 디렉터리 무결성을 확인하고 드리프트를 보고합니다. `--repair`는 복구 가능한 문제를 자동으로 수정합니다.
`/msd-health`는 `.planning/` 디렉터리 무결성을 확인하고 드리프트를 보고합니다. `--repair`는 복구 가능한 문제를 자동으로 수정합니다.
그다음 GSD Core가 프로젝트 상태를 읽을 수 있는지 확인합니다:
그다음 MSD Core가 프로젝트 상태를 읽을 수 있는지 확인합니다:
```bash
/gsd-progress
/msd-progress
```
프로젝트가 깔끔하게 이전되었다면 현재 페이즈 상태와 권장 다음 단계가 표시됩니다. 여기서부터 표준 GSD Core 워크플로가 적용됩니다.
프로젝트가 깔끔하게 이전되었다면 현재 페이즈 상태와 권장 다음 단계가 표시됩니다. 여기서부터 표준 MSD Core 워크플로가 적용됩니다.
---
@@ -127,13 +127,13 @@ GSD는 동일한 충돌 감지 패스를 수행하고, 콘텐츠를 GSD Core `PL
| 상황 | 할 일 |
|-----------|-----------|
| `.gsd/`가 현재 디렉터리에 있음 | `/gsd-import --from-gsd2` 실행 (`--path` 불필요) |
| `.gsd/`가 현재 디렉터리에 있음 | `/msd-import --from-gsd2` 실행 (`--path` 불필요) |
| `.gsd/`가 다른 디렉터리에 있음 | `--path ~/projects/old-project` 사용 |
| 전체 GSD-2 프로젝트가 아닌 독립형 플랜 문서가 있음 | `/gsd-import --from /path/to/plan.md` 사용 |
| `docs/adr/`에 ADR이 있음 | 마이그레이션 후 `/gsd-ingest-docs docs/adr/` 실행 |
| ADR, PRD, 스펙이 혼합되어 있음 | 저장소 루트에서 `/gsd-ingest-docs` 실행; 자동으로 분류됨 |
| 전체 GSD-2 프로젝트가 아닌 독립형 플랜 문서가 있음 | `/msd-import --from /path/to/plan.md` 사용 |
| `docs/adr/`에 ADR이 있음 | 마이그레이션 후 `/msd-ingest-docs docs/adr/` 실행 |
| ADR, PRD, 스펙이 혼합되어 있음 | 저장소 루트에서 `/msd-ingest-docs` 실행; 자동으로 분류됨 |
| 충돌 감지가 블로커를 보고함 | 나열된 모순을 해결한 후 재실행; 모든 블로커가 해결될 때까지 파일이 작성되지 않음 |
| 마이그레이션 작동 여부 확인이 안 됨 | `/gsd-health`와 `/gsd-progress`를 실행하여 확인 |
| 마이그레이션 작동 여부 확인이 안 됨 | `/msd-health`와 `/msd-progress`를 실행하여 확인 |
| INGEST-CONFLICTS.md에 미해결 블로커가 나열됨 | 영향받는 문서가 계획에 통합되기 전에 수동 해결 필요 |
---

50
docs/ko-KR/how-to/plan-a-phase.md
View File

@@ -2,23 +2,23 @@
**목표:** 페이즈 결정 사항과 리서치를 실행 준비가 된 원자적이고 검증 가능한 태스크 계획으로 변환합니다.
**전제 조건:** `.planning/ROADMAP.md`가 존재해야 합니다. `/gsd-discuss-phase`에서 생성된 `{phase}-CONTEXT.md`를 강력히 권장하지만 필수는 아닙니다.
**전제 조건:** `.planning/ROADMAP.md`가 존재해야 합니다. `/msd-discuss-phase`에서 생성된 `{phase}-CONTEXT.md`를 강력히 권장하지만 필수는 아닙니다.
---
## 표준 기획 흐름 실행
```bash
/gsd-plan-phase 2
/msd-plan-phase 2
```
다음 세 단계를 순서대로 실행합니다:
1. **리서치** — `gsd-phase-researcher` 서브에이전트가 도메인을 조사하고 `{phase}-RESEARCH.md`를 작성합니다.
2. **기획** — `gsd-planner` 서브에이전트가 컨텍스트, 리서치, 요구 사항을 읽고 하나 이상의 `{phase}-{N}-PLAN.md` 파일을 작성합니다.
3. **검증** — `gsd-plan-checker` 서브에이전트가 8개 차원에서 계획 품질을 검증하고 품질 게이트를 통과할 때까지 최대 3회의 수정 루프를 실행합니다.
1. **리서치** — `msd-phase-researcher` 서브에이전트가 도메인을 조사하고 `{phase}-RESEARCH.md`를 작성합니다.
2. **기획** — `msd-planner` 서브에이전트가 컨텍스트, 리서치, 요구 사항을 읽고 하나 이상의 `{phase}-{N}-PLAN.md` 파일을 작성합니다.
3. **검증** — `msd-plan-checker` 서브에이전트가 8개 차원에서 계획 품질을 검증하고 품질 게이트를 통과할 때까지 최대 3회의 수정 루프를 실행합니다.
페이즈 번호가 없으면 GSD Core는 로드맵에서 다음 미기획 페이즈를 대상으로 합니다.
페이즈 번호가 없으면 MSD Core는 로드맵에서 다음 미기획 페이즈를 대상으로 합니다.
---
@@ -27,34 +27,34 @@
**도메인이 익숙하고 새 리서치가 필요 없는 경우:**
```bash
/gsd-plan-phase 3 --skip-research
/msd-plan-phase 3 --skip-research
```
**RESEARCH.md가 이미 존재하지만 강제로 새로 고침하려는 경우:**
```bash
/gsd-plan-phase 3 --research
/msd-plan-phase 3 --research
```
**리서치만 실행하려는 경우** — RESEARCH.md를 작성하고 기획 전 종료:
```bash
/gsd-plan-phase --research-phase 4
/msd-plan-phase --research-phase 4
```
RESEARCH.md가 이미 존재하면 업데이트, 보기, 또는 건너뛰기 프롬프트가 표시됩니다. 프롬프트 없이 강제 새로 고침하려면:
```bash
/gsd-plan-phase --research-phase 4 --research
/msd-plan-phase --research-phase 4 --research
```
리서처를 실행하지 않고 기존 RESEARCH.md를 표준 출력으로 출력하려면:
```bash
/gsd-plan-phase --research-phase 4 --view
/msd-plan-phase --research-phase 4 --view
```
참고: `--research-phase <N>`은 `/gsd-plan-phase`의 플래그입니다. 독립형 리서치 페이즈 명령은 없습니다. 이전의 독립형 리서치 명령은 이 플래그로 대체되었습니다.
참고: `--research-phase <N>`은 `/msd-plan-phase`의 플래그입니다. 독립형 리서치 페이즈 명령은 없습니다. 이전의 독립형 리서치 명령은 이 플래그로 대체되었습니다.
---
@@ -63,7 +63,7 @@ RESEARCH.md가 이미 존재하면 업데이트, 보기, 또는 건너뛰기 프
**기술 계층별이 아닌 기능별 얇은 종단 슬라이스**(UI → API → DB)로 태스크를 구성하려면:
```bash
/gsd-plan-phase 1 --mvp
/msd-plan-phase 1 --mvp
```
이전 페이즈 요약이 없는 새 프로젝트의 페이즈 1에서 `--mvp`는 프로젝트 스캐폴드, 라우팅, 실제 DB 읽기/쓰기 하나, 실제 UI 인터랙션 하나, 개발 배포를 다루는 `SKELETON.md`도 생성합니다.
@@ -77,13 +77,13 @@ RESEARCH.md가 이미 존재하면 업데이트, 보기, 또는 건너뛰기 프
**TDD 적용을 원하는 경우** — 각 동작 추가 태스크는 구현 전 실패하는 테스트로 시작합니다:
```bash
/gsd-plan-phase 1 --tdd
/msd-plan-phase 1 --tdd
```
`--mvp`와 조합 가능:
```bash
/gsd-plan-phase 1 --mvp --tdd
/msd-plan-phase 1 --mvp --tdd
```
모든 동작 추가 태스크가 RED → GREEN → REFACTOR를 따르는 수직 슬라이스를 생성합니다. 플래너는 적합한 태스크(비즈니스 로직, API 엔드포인트, 데이터 변환)에 `type: tdd`를 적용하고 UI, 설정, 연결 코드에는 표준 `type: execute`를 사용합니다.
@@ -91,17 +91,17 @@ RESEARCH.md가 이미 존재하면 업데이트, 보기, 또는 건너뛰기 프
TDD 모드는 설정에서도 지속할 수 있습니다:
```bash
node gsd-tools.cjs config-set workflow.tdd_mode true
node msd-tools.cjs config-set workflow.tdd_mode true
```
---
## 크로스 AI 리뷰 피드백으로 재기획
**`/gsd-review --phase N`을 실행하여 `REVIEWS.md`가 존재하는 경우:**
**`/msd-review --phase N`을 실행하여 `REVIEWS.md`가 존재하는 경우:**
```bash
/gsd-plan-phase 3 --reviews
/msd-plan-phase 3 --reviews
```
플래너는 `REVIEWS.md`를 읽고 피드백을 반영하여 계획을 수정합니다. `--gaps`와 함께 사용할 수 없습니다.
@@ -109,7 +109,7 @@ node gsd-tools.cjs config-set workflow.tdd_mode true
**자동화된 루프를 원하는 경우** — HIGH 우려 사항이 남지 않을 때까지 재기획 및 재검토:
```bash
/gsd-plan-review-convergence 3
/msd-plan-review-convergence 3
```
수렴 루프는 plan → review → replan → re-review 사이클을 기본 최대 3회 실행합니다. 상한선을 변경하려면 `--max-cycles N`을 사용하세요.
@@ -121,7 +121,7 @@ node gsd-tools.cjs config-set workflow.tdd_mode true
**`VERIFICATION.md`에 미해결 갭이 있고 해당 갭만을 대상으로 재기획하려는 경우:**
```bash
/gsd-plan-phase 3 --gaps
/msd-plan-phase 3 --gaps
```
리서치는 건너뛰고 플래너는 검증 갭을 직접 읽습니다.
@@ -133,13 +133,13 @@ node gsd-tools.cjs config-set workflow.tdd_mode true
**`workflow.plan_bounce_script`가 설정되어 있고 완성된 계획의 외부 검증을 원하는 경우:**
```bash
/gsd-plan-phase 1 --bounce
/msd-plan-phase 1 --bounce
```
설정에 바운스가 활성화된 경우에도 건너뛰려면:
```bash
/gsd-plan-phase 1 --skip-bounce
/msd-plan-phase 1 --skip-bounce
```
---
@@ -147,7 +147,7 @@ node gsd-tools.cjs config-set workflow.tdd_mode true
## 대화형 확인 억제
```bash
/gsd-plan-phase --auto
/msd-plan-phase --auto
```
모든 프롬프트를 건너뜁니다. 자동화 파이프라인에 유용합니다. 설정에서 `research_enabled`가 false인 경우 리서치는 건너뜁니다.
@@ -171,7 +171,7 @@ node gsd-tools.cjs config-set workflow.tdd_mode true
### 계획 품질 차원
`gsd-plan-checker`는 실행을 허용하기 전에 8개 차원에서 계획을 검증합니다:
`msd-plan-checker`는 실행을 허용하기 전에 8개 차원에서 계획을 검증합니다:
1. 태스크 원자성 — 각 태스크는 단일 관심사
2. 의존성 정확성 — 웨이브 순서가 일관됨
@@ -191,7 +191,7 @@ node gsd-tools.cjs config-set workflow.tdd_mode true
`status: passed`가 있는 `VERIFICATION.md`가 있는 페이즈는 닫힌 것으로 간주됩니다. 재기획을 시도하면 오류로 중단됩니다. 종료가 잘못된 경우 `--force`로 재정의하세요:
```bash
/gsd-plan-phase 2 --force
/msd-plan-phase 2 --force
```
트랜스크립트와 커밋된 계획 문서에 경고가 기록됩니다.

116
docs/ko-KR/how-to/recover-and-troubleshoot.md
View File

@@ -2,7 +2,7 @@
**목표:** 조건부 레시피 구조를 사용하여 컨텍스트 손실과 손상된 상태부터 설치 실패와 권한 오류까지 일반적인 문제를 식별하고 수정합니다.
**사전 조건:** GSD Core가 설치되어 있어야 합니다. 설치 문제의 경우 [런타임에 설치](install-on-your-runtime.md)를 참조하세요.
**사전 조건:** MSD Core가 설치되어 있어야 합니다. 설치 문제의 경우 [런타임에 설치](install-on-your-runtime.md)를 참조하세요.
---
@@ -11,7 +11,7 @@
### 현재 위치를 파악하지 못한 경우
```bash
/gsd-progress
/msd-progress
```
모든 상태 파일을 읽고 현재 위치와 다음 할 일을 정확히 알려줍니다.
@@ -19,13 +19,13 @@
올바른 다음 단계로 자동 진행하려면:
```bash
/gsd-progress --next
/msd-progress --next
```
### 새 세션을 시작하고 컨텍스트를 복원해야 하는 경우
```bash
/gsd-resume-work
/msd-resume-work
```
마지막 핸드오프의 전체 세션 컨텍스트(현재 페이즈, 계획 결정, 작업이 중단된 위치)를 복원합니다.
@@ -41,21 +41,21 @@
그다음 상태를 복원합니다:
```bash
/gsd-resume-work
/msd-resume-work
```
GSD는 새로운 컨텍스트를 중심으로 설계되었습니다. 모든 서브에이전트는 이미 깨끗한 200k 창을 받습니다. 메인 세션은 시간이 지남에 따라 저하됩니다 — 초기화하고 재개하는 것이 올바른 해결책이며 계속 밀어붙이는 것이 아닙니다.
MSD는 새로운 컨텍스트를 중심으로 설계되었습니다. 모든 서브에이전트는 이미 깨끗한 200k 창을 받습니다. 메인 세션은 시간이 지남에 따라 저하됩니다 — 초기화하고 재개하는 것이 올바른 해결책이며 계속 밀어붙이는 것이 아닙니다.
### 중단 전에 컨텍스트를 저장하고 싶은 경우
```bash
/gsd-pause-work
/msd-pause-work
```
현재 위치가 있는 `.planning/HANDOFF.json`을 생성합니다. 세션 후 요약도 `.planning/reports/`에 작성하려면 `--report`를 추가합니다:
```bash
/gsd-pause-work --report
/msd-pause-work --report
```
---
@@ -65,7 +65,7 @@ GSD는 새로운 컨텍스트를 중심으로 설계되었습니다. 모든 서
### `.planning/` 무결성이 불확실한 경우
```bash
/gsd-health
/msd-health
```
오류, 경고, 정보 메모에 걸쳐 상태를 보고합니다:
@@ -79,7 +79,7 @@ GSD는 새로운 컨텍스트를 중심으로 설계되었습니다. 모든 서
일반적인 자동 복구 가능한 문제(오류 E004, E005; 경고 W003, W008):
```bash
/gsd-health --repair
/msd-health --repair
```
누락된 `STATE.md`를 재생성하고, 손상된 `config.json`을 기본값으로 재설정하며, 누락된 구성 키를 추가합니다. `PROJECT.md`나 `ROADMAP.md`를 덮어쓰지 않습니다.
@@ -89,40 +89,40 @@ GSD는 새로운 컨텍스트를 중심으로 설계되었습니다. 모든 서
이것은 경고 `W002`를 생성합니다. 상태 CLI를 사용하여 진단하고 복구합니다:
```bash
node "$HOME/.claude/gsd-core/bin/gsd-tools.cjs" state validate
node "$HOME/.claude/msd-core/bin/msd-tools.cjs" state validate
```
쓰기 없이 동기화가 변경할 내용 미리 보기:
```bash
node "$HOME/.claude/gsd-core/bin/gsd-tools.cjs" state sync --verify
node "$HOME/.claude/msd-core/bin/msd-tools.cjs" state sync --verify
```
동기화 적용:
```bash
node "$HOME/.claude/gsd-core/bin/gsd-tools.cjs" state sync
node "$HOME/.claude/msd-core/bin/msd-tools.cjs" state sync
```
이 명령들은 디스크의 실제 프로젝트 상태에서 `STATE.md`를 재구성합니다. 수동 `STATE.md` 편집을 대체합니다.
### "Project already initialised"가 표시되는 경우
`.planning/PROJECT.md`가 이미 있습니다. `/gsd-new-project`는 안전 확인입니다. 정말로 처음부터 다시 시작하고 싶다면 먼저 `.planning/` 디렉터리를 삭제합니다:
`.planning/PROJECT.md`가 이미 있습니다. `/msd-new-project`는 안전 확인입니다. 정말로 처음부터 다시 시작하고 싶다면 먼저 `.planning/` 디렉터리를 삭제합니다:
```bash
rm -rf .planning/
```
그다음 `/gsd-new-project`를 다시 실행합니다.
그다음 `/msd-new-project`를 다시 실행합니다.
### 컨텍스트 창 사용률이 높은 경우
```bash
/gsd-health --context
/msd-health --context
```
컨텍스트 창 사용률 가드를 프로브합니다. 60%에서 경고, 70%에서 위험. 경고 임계값을 초과한 경우 다음 주요 명령을 시작하기 전에 `/clear`를 실행한 후 `/gsd-resume-work`를 실행합니다.
컨텍스트 창 사용률 가드를 프로브합니다. 60%에서 경고, 70%에서 위험. 경고 임계값을 초과한 경우 다음 주요 명령을 시작하기 전에 `/clear`를 실행한 후 `/msd-resume-work`를 실행합니다.
---
@@ -130,7 +130,7 @@ rm -rf .planning/
### 실행자가 Bash 명령에서 "Permission denied"를 받는 경우
GSD의 `gsd-executor` 서브에이전트는 쓰기 가능한 Bash 접근이 필요합니다. `~/.claude/settings.json`의 `permissions.allow` 아래에 필요한 패턴을 추가합니다. 최소한:
MSD의 `msd-executor` 서브에이전트는 쓰기 가능한 Bash 접근이 필요합니다. `~/.claude/settings.json`의 `permissions.allow` 아래에 필요한 패턴을 추가합니다. 최소한:
```json
"Bash(git add:*)",
@@ -148,17 +148,17 @@ GSD의 `gsd-executor` 서브에이전트는 쓰기 가능한 Bash 접근이 필
플랜이 너무 야심찬지 확인합니다. 플랜에는 최대 두세 개의 작업이 있어야 합니다. 작업이 너무 크면 단일 컨텍스트 창이 안정적으로 생성할 수 있는 것을 초과합니다. 더 작은 범위로 페이즈를 다시 계획합니다:
```bash
/gsd-plan-phase 1
/msd-plan-phase 1
```
무엇이 잘못되었는지에 대한 체계적인 진단은 [실패한 실행 디버그](debug-a-failed-execution.md)를 참조하세요.
### 병렬 실행이 빌드 잠금 오류 또는 사전 커밋 훅 실패를 일으키는 경우
이것은 여러 에이전트가 동시에 빌드 도구를 트리거하여 발생합니다. GSD는 v1.26 이후 이를 자동으로 처리합니다. 오래된 버전이거나 여전히 경합이 보이면 병렬 실행을 비활성화합니다:
이것은 여러 에이전트가 동시에 빌드 도구를 트리거하여 발생합니다. MSD는 v1.26 이후 이를 자동으로 처리합니다. 오래된 버전이거나 여전히 경합이 보이면 병렬 실행을 비활성화합니다:
```bash
/gsd-settings
/msd-settings
```
`parallelization.enabled`를 `false`로 설정합니다.
@@ -171,7 +171,7 @@ GSD의 `gsd-executor` 서브에이전트는 쓰기 가능한 Bash 접근이 필
git log --oneline -10
```
알려진 Claude Code 분류 버그로 인해 작업이 성공했는데도 실패를 보고할 수 있습니다. GSD의 오케스트레이터는 실제 출력을 점검하지만 불일치가 보이면 커밋이 실제 근거입니다.
알려진 Claude Code 분류 버그로 인해 작업이 성공했는데도 실패를 보고할 수 있습니다. MSD의 오케스트레이터는 실제 출력을 점검하지만 불일치가 보이면 커밋이 실제 근거입니다.
---
@@ -179,31 +179,31 @@ git log --oneline -10
### 플랜이 의도와 맞지 않거나 잘못 정렬된 경우
계획 전에 `/gsd-discuss-phase N`을 실행합니다. 대부분의 플랜 품질 문제는 `CONTEXT.md`가 방지했을 가정에서 발생합니다:
계획 전에 `/msd-discuss-phase N`을 실행합니다. 대부분의 플랜 품질 문제는 `CONTEXT.md`가 방지했을 가정에서 발생합니다:
```bash
/gsd-discuss-phase 1
/msd-discuss-phase 1
```
전체 세션을 시작하지 않고 GSD가 현재 어떤 가정을 하는지 보려면:
전체 세션을 시작하지 않고 MSD가 현재 어떤 가정을 하는지 보려면:
```bash
/gsd-discuss-phase 3 --assumptions
/msd-discuss-phase 3 --assumptions
```
### 실행 후 무언가를 변경해야 하는 경우
`/gsd-execute-phase`를 다시 실행하지 마세요. 대상이 되는 수정에는 `/gsd-quick`을 사용합니다:
`/msd-execute-phase`를 다시 실행하지 마세요. 대상이 되는 수정에는 `/msd-quick`을 사용합니다:
```bash
/gsd-quick "Fix the login button not responding on mobile Safari"
/msd-quick "Fix the login button not responding on mobile Safari"
```
또는 `/gsd-verify-work N`을 사용하여 UAT를 통해 체계적으로 문제를 식별하고 수정합니다.
또는 `/msd-verify-work N`을 사용하여 UAT를 통해 체계적으로 문제를 식별하고 수정합니다.
### 명령이 "Spawning…"에서 멈춘 것처럼 보이는 경우
기다리세요. GSD 서브에이전트는 별도의 컨텍스트 창에서 실행됩니다. 진행 중일 때는 상위 세션에서 보이지 않습니다. 스폰 라인의 활성 상태 메모가 이것이 예상된 동작임을 확인합니다. 연구 및 계획 에이전트는 일상적으로 1~5분이 걸립니다. 검증 에이전트는 대규모 페이즈에서 더 오래 걸릴 수 있습니다.
기다리세요. MSD 서브에이전트는 별도의 컨텍스트 창에서 실행됩니다. 진행 중일 때는 상위 세션에서 보이지 않습니다. 스폰 라인의 활성 상태 메모가 이것이 예상된 동작임을 확인합니다. 연구 및 계획 에이전트는 일상적으로 1~5분이 걸립니다. 검증 에이전트는 대규모 페이즈에서 더 오래 걸릴 수 있습니다.
세션을 중단하지 마세요. 종료하면 진행 중인 서브에이전트 작업이 버려집니다.
@@ -216,56 +216,56 @@ git log --oneline -10
### 워크플로가 손상되거나 상태가 일관성이 없어 보이는 경우
```bash
/gsd-forensics
/msd-forensics
```
또는 설명과 함께:
```bash
/gsd-forensics "Phase 3 execution stalled after wave 1"
/msd-forensics "Phase 3 execution stalled after wave 1"
```
`/gsd-forensics`는 사후 분석 조사를 실행합니다: git 히스토리 이상 감지, 아티팩트 무결성, STATE.md 일관성, 커밋되지 않은 작업, 고아 워크트리. `.planning/forensics/`에 보고서를 작성하고 권장 복구 단계를 제시합니다. 읽기 전용이며 프로젝트 파일을 절대 수정하지 않습니다.
`/msd-forensics`는 사후 분석 조사를 실행합니다: git 히스토리 이상 감지, 아티팩트 무결성, STATE.md 일관성, 커밋되지 않은 작업, 고아 워크트리. `.planning/forensics/`에 보고서를 작성하고 권장 복구 단계를 제시합니다. 읽기 전용이며 프로젝트 파일을 절대 수정하지 않습니다.
### 페이즈 또는 플랜을 롤백해야 하는 경우
```bash
/gsd-undo --phase 03 # 페이즈 3의 모든 커밋 롤백
/gsd-undo --plan 03-02 # 페이즈 3의 플랜 02 커밋 롤백
/gsd-undo --last 5 # 가장 최근 GSD 커밋 5개에서 대화식으로 선택
/msd-undo --phase 03 # 페이즈 3의 모든 커밋 롤백
/msd-undo --plan 03-02 # 페이즈 3의 플랜 02 커밋 롤백
/msd-undo --last 5 # 가장 최근 MSD 커밋 5개에서 대화식으로 선택
```
`/gsd-undo`는 되돌리기 전에 종속 페이즈를 확인하고 항상 확인 게이트를 표시합니다.
`/msd-undo`는 되돌리기 전에 종속 페이즈를 확인하고 항상 확인 게이트를 표시합니다.
---
## 설치 및 업데이트 문제
### 설치 후 GSD가 인식되지 않는 경우
### 설치 후 MSD가 인식되지 않는 경우
런타임을 재시작합니다. GSD는 런타임의 명령 디렉터리(예: `~/.claude/commands/gsd/`)에 슬래시 명령을 설치합니다. 대부분의 런타임은 시작 시에만 새 명령을 발견합니다.
런타임을 재시작합니다. MSD는 런타임의 명령 디렉터리(예: `~/.claude/commands/msd/`)에 슬래시 명령을 설치합니다. 대부분의 런타임은 시작 시에만 새 명령을 발견합니다.
문제가 지속되면 설치를 확인합니다:
```bash
npx @opengsd/gsd-core@latest --claude --local
npx @golem15/msd-core@latest --claude --local
```
런타임별 설치 경로와 문제 해결은 [런타임에 설치](install-on-your-runtime.md)를 참조하세요.
### 업데이트가 로컬 변경 사항을 덮어쓴 경우
v1.17 이후 인스톨러는 로컬에서 수정된 파일을 `gsd-local-patches/`에 백업합니다. 변경 사항을 재적용합니다:
v1.17 이후 인스톨러는 로컬에서 수정된 파일을 `msd-local-patches/`에 백업합니다. 변경 사항을 재적용합니다:
```bash
/gsd-update --reapply
/msd-update --reapply
```
### npm을 통한 업데이트가 불가능한 경우
npm 중단이나 네트워크 제한으로 `npx @opengsd/gsd-core`가 실패하는 경우 npm 접근 없이도 작동하는 단계별 수동 업데이트 절차는 `docs/manual-update.md`를 참조하세요.
npm 중단이나 네트워크 제한으로 `npx @golem15/msd-core`가 실패하는 경우 npm 접근 없이도 작동하는 단계별 수동 업데이트 절차는 `docs/manual-update.md`를 참조하세요.
일상적인 업데이트는 [GSD 업데이트](update-gsd.md)를 참조하세요.
일상적인 업데이트는 [MSD 업데이트](update-msd.md)를 참조하세요.
---
@@ -276,13 +276,13 @@ npm 중단이나 네트워크 제한으로 `npx @opengsd/gsd-core`가 실패하
예산 프로필로 전환합니다:
```bash
/gsd-config --profile budget
/msd-config --profile budget
```
도메인이 익숙한 경우 설정에서 연구 및 플랜 체크 에이전트를 비활성화합니다:
```bash
/gsd-settings
/msd-settings
```
활성화된 MCP 서버도 감사합니다. 활성화된 모든 MCP 서버는 모든 턴에 도구 스키마를 주입합니다. 브라우저 및 플랫폼별 도구는 각각 20k+ 토큰이 소요될 수 있습니다. 현재 페이즈에 필요하지 않은 것은 `.claude/settings.json`에서 비활성화합니다:
@@ -299,19 +299,19 @@ npm 중단이나 네트워크 제한으로 `npx @opengsd/gsd-core`가 실패하
| 문제 | 해결책 |
|---------|---------|
| 컨텍스트 손실 또는 새 세션 | `/gsd-resume-work` 또는 `/gsd-progress` |
| 다음 단계를 모름 | `/gsd-progress --next` |
| 페이즈가 잘못됨 | `/gsd-undo --phase NN`, 그다음 다시 계획 |
| 무언가 고장남 | `/gsd-debug "description"` (수정 없이 분석만 하려면 `--diagnose` 추가) |
| 컨텍스트 손실 또는 새 세션 | `/msd-resume-work` 또는 `/msd-progress` |
| 다음 단계를 모름 | `/msd-progress --next` |
| 페이즈가 잘못됨 | `/msd-undo --phase NN`, 그다음 다시 계획 |
| 무언가 고장남 | `/msd-debug "description"` (수정 없이 분석만 하려면 `--diagnose` 추가) |
| STATE.md 동기화 오류 | `state validate` 후 `state sync` |
| `.planning/` 무결성 불확실 | `/gsd-health`, 그다음 `/gsd-health --repair` |
| 워크플로 상태 손상 | `/gsd-forensics` |
| 빠른 대상 수정 | `/gsd-quick` |
| 플랜이 비전과 맞지 않음 | `/gsd-discuss-phase N` 후 다시 계획 |
| 비용이 높아짐 | `/gsd-config --profile budget` 및 `/gsd-settings`에서 에이전트 끄기 |
| 업데이트가 로컬 변경 사항 손상 | `/gsd-update --reapply` |
| 세션 요약 원함 | `/gsd-pause-work --report` |
| 병렬 실행 빌드 오류 | GSD 업데이트 또는 `parallelization.enabled: false` 설정 |
| `.planning/` 무결성 불확실 | `/msd-health`, 그다음 `/msd-health --repair` |
| 워크플로 상태 손상 | `/msd-forensics` |
| 빠른 대상 수정 | `/msd-quick` |
| 플랜이 비전과 맞지 않음 | `/msd-discuss-phase N` 후 다시 계획 |
| 비용이 높아짐 | `/msd-config --profile budget` 및 `/msd-settings`에서 에이전트 끄기 |
| 업데이트가 로컬 변경 사항 손상 | `/msd-update --reapply` |
| 세션 요약 원함 | `/msd-pause-work --report` |
| 병렬 실행 빌드 오류 | MSD 업데이트 또는 `parallelization.enabled: false` 설정 |
---

38
docs/ko-KR/how-to/run-phases-autonomously.md
View File

@@ -1,6 +1,6 @@
# 페이즈를 자율적으로 실행하는 방법
남은 모든 페이즈 또는 지정된 범위를 무인으로 실행합니다. GSD가 각 단계마다 직접 진행하지 않아도 discuss → plan → execute를 진행합니다.
남은 모든 페이즈 또는 지정된 범위를 무인으로 실행합니다. MSD가 각 단계마다 직접 진행하지 않아도 discuss → plan → execute를 진행합니다.
자율 실행 중 페이즈 루프가 무엇을 하는지에 대한 배경은 [페이즈 루프](../explanation/the-phase-loop.md)를 참고하세요.
@@ -10,17 +10,17 @@
- `.planning/ROADMAP.md`와 `.planning/STATE.md`가 있는 활성 프로젝트
- 실행하려는 모든 페이즈가 자율 모드로 처리 가능한 상태여야 함 (보류 중 또는 진행 중, 이미 완료되지 않은 것)
- 중요한 설계 결정 사항은 이미 `PROJECT.md`에 있거나 이전 `/gsd-discuss-phase`를 통해 캡처되어 있어야 함 — 자율 모드는 `--interactive`를 사용할 때만 대화형으로 모호한 영역을 표시할 수 있음
- 중요한 설계 결정 사항은 이미 `PROJECT.md`에 있거나 이전 `/msd-discuss-phase`를 통해 캡처되어 있어야 함 — 자율 모드는 `--interactive`를 사용할 때만 대화형으로 모호한 영역을 표시할 수 있음
---
## 남은 모든 페이즈 실행
```bash
/gsd-autonomous
/msd-autonomous
```
GSD는 `ROADMAP.md`를 읽고, 미완료 페이즈를 번호 순으로 발견하며, 각각에 대해 discuss → plan → execute를 실행합니다. 모든 페이즈가 완료되면 자동으로 마일스톤 생애주기를 실행합니다: audit → complete → cleanup.
MSD는 `ROADMAP.md`를 읽고, 미완료 페이즈를 번호 순으로 발견하며, 각각에 대해 discuss → plan → execute를 실행합니다. 모든 페이즈가 완료되면 자동으로 마일스톤 생애주기를 실행합니다: audit → complete → cleanup.
---
@@ -29,15 +29,15 @@ GSD는 `ROADMAP.md`를 읽고, 미완료 페이즈를 번호 순으로 발견하
`--from`과 `--to`를 사용하여 실행 범위를 지정합니다. 두 플래그 모두 소수 페이즈 번호를 허용합니다(예: `3.1`).
```bash
/gsd-autonomous --from 3 # 페이즈 3, 4, 5 … (이미 완료된 1, 2 건너뜀)
/gsd-autonomous --to 5 # 5까지 포함한 페이즈
/gsd-autonomous --from 3 --to 5 # 정확히 페이즈 3, 4, 5
/msd-autonomous --from 3 # 페이즈 3, 4, 5 … (이미 완료된 1, 2 건너뜀)
/msd-autonomous --to 5 # 5까지 포함한 페이즈
/msd-autonomous --from 3 --to 5 # 정확히 페이즈 3, 4, 5
```
`--to`에 도달하면 마일스톤의 모든 페이즈가 완료되지 않았으므로 생애주기 단계는 건너뜁니다. 완료 배너가 재개 방법을 알려줍니다:
```text
Resume with: /gsd-autonomous --from 6
Resume with: /msd-autonomous --from 6
```
---
@@ -47,11 +47,11 @@ Resume with: /gsd-autonomous --from 6
기본적으로 자율 모드는 스마트 논의(배치 테이블 제안)를 사용하여 논의 질문에 자동으로 답변합니다. 계획 및 실행을 메인 컨텍스트 밖으로 유지하면서 설계 질문에 직접 답하고 싶다면:
```bash
/gsd-autonomous --interactive
/msd-autonomous --interactive
```
대화형 모드에서:
- `/gsd-discuss-phase`가 인라인으로 실행되어 답변을 기다림
- `/msd-discuss-phase`가 인라인으로 실행되어 답변을 기다림
- 기획 및 실행은 백그라운드 에이전트로 실행되므로 현재 페이즈가 구축되는 동안 다음 페이즈를 논의할 수 있음
- 메인 컨텍스트는 가볍게 유지됨 — 논의 대화만 누적됨
@@ -59,7 +59,7 @@ Resume with: /gsd-autonomous --from 6
## 여전히 적용되는 안전 게이트
자율 모드는 GSD의 품질 파이프라인을 우회하지 않습니다. 각 페이즈는 여전히:
자율 모드는 MSD의 품질 파이프라인을 우회하지 않습니다. 각 페이즈는 여전히:
- 실행 전 플랜 체커를 실행함
- 실행 후 `VERIFICATION.md`를 읽고 결과에 따라 라우팅함
@@ -74,15 +74,15 @@ Resume with: /gsd-autonomous --from 6
## 자율 모드를 사용하지 않아야 할 때
다음과 같은 경우 `/gsd-autonomous`를 사용하지 마세요:
다음과 같은 경우 `/msd-autonomous`를 사용하지 마세요:
- **페이즈에 미결된 설계 결정이 있는 경우.** `/gsd-discuss-phase`를 실행하지 않았고 `PROJECT.md`에 선호 사항이 캡처되지 않은 경우, 스마트 논의가 동의하지 않을 수 있는 자율 선택을 합니다. 먼저 대화형으로 논의하거나 `--interactive`를 사용하세요.
- **페이즈에 미결된 설계 결정이 있는 경우.** `/msd-discuss-phase`를 실행하지 않았고 `PROJECT.md`에 선호 사항이 캡처되지 않은 경우, 스마트 논의가 동의하지 않을 수 있는 자율 선택을 합니다. 먼저 대화형으로 논의하거나 `--interactive`를 사용하세요.
- **단일 페이즈를 세밀하게 제어해야 하는 경우.** 하나의 페이즈는 `/gsd-execute-phase N`이 단계별 출력을 제공하고 계속하기 전에 반응할 수 있게 해줍니다. 자율 모드는 대규모 무인 실행을 위해 설계되었습니다.
- **단일 페이즈를 세밀하게 제어해야 하는 경우.** 하나의 페이즈는 `/msd-execute-phase N`이 단계별 출력을 제공하고 계속하기 전에 반응할 수 있게 해줍니다. 자율 모드는 대규모 무인 실행을 위해 설계되었습니다.
- **페이즈에 새롭거나 위험도 높은 작업이 있는 경우.** 자율 모드는 차단기가 없는 한 일시 중지를 건너뜁니다. 예상치 못한 상황이 예상되는 페이즈에서는 수동 실행으로 루프에 머무세요.
- **부분 실행 중인 페이즈가 있는 경우.** 자율 모드는 미완료 페이즈를 처리하지만 부분적으로 실행된 웨이브는 재개하지 않습니다. 이미 진행 중인 페이즈를 완료하려면 `/gsd-execute-phase N`을 사용하세요.
- **부분 실행 중인 페이즈가 있는 경우.** 자율 모드는 미완료 페이즈를 처리하지만 부분적으로 실행된 웨이브는 재개하지 않습니다. 이미 진행 중인 페이즈를 완료하려면 `/msd-execute-phase N`을 사용하세요.
실행이 도중에 중단된 경우 [실패한 실행 디버그](debug-a-failed-execution.md)를 참고하여 문제를 진단하세요.
@@ -93,13 +93,13 @@ Resume with: /gsd-autonomous --from 6
자율 모드는 각 페이즈 전에 진행 상황 배너를 출력합니다:
```text
GSD ► AUTONOMOUS ▸ Phase 3/7: Auth Middleware [████░░░░] 28%
MSD ► AUTONOMOUS ▸ Phase 3/7: Auth Middleware [████░░░░] 28%
```
세션 도중 실행 상태를 확인해야 한다면 다른 터미널을 열고 실행하세요:
```bash
/gsd-progress
/msd-progress
```
---
@@ -109,10 +109,10 @@ Resume with: /gsd-autonomous --from 6
자율 모드가 중단된 경우(차단기 프롬프트에서 "자율 모드 중단"을 선택했거나 세션이 중단된 경우), 중단된 곳에서 재개하세요:
```bash
/gsd-autonomous --from 4 # 4를 첫 번째 미완료 페이즈 번호로 교체
/msd-autonomous --from 4 # 4를 첫 번째 미완료 페이즈 번호로 교체
```
GSD는 이미 완료된 페이즈를 자동으로 건너뛰므로 실행이 어디서 중단되었는지 확실하지 않은 경우 이전 페이즈 번호에서 재실행해도 안전합니다.
MSD는 이미 완료된 페이즈를 자동으로 건너뛰므로 실행이 어디서 중단되었는지 확실하지 않은 경우 이전 페이즈 번호에서 재실행해도 안전합니다.
---

44
docs/ko-KR/how-to/set-up-cross-ai-review.md
View File

@@ -8,7 +8,7 @@
## 어떤 리뷰어를 사용할지 결정
GSD Core는 Claude(별도 세션), Codex CLI, CodeRabbit, OpenCode, Qwen Code, Cursor, Antigravity CLI, Ollama, LM Studio, llama.cpp의 조합으로 리뷰 요청을 라우팅할 수 있습니다.
MSD Core는 Claude(별도 세션), Codex CLI, CodeRabbit, OpenCode, Qwen Code, Cursor, Antigravity CLI, Ollama, LM Studio, llama.cpp의 조합으로 리뷰 요청을 라우팅할 수 있습니다.
각 리뷰어는 `PLAN.md` 파일에 대해 동일한 구조화된 프롬프트를 독립적으로 실행합니다. 서로 다른 모델은 서로 다른 맹점을 가지고 있으므로 멀티 리뷰어 합의가 단일 리뷰어보다 더 많은 문제를 발견합니다.
@@ -26,18 +26,18 @@ npm install -g @openai/codex
## 기본 리뷰어 설정 (선택 사항)
기본적으로 `/gsd-review`는 감지된 모든 CLI를 실행합니다. 프로젝트 기본값으로 하위 집합을 고정하려면:
기본적으로 `/msd-review`는 감지된 모든 CLI를 실행합니다. 프로젝트 기본값으로 하위 집합을 고정하려면:
```bash
/gsd-config --integrations
/msd-config --integrations
```
통합 마법사는 API 키, 코드 리뷰 CLI 라우팅, `review.default_reviewers` 목록을 다룹니다. 목록을 플래그 없는 기본값으로 사용하려는 리뷰어로 설정하세요. 예: `["codex","claude"]`.
또는 `gsd-tools`로 직접 설정하세요:
또는 `msd-tools`로 직접 설정하세요:
```bash
gsd config-set review.default_reviewers '["codex","claude"]'
msd config-set review.default_reviewers '["codex","claude"]'
```
전체 통합 설정 스키마(API 키, 리뷰어별 모델 재정의, 로컬 서버 호스트 주소)에 대해서는 [설정](../CONFIGURATION.md)을 참고하세요.
@@ -49,17 +49,17 @@ gsd config-set review.default_reviewers '["codex","claude"]'
### 표준 리뷰 (설정된 기본값 또는 감지된 모든 CLI 사용)
```bash
/gsd-review --phase 3
/msd-review --phase 3
```
GSD는 각 리뷰어를 순서대로 호출하고 구조화된 피드백(요약, 강점, HIGH/MEDIUM/LOW 우려 사항, 제안, 위험 평가)을 수집하여 `.planning/phases/03-.../03-REVIEWS.md`에 결합된 출력을 작성합니다.
MSD는 각 리뷰어를 순서대로 호출하고 구조화된 피드백(요약, 강점, HIGH/MEDIUM/LOW 우려 사항, 제안, 위험 평가)을 수집하여 `.planning/phases/03-.../03-REVIEWS.md`에 결합된 출력을 작성합니다.
### 일회성 실행을 위한 단일 리뷰어 선택
```bash
/gsd-review --phase 3 --agy
/gsd-review --phase 3 --codex
/gsd-review --phase 3 --cursor
/msd-review --phase 3 --agy
/msd-review --phase 3 --codex
/msd-review --phase 3 --cursor
```
명시적 플래그는 해당 실행에 대해 `--all` 기본값과 `review.default_reviewers` 모두를 재정의합니다.
@@ -67,7 +67,7 @@ GSD는 각 리뷰어를 순서대로 호출하고 구조화된 피드백(요약,
### 모든 사용 가능한 리뷰어를 병렬로 실행
```bash
/gsd-review --phase 3 --all
/msd-review --phase 3 --all
```
`--all`은 항상 설정을 재정의하고 Ollama, LM Studio, llama.cpp를 포함하여 설정된 모든 로컬 모델 서버를 포함한 전체 감지 집합을 실행합니다.
@@ -77,11 +77,11 @@ GSD는 각 리뷰어를 순서대로 호출하고 구조화된 피드백(요약,
Ollama 또는 LM Studio를 로컬에서 실행하는 경우 서버에 접근할 수 있을 때 `--all`에 자동으로 포함됩니다. 명시적으로 지정할 수도 있습니다:
```bash
/gsd-review --phase 3 --ollama
/gsd-review --phase 3 --lm-studio
/msd-review --phase 3 --ollama
/msd-review --phase 3 --lm-studio
```
기본값(`localhost:11434` / `localhost:1234`)이 적용되지 않는 경우 `/gsd-config --integrations`를 통해 `review.*` 키 아래의 호스트 주소와 모델 선택을 설정하세요.
기본값(`localhost:11434` / `localhost:1234`)이 적용되지 않는 경우 `/msd-config --integrations`를 통해 `review.*` 키 아래의 호스트 주소와 모델 선택을 설정하세요.
---
@@ -100,7 +100,7 @@ Ollama 또는 LM Studio를 로컬에서 실행하는 경우 서버에 접근할
출력을 검토한 후 피드백을 반영하여 재기획하세요:
```bash
/gsd-plan-phase 3 --reviews
/msd-plan-phase 3 --reviews
```
플래너는 `REVIEWS.md`를 읽고 우려 사항을 해소하도록 저장 전에 계획을 조정합니다.
@@ -112,7 +112,7 @@ Ollama 또는 LM Studio를 로컬에서 실행하는 경우 서버에 접근할
모든 HIGH 심각도 우려 사항이 해결될 때까지 반복하려는 페이즈에는 수렴 루프를 사용하세요:
```bash
/gsd-plan-review-convergence 3
/msd-plan-review-convergence 3
```
`plan-phase → review → replan → re-review` 사이클을 기본 최대 3회 실행합니다. HIGH 우려 사항 수가 0에 도달하면 루프를 종료합니다.
@@ -120,17 +120,17 @@ Ollama 또는 LM Studio를 로컬에서 실행하는 경우 서버에 접근할
### 특정 리뷰어로 수렴
```bash
/gsd-plan-review-convergence 3 --codex
/gsd-plan-review-convergence 3 --agy
/msd-plan-review-convergence 3 --codex
/msd-plan-review-convergence 3 --agy
```
### 모든 리뷰어로 더 높은 사이클 상한으로 수렴
```bash
/gsd-plan-review-convergence 3 --all --max-cycles 5
/msd-plan-review-convergence 3 --all --max-cycles 5
```
**정체 감지:** HIGH 우려 사항 수가 사이클 전반에 걸쳐 감소하지 않으면 GSD가 경고합니다. 사이클 상한에 도달했지만 HIGH 우려 사항이 남아 있는 경우, 진행하거나 수동으로 검토할지를 묻는 에스컬레이션 게이트가 표시됩니다.
**정체 감지:** HIGH 우려 사항 수가 사이클 전반에 걸쳐 감소하지 않으면 MSD가 경고합니다. 사이클 상한에 도달했지만 HIGH 우려 사항이 남아 있는 경우, 진행하거나 수동으로 검토할지를 묻는 에스컬레이션 게이트가 표시됩니다.
---
@@ -143,8 +143,8 @@ Ollama 또는 LM Studio를 로컬에서 실행하는 경우 서버에 접근할
| OpenAI 중심 프로젝트인 경우 | OpenAI 모델 관점을 위해 `--codex` 추가 |
| GitHub Copilot 모델을 원하는 경우 | `--opencode` 추가 |
| API 비용을 완전히 피하려는 경우 | 로컬 모델로 Ollama를 설정하고 `--ollama` 사용 |
| 릴리스 전 최대 커버리지가 필요한 경우 | `/gsd-plan-review-convergence N --all` |
| 빠르게 반복하며 빠른 피드백을 원하는 경우 | CLI 하나 선택: `/gsd-review --phase N --agy` |
| 릴리스 전 최대 커버리지가 필요한 경우 | `/msd-plan-review-convergence N --all` |
| 빠르게 반복하며 빠른 피드백을 원하는 경우 | CLI 하나 선택: `/msd-review --phase N --agy` |
---

52
docs/ko-KR/how-to/spike-and-sketch.md
View File

@@ -2,7 +2,7 @@
**목표:** 특정 접근 방식을 페이즈에 확정하기 전에 집중된 실현 가능성 실험(스파이크)과 일회용 HTML 목업을 통한 시각적 방향 탐색(스케치)으로 구현 위험을 줄입니다.
**사전 조건:** 없음. `/gsd-spike`와 `/gsd-sketch`는 자체 저장 디렉터리를 생성하며 초기화된 GSD 프로젝트가 필요하지 않습니다.
**사전 조건:** 없음. `/msd-spike`와 `/msd-sketch`는 자체 저장 디렉터리를 생성하며 초기화된 MSD 프로젝트가 필요하지 않습니다.
---
@@ -10,8 +10,8 @@
| 답하고 싶은 질문… | 사용할 도구 |
|---|---|
| "이 기술적 접근 방식이 실제로 작동할까?" | `/gsd-spike` |
| "이 레이아웃 / 인터랙션 / 시각적 처리가 맞는 느낌인가?" | `/gsd-sketch` |
| "이 기술적 접근 방식이 실제로 작동할까?" | `/msd-spike` |
| "이 레이아웃 / 인터랙션 / 시각적 처리가 맞는 느낌인가?" | `/msd-sketch` |
| "올바른 기술적 접근 방식은 무엇이고, 어떻게 보여야 할까?" | 둘 다, 순서대로: 먼저 스파이크, 그다음 스케치 |
스파이크는 실행 가능한 코드와 VALIDATED / INVALIDATED / PARTIAL 판정으로 이진 실현 가능성 질문에 답합니다. 스케치는 2~3개의 브라우저에서 비교 가능한 HTML 변형으로 시각적 질문에 답합니다. 두 가지는 상호 보완적입니다 — 스파이크는 접근 방식이 구현 가능함을 증명하고, 스케치는 디자인이 구현할 가치가 있음을 증명합니다.
@@ -23,21 +23,21 @@
### 대화식 입력(기본값)
```bash
/gsd-spike
/msd-spike
```
GSD는 기술적 질문에 대해 물어보고, 이를 **Given / When / Then** 가설로 구성된 2~5개의 독립적인 실험으로 분해하며, 빌드 전에 확인을 요청합니다.
MSD는 기술적 질문에 대해 물어보고, 이를 **Given / When / Then** 가설로 구성된 2~5개의 독립적인 실험으로 분해하며, 빌드 전에 확인을 요청합니다.
### 아이디어를 직접 제공
```bash
/gsd-spike "can we stream LLM tokens through SSE"
/msd-spike "can we stream LLM tokens through SSE"
```
### 입력 건너뛰고 즉시 실행
```bash
/gsd-spike --quick "websocket vs SSE latency"
/msd-spike --quick "websocket vs SSE latency"
```
`--quick`은 분해 대화를 건너뛰고 인자를 단일 스파이크 질문으로 처리합니다. 질문이 이미 충분히 구체적이어서 세분화 없이 실행할 수 있을 때 사용합니다.
@@ -59,10 +59,10 @@ GSD는 기술적 질문에 대해 물어보고, 이를 **Given / When / Then**
신호가 확보되면 결과를 프로젝트 로컬 스킬로 패키징하여 향후 세션에서 자동으로 로드되도록 합니다:
```bash
/gsd-spike --wrap-up
/msd-spike --wrap-up
```
이 명령은 `.claude/skills/spike-findings-[project]/`를 작성합니다. 스킬은 자동으로 발견되어 이후의 `/gsd-sketch`, `/gsd-ui-phase`, `/gsd-plan-phase` 실행에서 로드됩니다 — 명시적으로 참조할 필요가 없습니다.
이 명령은 `.claude/skills/spike-findings-[project]/`를 작성합니다. 스킬은 자동으로 발견되어 이후의 `/msd-sketch`, `/msd-ui-phase`, `/msd-plan-phase` 실행에서 로드됩니다 — 명시적으로 참조할 필요가 없습니다.
---
@@ -71,21 +71,21 @@ GSD는 기술적 질문에 대해 물어보고, 이를 **Given / When / Then**
### 분위기 입력(기본값)
```bash
/gsd-sketch
/msd-sketch
```
GSD는 코드 작성 전에 느낌, 시각적 참조, 핵심 사용자 작업을 탐색하는 짧은 대화를 시작합니다. 한 번에 하나의 질문을 하며 진행 승인을 받을 때만 빌드를 시작합니다.
MSD는 코드 작성 전에 느낌, 시각적 참조, 핵심 사용자 작업을 탐색하는 짧은 대화를 시작합니다. 한 번에 하나의 질문을 하며 진행 승인을 받을 때만 빌드를 시작합니다.
### 디자인 방향을 직접 제공
```bash
/gsd-sketch "dashboard layout"
/msd-sketch "dashboard layout"
```
### 분위기 입력 건너뛰고 즉시 실행
```bash
/gsd-sketch --quick "sidebar navigation"
/msd-sketch --quick "sidebar navigation"
```
`--quick`은 입력 대화를 완전히 건너뛰고 인자를 디자인 방향으로 사용합니다.
@@ -93,7 +93,7 @@ GSD는 코드 작성 전에 느낌, 시각적 참조, 핵심 사용자 작업을
### 비 Claude 런타임(Codex, Antigravity CLI 등)
```bash
/gsd-sketch --text "onboarding flow"
/msd-sketch --text "onboarding flow"
```
`--text`는 대화식 프롬프트를 일반 텍스트 번호 목록으로 대체합니다. 런타임이 `AskUserQuestion`을 지원하지 않을 때 사용합니다.
@@ -115,10 +115,10 @@ GSD는 코드 작성 전에 느낌, 시각적 참조, 핵심 사용자 작업을
변형을 선택한 후 시각적 결정을 프로젝트 로컬 스킬로 캡처합니다:
```bash
/gsd-sketch --wrap-up
/msd-sketch --wrap-up
```
이 명령은 `.claude/skills/sketch-findings-[project]/`를 작성합니다. 스킬은 `/gsd-ui-phase`에 의해 자동으로 가져옵니다 — 사전 검증된 결정(레이아웃, 색상 팔레트, 타이포그래피, 간격)은 확정된 것으로 처리되어 다시 묻지 않습니다.
이 명령은 `.claude/skills/sketch-findings-[project]/`를 작성합니다. 스킬은 `/msd-ui-phase`에 의해 자동으로 가져옵니다 — 사전 검증된 결정(레이아웃, 색상 팔레트, 타이포그래피, 간격)은 확정된 것으로 처리되어 다시 묻지 않습니다.
---
@@ -127,26 +127,26 @@ GSD는 코드 작성 전에 느낌, 시각적 참조, 핵심 사용자 작업을
기술적 실현 가능성과 시각적 방향 모두 불확실할 때 권장하는 순서:
```bash
/gsd-spike "SSE vs WebSocket for real-time feed"
/gsd-spike --wrap-up
/msd-spike "SSE vs WebSocket for real-time feed"
/msd-spike --wrap-up
/gsd-sketch "real-time feed UI"
/gsd-sketch --wrap-up
/msd-sketch "real-time feed UI"
/msd-sketch --wrap-up
/gsd-discuss-phase N
/gsd-plan-phase N
/msd-discuss-phase N
/msd-plan-phase N
```
스파이크 결과가 스케치에 정보를 제공합니다(실제 데이터 형태, 실제 인터랙션 상태, 현실적인 제약). 두 wrap-up 모두 플래너와 UI 연구자가 자동으로 로드하는 결정을 유지하므로 `/gsd-discuss-phase`나 `/gsd-ui-phase` 중에 선택 사항을 다시 설명할 필요가 없습니다.
스파이크 결과가 스케치에 정보를 제공합니다(실제 데이터 형태, 실제 인터랙션 상태, 현실적인 제약). 두 wrap-up 모두 플래너와 UI 연구자가 자동으로 로드하는 결정을 유지하므로 `/msd-discuss-phase`나 `/msd-ui-phase` 중에 선택 사항을 다시 설명할 필요가 없습니다.
---
## 스파이크 또는 스케치가 페이즈에 반영되는 방식
스파이크와 스케치 아티팩트는 수동으로 참조할 필요가 없습니다. GSD는 두 시점에서 자동으로 읽습니다:
스파이크와 스케치 아티팩트는 수동으로 참조할 필요가 없습니다. MSD는 두 시점에서 자동으로 읽습니다:
1. **`/gsd-sketch`** — 목업 빌드 전에 `.claude/skills/spike-findings-*/`를 로드하여 변형이 증명된 제약(스트리밍 상태, 실제 필드 이름 등)을 반영하도록 함
2. **`/gsd-ui-phase N`** — UI 디자인 계약을 생성하기 전에 `.claude/skills/sketch-findings-*/`를 로드. 사전 검증된 디자인 결정은 확정된 것으로 처리됨
1. **`/msd-sketch`** — 목업 빌드 전에 `.claude/skills/spike-findings-*/`를 로드하여 변형이 증명된 제약(스트리밍 상태, 실제 필드 이름 등)을 반영하도록 함
2. **`/msd-ui-phase N`** — UI 디자인 계약을 생성하기 전에 `.claude/skills/sketch-findings-*/`를 로드. 사전 검증된 디자인 결정은 확정된 것으로 처리됨
플래너도 `spike-findings-*` 스킬이 있을 때 스파이크 결과를 읽으므로 검증된 기술 선택(어떤 라이브러리, 어떤 프로토콜, 어떤 데이터 형식)이 반복적인 설명 없이 작업 플랜으로 직접 반영됩니다.

54
docs/ko-KR/how-to/update-gsd.md → docs/ko-KR/how-to/update-msd.md
View File

@@ -1,8 +1,8 @@
# GSD Core 업데이트 방법
# MSD Core 업데이트 방법
기존 GSD Core 설치를 최신 릴리즈로 업데이트하고, 확정 전에 변경 로그를 미리보고, 업데이트가 덮어쓸 로컬 커스터마이징을 복구합니다.
기존 MSD Core 설치를 최신 릴리즈로 업데이트하고, 확정 전에 변경 로그를 미리보고, 업데이트가 덮어쓸 로컬 커스터마이징을 복구합니다.
**필요한 것:** GSD가 설치된 것과 동일한 런타임. 업데이트 명령은 내부적으로 인스톨러를 다시 실행하므로 Node.js와 npx가 필요합니다(원래 설치와 동일한 요구 사항).
**필요한 것:** MSD가 설치된 것과 동일한 런타임. 업데이트 명령은 내부적으로 인스톨러를 다시 실행하므로 Node.js와 npx가 필요합니다(원래 설치와 동일한 요구 사항).
---
@@ -11,19 +11,19 @@
AI 런타임 내에서 실행합니다:
```bash
/gsd-update
/msd-update
```
GSD가 수행하는 작업:
MSD가 수행하는 작업:
1. 설치된 버전과 설치 범위(전역 또는 로컬)를 감지합니다.
2. npm에서 `@opengsd/gsd-core`의 최신 릴리즈를 확인합니다.
2. npm에서 `@golem15/msd-core`의 최신 릴리즈를 확인합니다.
3. 변경 로그를 가져와 설치된 버전과 최신 버전 사이의 변경 사항을 표시합니다.
4. 아무것도 건드리기 전에 확인을 요청합니다.
5. GSD 관리 디렉터리 내에서 발견된 사용자 추가 파일을 `gsd-user-files-backup/`에 백업합니다.
6. 인스톨러를 실행합니다(`npx @opengsd/gsd-core@latest --<runtime> --<scope>`).
5. MSD 관리 디렉터리 내에서 발견된 사용자 추가 파일을 `msd-user-files-backup/`에 백업합니다.
6. 인스톨러를 실행합니다(`npx @golem15/msd-core@latest --<runtime> --<scope>`).
7. 업데이트 확인 캐시를 초기화하여 상태 표시줄 인디케이터가 재설정됩니다.
8. 로컬에서 수정된 GSD 파일이 `gsd-local-patches/`에 백업되었는지 보고합니다.
8. 로컬에서 수정된 MSD 파일이 `msd-local-patches/`에 백업되었는지 보고합니다.
새로운 명령과 에이전트를 적용하려면 업데이트 후 런타임을 재시작하세요.
@@ -33,22 +33,22 @@ GSD가 수행하는 작업:
| 플래그 | 수행하는 작업 |
|------|--------------|
| `--sync` | 업데이트 후 GSD 레지스트리에서 스킬 동기화 |
| `--reapply` | 업데이트 후 `gsd-local-patches/`에서 로컬에서 수정된 GSD 파일 다시 병합 |
| `--sync` | 업데이트 후 MSD 레지스트리에서 스킬 동기화 |
| `--reapply` | 업데이트 후 `msd-local-patches/`에서 로컬에서 수정된 MSD 파일 다시 병합 |
```bash
/gsd-update --sync # 업데이트 및 스킬 동기화
/gsd-update --reapply # 업데이트 및 로컬 패치 재적용
/msd-update --sync # 업데이트 및 스킬 동기화
/msd-update --reapply # 업데이트 및 로컬 패치 재적용
```
---
## 업데이트 전 변경 로그 검토
`/gsd-update`는 확인을 요청하기 *전에* 항상 설치된 버전과 최신 버전 사이의 변경 로그 diff를 표시합니다. GitHub를 별도로 방문할 필요가 없습니다. 출력은 다음과 같습니다:
`/msd-update`는 확인을 요청하기 *전에* 항상 설치된 버전과 최신 버전 사이의 변경 로그 diff를 표시합니다. GitHub를 별도로 방문할 필요가 없습니다. 출력은 다음과 같습니다:
```text
## GSD Update Available
## MSD Update Available
Installed: 1.39.0
Latest: 1.41.0
@@ -70,47 +70,47 @@ Proceed with update? [Yes, update now / No, cancel]
## 로컬 커스터마이징 복구
### GSD 관리 디렉터리에 추가한 파일
### MSD 관리 디렉터리에 추가한 파일
GSD가 소유하는 디렉터리 내에 커스텀 파일을 배치한 경우(예: `gsd-` 접두사가 붙은 커스텀 에이전트 또는 `commands/gsd/`에 있는 추가 파일), 인스톨러가 이를 감지하고 해당 디렉터리를 지우기 전에 `gsd-user-files-backup/`에 복사합니다. 업데이트 후 해당 백업 위치에서 수동으로 복원합니다.
MSD가 소유하는 디렉터리 내에 커스텀 파일을 배치한 경우(예: `msd-` 접두사가 붙은 커스텀 에이전트 또는 `commands/msd/`에 있는 추가 파일), 인스톨러가 이를 감지하고 해당 디렉터리를 지우기 전에 `msd-user-files-backup/`에 복사합니다. 업데이트 후 해당 백업 위치에서 수동으로 복원합니다.
GSD 관리 디렉터리 외부에 배치한 파일 — `gsd-` 접두사 없는 커스텀 에이전트, `commands/gsd/` 외부의 커스텀 명령, `CLAUDE.md` 파일, 커스텀 훅 — 은 인스톨러가 절대 건드리지 않습니다.
MSD 관리 디렉터리 외부에 배치한 파일 — `msd-` 접두사 없는 커스텀 에이전트, `commands/msd/` 외부의 커스텀 명령, `CLAUDE.md` 파일, 커스텀 훅 — 은 인스톨러가 절대 건드리지 않습니다.
### 직접 수정한 GSD 파일
### 직접 수정한 MSD 파일
GSD가 설치한 파일을 편집한 경우(예: 에이전트의 시스템 프롬프트 수정), 인스톨러는 매니페스트에 대한 해시 비교를 통해 수정을 감지하고 파일을 `gsd-local-patches/`에 백업한 후 새 버전으로 교체합니다. 업데이트 후:
MSD가 설치한 파일을 편집한 경우(예: 에이전트의 시스템 프롬프트 수정), 인스톨러는 매니페스트에 대한 해시 비교를 통해 수정을 감지하고 파일을 `msd-local-patches/`에 백업한 후 새 버전으로 교체합니다. 업데이트 후:
```bash
/gsd-update --reapply
/msd-update --reapply
```
이 명령은 새로 설치된 파일에 `gsd-local-patches/`의 수정 사항을 병합합니다.
이 명령은 새로 설치된 파일에 `msd-local-patches/`의 수정 사항을 병합합니다.
이전 업데이트 후 `--reapply`를 건너뛰었고 지금 패치를 적용하고 싶다면:
```bash
/gsd-update --reapply
/msd-update --reapply
```
이미 최신 버전이면 GSD는 설치 단계를 건너뛰고 바로 패치 재적용으로 진행합니다 — 새 다운로드를 트리거하지 않고도 `--reapply`를 단독으로 실행하는 것이 안전합니다.
이미 최신 버전이면 MSD는 설치 단계를 건너뛰고 바로 패치 재적용으로 진행합니다 — 새 다운로드를 트리거하지 않고도 `--reapply`를 단독으로 실행하는 것이 안전합니다.
---
## npm을 사용할 수 없을 때
npm 중단, 네트워크 제한, 또는 소스 저장소에서 작업 중이어서 `npx @opengsd/gsd-core@latest`가 실패하는 경우 [docs/manual-update.md](../../manual-update.md)의 수동 업데이트 절차를 사용하세요. 해당 문서는 최신 커밋 풀링, hooks dist 빌드, `node bin/install.js` 직접 실행을 다룹니다.
npm 중단, 네트워크 제한, 또는 소스 저장소에서 작업 중이어서 `npx @golem15/msd-core@latest`가 실패하는 경우 [docs/manual-update.md](../../manual-update.md)의 수동 업데이트 절차를 사용하세요. 해당 문서는 최신 커밋 풀링, hooks dist 빌드, `node bin/install.js` 직접 실행을 다룹니다.
---
## 이미 최신 버전인 경우
`/gsd-update`는 확인 메시지와 함께 조기 종료합니다 — 다운로드 없음, 설치 없음, 재시작 불필요.
`/msd-update`는 확인 메시지와 함께 조기 종료합니다 — 다운로드 없음, 설치 없음, 재시작 불필요.
---
## 인스톨러 마이그레이션
각 GSD 릴리즈에는 관리 파일을 이름 변경, 이동, 또는 폐기하는 인스톨러 마이그레이션이 포함될 수 있습니다. 마이그레이션 레이어는 새 패키지 페이로드가 작성되기 전에 자동으로 실행됩니다. 수정한 파일에 영향을 주는 마이그레이션은 자동으로 처리되지 않고 확인을 요청합니다. 전체 설계와 런타임 구성 계약 레지스트리는 [docs/installer-migrations.md](../../installer-migrations.md)를 참조하세요.
각 MSD 릴리즈에는 관리 파일을 이름 변경, 이동, 또는 폐기하는 인스톨러 마이그레이션이 포함될 수 있습니다. 마이그레이션 레이어는 새 패키지 페이로드가 작성되기 전에 자동으로 실행됩니다. 수정한 파일에 영향을 주는 마이그레이션은 자동으로 처리되지 않고 확인을 요청합니다. 전체 설계와 런타임 구성 계약 레지스트리는 [docs/installer-migrations.md](../../installer-migrations.md)를 참조하세요.
---

46
docs/ko-KR/how-to/verify-and-ship.md
View File

@@ -9,36 +9,36 @@
## 사용자 인수 테스트 실행
```bash
/gsd-verify-work 1
/msd-verify-work 1
```
GSD는 페이즈의 `SUMMARY.md` 파일을 읽고, 사용자가 관찰 가능한 결과물을 추출하여 하나씩 안내합니다. 각 체크포인트에서 *예상되는 것*을 제시하고 실제와 일치하는지 묻습니다.
MSD는 페이즈의 `SUMMARY.md` 파일을 읽고, 사용자가 관찰 가능한 결과물을 추출하여 하나씩 안내합니다. 각 체크포인트에서 *예상되는 것*을 제시하고 실제와 일치하는지 묻습니다.
- `yes` / `y` / 빈 값 → 통과, 다음 테스트로 이동
- 그 외 → 문제로 기록됨, 설명에서 심각도 추론
심각도를 직접 분류할 필요가 없습니다. GSD가 표현에서 추론합니다("충돌" → 차단, "작동 안 함" → 주요, "이상해 보임" → 외관상).
심각도를 직접 분류할 필요가 없습니다. MSD가 표현에서 추론합니다("충돌" → 차단, "작동 안 함" → 주요, "이상해 보임" → 외관상).
진행 상황은 `.planning/phases/01-<name>/01-UAT.md`에 기록되며 `/clear`에서도 유지됩니다. 세션이 중단된 경우 `/gsd-verify-work 1`을 다시 실행하면 GSD가 마지막 체크포인트에서 재개할 것을 제안합니다.
진행 상황은 `.planning/phases/01-<name>/01-UAT.md`에 기록되며 `/clear`에서도 유지됩니다. 세션이 중단된 경우 `/msd-verify-work 1`을 다시 실행하면 MSD가 마지막 체크포인트에서 재개할 것을 제안합니다.
---
## 실패 발견 시: 자동 진단 및 수정 기획
테스트에서 문제가 발견되면 GSD는 자동으로 진행합니다:
테스트에서 문제가 발견되면 MSD는 자동으로 진행합니다:
1. **근본 원인 진단** — 문제당 하나씩 병렬 디버그 에이전트를 실행하고 근본 원인으로 `UAT.md`를 업데이트합니다.
2. **갭 해소 기획** — 갭 해소 모드에서 `gsd-planner`를 실행하며, 진단이 포함된 `UAT.md`를 읽고 새 `PLAN.md` 파일을 작성합니다.
3. **수정 계획 검증** — `gsd-plan-checker`를 실행하여 계획이 실행 가능한지 확인합니다. 문제가 발견되면 플래너와 체커가 최대 3회 반복합니다.
2. **갭 해소 기획** — 갭 해소 모드에서 `msd-planner`를 실행하며, 진단이 포함된 `UAT.md`를 읽고 새 `PLAN.md` 파일을 작성합니다.
3. **수정 계획 검증** — `msd-plan-checker`를 실행하여 계획이 실행 가능한지 확인합니다. 문제가 발견되면 플래너와 체커가 최대 3회 반복합니다.
4. **다음 단계 제시** — 계획이 체커를 통과하면:
```
Plans verified and ready for execution.
`/clear` then `/gsd-execute-phase 1 --gaps-only`
`/clear` then `/msd-execute-phase 1 --gaps-only`
```
제안된 명령을 실행하여 수정을 적용한 후, `/gsd-verify-work 1`을 다시 실행하여 모든 것이 통과하는지 확인하세요.
제안된 명령을 실행하여 수정을 적용한 후, `/msd-verify-work 1`을 다시 실행하여 모든 것이 통과하는지 확인하세요.
---
@@ -47,14 +47,14 @@ Plans verified and ready for execution.
모든 UAT 테스트가 통과하면(또는 첫 번째 실행에서 문제가 발견되지 않으면) 페이즈는 `ROADMAP.md`와 `STATE.md`에서 자동으로 완료로 표시됩니다.
```bash
/gsd-ship 1
/msd-ship 1
```
GSD는 사전 점검(검증 상태, 깨끗한 작업 트리, 브랜치, 원격 저장소, `gh` CLI 인증)을 실행하고 브랜치를 푸시한 후 PR을 생성합니다:
MSD는 사전 점검(검증 상태, 깨끗한 작업 트리, 브랜치, 원격 저장소, `gh` CLI 인증)을 실행하고 브랜치를 푸시한 후 PR을 생성합니다:
```bash
/gsd-ship 1 # 검토 준비된 PR
/gsd-ship 1 --draft # 초안 PR — 더 많은 페이즈가 뒤따를 때 유용
/msd-ship 1 # 검토 준비된 PR
/msd-ship 1 --draft # 초안 PR — 더 많은 페이즈가 뒤따를 때 유용
```
PR 본문은 기획 산출물에서 자동으로 조합됩니다:
@@ -71,19 +71,19 @@ PR 본문은 기획 산출물에서 자동으로 조합됩니다:
## 선택 사항: 배포 전후 코드 리뷰
`/gsd-ship`은 자동으로 코드 리뷰를 실행하지 않지만, 언제든지 추가할 수 있습니다:
`/msd-ship`은 자동으로 코드 리뷰를 실행하지 않지만, 언제든지 추가할 수 있습니다:
**검증 전** (UAT 전에 문제 발견):
```bash
/gsd-code-review 1 # 표준 리뷰
/gsd-code-review 1 --fix # 리뷰 후 Critical + Warning 발견 사항 자동 수정
/msd-code-review 1 # 표준 리뷰
/msd-code-review 1 --fix # 리뷰 후 Critical + Warning 발견 사항 자동 수정
```
**PR 오픈 후** (병합 전 품질 게이팅):
```bash
/gsd-code-review 1 --depth=deep # 임포트 그래프를 포함한 파일 간 분석
/msd-code-review 1 --depth=deep # 임포트 그래프를 포함한 파일 간 분석
```
주기 초반의 계획 리뷰를 위해 Antigravity, Codex 또는 다른 리뷰어를 설정하려면 [크로스 AI 리뷰 설정](set-up-cross-ai-review.md)을 참고하세요.
@@ -95,11 +95,11 @@ PR 본문은 기획 산출물에서 자동으로 조합됩니다:
브랜치에 리뷰어에게 보여주고 싶지 않은 `.planning/` 커밋이 포함된 경우:
```bash
/gsd-pr-branch # main에 대해 필터링
/gsd-pr-branch develop # develop에 대해 필터링
/msd-pr-branch # main에 대해 필터링
/msd-pr-branch develop # develop에 대해 필터링
```
`/gsd-pr-branch`는 코드 변경 사항만 포함된 새 브랜치를 생성합니다. 기획 산출물 커밋은 제외됩니다. 팀의 리뷰 정책에서 기획 노이즈를 제외하는 경우 `/gsd-ship` 전에 실행하세요.
`/msd-pr-branch`는 코드 변경 사항만 포함된 새 브랜치를 생성합니다. 기획 산출물 커밋은 제외됩니다. 팀의 리뷰 정책에서 기획 노이즈를 제외하는 경우 `/msd-ship` 전에 실행하세요.
---
@@ -108,11 +108,11 @@ PR 본문은 기획 산출물에서 자동으로 조합됩니다:
이것이 마일스톤의 마지막 페이즈였다면 마일스톤 감사를 실행하고 보관하세요:
```bash
/gsd-audit-milestone # 모든 요구 사항이 배포되었는지 확인
/gsd-complete-milestone # 보관, git 태그 생성
/msd-audit-milestone # 모든 요구 사항이 배포되었는지 확인
/msd-complete-milestone # 보관, git 태그 생성
```
`/gsd-complete-milestone`은 PR이 병합된 후의 자연스러운 다음 단계입니다. 검증과 배포가 전체 프로젝트 생애주기에 어떻게 적합한지는 [페이즈 루프](../explanation/the-phase-loop.md)를 참고하세요.
`/msd-complete-milestone`은 PR이 병합된 후의 자연스러운 다음 단계입니다. 검증과 배포가 전체 프로젝트 생애주기에 어떻게 적합한지는 [페이즈 루프](../explanation/the-phase-loop.md)를 참고하세요.
---

46
docs/ko-KR/how-to/work-in-parallel-with-workstreams.md
View File

@@ -2,7 +2,7 @@
**목표:** 백엔드 API, 프론트엔드 대시보드, 인프라 등 서로 다른 마일스톤 영역에서 한 영역의 계획 상태가 다른 영역으로 유입되지 않도록 동시 작업을 수행합니다.
**사전 조건:** 활성화된 GSD Core 프로젝트(`.planning/ROADMAP.md` 존재). 없는 경우 먼저 `/gsd-new-project`를 실행하세요.
**사전 조건:** 활성화된 MSD Core 프로젝트(`.planning/ROADMAP.md` 존재). 없는 경우 먼저 `/msd-new-project`를 실행하세요.
---
@@ -28,24 +28,24 @@
└── phases/
```
워크스트림이 활성화되면 모든 GSD 명령인 `/gsd-progress`, `/gsd-discuss-phase`, `/gsd-plan-phase`, `/gsd-execute-phase`가 해당 워크스트림의 디렉터리에서 읽고 씁니다. 워크스트림을 전환하면 소스 트리를 건드리지 않고 모든 명령이 다른 서브트리로 리디렉션됩니다.
워크스트림이 활성화되면 모든 MSD 명령인 `/msd-progress`, `/msd-discuss-phase`, `/msd-plan-phase`, `/msd-execute-phase`가 해당 워크스트림의 디렉터리에서 읽고 씁니다. 워크스트림을 전환하면 소스 트리를 건드리지 않고 모든 명령이 다른 서브트리로 리디렉션됩니다.
---
## 워크스트림 생성
```bash
/gsd-workstreams create backend-api
/msd-workstreams create backend-api
```
GSD는 `.planning/workstreams/backend-api/` 아래에 워크스트림 디렉터리를 생성하고 기본 `STATE.md`와 `ROADMAP.md`를 시드합니다. 워크스트림은 자동으로 활성화되지 않으며 명시적으로 전환해야 합니다.
MSD는 `.planning/workstreams/backend-api/` 아래에 워크스트림 디렉터리를 생성하고 기본 `STATE.md`와 `ROADMAP.md`를 시드합니다. 워크스트림은 자동으로 활성화되지 않으며 명시적으로 전환해야 합니다.
---
## 워크스트림 목록 보기
```bash
/gsd-workstreams list
/msd-workstreams list
```
모든 워크스트림과 현재 세션에서 활성화된 워크스트림을 표시합니다.
@@ -55,26 +55,26 @@ GSD는 `.planning/workstreams/backend-api/` 아래에 워크스트림 디렉터
## 워크스트림으로 전환
```bash
/gsd-workstreams switch backend-api
/msd-workstreams switch backend-api
```
이 시점부터 모든 GSD 워크플로 명령은 `backend-api` 컨텍스트에서 동작합니다. 전환은 세션 범위로 적용됩니다. 같은 저장소에서 여러 Claude Code 터미널이 열려 있는 경우, 각 세션은 서로 간섭 없이 서로 다른 활성 워크스트림을 유지할 수 있습니다.
이 시점부터 모든 MSD 워크플로 명령은 `backend-api` 컨텍스트에서 동작합니다. 전환은 세션 범위로 적용됩니다. 같은 저장소에서 여러 Claude Code 터미널이 열려 있는 경우, 각 세션은 서로 간섭 없이 서로 다른 활성 워크스트림을 유지할 수 있습니다.
전환 후 일반 페이즈 워크플로를 진행합니다:
```bash
/gsd-discuss-phase 1
/gsd-plan-phase 1
/gsd-execute-phase 1
/gsd-verify-work 1
/msd-discuss-phase 1
/msd-plan-phase 1
/msd-execute-phase 1
/msd-verify-work 1
```
다른 영역에서 작업하려면 두 번째 터미널에서 워크스트림을 전환합니다:
```bash
/gsd-workstreams switch frontend-dash
/gsd-discuss-phase 1
/gsd-plan-phase 1
/msd-workstreams switch frontend-dash
/msd-discuss-phase 1
/msd-plan-phase 1
```
---
@@ -82,7 +82,7 @@ GSD는 `.planning/workstreams/backend-api/` 아래에 워크스트림 디렉터
## 모든 워크스트림의 진행 상황 확인
```bash
/gsd-workstreams progress
/msd-workstreams progress
```
워크스트림 간 전환 없이 모든 워크스트림의 페이즈 상태, 현재 위치, 미완료 작업을 포함한 교차 워크스트림 요약을 출력합니다.
@@ -90,7 +90,7 @@ GSD는 `.planning/workstreams/backend-api/` 아래에 워크스트림 디렉터
단일 워크스트림의 상세 상태 확인:
```bash
/gsd-workstreams status backend-api
/msd-workstreams status backend-api
```
---
@@ -100,10 +100,10 @@ GSD는 `.planning/workstreams/backend-api/` 아래에 워크스트림 디렉터
컨텍스트 초기화나 새 세션 이후 위치를 복원합니다:
```bash
/gsd-workstreams resume backend-api
/msd-workstreams resume backend-api
```
이 명령은 워크스트림을 활성화하고 마지막으로 알려진 위치를 복원합니다. 전환 후 `/gsd-resume-work`를 실행하는 것과 동일합니다.
이 명령은 워크스트림을 활성화하고 마지막으로 알려진 위치를 복원합니다. 전환 후 `/msd-resume-work`를 실행하는 것과 동일합니다.
---
@@ -112,10 +112,10 @@ GSD는 `.planning/workstreams/backend-api/` 아래에 워크스트림 디렉터
워크스트림의 마일스톤 작업이 완료되면:
```bash
/gsd-workstreams complete backend-api
/msd-workstreams complete backend-api
```
GSD는 워크스트림을 보관 상태로 표시하고 활성 목록에서 제거합니다. 계획 아티팩트는 감사 목적으로 `.planning/workstreams/backend-api/`에 보존됩니다.
MSD는 워크스트림을 보관 상태로 표시하고 활성 목록에서 제거합니다. 계획 아티팩트는 감사 목적으로 `.planning/workstreams/backend-api/`에 보존됩니다.
---
@@ -124,8 +124,8 @@ GSD는 워크스트림을 보관 상태로 표시하고 활성 목록에서 제
세션의 활성 컨텍스트를 변경하지 않고 특정 워크스트림에 대해 하나의 명령을 실행해야 하는 경우 `--ws` 플래그를 사용합니다:
```bash
/gsd-progress --ws frontend-dash
/gsd-plan-phase 2 --ws backend-api
/msd-progress --ws frontend-dash
/msd-plan-phase 2 --ws backend-api
```
`--ws`는 해석 우선순위에서 가장 높은 우선권을 가지며 세션 범위의 포인터를 변경하지 않습니다.
@@ -145,7 +145,7 @@ GSD는 워크스트림을 보관 상태로 표시하고 활성 목록에서 제
- **여러 저장소**(예: `hr-ui`와 `ZeymoAPI`)에서 작업할 때
- 기능별로 **별도의 git 워크트리** 또는 클론이 필요할 때 — 완전히 독립된 브랜치, 잠금 파일, 빌드 아티팩트
- 메인 저장소의 `.planning/` 하위 디렉터리가 아닌 완전히 별도의 `.planning/` 루트로 `/gsd-new-project`를 독립적으로 실행하고자 할 때
- 메인 저장소의 `.planning/` 하위 디렉터리가 아닌 완전히 별도의 `.planning/` 루트로 `/msd-new-project`를 독립적으로 실행하고자 할 때
---

74
docs/ko-KR/issue-driven-orchestration.md
View File

@@ -1,56 +1,56 @@
# GSD를 사용한 이슈 주도 오케스트레이션
# MSD를 사용한 이슈 주도 오케스트레이션
**상태:** 안정적인 워크플로우 가이드
**대상:** GitHub Issues, Linear, Jira 또는 유사한 이슈 트래커에서 작업을 관리하며
GSD의 기존 기본 도구들을 통해 AI 보조 구현을 이끌고자 하는 개발자.
MSD의 기존 기본 도구들을 통해 AI 보조 구현을 이끌고자 하는 개발자.
## 이 가이드란 무엇인가
GSD가 이미 제공하는 명령어들을 이슈 트래커 → 워크스페이스 → 계획/실행 → 검증/리뷰 → PR 루프로 조합하는 레시피이다. 문서화만을 위한 것이다. 새로운 명령어도, 데몬도, 트래커 통합도 없다 — 아래 참조된 모든 명령어들은 GSD에 이미 존재한다.
MSD가 이미 제공하는 명령어들을 이슈 트래커 → 워크스페이스 → 계획/실행 → 검증/리뷰 → PR 루프로 조합하는 레시피이다. 문서화만을 위한 것이다. 새로운 명령어도, 데몬도, 트래커 통합도 없다 — 아래 참조된 모든 명령어들은 MSD에 이미 존재한다.
형태는 OpenAI의 오픈 소스 [Symphony 오케스트레이션 레퍼런스](https://openai.com/index/open-source-codex-orchestration-symphony/)([저장소](https://github.com/openai/symphony))에서 영감을 받았다. GSD는 Symphony를 벤더링하거나 래핑하지 않는다. 오케스트레이션 *개념들*이 GSD가 이미 노출하는 기본 도구들에 깔끔하게 매핑된다; 이 가이드는 글루 코드를 작성하거나 GSD의 안전 게이트를 우회하지 않고도 패턴을 채택할 수 있도록 매핑을 명확하게 설명한다.
형태는 OpenAI의 오픈 소스 [Symphony 오케스트레이션 레퍼런스](https://openai.com/index/open-source-codex-orchestration-symphony/)([저장소](https://github.com/openai/symphony))에서 영감을 받았다. MSD는 Symphony를 벤더링하거나 래핑하지 않는다. 오케스트레이션 *개념들*이 MSD가 이미 노출하는 기본 도구들에 깔끔하게 매핑된다; 이 가이드는 글루 코드를 작성하거나 MSD의 안전 게이트를 우회하지 않고도 패턴을 채택할 수 있도록 매핑을 명확하게 설명한다.
## 존재 이유
GSD에는 이슈 주도 AI 개발을 위한 구성 요소들이 있다 —
`/gsd-workspace --new`, `/gsd-manager`, `/gsd-autonomous`, `/gsd-verify-work`,
`/gsd-review`, `/gsd-ship`, 그리고 `STATE.md`와 단계 결과물 스위트
MSD에는 이슈 주도 AI 개발을 위한 구성 요소들이 있다 —
`/msd-workspace --new`, `/msd-manager`, `/msd-autonomous`, `/msd-verify-work`,
`/msd-review`, `/msd-ship`, 그리고 `STATE.md`와 단계 결과물 스위트
— 하지만 사용자 정의 오케스트레이션 스크립트를 작성하지 않고 단일 트래커 이슈에서 이것들을 구동하는 방법을 안내하는 가이드가 없다. 그 가이드 없이는 실패 모드들이 발생한다:
- 과소 사용: 개발자들이 discuss/plan/execute를 수동으로 실행하면서 작업 패턴이 적합할 때도 `/gsd-manager`나 `/gsd-autonomous`에 손을 뻗지 않는다.
- 과소 사용: 개발자들이 discuss/plan/execute를 수동으로 실행하면서 작업 패턴이 적합할 때도 `/msd-manager`나 `/msd-autonomous`에 손을 뻗지 않는다.
- 임시방편 스크립트: 개발자들이 트래커와 `claude` 호출 사이에 임시 쉘 루프를 연결하여 `STATE.md`, 단계 매니페스트, 검증 게이트를 우회한다.
이 가이드는 정규 루프를 발견 가능하게 만든다.
## 개념 매핑
각 행은 Symphony 스타일 오케스트레이션 개념을 GSD가 이미 제공하는 기본 도구에 매핑한다. Symphony 문서, 블로그 게시물, 또는 타사 오케스트레이션 설명을 읽을 때 이 표를 번역 키로 사용하라.
각 행은 Symphony 스타일 오케스트레이션 개념을 MSD가 이미 제공하는 기본 도구에 매핑한다. Symphony 문서, 블로그 게시물, 또는 타사 오케스트레이션 설명을 읽을 때 이 표를 번역 키로 사용하라.
| Symphony 개념 | GSD 기본 도구 |
| Symphony 개념 | MSD 기본 도구 |
|---|---|
| `WORKFLOW.md` (최상위 의도) | `ROADMAP.md` (프로젝트 의도), `STATE.md` (라이브 상태), 단계 `CONTEXT.md` (단계별 범위), 단계 `PLAN.md` (실행 가능한 단계) |
| 작업당 격리된 에이전트 워크스페이스 | `/gsd-workspace --new --strategy worktree` |
| 에이전트 디스패치 및 동시성 | `/gsd-manager` (대화형 대시보드), `/gsd-autonomous` (무인) |
| 단계별 계획 및 논의 단계 | `/gsd-discuss-phase` → `/gsd-plan-phase` → `/gsd-execute-phase` |
| 작업 증명 / 테스트 증거 | `/gsd-verify-work` (`/clear` 전반에 걸쳐 지속되는 UAT.md) |
| 적대적 리뷰 | `/gsd-review` (계획의 교차 AI 동료 리뷰) |
| 사람 병합 게이트 | `/gsd-ship` (PR 생성, 선택적 코드 리뷰, 병합 준비) |
| 후속 캡처 | `/gsd-capture`, `/gsd-capture --seed`, `/gsd-new-milestone`, 또는 수동으로 열린 트래커 이슈 |
| 작업당 격리된 에이전트 워크스페이스 | `/msd-workspace --new --strategy worktree` |
| 에이전트 디스패치 및 동시성 | `/msd-manager` (대화형 대시보드), `/msd-autonomous` (무인) |
| 단계별 계획 및 논의 단계 | `/msd-discuss-phase` → `/msd-plan-phase` → `/msd-execute-phase` |
| 작업 증명 / 테스트 증거 | `/msd-verify-work` (`/clear` 전반에 걸쳐 지속되는 UAT.md) |
| 적대적 리뷰 | `/msd-review` (계획의 교차 AI 동료 리뷰) |
| 사람 병합 게이트 | `/msd-ship` (PR 생성, 선택적 코드 리뷰, 병합 준비) |
| 후속 캡처 | `/msd-capture`, `/msd-capture --seed`, `/msd-new-milestone`, 또는 수동으로 열린 트래커 이슈 |
| 동시성 제어 | Manager / background-agent 의미 (항상 켜진 폴러 없음) |
매핑은 단방향이다: GSD가 안전 게이트(검증, 사람 리뷰, 후속 생성에 대한 명시적 확인)를 소유한다. Symphony의 "지속적 오케스트레이션" 프레이밍은 의도적으로 채택하지 않는다 — [비목표](#비목표) 참조.
매핑은 단방향이다: MSD가 안전 게이트(검증, 사람 리뷰, 후속 생성에 대한 명시적 확인)를 소유한다. Symphony의 "지속적 오케스트레이션" 프레이밍은 의도적으로 채택하지 않는다 — [비목표](#비목표) 참조.
## 엔드투엔드 흐름
단일 트래커 이슈에서 엔드투엔드로 실행될 수 있도록 작성된 정규 이슈 → PR 루프. 실행 전에 대괄호 플레이스홀더를 교체하라.
1. **트래커 이슈 선택.** 트래커(GitHub, Linear 등)에서 자율 구현에 충분히 범위가 지정된 이슈 하나를 선택한다 — 범위가 한정되고, 관찰 가능한 수락 기준이 있으며, 실행을 막는 업스트림 의존성이 없는 것.
2. **GSD 단계에 매핑.** 이슈가 `ROADMAP.md`의 기존 단계에 매핑된다면 선택한다. 그렇지 않으면 `/gsd-new-milestone`(관련 이슈들의 새 마일스톤을 위한)을 실행하거나 `/gsd-phase` / `/gsd-phase --insert`를 통해 단계를 열어라. 압축 후에도 추적 가능성이 유지되도록 단계의 `CONTEXT.md`에 트래커 이슈 URL을 캡처하라.
3. **격리된 워크스페이스 생성.** `/gsd-workspace --new --strategy worktree <slug>`를 실행하여 독립적인 `.planning/` 디렉터리를 가진 git worktree를 생성한다. worktree가 안전 경계이다: 모든 탐색, 부분 커밋, 중단된 계획이 `main` 밖에 머문다.
4. **GSD를 통해 discuss → plan → execute 실행.** 워크스페이스 내에서 `/gsd-discuss-phase`로 모호함을 명확히 하고, `/gsd-plan-phase`로 `PLAN.md`를 생성하고, `/gsd-manager`(대화형 대시보드) 또는 `/gsd-execute-phase` / `/gsd-autonomous`(무인)로 구현한다. GSD 외부에서 raw `claude` 호출을 구동하는 것을 피하라 — 그것은 `STATE.md` 업데이트와 단계 매니페스트를 우회한다.
5. **작업 증명 요구.** `/gsd-verify-work`를 실행하여 사용자가 단계의 수락 기준에 대해 UAT를 진행하도록 안내한다. 테스트, 스크린샷, 로그 캡처, 설정 차이가 모두 `UAT.md`에 기록되며, 이것은 `/clear` 전반에 걸쳐 지속되고 검증이 놓친 범위를 표면화할 때 `/gsd-plan-phase --gaps`에 공급된다.
6. **리뷰 및 출시 게이트 통과.** `/gsd-review`를 실행하여 독립적인 AI CLI들로부터 계획의 적대적 동료 리뷰를 받고(모델별 맹점 포착), 그런 다음 `/gsd-ship`을 실행하여 계획 결과물로 구성된 풍부한 본문으로 PR을 열어라. 두 게이트 모두 원격에 도달하기 전에 사람의 결정을 요구한다.
7. **후속 작업 명시적으로 캡처.** 인라인 메모에는 `/gsd-capture`를, 미래 단계가 될 아이디어에는 `/gsd-capture --seed`를, 일관된 후속 작업 그룹에는 `/gsd-new-milestone`을 사용하라. 발견된 후속 작업에서 트래커 이슈를 생성하는 것은 명시적인 사용자 확인이 필요하다 — GSD는 원격 트래커에 자동으로 게시하지 않는다.
2. **MSD 단계에 매핑.** 이슈가 `ROADMAP.md`의 기존 단계에 매핑된다면 선택한다. 그렇지 않으면 `/msd-new-milestone`(관련 이슈들의 새 마일스톤을 위한)을 실행하거나 `/msd-phase` / `/msd-phase --insert`를 통해 단계를 열어라. 압축 후에도 추적 가능성이 유지되도록 단계의 `CONTEXT.md`에 트래커 이슈 URL을 캡처하라.
3. **격리된 워크스페이스 생성.** `/msd-workspace --new --strategy worktree <slug>`를 실행하여 독립적인 `.planning/` 디렉터리를 가진 git worktree를 생성한다. worktree가 안전 경계이다: 모든 탐색, 부분 커밋, 중단된 계획이 `main` 밖에 머문다.
4. **MSD를 통해 discuss → plan → execute 실행.** 워크스페이스 내에서 `/msd-discuss-phase`로 모호함을 명확히 하고, `/msd-plan-phase`로 `PLAN.md`를 생성하고, `/msd-manager`(대화형 대시보드) 또는 `/msd-execute-phase` / `/msd-autonomous`(무인)로 구현한다. MSD 외부에서 raw `claude` 호출을 구동하는 것을 피하라 — 그것은 `STATE.md` 업데이트와 단계 매니페스트를 우회한다.
5. **작업 증명 요구.** `/msd-verify-work`를 실행하여 사용자가 단계의 수락 기준에 대해 UAT를 진행하도록 안내한다. 테스트, 스크린샷, 로그 캡처, 설정 차이가 모두 `UAT.md`에 기록되며, 이것은 `/clear` 전반에 걸쳐 지속되고 검증이 놓친 범위를 표면화할 때 `/msd-plan-phase --gaps`에 공급된다.
6. **리뷰 및 출시 게이트 통과.** `/msd-review`를 실행하여 독립적인 AI CLI들로부터 계획의 적대적 동료 리뷰를 받고(모델별 맹점 포착), 그런 다음 `/msd-ship`을 실행하여 계획 결과물로 구성된 풍부한 본문으로 PR을 열어라. 두 게이트 모두 원격에 도달하기 전에 사람의 결정을 요구한다.
7. **후속 작업 명시적으로 캡처.** 인라인 메모에는 `/msd-capture`를, 미래 단계가 될 아이디어에는 `/msd-capture --seed`를, 일관된 후속 작업 그룹에는 `/msd-new-milestone`을 사용하라. 발견된 후속 작업에서 트래커 이슈를 생성하는 것은 명시적인 사용자 확인이 필요하다 — MSD는 원격 트래커에 자동으로 게시하지 않는다.
PR이 병합되면 루프가 닫힌다. PR 본문의 자동 닫기 키워드들(`Closes #NNN` / `Fixes #NNN`)이 병합 시점에 트래커 이슈를 닫는다.
@@ -58,30 +58,30 @@ PR이 병합되면 루프가 닫힌다. PR 본문의 자동 닫기 키워드들(
루프는 네 가지 불변성이 구성상 유지되기 때문에 안전하다:
- **격리된 worktree.** 모든 이슈는 `/gsd-workspace --new` worktree에서 실행되므로 부분 작업, 중단된 계획, 탐색적 커밋이 `main`에 절대 닿지 않는다. `gsd-local-patches/`가 worktree의 수동 편집이 업데이트 후에 다시 돌아와야 할 경우의 복구 표면이다.
- **명시적 사람 리뷰.** `/gsd-review`와 `/gsd-ship` 모두 사람 승인을 위해 중지된다. 자동 병합도 실행에서 자동 PR 경로도 없다. 특정 저장소에 대해 사람 게이트를 제거하고 싶다면, 그것은 사용자의 브랜치 보호 / 병합 큐 정책 결정이지 GSD가 사용자 대신 선택하는 것이 아니다.
- **자동 공개 게시 없음.** GSD는 명시적으로 사용자가 시작한 명령어 없이는 트래커 이슈를 열거나, 댓글을 달거나, 닫지 않는다. 후속 캡처는 기본적으로 로컬 결과물(메모, 시드, 마일스톤)에 저장된다; 트래커에 다시 푸시하는 것은 별도의 수동 단계이다.
- **출시 전 검증.** `/gsd-verify-work`의 UAT.md는 `/gsd-ship`이 실행되기 전에 증거를 기록해야 한다. 권장 원칙은 구현이 올바르게 보일 때도 `verification_failed`를 차단제로 취급하는 것이다 — 실패는 일반적으로 불안정한 테스트가 아닌 놓친 수락 기준을 표면화한다.
- **격리된 worktree.** 모든 이슈는 `/msd-workspace --new` worktree에서 실행되므로 부분 작업, 중단된 계획, 탐색적 커밋이 `main`에 절대 닿지 않는다. `msd-local-patches/`가 worktree의 수동 편집이 업데이트 후에 다시 돌아와야 할 경우의 복구 표면이다.
- **명시적 사람 리뷰.** `/msd-review`와 `/msd-ship` 모두 사람 승인을 위해 중지된다. 자동 병합도 실행에서 자동 PR 경로도 없다. 특정 저장소에 대해 사람 게이트를 제거하고 싶다면, 그것은 사용자의 브랜치 보호 / 병합 큐 정책 결정이지 MSD가 사용자 대신 선택하는 것이 아니다.
- **자동 공개 게시 없음.** MSD는 명시적으로 사용자가 시작한 명령어 없이는 트래커 이슈를 열거나, 댓글을 달거나, 닫지 않는다. 후속 캡처는 기본적으로 로컬 결과물(메모, 시드, 마일스톤)에 저장된다; 트래커에 다시 푸시하는 것은 별도의 수동 단계이다.
- **출시 전 검증.** `/msd-verify-work`의 UAT.md는 `/msd-ship`이 실행되기 전에 증거를 기록해야 한다. 권장 원칙은 구현이 올바르게 보일 때도 `verification_failed`를 차단제로 취급하는 것이다 — 실패는 일반적으로 불안정한 테스트가 아닌 놓친 수락 기준을 표면화한다.
이 불변성 중 하나라도 우회되면(예: worktree에 직접 `claude`를 실행하거나, `/gsd-verify-work`를 건너뛰거나, 사용자 확인 없이 트래커 API를 통해 이슈 생성을 스크립팅하는 경우), 이 가이드의 보장이 적용되지 않는다.
이 불변성 중 하나라도 우회되면(예: worktree에 직접 `claude`를 실행하거나, `/msd-verify-work`를 건너뛰거나, 사용자 확인 없이 트래커 API를 통해 이슈 생성을 스크립팅하는 경우), 이 가이드의 보장이 적용되지 않는다.
## 비목표
이 가이드는 의도적으로 다음 중 어느 것도 제안하지 않는다. 코드 리뷰에서 재논의되지 않도록 여기에 나열한다:
- **Symphony 코드 벤더링이나 복사 없음.** GSD는 자체 기본 도구를 재사용한다. 위의 매핑은 개념적이다; 이 저장소에 Symphony 파생 소스가 없다.
- **장시간 실행 데몬 없음.** GSD는 GitHub이나 Linear를 폴링하지 않는다. manager와 autonomous 워크플로우는 데몬이 아닌 background-agent 의미를 통해 동시성을 처리한다.
- **필수 트래커 의존성 없음.** 루프는 트래커 통합 없이도 작동한다. "트래커 이슈" 단계는 *사람 입력*이다 — URL이 `CONTEXT.md`에 들어간다. GSD는 어떤 트래커를 사용하는지, 또는 트래커를 사용하는지에 대해 의견이 없다.
- **검증, 리뷰, 사람 결정 게이트 우회 없음.** `/gsd-autonomous`를 실행할 때도 검증 및 리뷰 게이트가 여전히 실행된다. "autonomous" 레이블은 단계 간 진행을 가리키며, 사람 승인 건너뛰기를 가리키지 않는다.
- **Symphony 코드 벤더링이나 복사 없음.** MSD는 자체 기본 도구를 재사용한다. 위의 매핑은 개념적이다; 이 저장소에 Symphony 파생 소스가 없다.
- **장시간 실행 데몬 없음.** MSD는 GitHub이나 Linear를 폴링하지 않는다. manager와 autonomous 워크플로우는 데몬이 아닌 background-agent 의미를 통해 동시성을 처리한다.
- **필수 트래커 의존성 없음.** 루프는 트래커 통합 없이도 작동한다. "트래커 이슈" 단계는 *사람 입력*이다 — URL이 `CONTEXT.md`에 들어간다. MSD는 어떤 트래커를 사용하는지, 또는 트래커를 사용하는지에 대해 의견이 없다.
- **검증, 리뷰, 사람 결정 게이트 우회 없음.** `/msd-autonomous`를 실행할 때도 검증 및 리뷰 게이트가 여전히 실행된다. "autonomous" 레이블은 단계 간 진행을 가리키며, 사람 승인 건너뛰기를 가리키지 않는다.
- **기본 스킬 / 명령어 표면 확장 없음.** 이 가이드에 참조된 모든 명령어들은 이미 존재한다. 이 가이드는 문서 표면이지, 기능 표면이 아니다.
## 가능한 미래 후속 작업
이 루프에 대한 유지관리자 경험이 정당화된다면, 별도의 승인된 개선 사항이 나중에 *최소한의* 트래커 브리지를 추가할 수 있다:
- 하나의 GitHub 또는 Linear 이슈를 GSD 워크스페이스 / 단계로 가져오기.
- 하나의 GitHub 또는 Linear 이슈를 MSD 워크스페이스 / 단계로 가져오기.
- `UAT.md` 증거를 소스 이슈의 댓글로 내보내기.
- `/gsd-capture --seed` 출력에서 후속 트래커 이슈 생성.
- `/msd-capture --seed` 출력에서 후속 트래커 이슈 생성.
그 각각은 통합 표면과 지속적인 유지 관리 부담을 추가하기 때문에 자체 개선 제안이 될 것이다. 이 가이드의 범위에서 벗어난다.
@@ -89,8 +89,8 @@ PR이 병합되면 루프가 닫힌다. PR 본문의 자동 닫기 키워드들(
- [단계 루프](explanation/the-phase-loop.md) — 논의 → 계획 → 실행 → 검증 → 출시가 반복되는 사이클로 어떻게 맞물리는지.
- [워크스페이스 how-to](how-to/work-in-parallel-with-workstreams.md) — 병렬 worktree를 생성하고 관리하는 단계별 가이드.
- [문서 인덱스](README.md) — GSD Core 문서의 전체 목차.
- [문서 인덱스](README.md) — MSD Core 문서의 전체 목차.
- [docs/USER-GUIDE.md](./USER-GUIDE.md) — 위에 참조된 개별 명령어들의 작업 지향 안내서.
- [docs/COMMANDS.md](COMMANDS.md) — `/gsd-*` 명령어의 전체 레퍼런스.
- [docs/COMMANDS.md](COMMANDS.md) — `/msd-*` 명령어의 전체 레퍼런스.
- [docs/FEATURES.md](FEATURES.md) — 기능 수준 역량 매트릭스 (워크스페이스, manager, autonomous, verify, review, ship).
- [docs/ARCHITECTURE.md](ARCHITECTURE.md) — 단계 결과물 수명 주기와 `STATE.md` 메카닉.

18
docs/ko-KR/reference/context-md.md
View File

@@ -1,6 +1,6 @@
# CONTEXT.md 스키마 참조
페이즈별 `CONTEXT.md`는 `/gsd-discuss-phase` 중 캡처된 구현 결정을 담는 GSD Core의 파일입니다. 이 파일은 리서치 에이전트와 플래닝 에이전트 모두를 위한 주요 업스트림 입력입니다. 이 페이지는 해당 파일의 구조를 설명합니다. [문서 인덱스](../../README.md)를 참조하세요.
페이즈별 `CONTEXT.md`는 `/msd-discuss-phase` 중 캡처된 구현 결정을 담는 MSD Core의 파일입니다. 이 파일은 리서치 에이전트와 플래닝 에이전트 모두를 위한 주요 업스트림 입력입니다. 이 페이지는 해당 파일의 구조를 설명합니다. [문서 인덱스](../../README.md)를 참조하세요.
---
@@ -14,7 +14,7 @@
예: `.planning/phases/03-post-feed/03-CONTEXT.md`.
이 파일은 `gsd-core/workflows/discuss-phase.md`의 `write_context`(또는 PRD / ADR 인제스트 익스프레스 경로)에 의해 생성됩니다. 일반적인 운영 중에는 절대로 수동으로 편집하지 않습니다 — discuss-phase 워크플로가 이 파일을 기록하고 다운스트림 에이전트는 이를 봉인된 진실의 원천으로 읽습니다.
이 파일은 `msd-core/workflows/discuss-phase.md`의 `write_context`(또는 PRD / ADR 인제스트 익스프레스 경로)에 의해 생성됩니다. 일반적인 운영 중에는 절대로 수동으로 편집하지 않습니다 — discuss-phase 워크플로가 이 파일을 기록하고 다운스트림 에이전트는 이를 봉인된 진실의 원천으로 읽습니다.
---
@@ -39,12 +39,12 @@
| 블록 | 목적 | 작성자 | 소비자 |
|---|---|---|---|
| `<domain>` | 페이즈 경계를 명시합니다 — 이 페이즈가 무엇을 전달하고 명시적으로 범위 밖인 것이 무엇인지. 플래닝과 실행 전반에 걸쳐 범위 가드레일을 고정합니다. | `discuss-phase` (ROADMAP.md 페이즈 목표에서) | `gsd-planner`, `gsd-plan-checker` (범위 준수) |
| `<spec_lock>` | `check_spec` 단계에서 `*-SPEC.md`가 발견된 경우에만 존재합니다. 잠긴 요구사항 수와 범위 경계를 나열하며, 에이전트는 전체 요구사항을 위해 `SPEC.md`를 직접 읽도록 안내됩니다. | `discuss-phase` (조건부) | `gsd-planner` (요구사항을 여기서 재읽지 않고 SPEC.md를 읽음) |
| `<decisions>` | 논의에서 캡처된 구현 결정으로 `D-NN` 식별자로 키가 지정됩니다. 카테고리는 고정된 분류법이 아닌 실제로 논의된 내용에서 나옵니다. 사용자가 위임한 영역을 위한 `Claude's Discretion` 하위 섹션을 포함합니다. | `discuss-phase` (대화형 토론) | `gsd-planner` (잠긴 결정은 반드시 구현되어야 함), `gsd-plan-checker` (Dimension 7 준수) |
| `<canonical_refs>` | 이 페이즈와 관련된 모든 spec, ADR, 기능 문서, 또는 설계 문서의 전체 상대 경로. 필수 — 모든 CONTEXT.md에 이 섹션이 있어야 합니다. 에이전트는 플래닝 또는 구현 전에 나열된 파일을 읽어야 합니다. | `discuss-phase` (ROADMAP.md 참조 + 토론 중 사용자 참조 + 코드베이스 스카우트에서 축적) | `gsd-phase-researcher`, `gsd-planner` |
| `<code_context>` | `scout_codebase` 단계에서 발견된 재사용 가능한 자산, 확립된 패턴, 통합 지점. 에이전트가 재구현하는 대신 기존 코드를 활용하도록 안내합니다. | `discuss-phase` (코드베이스 스카우트) | `gsd-planner`, `gsd-phase-researcher` |
| `<specifics>` | 토론 중 캡처된 구체적인 "X처럼 하고 싶다" 참조, 제품 비교, 또는 특정 예시. | `discuss-phase` (자유형 사용자 입력) | `gsd-planner` |
| `<domain>` | 페이즈 경계를 명시합니다 — 이 페이즈가 무엇을 전달하고 명시적으로 범위 밖인 것이 무엇인지. 플래닝과 실행 전반에 걸쳐 범위 가드레일을 고정합니다. | `discuss-phase` (ROADMAP.md 페이즈 목표에서) | `msd-planner`, `msd-plan-checker` (범위 준수) |
| `<spec_lock>` | `check_spec` 단계에서 `*-SPEC.md`가 발견된 경우에만 존재합니다. 잠긴 요구사항 수와 범위 경계를 나열하며, 에이전트는 전체 요구사항을 위해 `SPEC.md`를 직접 읽도록 안내됩니다. | `discuss-phase` (조건부) | `msd-planner` (요구사항을 여기서 재읽지 않고 SPEC.md를 읽음) |
| `<decisions>` | 논의에서 캡처된 구현 결정으로 `D-NN` 식별자로 키가 지정됩니다. 카테고리는 고정된 분류법이 아닌 실제로 논의된 내용에서 나옵니다. 사용자가 위임한 영역을 위한 `Claude's Discretion` 하위 섹션을 포함합니다. | `discuss-phase` (대화형 토론) | `msd-planner` (잠긴 결정은 반드시 구현되어야 함), `msd-plan-checker` (Dimension 7 준수) |
| `<canonical_refs>` | 이 페이즈와 관련된 모든 spec, ADR, 기능 문서, 또는 설계 문서의 전체 상대 경로. 필수 — 모든 CONTEXT.md에 이 섹션이 있어야 합니다. 에이전트는 플래닝 또는 구현 전에 나열된 파일을 읽어야 합니다. | `discuss-phase` (ROADMAP.md 참조 + 토론 중 사용자 참조 + 코드베이스 스카우트에서 축적) | `msd-phase-researcher`, `msd-planner` |
| `<code_context>` | `scout_codebase` 단계에서 발견된 재사용 가능한 자산, 확립된 패턴, 통합 지점. 에이전트가 재구현하는 대신 기존 코드를 활용하도록 안내합니다. | `discuss-phase` (코드베이스 스카우트) | `msd-planner`, `msd-phase-researcher` |
| `<specifics>` | 토론 중 캡처된 구체적인 "X처럼 하고 싶다" 참조, 제품 비교, 또는 특정 예시. | `discuss-phase` (자유형 사용자 입력) | `msd-planner` |
| `<deferred>` | 토론에서 제기되었지만 다른 페이즈에 속하는 아이디어. 잃어버리지 않도록 보존됩니다. todo가 검토되었지만 범위에 포함되지 않은 경우 `Reviewed Todos` 하위 섹션을 포함합니다. | `discuss-phase` (범위 초과 리디렉션) | 자동화된 에이전트가 소비하지 않음; 인간 참조 전용 |
---
@@ -107,7 +107,7 @@ No external specs — requirements fully captured in decisions above
## SPEC.md 통합
페이즈를 논의하기 전에 `/gsd-spec-phase`가 실행된 경우, `check_spec` 단계에서 `*-SPEC.md` 파일을 찾아 `<spec_lock>`을 활성화합니다:
페이즈를 논의하기 전에 `/msd-spec-phase`가 실행된 경우, `check_spec` 단계에서 `*-SPEC.md` 파일을 찾아 `<spec_lock>`을 활성화합니다:
```markdown
<spec_lock>

14
docs/ko-KR/reference/plan-md.md
View File

@@ -1,6 +1,6 @@
# PLAN.md 스키마 참조
플랜별 `PLAN.md`는 GSD Core의 실행 가능한 작업 단위입니다 — 실행기 에이전트에게 무엇을 빌드해야 하고 올바르게 빌드되었는지 어떻게 검증할지를 정확히 알려주는 구조화된 문서입니다. 이 페이지는 해당 파일의 구조를 설명합니다. [문서 인덱스](../../README.md)를 참조하세요.
플랜별 `PLAN.md`는 MSD Core의 실행 가능한 작업 단위입니다 — 실행기 에이전트에게 무엇을 빌드해야 하고 올바르게 빌드되었는지 어떻게 검증할지를 정확히 알려주는 구조화된 문서입니다. 이 페이지는 해당 파일의 구조를 설명합니다. [문서 인덱스](../../README.md)를 참조하세요.
---
@@ -14,7 +14,7 @@
예: `.planning/phases/03-post-feed/03-02-PLAN.md` (Phase 3, Plan 2).
플랜은 `gsd-planner` 에이전트(`/gsd-plan-phase`에 의해 생성됨)가 만들고 `execute-phase`가 소비합니다. 페이즈는 보통 1~4개의 플랜을 포함하며, 페이즈 내의 플랜은 독립적인 작업이 병렬로 실행되도록 실행 웨이브에 할당됩니다.
플랜은 `msd-planner` 에이전트(`/msd-plan-phase`에 의해 생성됨)가 만들고 `execute-phase`가 소비합니다. 페이즈는 보통 1~4개의 플랜을 포함하며, 페이즈 내의 플랜은 독립적인 작업이 병렬로 실행되도록 실행 웨이브에 할당됩니다.
---
@@ -66,7 +66,7 @@ must_haves:
| `phase` | 예 | string | 페이즈 식별자, 예: `03-post-feed`. |
| `plan` | 예 | string | 페이즈 내 플랜 번호, 예: `02`. |
| `type` | 예 | `execute` 또는 `tdd` | 표준 플랜의 경우 `execute`; 구현 전에 테스트를 먼저 작성하는 테스트 주도 플랜의 경우 `tdd`. |
| `wave` | 예 | integer | 실행 웨이브. 웨이브 1의 플랜은 병렬로 실행됩니다(의존성 없음). 웨이브 2 이상의 플랜은 이전 웨이브의 모든 플랜이 완료될 때까지 기다립니다. `gsd-planner`가 플래닝 시점에 미리 계산합니다. |
| `wave` | 예 | integer | 실행 웨이브. 웨이브 1의 플랜은 병렬로 실행됩니다(의존성 없음). 웨이브 2 이상의 플랜은 이전 웨이브의 모든 플랜이 완료될 때까지 기다립니다. `msd-planner`가 플래닝 시점에 미리 계산합니다. |
| `depends_on` | 예 | 플랜 ID 배열 | 이 플랜이 기다려야 하는 플랜. 빈 배열 = 웨이브 1. 예: `["03-01"]`은 이 플랜이 Phase 3의 Plan 01 이후에 실행됨을 의미합니다. |
| `files_modified` | 예 | 경로 배열 | 이 플랜이 생성하거나 수정하는 모든 파일. 플랜 체커가 동일 웨이브 파일 충돌을 감지하고 execute-phase가 머지 추적에 사용합니다. |
| `autonomous` | 예 | boolean | 모든 태스크가 `auto` 타입일 때 `true`. 플랜에 인간 상호작용이 필요한 `checkpoint:*` 태스크가 포함된 경우 `false`. |
@@ -78,7 +78,7 @@ must_haves:
## `must_haves` 필드
`must_haves`는 페이즈 목표 달성을 위해 관찰 가능하게 참이어야 하는 것을 캡처합니다. 플래닝 중에 도출되며 실행 후 `gsd-verifier` 에이전트가 검증합니다.
`must_haves`는 페이즈 목표 달성을 위해 관찰 가능하게 참이어야 하는 것을 캡처합니다. 플래닝 중에 도출되며 실행 후 `msd-verifier` 에이전트가 검증합니다.
### 하위 필드
@@ -122,8 +122,8 @@ Output: PostFeed and PostCard components wired to /api/feed.
```xml
<execution_context>
@~/.claude/gsd-core/workflows/execute-plan.md
@~/.claude/gsd-core/templates/summary.md
@~/.claude/msd-core/workflows/execute-plan.md
@~/.claude/msd-core/templates/summary.md
</execution_context>
```
@@ -194,7 +194,7 @@ Output: PostFeed and PostCard components wired to /api/feed.
## 플랜 품질 차원
`gsd-plan-checker` 에이전트는 실행 시작 전에 12개 차원에 걸쳐 모든 PLAN.md를 검토합니다. BLOCKER 심각도 확인에 실패한 플랜은 수정을 위해 `gsd-planner`에 반환됩니다(최대 3회 반복):
`msd-plan-checker` 에이전트는 실행 시작 전에 12개 차원에 걸쳐 모든 PLAN.md를 검토합니다. BLOCKER 심각도 확인에 실패한 플랜은 수정을 위해 `msd-planner`에 반환됩니다(최대 3회 반복):
| 차원 | 확인 내용 |
|---|---|

72
docs/ko-KR/reference/planning-artifacts.md
View File

@@ -1,6 +1,6 @@
# Planning artifacts 참조
`.planning/` 디렉터리는 프로젝트를 위한 GSD Core의 공유 메모리입니다. 모든 워크플로가 여기서 읽고 쓰며, 감사 가능한 결정 추적 기록을 남깁니다. 이 페이지는 모든 파일, 그 목적, 그리고 어떤 명령이 생성하거나 소비하는지를 매핑합니다. [문서 인덱스](../../README.md)를 참조하세요.
`.planning/` 디렉터리는 프로젝트를 위한 MSD Core의 공유 메모리입니다. 모든 워크플로가 여기서 읽고 쓰며, 감사 가능한 결정 추적 기록을 남깁니다. 이 페이지는 모든 파일, 그 목적, 그리고 어떤 명령이 생성하거나 소비하는지를 매핑합니다. [문서 인덱스](../../README.md)를 참조하세요.
---
@@ -50,32 +50,32 @@
| | |
|---|---|
| **목적** | 표준 프로젝트 아이덴티티: 무엇인지, 누구를 위한 것인지, 핵심 가치, 요구사항, 제약 사항, 주요 결정. 제품이 발전함에 따라 프로젝트 생명주기 전반에 걸쳐 업데이트됩니다. |
| **생성자** | `/gsd-new-project` (최초 생성, `/gsd-onboard` handoff 포함); 결정이 검증됨에 따라 `/gsd-complete-milestone`에 의해 업데이트됩니다. |
| **소비자** | 모든 플래닝 워크플로; `gsd-phase-researcher`, `gsd-planner` (컨텍스트); `discuss-phase` (이전 결정); `gsd-plan-checker` (프로젝트 제약 사항). |
| **생성자** | `/msd-new-project` (최초 생성, `/msd-onboard` handoff 포함); 결정이 검증됨에 따라 `/msd-complete-milestone`에 의해 업데이트됩니다. |
| **소비자** | 모든 플래닝 워크플로; `msd-phase-researcher`, `msd-planner` (컨텍스트); `discuss-phase` (이전 결정); `msd-plan-checker` (프로젝트 제약 사항). |
### `ROADMAP.md`
| | |
|---|---|
| **목적** | 목표, 요구사항 ID, 성공 기준, 페이즈별 표준 참조가 있는 마일스톤 및 페이즈 목록. 프로젝트가 무엇을 빌드하고 어떤 순서로 하는지에 대한 단일 진실의 원천. |
| **생성자** | `/gsd-new-project` (최초 생성, `/gsd-onboard` handoff 포함); `/gsd-phase --insert`와 `/gsd-complete-milestone`에 의해 업데이트됩니다. |
| **소비자** | `/gsd-discuss-phase`, `/gsd-plan-phase`, `/gsd-execute-phase`; 페이즈 정보가 필요한 모든 오케스트레이션 명령; `gsd-planner`, `gsd-plan-checker`, `gsd-phase-researcher`. |
| **생성자** | `/msd-new-project` (최초 생성, `/msd-onboard` handoff 포함); `/msd-phase --insert`와 `/msd-complete-milestone`에 의해 업데이트됩니다. |
| **소비자** | `/msd-discuss-phase`, `/msd-plan-phase`, `/msd-execute-phase`; 페이즈 정보가 필요한 모든 오케스트레이션 명령; `msd-planner`, `msd-plan-checker`, `msd-phase-researcher`. |
### `REQUIREMENTS.md`
| | |
|---|---|
| **목적** | 프로젝트의 번호가 매겨진 체크 가능한 인수 기준. 각 요구사항은 로드맵 페이즈에 매핑되는 ID(예: `AUTH-01`)를 가집니다. 페이즈가 실행됨에 따라 요구사항을 완료로 표시합니다. |
| **생성자** | `/gsd-new-project` (최초 생성, `/gsd-onboard` handoff 포함); `execute-phase`에 의해 요구사항이 완료로 표시됩니다. |
| **소비자** | `gsd-planner` (플랜은 모든 페이즈 요구사항 ID를 처리해야 함); `gsd-plan-checker` Dimension 1 (요구사항 커버리지); `discuss-phase` (이전 요구사항). |
| **생성자** | `/msd-new-project` (최초 생성, `/msd-onboard` handoff 포함); `execute-phase`에 의해 요구사항이 완료로 표시됩니다. |
| **소비자** | `msd-planner` (플랜은 모든 페이즈 요구사항 ID를 처리해야 함); `msd-plan-checker` Dimension 1 (요구사항 커버리지); `discuss-phase` (이전 요구사항). |
### `STATE.md`
| | |
|---|---|
| **목적** | 살아있는 위치 추적기 — 현재 페이즈와 플랜, 진행 지표, 누적된 결정, 세션 연속성 노트. 모든 워크플로 실행 시작 시 읽힙니다. 중요한 작업 이후 업데이트됩니다. |
| **생성자** | `/gsd-new-project` (최초 생성, `/gsd-onboard` handoff 포함); 모든 페이즈 워크플로, `/gsd-pause-work`, `/gsd-resume-work`에 의해 지속적으로 업데이트됩니다. |
| **소비자** | 모든 오케스트레이션 워크플로; `/gsd-progress`; `/gsd-quick`을 통한 임시 태스크 실행; `gsd-planner` 및 `gsd-phase-researcher` (프로젝트 결정). |
| **생성자** | `/msd-new-project` (최초 생성, `/msd-onboard` handoff 포함); 모든 페이즈 워크플로, `/msd-pause-work`, `/msd-resume-work`에 의해 지속적으로 업데이트됩니다. |
| **소비자** | 모든 오케스트레이션 워크플로; `/msd-progress`; `/msd-quick`을 통한 임시 태스크 실행; `msd-planner` 및 `msd-phase-researcher` (프로젝트 결정). |
전체 필드 참조는 [STATE.md 스키마](state-md.md)를 참조하세요.
@@ -84,8 +84,8 @@
| | |
|---|---|
| **목적** | 워크플로 구성: 모델 프로파일, 리서치 및 플랜 체커 토글, git 브랜칭 전략, Nyquist 검증, 병렬화 설정, 에이전트별 모델 오버라이드. |
| **생성자** | `/gsd-new-project` (최초 생성); `/gsd-settings` (대화형 편집). |
| **소비자** | 모든 워크플로 및 서브에이전트 — `gsd-tools query config-get`을 통해 초기화 시점에 읽습니다. |
| **생성자** | `/msd-new-project` (최초 생성); `/msd-settings` (대화형 편집). |
| **소비자** | 모든 워크플로 및 서브에이전트 — `msd-tools query config-get`을 통해 초기화 시점에 읽습니다. |
전체 스키마는 [CONFIGURATION](../../CONFIGURATION.md)을 참조하세요.
@@ -93,17 +93,17 @@
| | |
|---|---|
| **목적** | 브라운필드 온보딩 인덱스. 아티팩트 상태, 코드베이스 매핑 완료 여부, 초기 설정 후 권장되는 다음 GSD 명령을 기록합니다. |
| **생성자** | `PROJECT.md`, `REQUIREMENTS.md`, `ROADMAP.md`, `STATE.md`가 모두 존재한 뒤 `/gsd-onboard`. |
| **소비자** | 초기 설정을 검토하는 사람; 기존 온보딩 상태를 확인하는 향후 `/gsd-onboard` 실행. |
| **목적** | 브라운필드 온보딩 인덱스. 아티팩트 상태, 코드베이스 매핑 완료 여부, 초기 설정 후 권장되는 다음 MSD 명령을 기록합니다. |
| **생성자** | `PROJECT.md`, `REQUIREMENTS.md`, `ROADMAP.md`, `STATE.md`가 모두 존재한 뒤 `/msd-onboard`. |
| **소비자** | 초기 설정을 검토하는 사람; 기존 온보딩 상태를 확인하는 향후 `/msd-onboard` 실행. |
### `MILESTONES.md` (선택)
| | |
|---|---|
| **목적** | 완료된 마일스톤의 역사적 기록. 각 마일스톤이 종료될 때 채워지며, 무엇이 언제 출시되었는지의 아카이브 스냅샷을 제공합니다. |
| **생성자** | `/gsd-complete-milestone`. |
| **소비자** | `/gsd-audit-milestone`; 인간 검토. |
| **생성자** | `/msd-complete-milestone`. |
| **소비자** | `/msd-audit-milestone`; 인간 검토. |
### `DECISIONS-INDEX.md` (선택)
@@ -118,8 +118,8 @@
| | |
|---|---|
| **목적** | 작업이 중단될 때 기록되는 기계가 읽을 수 있는 일시 정지 상태. 재개 지점, 진행 중인 컨텍스트, 연속 지침을 포함합니다. 정확히 한 번 소비됩니다 — 재개 시. |
| **생성자** | `/gsd-pause-work`. |
| **소비자** | `/gsd-resume-work`. |
| **생성자** | `/msd-pause-work`. |
| **소비자** | `/msd-resume-work`. |
---
@@ -132,8 +132,8 @@
| | |
|---|---|
| **목적** | 플래닝 시작 전에 캡처된 구현 결정. 페이즈 경계(`<domain>`), `D-NN` 식별자가 있는 잠긴 결정(`<decisions>`), 표준 문서 참조(`<canonical_refs>`), 기존 코드 인사이트(`<code_context>`), 특정 영감(`<specifics>`), 미뤄진 아이디어(`<deferred>`)를 포함합니다. |
| **생성자** | `/gsd-discuss-phase` (대화형 토론 또는 PRD/ADR 익스프레스 경로). |
| **소비자** | `gsd-phase-researcher` (무엇을 조사할지); `gsd-planner` (잠긴 결정); `gsd-plan-checker` Dimension 7 (컨텍스트 준수). |
| **생성자** | `/msd-discuss-phase` (대화형 토론 또는 PRD/ADR 익스프레스 경로). |
| **소비자** | `msd-phase-researcher` (무엇을 조사할지); `msd-planner` (잠긴 결정); `msd-plan-checker` Dimension 7 (컨텍스트 준수). |
전체 필드 참조는 [CONTEXT.md 스키마](context-md.md)를 참조하세요.
@@ -142,7 +142,7 @@
| | |
|---|---|
| **목적** | discuss-phase 세션의 사람이 읽을 수 있는 감사 추적: 논의된 영역, 제시된 옵션, 선택된 항목, 미뤄진 아이디어, Claude의 재량에 맡겨진 항목. 자동화된 워크플로에서 소비되지 않습니다. |
| **생성자** | `/gsd-discuss-phase` (`git_commit` 단계). |
| **생성자** | `/msd-discuss-phase` (`git_commit` 단계). |
| **소비자** | 인간 검토; 회고. |
### `<NN>-RESEARCH.md`
@@ -150,32 +150,32 @@
| | |
|---|---|
| **목적** | 플래닝 전에 생성된 기술 리서치 결과. "이 페이즈를 잘 계획하기 위해 무엇을 알아야 하는가?"에 답합니다 — 도메인 분석, 패턴, 위험, 아키텍처 책임 맵, 검증 아키텍처 섹션(Nyquist 게이트에서 사용)을 포함합니다. |
| **생성자** | `/gsd-plan-phase` (via `gsd-phase-researcher` 에이전트). |
| **소비자** | `gsd-planner` (플래닝 입력); `gsd-plan-checker` Dimension 7c (계층 준수), Dimension 8 (Nyquist), Dimension 11 (리서치 해결); `gsd-pattern-mapper` (파일 목록 소스). |
| **생성자** | `/msd-plan-phase` (via `msd-phase-researcher` 에이전트). |
| **소비자** | `msd-planner` (플래닝 입력); `msd-plan-checker` Dimension 7c (계층 준수), Dimension 8 (Nyquist), Dimension 11 (리서치 해결); `msd-pattern-mapper` (파일 목록 소스). |
### `<NN>-VALIDATION.md`
| | |
|---|---|
| **목적** | RESEARCH.md의 `## Validation Architecture` 섹션에서 도출된 Nyquist 영감 검증 전략. 플랜이 지켜야 하는 자동화된 테스트 커버리지 요구사항을 지정합니다. |
| **생성자** | `/gsd-plan-phase` (Step 5.5, `workflow.nyquist_validation`이 활성화되고 RESEARCH.md에 Validation Architecture 섹션이 있는 경우). |
| **소비자** | `gsd-plan-checker` Dimension 8 (Check 8e 게이트 — Nyquist 확인이 진행되기 전에 반드시 존재해야 함); `gsd-verifier`. |
| **생성자** | `/msd-plan-phase` (Step 5.5, `workflow.nyquist_validation`이 활성화되고 RESEARCH.md에 Validation Architecture 섹션이 있는 경우). |
| **소비자** | `msd-plan-checker` Dimension 8 (Check 8e 게이트 — Nyquist 확인이 진행되기 전에 반드시 존재해야 함); `msd-verifier`. |
### `<NN>-PATTERNS.md`
| | |
|---|---|
| **목적** | `gsd-pattern-mapper`가 생성한 코드베이스 유사 맵. 이 페이즈에서 생성하거나 수정할 각 파일에 대해, 가장 가까운 기존 유사 파일을 식별하고, 파일의 역할과 데이터 흐름을 분류하며, 구체적인 코드 발췌를 추출합니다. 플래너가 일관된 패턴을 사용하도록 안내합니다. |
| **생성자** | `/gsd-plan-phase` (via `gsd-pattern-mapper` 에이전트, 선택; `workflow.pattern_mapper: false`이면 건너뜀). |
| **소비자** | `gsd-planner` (패턴 안내); `gsd-plan-checker` Dimension 12 (패턴 준수). |
| **목적** | `msd-pattern-mapper`가 생성한 코드베이스 유사 맵. 이 페이즈에서 생성하거나 수정할 각 파일에 대해, 가장 가까운 기존 유사 파일을 식별하고, 파일의 역할과 데이터 흐름을 분류하며, 구체적인 코드 발췌를 추출합니다. 플래너가 일관된 패턴을 사용하도록 안내합니다. |
| **생성자** | `/msd-plan-phase` (via `msd-pattern-mapper` 에이전트, 선택; `workflow.pattern_mapper: false`이면 건너뜀). |
| **소비자** | `msd-planner` (패턴 안내); `msd-plan-checker` Dimension 12 (패턴 준수). |
### `<NN>-<PP>-PLAN.md`
| | |
|---|---|
| **목적** | 페이즈 내 단일 작업 단위에 대한 실행 가능한 플랜. YAML 프론트매터(웨이브, 의존성, 파일, 요구사항, `must_haves`), 목표, 컨텍스트 참조, `<read_first>`, `<action>`, `<verify>`, `<acceptance_criteria>` 필드가 있는 XML 구조의 태스크, 검증 기준을 포함합니다. |
| **생성자** | `/gsd-plan-phase` (via `gsd-planner` 에이전트). 플랜당 하나의 파일 — 예: `03-02-PLAN.md`는 Phase 3, Plan 2. |
| **소비자** | `/gsd-execute-phase` (실행기 에이전트가 플랜을 읽고 태스크를 실행); `gsd-plan-checker` (실행 전 품질 검토); `gsd-verifier` (실행 후 검증을 위해 `must_haves`를 읽음). |
| **생성자** | `/msd-plan-phase` (via `msd-planner` 에이전트). 플랜당 하나의 파일 — 예: `03-02-PLAN.md`는 Phase 3, Plan 2. |
| **소비자** | `/msd-execute-phase` (실행기 에이전트가 플랜을 읽고 태스크를 실행); `msd-plan-checker` (실행 전 품질 검토); `msd-verifier` (실행 후 검증을 위해 `must_haves`를 읽음). |
전체 필드 참조는 [PLAN.md 스키마](plan-md.md)를 참조하세요.
@@ -185,30 +185,30 @@
|---|---|
| **목적** | 플랜이 완료된 후 기록된 실행 기록. 빌드된 내용, 플랜과의 편차, 인수 기준에 대한 자가 점검, 페이즈의 의존성 그래프를 문서화합니다. |
| **생성자** | `execute-phase` 실행기 에이전트 (각 플랜 실행 종료 시 기록). |
| **소비자** | `/gsd-progress` (페이즈 상태); `gsd-planner` (후속 플랜이 이전 플랜 출력에 대한 실질적인 의존성이 있는 경우); `milestone-summary`. |
| **소비자** | `/msd-progress` (페이즈 상태); `msd-planner` (후속 플랜이 이전 플랜 출력에 대한 실질적인 의존성이 있는 경우); `milestone-summary`. |
### `<NN>-VERIFICATION.md`
| | |
|---|---|
| **목적** | 페이즈 목표 검증 보고서. 실행 후 모든 플랜의 `must_haves.truths`, `must_haves.artifacts`, `must_haves.key_links`를 실제 코드베이스에 대해 확인합니다. `status: passed | gaps_found | human_needed`를 기록합니다. |
| **생성자** | `/gsd-verify-work` (또는 `/gsd-execute-phase` 내의 verify 단계). |
| **소비자** | `plan-phase` 종료된 페이즈 게이트(`status: passed`인 VERIFICATION.md는 페이즈를 `Complete`로 표시하고 `--force` 없이 재플래닝을 차단함); `/gsd-progress`; 인간 검토. |
| **생성자** | `/msd-verify-work` (또는 `/msd-execute-phase` 내의 verify 단계). |
| **소비자** | `plan-phase` 종료된 페이즈 게이트(`status: passed`인 VERIFICATION.md는 페이즈를 `Complete`로 표시하고 `--force` 없이 재플래닝을 차단함); `/msd-progress`; 인간 검토. |
### `<NN>-UAT.md`
| | |
|---|---|
| **목적** | 지속적인 UAT 세션 추적. 라이브 UAT 세션 전반에 걸쳐 각 테스트 케이스, 예상 관찰 가능한 동작, 결과, 개발자 응답을 기록합니다. YAML 프론트매터(`status`, `phase`, `source`, 타임스탬프)를 가집니다. |
| **생성자** | `/gsd-audit-uat` (대화형 UAT 세션). |
| **소비자** | `/gsd-audit-uat` (이전 UAT 세션 재개). |
| **생성자** | `/msd-audit-uat` (대화형 UAT 세션). |
| **소비자** | `/msd-audit-uat` (이전 UAT 세션 재개). |
### `.continue-here.md`
| | |
|---|---|
| **목적** | 페이즈 작업이 일시 정지될 때 기록되는 사람이 읽을 수 있는 재개 지침. 재개 에이전트를 위한 컨텍스트를 포함합니다: 중요한 안티패턴, 차단 이슈, 필수 읽기, 재개를 위한 정확한 명령. |
| **생성자** | `/gsd-pause-work`. |
| **생성자** | `/msd-pause-work`. |
| **소비자** | 페이즈에서 시작하는 모든 워크플로 — `discuss-phase`와 `plan-phase` 모두 진입 시 이 파일을 확인하고, 진행하기 전에 에이전트가 `blocking` 안티패턴을 이해했음을 입증하도록 요구합니다. |
---

42
docs/ko-KR/reference/state-md.md
View File

@@ -1,14 +1,14 @@
# STATE.md 스키마 참조
`STATE.md`는 GSD Core의 살아있는 프로젝트 메모리 파일입니다 — 프로젝트의 현재 상태, 최근 작업 내역, 그리고 다음에 실행할 명령을 기록하는 단일 Markdown 문서입니다. 이 페이지는 해당 파일의 구조를 설명합니다. [문서 인덱스](../../README.md)를 참조하세요.
`STATE.md`는 MSD Core의 살아있는 프로젝트 메모리 파일입니다 — 프로젝트의 현재 상태, 최근 작업 내역, 그리고 다음에 실행할 명령을 기록하는 단일 Markdown 문서입니다. 이 페이지는 해당 파일의 구조를 설명합니다. [문서 인덱스](../../README.md)를 참조하세요.
---
## 개요
GSD Core가 관리하는 모든 프로젝트는 `.planning/STATE.md`에 하나의 `STATE.md`를 유지합니다. 이 파일은 모든 워크플로 시작 시 읽히고 중요한 작업 이후에 기록됩니다. 파일은 다음 두 부분으로 구성됩니다:
MSD Core가 관리하는 모든 프로젝트는 `.planning/STATE.md`에 하나의 `STATE.md`를 유지합니다. 이 파일은 모든 워크플로 시작 시 읽히고 중요한 작업 이후에 기록됩니다. 파일은 다음 두 부분으로 구성됩니다:
- **YAML 프론트매터** — 상태 표시줄 훅(`parseStateMd`)과 `gsd-tools state` 명령이 사용하는 기계가 읽을 수 있는 필드.
- **YAML 프론트매터** — 상태 표시줄 훅(`parseStateMd`)과 `msd-tools state` 명령이 사용하는 기계가 읽을 수 있는 필드.
- **Markdown 본문** — 현재 위치, 누적된 맥락, 세션 연속성, 성능 지표를 다루는 사람이 읽을 수 있는 섹션.
파일은 의도적으로 작게 유지됩니다(목표: 100줄 미만). 이 파일은 프로젝트 상태의 요약이며 아카이브가 아닙니다.
@@ -17,13 +17,13 @@ GSD Core가 관리하는 모든 프로젝트는 `.planning/STATE.md`에 하나
## YAML 프론트매터
프론트매터는 파일 맨 처음의 `---` 구분자 사이에 위치합니다. `gsd_state_version`과 `status`를 제외한 모든 필드는 선택 사항이며, 데이터를 아직 사용할 수 없는 경우 필드가 없을 수 있습니다.
프론트매터는 파일 맨 처음의 `---` 구분자 사이에 위치합니다. `msd_state_version`과 `status`를 제외한 모든 필드는 선택 사항이며, 데이터를 아직 사용할 수 없는 경우 필드가 없을 수 있습니다.
### 주석이 달린 예시
```yaml
---
gsd_state_version: '1.0'
msd_state_version: '1.0'
milestone: v2.0
milestone_name: Code Quality
status: executing
@@ -56,7 +56,7 @@ paused_at: null
| 필드 | 타입 | 채워지는 시점 | 목적 |
|---|---|---|---|
| `gsd_state_version` | string (`'1.0'`) | 항상 | 스키마 버전. `syncStateFrontmatter`에 의한 첫 번째 `state.*` 호출 시 기록됩니다. |
| `msd_state_version` | string (`'1.0'`) | 항상 | 스키마 버전. `syncStateFrontmatter`에 의한 첫 번째 `state.*` 호출 시 기록됩니다. |
| `milestone` | string (예: `v2.0`) | 마일스톤이 구성된 경우 | 프로젝트 설정에서 읽어온 현재 마일스톤 버전. |
| `milestone_name` | string | 마일스톤이 구성된 경우 | 사람이 읽을 수 있는 마일스톤 레이블 (예: `Code Quality`). |
| `status` | string | 항상 | 현재 생명주기 단계. `normalizeStateStatus()`에 의해 정규화됩니다 — [상태 값](#상태-값)을 참조하세요. |
@@ -83,7 +83,7 @@ paused_at: null
| 필드 | 카디널리티 |
|---|---|
| `gsd_state_version` | one |
| `msd_state_version` | one |
| `milestone` | optional |
| `milestone_name` | optional |
| `current_phase` | optional |
@@ -105,7 +105,7 @@ paused_at: null
### 상태 값
`gsd-core/bin/lib/state-document.cjs`의 `normalizeStateStatus()`는 본문의 원시 텍스트를 다음 표준 값으로 매핑합니다:
`msd-core/bin/lib/state-document.cjs`의 `normalizeStateStatus()`는 본문의 원시 텍스트를 다음 표준 값으로 매핑합니다:
| 표준 값 | 매칭되는 텍스트 (대소문자 무관) |
|---|---|
@@ -121,10 +121,10 @@ paused_at: null
| 명령 | 실행 중 `status` |
|---|---|
| `/gsd-discuss-phase` | `discussing` |
| `/gsd-plan-phase` | `planning` |
| `/gsd-execute-phase` | `executing` |
| `/gsd-verify-work` | `verifying` |
| `/msd-discuss-phase` | `discussing` |
| `/msd-plan-phase` | `planning` |
| `/msd-execute-phase` | `executing` |
| `/msd-verify-work` | `verifying` |
<!-- STATE-MD-SCHEMA:START:status-lifecycle — generated by scripts/gen-state-md-docs.cjs from src/state-md-schema.cts; do not edit by hand -->
### 상태 라이프사이클 (ADR-2207)
@@ -145,7 +145,7 @@ Phase-completion verbs never write `Milestone complete` (the overloaded bare val
## 상태 표시줄 렌더링 장면
`hooks/gsd-statusline.js`의 `formatGsdState()`는 파싱된 프론트매터를 읽고 **첫 번째로 일치하는 장면**을 출력합니다. 새로운 생명주기 필드가 적용되지 않으면 렌더링은 v1.38.x와 바이트 단위로 동일한 원래 형식으로 폴백됩니다.
`hooks/msd-statusline.js`의 `formatMsdState()`는 파싱된 프론트매터를 읽고 **첫 번째로 일치하는 장면**을 출력합니다. 새로운 생명주기 필드가 적용되지 않으면 렌더링은 v1.38.x와 바이트 단위로 동일한 원래 형식으로 폴백됩니다.
| 장면 | 트리거 | 표시 예시 |
|---|---|---|
@@ -154,7 +154,7 @@ Phase-completion verbs never write `Milestone complete` (the overloaded bare val
| **3. 마일스톤 완료** | `percent`가 `100`이거나 `completed_phases == total_phases`인 경우 | `v2.0 [██████████] 100% · milestone complete` |
| **4. 기본 폴백** | 위 중 해당 없음 | `v1.9 Code Quality · executing · ph 1/5` (기존 형식) |
**장면 우선순위:** `active_phase`와 `next_action`이 모두 채워진 경우 장면 1이 우선합니다 — 오케스트레이터가 실행 중이므로 "다음 권장 사항"은 오해의 소지가 있습니다. 이 우선순위는 `formatGsdState()`의 확인 순서로 강제되며 `tests/gsd-statusline.test.cjs`의 `"scene priority"` 스위트에서 테스트됩니다.
**장면 우선순위:** `active_phase`와 `next_action`이 모두 채워진 경우 장면 1이 우선합니다 — 오케스트레이터가 실행 중이므로 "다음 권장 사항"은 오해의 소지가 있습니다. 이 우선순위는 `formatMsdState()`의 확인 순서로 강제되며 `tests/msd-statusline.test.cjs`의 `"scene priority"` 스위트에서 테스트됩니다.
진행 막대(`[██░░░░░░░░] 20%`)는 프론트매터에 `progress.percent`가 있을 때만 마일스톤 세그먼트에 추가됩니다. 없으면 막대가 표시되지 않습니다.
@@ -162,7 +162,7 @@ Phase-completion verbs never write `Milestone complete` (the overloaded bare val
## 프론트매터 파싱 제약 사항
상태 표시줄 훅은 정규식 기반 파싱을 사용합니다(YAML 라이브러리 없음). 따라서 다음 제약 사항이 적용됩니다. 이는 `tests/gsd-statusline.test.cjs`에서 테스트됩니다.
상태 표시줄 훅은 정규식 기반 파싱을 사용합니다(YAML 라이브러리 없음). 따라서 다음 제약 사항이 적용됩니다. 이는 `tests/msd-statusline.test.cjs`에서 테스트됩니다.
1. **프론트매터는 파일의 맨 첫 번째 문자에서 시작해야 합니다.** 주석을 포함한 어떤 것이든 여는 `---` 위에 있으면 매칭이 무효화됩니다. 여는 `---` 줄은 정확히 그것이어야 하며, 후행 공백이 없어야 합니다.
@@ -176,7 +176,7 @@ Phase-completion verbs never write `Milestone complete` (the overloaded bare val
## Markdown 본문 섹션
본문(닫는 `---` 이후의 모든 것)은 `gsd-core/templates/state.md`의 템플릿을 따릅니다. 표준 섹션은 다음과 같습니다:
본문(닫는 `---` 이후의 모든 것)은 `msd-core/templates/state.md`의 템플릿을 따릅니다. 표준 섹션은 다음과 같습니다:
### Project Reference
@@ -200,7 +200,7 @@ Phase-completion verbs never write `Milestone complete` (the overloaded bare val
진행 *이력*은 여기에 속하지 않습니다. 이는 계속 늘어나도록 설계된 섹션인 아래의 [`### Performance Metrics`](#performance-metrics)에 누적됩니다.
이 섹션의 `Status:` 및 `Last activity:` 필드는 기존 값이 알려진 템플릿 기본값인 경우 GSD 핸들러에 의해 업데이트됩니다(크누스 불변량: 실행기가 작성한 값은 보존됩니다). 알려진 핸들러 기본값의 전체 목록은 `gsd-core/bin/lib/state-document.cjs`의 `KNOWN_TEMPLATE_DEFAULTS`에 있습니다.
이 섹션의 `Status:` 및 `Last activity:` 필드는 기존 값이 알려진 템플릿 기본값인 경우 MSD 핸들러에 의해 업데이트됩니다(크누스 불변량: 실행기가 작성한 값은 보존됩니다). 알려진 핸들러 기본값의 전체 목록은 `msd-core/bin/lib/state-document.cjs`의 `KNOWN_TEMPLATE_DEFAULTS`에 있습니다.
### Performance Metrics
@@ -213,11 +213,11 @@ Phase-completion verbs never write `Milestone complete` (the overloaded bare val
### Accumulated Context
**Decisions** — 현재 작업에 영향을 미치는 최근 결정 사항 요약(전체 로그는 `PROJECT.md`에 있음). `gsd-tools state add-decision`을 통해 추가됩니다.
**Decisions** — 현재 작업에 영향을 미치는 최근 결정 사항 요약(전체 로그는 `PROJECT.md`에 있음). `msd-tools state add-decision`을 통해 추가됩니다.
**Pending Todos** — 개수 및 `.planning/todos/pending/`에 대한 참조. `/gsd-capture`를 통해 캡처됩니다.
**Pending Todos** — 개수 및 `.planning/todos/pending/`에 대한 참조. `/msd-capture`를 통해 캡처됩니다.
**Blockers/Concerns** — 미래 작업에 영향을 미치는 문제, 발생한 페이즈 접두사 포함. `gsd-tools state add-blocker`를 통해 추가되고, `gsd-tools state resolve-blocker`를 통해 해결됩니다.
**Blockers/Concerns** — 미래 작업에 영향을 미치는 문제, 발생한 페이즈 접두사 포함. `msd-tools state add-blocker`를 통해 추가되고, `msd-tools state resolve-blocker`를 통해 해결됩니다.
### Session Continuity
@@ -236,7 +236,7 @@ Phase-completion verbs never write `Milestone complete` (the overloaded bare val
- 생명주기 필드 추가는 선택 사항입니다 — 렌더러는 필드가 없을 때 우아하게 저하됩니다.
- 진행 막대는 `progress` 블록이 있어도 선택 사항입니다: `progress.percent`만 막대를 트리거하고, `total_phases`와 `completed_phases`만으로는 트리거되지 않습니다.
`tests/gsd-statusline.test.cjs`의 `formatGsdState #2833 backward compatibility` 테스트 스위트는 이 보장을 고정합니다. 레거시 `STATE.md` 렌더링을 깨는 변경 사항은 스위트에서 실패합니다.
`tests/msd-statusline.test.cjs`의 `formatMsdState #2833 backward compatibility` 테스트 스위트는 이 보장을 고정합니다. 레거시 `STATE.md` 렌더링을 깨는 변경 사항은 스위트에서 실패합니다.
---

90
docs/ko-KR/superpowers/plans/2026-03-18-materialize-new-project-config.md
View File

@@ -2,11 +2,11 @@
> **에이전트 작업자를 위한 안내:** 필수 하위 기술: superpowers:subagent-driven-development(권장) 또는 superpowers:executing-plans를 사용하여 이 계획을 작업 단위로 구현하세요. 단계는 체크박스(`- [ ]`) 형식으로 진행 상황을 추적합니다.
**목표:** `/gsd-new-project`가 `.planning/config.json`을 생성할 때, 파일에 사용자가 선택한 6개 키만이 아닌 모든 유효한 기본값이 포함되도록 하여 개발자가 소스 코드를 읽지 않고도 모든 설정을 확인할 수 있게 합니다.
**목표:** `/msd-new-project`가 `.planning/config.json`을 생성할 때, 파일에 사용자가 선택한 6개 키만이 아닌 모든 유효한 기본값이 포함되도록 하여 개발자가 소스 코드를 읽지 않고도 모든 설정을 확인할 수 있게 합니다.
**아키텍처:** 새 프로젝트의 전체 config에 대한 단일 진실 공급원으로서 `config.cjs`에 단일 JS 함수 `buildNewProjectConfig(cwd, userChoices)`를 추가합니다. CLI 명령어 `config-new-project`로 노출합니다. 부분적인 JSON을 인라인으로 작성하는 대신 이 명령어를 호출하도록 `new-project.md` 워크플로우를 업데이트합니다.
**기술 스택:** Node.js/CommonJS, 기존 gsd-tools CLI, 테스트에는 `node:test`.
**기술 스택:** Node.js/CommonJS, 기존 msd-tools CLI, 테스트에는 `node:test`.
---
@@ -27,8 +27,8 @@
- `search_gitignored: false`
- `brave_search: false` (또는 환경 감지 시 `true`)
- `git.branching_strategy: "none"`
- `git.phase_branch_template: "gsd/phase-{phase}-{slug}"`
- `git.milestone_branch_template: "gsd/{milestone}-{slug}"`
- `git.phase_branch_template: "msd/phase-{phase}-{slug}"`
- `git.milestone_branch_template: "msd/{milestone}-{slug}"`
처음부터 존재해야 하는 전체 config:
@@ -43,8 +43,8 @@
"brave_search": false,
"git": {
"branching_strategy": "none",
"phase_branch_template": "gsd/phase-{phase}-{slug}",
"milestone_branch_template": "gsd/{milestone}-{slug}"
"phase_branch_template": "msd/phase-{phase}-{slug}",
"milestone_branch_template": "msd/{milestone}-{slug}"
},
"workflow": {
"research": true,
@@ -62,7 +62,7 @@
| 파일 | 액션 | 목적 |
|------|--------|---------|
| `get-shit-done/bin/lib/config.cjs` | 수정 | `buildNewProjectConfig()` + `cmdConfigNewProject()` 추가 |
| `get-shit-done/bin/gsd-tools.cjs` | 수정 | `config-new-project` case 등록 + usage 문자열 업데이트 |
| `get-shit-done/bin/msd-tools.cjs` | 수정 | `config-new-project` case 등록 + usage 문자열 업데이트 |
| `get-shit-done/workflows/new-project.md` | 수정 | Steps 2a + 5: 인라인 JSON 작성을 CLI 호출로 교체 |
| `tests/config.test.cjs` | 수정 | `config-new-project` 테스트 스위트 추가 |
@@ -101,7 +101,7 @@ describe('config-new-project command', () => {
model_profile: 'balanced',
workflow: { research: true, plan_check: true, verifier: true, nyquist_validation: true },
});
const result = runGsdTools(['config-new-project', choices], tmpDir);
const result = runMsdTools(['config-new-project', choices], tmpDir);
assert.ok(result.success, `Command failed: ${result.error}`);
const config = readConfig(tmpDir);
@@ -120,8 +120,8 @@ describe('config-new-project command', () => {
// git 섹션에 세 가지 키가 모두 존재하는지 확인
assert.ok(config.git && typeof config.git === 'object', 'git section should exist');
assert.strictEqual(config.git.branching_strategy, 'none');
assert.strictEqual(config.git.phase_branch_template, 'gsd/phase-{phase}-{slug}');
assert.strictEqual(config.git.milestone_branch_template, 'gsd/{milestone}-{slug}');
assert.strictEqual(config.git.phase_branch_template, 'msd/phase-{phase}-{slug}');
assert.strictEqual(config.git.milestone_branch_template, 'msd/{milestone}-{slug}');
// workflow 섹션에 네 가지 키가 모두 존재하는지 확인
assert.ok(config.workflow && typeof config.workflow === 'object', 'workflow section should exist');
@@ -140,7 +140,7 @@ describe('config-new-project command', () => {
model_profile: 'quality',
workflow: { research: false, plan_check: false, verifier: true, nyquist_validation: false },
});
const result = runGsdTools(['config-new-project', choices], tmpDir);
const result = runMsdTools(['config-new-project', choices], tmpDir);
assert.ok(result.success, `Command failed: ${result.error}`);
const config = readConfig(tmpDir);
@@ -159,7 +159,7 @@ describe('config-new-project command', () => {
});
test('works with empty choices — all defaults materialized', () => {
const result = runGsdTools(['config-new-project', '{}'], tmpDir);
const result = runMsdTools(['config-new-project', '{}'], tmpDir);
assert.ok(result.success, `Command failed: ${result.error}`);
const config = readConfig(tmpDir);
@@ -176,13 +176,13 @@ describe('config-new-project command', () => {
test('is idempotent — returns already_exists if config exists', () => {
// 첫 번째 호출: 생성
const choices = JSON.stringify({ mode: 'yolo', granularity: 'fine' });
const first = runGsdTools(['config-new-project', choices], tmpDir);
const first = runMsdTools(['config-new-project', choices], tmpDir);
assert.ok(first.success, `First call failed: ${first.error}`);
const firstOut = JSON.parse(first.output);
assert.strictEqual(firstOut.created, true);
// 두 번째 호출: 멱등성
const second = runGsdTools(['config-new-project', choices], tmpDir);
const second = runMsdTools(['config-new-project', choices], tmpDir);
assert.ok(second.success, `Second call failed: ${second.error}`);
const secondOut = JSON.parse(second.output);
assert.strictEqual(secondOut.created, false);
@@ -200,7 +200,7 @@ describe('config-new-project command', () => {
granularity: 'standard',
workflow: { research: true, plan_check: true, verifier: true, nyquist_validation: true, auto_advance: true },
});
const result = runGsdTools(['config-new-project', choices], tmpDir);
const result = runMsdTools(['config-new-project', choices], tmpDir);
assert.ok(result.success, `Command failed: ${result.error}`);
const config = readConfig(tmpDir);
@@ -208,14 +208,14 @@ describe('config-new-project command', () => {
});
test('rejects invalid JSON choices', () => {
const result = runGsdTools(['config-new-project', '{not-json}'], tmpDir);
const result = runMsdTools(['config-new-project', '{not-json}'], tmpDir);
assert.strictEqual(result.success, false);
assert.ok(result.error.includes('Invalid JSON'), `Expected "Invalid JSON" in: ${result.error}`);
});
test('output JSON has created:true on success', () => {
const choices = JSON.stringify({ mode: 'interactive', granularity: 'standard' });
const result = runGsdTools(['config-new-project', choices], tmpDir);
const result = runMsdTools(['config-new-project', choices], tmpDir);
assert.ok(result.success, `Command failed: ${result.error}`);
const out = JSON.parse(result.output);
assert.strictEqual(out.created, true);
@@ -243,7 +243,7 @@ node --test tests/config.test.cjs 2>&1 | grep -E "config-new-project|FAIL|Error"
*
* 다음 우선순위 순서로 병합합니다:
* 1. 하드코딩된 기본값
* 2. ~/.gsd/defaults.json의 사용자 수준 기본값(있는 경우)
* 2. ~/.msd/defaults.json의 사용자 수준 기본값(있는 경우)
* 3. userChoices (new-project 중 사용자가 명시적으로 선택한 설정)
*
* 일반 객체를 반환합니다 — 파일을 직접 작성하지 않습니다.
@@ -253,11 +253,11 @@ function buildNewProjectConfig(cwd, userChoices) {
const homedir = require('os').homedir();
// Brave Search API 키 가용성 감지
const braveKeyFile = path.join(homedir, '.gsd', 'brave_api_key');
const braveKeyFile = path.join(homedir, '.msd', 'brave_api_key');
const hasBraveSearch = !!(process.env.BRAVE_API_KEY || fs.existsSync(braveKeyFile));
// 사용 가능한 경우 ~/.gsd/defaults.json에서 사용자 수준 기본값 로드
const globalDefaultsPath = path.join(homedir, '.gsd', 'defaults.json');
// 사용 가능한 경우 ~/.msd/defaults.json에서 사용자 수준 기본값 로드
const globalDefaultsPath = path.join(homedir, '.msd', 'defaults.json');
let userDefaults = {};
try {
if (fs.existsSync(globalDefaultsPath)) {
@@ -284,8 +284,8 @@ function buildNewProjectConfig(cwd, userChoices) {
brave_search: hasBraveSearch,
git: {
branching_strategy: 'none',
phase_branch_template: 'gsd/phase-{phase}-{slug}',
milestone_branch_template: 'gsd/{milestone}-{slug}',
phase_branch_template: 'msd/phase-{phase}-{slug}',
milestone_branch_template: 'msd/{milestone}-{slug}',
},
workflow: {
research: true,
@@ -316,8 +316,8 @@ function buildNewProjectConfig(cwd, userChoices) {
/**
* 명령어: 새 프로젝트를 위한 완전히 구체화된 .planning/config.json을 생성합니다.
*
* 사용자가 선택한 설정을 JSON 문자열로 받습니다(/gsd-new-project 중 명시적으로
* 구성한 키들). 나머지 키들은 하드코딩된 기본값과 선택적 ~/.gsd/defaults.json에서 채워집니다.
* 사용자가 선택한 설정을 JSON 문자열로 받습니다(/msd-new-project 중 명시적으로
* 구성한 키들). 나머지 키들은 하드코딩된 기본값과 선택적 ~/.msd/defaults.json에서 채워집니다.
*
* 멱등성: config.json이 이미 존재하면 { created: false }를 반환합니다.
*/
@@ -382,13 +382,13 @@ git commit -m "feat: add config-new-project command for full config materializat
---
## 작업 2: gsd-tools.cjs에 `config-new-project` 등록
## 작업 2: msd-tools.cjs에 `config-new-project` 등록
**파일.**
- 수정: `get-shit-done/bin/gsd-tools.cjs`
- 수정: `get-shit-done/bin/msd-tools.cjs`
- [ ] **Step 2.1: gsd-tools.cjs의 switch에 case 추가**
- [ ] **Step 2.1: msd-tools.cjs의 switch에 case 추가**
`config-get` case 뒤(약 401번째 줄)에 다음을 추가하세요:
@@ -408,12 +408,12 @@ git commit -m "feat: add config-new-project command for full config materializat
```bash
cd /Users/diego/Dev/get-shit-done
node get-shit-done/bin/gsd-tools.cjs config-new-project '{"mode":"interactive","granularity":"standard"}' --cwd /tmp/gsd-smoke-$(date +%s)
node get-shit-done/bin/msd-tools.cjs config-new-project '{"mode":"interactive","granularity":"standard"}' --cwd /tmp/msd-smoke-$(date +%s)
```
예상 결과: `{"created":true,"path":".planning/config.json"}` (또는 유사한 형태)가 출력됩니다.
정리: `rm -rf /tmp/gsd-smoke-*`
정리: `rm -rf /tmp/msd-smoke-*`
- [ ] **Step 2.3: 전체 테스트 스위트 실행**
@@ -428,8 +428,8 @@ node --test tests/config.test.cjs 2>&1 | tail -10
```bash
cd /Users/diego/Dev/get-shit-done
git add get-shit-done/bin/gsd-tools.cjs
git commit -m "feat: register config-new-project in gsd-tools CLI router"
git add get-shit-done/bin/msd-tools.cjs
git commit -m "feat: register config-new-project in msd-tools CLI router"
```
---
@@ -469,7 +469,7 @@ Create `.planning/config.json` using the CLI (fills in all defaults automaticall
```bash
mkdir -p .planning
node "$HOME/.claude/get-shit-done/bin/gsd-tools.cjs" config-new-project "$(cat <<'CHOICES'
node "$HOME/.claude/get-shit-done/bin/msd-tools.cjs" config-new-project "$(cat <<'CHOICES'
{
"mode": "yolo",
"granularity": "[selected: coarse|standard|fine]",
@@ -515,7 +515,7 @@ Create `.planning/config.json` using the CLI (fills in all defaults automaticall
```bash
mkdir -p .planning
node "$HOME/.claude/get-shit-done/bin/gsd-tools.cjs" config-new-project "$(cat <<'CHOICES'
node "$HOME/.claude/get-shit-done/bin/msd-tools.cjs" config-new-project "$(cat <<'CHOICES'
{
"mode": "[selected: yolo|interactive]",
"granularity": "[selected: coarse|standard|fine]",
@@ -577,10 +577,10 @@ TMP=$(mktemp -d)
cd "$TMP"
# Step 1 시뮬레이션: init new-project가 반환하는 내용
node /Users/diego/Dev/get-shit-done/get-shit-done/bin/gsd-tools.cjs init new-project --cwd "$TMP"
node /Users/diego/Dev/get-shit-done/get-shit-done/bin/msd-tools.cjs init new-project --cwd "$TMP"
# Step 5 시뮬레이션: 전체 config 생성
node /Users/diego/Dev/get-shit-done/get-shit-done/bin/gsd-tools.cjs config-new-project '{
node /Users/diego/Dev/get-shit-done/get-shit-done/bin/msd-tools.cjs config-new-project '{
"mode": "interactive",
"granularity": "standard",
"parallelization": true,
@@ -610,11 +610,11 @@ rm -rf "$TMP"
TMP=$(mktemp -d)
CHOICES='{"mode":"yolo","granularity":"coarse"}'
node /Users/diego/Dev/get-shit-done/get-shit-done/bin/gsd-tools.cjs config-new-project "$CHOICES" --cwd "$TMP"
node /Users/diego/Dev/get-shit-done/get-shit-done/bin/msd-tools.cjs config-new-project "$CHOICES" --cwd "$TMP"
FIRST=$(cat "$TMP/.planning/config.json")
# 두 번째 호출은 no-op이어야 함
node /Users/diego/Dev/get-shit-done/get-shit-done/bin/gsd-tools.cjs config-new-project "$CHOICES" --cwd "$TMP"
node /Users/diego/Dev/get-shit-done/get-shit-done/bin/msd-tools.cjs config-new-project "$CHOICES" --cwd "$TMP"
SECOND=$(cat "$TMP/.planning/config.json")
[ "$FIRST" = "$SECOND" ] && echo "IDEMPOTENT: OK" || echo "IDEMPOTENT: FAIL"
@@ -627,17 +627,17 @@ rm -rf "$TMP"
```bash
TMP=$(mktemp -d)
node /Users/diego/Dev/get-shit-done/get-shit-done/bin/gsd-tools.cjs config-new-project '{
node /Users/diego/Dev/get-shit-done/get-shit-done/bin/msd-tools.cjs config-new-project '{
"mode":"yolo","granularity":"standard","parallelization":true,"commit_docs":true,
"model_profile":"balanced",
"workflow":{"research":true,"plan_check":false,"verifier":true,"nyquist_validation":true}
}' --cwd "$TMP"
# loadConfig는 plan_check(중첩된 workflow.plan_check로)를 올바르게 읽어야 함
node /Users/diego/Dev/get-shit-done/get-shit-done/bin/gsd-tools.cjs config-get workflow.plan_check --cwd "$TMP"
node /Users/diego/Dev/get-shit-done/get-shit-done/bin/msd-tools.cjs config-get workflow.plan_check --cwd "$TMP"
# 예상: false
node /Users/diego/Dev/get-shit-done/get-shit-done/bin/gsd-tools.cjs config-get git.branching_strategy --cwd "$TMP"
node /Users/diego/Dev/get-shit-done/get-shit-done/bin/msd-tools.cjs config-get git.branching_strategy --cwd "$TMP"
# 예상: "none"
rm -rf "$TMP"
@@ -660,7 +660,7 @@ node --test tests/ 2>&1 | grep -E "pass|fail|error" | tail -5
feat: materialize all config defaults at new-project initialization
**문제:**
`/gsd-new-project`는 온보딩 중 사용자가 명시적으로 선택한 6개 키만으로
`/msd-new-project`는 온보딩 중 사용자가 명시적으로 선택한 6개 키만으로
`.planning/config.json`을 생성합니다. 5개의 추가 키
(`search_gitignored`, `brave_search`, `git.branching_strategy`,
`git.phase_branch_template`, `git.milestone_branch_template`)는
@@ -669,12 +669,12 @@ feat: materialize all config defaults at new-project initialization
이로 인해 두 가지 문제가 발생합니다:
1. **발견성**: 소스 코드를 읽지 않고는 `git.branching_strategy`를
확인하거나 이해할 수 없습니다 — config에 표시되지 않습니다.
2. **암묵적 확장**: `/gsd-settings` 또는 `config-set`이 처음으로 config에
2. **암묵적 확장**: `/msd-settings` 또는 `config-set`이 처음으로 config에
기록할 때도 해당 키들이 추가되지 않습니다. config는 유효한 구성의
일부만 반영합니다.
**해결책:**
`gsd-tools.cjs`에 `config-new-project` CLI 명령어를 추가합니다. 이 명령어는:
`msd-tools.cjs`에 `config-new-project` CLI 명령어를 추가합니다. 이 명령어는:
- 사용자가 선택한 값을 JSON으로 받습니다.
- 모든 런타임 기본값(환경 감지 `brave_search` 포함)과 병합합니다.
- 완전히 구체화된 config를 한 번에 작성합니다.
@@ -694,6 +694,6 @@ feat: materialize all config defaults at new-project initialization
**이것이 발견성을 개선하는 이유:**
처음으로 `.planning/config.json`을 여는 개발자는 이제
`git.branching_strategy: "none"`을 확인하고 GSD 소스를 읽지 않고도
`git.branching_strategy: "none"`을 확인하고 MSD 소스를 읽지 않고도
브랜칭이 가능하고 구성 가능하다는 것을 즉시 이해할 수 있습니다.
```

56
docs/ko-KR/superpowers/specs/2026-03-20-multi-project-workspaces-design.md
View File

@@ -1,4 +1,4 @@
# 멀티 프로젝트 워크스페이스 (`/gsd-workspace --new`)
# 멀티 프로젝트 워크스페이스 (`/msd-workspace --new`)
**Issue:** #1241
**Date:** 2026-03-20
@@ -6,7 +6,7 @@
## 문제
GSD는 작업 디렉토리당 하나의 `.planning/` 디렉토리에 종속되어 있습니다. 20개 이상의 하위 저장소가 있는 모노저장소 스타일 설정에서 여러 독립 프로젝트를 사용하는 사용자나 동일한 저장소에서 피처 브랜치 격리가 필요한 사용자는 수동 클론 및 상태 관리 없이 병렬 GSD 세션을 실행할 수 없습니다.
MSD는 작업 디렉토리당 하나의 `.planning/` 디렉토리에 종속되어 있습니다. 20개 이상의 하위 저장소가 있는 모노저장소 스타일 설정에서 여러 독립 프로젝트를 사용하는 사용자나 동일한 저장소에서 피처 브랜치 격리가 필요한 사용자는 수동 클론 및 상태 관리 없이 병렬 MSD 세션을 실행할 수 없습니다.
## 해결책
@@ -18,13 +18,13 @@ GSD는 작업 디렉토리당 하나의 `.planning/` 디렉토리에 종속되
## 명령어
### `/gsd-workspace --new`
### `/msd-workspace --new`
저장소 복사본과 자체 `.planning/`이 있는 워크스페이스 디렉토리를 생성합니다.
```bash
/gsd-workspace --new --name feature-b --repos hr-ui,ZeymoAPI --path ~/workspaces/feature-b
/gsd-workspace --new --name feature-b --repos . --strategy worktree # 동일 저장소 격리
/msd-workspace --new --name feature-b --repos hr-ui,ZeymoAPI --path ~/workspaces/feature-b
/msd-workspace --new --name feature-b --repos . --strategy worktree # 동일 저장소 격리
```
**인수.**
@@ -33,26 +33,26 @@ GSD는 작업 디렉토리당 하나의 `.planning/` 디렉토리에 종속되
|------|----------|---------|-------------|
| `--name` | 예 | — | 워크스페이스 이름 |
| `--repos` | 아니오 | 대화형 선택 | 쉼표로 구분된 저장소 경로 또는 이름 |
| `--path` | 아니오 | `~/gsd-workspaces/<name>` | 대상 디렉토리 |
| `--path` | 아니오 | `~/msd-workspaces/<name>` | 대상 디렉토리 |
| `--strategy` | 아니오 | `worktree` | `worktree`(가볍고 .git 공유) 또는 `clone`(완전히 독립) |
| `--branch` | 아니오 | `workspace/<name>` | 체크아웃할 브랜치 |
| `--auto` | 아니오 | false | 대화형 질문 건너뛰고 기본값 사용 |
### `/gsd-workspace --list`
### `/msd-workspace --list`
워크스페이스 매니페스트를 위해 `~/gsd-workspaces/*/WORKSPACE.md`를 스캔합니다. 이름, 경로, 저장소 수, GSD 상태(PROJECT.md 존재 여부, 현재 페이즈)가 있는 표를 표시합니다.
워크스페이스 매니페스트를 위해 `~/msd-workspaces/*/WORKSPACE.md`를 스캔합니다. 이름, 경로, 저장소 수, MSD 상태(PROJECT.md 존재 여부, 현재 페이즈)가 있는 표를 표시합니다.
### `/gsd-workspace --remove`
### `/msd-workspace --remove`
확인 후 워크스페이스 디렉토리를 제거합니다. worktree 전략의 경우 먼저 각 멤버 저장소에 대해 `git worktree remove`를 실행합니다. 저장소에 커밋되지 않은 변경사항이 있으면 거부합니다.
## 디렉토리 구조
```
~/gsd-workspaces/feature-b/ # 워크스페이스 루트
~/msd-workspaces/feature-b/ # 워크스페이스 루트
├── WORKSPACE.md # 매니페스트
├── .planning/ # 독립적인 GSD 계획 디렉토리
│ ├── PROJECT.md # (사용자가 /gsd-new-project를 실행한 경우)
├── .planning/ # 독립적인 MSD 계획 디렉토리
│ ├── PROJECT.md # (사용자가 /msd-new-project를 실행한 경우)
│ ├── STATE.md
│ └── config.json
├── hr-ui/ # 소스 저장소의 git worktree
@@ -64,7 +64,7 @@ GSD는 작업 디렉토리당 하나의 `.planning/` 디렉토리에 종속되
주요 속성.
- `.planning/`은 개별 저장소 내부가 아닌 워크스페이스 루트에 있습니다.
- 각 저장소는 워크스페이스 루트 아래의 피어 디렉토리입니다.
- `WORKSPACE.md`는 루트에 있는 유일한 GSD 전용 파일입니다(`.planning/` 외).
- `WORKSPACE.md`는 루트에 있는 유일한 MSD 전용 파일입니다(`.planning/` 외).
- `--strategy clone`의 경우 동일한 구조이지만 저장소는 전체 클론입니다.
## WORKSPACE.md 형식
@@ -89,7 +89,7 @@ Strategy: worktree
## 워크플로우
### `/gsd-workspace --new` 워크플로우 단계
### `/msd-workspace --new` 워크플로우 단계
1. **설정** — `init new-workspace` 호출, JSON 컨텍스트 파싱
2. **입력 수집** — `--name`/`--repos`/`--path`가 제공되지 않으면 대화형으로 질문합니다. 저장소의 경우 cwd의 하위 `.git` 디렉토리를 옵션으로 표시합니다.
@@ -100,7 +100,7 @@ Strategy: worktree
- Clone: `git clone <source> <workspace>/<repo-name>`
6. **WORKSPACE.md 작성** — 소스 경로, 전략, 브랜치가 있는 매니페스트
7. **.planning/ 초기화** — `mkdir -p <workspace>/.planning`
8. **/gsd-new-project 제안** — 새 워크스페이스에서 프로젝트 초기화를 실행할지 사용자에게 질문
8. **/msd-new-project 제안** — 새 워크스페이스에서 프로젝트 초기화를 실행할지 사용자에게 질문
9. **커밋** — commit_docs가 활성화된 경우 WORKSPACE.md의 원자적 커밋
10. **완료** — 워크스페이스 경로와 다음 단계 출력
@@ -111,7 +111,7 @@ Strategy: worktree
- 대상 경로가 이미 존재하는지 여부
- 소스 저장소에 커밋되지 않은 변경사항이 있는지 여부
- `git worktree`를 사용할 수 있는지 여부
- 기본 워크스페이스 기본 디렉토리(`~/gsd-workspaces/`)
- 기본 워크스페이스 기본 디렉토리(`~/msd-workspaces/`)
워크플로우 게이팅을 위한 플래그가 포함된 JSON을 반환합니다.
@@ -137,7 +137,7 @@ Strategy: worktree
### List-Workspaces 엣지 케이스
- **`~/gsd-workspaces/`가 존재하지 않음** — "No workspaces found"
- **`~/msd-workspaces/`가 존재하지 않음** — "No workspaces found"
- **WORKSPACE.md는 있지만 내부 저장소가 사라짐** — 워크스페이스를 표시하되 저장소를 누락으로 표시
## 테스팅
@@ -163,23 +163,23 @@ Strategy: worktree
| 컴포넌트 | 경로 |
|-----------|------|
| 명령어: new-workspace | `commands/gsd/new-workspace.md` |
| 명령어: list-workspaces | `commands/gsd/list-workspaces.md` |
| 명령어: remove-workspace | `commands/gsd/remove-workspace.md` |
| 워크플로우: new-workspace | `gsd-core/workflows/new-workspace.md` |
| 워크플로우: list-workspaces | `gsd-core/workflows/list-workspaces.md` |
| 워크플로우: remove-workspace | `gsd-core/workflows/remove-workspace.md` |
| Init 함수 | `gsd-core/bin/lib/init.cjs`(`cmdInitNewWorkspace`, `cmdInitListWorkspaces`, `cmdInitRemoveWorkspace` 추가) |
| 라우팅 | `gsd-core/bin/gsd-tools.cjs`(init switch에 case 추가) |
| 명령어: new-workspace | `commands/msd/new-workspace.md` |
| 명령어: list-workspaces | `commands/msd/list-workspaces.md` |
| 명령어: remove-workspace | `commands/msd/remove-workspace.md` |
| 워크플로우: new-workspace | `msd-core/workflows/new-workspace.md` |
| 워크플로우: list-workspaces | `msd-core/workflows/list-workspaces.md` |
| 워크플로우: remove-workspace | `msd-core/workflows/remove-workspace.md` |
| Init 함수 | `msd-core/bin/lib/init.cjs`(`cmdInitNewWorkspace`, `cmdInitListWorkspaces`, `cmdInitRemoveWorkspace` 추가) |
| 라우팅 | `msd-core/bin/msd-tools.cjs`(init switch에 case 추가) |
| 테스트 | `tests/workspace.test.cjs` |
## 설계 결정
| 결정 | 근거 |
|----------|-----------|
| 논리적 레지스트리 대신 물리적 디렉토리 | 파일 시스템이 진실 공급원 — GSD의 기존 cwd 기반 감지 패턴과 일치 |
| 논리적 레지스트리 대신 물리적 디렉토리 | 파일 시스템이 진실 공급원 — MSD의 기존 cwd 기반 감지 패턴과 일치 |
| 기본 전략으로 Worktree | 가볍고(.git 오브젝트 공유) 생성이 빠르며 정리가 쉬움 |
| 워크스페이스 루트에 `.planning/` | 개별 저장소 계획으로부터 완전한 격리를 제공. 각 워크스페이스는 독립적인 GSD 프로젝트 |
| 워크스페이스 루트에 `.planning/` | 개별 저장소 계획으로부터 완전한 격리를 제공. 각 워크스페이스는 독립적인 MSD 프로젝트 |
| 중앙 레지스트리 없음 | 상태 드리프트 방지. `list-workspaces`가 파일 시스템을 직접 스캔 |
| A의 특수 케이스로서 케이스 B | `--repos .`는 동일한 메커니즘을 재사용하므로 특별한 피처 브랜치 코드 불필요 |
| 기본 경로 `~/gsd-workspaces/<name>` | `list-workspaces`가 스캔할 예측 가능한 위치, 소스 저장소 외부에 워크스페이스 유지 |
| 기본 경로 `~/msd-workspaces/<name>` | `list-workspaces`가 스캔할 예측 가능한 위치, 소스 저장소 외부에 워크스페이스 유지 |

62
docs/ko-KR/tutorials/onboarding-an-existing-codebase.md
View File

@@ -1,12 +1,12 @@
# 기존 코드베이스 온보딩
이 튜토리얼에서는 이미 코드가 있는 저장소에 GSD Core를 도입합니다. 코드베이스를 매핑하고, *추가하려는* 내용을 설명하는 프로젝트를 생성한 다음, 작은 변경 사항에 대한 첫 번째 논의-계획 사이클을 실행합니다. 튜토리얼이 끝나면 GSD Core의 계획 파이프라인이 여러분의 기술 스택, 컨벤션, 그리고 관심사를 파악하게 됩니다 — 이후 계획을 수립할 때마다 이 지식을 활용합니다.
이 튜토리얼에서는 이미 코드가 있는 저장소에 MSD Core를 도입합니다. 코드베이스를 매핑하고, *추가하려는* 내용을 설명하는 프로젝트를 생성한 다음, 작은 변경 사항에 대한 첫 번째 논의-계획 사이클을 실행합니다. 튜토리얼이 끝나면 MSD Core의 계획 파이프라인이 여러분의 기술 스택, 컨벤션, 그리고 관심사를 파악하게 됩니다 — 이후 계획을 수립할 때마다 이 지식을 활용합니다.
---
## 만들 것
기존 Express 애플리케이션에 `GET /health` 엔드포인트 하나를 추가합니다. 변경 사항이 충분히 작아서 진짜 핵심 교훈, 즉 GSD Core가 계획을 수립하기 전에 코드베이스를 어떻게 학습하는지에 집중할 수 있습니다.
기존 Express 애플리케이션에 `GET /health` 엔드포인트 하나를 추가합니다. 변경 사항이 충분히 작아서 진짜 핵심 교훈, 즉 MSD Core가 계획을 수립하기 전에 코드베이스를 어떻게 학습하는지에 집중할 수 있습니다.
---
@@ -18,12 +18,12 @@
---
## Step 1 — GSD Core 설치
## Step 1 — MSD Core 설치
저장소 루트에서 실행합니다:
```bash
npx @opengsd/gsd-core@latest
npx @golem15/msd-core@latest
```
프롬프트가 표시되면 **Claude Code**와 **local**을 선택합니다. 다음과 같이 표시됩니다:
@@ -31,7 +31,7 @@ npx @opengsd/gsd-core@latest
```text
✓ Installed 86 skills to .claude/commands/
✓ Installed agents to .claude/agents/
✓ GSD Core ready — run /gsd-new-project to start
✓ MSD Core ready — run /msd-new-project to start
```
---
@@ -44,7 +44,7 @@ claude --dangerously-skip-permissions
> [!CAUTION]
> **The permissions flag is optional.** It skips per-file confirmation while
> GSD's sub-agents read and write files. Use it only in low-stakes or
> MSD's sub-agents read and write files. Use it only in low-stakes or
> throwaway contexts. To keep confirmations enabled, start with `claude` instead.
> For real work, read the [security model](../explanation/security-model.md) first.
@@ -53,13 +53,13 @@ claude --dangerously-skip-permissions
## Step 3 — 브라운필드 온보딩 시작
프로젝트를 생성하기 전에 GSD Core가 저장소 상태를 검사하고 안전한 다음 top-level 명령을 알려주게 하세요. 이 단계는 코드베이스 컨텍스트를 건너뛰거나 기존 planning 파일을 덮어쓰는 일을 방지합니다.
프로젝트를 생성하기 전에 MSD Core가 저장소 상태를 검사하고 안전한 다음 top-level 명령을 알려주게 하세요. 이 단계는 코드베이스 컨텍스트를 건너뛰거나 기존 planning 파일을 덮어쓰는 일을 방지합니다.
```text
/gsd-onboard
/msd-onboard
```
온보딩이 코드베이스 맵 누락을 보고하면 권장 옵션을 선택하고 출력된 `/gsd-map-codebase` handoff를 실행한 뒤 `/gsd-onboard`를 다시 실행합니다. `/gsd-onboard --fast`는 가벼운 첫 패스에는 충분하지만, `/gsd-new-project` 전에는 완전한 맵이 필요합니다. `/gsd-map-codebase`가 4개의 병렬 매퍼 서브 에이전트를 생성합니다("Spawning 4 parallel codebase mapper agents…" 메시지가 표시되며, 1–5분 소요됩니다. 중단하지 마세요). 각 에이전트는 서로 다른 관심사에 집중합니다:
온보딩이 코드베이스 맵 누락을 보고하면 권장 옵션을 선택하고 출력된 `/msd-map-codebase` handoff를 실행한 뒤 `/msd-onboard`를 다시 실행합니다. `/msd-onboard --fast`는 가벼운 첫 패스에는 충분하지만, `/msd-new-project` 전에는 완전한 맵이 필요합니다. `/msd-map-codebase`가 4개의 병렬 매퍼 서브 에이전트를 생성합니다("Spawning 4 parallel codebase mapper agents…" 메시지가 표시되며, 1–5분 소요됩니다. 중단하지 마세요). 각 에이전트는 서로 다른 관심사에 집중합니다:
| 에이전트 | 집중 영역 |
|---------|---------|
@@ -83,9 +83,9 @@ Created .planning/codebase/:
- CONCERNS.md (33 lines) - Technical debt and issues
```
`.planning/codebase/STACK.md`를 열어봅니다. GSD Core가 실제 파일을 읽어서 감지한 언어, 런타임, 프레임워크 버전, 주요 의존성이 표시됩니다 — 추측이 아닌 실제 데이터를 기반으로 합니다.
`.planning/codebase/STACK.md`를 열어봅니다. MSD Core가 실제 파일을 읽어서 감지한 언어, 런타임, 프레임워크 버전, 주요 의존성이 표시됩니다 — 추측이 아닌 실제 데이터를 기반으로 합니다.
`.planning/codebase/CONVENTIONS.md`를 열어봅니다. 소스 코드에서 관찰한 네이밍 컨벤션, 에러 처리 패턴, 코드 스타일 규칙이 표시됩니다. GSD Core가 이 저장소를 위해 생성하는 모든 계획은 이 컨벤션을 자동으로 따릅니다.
`.planning/codebase/CONVENTIONS.md`를 열어봅니다. 소스 코드에서 관찰한 네이밍 컨벤션, 에러 처리 패턴, 코드 스타일 규칙이 표시됩니다. MSD Core가 이 저장소를 위해 생성하는 모든 계획은 이 컨벤션을 자동으로 따릅니다.
`.planning/codebase/CONCERNS.md`를 열어봅니다. 새로운 기능 작업 전에 가장 먼저 읽어야 할 파일입니다 — 계획에 영향을 줄 수 있는 기술 부채와 취약한 영역을 드러냅니다.
@@ -99,13 +99,13 @@ Created .planning/codebase/:
/clear
```
이제 `/gsd-onboard`를 다시 실행합니다. GSD Core가 ADR, PRD, spec, RFC 또는 루트 요구사항 문서를 감지하면 먼저 권장되는 `/gsd-ingest-docs` handoff를 실행하고 이후 `/gsd-onboard`를 다시 실행하세요. 컨텍스트가 준비되면 온보딩이 프로젝트 초기화 handoff를 출력합니다:
이제 `/msd-onboard`를 다시 실행합니다. MSD Core가 ADR, PRD, spec, RFC 또는 루트 요구사항 문서를 감지하면 먼저 권장되는 `/msd-ingest-docs` handoff를 실행하고 이후 `/msd-onboard`를 다시 실행하세요. 컨텍스트가 준비되면 온보딩이 프로젝트 초기화 handoff를 출력합니다:
```text
/gsd-new-project
/msd-new-project
```
GSD Core가 무엇을 만들고 싶은지 묻습니다. 전체 코드베이스에 대한 설명이 아닌 추가하려는 기능으로 답변합니다:
MSD Core가 무엇을 만들고 싶은지 묻습니다. 전체 코드베이스에 대한 설명이 아닌 추가하려는 기능으로 답변합니다:
```text
Add a GET /health endpoint to the Express app. It should return
@@ -113,7 +113,7 @@ Add a GET /health endpoint to the Express app. It should return
health checks.
```
GSD Core는 소수의 후속 질문을 한 다음 요구사항과 로드맵 생성을 진행합니다. 이미 `ARCHITECTURE.md`와 `STACK.md`를 읽었으므로, 기존 기능을 `PROJECT.md`의 **Validated** 섹션에 자동으로 매핑합니다 — 기존 API 표면을 직접 설명할 필요가 없습니다.
MSD Core는 소수의 후속 질문을 한 다음 요구사항과 로드맵 생성을 진행합니다. 이미 `ARCHITECTURE.md`와 `STACK.md`를 읽었으므로, 기존 기능을 `PROJECT.md`의 **Validated** 섹션에 자동으로 매핑합니다 — 기존 API 표면을 직접 설명할 필요가 없습니다.
모든 워크플로 설정에서 권장 기본값을 선택합니다.
@@ -131,7 +131,7 @@ Proposed Roadmap
로드맵을 승인합니다.
프로젝트 설정이 끝난 뒤 `/gsd-onboard`를 한 번 더 실행합니다. 이제 `PROJECT.md`, `REQUIREMENTS.md`, `ROADMAP.md`, `STATE.md`가 모두 있으므로 온보딩은 `.planning/onboarding/SUMMARY.md`를 생성하거나 확인합니다.
프로젝트 설정이 끝난 뒤 `/msd-onboard`를 한 번 더 실행합니다. 이제 `PROJECT.md`, `REQUIREMENTS.md`, `ROADMAP.md`, `STATE.md`가 모두 있으므로 온보딩은 `.planning/onboarding/SUMMARY.md`를 생성하거나 확인합니다.
**`.planning/`에 생성되는 파일:**
@@ -146,7 +146,7 @@ Proposed Roadmap
codebase/ ← Step 3에서 생성된 7개의 맵 파일
```
`.planning/codebase/`는 Step 3에서 이미 생성된 것입니다. `PROJECT.md` 작성 시 GSD Core가 해당 파일들을 읽었기 때문에, 여러분이 직접 설명하지 않아도 Validated 요구사항을 채울 수 있었습니다.
`.planning/codebase/`는 Step 3에서 이미 생성된 것입니다. `PROJECT.md` 작성 시 MSD Core가 해당 파일들을 읽었기 때문에, 여러분이 직접 설명하지 않아도 Validated 요구사항을 채울 수 있었습니다.
---
@@ -157,10 +157,10 @@ Proposed Roadmap
```
```text
/gsd-discuss-phase 1
/msd-discuss-phase 1
```
GSD Core가 `CONVENTIONS.md`와 `ARCHITECTURE.md`를 읽었으므로, 질문들이 실제 코드베이스에 근거합니다 — 일반적인 조언이 아닙니다. 다음과 같은 질문을 받을 수 있습니다:
MSD Core가 `CONVENTIONS.md`와 `ARCHITECTURE.md`를 읽었으므로, 질문들이 실제 코드베이스에 근거합니다 — 일반적인 조언이 아닙니다. 다음과 같은 질문을 받을 수 있습니다:
```text
> Your routes are registered in src/routes/index.js. Should the health
@@ -175,7 +175,7 @@ GSD Core가 `CONVENTIONS.md`와 `ARCHITECTURE.md`를 읽었으므로, 질문들
process.uptime() is fine.
```
논의가 끝나면 GSD Core가 다음 파일을 생성합니다:
논의가 끝나면 MSD Core가 다음 파일을 생성합니다:
```text
.planning/phases/01-health-endpoint/CONTEXT.md
@@ -188,7 +188,7 @@ GSD Core가 `CONVENTIONS.md`와 `ARCHITECTURE.md`를 읽었으므로, 질문들
## Step 6 — Phase 1 계획
```text
/gsd-plan-phase 1
/msd-plan-phase 1
```
4개의 리서치 서브 에이전트가 병렬로 실행됩니다(1–5분). 완료되면 플래너가 `CONTEXT.md`, 리서치 결과, 코드베이스 맵을 읽어 컨벤션에 맞는 태스크 계획을 생성합니다.
@@ -202,7 +202,7 @@ GSD Core가 `CONVENTIONS.md`와 `ARCHITECTURE.md`를 읽었으므로, 질문들
01-02-PLAN.md ← 태스크: src/routes/index.js에 health 라우트 등록
```
`01-01-PLAN.md`를 열어봅니다. `<files>` 태그에 `src/routes/health.js`가 참조되어 있습니다 — 논의에서 지정한 정확한 경로이며, GSD Core가 코드베이스 맵에서 관찰한 라우팅 패턴과 일치합니다. 코드베이스 맵이 실제로 작동하는 모습입니다.
`01-01-PLAN.md`를 열어봅니다. `<files>` 태그에 `src/routes/health.js`가 참조되어 있습니다 — 논의에서 지정한 정확한 경로이며, MSD Core가 코드베이스 맵에서 관찰한 라우팅 패턴과 일치합니다. 코드베이스 맵이 실제로 작동하는 모습입니다.
---
@@ -211,21 +211,21 @@ GSD Core가 `CONVENTIONS.md`와 `ARCHITECTURE.md`를 읽었으므로, 질문들
이제 코드베이스 맵, 논의 결정 기록, 검증된 태스크 계획을 갖춘 프로젝트가 완성되었습니다 — 모두 실제 코드에 근거합니다. 이후 워크플로는 그린필드 프로젝트와 동일합니다:
```text
/gsd-execute-phase 1
/gsd-verify-work 1
/gsd-ship 1
/msd-execute-phase 1
/msd-verify-work 1
/msd-ship 1
```
앞으로 새로운 기능을 추가할 때마다 구조가 크게 바뀌면 `/gsd-map-codebase`를 다시 실행하여 코드베이스 맵을 최신 상태로 유지합니다.
앞으로 새로운 기능을 추가할 때마다 구조가 크게 바뀌면 `/msd-map-codebase`를 다시 실행하여 코드베이스 맵을 최신 상태로 유지합니다.
---
## 배운 내용
- `/gsd-onboard`가 인터랙티브 명령을 중첩하거나 기존 planning 파일을 덮어쓰지 않고 브라운필드 설정을 안전하게 순서화하는 방법.
- `/gsd-map-codebase`가 4개의 병렬 에이전트를 실행하여 `.planning/codebase/`에 `STACK.md`, `ARCHITECTURE.md`, `CONVENTIONS.md`, `CONCERNS.md`, `STRUCTURE.md`, `TESTING.md`, `INTEGRATIONS.md`를 생성하는 방법.
- 브라운필드 저장소에서 `/gsd-new-project`가 *추가하는* 것에 집중한 질문을 하고 기존 코드에서 Validated 요구사항을 채우는 방법.
- 코드베이스 맵이 `/gsd-discuss-phase`의 모든 질문을 형성하는 방법 — 파일 경로, 패턴, 컨벤션이 실제 코드에서 옵니다.
- `/msd-onboard`가 인터랙티브 명령을 중첩하거나 기존 planning 파일을 덮어쓰지 않고 브라운필드 설정을 안전하게 순서화하는 방법.
- `/msd-map-codebase`가 4개의 병렬 에이전트를 실행하여 `.planning/codebase/`에 `STACK.md`, `ARCHITECTURE.md`, `CONVENTIONS.md`, `CONCERNS.md`, `STRUCTURE.md`, `TESTING.md`, `INTEGRATIONS.md`를 생성하는 방법.
- 브라운필드 저장소에서 `/msd-new-project`가 *추가하는* 것에 집중한 질문을 하고 기존 코드에서 Validated 요구사항을 채우는 방법.
- 코드베이스 맵이 `/msd-discuss-phase`의 모든 질문을 형성하는 방법 — 파일 경로, 패턴, 컨벤션이 실제 코드에서 옵니다.
- 플래너가 `CONTEXT.md`와 `CONVENTIONS.md`를 함께 읽어 저장소 스타일에 맞는 계획을 생성하는 방법.
---
@@ -233,5 +233,5 @@ GSD Core가 `CONVENTIONS.md`와 `ARCHITECTURE.md`를 읽었으므로, 질문들
## Related
- [Your first project](your-first-project.md) — 설치부터 PR까지 전체 그린필드 루프
- [Map codebase via Commands](../COMMANDS.md) — `/gsd-map-codebase`의 모든 플래그와 서브커맨드
- [Map codebase via Commands](../COMMANDS.md) — `/msd-map-codebase`의 모든 플래그와 서브커맨드
- [Documentation index](../README.md)

70
docs/ko-KR/tutorials/your-first-project.md
View File

@@ -1,6 +1,6 @@
# 첫 번째 프로젝트
이 튜토리얼에서는 GSD Core를 설치하고, 간단한 커맨드라인 할 일(to-do) 앱을 처음부터 만들어봅니다 — 하나의 단계(phase), 하나의 PR, 그리고 전체 루프를 경험합니다. 튜토리얼이 끝나면 핵심 단계 루프의 모든 명령어를 최소 한 번씩 실행해보고, 각 명령어가 생성하는 계획 산출물도 확인하게 됩니다.
이 튜토리얼에서는 MSD Core를 설치하고, 간단한 커맨드라인 할 일(to-do) 앱을 처음부터 만들어봅니다 — 하나의 단계(phase), 하나의 PR, 그리고 전체 루프를 경험합니다. 튜토리얼이 끝나면 핵심 단계 루프의 모든 명령어를 최소 한 번씩 실행해보고, 각 명령어가 생성하는 계획 산출물도 확인하게 됩니다.
---
@@ -16,16 +16,16 @@
- **Claude Code** — 사용하려는 프로젝트 디렉터리에서 열어둡니다.
- 초기 설치를 위한 인터넷 연결.
그 외 도구는 필요하지 않습니다. GSD Core는 다음 단계에서 설치합니다.
그 외 도구는 필요하지 않습니다. MSD Core는 다음 단계에서 설치합니다.
---
## Step 1 — GSD Core 설치
## Step 1 — MSD Core 설치
프로젝트 디렉터리에서 터미널을 열고 실행합니다:
```bash
npx @opengsd/gsd-core@latest
npx @golem15/msd-core@latest
```
설치 프로그램이 사용 중인 AI 코딩 런타임과 전역 설치 또는 현재 프로젝트 설치 여부를 묻습니다. 지금은 **Claude Code**와 **local**(이 프로젝트에만)을 선택합니다.
@@ -35,10 +35,10 @@ npx @opengsd/gsd-core@latest
```text
✓ Installed 86 skills to .claude/commands/
✓ Installed agents to .claude/agents/
✓ GSD Core ready — run /gsd-new-project to start
✓ MSD Core ready — run /msd-new-project to start
```
프로젝트 안에 `.claude/` 디렉터리가 생성된 것을 확인할 수 있습니다. GSD Core의 명령어와 에이전트가 이곳에 저장됩니다.
프로젝트 안에 `.claude/` 디렉터리가 생성된 것을 확인할 수 있습니다. MSD Core의 명령어와 에이전트가 이곳에 저장됩니다.
> 로컬 vs 전역 설치 이유? 로컬 설치는 이 프로젝트에 스킬 버전을 고정합니다. 전역 설치가 필요하다면 [런타임에 설치하기](../how-to/install-on-your-runtime.md)를 참고하세요.
@@ -46,7 +46,7 @@ npx @opengsd/gsd-core@latest
## Step 2 — 권한 플래그로 Claude Code 시작
GSD Core는 파일을 읽고 쓰는 서브 에이전트를 생성합니다. 모든 파일 작업마다 확인을 요청하지 않도록 권한 플래그를 사용해 Claude Code를 시작합니다:
MSD Core는 파일을 읽고 쓰는 서브 에이전트를 생성합니다. 모든 파일 작업마다 확인을 요청하지 않도록 권한 플래그를 사용해 Claude Code를 시작합니다:
```bash
claude --dangerously-skip-permissions
@@ -61,10 +61,10 @@ claude --dangerously-skip-permissions
Claude Code 프롬프트에 다음 슬래시 명령어를 입력합니다:
```text
/gsd-new-project
/msd-new-project
```
GSD Core가 대화를 시작합니다. 먼저 질문을 하나 합니다:
MSD Core가 대화를 시작합니다. 먼저 질문을 하나 합니다:
```text
What do you want to build?
@@ -78,13 +78,13 @@ A Node.js CLI tool for managing to-do items. Users run `todo add "buy milk"`,
No external dependencies — Node built-ins only.
```
GSD Core는 몇 가지 후속 질문을 합니다. 자연스럽게 답변하면 됩니다. 계획을 하나도 작성하기 전에 먼저 여러분이 중요하게 생각하는 것을 파악합니다.
MSD Core는 몇 가지 후속 질문을 합니다. 자연스럽게 답변하면 됩니다. 계획을 하나도 작성하기 전에 먼저 여러분이 중요하게 생각하는 것을 파악합니다.
질문이 끝나면 도메인 리서치 실행 여부를 묻습니다. 이 정도 규모의 프로젝트는 리서치를 건너뛰어도 됩니다 — 프롬프트가 표시될 때 **Skip research**를 선택합니다.
그런 다음 GSD Core가 워크플로 설정(모드, 세분화 수준, 리서치 에이전트)을 선택하도록 안내합니다. 각 항목마다 권장 기본값을 선택합니다. 이 설정들은 `.planning/config.json`에 저장됩니다.
그런 다음 MSD Core가 워크플로 설정(모드, 세분화 수준, 리서치 에이전트)을 선택하도록 안내합니다. 각 항목마다 권장 기본값을 선택합니다. 이 설정들은 `.planning/config.json`에 저장됩니다.
마지막으로 로드맵 작성 서브 에이전트가 실행됩니다("Spawning roadmapper…" 메시지가 표시되는 것은 정상이며, 약 1분 정도 소요됩니다). 완료되면 GSD Core가 제안 로드맵을 제시합니다. 단일 단계 프로젝트라면 다음과 같이 표시됩니다:
마지막으로 로드맵 작성 서브 에이전트가 실행됩니다("Spawning roadmapper…" 메시지가 표시되는 것은 정상이며, 약 1분 정도 소요됩니다). 완료되면 MSD Core가 제안 로드맵을 제시합니다. 단일 단계 프로젝트라면 다음과 같이 표시됩니다:
```text
Proposed Roadmap
@@ -115,7 +115,7 @@ Proposed Roadmap
## Step 4 — 컨텍스트 초기화 후 Phase 1 논의
GSD Core는 새로운 컨텍스트를 기반으로 동작하도록 설계되었습니다. 각 단계를 시작하기 전에 메인 세션 창을 초기화합니다:
MSD Core는 새로운 컨텍스트를 기반으로 동작하도록 설계되었습니다. 각 단계를 시작하기 전에 메인 세션 창을 초기화합니다:
```text
/clear
@@ -124,10 +124,10 @@ GSD Core는 새로운 컨텍스트를 기반으로 동작하도록 설계되었
그런 다음 Phase 1 논의를 시작합니다:
```text
/gsd-discuss-phase 1
/msd-discuss-phase 1
```
GSD Core가 단계 목표를 읽고 구현 방식에 대해 질문합니다. 이는 *무엇을* 만들지가 아닌 *어떻게* 만들지를 결정하는 과정입니다. 예시 대화:
MSD Core가 단계 목표를 읽고 구현 방식에 대해 질문합니다. 이는 *무엇을* 만들지가 아닌 *어떻게* 만들지를 결정하는 과정입니다. 예시 대화:
```text
> How should done items be stored — mark them in place or move them?
@@ -140,7 +140,7 @@ GSD Core가 단계 목표를 읽고 구현 방식에 대해 질문합니다. 이
Create it silently on first add.
```
논의가 끝나면 GSD Core가 다음 파일을 생성합니다:
논의가 끝나면 MSD Core가 다음 파일을 생성합니다:
```text
.planning/phases/01-core-cli/CONTEXT.md
@@ -153,7 +153,7 @@ GSD Core가 단계 목표를 읽고 구현 방식에 대해 질문합니다. 이
## Step 5 — Phase 1 계획
```text
/gsd-plan-phase 1
/msd-plan-phase 1
```
4개의 리서치 서브 에이전트가 병렬로 실행됩니다("Spawning 4 researchers…" 메시지가 표시됩니다). 1–5분 정도 소요됩니다. 중단하지 마세요.
@@ -169,17 +169,17 @@ GSD Core가 단계 목표를 읽고 구현 방식에 대해 질문합니다. 이
01-02-PLAN.md ← 태스크: add / list / done 명령어 구현
```
`01-01-PLAN.md`를 열어봅니다. 이름, 관련 파일, 실행 단계, 검증 명령어, 완료 조건이 담긴 `<task>` 블록을 확인할 수 있습니다. `<verify>` 태그에 주목하세요 — GSD Core의 실행기가 코드 작성 후 해당 명령어를 실행합니다.
`01-01-PLAN.md`를 열어봅니다. 이름, 관련 파일, 실행 단계, 검증 명령어, 완료 조건이 담긴 `<task>` 블록을 확인할 수 있습니다. `<verify>` 태그에 주목하세요 — MSD Core의 실행기가 코드 작성 후 해당 명령어를 실행합니다.
---
## Step 6 — Phase 1 실행
```text
/gsd-execute-phase 1
/msd-execute-phase 1
```
GSD Core가 계획을 웨이브(독립적인 계획은 병렬로 실행)로 묶고, 계획별로 새로운 200k 컨텍스트 실행기를 생성하며, 각 태스크를 원자적으로 커밋합니다.
MSD Core가 계획을 웨이브(독립적인 계획은 병렬로 실행)로 묶고, 계획별로 새로운 200k 컨텍스트 실행기를 생성하며, 각 태스크를 원자적으로 커밋합니다.
다음과 같은 출력이 표시됩니다:
@@ -215,17 +215,17 @@ node todo.js done 1
node todo.js list
```
항목이 나타나고, 완료 처리한 항목 1번이 기본 목록에서 사라지는 것을 확인할 수 있습니다. 이것이 GSD Core가 전달하는 첫 번째 가시적인 결과입니다.
항목이 나타나고, 완료 처리한 항목 1번이 기본 목록에서 사라지는 것을 확인할 수 있습니다. 이것이 MSD Core가 전달하는 첫 번째 가시적인 결과입니다.
---
## Step 7 — 작업 검증
```text
/gsd-verify-work 1
/msd-verify-work 1
```
GSD Core가 단계의 성공 기준을 추출하고 하나씩 확인합니다:
MSD Core가 단계의 성공 기준을 추출하고 하나씩 확인합니다:
```text
[1/3] Can you run `node todo.js add "buy milk"` without errors?
@@ -240,7 +240,7 @@ GSD Core가 단계의 성공 기준을 추출하고 하나씩 확인합니다:
All 3 checks passed. Phase 1 verified.
```
검사가 실패하면 GSD Core가 근본 원인을 진단하고 수정 계획을 생성합니다. `/gsd-execute-phase 1`을 다시 실행해 수정을 적용한 후, `/gsd-verify-work 1`을 다시 실행합니다.
검사가 실패하면 MSD Core가 근본 원인을 진단하고 수정 계획을 생성합니다. `/msd-execute-phase 1`을 다시 실행해 수정을 적용한 후, `/msd-verify-work 1`을 다시 실행합니다.
**생성되는 파일:**
@@ -253,10 +253,10 @@ All 3 checks passed. Phase 1 verified.
## Step 8 — 배포
```text
/gsd-ship 1
/msd-ship 1
```
GSD Core가 자동 생성된 본문으로 풀 리퀘스트를 생성합니다. PR 본문에는 항상 요약(Summary), 변경 사항(Changes), 요구사항 반영(Requirements Addressed), 검증(Verification), 핵심 결정사항(Key Decisions)이 포함됩니다.
MSD Core가 자동 생성된 본문으로 풀 리퀘스트를 생성합니다. PR 본문에는 항상 요약(Summary), 변경 사항(Changes), 요구사항 반영(Requirements Addressed), 검증(Verification), 핵심 결정사항(Key Decisions)이 포함됩니다.
다음과 같이 표시됩니다:
@@ -272,15 +272,15 @@ Title: feat(phase-1): core CLI — add / list / done commands
## 배운 내용
- `npx @opengsd/gsd-core@latest`로 GSD Core를 설치하는 방법.
- `/gsd-new-project`가 대화를 통해 `.planning/` 산출물로 뒷받침되는 로드맵으로 전환하는 방법.
- `/gsd-discuss-phase`가 계획 수립 전에 구현 결정사항을 기록하는 방법.
- `/gsd-plan-phase`가 병렬 리서처를 생성하고 원자적 태스크 계획을 만드는 방법.
- `/gsd-execute-phase`가 해당 계획을 병렬 웨이브로 실행하고 각 태스크를 커밋하는 방법.
- `/gsd-verify-work`가 성공 기준을 하나씩 확인하고 필요 시 수정 계획을 생성하는 방법.
- `/gsd-ship`이 검증된 단계를 풀 리퀘스트로 전환하는 방법.
- `npx @golem15/msd-core@latest`로 MSD Core를 설치하는 방법.
- `/msd-new-project`가 대화를 통해 `.planning/` 산출물로 뒷받침되는 로드맵으로 전환하는 방법.
- `/msd-discuss-phase`가 계획 수립 전에 구현 결정사항을 기록하는 방법.
- `/msd-plan-phase`가 병렬 리서처를 생성하고 원자적 태스크 계획을 만드는 방법.
- `/msd-execute-phase`가 해당 계획을 병렬 웨이브로 실행하고 각 태스크를 커밋하는 방법.
- `/msd-verify-work`가 성공 기준을 하나씩 확인하고 필요 시 수정 계획을 생성하는 방법.
- `/msd-ship`이 검증된 단계를 풀 리퀘스트로 전환하는 방법.
멀티 단계 프로젝트의 경우 각 단계마다 Step 4–8을 반복한 다음, `/gsd-progress --next`를 실행해 GSD Core가 다음 단계를 자동으로 감지하도록 합니다.
멀티 단계 프로젝트의 경우 각 단계마다 Step 4–8을 반복한 다음, `/msd-progress --next`를 실행해 MSD Core가 다음 단계를 자동으로 감지하도록 합니다.
---
@@ -288,4 +288,4 @@ Title: feat(phase-1): core CLI — add / list / done commands
- [The phase loop](../explanation/the-phase-loop.md) — 루프가 이런 구조를 가지는 이유
- [How-to guides](../README.md#how-to-guides) — 특정 상황에 대한 태스크 중심 레시피
- [Onboarding an existing codebase](onboarding-an-existing-codebase.md) — 브라운필드 레포에 GSD Core 도입하기
- [Onboarding an existing codebase](onboarding-an-existing-codebase.md) — 브라운필드 레포에 MSD Core 도입하기

10
docs/ko-KR/workflow-discuss-mode.md
View File

@@ -1,6 +1,6 @@
# 논의 모드: 가정 vs 인터뷰
GSD Core의 discuss-phase는 계획 전에 구현 컨텍스트를 수집하기 위한 두 가지 모드를 제공한다. 각 모드를 언제 사용해야 하는지 이해하면 더 적은 주고받음으로 확인된 `CONTEXT.md`에 도달할 수 있다.
MSD Core의 discuss-phase는 계획 전에 구현 컨텍스트를 수집하기 위한 두 가지 모드를 제공한다. 각 모드를 언제 사용해야 하는지 이해하면 더 적은 주고받음으로 확인된 `CONTEXT.md`에 도달할 수 있다.
두 모드 중 하나를 실행하는 단계별 지침은 [단계 논의하기 how-to](how-to/discuss-a-phase.md)를 참조하라.
@@ -26,10 +26,10 @@ GSD Core의 discuss-phase는 계획 전에 구현 컨텍스트를 수집하기
```bash
# assumptions 모드 활성화
node gsd-tools.cjs config-set workflow.discuss_mode assumptions
node msd-tools.cjs config-set workflow.discuss_mode assumptions
# 인터뷰 모드로 전환
node gsd-tools.cjs config-set workflow.discuss_mode discuss
node msd-tools.cjs config-set workflow.discuss_mode discuss
```
설정은 프로젝트별이다(`.planning/config.json`에 저장). 두 모드 모두가 생성하는 파일의 전체 구조는 [CONTEXT.md 스키마](reference/context-md.md)를 참조하라.
@@ -69,7 +69,7 @@ node gsd-tools.cjs config-set workflow.discuss_mode discuss
## Related
- [단계 논의하기](how-to/discuss-a-phase.md) — 두 모드 중 하나로 `/gsd-discuss-phase`를 실행하는 단계별 how-to.
- [단계 논의하기](how-to/discuss-a-phase.md) — 두 모드 중 하나로 `/msd-discuss-phase`를 실행하는 단계별 how-to.
- [CONTEXT.md 스키마](reference/context-md.md) — 두 모드 모두가 생성하는 파일의 전체 필드 레퍼런스.
- [단계 루프](explanation/the-phase-loop.md) — 논의가 더 넓은 논의 → 계획 → 실행 → 검증 → 출시 사이클에서 어떻게 맞는지.
- [문서 인덱스](README.md) — GSD Core 문서의 전체 목차.
- [문서 인덱스](README.md) — MSD Core 문서의 전체 목차.