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

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.

docs/ko-KR/reference/context-md.md

@@ -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>

docs/ko-KR/reference/plan-md.md

@@ -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회 반복):
 
 | 차원 | 확인 내용 |
 |---|---|

docs/ko-KR/reference/planning-artifacts.md

@@ -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` 안티패턴을 이해했음을 입증하도록 요구합니다. |
 
 ---

docs/ko-KR/reference/state-md.md

@@ -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` 렌더링을 깨는 변경 사항은 스위트에서 실패합니다.
 
 ---