@simplysm/sd-claude 14.0.57 → 14.0.58

package/claude/references/sd-simplysm-v14/angular/ui-data/sd-crud-list.md

@@ -182,7 +182,7 @@ viewType에 따라 렌더링 위치가 달라진다:
 | `item` | `TItem` | 현재 행 항목 (명시적 이름) |
 | `index` | `number` | 행 인덱스 |
 | `depth` | `number` | 트리 데이터의 중첩 깊이 |
-| `edit` | `boolean` | 현재 행이 편집 모드인지 여부. 행 클릭(또는 더블클릭) 시 `true`가 된다. `SdTextfield`의 `[readonly]`에 `!edit`을 바인딩하여 인라인 편집을 구현한다. |
+| `edit` | `boolean` | 현재 행이 편집 모드인지 여부. 행 클릭(또는 더블클릭) 시 `true`가 된다. `SdTextfield`의 `[readonly]`에 `!edit`을 바인딩하여 인라인 편집을 구현한다. **`SdSelect`/`SdSharedDataSelect`/`SdCheckbox`/`SdButton`류는 `readonly` 입력 자체가 없으며 클릭 한 번에 즉시 동작하므로 `let-edit`을 받지 않고 `[disabled]="!canEdit()"`만 사용한다 (자세한 내용은 [`sd-sheet.md`](./sd-sheet.md)의 "컨트롤별 `edit` 모드 처리" 표 참조).** |
 
 ```html
 <!-- 읽기 전용 셀 -->
@@ -592,6 +592,88 @@ export class CustomerList implements SdSelectModal<number> {
 </sd-crud-list>
 ```
 
+## Usage: 외부 input(초기 필터)을 받는 모달
+
+`SdSelectModal`로도 사용되면서 동시에 페이지 라우팅으로도 진입 가능한 컴포넌트는, 호출자가 `inputs`로 강제 주입하는 초기 필터(`includeCustomerIds`, `includeGoodsIds`, `excludeIds` 등)와 사용자가 화면에서 변경하는 `filter`/`lastFilter`가 같은 키를 공유한다. 이때 effect를 **두 개로 분리**해야 한다.
+
+### ✅ 권장: input 동기화와 검색 트리거를 분리
+
+```typescript
+constructor() {
+  // effect 1: 외부 input → filter/lastFilter 단방향 동기화 (input 변경 시만 트리거)
+  effect(() => {
+    const cIds = this.includeCustomerIds() ?? [];
+    const gIds = this.includeGoodsIds() ?? [];
+    const xIds = this.excludeIds() ?? [];
+
+    untracked(() => {
+      this.filter.update((f) => ({
+        ...f,
+        includeCustomerIds: cIds,
+        includeGoodsIds: gIds,
+        excludeIds: xIds,
+      }));
+      this.lastFilter.set({ ...this.filter() });
+    });
+  });
+
+  // effect 2: lastFilter/page/sortingDefs → 검색 (사용자 onFilterSubmit/페이지 이동/정렬 시 트리거)
+  effect(() => {
+    if (!this.perms().includes("use") || !this.ready()) {
+      this.initialized.set(true);
+      return;
+    }
+
+    this.lastFilter();
+    this.page();
+    this.sortingDefs();
+
+    void untracked(async () => {
+      this.busyCount.update((v) => v + 1);
+      await this._sdToast.try(async () => {
+        await this._refresh();
+      });
+      this.busyCount.update((v) => v - 1);
+      this.initialized.set(true);
+    });
+  });
+}
+```
+
+- effect 1은 **input signal에만 의존**. 페이지 모드(input 미전달)에서는 init 1회만 실행되고 이후 트리거되지 않으므로, 사용자가 화면에서 바꾼 `filter`/`lastFilter`를 덮어쓰지 않는다.
+- effect 2는 **lastFilter/page/sortingDefs에만 의존**. `onFilterSubmit()`이 `lastFilter.set` 하면 검색이 자동 실행된다.
+- 모달 모드에서 호출자가 inputs를 한 번만 전달하므로, 모달이 열린 동안 effect 1이 재트리거되지 않아 모달 내 사용자 변경도 보존된다.
+
+### ❌ 안티패턴: 한 effect에서 input vs lastFilter 비교 후 reset
+
+```typescript
+constructor() {
+  effect(() => {
+    if (!this.perms().includes("use") || !this.ready()) { /* ... */ return; }
+
+    const cIds = this.includeCustomerIds() ?? [];      // 페이지 모드: 항상 []
+    const lf = this.lastFilter();                       // 사용자 검색 직후: [123]
+    if (!obj.equal(cIds, lf.includeCustomerIds)) {     // ❌ input과 lastFilter 비교
+      untracked(() => {
+        this.filter.update((f) => ({ ...f, includeCustomerIds: cIds }));
+        this.lastFilter.set({ ...this.filter() });     // ❌ 사용자 변경을 [] 로 덮어씀
+        this.page.set(0);
+      });
+    }
+
+    this.lastFilter();
+    this.page();
+    this.sortingDefs();
+
+    void untracked(async () => { await this._refresh(); });
+  });
+}
+```
+
+- 사용자가 화면에서 필터를 변경하고 `onFilterSubmit()` 호출 → `lastFilter.set([123])` → 이 effect 재실행 → `cIds=[]`와 `lastFilter=[123]`이 다르다고 판단 → `filter`/`lastFilter`를 `[]`로 reset → `_refresh()`는 빈 필터로 검색.
+- 결과: 페이지 모드에서 필터가 항상 빈 배열로 동작하는 것처럼 보임 (필터 미적용).
+- 외부 input은 "외부에서 명령적 reset"의 트리거여야 하며, 사용자 변경(`lastFilter`)과 동등 비교의 기준이 되어선 안 된다.
+
 ## Anti-patterns
 
 ```html
@@ -620,4 +702,20 @@ export class CustomerList implements SdSelectModal<number> {
 <!-- ❌ cell 템플릿에서 items 시그널 호출을 빠뜨리지 않는다 -->
 <ng-template [cell]="[]" let-item="item">  <!-- ❌ 타입 추론 불가 -->
 <ng-template [cell]="items()" let-item="item">  <!-- ✅ -->
+
+<!-- ❌ select류 컨트롤에 [readonly]="!edit"을 바인딩하지 않는다 -->
+<sd-select [readonly]="!edit" ...>
+<!-- → typecheck 에러: Can't bind to 'readOnly' since it isn't a known property of 'sd-select' -->
+
+<!-- ❌ 위 에러를 회피하려고 disabled에 !edit을 합치지 않는다 -->
+<!-- (select는 즉시 변경 컨트롤이라 edit 모드 분기가 의미 없고, -->
+<!--  값 표시 행에서도 disabled로 회색 처리되어 권한 없음 시각과 혼동됨) -->
+<ng-template [cell]="items()" let-item="item" let-edit="edit">
+  <sd-select [disabled]="!canEdit() || !edit" ...>
+</ng-template>
+
+<!-- ✅ select류는 edit 모드 분기 없음. let-edit 안 받고 disabled는 권한만 -->
+<ng-template [cell]="items()" let-item="item">
+  <sd-select [disabled]="!canEdit()" ...>  <!-- ✅ -->
+</ng-template>
 ```

package/claude/references/sd-simplysm-v14/angular/ui-data/sd-sheet.md

@@ -111,6 +111,33 @@ class SdSheetColumnCellTemplate<T> {
 - **일반 텍스트**: `<div class="p-xs-sm">` 로 감싸 기본 패딩 적용
 - **컨트롤 삽입**: 반드시 `[inset]="true"` + `[size]="'sm'"` 지정
 
+**컨트롤별 `edit` 모드 처리** — `SdSheetCellContext.edit`은 셀이 편집 진입 모드인지 여부(행 클릭/더블클릭으로 활성)다. 컨트롤 종류에 따라 처리가 다르다:
+
+| 컨트롤 | `[disabled]` | `[readonly]` | `let-edit="edit"` |
+|--------|-------------|-------------|---------------------|
+| `SdTextfield` (text/number/date 등) | `!canEdit()` | `!edit` | 받음 |
+| `SdSelect` / `SdSharedDataSelect` | `!canEdit()` | (사용 안 함) | **받지 않음** |
+| `SdCheckbox` | `!canEdit()` | (사용 안 함) | 받지 않음 |
+| `SdButton` | `!canEdit()` | (사용 안 함) | 받지 않음 |
+
+`readonly`는 "값은 보이되 편집 진입을 막는다", `disabled`는 "회색 + 비활성"이라 의미·시각이 다르다. textfield 류는 둘을 분리해 인라인 편집(읽기 모드 → 클릭 → 편집 모드) UX를 구현한다.
+
+select·체크박스·버튼류는 클릭 한 번으로 즉시 동작하는 컨트롤이라 `edit` 모드 분기 자체가 의미 없다. `let-edit="edit"`을 받지 않고 `[disabled]`는 권한(`!canEdit()`)만 반영한다.
+
+```html
+<!-- ❌ select류 컨트롤에서 disabled에 !edit을 합치지 않는다 -->
+<ng-template [cell]="items()" let-item="item" let-edit="edit">
+  <sd-select [disabled]="!canEdit() || !edit" ...>
+</ng-template>
+
+<!-- ✅ select는 edit 모드 분기 없음. let-edit 안 받고 disabled는 권한만 -->
+<ng-template [cell]="items()" let-item="item">
+  <sd-select [disabled]="!canEdit()" ...>
+</ng-template>
+```
+
+> **주의**: `SdSelect`/`SdSharedDataSelect`/`SdCheckbox`/`SdButton`은 `readonly` 입력을 **제공하지 않는다**. `[readonly]="!edit"`을 바인딩하면 typecheck 에러(`Can't bind to 'readOnly' since it isn't a known property of 'sd-...'`)가 발생한다. textfield 패턴(`disabled`/`readonly` 분리)을 select류에 그대로 적용하지 말 것.
+
 ### `SdSheetCellContext`
 
 ```typescript

package/claude/references/sd-simplysm-v14/angular/ui-form/sd-select.md

@@ -45,6 +45,26 @@ class SdSelect<T, M extends keyof SelectModeValue<T>> {
 
 **스타일 적용**: `contentClass`/`contentStyle`은 트리거 영역(선택값 텍스트와 드롭다운 화살표가 함께 놓인 박스)에만 적용된다.
 
+## 빈 값(`undefined`) 항목 표시 권장 패턴
+
+`SdSelect`에서 `[value]="undefined"` 항목은 일반 항목과 시각적으로 구분되도록 라벨을 회색으로 처리한다. 사용자가 "값 없음"을 즉시 인지하고 의미 있는 값과 혼동하지 않도록 한다.
+
+```html
+<sd-select [(value)]="item.weekOffset" (valueChange)="mark(items)">
+  <sd-select-item [value]="undefined">
+    <span class="tx-theme-gray-default">미지정</span>
+  </sd-select-item>
+  <sd-select-item [value]="0">+0주</sd-select-item>
+  <sd-select-item [value]="1">+1주</sd-select-item>
+  <sd-select-item [value]="2">+2주</sd-select-item>
+</sd-select>
+```
+
+- `tx-theme-gray-default`은 `@simplysm/angular`의 회색 텍스트 토큰이다.
+- 본 패턴은 **single 모드 한정**이다 — 필터의 "전체"(모든 옵션 포함), nullable 컬럼의 "미지정" 등 single 모드의 빈 값 라벨에 적용한다.
+- multi 모드는 `hideSelectAll` 옵션으로 "전체 선택"이 자체 제공되므로 별도 `[value]="undefined"` 항목을 두지 않는다.
+- `placeholder` 만으로는 사용자가 한 번 값을 선택한 뒤 빈 값으로 복귀할 수 없으므로, `[value]="undefined"` 항목을 명시하고 라벨에 회색을 적용하는 것이 권장 패턴이다.
+
 ## Related Types
 
 ### `SdSelectItem`

package/claude/references/sd-simplysm-v14/sd-claude/assets.md

@@ -40,7 +40,7 @@ claude/
 | `sd-deliverable/`     | sd-deliverable     | 매뉴얼/SIT 문서 생성                               |
 | `sd-dev/`             | sd-dev             | 통합 개발 오케스트레이터 (요구명세 → TDD → 리뷰)   |
 | `sd-doc-extract/`     | sd-doc-extract     | 문서 파일 텍스트/이미지 추출 (Python)              |
-| `sd-inner-clarify/`   | sd-inner-clarify   | (내부 전용) 명확성 분류·근거 탐색·명확화 질문      |
+| `sd-clarify/`   | sd-clarify   | (내부 전용) 명확성 분류·근거 탐색·명확화 질문      |
 | `sd-issue/`           | sd-issue           | GitHub 이슈 생성                                   |
 | `sd-outlook/`         | sd-outlook         | Outlook 메일 검색/다운로드 (Python)                |
 | `sd-plan/`            | sd-plan            | 요구명세/구현계획 작성                             |

package/claude/rules/sd-claude-rules.md

@@ -8,9 +8,9 @@
 
 # 대화 규칙
 
-- 응답 전 항상 thinking 할 것.
+- 모든 요청에 대해 항상 깊이 생각 할 것.
 - 내장 도구 적극 활용 (Read/Grep/Glob/Bash/WebFetch/WebSearch/Skill/TaskCreate 등)
-- 사용자 요청의 의도가 불명확할 때는 `/sd-inner-clarify` 스킬을 호출하여 명확화.
+- 사용자 요청의 의도가 불명확할 때는 `/sd-clarify` 스킬을 호출하여 명확화.
 - 맥락에 맞는 용어 사용
   - 업무 기능·요구사항 논의 → 업무 용어 (사용자가 화면에서 뭘 하는지)
   - DB 스키마 설계 → 테이블·컬럼명

package/claude/rules/sd-response-format.md

@@ -12,6 +12,7 @@
 - 불릿 우선: 항목이 2개 이상이거나 병렬 구조면 산문 대신 불릿 리스트 사용. 3줄 이상 텍스트가 이어지면 빈 줄 또는 리스트로 끊는다.
 - 표 활용: 대비·비교·다축 평가는 표(table)로 정돈. 정렬·가시성 우수.
 - 코드블록 활용: 명령어 1줄 이상, 코드 인용, 파일 내용 발췌, 변경 전후 본문은 fenced code block으로 분리.
+- 꼬리 요약: 응답이 30줄 이상이면 마지막에 가로선 분리 후 `## 요약` 헤더 + 핵심 불릿 3~5개를 출력한다. 30줄 미만이면 출력 금지.
 
 ## 색상 활용 (Claude Code 터미널 기준)
 

package/claude/settings.json

@@ -1,6 +1,4 @@
 {
-  "transcriptView": "verbose",
-  "outputStyle": "Explanatory",
   "hooks": {
     "PreToolUse": [
       {

package/claude/skills/sd-check/SKILL.md

@@ -121,13 +121,13 @@ typecheck 명령어를 실행한다. (`출력 캡처 규칙`에 따라 파일로
    - **테스트 데이터 갱신 누락**: snapshot/expected/golden 출력만 달라진 경우 변경 의도 확인 후 해당 테스트 데이터 수정.
    - **무관한 기존 실패**: `에러 처리 범위`에 따라 조용히 스킵.
    - **원인 특정 불가**: 에스컬레이션 규칙에 따라 즉시 보고.
-6. 1차 분류 결과와 근거 전체를 `/sd-inner-clarify`로 전달하여 분류와 처리 방향의 명확성을 판정한다. sd-check가 자체 판단으로 명확한 항목을 제외하고 보내지 않는다.
-7. `/sd-inner-clarify`가 분류와 처리 방향을 명확하다고 판정하면 즉시 처리한다:
+6. 1차 분류 결과와 근거 전체를 `/sd-clarify`로 전달하여 분류와 처리 방향의 명확성을 판정한다. sd-check가 자체 판단으로 명확한 항목을 제외하고 보내지 않는다.
+7. `/sd-clarify`가 분류와 처리 방향을 명확하다고 판정하면 즉시 처리한다:
    - **구현 버그가 명확함**: 코드 수정.
    - **테스트 변경 누락이 명확함**: 테스트, fixture, expected/golden 수정.
    - **테스트 데이터 갱신 누락이 명확함**: snapshot/expected/golden 수정.
    - **무관한 기존 실패가 명확함**: `에러 처리 범위`에 따라 조용히 스킵.
-8. `/sd-inner-clarify`가 1%라도 불확실하다고 판정하면 처리하지 않는다. 사용자에게 분류 근거와 처리 방향을 확인받고 승인된 처리만 실행한다.
+8. `/sd-clarify`가 1%라도 불확실하다고 판정하면 처리하지 않는다. 사용자에게 분류 근거와 처리 방향을 확인받고 승인된 처리만 실행한다.
 
 **NEVER: 테스트를 통과시키기 위해 현재 세션의 의도된 코드 변경을 예전 동작으로 되돌리지 않는다.** 코드 롤백성 수정은 실패 원인이 구현 버그로 확정된 경우에만 허용한다. "테스트가 기존 값을 기대한다"는 사실만으로 구현 버그를 확정할 수 없다.
 

package/claude/skills/{sd-inner-clarify → sd-clarify}/SKILL.md

@@ -1,9 +1,9 @@
 ---
-name: sd-inner-clarify
-description: (내부 전용) 명확성 분류·근거 탐색·재분류·명확화 질문 프로세스. sd-plan, sd-wbs, sd-tdd, sd-refactor, sd-prompt, sd-inner-debug 등에서 호출된다. 직접 호출하지 않는다.
+name: sd-clarify
+description: 명확성 분류·근거 탐색·재분류·명확화 질문 프로세스. 타 스킬내에서 호출되거나, 사용자 요청이 불명확할때 사용된다.
 ---
 
-# sd-inner-clarify: 명확화 프로세스
+# sd-clarify: 명확화 프로세스
 
 정보의 명확성 판단 및 불명확한 정보를 명확화 하고자 할 때 적용한다.
 파악한 정보를 확실성 수준별로 분류하고, 불명확한 항목은 사용자에게 질문하여 해소한다.
@@ -21,13 +21,13 @@ description: (내부 전용) 명확성 분류·근거 탐색·재분류·명확
 
 ## Step 2: 근거 탐색 (질문 전 필수)
 
-**CRITICAL: Medium/Low/ASSUMED로 분류된 모든 항목은 사용자에게 질문하기 전에 반드시 근거를 탐색한다.**
+**CRITICAL: Medium/Low/ASSUMED로 분류된 모든 항목은 사용자에게 질문하기 전에 반드시 근거를 한번 더 탐색한다.**
 
 근거 출처는 항목의 성격에 따라 결정한다. 컨텍스트 회수와 타겟 탐색 중 어느 한쪽으로 미리 편향시키지 않는다.
 
 ### 2-1. 컨텍스트 회수
 
-지금까지 누적된 맥락 전체에서 근거를 찾는다. 새 tool 호출 전에 수행한다.
+지금까지 누적된 맥락 전체에서 근거를 찾는다.
 
 - **사용자 메시지** — 현재/이전 턴의 지시, 인용, 예시, 제약
 - **호출자에게서 받은 인자** — 이 스킬을 부른 상위 스킬(sd-plan/sd-wbs 등)이 전달한 정보
@@ -40,8 +40,8 @@ description: (내부 전용) 명확성 분류·근거 탐색·재분류·명확
 
 - **타겟 코드베이스** — Grep/Read/Glob으로 동일/유사 패턴. **다음 항목은 코드베이스 탐색 필수(컨텍스트 회수로 종결 금지):** UI 컴포넌트 구조·레이아웃·생김새, 메뉴/네비게이션 분할, 라우팅 구조, 도메인 엔터티 구조, 네이밍 컨벤션, 디렉토리 구조
 - **참조 문서** — `.claude/references/**`, CLAUDE.md 등 프로젝트 문서
-- **사용자가 제공한 원본 자료** — 첨부 문서·파일·경로를 끝까지 확인 (키워드 검색만으로 종결 금지)
-- **공식 문서** — 외부 라이브러리/프레임워크 (필요 시)
+- **사용자가 제공한 원본 자료** — 첨부 문서·파일·경로를 끝까지 확인 (완독. 키워드 검색만으로 종결 금지)
+- **공식 문서** — 외부 라이브러리/프레임워크의 공식 문서
 
 ### 실패 시그널 (Step 3 진입 전 자가 검증)
 
@@ -50,7 +50,7 @@ description: (내부 전용) 명확성 분류·근거 탐색·재분류·명확
 - 찾음: `{파일/문서}:{라인/페이지/섹션}` + 인용·요약
 - 못 찾음: 어디를 봤는지(회수한 맥락 + 탐색한 소스) 명시
 
-둘 다 못 대면 탐색이 부족한 것이다. 다시 수행한다. "어차피 모를 것"이라는 판단으로 건너뛰는 것은 **금지(NEVER)**.
+"어차피 모를 것"이라는 판단으로 건너뛰는 것은 **금지(NEVER)**.
 
 ## Step 3: 재분류
 
@@ -61,9 +61,21 @@ description: (내부 전용) 명확성 분류·근거 탐색·재분류·명확
 
 ## Step 4: 재분류 보고 (필수)
 
-재분류 결과를 **표 형태로 사용자에게 출력**한다. Step 5 질문 전에 반드시 수행한다.
+최종 분류 결과를 **표 형태로 사용자에게 출력**한다.
 
-### 인용 형식
+### 표 출력
+
+| 항목        | 1차 분류 | 탐색 위치                 | 인용/요약       | 재분류   |
+| ----------- | -------- | ------------------------- | --------------- | -------- |
+| (정보 항목) | ASSUMED  | 원본.docx p.3 / foo.ts:42 | "..." 또는 요약 | VERIFIED |
+
+- **탐색 위치**는 파일경로:라인번호, 문서명:페이지/섹션, 메일 식별자, 회의록 발화자:시점 등 **구체 좌표**로 명시한다. "전체 검토", "문서 봄", "전반적으로 확인" 같은 추상 보고는 **금지(NEVER)**.
+- **인용/요약**은 위 "인용 형식" 규칙을 따른다. 인용이 비어 있으면 해당 항목은 ASSUMED 유지(승격 금지).
+- **근거 없음**으로 남기려면 (a) 어떤 키워드/구간을 봤는지, (b) 어떤 자료의 어떤 부분에서 부재를 확인했는지를 두 줄 이상 구체 명시한다. "탐색했으나 근거 없음" 한 줄로 종결하면 위반.
+- 비정형 자료(메일, 회의 대본, 메시지 본문)가 호출자(sd-wbs 등)에서 보고되었는데 표에 해당 자료 인용이 1건도 없으면, 끝까지 읽지 않은 신호로 간주하여 Step 2로 되돌아간다.
+- 보고 직후, 질문 대상이 남아 있으면 Step 5로 진행한다.
+
+#### 인용 형식
 
 표의 "인용/요약" 칼럼에 사용한다.
 
@@ -74,20 +86,9 @@ description: (내부 전용) 명확성 분류·근거 탐색·재분류·명확
   - 메시지 본문: `사용자 메시지 ({n}번째 턴) — "..."`
 - 인용은 1~2문장으로 의미가 드러나야 한다. 좌표만 적고 인용을 생략하는 것은 **금지**.
 
-### 표 출력
-
-| 항목 | 1차 분류 | 탐색 위치 | 인용/요약 | 재분류 |
-|------|---------|----------|----------|--------|
-| (정보 항목) | ASSUMED | 원본.docx p.3 / foo.ts:42 | "..." 또는 요약 | VERIFIED |
-
-- **탐색 위치**는 파일경로:라인번호, 문서명:페이지/섹션, 메일 식별자, 회의록 발화자:시점 등 **구체 좌표**로 명시한다. "전체 검토", "문서 봄", "전반적으로 확인" 같은 추상 보고는 **금지(NEVER)**.
-- **인용/요약**은 위 "인용 형식" 규칙을 따른다. 인용이 비어 있으면 해당 항목은 ASSUMED 유지(승격 금지).
-- **근거 없음**으로 남기려면 (a) 어떤 키워드/구간을 봤는지, (b) 어떤 자료의 어떤 부분에서 부재를 확인했는지를 두 줄 이상 구체 명시한다. "탐색했으나 근거 없음" 한 줄로 종결하면 위반.
-- 비정형 자료(메일, 회의 대본, 메시지 본문)가 호출자(sd-wbs 등)에서 보고되었는데 표에 해당 자료 인용이 1건도 없으면, 끝까지 읽지 않은 신호로 간주하여 Step 2로 되돌아간다.
-- 보고 직후, 질문 대상이 남아 있으면 Step 5로 진행한다.
-
 ## Step 5: 명확화 질문
 
-재분류 후에도 **INFERRED Medium/Low** 또는 **ASSUMED**로 남은 항목은 **MUST** `.claude/rules/sd-options.md`의 지침에 따라 사용자에게 질문한다.
+재분류 후에도 **INFERRED Medium/Low** 또는 **ASSUMED**로 남은 항목은 **MUST** 사용자에게 질문한다.
 
+- 질문 방법: @.claude/rules/sd-options.md
 - VERIFIED와 INFERRED High는 명확한 것으로 본다.

package/claude/skills/sd-commit/SKILL.md

@@ -9,20 +9,12 @@ model: haiku
 ## 프로세스
 
 ```
-Step 1: 스테이징 및 Diff 수집 → Step 2: Diff 분석 → Step 3: 메시지 작성 → Step 4: 커밋
+Step 1: 스테이징 → Step 2: Diff 분석 → Step 3: 메시지 작성 → Step 4: 커밋
 ```
 
-## Step 1: 스테이징 및 Diff 수집
+## Step 1: 스테이징
 
-모든 변경사항을 스테이징하고 diff를 파일로 저장한다.
-
-```bash
-mkdir -p .tmp && git add -A && git diff --staged > ".tmp/$(date +%y%m%d%H%M%S)_commit.txt"
-```
-
-파일이 비어있으면 스테이징된 변경사항이 없는 것이다. 사용자에게 알리고 중단한다.
-
-생성된 파일을 Read하여 전체 변경 내역을 확인한다.
+`git add -A`로 모든 변경을 스테이징한다 (sd-commit은 전체 단일 커밋 정책이므로 "관련 파일만 add" 권고를 의도적으로 오버라이드).
 
 ## Step 2: Diff 분석
 

package/claude/skills/sd-debug/SKILL.md

@@ -106,7 +106,7 @@ LLM 디버깅의 주요 실패 모드와 차단 룰.
 - **최근 변경** — 언제부터 발생했는지, 관련 커밋
 - **출처** — GitHub 이슈에서 시작된 경우 `owner/repo#N` 형식. 그 외에는 `direct`
 
-누락 항목이 있으면 `/sd-inner-clarify` 스킬을 호출하여 명확화한다.
+누락 항목이 있으면 `/sd-clarify` 스킬을 호출하여 명확화한다.
 
 ## Phase 2: 재현 & 최소화
 

package/claude/skills/sd-deliverable/SKILL.md

@@ -1,7 +1,7 @@
 ---
 name: sd-deliverable
 description: 코드 분석 기반으로 사용자 매뉴얼(md)과 SIT 문서(md)를 생성·업데이트하는 스킬. "매뉴얼 만들어줘", "SIT 문서 만들어줘", "산출물 생성", "매뉴얼 업데이트" 등을 요청할 때 사용한다.
-model: haiku
+effort: low
 ---
 
 # sd-deliverable: 매뉴얼 & SIT 생성

package/claude/skills/sd-dev/SKILL.md

@@ -18,7 +18,6 @@ sd-wbs → sd-plan → sd-tdd → sd-check → sd-review를 순차 진행하는
 | wbs 경로만 (추가 요청 있음)          | → Step 2 (sd-wbs 업데이트)                                                     |
 | wbs + Feature 번호                   | → Step 3 (sd-plan)                                                             |
 | Feature 문서 경로                    | → Step 4 (sd-tdd). Slice 체크박스(`[x]`/`[ ]`)를 확인하여 진행 상태를 복원한다 |
-| `/sd-review`가 전달한 확정 이슈 목록 | → Step 3 (sd-plan: 리뷰 수정 Feature 문서 생성)                                |
 | 그 외 (자연어 요청, 참고자료 등)     | → Step 2 (sd-wbs)                                                              |
 
 ## Step 2: sd-wbs
@@ -31,12 +30,7 @@ sd-wbs → sd-plan → sd-tdd → sd-check → sd-review를 순차 진행하는
 ## Step 3: sd-plan
 
 `/sd-plan` 스킬을 즉시 수행한다. 완료 후 사용자 확인 없이 즉시 Step 4로 진행한다.
-
-`/sd-review`가 전달한 확정 이슈 목록으로 시작한 경우:
-
-- `/sd-wbs`를 수행하지 않는다.
-- 확정 이슈 목록 전체를 하나의 리뷰 수정 Feature로 보고 `/sd-plan`을 즉시 수행한다.
-- 이슈별 또는 근본 원인별 작업 단위는 WBS Feature가 아니라 Feature 문서의 Slice로 나눈다.
+단, Feature 문서의 Scenario 수가 10개를 초과하면 Step 4를 중단하고 `/sd-dev {Feature파일경로}`로 새 세션에서 진행하도록 안내한다.
 
 ## Step 4: sd-tdd
 

package/claude/skills/sd-plan/SKILL.md

@@ -7,43 +7,9 @@ description: Feature의 요구명세와 구현계획을 작성하는 스킬. "
 
 Feature 하나를 대상으로, WBS에서 확정된 고객 중심 What을 개발자 중심의 구현 가능한 명세와 구현계획(How)으로 변환한다.
 
-## 공통 규칙
-
-### WBS와 sd-plan의 역할 경계
-
-WBS는 고객 중심으로 **무엇을 만들어야 하는지(What)** 를 확정한 source of truth이다.
-sd-plan은 개발자 중심으로 **어떻게 만들지(How)** 를 결정한다.
-
-- sd-plan은 WBS에 없는 고객 동작, 업무 규칙, 정책, 예외 흐름을 새로 추가하지 않는다.
-- sd-plan에서 고객 중심 미확정 사항을 발견하면 기술 질문으로 처리하지 않는다.
-- 고객 중심 미확정 사항은 WBS 수정 대상으로 되돌리고, Feature 문서 생성과 구현계획 작성을 중단한다.
-- sd-plan에서 사용자에게 질문할 수 있는 항목은 기술 설계, 기존 코드 패턴 적용, 구현 구조, 테스트 분해처럼 How에 속하는 결정이다.
-
-### 정확성 우선 원칙
-
-부정확한 진행보다 과한 검증, 질문, 중단을 우선한다.
-
-- **NEVER: 근거 없는 설계 결정 금지.** 모든 설계 결정은 `WBS`, `사용자 답변`, `기준 코드`, `프로젝트 문서` 중 하나 이상의 근거를 가져야 한다.
-- **NEVER: 임시 가정 진행 금지.** 고객 동작, 업무 규칙, 정책, 예외 흐름, 수치, 권한, 상태, 기간, 열거값은 추정해서 확정 사항처럼 기록하지 않는다.
-- **MUST: 확정/미확정/설계 결정을 분리한다.** Feature 문서에는 확정 사항, 미확정/WBS 되돌림 사항, 기술 설계 결정을 서로 다른 섹션으로 기록한다.
-- **MUST: 추정은 최종 결정으로 남기지 않는다.** 추정이 필요한 항목은 미확정으로 분류하고, 고객 중심 항목이면 WBS 되돌림 절차로, How 항목이면 명확화 질문으로 처리한다.
-- **MUST: 사용자 답변의 구체 정보 보존.** 사용자가 답한 수치, 열거 항목, 정책, 예외 조건, 상태, 권한, 기간은 원문 의미를 유지해 Feature 문서에 근거와 함께 기록한다.
-
-### 범위 겹침
-
-어느 단계에서든 현재 Feature 범위가 다른 Feature 영역과 겹치는 것을 발견하면, 사용자에게 확인 후 조정한다.
-
-예: Feature 1.1 "사용자 인증"의 범위에 "권한 기반 접근 제어"가 있고 Feature 1.2가 "권한 관리"라면, "권한 기반 접근 제어"는 Feature 1.2로 이관이 적절할 수 있다.
-
 ## Step 1: 입력 확인
 
-다음 입력 중 하나가 필수이다.
-
-- wbs 문서 경로 + Feature 번호
-- `/sd-review`가 전달한 확정 이슈 목록
-
-wbs 문서 경로와 Feature 번호가 없더라도 `/sd-review` 전달 입력이면 종료하지 않고 Feature 문서 생성을 진행한다.
-그 외 입력이면 `/sd-wbs`를 안내하고 종료한다.
+`wbs 문서 경로 + Feature 번호`가 입력되지 않으면, `/sd-wbs`를 안내하고 종료한다.
 
 ## Step 2: Feature 분석
 
@@ -51,22 +17,31 @@ wbs 문서 경로와 Feature 번호가 없더라도 `/sd-review` 전달 입력
 
 wbs의 범위/경계를 기반으로 세분화하여 재분석한다. WBS의 고객 동작과 업무 규칙은 확정된 입력으로 취급한다.
 
-- **범위**: wbs의 세부 기능을 **구체적 동작 수준**으로 **MUST** 빠짐없이 재나열. WBS에 없는 고객 동작은 추가하지 않는다.
+- **범위**: wbs의 세부 기능을 구체적 동작 수준으로 빠짐없이 재나열. WBS에 없는 고객 동작은 추가하지 않는다.
 - **경계**: wbs의 경계를 확인하고, 모호한 부분을 구체화.
 - **근거**: 범위의 출처. 참조 파일/자료 경로가 있으면 기록.
 
-WBS에 없는 고객 동작, 업무 규칙, 정책, 예외 흐름이 필요하다고 판단되면 다음 절차를 따른다.
+모든 항목은 `/sd-clarify`스킬을 호출하여 명확화 한다.
+
+## 다른 Feature와 범위가 겹칠경우
 
-1. 해당 항목을 "WBS 미확정/누락"으로 분류한다.
-2. `/sd-inner-clarify`로 확정 질문을 수행한다. 확정될 때까지 반복한다.
-3. 확정되면 WBS 문서를 먼저 수정하고 즉시 종료한다. 사용자가 다시 `/sd-dev {wbs경로} {Feature번호}`를 실행해야 한다.
+어느 단계에서든 현재 Feature 범위가 다른 Feature 영역과 겹치는 것을 발견하면, `@.claude/rules/sd-options.md`의 규칙에 따라 사용자에게 확인 후 조정한다.
 
-**CRITICAL: WBS 미확정/누락을 발견한 상태에서 임시 가정으로 Feature 문서 생성이나 구현계획 작성을 계속하지 않는다.**
+### 예시
+
+Feature 1.1 "사용자 인증"의 범위에 "권한 기반 접근 제어"가 있고 Feature 1.2가 "권한 관리"라면, 다음과 같은 선택지가 있을 수 있다.
+
+- "권한 기반 접근 제어"는 Feature 1.2로 이관
+- "권한 기반 접근 제어"는 Feautre 1.1a로, 사용자 인증을 Feature 1.1b로 분할
+- 수행안함
+
+수행안함인경우 다음단계로 진행하고, 그 외의 경우 WBS 문서를 수정하고 즉시 종료한다.
 
 ### 세부 기능 5개 초과 시
 
-세부 기능 **5개 초과** 시 SPIDR(Spike / Path / Interface / Data / Rule) 축으로 분리안 제시 ("그대로 진행" 포함).
-- **CRITICAL: 분리 수락 시 wbs 문서를 수정하고 즉시 종료한다.**
+세부 기능 7개 초과 시 SPIDR(Spike / Path / Interface / Data / Rule) 축으로 Feature 분리안을 `@.claude/rules/sd-options.md`의 규칙에 따라 제시한다.
+
+- 분리 수락 시 wbs 문서를 수정하고 즉시 종료한다.
 
 ### 2-2. Rule / Example / Question
 
@@ -74,25 +49,25 @@ WBS에 없는 고객 동작, 업무 규칙, 정책, 예외 흐름이 필요하
 
 - **Rule**: WBS에서 확정된 업무 규칙 (검증 조건, 제약, 정책)
 - **Example**: Rule의 구체 사례 (입력 → 기대 결과)
-- **Question**: 구현계획 수립에 필요한 기술적 불확실성. 고객 동작/업무 규칙/정책/예외 흐름의 불확실성은 Question으로 남기지 않고 2-1의 WBS 되돌림 절차로 처리한다.
+- **Question**: 구현계획 수립에 필요한 불확실성.
 
-Rule과 Example은 반드시 확정 근거를 가져야 한다. 근거가 없는 Rule/Example은 작성하지 않고 WBS 미확정/누락 또는 기술적 Question으로 분류한다.
+Rule과 Example은 반드시 확정 근거를 가져야 한다. 근거가 없는 Rule/Example은 작성하지 않고 Question으로 분류한다.
 
-Question 도출 기법 — Feature 성격에 맞게 **하나 이상** 선택하고, 적용 기법명을 표기한다.
-도출된 빈칸이 고객 동작/업무 규칙/정책/예외 흐름이면 2-1의 WBS 되돌림 절차로 처리하고, 구현 방식에 관한 빈칸만 기술적 Question으로 남긴다.
+Question 도출 기법 — Feature 성격에 맞게 하나 이상 선택하고, 적용 기법명을 표기한다.
 
-| 기법                            | 적용 시점          | 방법                                      |
-|-------------------------------|----------------|-----------------------------------------|
-| **Decision Table**            | 조건 조합이 있을 때    | 조건 조합 나열 → 빈 칸을 WBS 되돌림 대상 또는 기술적 Question으로 분류 |
-| **Boundary Value Analysis**   | 숫자/범위가 있을 때    | 경계값 강제 → 미정의 경계를 WBS 되돌림 대상 또는 기술적 Question으로 분류 |
-| **Equivalence Partitioning**  | 입력 분류가 있을 때    | 입력 분류 나열 → 미정의 분류를 WBS 되돌림 대상 또는 기술적 Question으로 분류 |
-| **State Transition**          | 상태가 있는 Feature | 상태 x 이벤트 나열 → 미정의 전이를 WBS 되돌림 대상 또는 기술적 Question으로 분류 |
-| **Perspective-Based Reading** | 최종 검토 시        | 테스터/개발자/사용자 관점 검토 → 빠진 것을 WBS 되돌림 대상 또는 기술적 Question으로 분류 |
+| 기법                          | 적용 시점           | 방법                                                         |
+| ----------------------------- | ------------------- | ------------------------------------------------------------ |
+| **Decision Table**            | 조건 조합이 있을 때 | 조건 조합 나열 → 빈 칸을Question으로 분류                    |
+| **Boundary Value Analysis**   | 숫자/범위가 있을 때 | 경계값 강제 → 미정의 경계를 Question으로 분류                |
+| **Equivalence Partitioning**  | 입력 분류가 있을 때 | 입력 분류 나열 → 미정의 분류를 Question으로 분류             |
+| **State Transition**          | 상태가 있는 Feature | 상태 x 이벤트 나열 → 미정의 전이를 Question으로 분류         |
+| **Perspective-Based Reading** | 최종 검토 시        | 테스터/개발자/사용자 관점 검토 → 빠진 것을 Question으로 분류 |
 
 형식 — Rule별 그룹화, `[근거: ...]` 태그:
 
 ```markdown
 ### Rule: 제목은 필수 [근거: wbs "태스크 생성 시 제목 필수"]
+
 - Example: 제목 입력 → 저장 성공
 - Example: 제목 비움 → 에러
 - Question: 기존 입력 컴포넌트의 maxLength 처리 패턴?
@@ -100,10 +75,10 @@ Question 도출 기법 — Feature 성격에 맞게 **하나 이상** 선택하
 
 ### 2-3. 명확화
 
-`/sd-inner-clarify` 스킬을 호출하여 기술적 Question과 기타 How 불명확성을 명확화한다.
-답변에 따라 Rule/Example/Question을 갱신하며, 모든 Question이 해소될 때까지 **MUST** 반복한다. (추가 Question 발생 가능)
+`@.claude/rules/sd-options.md`의 규칙에 따라 Question 불명확성을 명확화한다.
+답변에 따라 Rule/Example/Question을 갱신하며, 모든 Question이 해소될 때까지 반복한다. (추가 Question 발생 가능)
+
 - **나쁜 예:** "예약 기능 포함이 결정됨 → 예약 세부규칙(대기열 정책, 미대출 시 자동취소 기간)도 확정" — 기능 포함 여부와 세부 수치/규칙은 별개다. 세부사항은 별도로 분류·질문한다.
-- **나쁜 예:** "WBS에 제목 최대 길이가 없으니 sd-plan에서 100자로 결정" — 고객/업무 규칙이므로 WBS 되돌림 절차로 처리한다.
 
 해소된 기술 결정사항은 `### 설계 결정` 테이블에 기록 (D1, D2, ... 순번 부여)
 각 설계 결정은 `결정사항`, `선택`, `근거 유형`, `근거`를 기록한다. 근거 유형은 `WBS`, `사용자 답변`, `기준 코드`, `프로젝트 문서` 중 하나 이상이어야 한다.
@@ -133,6 +108,7 @@ Feature: {번호} {이름}
 코드베이스에서 이 Feature와 **가장 유사한 기존 기능**을 찾는다. 유사 기능이란 동일한 도메인, 비슷한 CRUD 패턴, 유사한 UI 흐름 등을 공유하는 기능이다.
 
 탐색 대상:
+
 - 관련 엔티티/모델 구조
 - 기존 API 엔드포인트 및 패턴
 - UI 컴포넌트 구조, **레이아웃·생김새 (HTML 골격, CSS 클래스 네이밍, 컨트롤 배치, 스타일 토큰)**, 라우팅
@@ -146,15 +122,18 @@ Feature: {번호} {이름}
 
 ```markdown
 ### 기준 코드
+
 (이 Feature 구현 시 따라야 할 기존 코드 패턴)
 
 #### 유사 기능: {기능명}
+
 - 엔티티: `src/models/xxx.ts:15` — {구조 요약}
 - API: `src/services/xxx-service.ts:42` — {패턴 요약}
 - UI: `src/views/xxx.component.ts:10` — {구조 요약}
 - 테스트: `tests/xxx.spec.ts:5` — {패턴 요약}
 
 #### 프로젝트 컨벤션
+
 - 네이밍 (파일·클래스·함수·변수): {관찰된 패턴} [근거: `파일경로:라인번호`]
 - 디렉토리 구조 / 파일 배치: {관찰된 패턴} [근거: `파일경로:라인번호`]
 - 에러 처리: {관찰된 패턴} [근거: `파일경로:라인번호`]
@@ -186,30 +165,42 @@ Feature: {번호} {이름}
 
 ```markdown
 ### 배경
+
 (이 Feature를 구현하는 기술적 맥락. 기준 코드의 관련 구조 인용)
+
 ### 목표
+
 - 기술적 목표 [근거: Rule "..."]
+
 ### 비목표
+
 - 의도적 제외 항목 [근거: wbs 경계 "..."]
+
 ### 설계
+
 - API, 엔티티, 검증 규칙, UI 구조 등 [근거: Rule "..." 처리를 위해, 기준 코드 `파일경로:라인번호` 패턴 준수]
+
 ### 대안 검토
+
 (고려했으나 선택하지 않은 접근 방식과 그 이유. 기존 패턴과 다른 방식을 제안할 경우 필수)
 ```
 
 ### Vertical Slicing
 
 Gherkin Scenarios를 구현 단위(Slice)로 분할한다.
+
 - 구현 규모(코드 변경량·복잡도) 기준 (Rule과 1:1 아님)
 - 각 Slice에 Scenario 매핑 (1:N)
 - Slice 간 의존 관계로 순서 결정
 
 ```markdown
 #### [ ] Slice 1: (제목)
+
 - **구현 내용:** (요약)
 - **Scenarios:** ...
 
 #### [ ] Slice 2: (제목)
+
 - **의존:** Slice 1
 - **구현 내용:** (요약)
 - **Scenarios:** ...
@@ -224,48 +215,112 @@ Gherkin Scenarios를 구현 단위(Slice)로 분할한다.
 # Feature {번호} {이름}
 
 ## 참조 자료
-- WBS: @{wbs 문서 상대경로}
-{수집한 구체적 정보 — 참조 파일 경로는 `@path` 형태로 기록}
-
-## 확정/미확정 구분
 
-### 확정 사항
-- {WBS 또는 사용자 답변으로 확정된 고객 동작/업무 규칙/정책/수치/예외} [근거: ...]
-
-### 미확정/WBS 되돌림
-- 없음
+- WBS: @{wbs 문서 상대경로}
+  {수집한 구체적 정보 — 참조 파일 경로는 `@path` 형태로 기록}
 
 ## 기준 코드
+
 {Step 4에서 작성한 기준 코드 섹션}
 
 ### 설계 결정
-| # | 결정사항 | 선택 | 근거 유형 | 근거 |
+
+| # | 결정사항 | 선택 | 근거 |
 
 ## 요구명세
+
 {Gherkin}
 
 ## 구현계획
+
 {Tech Design + Slicing}
 ```
 
-## Step 7: 정보 유실 방지 검증
+## Step 7: 격리 검증 (정보 유실·누락 점검)
+
+문서 작성 후, 작성자 편향 제거와 정보 유실 차단을 위해 메인 세션과 분리된 subagent로 격리 검증을 수행한다.
+
+### 검증 호출
+
+`Agent` tool로 `subagent_type: "general-purpose"`, `model: "haiku"`를 호출한다.
+
+subagent에 전달할 입력:
+
+- **Feature 문서 절대 경로** — Step 6에서 작성한 검증 대상
+- **WBS 문서 절대 경로** — Step 1에서 받은 WBS
+- **사용자 초기 요청 메시지 본문** — 프롬프트에 인라인 삽입 (sd-plan 호출 시 함께 받은 모든 컨텍스트 원문)
+
+사용자 명확화 답변·결정사항은 Feature 문서의 `### 설계 결정` 표와 `[근거: ...]` 태그에 반영되어 있으므로 별도 전달하지 않는다.
+
+subagent에 부여할 제약: "보고만 수행. Feature 문서를 수정하지 말 것."
+
+### subagent 프롬프트에 포함할 검증 가이드
 
-문서 작성 후, 대화에서 수집한 모든 구체적 정보가 문서에 기록되었는지 검증한다.
+#### 검증 항목 (8가지 모두 수행)
 
-- 사용자의 답변에 포함된 구체적 수치, 열거 항목, 업무 규칙, 제약 조건, 정책, 예외 조건, 상태 전이, 권한, 기간, 시간대, 검증 경계값, 오류 동작이 누락 없이 Feature 문서에 기록되었는가?
-- 언급된 참조 파일/문서 경로가 확인 목적과 함께 기록되었는가?
-- `확정 사항`, `미확정/WBS 되돌림`, `설계 결정`이 서로 섞이지 않고 분리되었는가?
-- 모든 Rule, Example, Scenario, 설계 결정, 구현계획 항목이 근거를 가지는가?
-- 근거 없는 "일반적으로", "기본값", "통상", "아마", "추정" 표현이 확정처럼 남아 있지 않은가?
-- 누락 발견 시 문서에 반영한 뒤 저장한다.
+1. **대화 정보 ↔ 문서 매핑 (정량 매핑 표 + 의역 변형 검출)**
+   - 사용자 초기 요청에 포함된 구체적 정보(수치·열거값·업무 규칙·제약·정책·예외·상태 전이·권한·기간·시간대·경계값·오류 동작·참조 경로)가 Feature 문서의 `참조 자료`·`### 설계 결정`·`Rule`·`Example`·`Gherkin`·`구현계획` 중 한 곳 이상에 반영되었는가?
+   - **정량 매핑 표 작성**: `원본 표현` / `출처(메시지 위치)` / `Feature 문서 반영 위치` / `Feature 문서 표현`. 반영 위치가 비어 있으면 누락 항목.
+   - **의역 변형 검출**: 원문이 구체적인데 Feature 문서가 추상화된 사례 (예: 원문 "최대 100건" → 문서 "다수 항목", 원문 "월요일 오전 9시" → 문서 "주 1회").
+
+2. **WBS ↔ Feature 역추적성**
+   WBS의 해당 Feature 세부기능·경계 항목 각각이 Feature 문서의 `요구명세` 또는 `구현계획`에 매핑되어 있는가?
+
+3. **Example ↔ Scenario 매핑**
+   `Rule:` 하위 모든 Example이 Gherkin `Scenario:`로 1:1 매핑되는가?
+
+4. **설계 결정 번호 무결성**
+   `### 설계 결정` 표의 D1..Dn 일련번호에 누락·중복·역순이 없는가?
+
+5. **Slice 의존성 실재 검증**
+   각 Slice의 `의존:` 항목이 같은 문서에 실제 존재하는 Slice 번호를 가리키는가?
+
+6. **추상 표현 검출**
+   Feature 문서 본문에 `TBD|추후|적절히|기본(?:값)?|일반적으로|통상|아마|추정|등등` 표현이 잔존하는가? (예시·인용·정규식 본문 제외)
+
+7. **근거 태그 누락**
+   `Rule:`, `Example:`, `### 설계 결정` 행, `### 설계` 항목, Slice 항목 각각에 `[근거: ...]` 또는 등가 태그가 있는가?
+
+8. **참조 경로 실재 검증**
+   문서에 인용된 `파일경로:라인번호`, `@path` 형태의 경로가 실제 파일 시스템에 존재하는가? (Read/Glob 도구로 확인. 라인번호는 파일 라인 수 이내인지만 확인)
+
+#### 완독 의무
+
+사용자 초기 요청 메시지·WBS 문서·Feature 문서는 끝까지 읽는다. 키워드 검색만으로 종결하지 않는다.
+
+#### 출력 포맷
+
+subagent는 다음 구조의 보고서를 작성한다.
+
+- **요약 표** — 8개 항목 각각 PASS/FAIL
+- **정량 매핑 표** (항목 1) — 컬럼: `원본 표현` / `출처` / `Feature 문서 위치` / `Feature 문서 표현`. 반영 위치가 비어 있으면 누락 항목.
+- **항목별 FAIL 상세**
+  - 항목 1: 누락 / 의역 변형 의심 — `[출처] 원문: "..." → 권장 반영 위치: Feature 섹션·라인`
+  - 항목 2: WBS 미매핑 — `[WBS 위치] 항목: "..." → Feature 문서 미반영`
+  - 항목 3: Example 미매핑 — `Rule "..." Example "..." → Scenario 없음`
+  - 항목 4: 번호 결함 — `D# 누락/중복/역순 위치`
+  - 항목 5: Slice 의존 무효 — `Slice N: 의존 "M" 실재 안 함`
+  - 항목 6: 추상 표현 잔존 — `Feature 문서 라인 N: "..."`
+  - 항목 7: 근거 태그 누락 — `Feature 문서 라인 N: "..."`
+  - 항목 8: 참조 경로 무효 — `Feature 문서 라인 N: "경로:라인" → 실재 안 함`
+
+### 메인의 결과 처리
+
+1. subagent 보고서의 **각 FAIL 항목**에 대해 `/sd-clarify`로 사용자에게 명확화 질문한다.
+   - 결정 대상: 반영 여부 / 반영 위치 / 표현 정확도
+   - 답변에 따라 Feature 문서를 메인이 직접 수정한다.
+2. 모든 명확화·반영이 끝나면 동일 subagent를 재호출하여 모든 항목 PASS를 확인한 후 Feature 문서 최종 저장.
+
+**CRITICAL: 각 Slice는 sd-tdd로 구현되므로, 절대(NEVER) Feature 문서에 누락이 있어서는 안됨**
 
 ## Step 8: 역방향 피드백
 
 wbs 문서에 변경/발견 사항을 반드시 반영한다. 누락/불일치 수정을 생략하지 않는다.
+
 - 범위 축소/확대, 경계 재조정, Feature 간 범위 이관 등 고객 중심 What에 해당하는 변경만 반영한다.
 - API 형태, DB 구조, UI 컴포넌트 구조, 테스트 Slice 같은 How 결정은 WBS에 기록하지 않고 Feature 문서의 `### 설계 결정`과 `## 구현계획`에만 기록한다.
-문서 간 정합성을 유지하고 변경 사유를 명확히 작성한다.
-역방향 피드백의 목적은, 새로운 세션에서 다른 작업을 수행할때 이 세션의 결정사항을 잊지 않고 이어서 하기 위함이다.
+  문서 간 정합성을 유지하고 변경 사유를 명확히 작성한다.
+  역방향 피드백의 목적은, 새로운 세션에서 다른 작업을 수행할때 이 세션의 결정사항을 잊지 않고 이어서 하기 위함이다.
 
 ## Step 9: 다음 단계 안내
 

package/claude/skills/sd-prompt/SKILL.md

@@ -34,7 +34,7 @@ Step 1~5는 장기 프로세스이다. 스킬 시작 시점에 각 Step을 `Task
 - **입력**: 무엇을 받는가
 - **출력**: 무엇을 내놓는가
 
-`/sd-inner-clarify` 스킬을 호출하여 명확화한다.
+`/sd-clarify` 스킬을 호출하여 명확화한다.
 
 ## Step 2: Eval 시나리오 정의
 
@@ -215,7 +215,7 @@ Judge 보고서의 개선 제안에 대해:
   - B의 세부 절차는 B 스킬 원문 참조 또는 호출로 대체한다
   - B 호출이 depth 제한을 초과하면 호출 구조 자체를 사용자에게 선택지로 제시한다
 
-발견된 Prompt Smell에 대해 `/sd-inner-clarify` 스킬을 호출하여 진행여부와 방법을 명확화하여 수정한다.
+발견된 Prompt Smell에 대해 `/sd-clarify` 스킬을 호출하여 진행여부와 방법을 명확화하여 수정한다.
 위임 경계 침범을 리포트할 때는 호출자 스킬, 호출 대상 스킬, 호출자에 복제된 대상 스킬 책임, 남길 계약 정보, 제거·이동할 세부 절차를 포함한다.
 
 ### Regression Guard

package/claude/skills/sd-refactor/SKILL.md

@@ -16,7 +16,7 @@ sd-refactor는 "구조 개선 방향 제안"(패키지/아키텍처 수준)에
 - **린터/타입체커 영역**: 타입 누락, `any` 사용, 미사용 변수, 코드 스타일
 - **거짓 양성**: 프레임워크가 요구하는 패턴, 프로젝트 컨벤션에 의한 의도적 구조
 
-이슈가 의도된 설계인지 불확실하거나, 제안이 기존 기능의 동작 변경을 수반하는 경우 `/sd-inner-clarify` 스킬을 호출하여 명확화한다. 사용자 확인 없이 기능 변경을 리포트에 포함하지 않는다.
+이슈가 의도된 설계인지 불확실하거나, 제안이 기존 기능의 동작 변경을 수반하는 경우 `/sd-clarify` 스킬을 호출하여 명확화한다. 사용자 확인 없이 기능 변경을 리포트에 포함하지 않는다.
 
 ## Step 1: 대상 결정
 
@@ -95,7 +95,7 @@ Step 3에서 탐지된 이슈를 사용자에게 제시하기 전에 거짓 양
 각 이슈에 대해:
 1. **코드 재대조**: 해당 위치의 코드를 Read 도구로 **반드시 다시 읽고**, 이슈가 실제로 존재하는지 확인한다. 거짓 양성으로 판단된 이슈는 제거한다.
 2. **중복 이슈 병합**: 동일 근본 원인에서 파생된 이슈를 하나로 병합한다.
-3. **명확화 판단**: 코드 주석·변수명 등에 의도적 설계를 시사하는 표현("의도적", "팀 규칙", "컨벤션" 등)이 있는 경우, 해당 이슈를 제외하기 전에 반드시 `/sd-inner-clarify` 스킬을 호출하여 분류를 수행한다. 코드 주석만으로는 VERIFIED가 아니며, CLAUDE.md나 공식 문서에 근거가 없으면 INFERRED Medium 이하로 분류한다.
+3. **명확화 판단**: 코드 주석·변수명 등에 의도적 설계를 시사하는 표현("의도적", "팀 규칙", "컨벤션" 등)이 있는 경우, 해당 이슈를 제외하기 전에 반드시 `/sd-clarify` 스킬을 호출하여 분류를 수행한다. 코드 주석만으로는 VERIFIED가 아니며, CLAUDE.md나 공식 문서에 근거가 없으면 INFERRED Medium 이하로 분류한다.
 
 검증을 통과한 이슈만 Step 5로 진행한다.
 

package/claude/skills/sd-review/SKILL.md

@@ -13,7 +13,7 @@ description: 정적 분석이 잡지 못하는 관점(로직 버그, 일관성,
 - `review.md` 같은 별도 리뷰 파일을 생성하지 않는다.
 - 확정 이슈 목록은 대화 맥락으로 `/sd-dev`에 전달한다.
 - `/sd-dev`의 마지막 단계에서 호출된 경우, 기존 `/sd-dev` 실행은 `/sd-review` 호출 시점에 종료된 것으로 본다.
-- 이슈 여부가 명확하지 않으면 `/sd-inner-clarify`로 명확화하고, 해소되지 않은 항목은 확정 이슈로 넘기지 않는다.
+- 이슈 여부가 명확하지 않으면 `/sd-clarify`로 명확화하고, 해소되지 않은 항목은 확정 이슈로 넘기지 않는다.
 
 ## Step 1: 대상 결정
 
@@ -154,8 +154,8 @@ Step 3에서 탐지된 이슈를 하나씩 순회하며, 해당 위치의 코드
 
 ## Step 5: 남은 이슈 명확화
 
-Step 4를 통과한 이슈를 최종 이슈로 확정하기 전에 `/sd-inner-clarify`에 전달한다.
-명확성 분류, 근거 탐색, 재분류 보고, 사용자 질문 여부는 `/sd-inner-clarify`의 기준을 따른다.
+Step 4를 통과한 이슈를 최종 이슈로 확정하기 전에 `/sd-clarify`에 전달한다.
+명확성 분류, 근거 탐색, 재분류 보고, 사용자 질문 여부는 `/sd-clarify`의 기준을 따른다.
 
 ### 전달 내용
 
@@ -167,7 +167,7 @@ Step 4를 통과한 이슈를 최종 이슈로 확정하기 전에 `/sd-inner-cl
 - Severity 후보: Critical / Medium / Low
 - Step 4에서 확인한 검증 근거와 남은 불확실성
 
-`/sd-inner-clarify` 결과 사용자가 제외하기로 선택한 이슈는 Step 6 최종 이슈 목록에서 제거한다.
+`/sd-clarify` 결과 사용자가 제외하기로 선택한 이슈는 Step 6 최종 이슈 목록에서 제거한다.
 이슈 여부가 해소되지 않은 항목이 남아 있으면 Step 6으로 진행하지 않는다.
 
 ## Step 6: 이슈 정리

package/claude/skills/sd-tdd/SKILL.md

@@ -1,7 +1,6 @@
 ---
 name: sd-tdd
 description: 구현계획(plan) 기반으로 TDD 개발하는 스킬
-effort: medium
 ---
 
 # sd-tdd: TDD 개발
@@ -64,7 +63,7 @@ Feature 문서 및 WBS 문서의 `## 참조 자료` 섹션 및 그 하위섹션
 
 ### 1-3. 문서 정합성 확인
 
-요구명세의 각 Scenario에서 참조하는 기능·메서드를 구현계획과 대조한다. 다음과 같은 불명확한 부분이 있으면 `/sd-inner-clarify` 스킬을 호출하여 명확화한다:
+요구명세의 각 Scenario에서 참조하는 기능·메서드를 구현계획과 대조한다. 다음과 같은 불명확한 부분이 있으면 `/sd-clarify` 스킬을 호출하여 명확화한다:
 
 - Scenario가 참조하는 메서드/기능이 구현계획의 Slice에 등장하지 않음
 - 요구명세의 용어와 구현계획의 용어가 서로 다름 (동일 개념을 다른 이름으로 지칭)
@@ -110,7 +109,7 @@ Acceptance Test는 Feature의 **외부 계약**을 도메인 언어로 검증한
    - **스펙 충돌**: 이번 Feature의 요구명세와 다른 동작을 기대 → 스펙에 맞게 선수정
    - **실제 버그**: 기존 구현의 버그를 미검증 → 이번 Feature 범위 내면 수정, 범위 밖이면 사용자에게 보고 후 판단
    - **무관**: 이번 Scenario와 무관한 동작 검증 → 건드리지 않음
-3. 판단이 모호하면 `/sd-inner-clarify`로 명확화한다.
+3. 판단이 모호하면 `/sd-clarify`로 명확화한다.
 4. 선수정이 끝난 뒤 새 Acceptance Test 작성으로 진행한다.
 
 #### Gherkin Scenario 변환

package/claude/skills/sd-wbs/SKILL.md

@@ -8,6 +8,35 @@ description: 프로젝트 요구사항을 Feature 단위로 분해하는 스킬.
 WBS는 고객 중심으로 **무엇을 만들어야 하는지(What)** 를 확정하는 산출물이다.
 Feature 범위에는 이후 `/sd-dev`가 바로 시작되어도 해석이 갈리지 않는 고객 동작과 업무 규칙만 남긴다.
 
+## What/How 경계
+
+비즈니스 요구사항(What)에 대해 분석한다.
+
+- 기술적 구현 방법(How) — 인증 방식, 통신 프로토콜, 프레임워크, 아키텍처 패턴 등에 대한 결정은 이 단계의 범위가 아니다.
+- `/sd-clarify` 스킬을 호출하여 명확화한다.
+
+### What/How 분류 규칙 (CRITICAL)
+
+**다음 항목은 sd-wbs에서 반드시 확정한다 — sd-plan으로 위임 금지(NEVER):**
+
+- 고객/사용자 동작, 업무 규칙, 정책, 예외 흐름
+- 수치(최대/최소/기본값/허용 범위), 기간, 시간대, 경계값
+- 권한, 역할, 상태, 상태 전이, 열거값(enum 후보)
+- 화면/플로우의 분기 조건과 결과
+- 기능 포함 여부 자체
+
+**다음 항목은 sd-plan에서 결정한다 — sd-wbs에서 묻지 않는다:**
+
+- 인증 방식, 통신 프로토콜, 프레임워크, 아키텍처 패턴
+- DB 종류, API 형태, 컴포넌트 구조, 테스트 분해
+- 라이브러리 선택, 의존성 주입, import 패턴
+
+**분류가 모호하면 What으로 분류한다 (default = sd-wbs 확정 대상).**
+
+- "plan에서 결정될 것 같다"는 자체 판단으로 위임 금지(NEVER).
+- "어차피 sd-plan이 WBS 미확정/누락을 되돌릴 것이다"는 안전망 의존 금지(NEVER). 그 절차는 sd-wbs의 누락을 잡는 백업이지, sd-wbs의 책임을 다음 단계로 떠넘기는 경로가 아니다.
+- 모호한 항목은 `/sd-clarify`로 사용자에게 직접 질문하여 What/How를 확정한다.
+
 ## Step 1: 요구사항 수집
 
 사용자가 제공한 요구사항에 대한 분석을 시작한다.
@@ -20,8 +49,6 @@ Feature 번호 변경이 필요한 경우 기존 번호 → 새 번호 매핑과
 
 ### 원본 완독 보고 (CRITICAL)
 
-`/sd-inner-clarify`를 호출하기 **전에 반드시** 다음 보고를 출력한다. 보고 없이 명확화 단계로 진입하는 것은 **금지(NEVER)**.
-
 **[원본 분석 보고]** 형식:
 
 - 자료 1: `{파일경로 또는 메시지 영역}` ({분량: 페이지/라인/메일 통수 등}) — 완독 여부: [완독 | 부분({읽지 못한 구간})]. 핵심 발화/구절 요약: ...
@@ -33,53 +60,24 @@ Feature 번호 변경이 필요한 경우 기존 번호 → 새 번호 매핑과
 - **메일 thread**: 모든 통수를 명시하고 각각 읽었음을 확인한다. 발신자/수신자/제목/일시를 식별 가능하게 적는다.
 - **회의 대본**: 발화자 단위로 핵심 결정·요구를 추출한다. "전체 봄"으로 종결하면 위반.
 - **분량 명시**: 각 자료의 페이지/라인/통수 등 분량을 객관 수치로 출력하여 부분 독해를 표면화한다.
-- **부분 독해 금지**: "부분"으로 보고된 자료가 있으면 추가 읽기를 수행하여 완독 상태로 전환한다. 부분 상태로 `/sd-inner-clarify` 진입 금지.
+- **부분 독해 금지**: "부분"으로 보고된 자료가 있으면 추가 읽기를 수행하여 완독 상태로 전환한다. 부분 상태로 `/sd-clarify` 진입 금지.
 - **사용자 메시지 본문 포함**: 메시지에 직접 붙여넣어진 요구사항·예시·제약도 자료로 취급하여 보고에 포함한다.
 
-이 보고가 출력된 뒤에만 `/sd-inner-clarify` 스킬을 호출하여 명확화한다.
-
 ## Step 2: Impact Mapping
 
 Impact Mapping 트리(Goal → Actor → Impact → Deliverable)를 구축한다.
 
-### What/How 경계
-
-비즈니스 요구사항(What)에 대한 분석만 한다.
-
-- 기술적 구현 방법(How) — 인증 방식, 통신 프로토콜, 프레임워크, 아키텍처 패턴 등 — 에 대한 결정은 분석 단계에서 하지 않는다.
-- `/sd-inner-clarify` 스킬을 호출하여 명확화한다.
-
-#### What/How 분류 규칙 (CRITICAL)
-
-**다음 항목은 sd-wbs에서 반드시 확정한다 — sd-plan으로 위임 금지(NEVER):**
-
-- 고객/사용자 동작, 업무 규칙, 정책, 예외 흐름
-- 수치(최대/최소/기본값/허용 범위), 기간, 시간대, 경계값
-- 권한, 역할, 상태, 상태 전이, 열거값(enum 후보)
-- 화면/플로우의 분기 조건과 결과
-- 기능 포함 여부 자체
-
-**다음 항목은 sd-plan에서 결정한다 — sd-wbs에서 묻지 않는다:**
-
-- 인증 방식, 통신 프로토콜, 프레임워크, 아키텍처 패턴
-- DB 종류, API 형태, 컴포넌트 구조, 테스트 분해
-- 라이브러리 선택, 의존성 주입, import 패턴
-
-**분류가 모호하면 What으로 분류한다 (default = sd-wbs 확정 대상).**
-
-- "plan에서 결정될 것 같다"는 자체 판단으로 위임 금지(NEVER).
-- "어차피 sd-plan이 WBS 미확정/누락을 되돌릴 것이다"는 안전망 의존 금지(NEVER). 그 절차는 sd-wbs의 누락을 잡는 백업이지, sd-wbs의 책임을 다음 단계로 떠넘기는 경로가 아니다.
-- 모호한 항목은 `/sd-inner-clarify`로 사용자에게 직접 질문하여 What/How를 확정한다.
-
 ### 명확화 항목
 
-| 질문                       | 도출 요소          |
-|--------------------------|----------------|
-| Q1. "왜 만드나?" 반복          | Goal (측정 가능하게) |
-| Q2. "누가 쓰나? 누가 영향받나?"    | Actor          |
-| Q3. "그 사람 행동이 어떻게 바뀌어야?" | Impact (행동 변화) |
-| Q4. "가장 단순하게 뭘 만들면?"     | Deliverable    |
-| Q5. "뭘 빼나?"              | 제외 사항          |
+모든 항목은 `/sd-clarify`스킬을 호출하여 명확화 한다.
+
+| 질문                                  | 도출 요소            |
+| ------------------------------------- | -------------------- |
+| Q1. "왜 만드나?" 반복                 | Goal (측정 가능하게) |
+| Q2. "누가 쓰나? 누가 영향받나?"       | Actor                |
+| Q3. "그 사람 행동이 어떻게 바뀌어야?" | Impact (행동 변화)   |
+| Q4. "가장 단순하게 뭘 만들면?"        | Deliverable          |
+| Q5. "뭘 빼나?"                        | 제외 사항            |
 
 **나쁜예:**
 
@@ -188,14 +186,14 @@ Feature는 독립적으로 설계·개발·검증할 수 있는 최소 **기능*
 - **나쁜 예:** 검색 기능
 - **나쁜 예:** 도서 목록 개선
 
-항목별 근거가 없는 범위는 Feature에 포함하지 않는다. 필요해 보이지만 근거가 없으면 `/sd-inner-clarify`로 포함 여부를 질문한다.
+항목별 근거가 없는 범위는 Feature에 포함하지 않는다. 필요해 보이지만 근거가 없으면 `/sd-clarify`로 포함 여부를 질문한다.
 
 ### 미확정 요구 처리 규칙
 
 **CRITICAL: Feature 범위에는 구현자가 바로 `/sd-dev`로 들어가도 해석이 갈리지 않는 확정된 고객 동작과 업무 규칙만 남긴다.**
 
 - WBS Feature 안에는 "후속 확정", "보류", "추후 결정", "협의 필요" 같은 미확정 usecase를 넣지 않는다.
-- 원문에 미확정이라고 적힌 고객 요구, 업무 규칙, 정책, 예외 흐름은 WBS 작성 시점에 `/sd-inner-clarify`로 질문하여 **확정될 때까지 반복**한다. 추정 진행이나 "추후 결정" fallback은 금지(NEVER).
+- 원문에 미확정이라고 적힌 고객 요구, 업무 규칙, 정책, 예외 흐름은 WBS 작성 시점에 `/sd-clarify`로 질문하여 **확정될 때까지 반복**한다. 추정 진행이나 "추후 결정" fallback은 금지(NEVER).
 - 사용자가 명시적으로 "포함 안 함"으로 결정한 항목만 "제외 사항"에 기재한다.
 - Feature의 범위 항목은 완료 판정 가능한 사용자 동작으로만 작성하고, 각 항목에 출처를 남긴다.
 - 기술 구현 방식(API 형태, DB 구조, 프레임워크, 테스트 분해 등)은 WBS에서 결정하지 않는다. 해당 결정은 `/sd-plan`에서 다룬다.
@@ -218,7 +216,8 @@ Feature는 독립적으로 설계·개발·검증할 수 있는 최소 **기능*
 
 ---
 
-각 Feature의 세부 사항을 분류하고 `/sd-inner-clarify` 스킬을 호출하여 불명확한 부분을 명확화한다.
+각 Feature의 세부 사항을 분류하고 `/sd-clarify` 스킬을 호출하여 불명확한 부분을 명확화한다.
+
 - **나쁜 예:** "예약 기능 포함이 결정됨 → 예약 세부규칙(대기열 정책, 미대출 시 자동취소 기간)도 확정" — 기능 포함 여부와 세부 수치/규칙은 별개다. 세부사항은 별도로 분류·질문한다.
 
 ### Feature-Deliverable 역추적 강제 규칙
@@ -228,7 +227,7 @@ Feature는 독립적으로 설계·개발·검증할 수 있는 최소 **기능*
 Feature를 작성하다가 "이건 시스템 동작상 당연히 필요하다"는 판단이 드는데 Impact Mapping Deliverable로 역추적 불가한 경우(예: 사용자 계정 관리, 권한 설정, 로그, 알림 설정 등 Impact Mapping에는 없지만 실행에 필요해 보이는 기능):
 
 1. **절대 혼자 추가하지 않는다(NEVER).** "당연히 필요하다"는 추측으로 Feature를 임의 추가하거나 제외 사항에 자체 결정을 기재하는 것은 금지.
-2. **반드시 `/sd-inner-clarify`를 호출**하여 해당 기능을 포함할지 질문한다. 질문 형식:
+2. **반드시 `/sd-clarify`를 호출**하여 해당 기능을 포함할지 질문한다. 질문 형식:
    - 결정 대상: "{기능명}"을 시스템에 포함할지
    - 선택지: 포함 / 미포함 / 수행 안 함
 3. **포함으로 결정되면** Step 2로 돌아가 Impact Mapping에 해당 Deliverable을 먼저 추가한 뒤, Feature를 작성한다.
@@ -251,11 +250,11 @@ Feature를 작성하다가 "이건 시스템 동작상 당연히 필요하다"
 4. **Feature 독립성 (단일 책임)** — 한 Feature의 이름과 실제 범위가 일치하는지 확인한다. 이름에 드러나지 않는 일을 몰래 수행하면 분리한다.
 5. **병합 규칙 준수** — Step 3 "Feature 병합 규칙"의 기계적 판정 규칙을 위반하는 Feature가 없는지 확인한다.
 6. **범위 항목의 검증 가능성** — 각 세부 기능이 완료 판정 가능한 구체적 표현인지 확인한다. "개선한다", "최적화한다" 같은 모호한 표현은 구체 동작으로 재작성한다.
-7. **미확정 요구 제거** — "후속 확정", "보류", "추후 결정", "협의 필요" 같은 표현이 Feature 범위/경계/근거에 남아 있으면 `/sd-inner-clarify`로 확정 질문을 수행하여 모두 확정 처리한다.
-8. **범위 항목별 근거 확인** — 모든 범위 항목 끝에 `(근거: ...)`가 있는지 확인한다. 근거가 없는 항목은 `/sd-inner-clarify`로 확정 처리한다.
+7. **미확정 요구 제거** — "후속 확정", "보류", "추후 결정", "협의 필요" 같은 표현이 Feature 범위/경계/근거에 남아 있으면 `/sd-clarify`로 확정 질문을 수행하여 모두 확정 처리한다.
+8. **범위 항목별 근거 확인** — 모든 범위 항목 끝에 `(근거: ...)`가 있는지 확인한다. 근거가 없는 항목은 `/sd-clarify`로 확정 처리한다.
 9. **plan 위임 차단** — Feature 범위/경계/근거에 "plan에서 결정", "구현 시 결정", "추후 결정", "협의 필요", "별도 확정" 같은 표현이나 sd-plan으로 위임 대기 중인 항목이 남아 있는지 점검한다. 발견 시 다음 절차를 수행한다.
    - Step 2 "What/How 분류 규칙"에 따라 해당 항목의 영역을 재분류한다.
-   - **What으로 분류되면** `/sd-inner-clarify`로 확정 질문을 강제하고, 답변을 받아 Feature 범위에 반영한다.
+   - **What으로 분류되면** `/sd-clarify`로 확정 질문을 강제하고, 답변을 받아 Feature 범위에 반영한다.
    - **How로 분류되면** 해당 항목을 Feature 범위에서 제거하고, 경계 또는 근거에 "sd-plan에서 결정"임을 명시한다.
    - **"plan으로 미루기" 표현을 그대로 남기는 것은 금지(NEVER).**
 
@@ -341,16 +340,71 @@ Feature를 작성하다가 "이건 시스템 동작상 당연히 필요하다"
 
 - 사용자가 명시적으로 "포함 안 함"으로 결정한 항목과 Impact Mapping에서 Goal에 연결되지 않는 기능을 나열한다.
 - 각 항목은 `제외 항목 — 사유: ... / 출처: ... / 재검토 조건: ...` 형식으로 작성한다.
-- 사유에는 Goal 미연결, 사용자 명시적 제외, 범위 초과 중 하나를 사용한다. "미확정"은 사유로 사용하지 않는다 (미확정은 `/sd-inner-clarify`로 반드시 확정 처리).
+- 사유에는 Goal 미연결, 사용자 명시적 제외, 범위 초과 중 하나를 사용한다. "미확정"은 사유로 사용하지 않는다 (미확정은 `/sd-clarify`로 반드시 확정 처리).
+
+## Step 6: 격리 검증 (정보 유실·누락 점검)
+
+문서 작성 후, 작성자 편향 제거와 정보 유실 차단을 위해 메인 세션과 분리된 subagent로 격리 검증을 수행한다.
+
+### 검증 호출
+
+`Agent` tool로 `subagent_type: "general-purpose"`, `model: "haiku"`를 호출한다.
+
+subagent에 전달할 입력:
+
+- **wbs.md 절대 경로** — 검증 대상
+- **원본 자료 절대 경로 목록** — 첨부 파일(docx/xlsx/pdf 등). `/sd-doc-extract`로 추출된 파일이 있으면 함께 전달.
+- **사용자 초기 요청 메시지 본문** — 프롬프트에 인라인 삽입
+
+사용자 명확화 답변·결정사항은 wbs.md의 `근거:` 필드와 "제외 사항"에 반영되어 있으므로 별도 전달하지 않는다.
+
+subagent에 부여할 제약: "보고만 수행. wbs.md를 수정하지 말 것."
+
+### subagent 프롬프트에 포함할 검증 가이드
+
+#### 검증 항목 (4가지 모두 수행)
+
+1. **분류별 누락 점검** — 원본 자료에서 카테고리별로 사실 항목을 추출하고 wbs.md 반영 여부 점검
+   - 수치 (최대/최소/기본값/허용 범위, 기간, 시간대, 경계값)
+   - 열거값 (상태, 권한, 역할, 옵션 후보)
+   - 업무 규칙·정책
+   - 제약 조건
+   - 권한·역할 (Actor 단위)
+   - 상태 전이
+   - 예외 흐름·분기 조건
+   - 참조 자료 경로 + 확인 목적
+
+2. **정량 매핑 표** — 원본 사실 항목을 1:1로 wbs.md 위치(Feature 번호:범위 항목 또는 프로젝트 개요)에 매핑
+
+3. **양방향 커버리지**
+   - 원본 → wbs: 원본에 있는데 wbs.md에 없는 항목 (누락)
+   - wbs → 원본: wbs.md에 있는데 원본/근거에서 추적 불가한 항목 (근거 없는 추가)
+
+4. **의역 변형 검출** — 원문이 구체적인데 wbs.md가 추상화된 사례
+   - 예: 원문 "최대 100건" → wbs "다수 항목" (정보 손실)
+   - 예: 원문 "월요일 오전 9시" → wbs "주 1회" (정보 손실)
+
+#### 완독 의무
+
+원본 자료(첨부 파일·인라인 요청 메시지)는 끝까지 읽는다. 키워드 검색만으로 종결하지 않는다.
+
+#### 출력 포맷
+
+subagent는 다음 구조의 보고서를 작성한다.
 
-## Step 6: 정보 유실 방지 검증
+- **요약** — 원본 항목 수 / 매핑된 항목 / 누락 / 근거 없는 추가 / 의역 변형 의심 (각 정수)
+- **정량 매핑 표** — 컬럼: `원본 표현` / `출처(자료명·위치)` / `wbs.md 반영 위치` / `wbs 표현`. 반영 위치가 비어 있으면 누락 항목.
+- **누락 항목 목록** — `[출처] 원문: "..." → 권장 반영 위치: Feature X.Y 범위 / 프로젝트 개요 등`
+- **근거 없는 추가 항목 목록** — `[wbs 위치] 표현: "..." → 검토 사유`
+- **의역 변형 의심 항목 목록** — `원문 "..." → wbs "..." → 손실 추정: ...`
 
-문서 작성 후, 대화에서 수집한 모든 구체적 정보가 문서에 기록되었는지 검증한다.
+### 메인의 결과 처리
 
-- 사용자의 답변에 포함된 구체적 수치, 열거 항목, 업무 규칙, 제약 조건이 누락 없이 Feature 범위의 항목별 근거, Feature 근거 또는 프로젝트 개요에 기록되었는가?
-- 언급된 참조 파일/문서 경로가 확인 목적과 함께 기록되었는가?
-- 기존 WBS를 수정한 경우 체크박스 상태, Feature 번호, 사용자 메모, 제외 사항이 임의 초기화·삭제되지 않았는가?
-- 누락 발견 시 문서에 반영한 뒤 저장한다.
+1. subagent 보고서의 **누락·근거 없는 추가·의역 변형** 각 항목에 대해 `/sd-clarify`로 사용자에게 명확화 질문한다.
+   - 결정 대상: 반영 여부 / 위치 / 표현 정확도
+   - 답변에 따라 wbs.md 수정
+2. **기존 WBS 수정 사례 별도 점검** (격리 검증과 무관, 메인 직접 수행): 체크박스 상태(`[ ]`/`[x]`), Feature 번호, 사용자 메모, 제외 사항이 임의 초기화·삭제되지 않았는지 확인한다.
+3. 모든 명확화·반영이 끝나면 wbs.md 최종 저장.
 
 **CRITICAL: 각 Feature는 새 세션에서 진행되므로, 절대(NEVER) WBS 문서에 누락이 있어서는 안됨**
 

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "@simplysm/sd-claude",
-  "version": "14.0.57",
+  "version": "14.0.58",
   "description": "심플리즘 패키지 - Claude Code 셋업",
   "author": "심플리즘",
   "license": "Apache-2.0",