@simplysm/sd-claude 14.0.90 → 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/client-system-log.md

@@ -39,6 +39,10 @@ export const SystemLog = Table("SystemLog")
 `provideAppInitializer` 안에서 `SdSystemLogProvider.writeFn` 에 적재 함수를 할당.
 
 ```ts
+import { inject, provideAppInitializer } from "@angular/core";
+import { DateTime, json } from "@simplysm/core-common";
+import { SdSystemLogProvider } from "@simplysm/angular";
+
 provideAppInitializer(() => {
   const appService = inject(AppServiceProvider);
   const appOrm = inject(AppOrmProvider);
@@ -50,7 +54,7 @@ provideAppInitializer(() => {
         {
           dateTime: new DateTime(),
           severity,
-          message: logs
+          message: data
             .map((l) =>
               typeof l === "string"
                 ? l
@@ -71,7 +75,7 @@ provideAppInitializer(() => {
 ```
 
 - `CLIENT_NAME` 은 `provideSdAngular({ clientName: CLIENT_NAME })` 에 넘긴 값과 동일하게 두어 어느 앱에서 난 로그인지 구분.
-- `data` 는 가변 인자 배열이므로 `JSON.stringify(data)` 로 통째로 저장.
+- `data` 는 가변 인자 배열. 각 인자를 string→그대로 / Error→`stack` / 객체→`json.stringify` 로 문자열화해 공백으로 join 하여 저장(Error 의 `stack` 보존).
 - `writeFn` 미설정 시 외부 적재는 일어나지 않고 콘솔 출력만 수행됨. DB 적재가 필요한 앱에서만 배선.
 
 ## 자동으로 적재되는 로그

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`: 입력 문제 요약.