@simplysm/sd-claude 14.0.94 → 14.0.95

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)를 정리해 사용자에게 제시.

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

@@ -1,6 +1,7 @@
 ---
 name: sd-spec
 description: SI/업무시스템 요구사항을 분석해 spec.md 로 구조화. 배치 작성(분석/설계 워크플로) + 부분 수정 인라인 처리. Use when "요구사항 분석", "SI 분석", "업무시스템 spec 작성" 을 요청할 때.
+model: xhigh
 ---
 
 # sd-spec

package/package.json

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

package/claude/references/sd-simplysm14/apis/angular/infra.md

@@ -1,82 +0,0 @@
-# @simplysm/angular — 앱 부트스트랩·전역 설정
-
-앱 시작 시 1회 배선하는 `provideSdAngular` 와, `providedIn: "root"` 로 어디서든 inject 하는 전역 프로바이더(테마·로컬스토리지·시스템설정·시스템로그·서비스클라이언트)를 모은 군. 화면보다 부트스트랩(`provideAppInitializer`)·앱 셸·설정 코드에서 같이 읽힌다.
-
-## provideSdAngular
-
-zoneless Angular 앱의 핵심 프로바이더 묶음을 `EnvironmentProviders` 로 생성. `bootstrapApplication` 의 `providers` 에 한 번 넣음.
-
-- `opt.clientName: string` — 클라이언트 식별명. `SdAngularConfigProvider.clientName` 으로 저장되어 로컬스토리지 키 prefix·서비스 클라이언트 연결명에 쓰임.
-
-배선 내용(본문 기준): zoneless 변경 감지, ng-icons 기본 설정(stroke 1.5, size 1.33em), `IMAGE_CONFIG` 경고 끔, 전역 `ErrorHandler` 를 `SdGlobalErrorHandlerPlugin` 으로, `EVENT_MANAGER_PLUGINS` 에 `SdOptionEventPlugin` 추가, `window` 의 `error`/`unhandledrejection` 을 `ErrorHandler` 로 위임, 저장된 dark/fontSize 를 `SdThemeProvider` 에 복원하고 변경 시 로컬스토리지에 영속, 서비스워커 업데이트 주기 폴링(확인 시 새로고침 prompt, 실패 시 지수 백오프), 라우터 네비게이션 동안 `SdBusyProvider.globalBusyCount` 증감.
-
-```ts
-bootstrapApplication(AppComponent, {
-  providers: [provideSdAngular({ clientName: "wms-admin" }), provideRouter(routes)],
-});
-```
-
-## SdAngularConfigProvider
-
-`provideSdAngular` 가 채우는 전역 설정 보관소. 직접 set 하지 않고 `provideSdAngular(opt)` 로 주입됨.
-
-- `clientName: string` — 앱 식별명. 로컬스토리지 키·서비스 클라이언트명으로 참조.
-
-## SdThemeProvider
-
-다크모드·글자크기 전역 상태. `provideSdAngular` 가 로컬스토리지와 동기화. `sd-theme-selector` 가 이 프로바이더를 토글.
-
-- `dark: WritableSignal<boolean>` — 다크 모드 여부. true 면 `document.body` 에 `sd-theme-dark` 클래스 토글. 다크/라이트 전환 시.
-- `fontSize: WritableSignal<number>` — 루트 글자 크기(px). 변경 시 `documentElement.style.fontSize` 반영.
-- `fontSizePresets: readonly number[]` — 선택 가능한 글자 크기 단계(`[12,14,16,20,24,28]`).
-- `increaseFontSize()` / `decreaseFontSize()` — 프리셋에서 한 단계 위/아래로 이동.
-
-## SdLocalStorageProvider<T>
-
-`clientName` 을 prefix 로 붙여 `localStorage` 에 JSON 직렬화 저장/조회. 제네릭 `T` 로 키→값 타입 매핑.
-
-- `set<K>(key, value)` — `"{clientName}.{key}"` 키에 `JSON.stringify` 저장.
-- `get<K>(key): T[K] | undefined` — 저장값 파싱. 없거나 파싱 실패 시 `undefined`(결측 보존).
-- `remove(key)` — 키 삭제.
-
-```ts
-private readonly _ls = inject<SdLocalStorageProvider<{ lastTab: string }>>(SdLocalStorageProvider);
-this._ls.set("lastTab", "summary");
-```
-
-## SdSystemConfigProvider<T>
-
-화면별 사용자 설정(시트 컬럼 구성 등)을 서버 또는 로컬에 저장/조회. `fn` 미설정 시 `SdLocalStorageProvider` 로 폴백.
-
-- `fn?: { set(key, data); get(key) }` — 외부 저장 콜백. 설정하면 서버 등에 위임, 미설정 시 로컬스토리지 사용.
-- `setAsync<K>(key, data)` — `data` 가 null 이면 삭제, 아니면 저장.
-- `getAsync(key)` — 저장값 조회.
-
-## injectSdSystemConfigResource<T>
-
-`SdSystemConfigProvider` 를 host 태그명+key 로 감싼 Angular `resource` 래퍼. 시트가 컬럼 구성 영속화에 사용. injection 컨텍스트에서 호출.
-
-- `options.key: Signal<string | undefined>` — 설정 식별 키 시그널. `undefined` 면 로드/저장 안 함. 저장 키는 `"{호스트태그}.{key}"`.
-- 반환: `value`/`isLoading`/`status`/`hasValue()`/`reload()` 와, 값을 set 하면 즉시 `setAsync` 로 영속하는 `set(value)`·`update(fn)`.
-
-## SdSystemLogProvider
-
-콘솔 로깅 + 외부(DB 등) 적재를 겸하는 시스템 로그 프로바이더. 전역 에러 핸들러가 이걸로 에러를 기록.
-
-- `writeFn?: (severity: "error"|"warn"|"log", ...data) => Promise<void>|void` — 외부 적재 콜백. 설정 시 콘솔 출력 후 호출(실패해도 throw 안 하고 logger.error).
-- `writeAsync(severity, ...data)` — 콘솔에 해당 severity 로 출력하고, `writeFn` 있으면 함께 적재.
-
-```ts
-const sysLog = inject(SdSystemLogProvider);
-sysLog.writeFn = (sev, ...data) => appService.systemLog.writeAsync(sev, data);
-```
-
-## SdServiceClientFactoryProvider
-
-키별로 `ServiceClient`(`@simplysm/service-client`) 연결을 생성·보관·종료하고, 요청/응답 진행률을 토스트로 표시.
-
-- `connectAsync(key, options?)` — 현재 location(host/port/ssl) 기본값에 `options` 머지해 연결. 이미 연결/종료된 키면 throw. 진행 이벤트를 progress 토스트로.
-- `closeAsync(key)` — 해당 키 연결 종료. 미연결 키면 throw.
-- `get(key): ServiceClient` — 연결된 클라이언트 반환. 미연결/종료 키면 throw.
-
-앱 서비스 프로바이더(`AppServiceProvider`)가 이 팩토리를 감싸 쓰는 형태이며, 직접 호출보다 앱 프로바이더 경유가 일반적.