@simplysm/sd-claude 14.0.91 → 14.0.93

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

@@ -1,11 +1,12 @@
 ---
 name: sd-demo
-description: spec.md 의 화면 1개를 클라이언트 패키지의 화면 컴포넌트 자리에 인터랙티브 데모 골격으로 만들기. Use when "데모 만들기", "화면 데모", "spec 의 화면을 시각화" 를 요청할 때.
+description: 화면 명세(spec.md 또는 대화로 받은 화면 요구) 1개를 클라이언트 패키지의 화면 컴포넌트 자리에 인터랙티브 데모 골격으로 만들기. Use when "데모 만들기", "화면 데모", "spec 의 화면을 시각화" 를 요청할 때.
+disable-model-invocation: true
 ---
 
 # sd-demo
 
-spec.md 의 화면 1개를 클라이언트 패키지의 화면 컴포넌트 자리에 데모로 생성. 와이어프레임의 배치·라벨·동작 흐름과 일치하는 클릭 가능 UI 산출. 후속 단계에서 같은 자리에 실제 로직을 채워 진화시킴.
+화면 명세 1개를 클라이언트 패키지의 화면 컴포넌트 자리에 데모로 생성. 명세는 spec.md 의 화면 항목 또는 대화로 받은 화면 요구 어느 쪽이든 가능. 와이어프레임의 배치·라벨·동작 흐름과 일치하는 클릭 가능 UI 산출. 후속 단계에서 같은 자리에 실제 로직을 채워 진화시킴.
 
 ## 본질: UI 가 1순위
 
@@ -22,29 +23,30 @@ spec.md 의 화면 1개를 클라이언트 패키지의 화면 컴포넌트 자
 
 호출에 다음 입력이 필요:
 
-- 대상 spec.md 의 경로.
-- 만들 화면의 식별자 — `[화면.X]` 형태 또는 spec.md "화면 설계" 섹션의 화면 항목.
+- 화면 명세의 출처 — 다음 중 하나:
+    - spec.md 경로 (있을 때) — "화면"(§4) 섹션의 화면 항목을 명세로 사용.
+    - 대화로 받은 화면 요구 (spec.md 없을 때) — 호출자 발화·후속 대화에서 명세를 확보. 부족분은 2단계에서 질문.
+- 만들 화면의 식별자 — `[화면.X]` 형태, spec.md "화면"(§4) 섹션의 화면 항목, 또는 대화에서 지칭한 화면 이름.
 - 산출 위치 초안 — 클라이언트 패키지 + 화면 폴더. client 타겟이 1개면 자동 선택, 여러 개면 후보 제시 후 사용자 확정. (3단계-C 끝에서 도메인이 인접한 결과로 갱신)
 
-누락된 입력이 있으면 사용자에게 묻기. spec.md 에서 식별자 매칭이 안 되면 "화면 설계" 섹션의 화면 목록 표에서 후보 제시 후 확정.
+누락된 입력이 있으면 사용자에게 묻기. spec.md 사용 시 식별자 매칭이 안 되면 "화면"(§4) 섹션의 화면 목록 표에서 후보 제시 후 확정.
 
-**충돌 확인**: 대상 화면(또는 동반 모달 화면) 의 파일이 이미 존재하면 묻기 — ① 덮어쓰기 / ② spec 변경분만 보강 / ③ 취소. 호출자 발화에 명시된 분기가 있으면 묻지 않고 그 분기로 진행.
+**충돌 확인**: 대상 화면(또는 동반 모달 화면) 의 파일이 이미 존재하면 묻기 — ① 덮어쓰기 / ② 명세 변경분만 보강 / ③ 취소. 호출자 발화에 명시된 분기가 있으면 묻지 않고 그 분기로 진행.
 
-### 2단계: 대상 화면 항목 분석
+### 2단계: 대상 화면 명세 확보
 
-spec.md 의 대상 화면 항목에서 다음을 추출:
+화면 명세에서 다음을 확보. spec.md 가 있으면 대상 화면 항목에서 추출하고, 없으면 대화에서 확보하되 부족한 항목은 사용자에게 질문:
 
 - 헤더 인덱스(Actor · 관련 섹션 · 장치).
 - 기능 개요 · 와이어프레임 · 항목표 · 동작 · 도메인 규칙(해당 시).
 - 동작 항목에 등장하는 모달 호출(`→ [화면.Y] 을 모달로 띄움` 형태) 모두 수집.
 
-### 3단계: 분석 자료 확보
+와이어프레임은 데모 재현의 핵심 입력. spec.md 없이 진행할 때 와이어프레임이 확보되지 않으면 사용자에게 받아 진행(텍스트 배치 설명·ASCII 스케치 등). 확보 안 된 채 임의 작화 금지.
 
-**[gate] 3단계-A (라이브러리 문서) 진입 전엔 3단계 이후 출력 금지**.
+### 3단계: 분석 자료 확보
 
-- 3단계 진입 시 A 부터 Read (B·C 보다 먼저).
-- 스킵 안티패턴 — "참고 코드 부재" 신호(빈 패키지·참고할 화면 없음·client 타겟 비어있음 등) 를 이유로 A 를 건너뛰고 B(본체 소스 grep)·C(부위별 수집) 로 바로 진입.
-- A 미진입 시 3단계 이후 모든 출력 보류.
+- **[gate] 3단계 진입 시 A(라이브러리 문서) 부터 Read — B·C 는 그 뒤. A 미진입 시 3단계 이후 출력 보류.**
+- 안티패턴 — "참고 코드 부재" 신호(빈 패키지·참고할 화면 없음·client 타겟 비어있음 등) 를 이유로 A 를 건너뛰고 B(본체 소스 grep)·C(부위별 수집) 로 바로 진입.
 
 산출물을 만들기 전, 다음을 분석해 라이브러리 규약을 파악.
 
@@ -52,7 +54,7 @@ spec.md 의 대상 화면 항목에서 다음을 추출:
 
 코드베이스에 권위 있는 규약·매뉴얼 문서가 있으면 1순위로 따름.
 
-- `@simplysm/*` 14.x 사용 시 — [.claude/references/sd-simplysm14/README.md](../../references/sd-simplysm14/README.md) Read 후 "개발 매뉴얼" 항목 진입. 클라이언트 화면은 `client-component.md`, 화면 컨트롤은 `client-tab.md` 등.
+- `@simplysm/*` 14.x 사용 시 — [.claude/references/sd-simplysm14/README.md](../../references/sd-simplysm14/README.md) Read 후 "개발 매뉴얼" 표에서 현재 작업 트리거에 해당하는 항목 진입.
 - 그 외 framework 사용 시 코드베이스 안의 동등 위치 문서를 찾아 Read.
 
 **B. 라이브러리 컴포넌트 소스**
@@ -94,8 +96,8 @@ LLM 단독 판단의 한계: 동일 구성 화면이 한 곳도 없다는 이유
 - 파일명·selector·시그널·DI(Dependency Injection) 명명 등은 라이브러리 문서(A) 가 정한 형식 그대로 적용.
 - 슬롯·영역 분할·클래스 패턴은 3단계-C 의 부위별 패턴 채택분을 그대로 적용. 부위별로 다른 화면을 참조했더라도 각 부위의 채택분을 그대로 옮김.
 - 부위별 채택분의 출처(레퍼런스 화면 파일 경로)를 메모해 5단계 점검의 입력으로 활용.
-- 모달 호출이 포함된 화면이면 동반 모달 화면 항목도 같은 단계로 생성. 모달 띄우기는 실제로 작동시켜 시연 가치 확보.
-- 저장·삭제 등 데이터 변경 핸들러는 마커(`// sd-demo: 미구현 — 동작 자리`)만 작성. 클릭은 받되 결과 반영 금지.
+- 모달 호출이 포함된 화면이면 동반 모달 화면 항목도 같은 단계로 생성.
+- 저장·삭제 등 데이터 변경 핸들러 본문에는 마커(`// sd-demo: 미구현 — 동작 자리`)만 작성.
 
 **표식 마커 (고정)**
 
@@ -126,7 +128,3 @@ LLM 단독 판단의 한계: 동일 구성 화면이 한 곳도 없다는 이유
 ### 6단계: 완료 보고
 
 생성한 파일 목록을 보고 후 종료.
-
-## 운용
-
-- 결정 근거: 행동 규칙 "결정 근거" 적용.

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

@@ -1,21 +1,35 @@
 ---
 name: sd-dev
-description: 코드 변경 요청을 사용자와 합의 후 코드 변경분과 테스트로 산출. Use when 화면 단위 spec 분석이 필요 없는 라이브러리·CLI·내부 모듈의 기능 추가·수정·버그 수정 요청 시.
+description: 코드 변경 요청을 사용자와 대화로 합의 후 합의 범위만큼 테스트 포함 완결 구현(화면 산출 시 시연 포함)으로 산출. Use when spec.md 단위 풀 구현 워크플로가 필요 없는 증분 작업의 기능 추가·수정·버그 수정 요청 시 — 라이브러리·CLI·내부 모듈·서버 함수, 그리고 spec.md §4.x 단위 풀 구현/갱신에 해당하지 않는 화면 일부 변경(버튼 추가·기존 화면 버그 수정 등) 포함.
 ---
 
 # sd-dev
 
-spec.md 없이 진행하는 가벼운 코드 작업. 의도 합의 후 워크플로는 자동 진행 — 단 파일 삭제·시연 등 사용자 확인이 필요한 지점에서는 보고·승인 절차 수행. 합의 결과는 별도 산출물로 저장하지 않고 대화 메모리에만 유지.
+spec.md 없이 사용자와의 대화 합의를 권위 출처로 진행하는 증분 코드 작업.
+
+- **품질 동급**: 산출물 품질·엄밀성은 spec 파이프라인을 거치는 작업(sd-impl)과 동급. 차이는 작업 규모(spec.md 단위 풀 구현 워크플로를 거치느냐)뿐이며 품질 수준이 아님.
+- **권위 출처**: 1단계에서 사용자와 합의한 의도가 이후 전 단계의 권위 출처. 합의 결과는 별도 산출물로 저장하지 않고 대화 메모리에만 유지.
+- **자동 진행**: 의도 합의 후 워크플로는 자동 진행 — 단 파일 삭제·시연 등 사용자 확인이 필요한 지점에서는 보고·승인 절차 수행.
+- **대상 무제한 (산출물 종류)**: spec.md 단위 풀 구현 워크플로를 거칠 규모가 아닌 증분이면 산출물 종류로 한정하지 않음. 화면 일부 변경(버튼 추가·기존 화면 버그 수정 등)도 대상.
+
+## 본질 (횡단 룰)
+
+워크플로 전 단계 적용:
+
+- **임의 채움 금지**: 대화에서 합의되지 않았거나 모호한 분기·정의·경계 케이스를 발견하면 즉시 멈추고 사용자에게 질문. 자체 판단으로 채우지 않음. spec 같은 영속 권위 자료가 없어 모든 결정 근거가 대화 합의이므로 적용 빈도가 더 높음.
+- **테스트 목적 내부 분해 금지**: 합의에 없는 추상화·방어코드, 그리고 테스트를 위한 내부 구현 분리 금지 (상세는 4단계 테스트 단위 룰). 일반 스코프 밖 확장 금지는 상위 행동 규칙에 위임.
+- **사용자 보고 어휘**: 사용자에게 보고하는 본문에 내부 구현 식별자(내부 변수명·SQL 함수명·타입 키워드 등) 노출 금지. 사용자가 이해하는 기능·동작 어휘(업무 도메인이 있으면 도메인 어휘)로 풀어 보고. 단 사용자와 합의한 공개 계약(공개 함수명·CLI 옵션명 등)은 합의 산출물 자체이므로 그대로 노출.
 
 ## 워크플로
 
 ### 1단계: 의도파악
 
-사용자 발화를 토대로 무엇을 만들거나 바꿀지 합의. 다음을 확정해야 진행:
+사용자 발화를 토대로 무엇을 만들거나 바꿀지 합의. 이 합의가 이후 전 단계의 권위 출처. 다음을 확정해야 진행:
 
 - 작업 종류: 신규 추가 / 기존 수정 / 버그 수정.
 - 대상 파일·모듈·패키지.
 - 변경의 입출력·동작 — 이름·시그니처·예외 동작 등.
+- 독립 산출물로 합의되는 단위 — 추가·변경하기로 한 공개 함수·API·CLI 옵션·모듈 export 계약 (4단계 테스트 단위의 기준).
 
 근거 충분(사용자 발화 명시 + 기존 코드 패턴으로 추론 가능)이면 묻지 않고 진행. 부족분은 1건씩 질문 (행동 규칙 "사용자 질의 시"). 외부 자료(예: 디자인 시안·샘플 데이터·접근 자격증명)가 필요하면 이 단계에서 사용자에게 요청.
 
@@ -23,13 +37,13 @@ spec.md 없이 진행하는 가벼운 코드 작업. 의도 합의 후 워크플
 
 자료가 없어도 워크플로를 멈추지 않음. 발견된 만큼 활용.
 
-**A. 라이브러리·개발 매뉴얼**:
+**A. 라이브러리·개발 매뉴얼** (변경 전 기존 패턴 조사 룰에 따라 매뉴얼 참조):
 - `@simplysm/*` 14.x — `.claude/references/sd-simplysm14/README.md` 참조.
 - 그 외 framework — 코드베이스 안 동등 위치 문서.
 - 없으면 표준 패턴.
 
 **B. 기존 패턴**:
-- 작업 영역 인접 코드의 파일 위치·네이밍·구조·계층 분리 패턴 파악.
+- 작업 영역 인접 코드의 파일 위치·네이밍·구조·계층 분리 패턴 파악. 이 기존 패턴이 채택 패턴의 권위 출처 (변경 영역의 기존 코드 다수 사례에서 동일하게 나타난 패턴을 따름).
 - 동일 의도 기존 사용처 1~2개 Read.
 
 **C. 테스트 환경**:
@@ -37,10 +51,10 @@ spec.md 없이 진행하는 가벼운 코드 작업. 의도 합의 후 워크플
 
 ### 3단계: 작업 분해 표
 
-2단계 분석을 토대로 작업 분해 표 작성. 응답 본문에 표 형태로 출력하여 다음 4단계 TDD 사이클의 입력으로 사용.
+2단계 분석을 토대로 작업 분해 표 작성. 응답 본문에 표 형태로 출력하여 다음 4단계 TDD 사이클의 입력으로 사용. 차이 기준선 = 1단계에서 합의한 변경 범위 ↔ 현재 코드.
 
-| 항목 | 요구 | 현재 코드 상태 | 판정 | 매핑 파일 | 의존 |
-| ---- | ---- | -------------- | ---- | --------- | ---- |
+| 항목 | 합의 인용 | 현재 코드 상태 | 판정 | 매핑 파일 | 의존 |
+| ---- | -------- | -------------- | ---- | --------- | ---- |
 
 **항목 분해 단위**:
 - 함수·메서드 1개당 1줄.
@@ -50,7 +64,7 @@ spec.md 없이 진행하는 가벼운 코드 작업. 의도 합의 후 워크플
 
 **컬럼**:
 - **항목**: 분해 단위 1개의 짧은 식별자.
-- **요구**: 1단계 의도파악 합의 내용 인용.
+- **합의 인용**: 1단계 의도파악 합의 내용 인용.
 - **현재 코드 상태**: 코드베이스 조사 결과. 신규 작업은 "없음", 기존 수정은 "있음(현재 동작 요약)".
 - **판정**: 없음 / 불일치 / 일치 중 하나.
 - **매핑 파일**: 작성·갱신될 파일의 경로.
@@ -58,29 +72,118 @@ spec.md 없이 진행하는 가벼운 코드 작업. 의도 합의 후 워크플
 
 ### 4단계: TDD 사이클
 
-표에서 판정이 "없음" 또는 "불일치" 인 항목만 의존 순서대로 진행. "일치" 항목은 손대지 않음.
+표에서 판정이 "없음" 또는 "불일치" 인 항목만 의존 순서대로 진행. "일치" 항목은 손대지 않음 (차이만 작업).
+
+각 작업(표 1행)을 시작할 때 **테스트 작성 가능 여부** 판정 (2-C 테스트 환경 이용):
 
-각 작업(표 1행)을 시작할 때 **테스트 작성 가능 여부** 판정 — 입출력이 명확하고 외부 의존을 통제할 수 있는지 여부.
+| 분류 | 적용 대상 | 사이클 |
+| ---- | -------- | ------ |
+| 테스트 가능 | 도메인 로직·계산·변환·서버 함수·데이터 접근 | RED → GREEN → REFACTOR |
+| 테스트 불가·비효율 | UI 시각·인터랙션·외부 서비스 실호출·환경 의존 | 구현 → REFACTOR |
 
-- **테스트 가능**: **RED → GREEN → REFACTOR**.
-  - **RED**: 테스트만 작성 → 단위 테스트 실행 → 실패 확인. **이 단계에서 구현 파일 절대 손대지 말 것.**
-  - **GREEN**: 통과하는 최소 구현 → 단위 테스트 재실행 → 통과 확인.
-  - **REFACTOR**: 중복·가독성·기존 패턴 정합 정리 → 통과 유지 확인. 정리할 게 없으면 스킵.
-- **테스트 불가/비효율** (UI 시각·외부 서비스 실호출 등): **구현 → REFACTOR**.
+**테스트 단위 = 대화로 합의한 산출 단위. 내부 구현을 쪼개지 말 것**:
 
-**의도 모호 발견 시**: 사이클 진행 중 1단계 의도파악에서 합의되지 않은 모호함을 발견하면 즉시 멈추고 1단계 의도파악으로 회귀. 자체 판단으로 채우기 금지.
+- 위 "테스트 가능" 분류는 그 처리가 **대화에서 독립 산출물로 합의한 단위**(공개 함수·API·CLI 옵션·모듈 export 계약)일 때 적용 — 그 경우 그 단위를 그대로 테스트.
+- 합의된 요구가 "동작·기능"(화면·자동 처리·초기화 등)이고 변환·매핑·계산이 그 동작의 **내부 구현 조각**일 뿐이면, 동작 전체를 테스트 단위로 봄. 동작이 통째로 테스트 가능하면 그 단위로, 아니면(외부 I/O·환경 의존) "테스트 불가·비효율" 로 분류.
+- **내부 구현 조각을 테스트하려고 별도 함수·파일·인터페이스로 분리·추상화하지 말 것.** "이 헬퍼를 공개 API 로 한다"는 합의가 없으면, 테스트는 그 조각을 떼낼 이유가 되지 못함. 무엇을 테스트할지는 코드 구조가 아니라 1단계에서 합의한 산출 단위가 결정.
+
+**사이클 단계 정의**:
+
+- **RED**: 테스트만 작성 → 단위 테스트 실행 → 실패 확인. **이 단계에서 구현 파일 절대 손대지 말 것.**
+- **GREEN**: 테스트를 통과하는 **최소** 구현 → 단위 테스트 재실행 → 통과 확인.
+- **REFACTOR**: 중복·가독성·2-B 채택 패턴·2-A 매뉴얼 정합 검토 후 정리 → 통과 유지 확인. 채택 패턴·매뉴얼에서 벗어나는 임의 변형 금지. 검토는 항상 수행하며, 정리 대상이 없으면 코드 변경이 없을 뿐 단계를 건너뛰지 않음.
+
+**모호 발견 시**: 사이클 진행 중 1단계에서 합의되지 않은 분기·모호점을 발견하면 즉시 멈추고 사용자에게 재질의·재합의. 자체 판단으로 채우기 금지 (본질 "임의 채움 금지").
 
 ### 5단계: 코드 정리
 
-전체 변경분을 한 번 훑어 정돈. 4단계 TDD 사이클의 REFACTOR 단계가 잡지 못한 횡단 이슈와 작업 잔재를 정리 대상으로 함.
+전체 변경분을 한 번 훑어 정돈. 4단계 REFACTOR 가 잡지 못한 횡단 이슈와 작업 잔재를 정리 대상으로 함.
 
-- **횡단 중복**: 작업 사이클 사이에 동일 로직이 흩어져 있으면 합치기.
-- **인접 코드 패턴 정합**: 코드베이스 컨벤션 vs 실제 작성 — 파일 위치·네이밍·구조.
-- **불필요한 코드**: 미사용 import·변수·주석, 요구 없는 옵션·추상화 제거. 갱신·덮어쓰기 결과로 어디서도 참조되지 않는 파일도 포함. **단 파일 단위 삭제는 후보 목록을 사용자에게 보고 → 확정된 것만 삭제** (dynamic import·문서 자산 등 보존 대상은 사용자가 제외).
-- **권위 자료 정합**: 2단계 분석 항목 A(라이브러리·개발 매뉴얼)에서 확인한 규약을 위반한 항목 수정.
+- **횡단 중복**: TDD 사이클(4단계) 사이에 동일 로직이 흩어져 있으면 합치기.
+- **기존 패턴 정합 (drift 점검)**: 다항목 작업 누적으로 변경 모듈의 기존 패턴(파일 위치·네이밍·구조·함수 시그니처·에러 처리·테스트 패턴)에서 이탈한 부분이 있는지 횡단 점검. 이탈분만 2-B 채택 패턴으로 수정 (개별 항목 정합은 4단계에서 선반영).
+- **불필요한 코드**: 미사용 import·변수·주석, 합의 없는 옵션·추상화 제거. 갱신·덮어쓰기 결과로 어디서도 참조되지 않는 파일도 포함 (검사 범위는 전체 워크스페이스). **단 파일 단위 삭제는 후보 목록을 사용자에게 보고 → 확정된 것만 삭제** (dynamic import·문서 자산 등 정적 참조로 탐지 안 되는 보존 대상은 사용자가 제외 지시).
+- **권위 자료 정합 (횡단)**: 2-A 매뉴얼 규약 중 여러 항목·파일에 걸쳐 작성 후에만 드러나는 위반만 점검·수정 (개별 항목 준수는 4단계에서 선반영).
 
 정리 후 단위 테스트 재실행 — 회귀 없음 확인.
 
-### 6단계: 검증
+### 6단계: 합의 대조 (subagent 위탁)
+
+5단계 완료 후, 같은 LLM 의 자체 검증에서 발생하는 표면적 확인 편향을 제거하기 위해 별도 subagent 에 위탁해 합의 범위 ↔ 현재 코드를 독립 대조.
+
+sd-impl 은 외부 영속 산출물(spec.md)을 비교 기준으로 삼지만, sd-dev 의 권위 기준은 같은 LLM 이 보유한 대화 합의뿐임. 따라서 1단계에서 합의해 3단계 표로 굳힌 **합의된 산출 단위 + 입출력·동작·예외 동작** 목록을 입력으로 명시하여, 독립 에이전트가 그 목록을 비교 기준으로 코드와 항목 단위 1:1 대조하게 함.
+
+**대조는 합의된 변경 범위 전체를 대상으로 함.** "이번 사이클 변경분만" 식 스코프 제한 없음.
+
+#### subagent 호출
+
+- 도구: `Agent`.
+- `subagent_type`: `general-purpose` (추론·기능 어휘 풀어 보고 필요).
+- `description`: `sd-dev 합의 대조`.
+- `prompt`: 아래 입력 패키지 (그대로 복사 후 `<…>` 부분만 채움).
+
+````
+sd-dev 의 합의 범위 ↔ 코드 독립 대조를 수행해줘.
+
+**비교 기준 (합의된 산출 단위)**:
+
+(1) 3단계 작업 분해 표 (인라인):
+
+| 항목 | 합의 인용 | 현재 코드 상태 | 판정 | 매핑 파일 | 의존 |
+| ---- | -------- | -------------- | ---- | --------- | ---- |
+| ...  | ...      | ...            | ...  | ...       | ...  |
+
+(2) 합의된 입출력·동작·예외 동작 요약:
+- <항목별 합의 동작 요약>
+
+(3) 현재 구현 파일 목록 (절대경로):
+- <file1>
+- <file2>
+- ...
+
+**작업**:
+
+1. 현재 구현 파일을 모두 읽기.
+2. 위 합의 기준(1)(2) ↔ 코드를 항목 단위로 1:1 대조 (합의 범위 전체 대상. "이번 변경분만" 식 스코프 제한 없음).
+3. 차이 발견 시 아래 3분류로 보고:
+
+   - (a) **코드 위반**: 합의가 명확한데 코드가 빠뜨림·다름.
+   - (b) **합의 내부 모순**: 합의 항목 A vs 항목 B 충돌. (양쪽 인용 명시)
+   - (c) **합의 미정의 + 코드 임의 채움**: 합의에 정의·분기·경계 케이스 명시 없는데 코드가 채움.
+
+4. 보고 형식 (각 차이 1건마다):
+
+   ### 차이 N: <기능·동작 어휘로 표현된 한줄 요약>
+   - 분류: (a) / (b) / (c)
+   - 합의 항목: <표 항목 식별자 / 합의 동작>
+   - 코드 위치: <file:line>
+   - 코드 동작: <기능·동작 어휘로>
+   - 비고: (b) 면 모순 상대 인용 함께
+
+5. 차이 0건이면 `차이 없음, 검증 통과` 1줄만 응답.
+
+**제약**:
+
+- 보고 본문에 내부 구현 식별자(내부 변수명·SQL 함수명·타입 키워드 등) 노출 금지. 기능·동작 어휘로 풀어 쓸 것. 단 합의 기준에 포함된 공개 계약(공개 함수명·CLI 옵션명 등)은 그대로 인용 가능.
+- "코드가 합의 위반" 으로 단정 금지. 3분류 중 어디에 해당하는지 명시.
+- 합의 기준에 대조 근거가 없으면 (b)(c) 후보로 처리.
+
+**산출**: 위 3분류 보고 목록 또는 `차이 없음, 검증 통과`.
+````
+
+#### 결과 처리
+
+subagent 출력을 받은 후 분류별로 처리:
+
+- **(a) 코드 위반**: 4단계 TDD 사이클로 재진입하여 코드 수정.
+- **(b) 합의 내부 모순**: 사용자에게 1건씩 보고 (모순 양쪽 인용 + 의견) → 처리 방향 묻기 → 합의 갱신 후 4단계 재진입.
+- **(c) 합의 미정의 + 코드 임의 채움**: 사용자에게 1건씩 질문 → 결정 수령 → 합의 갱신 후 4단계 재진입.
+
+(b)(c) 모두 한꺼번에 묶음 보고 금지. 1건씩 합의 (본질 "임의 채움 금지").
+
+처리 완료 후 6단계 재실행 (재대조). 차이 0건 확인 후 7단계 진입.
+
+### 7단계: 검증
+
+산출물이 브라우저 시연이 필요한 화면·UI 이면 사용자에게 dev 서버 실행을 요청한 뒤 브라우저 자동화 도구(`playwright-cli`)로 합의된 동작 시나리오를 시연. assistant 가 직접 dev 서버·외부 장기 실행 프로세스를 띄우지 않음 — 사용자가 띄워 주소를 회신할 때까지 대기. 회귀 발견 시 4단계로 회귀 → 수정 → 재시연.
 
-산출물이 브라우저 시연이 필요한 화면·UI 이면 사용자에게 dev 서버 실행을 요청한 뒤 브라우저 자동화 도구로 시연. 그 외(라이브러리·CLI·내부 모듈·서버 함수)는 4단계 TDD 사이클의 단위 테스트 통과로 종결.
+그 외(라이브러리·CLI·내부 모듈·서버 함수)는 단위 테스트 통과로 회귀 점검. CLI 면 실제 명령 실행 결과 확인을 더함.

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

@@ -33,7 +33,7 @@ model: haiku
 
 - `apis/<패키지명>/README.md` 재작성.
 - 필요 시 `apis/<패키지명>/<군명>.md` 재작성. 코드에서 사라진 군의 파일은 삭제.
-- 결과 보고 1단락 (산출 파일 목록, 분할 발생 여부, 한 줄 트리거 요약).
+- 결과 반환: [references/subagent-prompt.md](references/subagent-prompt.md) §8 의 구조화 반환을 그대로 사용 (메인 에이전트는 §3 인덱스 취합에 `triggerSummary`, §4 보고에 `writtenFiles`·`deletedFiles` 를 씀).
 
 **범위 한정**: subagent 는 `apis/<패키지명>/` 위치만 다룸. 상위 `.claude/references/sd-simplysm14/README.md` 는 건드리지 않음 (다음 단계의 "패키지 인덱스 섹션 갱신" 에서 메인 에이전트가 처리).
 
@@ -41,7 +41,9 @@ model: haiku
 
 `.claude/references/sd-simplysm14/README.md` 는 **풀 재작성 대상 아님**. 파일 본문·다른 섹션은 그대로 보존, "패키지 인덱스" 섹션의 항목 리스트만 재구성함.
 
-모든 subagent 완료 후:
+**실패 게이트 (§3·§4 진입 조건)**: 모든 subagent 가 성공 반환했을 때만 §3·§4 를 진행함. 실패 = subagent 가 throw 로 끝났거나, 정상 반환했더라도 그 반환(`references/subagent-prompt.md` §8 의 `writtenFiles`)에 필수 README(`apis/<패키지명>/README.md`)가 없는 산출 누락. 실패가 있으면 실패한 패키지만 동일 프롬프트로 재호출하고, 전원 성공한 경우에만 §3 으로 진행함. 재호출에도 실패가 남으면 인덱스를 갱신하지 말고(부분 산출 패키지의 인덱스 항목을 새로 만들거나 완료로 보고하지 않음) 실패한 패키지 목록과 사유를 사용자에게 알린 뒤 동작 전체를 중단함.
+
+모든 subagent 가 성공 반환한 뒤:
 
 - **갱신 대상**: "패키지 인덱스" 섹션 본문(항목 리스트)만.
 - **건드리지 않음**: 섹션 머리(`## 패키지 인덱스`), 다른 모든 섹션, 파일 상단/하단 텍스트.
@@ -54,7 +56,7 @@ model: haiku
 
 다음 항목을 짧게 정리해 출력함.
 
-- 재작성된 패키지 목록 (= `public 리스트` 전체. 풀 재작성 모드 — 매번 모든 패키지 산출).
+- 재작성된 패키지 목록 (= `public 리스트` 전체. 풀 재작성 모드 — 매번 모든 패키지 산출). 단, §3 실패 게이트에서 재호출에도 실패가 남아 중단된 경우, 이 보고 대신 실패한 패키지 목록·사유를 보고하고 인덱스는 갱신하지 않음.
 - 분할 발생(`<군명>.md` 가 생긴) 패키지 목록.
 - 삭제된 분할 파일 (코드에서 사라진 군, 있다면).
 - 인덱스에서 제거된 항목 (있다면).

package/claude/skills/sd-docs/references/subagent-prompt.md

@@ -13,9 +13,9 @@
 
 타입 시그니처에서 직접 드러나지 않는 사용 패턴을 보강해야 하면 위 4개 소스 안에서만 추론.
 
-개발 매뉴얼은 **내용 근거가 아니라 예시·사용법의 일관성 제약**으로만 사용 (다음 "1.5. 매뉴얼 일관성 제약" 참조). 매뉴얼 본문을 API 문서로 복사·보강하는 것은 금지.
+개발 매뉴얼은 **내용 근거가 아니라 예시·사용법의 일관성 제약**으로만 사용 (다음 "1.1. 매뉴얼 일관성 제약" 참조). 매뉴얼 본문을 API 문서로 복사·보강하는 것은 금지.
 
-## 1.5. 매뉴얼 일관성 제약
+### 1.1. 매뉴얼 일관성 제약
 
 API 문서의 예시·사용법이 개발 매뉴얼이 정한 사용 패턴과 충돌하지 않게 함.
 
@@ -112,7 +112,6 @@ inputs: selectMode, autoSelect: "click"|"focus", useAutoSort, focusMode: "row"|"
 작성·갱신을 마치면 다음 항목을 구조화해 반환 (상위 README 인덱스 취합·사용자 보고에 사용).
 
 - `shortName`: `@simplysm/` 제외한 짧은 이름.
-- `mode`: 신규 작성인지 갱신인지.
 - `writtenFiles`: 산출·갱신한 파일 목록 (README + 분할 `.md` 모두).
 - `deletedFiles`: 삭제한 파일 목록 (코드에서 사라진 군, 없으면 빈 목록).
 - `triggerSummary`: 패키지의 한 줄 트리거 요약 (상위 README 인덱스에 옮겨 적을 문장).

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

@@ -33,22 +33,22 @@ spec.md 단위(§4.x 화면 / §5.x 자동 처리 / §6.x 공통·기반 기능)
 
 작업 대상 §4.x/§5.x/§6.x 와 작업 대상이 참조하는 §5/§6/§7/§8/§9 항목을 점검:
 
-- **헤더 `[OPEN: 날짜]` 섹션**: 본문이 재분석 포인터일 뿐 초안 부재 → "spec 수정 절차" 적용.
+- **섹션 `[OPEN]` (초안 부재)**: 섹션 본문이 재분석 포인터일 뿐 초안이 없음 → "spec 수정 절차" 적용.
 - **본문 인라인 `[OPEN]`**: 결정 근거가 있으면 결정. 없으면 1건씩 질문 → 답변 후 "spec 수정 절차" 적용.
 - **사용자 제공 예정 자료**: spec 본문에 사용자 회신 대기로 적힌 자료. 사용자 회신 후 진행.
 - **묵시적 모호**: 명시 마커는 없지만 spec 본문이 분기·정의·정의식·경계 케이스를 다루지 않는 부분. 4단계 분해 중 발견 가능성 높음. 발견 시 본 단계로 회귀.
 
 #### spec 수정 절차
 
-spec 본문 수정이 필요한 경우(인라인 `[OPEN]` 해소·헤더 `[OPEN]` 해소·구조 변경·6단계 (b)(d) 분류 처리 등) 메인 LLM 이 직접 처리:
+spec 본문 수정이 필요한 경우(인라인 `[OPEN]` 해소·섹션 `[OPEN]` 해소·구조 변경·6단계 (b)(c) 분류 처리 등) 메인 LLM 이 직접 처리:
 
-1. **sd-spec SKILL.md Read** — 룰 인지 (초안 작성 사이클·헤더 마커 형식·관련 섹션·의존 식별 룰).
-2. **초안 → "맞나요?" → 확정 → spec.md Edit** (sd-spec 사이클 적용).
-3. **의존 식별** — 수정된 § 항목을 의존으로 가진 §4.x/§5.x/§6.x 탐색 (sd-spec "의존 식별" 룰). 본 작업 단위 자신은 제외 (작업 중).
-4. **마커 제거** — 의존 §4.x/§5.x/§6.x 헤더의 `, 구현: YYYY-MM-DD` 부분만 제거 (이전 구현 무효화).
+1. **sd-spec SKILL.md Read** — 룰 인지: 부분 수정 인라인 경로·신뢰도 표기·형식 준수(§ 작성법 Read)·이름 기반 참조 cascade.
+2. **sd-spec "부분 수정 (인라인)" 경로로 Edit** — 정밀 반영(도메인 답이 이미 확정된 인라인 `[OPEN]`·6단계 결정 반영)은 바로 Edit, 초안·판단 필요분(섹션 `[OPEN]` 초안·구조 변경·모순 정정)은 진단·초안 제시 → 합의 후 Edit. 수정분은 사후 보고.
+3. **의존 추적** — 수정된 § 항목을 의존으로 가진 §4.x/§5.x/§6.x 를 이름 기반 참조 cascade(`[카테고리.이름]` grep 전수 추적) + 관련 섹션 한 줄로 탐색. 본 작업 단위 자신은 제외 (작업 중).
+4. **마커 제거** — 의존 §4.x/§5.x/§6.x 헤더의 `[구현]` 마커 제거 (이전 구현 무효화).
   - 영향 단위에 번호를 매겨 사용자에게 모아서 "맞나요?" 질문 — 전체 동의 → 일괄 제거 / 일부 유지 지목 → 지목 항목 마커 유지.
 
-본 작업 단위(§4.x/§5.x/§6.x 자신)의 헤더 `[확정]` 은 9단계에서 `[확정, 구현]` 으로 확장.
+본 작업 단위(§4.x/§5.x/§6.x 자신)의 헤더에는 9단계에서 `[구현]` 마커를 부착.
 
 ### 3단계: 보조 자료 수집 (있다면 활용)
 
@@ -86,9 +86,9 @@ spec 본문 수정이 필요한 경우(인라인 `[OPEN]` 해소·헤더 `[OPEN]
 | 부적합   | 있지만 spec 요구와 어긋남         | 같은 종류 다른 단위에서 그 계층 패턴 차용 |
 | 적합     | 그대로 따름                       | 변경 없이 사용                            |
 
-비어있음·부적합 계층은 같은 종류 다른 단위에서 2회 이상 반복된 패턴을 자동 채택. 1회만 쓰인 변종은 배제. 여러 패턴이 갈리면 사용자에게 1회 질문.
+비어있음·부적합 계층은 같은 종류의 서로 다른 단위 2개 이상에서 동일하게 나타난 패턴을 자동 채택. 단위 1개에서만 쓰인 변종은 배제. 여러 패턴이 갈리면 사용자에게 1회 질문.
 
-**읽기**: 기준 단위의 적합 계층 파일 + 보강 출처 파일을 모두 읽기. 7단계 정합 점검의 입력.
+**읽기**: 기준 단위의 적합 계층 파일 + 보강 출처 파일을 모두 읽기. 5단계 작성 시 채택 패턴 기준이자 7단계 drift 점검의 입력.
 
 #### C. 테스트 환경
 
@@ -149,7 +149,7 @@ spec 본문 수정이 필요한 경우(인라인 `[OPEN]` 해소·헤더 `[OPEN]
 
 - **RED**: 테스트만 작성 → 러너 실행 → 실패 확인. **구현 파일은 손대지 않음.**
 - **GREEN**: 테스트를 통과하는 **최소** 구현 → 러너 통과 확인.
-- **REFACTOR**: 중복·가독성·기존 패턴 정합 정리 → 러너 통과 유지.
+- **REFACTOR**: 중복·가독성·3-B 채택 패턴·3-A 매뉴얼 정합 정리(채택 패턴·매뉴얼에서 벗어나는 임의 변형 금지) → 러너 통과 유지.
 
 작업 사이클 중 spec 미정의·모호 분기를 만나면 2단계로 회귀.
 
@@ -195,12 +195,12 @@ sd-impl 의 spec ↔ 코드 독립 대조를 수행해줘.
 
    - (a) **코드 위반**: spec 명확한데 코드가 빠뜨림·다름.
    - (b) **spec 내부 모순**: §A 정의 vs §B 정의 충돌. (양쪽 인용 명시)
-   - (d) **spec 미정의 + 코드 임의 채움**: spec 본문에 정의·분기·경계 케이스 명시 없는데 코드가 채움.
+   - (c) **spec 미정의 + 코드 임의 채움**: spec 본문에 정의·분기·경계 케이스 명시 없는데 코드가 채움.
 
 5. 보고 형식 (각 차이 1건마다):
 
    ### 차이 N: <도메인 어휘로 표현된 한줄 요약>
-   - 분류: (a) / (b) / (d)
+   - 분류: (a) / (b) / (c)
    - spec 위치: §X.x line Y
    - spec 인용: "..."
    - 코드 위치: <file:line>
@@ -213,7 +213,7 @@ sd-impl 의 spec ↔ 코드 독립 대조를 수행해줘.
 
 - 보고 본문에 코드 식별자(변수명·SQL 함수명·타입 키워드 등) 노출 금지. 모두 도메인 어휘로 풀어 쓸 것.
 - "코드가 spec 위반" 으로 단정 금지. 3분류 중 어디에 해당하는지 명시.
-- spec 본문에 인용할 수 있는 문구가 없으면 (b)(d) 후보로 처리.
+- spec 본문에 인용할 수 있는 문구가 없으면 (b)(c) 후보로 처리.
 
 **산출**: 위 3분류 보고 목록 또는 `차이 없음, 검증 통과`.
 ````
@@ -224,22 +224,22 @@ subagent 출력을 받은 후 분류별로 처리:
 
 - **(a) 코드 위반**: 5단계 사이클로 재진입하여 코드 수정.
 - **(b) spec 내부 모순**: 사용자에게 1건씩 보고 (모순 양쪽 인용 + 어느 쪽이 합리적인지 의견) → 처리 방향 묻기 (spec 수정 / 코드 정정) → spec 수정 시 2단계 "spec 수정 절차" 적용.
-- **(d) spec 미정의 + 코드 임의 채움**: 사용자에게 1건씩 질문 → 결정 수령 → 2단계 "spec 수정 절차" 로 인라인 결정 반영 → 5단계 사이클 재진입.
+- **(c) spec 미정의 + 코드 임의 채움**: 사용자에게 1건씩 질문 → 결정 수령 → 2단계 "spec 수정 절차" 로 인라인 결정 반영 → 5단계 사이클 재진입.
 
-(b)(d) 모두 한꺼번에 묶음 보고 금지. 1건씩 합의.
+(b)(c) 모두 한꺼번에 묶음 보고 금지. 1건씩 합의.
 
 처리 완료 후 6단계 재실행 (재대조). 차이 0건 확인 후 7단계 진입.
 
 ### 7단계: 코드 정리
 
 - **횡단 중복**: 작업 사이클 사이에 흩어진 동일 로직 합치기.
-- **계층별 정합 점검**: 3-B 의 기준 단위 + 보강 출처 파일을 다시 Read 하여 4계층별로 실제 작성분과 비교. 한 계층이라도 채택 패턴과 어긋나면(임의 변형·새 발명) 수정.
+- **계층별 drift 점검**: 다항목 작업 누적으로 5단계의 3-B 채택 패턴에서 이탈한 계층이 있는지 4계층 전체를 횡단 점검. 이탈분만 채택 패턴으로 수정 (개별 항목 정합은 5단계에서 선반영).
   - 도메인 모델: 필드·타입·제약·네이밍 패턴 일치.
   - 데이터 접근: 함수 시그니처·쿼리 패턴·에러 처리 일치.
   - 본체: 컴포넌트·트리거·처리 단계·핸들러·의존성 패턴 일치.
   - 테스트: 러너·assertion·mock 패턴 일치.
 - **불필요한 코드**: 미사용 import·변수·주석, 요구가 없는 옵션·추상화 제거. 작업 결과로 어디서도 참조되지 않는 파일도 포함 (검사 범위는 전체 워크스페이스). **단 파일 단위 삭제는 후보 목록을 사용자에게 보고 → 확정분만 삭제** (dynamic import·마이그레이션·문서 자산 등 보존 대상은 사용자가 제외 지시).
-- **매뉴얼 권위 규약**: 3-A 에서 Read 한 매뉴얼 위반 항목 수정.
+- **매뉴얼 권위 규약 (횡단)**: 3-A 매뉴얼 규약 중 여러 항목·계층에 걸쳐 작성 후에만 드러나는 위반만 점검·수정 (개별 항목 준수는 5단계에서 선반영).
 
 정리 후 단위 테스트 재실행하여 회귀 없음을 확인.
 
@@ -260,7 +260,7 @@ subagent 출력을 받은 후 분류별로 처리:
 
 ### 9단계: 완료 보고
 
-- 대상 spec.md 의 해당 §4.x / §5.x / §6.x 헤더 `[확정: YYYY-MM-DD]` 를 `[확정: YYYY-MM-DD, 구현: YYYY-MM-DD]` 로 확장. 이미 `, 구현: …` 가 들어있으면 그 날짜만 갱신. 날짜는 PowerShell `Get-Date -Format "yyyy-MM-dd"` 로 취득.
+- 대상 spec.md 의 해당 §4.x / §5.x / §6.x 헤더(제목 + (장치) 표기 뒤)에 `[구현]` 마커를 부착. 이미 `[구현]` 이 있으면 그대로 둠 (날짜·`[확정]` 부착 안 함).
 - 만들거나 갱신한 파일 목록 보고 (마커를 부착한 spec.md 포함).
 - 본 세션에서 2단계·6단계 "spec 수정 절차" 로 의존 §4.x/§5.x/§6.x 마커가 제거된 항목이 있으면 영향 단위 목록 보고 (재구현 필요 알림). 없으면 생략.
 - 시연에서 사용자 확인이 끝나면 종료.

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

@@ -1,6 +1,7 @@
 ---
 name: sd-manual
 description: `.claude/references/sd-simplysm14/manuals/` 에 주제 단위 목적 기반 개발 매뉴얼(how-to)을 작성·갱신. Use when 라이브러리·프레임워크 사용법을 "~하려면 ~한다" 식 매뉴얼로 새로 쓰거나 코드 변경을 반영해 갱신할 때.
+disable-model-invocation: true
 ---
 
 # sd-manual

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

@@ -1,33 +1,39 @@
 ---
 name: sd-review
-description: 산출물(코드·문서 등) 을 적용 룰 기준으로 검증해 발견 사항을 보고. Use when 사용자가 리뷰 혹은 검토를 요청할 때.
+description: 산출물(코드·문서 등)을 도메인 자동판정 후 적용 룰을 전수·적대적으로 검증해 [자동]/결정 분류로 보고하는 멀티에이전트 리뷰. Use when 사용자가 리뷰 혹은 검토를 요청할 때.
 ---
 
 # sd-review
 
-## 워크플로
+리뷰 요청 시 멀티에이전트 워크플로(`workflow.js`)에 전수·적대적 검증을 위임하고, 그 검증 통과분을 메인 루프가 병합·분류·적용·결정 처리.
 
-1. **리뷰 대상 식별** — 사용자가 지정한 대상(파일 경로·코드·문서 등) 확정. 모호 시 사용자에게 묻기.
+## 절차
 
-2. **작업 도메인 명시** — 대상이 어떤 도메인의 산출물인가 식별 (예: LLM 문서 / 사람 문서 / UI / 코드).
+1. **리뷰 대상 확정** — 사용자가 지정한 대상(파일 경로·디렉터리·코드·문서·자연어 설명) 확정. 모호하면 사용자에게 묻기.
 
-3. **적용 룰 인용** — 도메인의 적용 룰 인용 (행동 규칙·sd-design-rules·스킬·도메인별 룰 등). 룰 항목 직접 표기.
+2. **워크플로 실행** — Workflow 도구로 이 스킬의 `workflow.js` 실행:
+   - `Workflow({ scriptPath: ".claude/skills/sd-review/workflow.js", args: <리뷰 대상> })`.
+   - `args` 는 1단계에서 확정한 대상 (경로 문자열·경로 배열·자연어 설명 중 무엇이든).
+   - 대상 식별·도메인 판정·룰 발견·차원 도출·전수 대조·적대 검증은 워크플로가 자율 수행. 반환은 검증 통과분 `survived[]`.
 
-4. **룰 부합 전수 검증** — 인용한 모든 룰 항목을 대상의 모든 단위(코드: 함수·라인 / 문서: 섹션·문장)에 대해 빠짐없이 대조. 표본·대표 패턴만 검사하거나 일부 단위만 보고 조기 종료하는 것 금지.
+3. **병합·중복제거** — `survived[]` 에서 같은 위치(`file`:`line`)·같은 본질 이슈가 여러 차원에서 중복 제기된 항목은 하나로 병합(룰 인용은 합쳐 표기). 위치·이슈가 다르면 별개로 유지.
 
-5. **발견 사항 분류** — 각 항목을 다음 기준으로 분류:
+4. **[자동]/결정 분류** — 워크플로가 산정해 반환한 `survived[].category` 값을 그대로 사용해 `[자동]`(`category`=`자동`)/결정 대상(`category`=`결정`)으로 묶음. 분류 기준은 workflow.js 가 단일 소스로 가지므로 메인 루프에서 재정의·재판정하지 않음.
 
-   | 판정 | 기준 |
-   | --- | --- |
-   | `[자동]` 화이트리스트 | 오타·맞춤법·띄어쓰기·조사 오용·들여쓰기/줄바꿈 통일·trailing whitespace·중복 제거 등 형식 정리 |
-   | `[자동]` 의미·범위 변동 없음 | 변경 전후의 의미·적용 범위가 동일함이 명백한 표현 정리 |
-   | 결정 대상 | 위 `[자동]` 판정 두 종류 어디에도 해당하지 않는 모든 항목 (의미·적용 범위가 변동될 가능성이 조금이라도 있음) |
+   - `verdict` 가 `uncertain` 인 항목은 (워크플로가 이미 `category`=`결정` 으로 산정함) 결정 진행 시 불확실 사유를 함께 명시.
+   - `fix_verdict` 가 `risky`·`flawed`·`uncertain` 인 항목은 `fix_assessment` 요약을 함께 적어 주의 환기.
 
-6. **자동 적용 실행** — `[자동]` 판정 항목을 즉시 변경.
+5. **[자동] 적용** — `[자동]` 분류 항목을 각 `file`·`line`·`fix` 대로 즉시 편집 적용. 0건이면 생략.
 
-7. **보고** — 모든 발견 사항을 나열. `[자동]` 판정 항목과 결정 대상 항목을 분리 표기.
-   - 각 항목의 필수 필드: 제목, 적용 룰 (출처 인용), 판정.
-   - `[자동]` 판정 항목: `[자동]` 마커 표기 (변경 완료).
-   - 결정 대상 항목: 마커 없음.
+6. **결정 진행** — 결정 대상이 1건 이상이면 행동 규칙 "사용자 질의 시" 의 결정 진행 모드로 전환 (각 항목의 `title`·`rule`·`evidence`·`fix` 를 근거로). 0건이면 7단계로.
 
-8. **결정 진행 모드 전환** — 결정 대상이 1건 이상이면 행동 규칙의 "사용자 질의 시" 섹션이 정의한 결정 진행 모드로 전환 (사용자 트리거 대기 금지). 0건이면 종료.
+7. **보고** — `summary`(단위·차원·total·confirmed/uncertain/rejected·survived 수) 와 `[자동]`/결정 분류 결과, `rejected[]`(검증 탈락분) 을 정리해 사용자에게 제시.
+
+   - 워크플로가 에러(throw)로 끝나면 에이전트 일부가 실패해 검증이 미완료된 것(fail-fast — 부분 결과를 반환하지 않음). 이때는 "위반 없음(clean pass)" 으로 보고하지 말고 실패 사실을 알린 뒤 resume 로 재실행. 정상 반환이면 전 차원·전 발견이 검증 완료된 것이므로 `survived` 를 그대로 신뢰.
+
+## 워크플로 반환 구조
+
+- `survived[]`: 적대 검증 통과 발견. 각 항목 `{ dimension, title, file, line, severity, category, rule, evidence, fix, fix_verdict, fix_assessment, verdict, verifyReason }`.
+- `summary`: 집계 수치(units·dimensions·total·confirmed·uncertain·rejected·survived). 워크플로는 fail-fast — 에이전트가 하나라도 실패하면 부분 결과 없이 throw 하므로, 정상 반환된 `summary` 는 항상 전 차원·전 발견 검증 완료를 의미.
+- `rejected[]`: 적대 검증에서 기각된 발견 `{ dimension, title, file, line, reason }`.
+- `plan`: 단위·차원·룰 발견 근거 `{ units: [{ path, domain }], dimensions: [{ key, title, ruleSources }], notes }` (반환 `dimensions` 는 내부값에서 `focus`·`units` 제외).