@simplysm/sd-claude 14.0.91 → 14.0.92

package/claude/references/sd-simplysm14/manuals/client-crud.md

@@ -56,6 +56,12 @@
 - **`'control'`** — view 안에 임베드. 명령 영역에 저장 버튼.
 - **`'modal'`** — 모달. `selectMode` 와 함께 쓰면 close 시 `{ selectedKeys }` 페이로드를 자동 전달.
 
+### 편집 방식 (`inlineEdit`, 기본 `true`)
+
+- `true` — 시트를 `<sd-form>` 으로 감싸 셀 인라인 편집 + 저장 버튼/CTRL+S + per-row 삭제 컬럼 제공.
+- `false` — 인라인 편집 chrome 제거. 시트는 조회·선택 전용이며, 편집은 호스트가 `selectedKeys`(또는 별도 진입)로 상세/모달을 열어 처리. 등록·선택 삭제·복구·필터·페이징은 그대로 유지. 이 모드에선 `submit` 출력이 발화하지 않음.
+- `readonly` 와 직교: `readonly=true` 면 편집 자체 불가, `readonly=false` + `inlineEdit=false` 면 편집은 가능하되 인라인이 아님(외부 모달·상세).
+
 ### 모달 선택 모드
 
 `viewType="modal"` + `selectMode` 지정 시:
@@ -65,6 +71,8 @@
 
 호출측은 `_sdModal.showAsync(...)` 결과로 `{ selectedKeys }` 페이로드 수신.
 
+`selectMode` 는 `readonly` 와 독립 — selectMode 지정만으로는 편집이 막히지 않음. 등록·인라인 편집은 그대로 유지되고, `single` 일 때 "선택 삭제/복구" 버튼만 숨김. 읽기 전용이 필요하면 `readonly=true` 를 별도로 전달. `sd-shared-data-select-list` 가 모달을 띄울 때도 `selectMode="single"` 만 주입하므로 모달 내용은 편집 가능 상태로 유지됨.
+
 ## `sd-crud-detail`
 
 단일 레코드 편집 화면의 표준 골격. 다음 기능을 일괄 제공: 폼 래핑, CTRL+S 단축키 저장, 저장 버튼, 모달의 "확인" 버튼 자동 처리.

package/claude/references/sd-simplysm14/manuals/client-demo.md

@@ -10,11 +10,13 @@
 | 단건 입력 폼                                             | `<domain>.detail.ts`                                                                            |
 | 좌 목록 + 우 단건                                        | `<domain>.view.ts` + `.list.ts` + `.detail.ts`                                                  |
 | 좌 헤더 목록 + 우(헤더 정보 + 라인 시트) 마스터-라인     | `<domain>.view.ts` + `.list.ts` + `.detail.ts` — 우 라인 영역은 `.detail.ts` (헤더 단건 + 라인) |
-| 모달 (동작 섹션에 `→ [화면.X] 을 모달로 띄움` 표기)      | `<domain>.modal.ts`                                                                             |
+| 모달 전용 비-CRUD 화면 (도구·검색·설정 등)               | `<domain>.modal.ts`                                                                             |
 | 프린트 양식                                              | `<domain>.print-template.ts`                                                                    |
 
 `<domain>` 은 화면명을 dash-case 영문으로 음역한 슬러그. 같은 도메인 폴더에 같은 역할의 파일이 2개 이상이면 `<domain>-<갈래>.<역할>.ts` 형식 사용.
 
+동작 섹션의 `→ [화면.X] 을 모달로 띄움` 표기는 표시 방식일 뿐 파일 역할이 아님. 화면.X 가 단건 편집이면 `.detail.ts` 를 `showAsync` 로 띄우고(= 위 "단건 입력 폼" 행), 모달 전용 비-CRUD UI 일 때만 `.modal.ts`. 판별 기준은 [client-component.md "detail 과 modal 구분"](./client-component.md) 참조.
+
 ## 와이어프레임 기준
 
 화면 정의 섹션(4번 섹션) 의 와이어프레임이 모든 시각 요소(버튼·필터·시트·탭·검색) 의 **존재·영역·순서** 결정의 1순위. 표준 슬롯이나 기본 UI(사용자 인터페이스) 와 충돌하면 와이어프레임에 맞춰 슬롯을 비우거나 컴포넌트를 교체. 줄 수·픽셀 좌표는 기준이 아님 (폼 inline 자동 wrap 등의 표현 한계 때문).
@@ -69,9 +71,9 @@ if (!result) return;
 // sd-demo: 미구현 — 동작 자리
 ```
 
-영역 한정 호출(`→ [화면.Y] 의 <영역> — 선택 전용` 등) 은 모달의 입력 시그널(`selectMode` 등) 로 전달.
+영역 한정 호출(`→ [화면.Y] 의 <영역> — 선택 전용` 등) 은 모달의 입력 시그널(`selectMode` 등) 로 전달. spec 마커 매핑: "선택 전용"·multiselect 는 `selectMode`(`single`/`multi`) 로, "편집 가능 여부" 는 `readonly` 로 따로 전달. "선택 전용" 은 선택 목적을 뜻할 뿐 편집을 막지 않으므로(readonly 아님), 편집까지 차단하려면 `readonly=true` 를 함께 줄 것.
 
-피호출 모달은 `<sd-crud-detail>` 을 루트로 사용 (`viewType='modal'` 자동 주입). 임의 `close` output 규약을 만들지 말 것 — `_sdModal.showAsync` 의 페이로드 반환 규약만 사용.
+단건 편집을 모달로 띄우는 경우 피호출 화면은 `.detail.ts`(`<sd-crud-detail>` 루트, `viewType='modal'` 자동 주입)이며 모달 표시용 별도 `.modal.ts` 를 만들지 않음. 모달 전용 비-CRUD 화면(`.modal.ts`)은 `sd-crud-detail` 대신 `sd-busy-container` 등으로 자체 구성. 어느 경우든 임의 `close` output 규약을 만들지 말 것 — `_sdModal.showAsync` 의 페이로드 반환 규약만 사용.
 
 **동반 모달**: 동작 섹션에 `→ [화면.Y] 을 모달로 띄움` 으로 등장하는 모든 모달은 같은 호출에서 함께 생성. 이미 존재하면 재사용.
 
@@ -109,19 +111,7 @@ state = signal<"draft" | "confirmed">("draft");
 
 ## "선택하세요." 빈 화면
 
-list 와 detail 의 합성 view 에서 항목 미선택 빈 상태는 시연 시 눈에 띄도록 작성:
-
-```html
-<div
-  class="flex-fill tx-theme-gray-default p-xxl"
-  style="font-size: 48px; line-height: 1.5em"
->
-  <ng-icon [svg]="tablerArrowLeft" />
-  선택하세요.
-</div>
-```
-
-[client-component.md "list + detail 합성"](./client-component.md) 의 단순 `<div class="flex-fill p-default">선택하세요.</div>` 코드를 위 사례로 대체.
+list 와 detail 의 합성 view 에서 항목 미선택 빈 상태는 [client-component.md "list + detail 합성"](./client-component.md) 의 빈 상태 규약(`p-xxl` + `font-size: 48px` + `tablerArrowLeft` 아이콘) 을 그대로 따름.
 
 ## 라우팅·메뉴 따라가기
 

package/claude/references/sd-simplysm14/manuals/client-shared-data.md

@@ -139,6 +139,32 @@ sharedProducts = useSharedSignal("품목");
 
 - `register` 에 쓴 이름 문자열을 그대로 넘기면 `TAppSharedData` 에서 타입이 추론됨.
 
+## 선택 컨트롤에서 관리·선택 모달 띄우기
+
+공유데이터 선택 컨트롤(`sd-shared-data-select` · `sd-shared-data-select-list`)은 그 자리에서 해당 마스터를 관리·선택하는 모달을 여는 입력을 가짐. 마스터 목록 화면(`sd-crud-list` 기반)을 모달로 재사용해, 선택 컨트롤 옆에서 등록·수정·선택을 끝낼 수 있음.
+
+| 입력         | 컨트롤              | 동작                                                                                               |
+| ------------ | ------------------- | -------------------------------------------------------------------------------------------------- |
+| `[modal]`    | select · select-list | 선택형 모달. 모달에 `selectMode: "single"` 과 현재 선택 키가 주입되어 열리고, 닫힘 결과의 첫 키로 선택을 갱신. |
+| `[editModal]` | select              | 관리 전용 모달(선택을 바꾸지 않음). 닫혀도 현재 선택은 그대로 유지.                                |
+
+```html
+<sd-shared-data-select-list
+  [items]="sharedRoles.items()"
+  [(selectedItem)]="selectedRole"
+  [modal]="{ type: RoleList, title: '역할', inputs: {} }"
+>
+  <ng-template [itemOf]="sharedRoles.items()" let-item="item">{{ item.name }}</ng-template>
+</sd-shared-data-select-list>
+```
+
+- `[modal]` 값은 `{ type, title, inputs }` (모달 호출과 동일 형태, [client-component.md](./client-component.md) 의 '모달 호출' 참조).
+- `[modal]` 로 띄울 목록 컴포넌트는 **선택 모달 계약**을 구현해야 함:
+  - `selectMode` input + `selectedKeys` model 보유.
+  - `SdModalContentDef<SelectModalOutputResult<TKey> | undefined>` 구현 (close 페이로드로 `{ selectedKeys }` 전달).
+  - 이 계약은 `sd-crud-list` 의 모달 선택 모드와 동일 ([client-crud.md](./client-crud.md) 참조). 즉 목록 화면 하나가 일반 페이지·선택 모달 양쪽으로 재사용됨.
+- 선택 컨트롤이 띄울 때는 항상 `selectMode: "single"` 로 주입되므로, 목록은 단건 선택 모드로 동작함.
+
 ## 지킬 것
 
 - 항목 추가 시 세 곳(`register` · `TAppSharedData` · 인터페이스)을 모두 갱신. 하나라도 빠지면 타입 불일치 또는 미등록 데이터가 됨.

package/claude/references/sd-simplysm14/manuals/logging.md

@@ -44,7 +44,7 @@ console.error("[X] 실패:", err);
 
 ## 환경별 셋업
 
-- **Node 진입점(서버·CLI)**: 진입점에서 `setupConsola()` 를 1회 호출. 상세는 [apis/core-node/consola.md](../apis/core-node/consola.md) 참조.
+- **Node 진입점(서버·CLI)**: 진입점에서 `setupConsola()` 를 1회 호출.
 - **Browser·Capacitor 진입점**: `setupConsola` 호출 금지 (Node 전용 API). consola 기본 reporter 가 브라우저 콘솔로 출력하며, tag·level·호출 방식의 일관성은 그대로 충족.
 
 ## 모듈-레벨 logger 주의

package/claude/references/sd-simplysm14/manuals/orm.md

@@ -27,6 +27,20 @@ WHERE 와 SELECT 양쪽에서 동일 도출 산식을 쓰겠다고 `buildDerived
 
 ## 안티패턴
 
+### execute 결과를 코드에서 후처리 금지
+
+가져올 데이터는 DB단에서 최소화함. 중복 제거·필터·정렬·집계·페이징은 ORM 절로 처리하고, `execute()` 로 받은 배열을 코드에서 가공하지 않음. 전건을 메모리로 끌어온 뒤 코드에서 거르면 네트워크·직렬화·메모리 비용이 행 수에 비례해 커짐.
+
+| 코드 후처리 (나쁜 예)                         | ORM 절 (좋은 예)                          |
+| --------------------------------------------- | ----------------------------------------- |
+| `(await q.execute())` 후 `.distinct()`        | `.distinct().execute()` (count 시 `.distinct().wrap().count()`) |
+| 받은 배열을 `.filter(...)`                    | `.where((r) => [...])`                     |
+| 받은 배열을 `.sort(...)`                      | `.orderBy((r) => ..., "ASC")`             |
+| 받은 배열을 `.slice(page*size, ...)`          | `.limit(page * size, size)`               |
+| 받은 배열로 `.reduce((sum, ...) => ...)`      | `.select((r) => ({ sum: expr.sum(...) }))` (집계는 `joinSingle` 부착) |
+
+이종 엔티티를 합쳐야 할 때도 코드 merge 대신 DB단 UNION — predicate pushdown 으로 각 소스에서 먼저 행을 줄임 ([orm-union.md](./orm-union.md)).
+
 ### SELECT 절 내부에 `expr.subquery` / `expr.exists` 사용 금지
 
 도메인 boolean(`isCompleted`, `hasAny` 등)이나 집계(`SUM`, `COUNT`, `MAX`)가 필요하면 `joinSingle` 안에서 `from + where + select(aggregate)` 로 묶어 outer 행에 컬럼으로 부착함. SELECT 컬럼에 subquery / exists 를 넣으면 outer 행마다 inner 쿼리가 N 회 실행됨.
@@ -77,7 +91,7 @@ WHERE 와 SELECT 양쪽에서 동일 도출 산식을 쓰겠다고 `buildDerived
 
 `expr.val` 은 `select` 콜백에서 리터럴 상수 컬럼을 만들 때처럼 `ExprUnit` 이 요구되는 자리에서만 사용.
 
-## 스키마 정의
+## 컬럼 정책 (nullable / default)
 
 컬럼은 `NOT NULL` 기본. `.nullable()` / `.default(...)` 는 도메인 근거가 있을 때만 사용.
 

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

@@ -62,6 +62,13 @@ API·함수가 단순 입력(리터럴·기본값·직접 인자)을 그대로
 - 안티패턴: 문제된 항목만 skip 하고 나머지를 완료 처리 — 데이터가 부분 반영되어 정합성이 깨짐.
 - 부분 성공을 의도적으로 허용하려면(예: 배치 중 실패분만 리포트) 사용자에게 보고 후 합의에 따름.
 
+## 변수 명명 시
+
+식별자(param·var·const·let) 전체가 `name` 인 것 금지. 무엇의 이름인지 드러내는 식별자로 대체. `name` 을 일부로 포함하는 식별자(`fileName`·`userName` 등)는 허용.
+
+- 나쁜 예: `const name = ...`, `function f(name: string)`.
+- 좋은 예: `const fileName = ...`, `function f(userName: string)`.
+
 ## 사용자에게 노출되는 알림 작성 시 심각도 분류
 
 사용자에게 노출되는 알림(로그·토스트·다이얼로그 등)의 심각도 분류 기준:

package/claude/sd-system-prompt.md

@@ -66,8 +66,9 @@ Claude 에이전트가 반드시 지켜야 할 행동 지침.
     - 결정 대상 처리 후 남은 결정 대상이 있으면 멈추지 말고 다음 결정 대상으로 진행.
 - 질문 구조: 맥락 + 질문 + 선택지(번호) + 추천.
     - 여러 제안이 있을 경우 모든 제안이 선택지에 포함.
-- 질문당 결정 대상 1건:
-    - 결정 대상 여러개를 하나의 질문으로 묶지 말 것 (여러 결정 대상을 "모두 확정" 또는 "큰 그림 채택 → 다항목 자동 진행" 식으로 묶지 말 것).
+- 질문당 결정 대상 1건 (사전 차단):
+    - 한 응답의 "옵션" 블록은 결정 대상 1건에 대해서만 출력. 결정 대상 2건 이상이면 첫 1건만 옵션 제시, 나머지는 이 응답에 적지 않음 (개수·이름 나열도 금지).
+    - 금지 표현: "확인할 결정 (N건)", "답을 한 번에", 여러 결정 대상의 번호 나열, "모두 확정", "큰 그림 채택 → 다항목 자동 진행".
     - 답변 받은 뒤 다음 결정 대상으로 이동.
 - `AskUserQuestion` 도구 사용 금지.
 
@@ -84,11 +85,6 @@ Claude 에이전트가 반드시 지켜야 할 행동 지침.
     - 좋은 예: 묻지 않고 Grep·Read 수행 → 결과 기반 다음 행동 결정.
 - 판정 기준: "사용자만 답할 수 있는가?" 가 아니라 "에이전트 도구로 답이 나오는가?" 를 먼저 확인. 도구로 나오면 묻지 않음.
 
-**응답 전송 직전 자가 점검**:
-
-- 마지막 문장에 우선순위·순서·그룹화·진행 트리거를 사용자에게 위임하는 표현이 있는가?
-    - Yes → 첫 결정 대상 1건만 옵션 제시 질문으로 재작성 후 전송.
-
 **예시** (시나리오: 어떤 함수에 캐시 도입. 결정 대상 3건 — 라이브러리·TTL·무효화 전략):
 
 ❌ 나쁜 예 (한 번에 묶기 + 후보 누락 + 추천 없음 + 점검 생략):
@@ -170,6 +166,7 @@ X 함수에 캐시 도입 검토 중. 기존 의존성 확인 결과 lru-cache
 
 - 가설1: <[결정 근거](#결정-근거) 인용> → <채택/기각>
 - 가설2: ...
+- 채택 가설 정합성 검증: 그 원인이 참이라 가정하면 보고된 증상이 반드시 도출되는가 + 이를 반박할 증거는 없는가 → <통과 / 실패 시 가설 재검토>
 
 해결책:
 
@@ -222,7 +219,7 @@ X 함수에 캐시 도입 검토 중. 기존 의존성 확인 결과 lru-cache
 
 ### 어휘·태도
 
-- 한국어 원어민 수준으로 자연스럽게 응답.
+- **한국어** 원어민 수준으로 자연스럽게 응답.
 - 통용 표현 우선. 단, 구어·속어·비속어는 통용되더라도 금지 (예: "퉁치다"→"대신하다"). LLM이 자체 조합한 신조어·합성어도 금지 — 글에서 흔히 쓰는 단어로.
 - 직설적이고 솔직하게 응답. 형식어·완곡어·균형형 응답 금지.
 - 결론·답·핵심 먼저, 근거·맥락·세부는 그 다음 (두괄식).

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

@@ -0,0 +1,43 @@
+---
+name: sd-debug
+description: 버그·실패·예외의 원인을 다관점으로 발굴하고 가설별 검증·해결책·적대검증을 거쳐 검증된 해결책을 제안하는 멀티에이전트 디버깅. Use when 버그·예외·실패의 근본 원인 분석과 해결책이 필요할 때.
+---
+
+# sd-debug
+
+디버깅 요청 시 멀티에이전트 워크플로(`workflow.js`)에 원인 발굴·검증·적대검증을 위임하고, 그 결과를 메인 루프가 사용자에게 제시·결정 처리.
+
+## 절차
+
+1. **문제 확정** — 증상·기대동작·관찰결과를 확정.
+   - 대화 중 오류를 논의하다 진입했으면, 그때까지의 맥락(증상·에러·스택·시도·관찰)을 요약해 문제 설명으로 합성.
+   - 에러 메시지·스택·재현조건·관련 코드 경로·환경은 있으면 함께 모음(선택).
+   - 문제 설명조차 불명확하면 사용자에게 묻기.
+
+2. **워크플로 실행** — Workflow 도구로 이 스킬의 `workflow.js` 실행:
+   - `Workflow({ scriptPath: ".claude/skills/sd-debug/workflow.js", args: <문제 설명> })`.
+   - `args` 는 1단계의 문제 설명(자연어 문자열 또는 `{ problem, error, repro, paths, env }` 객체).
+   - 관점 도출·가설 발굴·검증·해결책 탐색·적대검증·병합은 워크플로가 자율 수행.
+
+3. **병합·우선순위화** — 반환값 `survived[]` 를 메인이 직접 정리:
+   - 같은 근본 원인의 가설이 중복되면 병합.
+   - 각 가설의 해결책 중 `passed: true` 인 것을 채택하되 `revisions`(교정)를 반영하고 `risks` 는 잔존 리스크로 보존.
+   - (검증 confidence: confirmed>uncertain) + (적대검증 통과 강도 `votes`) + (원인-증상 직접성)으로 우선순위 정렬.
+
+4. **결과 렌더** — 행동 규칙 "문제 발생 시" 의 3블록으로 제시:
+   - 원인 가설: `survived[].hypothesis`·`cause` (+ `dropped[]` 로 기각된 가설과 사유).
+   - 검증: 각 항목의 `verdict`·`verifyReason` (uncertain 은 "근거 약함" 으로 표시).
+   - 해결책: 채택한 해결책(교정 반영) + 잔존 리스크.
+
+5. **결정 진행** — 채택 해결책 후보가 1건 이상이면 행동 규칙 "사용자 질의 시" 의 결정 진행 모드로 전환(우선순위 순). 사용자가 고른 해결책만 실제 수정에 착수.
+
+6. **미해결 보고** — `summary.noSolution` 이면(검증된 해결책 0건) `survived[]` 의 가설·탈락 사유와 `dropped[]` 를 제시해 다음 수동 디버깅의 출발점으로 삼게 함.
+
+## 워크플로 반환 구조
+
+- `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`: 입력 문제 요약.

package/claude/skills/sd-debug/workflow.js

@@ -0,0 +1,390 @@
+export const meta = {
+  name: "sd-debug",
+  description:
+    "버그·실패·예외의 원인 가설을 다관점으로 발굴하고 가설별로 검증→해결책→적대검증을 거쳐 검증된 해결책을 구조화 보고하는 멀티에이전트 디버깅",
+  phases: [
+    { title: "Hypothesize", detail: "관점 동적 생성 + 관점별 병렬 추출 + 자유탐색 + 의미 중복제거" },
+    { title: "Verify", detail: "가설별 검증→해결책 통합 (명백 오류·근거 전무 기각, 통과 시 근본 우선 해결책 ≤2, 무배리어)" },
+    { title: "Adversarial", detail: "가설+해결책 쌍별 4관점 적대검증 veto+다수결 (무배리어)" },
+  ],
+};
+
+// ── 입력 ───────────────────────────────────────────────────────
+// args: 문제 설명(필수). 에러·스택·재현조건·코드경로·환경은 선택.
+//       대화 맥락에서 호출되면 메인 루프가 위 정보를 요약해 args 로 전달.
+if (args == null || (typeof args === "string" && args.trim() === "")) {
+  throw new Error(
+    "디버깅할 문제 설명을 args 로 전달하세요 (증상·기대동작·관찰결과 등; 에러/재현조건/코드경로는 선택).",
+  );
+}
+const problem = typeof args === "string" ? args : JSON.stringify(args);
+
+// ── 공통 원칙(모든 단계 주입) ──────────────────────────────────
+const PRINCIPLES = `
+디버깅 원칙:
+- 모든 판정은 실제 코드/설정을 Read 하여 확인. 근거 없는 추측·일반론 금지(추측은 '가설'로만 등록, 사실로 단정 금지).
+- 현재 워킹트리만 기준. git log/diff/show/blame 등 과거 조회 금지. .back/ 및 .gitignore 등재 경로(node_modules·dist·.tmp 등) 읽지 말 것.
+- 결측(null/undefined)은 결측대로 다룰 것. 빈 값을 추측으로 채우지 말 것.
+- 입력 정보가 부족하면 Grep/Glob/Read 로 코드베이스를 직접 조사해 보강.
+`;
+
+// ── fail-fast 가드 ─────────────────────────────────────────────
+// parallel/pipeline 배리어 직후 호출. 결과에 null(에이전트 reject/스킵)이 하나라도 있으면
+// 부분 결과로 진행하지 않고 즉시 throw. 정상이지만 빈 결과(빈 배열 등)는 null 이 아니라 통과.
+function assertNoFailures(results, stage, labels) {
+  const failed = results.flatMap((r, i) => (r ? [] : [labels?.[i] ?? `#${i}`]));
+  if (failed.length > 0) {
+    throw new Error(
+      `[${stage}] 에이전트 ${failed.length}/${results.length}건 실행 실패(null) — 부분 결과로 진행 금지(fail-fast). 실패: ${failed.join(", ")}. resume 로 재실행하면 성공분은 캐시됩니다.`,
+    );
+  }
+}
+
+// ── 적대검증 관점 4개 ──────────────────────────────────────────
+const LENSES = [
+  { key: "causal", title: "인과", focus: "해결책이 이 가설의 원인을 실제로 제거하는가. 원인-증상 인과가 성립하는가." },
+  {
+    key: "regression",
+    title: "회귀·부작용",
+    focus:
+      "해결책이 새 버그·룰 위반·엣지케이스(결측 null/undefined·동시성/트랜잭션·soft delete 동명 레코드·권한 분기·타입/스키마 제약)를 유발하는가.",
+  },
+  { key: "evidence", title: "증거 정합", focus: "가설의 근거가 실제 코드/스택과 일치하는가. 오인·과장은 없는가." },
+  { key: "alternative", title: "대안 원인", focus: "이 가설 말고 다른 원인이 진짜일 가능성은 없는가." },
+];
+
+// ── 의심 범주 예시(단일 소스 — 스키마 설명·관점 도출 프롬프트가 공유) ──
+const PERSPECTIVE_EXAMPLES =
+  "동시성·타이밍, 데이터·결측, 타입·계약, 로직·경계조건, 외부의존·환경·설정, 상태·생명주기";
+
+// ── 스키마 ─────────────────────────────────────────────────────
+const PERSPECTIVES_SCHEMA = {
+  type: "object",
+  additionalProperties: false,
+  required: ["perspectives", "notes"],
+  properties: {
+    perspectives: {
+      type: "array",
+      items: {
+        type: "object",
+        additionalProperties: false,
+        required: ["key", "title", "focus"],
+        properties: {
+          key: { type: "string" },
+          title: { type: "string", description: `의심 범주 이름(예: ${PERSPECTIVE_EXAMPLES})` },
+          focus: { type: "string", description: "이 관점이 의심하는 구체 지점" },
+        },
+      },
+    },
+    notes: { type: "string", description: "증상에서 이 관점들을 고른 근거" },
+  },
+};
+
+const HYPOTHESES_SCHEMA = {
+  type: "object",
+  additionalProperties: false,
+  required: ["hypotheses"],
+  properties: {
+    hypotheses: {
+      type: "array",
+      items: {
+        type: "object",
+        additionalProperties: false,
+        required: ["title", "cause", "perspective", "evidenceExpected", "refuteSignal"],
+        properties: {
+          title: { type: "string", description: "가설 한 줄 요약" },
+          cause: { type: "string", description: "원인 가설 상세(무엇이 어떻게 증상을 일으키는가)" },
+          perspective: { type: "string", description: "이 가설이 나온 관점(자유탐색이면 'free')" },
+          evidenceExpected: { type: "string", description: "이 가설이 맞다면 코드/로그에서 보일 근거" },
+          refuteSignal: { type: "string", description: "이 가설이 틀렸다면 보일 반증 신호" },
+        },
+      },
+    },
+  },
+};
+
+const VERIFY_SOLVE_SCHEMA = {
+  type: "object",
+  additionalProperties: false,
+  required: ["verdict", "reason", "refinedCause", "solutions"],
+  properties: {
+    verdict: {
+      type: "string",
+      enum: ["confirmed", "uncertain", "rejected"],
+      description: "confirmed=근거 확인, uncertain=일부라도 코드로 뒷받침(통과), rejected=명백히 틀림 또는 근거 전무+반증 우세",
+    },
+    reason: { type: "string", description: "코드를 Read 해 확인한 판정 근거(근거 인용)" },
+    refinedCause: { type: "string", description: "검증으로 구체화된 원인(통과 시). rejected 면 빈 문자열" },
+    solutions: {
+      type: "array",
+      description: "통과(confirmed/uncertain) 시 근본 원인 직접 제거 정도가 높은 순으로 정렬한 해결책 후보(최대 2). rejected 면 빈 배열",
+      items: {
+        type: "object",
+        additionalProperties: false,
+        required: ["approach", "mechanism", "changeScope"],
+        properties: {
+          approach: { type: "string", description: "해결 접근 한 줄" },
+          mechanism: { type: "string", description: "이 접근이 원인을 어떻게 제거하는가" },
+          changeScope: { type: "string", description: "대략의 수정 범위(파일·함수)" },
+        },
+      },
+    },
+  },
+};
+
+const ADVERSARIAL_SCHEMA = {
+  type: "object",
+  additionalProperties: false,
+  required: ["lenses"],
+  properties: {
+    lenses: {
+      type: "array",
+      minItems: LENSES.length,
+      description: "각 적대검증 관점의 판정 (LENSES 4개 전부, 관점마다 1개 항목)",
+      items: {
+        type: "object",
+        additionalProperties: false,
+        required: ["lens", "pass", "critical", "reason", "revisedNote"],
+        properties: {
+          lens: { type: "string", description: "이 판정의 관점 이름" },
+          pass: { type: "boolean", description: "이 관점에서 해결책이 통과하는가(true=문제없음)" },
+          critical: {
+            type: "boolean",
+            description: "발견한 결함이 치명적인가(회귀 유발·인과 불성립은 true). pass=true 면 false",
+          },
+          reason: { type: "string", description: "코드 확인 기반 판정 근거" },
+          revisedNote: { type: "string", description: "결함 있으면 교정 제안. 없으면 빈 문자열" },
+        },
+      },
+    },
+  },
+};
+
+// ── 단계별 프롬프트 ────────────────────────────────────────────
+const verifySolvePrompt = (h) => `문제: ${problem}
+
+${PRINCIPLES}
+
+너의 일: 아래 원인 가설을 실제 코드를 Read 해 검증하고(관대 기준), 통과하면 같은 코드 근거 위에서 해결책까지 도출하라.
+
+1) 검증:
+- confirmed: 코드에서 근거를 확인함.
+- uncertain: 근거가 부분적·애매하지만 코드에서 일부라도 뒷받침됨 — 통과시킴(이후 적대검증이 거른다).
+- rejected: 코드로 보아 '명백히 틀린' 경우, 또는 코드에서 근거가 전혀 확인되지 않고 반증신호가 우세한 경우. 단 코드에서 일부라도 뒷받침되면 기각하지 말고 uncertain(진짜 원인이면 코드에 근거가 남으므로, '근거 전무'만 기각해 누락을 막는다).
+- 판정 근거(reason)에 확인한 코드 위치·내용을 인용. 통과면 refinedCause 에 구체화된 원인을 적을 것.
+
+2) 해결책(rejected 가 아닐 때만):
+- 검증하며 확인한 코드 근거 위에서, 근본 원인을 가장 직접적으로 제거하는 정도가 높은 순으로 정렬해 해결책 후보를 최대 2개, 서로 접근이 다르게.
+- 각 후보에 approach·mechanism(원인을 어떻게 제거하나)·changeScope(수정 범위) 채움.
+- 과도한 설계(over-engineering)·증상만 가리는 임시방편은 피할 것.
+- rejected 면 solutions 를 빈 배열로 둘 것.
+
+가설:
+- 제목: ${h.title}
+- 원인: ${h.cause}
+- 관점: ${h.perspective}
+- 예상 근거: ${h.evidenceExpected}
+- 반증 신호: ${h.refuteSignal}`;
+
+const adversarialPrompt = (h, verdict, sol) => `문제: ${problem}
+
+${PRINCIPLES}
+
+너의 일: 아래 (원인 가설 + 해결책) 쌍을 다음 4개 관점 각각에서 적대적으로 공격하라. 기본 입장은 '이 해결책은 결함이 있다'로 두고 약점을 찾을 것. 각 관점을 서로 끌려가지 말고 독립적으로 판정해 lenses 배열로 반환(관점마다 1개 항목).
+
+관점:
+${LENSES.map((l) => `- ${l.title}: ${l.focus}`).join("\n")}
+
+각 관점 판정:
+- pass=false 로 둘 결함을 찾으면 reason 에 코드 근거와 함께 적고, 치명적(회귀 유발·인과 불성립 등)이면 critical=true. 교정안이 있으면 revisedNote 에.
+- 그 관점에서 결함이 없으면 pass=true, critical=false, revisedNote="".
+
+원인 가설: ${h.title} — ${verdict?.refinedCause || h.cause}
+해결책: ${sol.approach} / ${sol.mechanism} (수정 범위: ${sol.changeScope})`;
+
+// ── [Hypothesize] 관점 생성 → 관점별 병렬 추출 + 자유탐색 → 중복제거 ──
+phase("Hypothesize");
+
+const perspectivePlan = await agent(
+  `문제: ${problem}
+
+${PRINCIPLES}
+
+너의 일 (디버깅 1단계 — 의심 관점 도출). 위 증상을 보고, 원인을 찾을 때 서로 겹치지 않는 '의심 관점(범주)'을 도출하라.
+- 증상 성격에 맞춰 동적으로 고를 것. 예시 범주: ${PERSPECTIVE_EXAMPLES}. (예시일 뿐 — 증상에 맞게 가감)
+- 각 관점에 key, title, focus(이 관점이 의심하는 구체 지점)를 채울 것.
+- 보통 3~6개. 증상을 좁게 가리키면 적게, 막연하면 넓게.
+- 관점 선정 근거를 notes 에.`,
+  { label: "perspectives", phase: "Hypothesize", schema: PERSPECTIVES_SCHEMA },
+);
+
+if (!perspectivePlan) throw new Error("[Hypothesize/perspectives] 관점 도출 에이전트 실행 실패(null) — 중단.");
+const PERSPECTIVES = (perspectivePlan.perspectives ?? []).filter(Boolean);
+if (PERSPECTIVES.length === 0) throw new Error("의심 관점을 도출하지 못했습니다.");
+log(`관점 ${PERSPECTIVES.length}개: ${PERSPECTIVES.map((p) => p.title).join(", ")}`);
+
+const extractTasks = PERSPECTIVES.map((p) => () =>
+  agent(
+    `문제: ${problem}
+
+${PRINCIPLES}
+
+너의 일: 오직 '${p.title}' 관점에서만 원인 가설을 발굴하라. 이 관점의 의심 지점: ${p.focus}
+- 코드베이스를 Grep/Glob/Read 로 직접 조사해 이 관점에 해당하는 원인 후보를 가능한 한 빠짐없이 뽑을 것(재현율 우선).
+- 다른 관점의 원인은 무시(중복은 이후 단계가 정리).
+- 각 가설에 title·cause·perspective('${p.title}')·evidenceExpected·refuteSignal 을 채울 것.
+- 해당 관점에서 원인이 안 보이면 hypotheses 를 비울 것(억지 생성 금지).`,
+    { label: `extract:${p.key}`, phase: "Hypothesize", schema: HYPOTHESES_SCHEMA },
+  ),
+);
+
+const freeTask = () =>
+  agent(
+    `문제: ${problem}
+
+${PRINCIPLES}
+
+너의 일: 어떤 정해진 관점에도 매이지 말고 자유롭게 원인 가설을 발굴하라(사각지대 안전망).
+- 앞서 정한 관점 목록(${PERSPECTIVES.map((p) => p.title).join(", ")})에 잘 안 들어가는 원인일수록 가치가 크다.
+- 코드베이스를 직접 조사해 근거 기반으로 뽑을 것. 각 가설에 title·cause·perspective('free')·evidenceExpected·refuteSignal 채움.`,
+    { label: "extract:free", phase: "Hypothesize", schema: HYPOTHESES_SCHEMA },
+  );
+
+const extracted = await parallel([...extractTasks, freeTask]);
+assertNoFailures(extracted, "Hypothesize/extract", [...PERSPECTIVES.map((p) => `extract:${p.key}`), "extract:free"]);
+const rawHypotheses = extracted.flatMap((r) => r.hypotheses ?? []);
+if (rawHypotheses.length === 0) {
+  throw new Error("원인 가설을 하나도 도출하지 못했습니다. 문제 설명을 보강해 재호출하세요.");
+}
+
+const dedup = await agent(
+  `아래는 여러 관점에서 발굴된 원인 가설들이다(JSON). 의미 기준으로 병합·중복제거하라.
+
+병합 규칙:
+- '같은 근본 원인'을 가리키는 가설끼리만 하나로 합칠 것(표현만 다른 중복 제거). 근본 원인이 다르면 절대 합치지 말 것(서로 다른 원인을 뭉개면 검증에서 통째 탈락한다).
+- 병합 시 evidenceExpected·refuteSignal 은 합쳐 보존. perspective 는 합쳐진 관점들을 표기.
+- 개수를 인위적으로 줄이지 말 것(재현율 우선). 진짜 중복만 제거.
+
+가설들(JSON):
+${JSON.stringify(rawHypotheses)}`,
+  { label: "dedup", phase: "Hypothesize", schema: HYPOTHESES_SCHEMA },
+);
+
+if (!dedup) throw new Error("[Hypothesize/dedup] 중복제거 에이전트 실행 실패(null) — 중단.");
+const HYPOTHESES = (dedup.hypotheses ?? []).filter(Boolean);
+if (HYPOTHESES.length === 0) throw new Error("중복제거 후 남은 가설이 없습니다.");
+log(`가설 ${HYPOTHESES.length}개 (원시 ${rawHypotheses.length}개에서 병합)`);
+
+// ── 비용 상한: 곱셈이 시스템 상한(1000) 근접 시 사전 throw ───────
+// 가설은 안 자른다(누락 방지). 전체 곱셈이 상한 근접하면 통째 throw 로 보고.
+const EST_PER_HYP = 1 /*verify+solve 통합*/ + 2 /*adversarial: 해결책 후보당 1(4관점 통합)*/;
+const EST_AGENTS = HYPOTHESES.length * EST_PER_HYP;
+const SAFE_AGENT_LIMIT = 900;
+if (EST_AGENTS > SAFE_AGENT_LIMIT) {
+  throw new Error(
+    `가설 ${HYPOTHESES.length}개 × 단계 ≈ ${EST_AGENTS} 에이전트로 시스템 상한(1000) 근접. 가설을 자르면 중요한 원인이 누락될 수 있으니, 문제 설명을 더 좁혀 재호출하세요.`,
+  );
+}
+
+// ── [Verify(+Solve)]→[Adversarial] 가설별 파이프라인 (무배리어) ──
+phase("Verify");
+const piped = await pipeline(
+  HYPOTHESES,
+  // stage1: 검증+해결책 통합 (한 에이전트가 검증하며 읽은 코드로 바로 해결책까지)
+  (h, _h, i) =>
+    agent(verifySolvePrompt(h), { label: `diagnose:${i}`, phase: "Verify", schema: VERIFY_SOLVE_SCHEMA }).then((v) => ({
+      index: i,
+      hypothesis: h,
+      verdict: { verdict: v.verdict, reason: v.reason, refinedCause: v.refinedCause },
+      solutions: v.verdict === "rejected" ? [] : (v.solutions ?? []).slice(0, 2),
+    })),
+  // stage2: 적대검증 (해결책별 fan-out, 4관점은 단일 에이전트가 1회 통합 판정)
+  (prev, h, i) => {
+    // stage1 실패(null)는 복구하지 말고 그대로 전파 → line 320 assertNoFailures(piped) 가 포착(fail-fast).
+    if (!prev) return null;
+    // 여기부터 prev 는 비-null 보장 → verdict 보존됨(정상 무해결책만 빈 judged 로 통과).
+    if (!prev.solutions || prev.solutions.length === 0) return Promise.resolve({ ...prev, judged: [] });
+    return parallel(
+      prev.solutions.map((sol, si) => () =>
+        agent(adversarialPrompt(h, prev.verdict, sol), {
+          label: `adv:${i}:${si}`,
+          phase: "Adversarial",
+          schema: ADVERSARIAL_SCHEMA,
+        }).then((v) => ({ solution: sol, lensResults: (v?.lenses ?? []).filter(Boolean) })),
+      ),
+    ).then((judged) => {
+      assertNoFailures(judged, `Adversarial(가설#${i})`, prev.solutions.map((_, si) => `adv:${i}:${si}`));
+      return { ...prev, judged };
+    });
+  },
+);
+
+// ── 집계: 검증 기각 분리 + 해결책 veto+다수결 판정 ──────────────
+// fail-fast: stage1(diagnose) reject 또는 stage2(adversarial) 실패로 null 이 된 가설이 하나라도 있으면 중단.
+assertNoFailures(piped, "Verify/Adversarial", HYPOTHESES.map((h) => h.title));
+const results = piped;
+const droppedH = results.filter((x) => x.verdict?.verdict === "rejected");
+const survivedH = results.filter((x) => x.verdict && x.verdict.verdict !== "rejected");
+
+function judgeSolution(j) {
+  const lr = (j.lensResults ?? []).filter(Boolean);
+  const veto = lr.some((l) => l.critical === true && l.pass === false); // 치명결함 1표면 기각
+  const passVotes = lr.filter((l) => l.pass === true).length;
+  const total = lr.length;
+  const passed = !veto && total > 0 && passVotes > total / 2; // veto 없으면 통과 다수결
+  const risks = lr.filter((l) => l.pass === false).map((l) => `[${l.lens}] ${l.reason}`);
+  const revisions = lr.filter((l) => l.revisedNote && l.revisedNote.trim() !== "").map((l) => `[${l.lens}] ${l.revisedNote}`);
+  return { passed, veto, passVotes, total, risks, revisions };
+}
+
+const survivedDetailed = survivedH.map((x) => {
+  const sols = (x.judged ?? []).map((j) => ({ solution: j.solution, ...judgeSolution(j) }));
+  return {
+    hypothesis: x.hypothesis,
+    verdict: x.verdict.verdict,
+    verifyReason: x.verdict.reason,
+    refinedCause: x.verdict.refinedCause,
+    solutions: sols,
+    passedSolutions: sols.filter((s) => s.passed),
+  };
+});
+
+const solutionsPassed = survivedDetailed.reduce((n, x) => n + x.passedSolutions.length, 0);
+const noSolution = solutionsPassed === 0;
+
+// 병합·우선순위화·렌더·결정 진행은 호출측(SKILL.md/메인 루프)이 수행.
+// 워크플로는 검증·적대검증 완료된 가설+해결책(평탄화) + 기각 가설을 구조화 반환.
+return {
+  problem,
+  perspectives: PERSPECTIVES.map((p) => p.title),
+  summary: {
+    hypotheses: HYPOTHESES.length,
+    confirmed: survivedH.filter((x) => x.verdict.verdict === "confirmed").length,
+    uncertain: survivedH.filter((x) => x.verdict.verdict === "uncertain").length,
+    dropped: droppedH.length,
+    solutionsPassed,
+    noSolution,
+  },
+  survived: survivedDetailed.map((x) => ({
+    hypothesis: x.hypothesis.title,
+    cause: x.refinedCause || x.hypothesis.cause,
+    perspective: x.hypothesis.perspective,
+    verdict: x.verdict,
+    verifyReason: x.verifyReason,
+    solutions: x.solutions.map((s) => ({
+      approach: s.solution.approach,
+      mechanism: s.solution.mechanism,
+      changeScope: s.solution.changeScope,
+      passed: s.passed,
+      vetoed: s.veto,
+      votes: `${s.passVotes}/${s.total}`,
+      risks: s.risks,
+      revisions: s.revisions,
+    })),
+  })),
+  dropped: droppedH.map((x) => ({
+    hypothesis: x.hypothesis.title,
+    cause: x.hypothesis.cause,
+    reason: x.verdict.reason,
+  })),
+};