@simplysm/sd-claude 14.0.94 → 14.0.96

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

@@ -1,43 +1,158 @@
 ---
 name: sd-debug
-description: 버그·실패·예외의 원인을 다관점으로 발굴하고 가설별 검증·해결책·적대검증을 거쳐 검증된 해결책을 제안하는 멀티에이전트 디버깅. Use when 버그·예외·실패의 근본 원인 분석과 해결책이 필요할 때.
+description: 버그·실패·예외의 원인을 다관점으로 발굴하고 가설별 검증·해결책·적대검증을 거쳐 검증된 해결책을 제안하는 멀티에이전트 디버깅. Use when 사용자가 sd-debug 스킬을 직접 지정해 호출할 때만 사용 (자동 트리거 금지).
 ---
 
 # sd-debug
 
-디버깅 요청 시 멀티에이전트 워크플로(`workflow.js`)에 원인 발굴·검증·적대검증을 위임하고, 그 결과를 메인 루프가 사용자에게 제시·결정 처리.
+디버깅 요청 시 메인 루프가 직접 오케스트레이션. 관점을 직접 도출한 뒤, 문제 규모에 따라 관점별 가설 발굴과 가설별 검증·해결책·적대검증을 서브에이전트(Agent 도구)로 펼치거나 직접 수행하고, 검증된 해결책을 병합·우선순위화·결정 처리. Workflow 도구는 쓰지 않음 — 효과를 문제 규모에 비례시켜 고정 비용을 피함.
+
+## 디버깅 원칙 (전 단계 공통)
+
+발굴·검증·적대검증 서브에이전트에 항상 주입하고, 메인 루프가 직접 수행할 때도 동일하게 적용:
+
+- 모든 판정은 실제 코드/설정을 Read 하여 확인. 근거 없는 추측·일반론 금지(추측은 '가설'로만 등록, 사실로 단정 금지).
+- 현재 워킹트리만 기준. git log/diff/show/blame 등 과거 조회 금지. `.back/` 및 `.gitignore` 등재 경로(node_modules·dist·.tmp 등) 읽지 말 것.
+- 결측(null/undefined)은 결측대로 다룰 것. 빈 값을 추측으로 채우지 말 것.
+- 입력 정보가 부족하면 Grep/Glob/Read 로 코드베이스를 직접 조사해 보강.
 
 ## 절차
 
-1. **문제 확정** — 증상·기대동작·관찰결과를 확정.
-   - 대화 중 오류를 논의하다 진입했으면, 그때까지의 맥락(증상·에러·스택·시도·관찰)을 요약해 문제 설명으로 합성.
-   - 에러 메시지·스택·재현조건·관련 코드 경로·환경은 있으면 함께 모음(선택).
-   - 문제 설명조차 불명확하면 사용자에게 묻기.
+### 1. 문제 확정
+
+증상·기대동작·관찰결과를 확정.
+
+- 대화 중 오류를 논의하다 진입했으면, 그때까지의 맥락(증상·에러·스택·시도·관찰)을 요약해 문제 설명으로 합성.
+- 에러 메시지·스택·재현조건·관련 코드 경로·환경은 있으면 함께 모음(선택).
+- 문제 설명조차 불명확하면 사용자에게 묻기.
+
+### 2. 의심 관점 도출 (메인 루프 직접)
+
+증상을 보고, 원인을 찾을 때 서로 겹치지 않는 '의심 관점(범주)'을 도출:
+
+- 증상 성격에 맞춰 동적으로 고름. 예시 범주: 동시성·타이밍, 데이터·결측, 타입·계약, 로직·경계조건, 외부의존·환경·설정, 상태·생명주기. (예시일 뿐 — 증상에 맞게 가감)
+- 각 관점에 key·title·focus(이 관점이 의심하는 구체 지점) 부여.
+- 보통 3~6개. 증상을 좁게 가리키면 적게, 막연하면 넓게.
+
+### 3. 규모 판단 → 펼침 여부 결정
+
+- **가설 발굴**: 관점이 여러 개이고 코드베이스 조사 범위가 넓으면 → 관점마다 Agent 펼침(각 Agent 는 자기 관점만 보므로 사각지대가 줄고 재현율이 오름). 관점이 적고 조사 범위가 좁으면 메인 루프가 직접 발굴.
+- **검증·적대검증**: 검증자가 가설을 발굴자와 무관하게 코드로 재확인하는 독립성이 핵심. **가설이 1건이라도 검증·적대검증은 독립 Agent 로 수행함이 기본**. 가설이 다수면 가설마다 Agent 병렬.
+- 서브에이전트 다수를 펼칠 때는 **한 메시지에 Agent 호출을 여러 개** 넣어 동시 실행. agentType 은 general-purpose (전수 Read·판정 필요).
+
+### 4. 가설 발굴
+
+(Agent 펼침 또는 직접) 관점별로 원인 가설을 발굴하고, 어떤 관점에도 매이지 않는 자유탐색 가설도 1벌 추가(사각지대 안전망).
+
+관점별 Agent 프롬프트:
+
+```
+문제: <문제 설명>
+[디버깅 원칙 주입]
+
+너의 일: 오직 '<title>' 관점에서만 원인 가설을 발굴하라. 이 관점의 의심 지점: <focus>
+- 코드베이스를 Grep/Glob/Read 로 직접 조사해 이 관점에 해당하는 원인 후보를 빠짐없이 뽑을 것(재현율 우선).
+- 다른 관점의 원인은 무시(중복은 이후 정리).
+- 각 가설에 title·cause·perspective('<title>')·evidenceExpected(맞다면 보일 근거)·refuteSignal(틀렸다면 보일 반증) 채움.
+- 이 관점에서 원인이 안 보이면 비울 것(억지 생성 금지).
+```
+
+자유탐색 Agent 는 위에서 `perspective='free'`, 정해진 관점 목록에 잘 안 들어가는 원인일수록 가치가 크다는 지시로 1벌.
+
+### 5. 가설 중복제거 (메인 루프 직접)
+
+발굴된 가설을 의미 기준으로 병합:
+
+- '같은 근본 원인'을 가리키는 가설끼리만 하나로 합침(표현만 다른 중복 제거). 근본 원인이 다르면 절대 합치지 말 것 — 서로 다른 원인을 뭉개면 검증에서 통째 탈락함.
+- 병합 시 evidenceExpected·refuteSignal 은 합쳐 보존, perspective 는 합쳐진 관점들 표기.
+- 개수를 인위적으로 줄이지 말 것(재현율 우선). 진짜 중복만 제거.
+
+### 6. 검증 + 해결책 도출
+
+각 가설을 (독립 Agent 가 기본) 코드를 Read 해 검증하고, 통과 시 같은 근거 위에서 해결책까지 도출. Agent 프롬프트:
+
+```
+문제: <문제 설명>
+[디버깅 원칙 주입]
+
+너의 일: 아래 원인 가설을 실제 코드를 Read 해 검증하고(관대 기준), 통과하면 같은 코드 근거 위에서 해결책까지 도출하라.
+
+1) 검증(verdict):
+- confirmed: 코드에서 근거를 확인함.
+- uncertain: 근거가 부분적·애매하지만 코드에서 일부라도 뒷받침됨 — 통과시킴(이후 적대검증이 거른다).
+- rejected: 코드로 보아 '명백히 틀린' 경우, 또는 코드에서 근거가 전혀 확인되지 않고 반증신호가 우세한 경우. 단 일부라도 뒷받침되면 기각하지 말고 uncertain('근거 전무'만 기각해 누락 방지).
+- reason 에 확인한 코드 위치·내용 인용. 통과면 refinedCause 에 구체화된 원인 기술.
+
+2) 해결책(rejected 가 아닐 때만):
+- 확인한 코드 근거 위에서, 근본 원인을 가장 직접적으로 제거하는 정도가 높은 순으로 최대 2개, 서로 접근이 다르게.
+- 각 후보에 approach·mechanism(원인을 어떻게 제거하나)·changeScope(수정 범위) 채움.
+- 과도한 설계(over-engineering)·증상만 가리는 임시방편은 피할 것.
+- rejected 면 solutions 를 비울 것.
+
+가설:
+- 제목: <title>
+- 원인: <cause>
+- 관점: <perspective>
+- 예상 근거: <evidenceExpected>
+- 반증 신호: <refuteSignal>
+```
+
+`rejected` 가설은 dropped 로 분리(보고용). `confirmed`/`uncertain` 은 통과로 다음 단계.
+
+### 7. 적대검증
+
+통과 가설의 각 해결책을 (독립 Agent 가 기본) 4관점에서 적대적으로 공격. 해결책마다 Agent 1개. 프롬프트:
+
+```
+문제: <문제 설명>
+[디버깅 원칙 주입]
+
+너의 일: 아래 (원인 가설 + 해결책) 쌍을 다음 4개 관점 각각에서 적대적으로 공격하라. 기본 입장은 '이 해결책은 결함이 있다'로 두고 약점을 찾을 것. 각 관점을 서로 끌려가지 말고 독립 판정해 관점마다 1개 항목으로 반환.
+
+관점:
+- 인과: 해결책이 이 가설의 원인을 실제로 제거하는가. 원인-증상 인과가 성립하는가.
+- 회귀·부작용: 해결책이 새 버그·룰 위반·엣지케이스(결측 null/undefined·동시성/트랜잭션·soft delete 동명 레코드·권한 분기·타입/스키마 제약)를 유발하는가.
+- 증거 정합: 가설의 근거가 실제 코드/스택과 일치하는가. 오인·과장은 없는가.
+- 대안 원인: 이 가설 말고 다른 원인이 진짜일 가능성은 없는가.
+
+각 관점 판정:
+- pass=false 로 둘 결함을 찾으면 reason 에 코드 근거와 함께 적고, 치명적(회귀 유발·인과 불성립 등)이면 critical=true. 교정안 있으면 revisedNote 에.
+- 그 관점에서 결함이 없으면 pass=true, critical=false, revisedNote="".
+
+원인 가설: <title> — <refinedCause 또는 cause>
+해결책: <approach> / <mechanism> (수정 범위: <changeScope>)
+```
+
+**fail-fast**: 펼친 Agent 중 하나라도 실패(에러)하면 부분 결과로 진행 금지. 실패 사실을 알린 뒤 해당 Agent 만 재실행해 보완. 전건 정상이어야 전 가설·전 해결책 검증 완료로 간주.
+
+### 8. 해결책 판정 (메인 루프 집계)
+
+각 해결책의 4관점 결과를 다음 규칙으로 판정:
+
+- **veto**: 어느 한 관점이라도 `critical=true && pass=false` 면 기각(치명결함 1표면 탈락).
+- **passed**: veto 가 없고, `pass=true` 가 과반(passVotes > total/2)이면 통과(채택 후보).
+- **risks**: `pass=false` 인 관점의 reason 모음(잔존 리스크).
+- **revisions**: 비어있지 않은 revisedNote 모음(교정안).
+- `votes` = `passVotes/total` 로 통과 강도 표기.
+
+### 9. 병합·우선순위화 (메인 루프)
+
+- 같은 근본 원인의 가설이 중복되면 병합.
+- 각 가설의 해결책 중 `passed=true` 인 것을 채택하되 revisions(교정)를 반영하고 risks 는 잔존 리스크로 보존.
+- (검증 confidence: confirmed>uncertain) + (적대검증 통과 강도 votes) + (원인-증상 직접성)으로 우선순위 정렬.
 
-2. **워크플로 실행** — Workflow 도구로 이 스킬의 `workflow.js` 실행:
-   - `Workflow({ scriptPath: ".claude/skills/sd-debug/workflow.js", args: <문제 설명> })`.
-   - `args` 는 1단계의 문제 설명(자연어 문자열 또는 `{ problem, error, repro, paths, env }` 객체).
-   - 관점 도출·가설 발굴·검증·해결책 탐색·적대검증·병합은 워크플로가 자율 수행.
+### 10. 결과 렌더
 
-3. **병합·우선순위화** — 반환값 `survived[]` 를 메인이 직접 정리:
-   - 같은 근본 원인의 가설이 중복되면 병합.
-   - 각 가설의 해결책 중 `passed: true` 인 것을 채택하되 `revisions`(교정)를 반영하고 `risks` 는 잔존 리스크로 보존.
-   - (검증 confidence: confirmed>uncertain) + (적대검증 통과 강도 `votes`) + (원인-증상 직접성)으로 우선순위 정렬.
+행동 규칙 "문제 발생 시" 의 3블록으로 제시:
 
-4. **결과 렌더** — 행동 규칙 "문제 발생 시" 의 3블록으로 제시:
-   - 원인 가설: `survived[].hypothesis`·`cause` (+ `dropped[]` 로 기각된 가설과 사유).
-   - 검증: 각 항목의 `verdict`·`verifyReason` (uncertain 은 "근거 약함" 으로 표시).
-   - 해결책: 채택한 해결책(교정 반영) + 잔존 리스크.
+- **원인 가설**: 통과 가설의 hypothesis·cause (+ dropped 로 기각된 가설과 사유).
+- **검증**: 각 항목의 verdict·verifyReason (uncertain 은 "근거 약함" 으로 표시).
+- **해결책**: 채택한 해결책(교정 반영) + 잔존 리스크.
 
-5. **결정 진행** — 채택 해결책 후보가 1건 이상이면 행동 규칙 "사용자 질의 시" 의 결정 진행 모드로 전환(우선순위 순). 사용자가 고른 해결책만 실제 수정에 착수.
+### 11. 결정 진행
 
-6. **미해결 보고** — `summary.noSolution` 이면(검증된 해결책 0건) `survived[]` 의 가설·탈락 사유와 `dropped[]` 를 제시해 다음 수동 디버깅의 출발점으로 삼게 함.
+채택 해결책 후보가 1건 이상이면 행동 규칙 "사용자 질의 시" 의 결정 진행 모드로 전환(우선순위 순). 사용자가 고른 해결책만 실제 수정에 착수.
 
-## 워크플로 반환 구조
+### 12. 미해결 보고
 
-- `survived[]`: `{ hypothesis, cause, perspective, verdict, verifyReason, solutions }` — 검증 통과 가설.
-  - `solutions[]`: `{ approach, mechanism, changeScope, passed, vetoed, votes, risks, revisions }` — `passed: true` 가 채택 후보.
-- `dropped[]`: `{ hypothesis, cause, reason }` — 검증에서 기각된 가설과 사유.
-- `summary`: 집계(가설 수·confirmed/uncertain·dropped·solutionsPassed·noSolution).
-- `perspectives`: 사용한 의심 관점 목록.
-- `problem`: 입력 문제 요약.
+검증된 해결책이 0건이면 통과 가설의 가설·탈락 사유와 dropped 를 제시해 다음 수동 디버깅의 출발점으로 삼게 함.

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

@@ -1,39 +1,177 @@
 ---
 name: sd-review
-description: 산출물(코드·문서 등)을 도메인 자동판정 후 적용 룰을 전수·적대적으로 검증해 [자동]/결정 분류로 보고하는 멀티에이전트 리뷰. Use when 사용자가 리뷰 혹은 검토를 요청할 때.
+description: 산출물(코드·문서 등)을 도메인 자동판정 후 적용 룰을 전수·적대적으로 검증해 [자동]/결정 분류로 보고하는 멀티에이전트 리뷰. Use when 사용자가 sd-review 스킬을 직접 지정해 호출할 때만 사용 (자동 트리거 금지).
 ---
 
 # sd-review
 
-리뷰 요청 시 멀티에이전트 워크플로(`workflow.js`)에 전수·적대적 검증을 위임하고, 그 검증 통과분을 메인 루프가 병합·분류·적용·결정 처리.
+리뷰 요청 시 메인 루프가 직접 오케스트레이션. 계획을 직접 세운 뒤, 대상 규모에 따라 차원별 전수 룰 대조와 발견별 적대 검증을 서브에이전트(Agent 도구)로 펼치거나 직접 수행하고, 검증 통과분을 병합·분류·적용·결정 처리. Workflow 도구는 쓰지 않음 — 효과를 대상 규모에 비례시켜 고정 비용을 피함.
+
+## 검증 원칙 (전 단계 공통)
+
+리뷰·검증 서브에이전트에 항상 주입하고, 메인 루프가 직접 수행할 때도 동일하게 적용:
+
+- 표본·대표 패턴만 보지 말고 모든 단위(코드: 함수·라인 / 문서: 섹션·문장)를 인용한 룰 항목 전체에 빠짐없이 대조.
+- 발견 항목은 (위치 + 위반한 룰 원문 인용 + 코드/문장 근거)를 반드시 갖출 것. 근거 없는 추측·일반론·개인 취향 지적 금지.
+- 적용 룰의 출처는 (a) 컨텍스트에 자동 주입된 프로젝트/글로벌 지침(설계룰·행동 규칙 등) 과 (b) 발견·전달된 룰 파일 뿐. 그 밖의 임의 기준으로 지적 금지.
+
+**분류(category) 기준**:
+
+- `자동` = 오타·맞춤법·띄어쓰기·조사 오용·들여쓰기/줄바꿈 통일·trailing whitespace·세미콜론·중복 제거 등 순수 형식 정리, 또는 변경 전후 의미·적용 범위가 동일함이 명백한 표현 정리.
+- `결정` = 위 `자동` 어디에도 해당하지 않는, 의미·적용 범위가 조금이라도 변동될 가능성이 있는 모든 항목.
+
+**심각도(severity)**: `error`=동작 결함·데이터 정합성·룰 명백 위반, `warn`=권고 위반·잠재 위험, `info`=경미·형식.
 
 ## 절차
 
-1. **리뷰 대상 확정** — 사용자가 지정한 대상(파일 경로·디렉터리·코드·문서·자연어 설명) 확정. 모호하면 사용자에게 묻기.
+### 1. 리뷰 대상 확정
+
+사용자가 지정한 대상(파일 경로·디렉터리·코드·문서·자연어 설명) 확정. 모호하면 사용자에게 묻기.
+
+### 2. 계획 수립 (메인 루프 직접)
+
+Glob·Grep·Read 로 직접 수행:
+
+1. **대상 식별** — 구체 리뷰 단위로 확정.
+   - 경로/디렉터리면 Glob 으로 파일 수집 (dist/.back/node_modules/.gitignore 등재 경로 제외).
+   - 자연어 설명이면 Grep/Glob 으로 산출물을 찾아 단위 확정.
+   - 각 단위 경로는 Read 로 직접 접근 가능한 형태로 확보. 사용자가 절대경로(다른 워크스페이스 등)를 줬으면 그대로 보존 — 상대경로로 깎지 말 것. 현재 레포 내부 대상일 때만 레포 기준 상대경로 사용.
+
+2. **도메인 판정** — 각 단위가 어떤 산출물 도메인인지 판정.
+   예: "@simplysm v14 화면 컴포넌트", "@simplysm v14 라이브러리/CLI 코드", "ORM/DB 스키마", "LLM 문서(SKILL.md/CLAUDE.md/.claude/rules)", "사람용 문서", "스킬 정의", "spec.md" 등.
+
+3. **적용 룰 동적 발견** — 도메인에 맞는 룰 소스를 실제로 찾아 경로를 적음.
+   - 컨텍스트에 자동 주입된 프로젝트/글로벌 지침(설계룰·행동 규칙 등) → `auto-injected: <지침명>` 으로 표기.
+   - `Glob ".claude/rules/*.md"`.
+   - 가장 가까운 CLAUDE.md (있으면).
+   - 도메인 관련 `.claude/references/**` 매뉴얼 (예: simplysm14 화면이면 references/sd-simplysm14/manuals/client-*.md, orm.md 등; 실제 Glob 으로 존재 확인).
+   - 도메인 관련 `.claude/skills/*/SKILL.md` (예: 스킬 리뷰면 sd-skill, spec.md 면 sd-spec, 매뉴얼이면 sd-manual).
+   - "기존 동종 산출물 패턴" 자체도 룰 소스 → `existing-pattern` 표기 (코드베이스 비교).
+
+4. **리뷰 차원 도출 (분할 축 자율 결정)** — 대상 규모(단위 수·파일 크기·룰 도메인 수)를 먼저 가늠한 뒤 가장 효율적인 분할 축을 택해 차원 구성.
+   - 룰축: 파일 적고 룰 도메인 많음 → 차원 = 룰 묶음, units = 전체 단위.
+   - 파일축: 파일 많고 룰 도메인 적음 → 차원 = 파일(또는 클러스터), ruleSources = 적용 룰 전체.
+   - 매트릭스: 파일도 많고 룰 도메인도 많은 대규모 → 파일 클러스터 × 룰 묶음 조합.
+   - 각 차원에 key·title·ruleSources(실제 경로/표기)·units(검사할 단위 경로)·focus 부여.
+   - 불변식: (a) 모든 (단위 × 적용 룰) 조합이 정확히 한 차원에서 빠짐없이 커버 — 누락·중복 금지, (b) 한 차원 컨텍스트 과부하 방지, (c) 차원 수 보통 3~8개.
+
+### 3. 규모 판단 → 펼침 여부 결정
+
+계획을 바탕으로 Review·Verify 를 서브에이전트로 펼칠지 직접 할지 판단:
+
+- **Review**: 차원이 2개 이상이거나 단위 파일이 많아 한 컨텍스트에 다 읽으면 과부하 → 차원마다 Agent 펼침. 차원 1개·소형이면 메인 루프가 직접 전수 대조.
+- **Verify**: 적대 검증의 독립성(발견자 ≠ 검증자)이 핵심. **발견이 1건이라도 검증은 독립 Agent 로 수행함이 기본** — 메인 루프는 발견자이므로 자기검증 편향을 피해야 함. 발견이 다수면 발견마다 Agent 병렬. 예외: 대상이 극히 작고 발견이 명백한 형식 항목(자동 분류)뿐이면 직접 가능.
+- 서브에이전트 다수를 펼칠 때는 **한 메시지에 Agent 호출을 여러 개** 넣어 동시 실행. agentType 은 general-purpose (전수 Read·판정 필요).
+
+### 4. Review — 전수 룰 대조
+
+각 차원에 대해 (Agent 또는 직접) 아래를 수행. Agent 로 펼칠 때 프롬프트:
+
+```
+[검증 원칙 주입]
+
+리뷰 차원: <title>
+검사 초점: <focus>
+
+적용할 룰 소스(존재 파일은 전부 Read; auto-injected/existing-pattern 는 컨텍스트·코드베이스 조사로 처리):
+- <ruleSources...>
+
+리뷰 단위(전부 Read 로 끝까지):
+- <units...>
+
+위 룰 소스를 단위 전체에 전수 대조해 위반을 보고. 각 발견에 아래 필드를 채울 것.
+위반 없으면 "발견 없음" 으로 반환.
+
+발견 형식(항목마다):
+- title: 한 줄 요약
+- file: 파일 경로 또는 basename
+- line: 라인/섹션 번호 또는 범위
+- severity: error|warn|info
+- category: 자동|결정
+- rule: 위반한 룰 출처 + 원문 인용
+- evidence: 코드/문장 근거 인용
+- fix: 제안 수정
+```
+
+전 차원의 발견을 수집해 합침.
+
+### 5. Verify — 발견별 적대적 검증
+
+발견이 0건이면 생략(7단계로). 1건 이상이면 각 발견을 (독립 Agent 가 기본) 적대 검증. Agent 프롬프트:
+
+```
+[검증 원칙 주입]
+
+다음은 리뷰에서 제기된 발견 항목이다. 두 가지를 모두 적대적으로 검증하라.
+
+[1] 발견(문제) 검증: 인용된 룰이 실제로 그렇게 규정하는지, 대상이 실제 그 위치에서 그러한지 파일을 직접 Read 하여 확인. 과장·오인·룰 오인용이면 verdict=rejected, 불명확하면 uncertain, 사실이면 confirmed. 의심스러우면 기각 쪽. final_severity/final_category 재산정.
+
+[2] 해결책(제안 수정) 검증: 제안 수정을 공격적으로 따져라 —
+  - 실제로 그 문제를 해결하는가,
+  - 새 룰 위반·회귀를 만들지 않는가,
+  - 엣지케이스(결측 null/undefined, 동시성/트랜잭션, soft delete 동명 레코드, 권한 분기, 타입/스키마 제약 등)에서 깨지지 않는가,
+  - 과도(over-engineering)하거나 틀린 접근은 아닌가.
+  대상 코드·스키마·룰을 직접 확인해 판정. 결함이 있으면 fix_verdict=flawed/risky 로 두고 교정안 제시. 건전하면 fix_verdict=sound 로 두고 원안 재기술.
+  발견이 rejected 면 [2] 생략 가능 — fix_verdict=uncertain, fix_revised="".
+
+발견 항목:
+- 제목: <title>
+- 위치: <file> (<line>)
+- 심각도(제안): <severity>
+- 분류(제안): <category>
+- 위반 룰: <rule>
+- 근거: <evidence>
+- 제안 수정: <fix>
+
+리뷰 단위 경로:
+- <units...>
+
+해당 파일·스키마·룰 소스를 Read 하여 직접 대조 후 판정.
+
+판정 형식:
+- verdict: confirmed|rejected|uncertain
+- reason: 룰 원문과 대상을 재확인한 판정 근거
+- final_severity: error|warn|info
+- final_category: 자동|결정
+- fix_verdict: sound|risky|flawed|uncertain
+- fix_assessment: 해결책이 문제를 실제 해결하는지, 새 룰 위반·회귀·엣지케이스를 유발하는지 근거
+- fix_revised: flawed/risky 면 교정된 해결책; sound 면 원안 재기술; 발견 rejected 면 빈 문자열
+```
+
+**fail-fast**: 펼친 Agent 중 하나라도 실패(에러)하면 부분 결과로 진행 금지. "위반 없음" 으로 보고하지 말고 실패 사실을 알린 뒤 해당 Agent 만 재실행해 보완. 전건 정상 반환이어야 전 차원·전 발견 검증 완료로 간주.
+
+### 6. survived 산정
+
+검증 결과를 모아 통과분(survived)을 산정:
+
+- `verdict` = `confirmed` 또는 `uncertain` 인 발견만 survived 로 채택. `rejected` 는 제외(보고용 rejected[] 로 분리).
+- survived 각 항목의 값:
+  - `severity` = 검증의 `final_severity`.
+  - `category` = `verdict`=`uncertain` 이면 무조건 `결정`, 아니면 검증의 `final_category`.
+  - `fix` = `fix_revised` 가 비어있지 않으면 그 값, 아니면 원안 `fix`.
+  - `fix_verdict`·`fix_assessment`·`verifyReason`(검증 reason) 보존.
+
+### 7. 병합·중복제거
 
-2. **워크플로 실행** — Workflow 도구로 이 스킬의 `workflow.js` 실행:
-   - `Workflow({ scriptPath: ".claude/skills/sd-review/workflow.js", args: <리뷰 대상> })`.
-   - `args` 는 1단계에서 확정한 대상 (경로 문자열·경로 배열·자연어 설명 중 무엇이든).
-   - 대상 식별·도메인 판정·룰 발견·차원 도출·전수 대조·적대 검증은 워크플로가 자율 수행. 반환은 검증 통과분 `survived[]`.
+survived 에서 같은 위치(`file`:`line`)·같은 본질 이슈가 여러 차원에서 중복 제기된 항목은 하나로 병합(룰 인용은 합쳐 표기). 위치·이슈가 다르면 별개로 유지.
 
-3. **병합·중복제거** — `survived[]` 에서 같은 위치(`file`:`line`)·같은 본질 이슈가 여러 차원에서 중복 제기된 항목은 하나로 병합(룰 인용은 합쳐 표기). 위치·이슈가 다르면 별개로 유지.
+### 8. [자동]/결정 분류
 
-4. **[자동]/결정 분류** — 워크플로가 산정해 반환한 `survived[].category` 값을 그대로 사용해 `[자동]`(`category`=`자동`)/결정 대상(`category`=`결정`)으로 묶음. 분류 기준은 workflow.js 가 단일 소스로 가지므로 메인 루프에서 재정의·재판정하지 않음.
+survived 의 `category` 로 묶음:
 
-   - `verdict` 가 `uncertain` 인 항목은 (워크플로가 이미 `category`=`결정` 으로 산정함) 결정 진행 시 불확실 사유를 함께 명시.
-   - `fix_verdict` 가 `risky`·`flawed`·`uncertain` 인 항목은 `fix_assessment` 요약을 함께 적어 주의 환기.
+- `category`=`자동` → `[자동]`.
+- `category`=`결정` → 결정 대상.
+- `verdict`=`uncertain` 항목은 결정 진행 시 불확실 사유를 함께 명시.
+- `fix_verdict` 가 `risky`·`flawed`·`uncertain` 인 항목은 `fix_assessment` 요약을 함께 적어 주의 환기.
 
-5. **[자동] 적용** — `[자동]` 분류 항목을 각 `file`·`line`·`fix` 대로 즉시 편집 적용. 0건이면 생략.
+### 9. [자동] 적용
 
-6. **결정 진행** — 결정 대상이 1건 이상이면 행동 규칙 "사용자 질의 시" 의 결정 진행 모드로 전환 (각 항목의 `title`·`rule`·`evidence`·`fix` 를 근거로). 0건이면 7단계로.
+`[자동]` 분류 항목을 각 `file`·`line`·`fix` 대로 즉시 편집 적용. 0건이면 생략.
 
-7. **보고** — `summary`(단위·차원·total·confirmed/uncertain/rejected·survived 수) 와 `[자동]`/결정 분류 결과, `rejected[]`(검증 탈락분) 을 정리해 사용자에게 제시.
+### 10. 결정 진행
 
-   - 워크플로가 에러(throw)로 끝나면 에이전트 일부가 실패해 검증이 미완료된 것(fail-fast — 부분 결과를 반환하지 않음). 이때는 "위반 없음(clean pass)" 으로 보고하지 말고 실패 사실을 알린 뒤 resume 로 재실행. 정상 반환이면 전 차원·전 발견이 검증 완료된 것이므로 `survived` 를 그대로 신뢰.
+결정 대상이 1건 이상이면 행동 규칙 "사용자 질의 시" 의 결정 진행 모드로 전환 (각 항목의 `title`·`rule`·`evidence`·`fix` 를 근거로). 0건이면 11단계로.
 
-## 워크플로 반환 구조
+### 11. 보고
 
-- `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` 제외).
+집계(단위·차원·total·confirmed/uncertain/rejected·survived 수) 와 `[자동]`/결정 분류 결과, rejected[](검증 탈락분: dimension·title·file·line·reason)를 정리해 사용자에게 제시.