@simplysm/sd-claude 14.0.85 → 14.0.86

package/claude/skills/sd-manual/evals/fixtures/new-manual/src/notification.ts

@@ -0,0 +1,25 @@
+export type Severity = "info" | "success" | "warning" | "danger";
+
+export interface ShowOptions {
+  /** 색상 강조 단계. 기본값 "info". */
+  severity?: Severity;
+  /** 자동 사라짐 시간(ms). 기본값 3000. */
+  durationMs?: number;
+}
+
+/**
+ * 화면 우상단에 토스트 알림을 띄운다.
+ * durationMs 경과 후 자동으로 사라진다.
+ */
+export function show(message: string, opts?: ShowOptions): void {
+  const severity = opts?.severity ?? "info";
+  const durationMs = opts?.durationMs ?? 3000;
+  renderToast(message, severity, durationMs);
+}
+
+function renderToast(message: string, severity: Severity, durationMs: number): void {
+  // 실제 DOM 렌더링 (생략)
+  void message;
+  void severity;
+  void durationMs;
+}

package/claude/skills/sd-manual/evals/fixtures/update-manual/.claude/references/sd-simplysm14/manuals/notification.md

@@ -0,0 +1,14 @@
+# 알림(notification) 매뉴얼
+
+화면에 토스트 알림을 띄우는 방법.
+
+## 알림 띄우기
+
+`show(message, opts)` 로 토스트를 띄움.
+
+```ts
+show("저장되었습니다", { severity: "success" });
+```
+
+- `severity` 로 색상 강조 단계(`info`/`success`/`warning`/`danger`)를 지정.
+- `durationMs` 로 자동 사라짐 시간을 조정 (미지정 시 3초).

package/claude/skills/sd-manual/evals/fixtures/update-manual/src/notification.ts

@@ -0,0 +1,37 @@
+export type Severity = "info" | "success" | "warning" | "danger";
+
+export interface ShowOptions {
+  /** 색상 강조 단계. 기본값 "info". */
+  severity?: Severity;
+  /** 자동 사라짐 시간(ms). 기본값 3000. */
+  durationMs?: number;
+}
+
+/**
+ * 화면 우상단에 토스트 알림을 띄운다.
+ * durationMs 경과 후 자동으로 사라진다.
+ */
+export function show(message: string, opts?: ShowOptions): void {
+  const severity = opts?.severity ?? "info";
+  const durationMs = opts?.durationMs ?? 3000;
+  renderToast(message, severity, durationMs);
+}
+
+/**
+ * 확인/취소 대화상자를 띄우고 사용자의 선택을 반환한다.
+ * 확인 시 true, 취소 시 false.
+ */
+export async function confirm(message: string): Promise<boolean> {
+  return await renderConfirmDialog(message);
+}
+
+function renderToast(message: string, severity: Severity, durationMs: number): void {
+  void message;
+  void severity;
+  void durationMs;
+}
+
+async function renderConfirmDialog(message: string): Promise<boolean> {
+  void message;
+  return true;
+}

package/claude/skills/sd-manual/evals/golden.jsonl

@@ -0,0 +1,2 @@
+{"id": "case-001", "input": "/sd-manual src/notification.ts 의 알림 표시 기능 매뉴얼 만들어줘 (평가 환경 — 이 파일만 대상으로 최소 작성)", "rubric": ["manuals/ 디렉토리에 새 .md 매뉴얼 파일이 1개 이상 생성되었는가", "생성된 매뉴얼에 코드 예시 블록(``` 펜스)이 1개 이상 포함되었는가", "생성된 매뉴얼의 섹션 헤딩이 사용/작업 목적 형태(예: '~하려면', '~하기', '~띄우기')로 구성되어 있는가", "README.md 의 매뉴얼 인덱스 표 또는 목록에 새 매뉴얼로 향하는 링크 행이 1줄 추가되었는가", "fixture 에 원래 있던 기존 manuals/*.md 파일들이 삭제되지 않고 보존되었는가"], "fixture": "new-manual"}
+{"id": "case-002", "input": "/sd-manual notification 매뉴얼 최신 코드 반영해서 갱신해줘", "rubric": ["기존 manuals/notification.md 파일이 보존된 상태로 존재하는가", "갱신된 notification.md 에 src/notification.ts 의 confirm 기능에 대한 사용법이 추가되었는가", "갱신된 notification.md 에 코드 예시 블록(``` 펜스)이 포함되어 있는가", "fixture 에 원래 있던 기존 manuals/*.md 파일들이 삭제되지 않고 보존되었는가"], "fixture": "update-manual"}

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

@@ -13,7 +13,7 @@ description: 산출물(코드·문서 등) 을 적용 룰 기준으로 검증해
 
 3. **적용 룰 인용** — 도메인의 적용 룰 인용 (행동 규칙·sd-design-rules·스킬·도메인별 룰 등). 룰 항목 직접 표기.
 
-4. **룰 부합 검증** — 대상이 인용 룰에 부합하는가 점검. 위반 항목 식별.
+4. **룰 부합 전수 검증** — 인용한 모든 룰 항목을 대상의 모든 단위(코드: 함수·라인 / 문서: 섹션·문장)에 대해 빠짐없이 대조. 표본·대표 패턴만 검사하거나 일부 단위만 보고 조기 종료하는 것 금지.
 
 5. **발견 사항 분류** — 각 항목을 다음 기준으로 분류:
 

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

@@ -20,13 +20,12 @@ description: SI/업무시스템 요구사항을 분석해 spec.md 로 구조화.
 초안 1건 당 1 사이클. 6단계 모두 거치는 것이 강제.
 
 ```
-1. 무엇 선정 → 2. 초안 작성 → 3. "맞나요?" 합의 → 4. spec.md 반영 → 5. 곁가지로 나온 것 점검 → 6. 세션 종료 신호
+1. 무엇 선정 → 2. 초안 작성 → 3. "맞나요?" 합의 → 4. spec.md 반영 → 5. 곁가지로 나온 것 점검 → 6. 다음 단위 연속
 ```
 
 ### 1단계: 무엇 선정
 
 사용자 지시가 우선. 지시가 없으면 LLM 의 권장 순서 따름.
-
 #### 큰 순서 (권장)
 
 각 단계별 진입 조건·spec.md 매핑·절차 위치·다음 단계:
@@ -138,7 +137,7 @@ OPEN 섹션의 본문 = **분석 방법** (초안 아님) — 재분석할 절
   - 영향 섹션 헤더가 `[OPEN]` 상태 → 그 본문 분석 방법에 한 줄 추가 (`<날짜> 추가: <내용>`).
   - 영향 섹션 헤더가 `[확정]` 상태 → 본문 안에 인라인 `[OPEN]` 항목을 추가 (헤더 [확정] 은 유지).
   - 영향 섹션 헤더가 존재하지 않음 → 헤더 신설 + `[OPEN: 날짜]` + 본문에 분석 방법 작성.
-  - 처리 후 사용자에게 한 줄 보고. 다음 세션 재진입 시 기존 흐름이 자동으로 회수됨.
+  - 처리 후 사용자에게 한 줄 보고. 원 작업 (현재 진입 단위) 완료 후 6단계에서 같은 세션 내 이어받아 처리 — 다음 세션으로 미루지 않음.
 
 - ❌ §2.1 작성 중에 "BOA 는 매일 갱신되고 라인은 며칠 내 사라짐" 을 발견 → 아무 처리 없이 §2.1 만 계속 진행.
 - ✅ (영향 작음) §7.x 보강 사이클로 즉시 진입 → 확정 → §7.x 에 반영 → §2.1 재개.
@@ -170,7 +169,7 @@ OPEN 섹션의 본문 = **분석 방법** (초안 아님) — 재분석할 절
 §4.x/§5.x/§6.x 본문 또는 그 본문이 의존하는 § 본문을 갱신할 때, `[확정: X, 구현: Y]` 에서 `, 구현: Y` 부분만 제거하여 `[확정: X]` 로 변경 (이전 구현을 무효화 → sd-impl 재실행 대기 상태로). 확정 날짜 갱신 여부는 무관.
 
 **의존 식별** — §4.x/§5.x/§6.x 본문에 다음 중 하나라도 나타나는 §x.x 는 그 §4.x/§5.x/§6.x 의 의존 대상으로 간주:
-- `관련 섹션:` 줄의 `[프로세스.X]`·`[기타.X]`·`[화면.X]`·`[자동 처리.X]`·`[횡단 처리.X]`·`[외부인터페이스.X]`.
+- `관련 섹션:` 줄의 `[프로세스.X]`·`[기타.X]`·`[화면.X]`·`[자동 처리.X]`·`[기반.X]`·`[외부인터페이스.X]`.
 - 본문 어느 위치든 등장하는 `[모델.X…]`·`[공통 정의.X]`.
 - §7 외부 자료 명세를 컬럼명 일치로 끌어다 쓴 양식 매핑 표 (해당 §7.x).
 - 모달 호출 `→ [화면.X]` 의 그 §4.x.
@@ -182,33 +181,39 @@ OPEN 섹션의 본문 = **분석 방법** (초안 아님) — 재분석할 절
 - 적음 (5개 내외) → "다른 섹션 반영거리" 와 같은 턴에 처리. 영향 받는 §4.x/§5.x/§6.x 를 번호를 매겨 각각 한 줄 이유와 함께 묶어 "맞나요?" 합의 요청.
   - 사용자가 전부 동의 → 일괄 마커 제거.
   - 사용자가 일부 유지를 지목 (예: "3~5는 유지") → 지목된 항목은 마커 유지, 나머지만 제거.
-- 많음 → 즉시 일괄 제거 + 사용자에게 한 줄 보고 (제거된 §4/§5/§6 목록 포함). 유지 검토는 다음 세션에서 그 §4/§5/§6 진입 시 본문 재검토 단계에서 수행.
+- 많음 → 즉시 일괄 제거 + 사용자에게 한 줄 보고 (제거된 §4/§5/§6 목록 포함). 유지 검토는 이후 그 §4/§5/§6 에 진입할 때 본문 재검토 단계에서 수행.
 
-### 6단계: 세션 종료 신호
+### 6단계: 다음 단위 연속
 
-사이클 5단계 처리 후마다 자문 — "이 세션의 주 작업이 자연 종결됐는가?"
+사이클 5단계 처리 후마다 자문 — "진입 단위가 완결됐는가? 남은 결정 대상은 무엇인가?"
 
-**자연 종결 조건** (모두 충족):
-- 세션 진입 시 잡은 §x.x 큰 단위의 모든 초안이 [확정] 상태.
-- 그 작업으로 발생한 곁가지 (다른 섹션 반영거리·구현 마커 제거 등) 가 처리 완료 또는 다음 세션으로 넘김 메모가 완료된 상태.
-- 사용자의 추가 지시가 없음.
+세션을 끝내거나 "새 세션에서 진행" 을 권하지 않음. 상위 행동 규칙 ("결정 대상 여러개 → 보고 직후 즉시 진행, 트리거 위임 금지") 적용 — 컨텍스트 한도는 자동 압축이 처리하므로 분량을 이유로 멈추지 않음.
 
-**종결 시 출력**:
-- 완료한 §x.x 명시.
-- 다음 권장 §x.x 후보 1~3건 제시 (큰 순서 + 자유 진입 룰에 따라 LLM 이 판단).
+**다음 대상 선택** (위→아래 우선순위. 멈추지 말고 해당 사이클로 즉시 진입):
 
-출력 문구 모범:
+1. **현재 사이클의 남은 초안 단위** — 진입한 §x.x 의 §별 초안 단위가 남아 있으면 다음 단위로 진입.
+2. **현재 묶음의 파생·의존 항목** — 방금 확정한 §x.x 에서 5단계로 도출된 곁가지 (신규 §4.x·관련 §5/§6 분할·구현 마커 제거 등). OPEN 메모로 남겨둔 것 포함 — 다음 세션으로 미루지 말고 그 §x.x 사이클로 즉시 진입.
+3. **독립적인 다음 큰 단위** — 위 1·2 가 모두 없을 때만. 현재 묶음과 무관한 새 작업 (다른 §2.x 프로세스·다음 최상위 [OPEN] 섹션 등).
+   - 우선순위 근거 (사용자 지시·의존 순서) 가 있으면 묻지 않고 그 단위로 진입.
+   - 근거가 없으면 다음 대상을 **인세션 옵션 질문** 으로 제시 (행동 규칙 "사용자 질의 시" 형식). "새 세션" 프레이밍·"골라서 진행" 위임 금지 — 답을 받으면 같은 세션에서 계속 진행.
 
-```
-§4.2 화면 본문 모든 초안 확정. 세션 자연 종결.
+**사용자 입력 대기** (아래 중 하나일 때만 진행을 멈춤):
+- 모든 섹션이 `[확정]` 이고 본문 인라인 `[OPEN]` 도 없음 → 추가 요구 대기.
+- 남은 결정 대상이 전부 사용자 자료·결정을 기다리는 OPEN 게이트 (자료 부족·외부 의존) 라 에이전트가 더 진행할 수 없음 → 무엇이 필요한지 보고 후 대기.
+- 3번 경로에서 우선순위 근거가 없어 옵션 질문을 제시한 직후.
+
+옵션 질문 모범 (3번 경로, 우선순위 근거 없을 때):
 
-다음 권장 (1건 골라 새 세션):
-1. §4.3 화면 (같은 §2.1 입고 파생 — 의존 흐름 연속)
-2. §2.2 본문 (다음 분석 명세 — 다른 프로세스 진행)
-3. §7.2 신규 (이번 세션 곁가지로 도출)
 ```
+§4.2 화면 본문 모든 초안 확정. 현재 묶음 파생 없음.
 
-**비종결 시**: 종결 출력 없이 다음 초안 사이클로 계속 진행.
+다음 분석 명세 단위를 고르는 단계 (현재 묶음 외 독립 작업):
+
+옵션 1. §2.2 본문 — 다음 업무 프로세스 분석
+옵션 2. §7.2 신규 — 이번 작업 곁가지로 도출된 공통 규격
+
+추천: 1 — 분석 명세를 먼저 마치고 설계로 내려가는 큰 순서에 부합.
+```
 
 ## spec.md 형식
 
@@ -223,7 +228,7 @@ spec.md 의 § 별 섹션 이름과 분류:
 | §3  | 기타 요구사항    | 분석 분할/명세               |
 | §4  | 화면             | 설계 분할/명세               |
 | §5  | 자동 처리        | 설계 분할/명세               |
-| §6  | 횡단 처리        | 설계 분할/명세               |
+| §6  | 공통·기반 기능   | 설계 분할/명세               |
 | §7  | 공통 정의        | 자연 도출 (다른 섹션 반영거리) |
 | §8  | 도메인 모델      | 자연 도출 (다른 섹션 반영거리) |
 | §9  | 외부 인터페이스  | 자연 도출 (다른 섹션 반영거리) |
@@ -263,7 +268,7 @@ spec.md 의 § 별 섹션 이름과 분류:
 예:
 - `[모델.재고]`·`[모델.박스.수량]`·`[모델.박스.품목.코드]`.
 - `[화면.재고 확인]`·`[프로세스.입고]`·`[기타.과거 재고 조회]`.
-- `[자동 처리.재고 스냅샷]`·`[횡단 처리.DataLog 기록]`·`[외부인터페이스.ERP 입고 통보]`·`[공통 정의.Location 라벨]`.
+- `[자동 처리.재고 스냅샷]`·`[기반.DataLog 기록]`·`[외부인터페이스.ERP 입고 통보]`·`[공통 정의.Location 라벨]`.
 
 **관련 섹션 한 줄**: §2~§9 본문에 `관련 섹션: [카테고리.이름], ...` 형식의 한 줄로 참조·의존 섹션을 콤마로 나열 (카테고리 제한 없음). **초안 단위가 아님** — 다른 sub-section 작성 시 곁가지로 자동 누적.
 
@@ -276,7 +281,7 @@ spec.md 의 § 별 섹션 이름과 분류:
 | §2 | BPMN (mermaid fence) · 흐름 설명 bullet · 관련 섹션 (한 줄)   | (없음)                                                               |
 | §4 | 헤더 인덱스 (한 줄씩) · 기능 개요 (라벨 + bullet)             | 와이어프레임 · 항목 · 동작 · 시각 규칙 · 도메인 규칙·로직 · 자유 추가 |
 | §5 | 목적 (라벨 + 한 줄) · 트리거 (라벨 + 본문) · 관련 섹션 (한 줄) | 처리 · 예외 처리 · 자유 추가                                         |
-| §6 | 목적 (라벨 + 한 줄) · 트리거 (라벨 + 본문) · 관련 섹션 (한 줄) | 처리 · 예외 처리 · 자유 추가                                         |
+| §6 | 목적 · 트리거·적용 범위 (해당) · 관련 섹션 · 참조 매뉴얼 (기본 기능) | (없음 — bespoke 만 본문 자유 서술, 필요 시 h4 자유 추가) |
 | §9 | 기본 정보 (라벨 bullet 3) · 관련 섹션 (한 줄)                 | 자료 매핑 · 예외 처리                                                |
 
 본 SKILL.md 내의 `#### BPMN`·`#### 목적` 등의 표기는 작성법 설명용 sub-section 분류 표기. 실제 spec.md 본문에서의 표기는 위 표의 룰 따름.
@@ -418,14 +423,14 @@ sub-section 헤더 레벨은 `## spec.md 형식` 의 "sub-section 헤더 레벨"
 - Cockburn 의 정의: "primary actor go away happy after having done this in a single sitting?".
 - 행위자가 1회 작업으로 끝내고 만족하여 떠나는 단일 user goal.
 - 사이클·handoff·지연이 없음.
-- 정형 분해 (화면 / 자동 처리 / 횡단 처리) 를 동반하는, 사용자의 직접 요구.
-- 시스템 전반 자동 룰 (예: "모든 데이터 수정 시 DataLog 기록") 도 §3 에 포함 — 그에 대한 설계는 §6 횡단 처리에서 수행.
+- 정형 분해 (화면 / 자동 처리 / 공통·기반 기능) 를 동반하는, 사용자의 직접 요구.
+- 시스템 전반 자동 룰 (예: "모든 데이터 수정 시 변경 이력 기록") 과 프레임워크 운영 기반 (앱 구조·접근 권한·부트스트랩 등) 도 §3 에 포함 — 그에 대한 설계는 §6 공통·기반 기능에서 수행.
 
 ### 본문 구조
 
 - 요구 의도 (한 줄 또는 한 문단).
 - 관련 섹션 한 줄 ("본문 내 참조" 절 룰 따름).
-- 구현 디테일은 §4 화면 / §5 자동 처리 / §6 횡단 처리 본문에 작성.
+- 구현 디테일은 §4 화면 / §5 자동 처리 / §6 공통·기반 기능 본문에 작성.
 
 ## §4 화면
 
@@ -460,7 +465,7 @@ sub-section 헤더 레벨은 `## spec.md 형식` 의 "sub-section 헤더 레벨"
    - §8 의 마스터 엔티티 → 마스터 화면.
    - 도메인 묶음 또는 장치별로 그룹화 → 화면 목록 표.
 2. **§5 자동 처리 도출** — §2/§3 의 시스템 백그라운드 처리 (스케줄·이벤트 트리거·외부 자료 수집·적재) 를 추출.
-3. **§6 횡단 처리 도출** — §3 의 시스템 전반 자동 룰 + §4/§5 의 부수효과 동작을 추출.
+3. **§6 공통·기반 기능 도출** — §4 화면·§5 자동 처리에 속하지 않는 모든 개발 단위를 추출: 부수효과로 발동되는 동작 + 앱 전역 정적 골격(앱 구조[메뉴·권한·모듈]·로깅·부트스트랩 초기화). §3 의 "시스템 기반" 류 요구가 주 도출원. 프레임워크 기본 기능(매뉴얼 존재)은 매뉴얼 참조로, 앱 고유 부수효과는 인라인으로 명세.
 
 각 § 헤더 분할 직후 자동 OPEN 상태가 됨 (4단계의 "보류 발생 경로" 참조).
 
@@ -591,7 +596,7 @@ list 화면과 detail 화면 모두 동일. 새 버튼은 해당 그룹의 끝
 
 스케줄러 또는 이벤트 트리거로 동작하는 시스템 백그라운드 처리. 표준 프로토콜·채널을 통한 외부 자료 수집·적재 (메일 폴링 + 첨부 적재, FTP 자료 수집 등) 도 §5 에 포함 — 시스템별 협상이 필요 없는 표준 인터페이싱은 §9 가 아님.
 
-§6 횡단 처리와의 차이: §5 = 스케줄·이벤트로 명시적인 트리거가 있음. §6 = 다른 동작의 부수효과로 트리거됨.
+§6 공통·기반 기능과의 차이: §5 = 스케줄·이벤트로 명시적인 트리거가 있음. §6 = 명시적 트리거가 없는 것 (부수효과로 발동되거나 전역에 상시 구성되는 것).
 
 ### 본문 구조
 
@@ -618,54 +623,47 @@ sub-section 헤더 레벨은 `## spec.md 형식` 의 "sub-section 헤더 레벨"
 - **양식 입출력** (예: `#### 읽기 양식`·`#### 쓰기 양식`) — §4 의 "양식 입출력" sub-section 룰과 동일. 방향은 읽기·쓰기. 일회성 양식이면 sub-section 안에서 직접 명세.
 - **기타 자동 처리 고유 정보** — sub-section 이름은 자유.
 
-## §6 횡단 처리
+## §6 공통·기반 기능
+
+화면(§4)도 명시적 트리거 자동 처리(§5)도 아닌, 시스템을 떠받치는 공통·기반 개발 단위 전부 (캐치올). §4·§5 에 속하지 않는 개발 entry 는 전부 여기로 모임 — 갈 곳 없는 항목을 §7(공통 정의) 등 명세 섹션으로 올리지 말 것.
+
+포괄 대상 (두 성격이 한 섹션에 섞임. 항목을 어느 한쪽으로 미리 분류하지 않음 — 애매하거나 두 성격을 겸하는 항목도 그대로 수용):
+- 부수효과로 발동되는 동작 — DataLog 기록·권한 체크·캐시 무효화·알림 발송·감사 로그.
+- 전역에 상시 구성되는 정적 골격 — 앱 구조(메뉴·권한·모듈)·로깅 정책·부트스트랩 초기화.
 
 **초안 단위**: §6.x 1개당 위→아래 순서로 1건씩:
-1. 목적 / 트리거 (부수효과 발동 조건) (한 묶음).
-2. 처리.
-3. 예외 처리.
-4. 자유 추가 sub-section (해당 시) — sub-section 별 1건 (예: 양식 매핑·모델 매핑 각각 별건). 복잡 양식 내부의 sub-단위는 sub-단위별 1건.
+1. 목적 / 트리거·적용 범위 (한 묶음).
+2. 참조 매뉴얼 (프레임워크 기본 기능) 또는 본문 자유 서술 (bespoke) — 1건.
+3. 자유 추가 sub-section (bespoke 가 실제로 요구할 때만) — sub-section 별 1건.
 
-**모범**: example-spec.md §6.1.
+**모범**: example-spec.md §6.1·§6.2.
 
 ### 정의
 
-다른 동작의 부수효과로 발동되는 시스템 동작. §3 기타 요구사항의 시스템 전반 자동 룰을 설계 차원에서 풀이.
-
-예시:
-- DataLog 기록 — 데이터 변경의 부수효과.
-- 권한 체크 — 요청의 부수효과.
-- 캐시 무효화 — 변경의 부수효과.
-- 알림 발송 — 이벤트의 부수효과.
-- 감사 로그 — 동작의 부수효과.
+§4 화면·§5 자동 처리에 속하지 않는 모든 개발 단위. §3 기타 요구사항의 시스템 전반 자동 룰을 설계 차원에서 풀이하는 것도 포함. 부수효과로 발동되는 동작과 전역 상시 골격을 모두 포괄하되, 두 성격이 한 항목에 섞일 수 있으므로 미리 가르지 않음.
 
-§5 자동 처리와의 차이: §5 = 스케줄·이벤트로 명시적 트리거 (예: 매일 자정·메일 도착). §6 = 다른 동작의 부수효과로 트리거 (예: 모든 엔티티 update 시).
+§5 자동 처리와의 차이: §5 = 스케줄·이벤트로 명시적 트리거 (예: 매일 자정·메일 도착). §6 = 명시적 트리거가 없는 것 — 부수효과로 발동되거나 전역에 상시 존재.
 
 ### 본문 구조
 
-sub-section 헤더 레벨은 `## spec.md 형식` 의 "sub-section 헤더 레벨" 표 참조.
+§6 은 항목 성격이 제각각인 캐치올이라 §4/§5 같은 고정 sub-section 구조가 없음. 항목은 두 갈래로 작성:
 
-**평문 sub-section** (§6.x 헤더 바로 아래에 "라벨 + 본문" 형식으로 작성):
+- **프레임워크 기본 기능** (앱 구조·로깅·부트스트랩·데이터 변경 이력 등 — 매뉴얼이 존재) → 매뉴얼 참조 stub. 평문 라벨 + `참조 매뉴얼:` 한 줄. 처리·구성·예외 detail 은 매뉴얼로 위임하고 spec 에 적지 않음.
+- **bespoke** (앱 고유 부수효과 — 매뉴얼 없음) → 평문 라벨 + 본문 한두 줄 자유 서술.
 
-- `목적:` 부수효과의 도메인 목적.
-- `트리거:` 어떤 동작의 부수로 발동되는지 + 적용 범위 (예: "모든 엔티티 update 시 / 전체", "특정 도메인 X 변경 시 / 특정 엔티티", "API 요청 시 / 전체").
-- `관련 섹션:` "본문 내 참조" 절 룰 따름.
-
-**h4 sub-section** (평문 아래에 고정 순서로 위→아래 작성):
-
-#### 처리
-
-처리 단계 작성.
+sub-section 헤더 레벨은 `## spec.md 형식` 의 "sub-section 헤더 레벨" 표 참조.
 
-#### 예외 처리
+**평문 sub-section** (§6.x 헤더 바로 아래에 "라벨 + 본문" 형식, 위→아래):
 
-실패 케이스별 위험·대처·재시도 한계 작성.
+- `목적:` 도메인 목적 (필수).
+- `트리거·적용 범위:` (해당 시) 어떤 동작의 부수로 발동되는지 / 어디에 상시 적용되는지 + 적용 시점. (예: "모든 엔티티 update 시 / 전체", "앱 부팅 시 / 전체 클라이언트").
+- `관련 섹션:` "본문 내 참조" 절 룰 따름.
+- `참조 매뉴얼:` (프레임워크 기본 기능인 경우) 구현 매뉴얼 파일명 (`.claude/references/sd-simplysm14/manuals/` 기준). 이 줄이 있으면 처리·구성·예외 detail 은 적지 않음.
 
-**자유 추가 sub-section** (`#### 예외 처리` 아래에, §6.x 별로 필요 시 h4 자유 추가):
+**본문** (bespoke 항목만, 평문 아래에 작성):
 
-- **양식 입출력** (§5 의 "양식 입출력" sub-section 룰과 동일).
-- **모델 매핑** (예: `#### 모델 매핑`) — 이 횡단 처리가 사용·갱신하는 도메인 모델 매핑. 표 컬럼은 `필드 ([모델.X.Y])` + `용도` + `변환·규칙 (해당 시)`.
-- **기타 횡단 처리 고유 정보** — sub-section 이름은 자유.
+- 설계 내용을 한두 줄로 자유 서술 — 설계 고도까지만 (구현 디테일은 sd-impl).
+- 처리 절차·모델 매핑·예외 처리 같은 고정 sub-section 은 두지 않음. 양식·매핑 등 정말 필요한 정보만 h4 자유 추가 (이름 자유).
 
 ## §7 공통 정의
 
@@ -837,7 +835,7 @@ sub-section 헤더 레벨은 `## spec.md 형식` 의 "sub-section 헤더 레벨"
 
 ## 5. 자동 처리
 
-## 6. 횡단 처리
+## 6. 공통·기반 기능
 
 ## 7. 공통 정의
 

package/claude/skills/sd-spec/evals/fixtures/case-a-split//355/232/214/354/235/230/353/241/235.md

@@ -0,0 +1,20 @@
+# 재고관리 시스템 구축 킥오프 회의록
+
+일시: 2026-05-30
+참석: 물류팀장, 창고 담당자, 전산팀
+
+## 논의 내용
+
+- 창고에 박스 단위로 물건이 들어온다. 박스에는 이미 바코드(품목코드 + 수량 + 박스번호 합성)가 붙어 도착한다.
+- 입고 시 창고 작업자가 PDA 로 박스 바코드를 스캔하면 시스템에 입고가 등록된다.
+- 입고된 박스는 창고 내 Location(적치 위치)에 놓이고, 어느 Location 에 두었는지 기록해야 한다.
+- 출고 요청이 들어오면 해당 품목의 박스를 빼서 출고 처리한다. 출고가 끝나면 ERP 로 출고 통보를 보낸다.
+- 품목 마스터(품목코드·품목명·규격)와 Location 마스터(위치코드·구역)를 관리하는 화면이 필요하다.
+- 재고 현황을 품목별로 조회하고 싶다. 어느 Location 에 얼마나 있는지 보여야 한다.
+- 모든 마스터 데이터 변경은 이력을 남겨야 한다 (누가 언제 무엇을 바꿨는지). 감사 목적이다.
+- 매일 자정에 재고 스냅샷을 떠서 일별 재고 추이를 보고 싶다.
+
+## 결정 사항
+
+- 1차 범위: 입고, 출고, 품목·Location 마스터, 재고 조회.
+- PDA 는 입고 스캔용, PC 는 마스터 관리·조회용.

package/claude/skills/sd-spec/evals/fixtures/case-b-detail/.specs/260513120000_warehouse/spec.md

@@ -0,0 +1,95 @@
+# 재고관리 요구 분석서
+
+## 1. 개요
+
+### 1.1 핵심 목적 [확정: 2026-05-20]
+
+박스 단위 입고와 품목별 재고 관리
+
+### 1.2 주요 목표 [확정: 2026-05-20]
+
+- 창고 작업자가 박스를 입고 등록한다
+- 운영자가 품목 마스터를 관리한다
+
+### 1.3 최종 사용자/이해관계자 [확정: 2026-05-20]
+
+- 창고 작업자
+- 시스템 운영자
+
+### 1.4 환경/장치 [확정: 2026-05-20]
+
+#### 구성도
+
+```
+┌──────────────┐    ┌──────────────┐
+│ PC 클라이언트 │───→│     서버      │
+└──────────────┘    └──────────────┘
+```
+
+#### 장치 목록
+
+- PC: Chrome 최신
+- 서버: Node 20
+
+## 2. 업무 프로세스
+
+### 2.1 박스 입고 [확정: 2026-05-20]
+
+```mermaid
+flowchart TD
+  E1([구매처 박스 도착]) --> T1[창고 작업자: PDA 박스 바코드 스캔]
+  T1 --> T2[시스템: 박스 입고 등록]
+  T2 --> T3[창고 작업자: Location 적치]
+```
+
+- 박스에는 품목코드·수량·박스번호 합성 바코드가 부착되어 도착
+- 스캔 시 박스 정보가 시스템에 등록됨
+
+관련 섹션: [화면.품목 관리], [모델.품목]
+
+## 3. 기타 요구사항
+
+### 3.1 품목 마스터 관리 [확정: 2026-05-20]
+
+운영자가 품목 코드·품목명·규격을 등록·수정한다.
+
+관련 섹션: [화면.품목 관리], [모델.품목]
+
+## 4. 화면
+
+| §   | 분류     | 화면      | 유형   | 장치 |
+| --- | -------- | --------- | ------ | ---- |
+| 4.1 | 기준정보 | 품목 관리 | 마스터 | PC   |
+
+### 4.1 품목 관리 (PC) [OPEN: 2026-05-20]
+
+분석 방법: §3.1 품목 마스터 관리 본문 + [모델.품목] 필드 기반으로 마스터 화면(목록 시트 + 등록·편집)을 명세. 마스터 화면 표준(ID 편집 버튼·선택 체크박스·시트 상단 버튼바) 적용.
+
+## 5. 자동 처리
+
+## 6. 공통·기반 기능
+
+## 7. 공통 정의
+
+## 8. 도메인 모델
+
+### 8.1 품목 [확정: 2026-05-20]
+
+필드:
+
+| 필드     | 타입   | 필수 | 비고                   |
+| -------- | ------ | ---- | ---------------------- |
+| ID       | 숫자   | Y    | 자동 부여              |
+| 품목코드 | 문자열 | Y    | 비즈니스 키. 영문·숫자 |
+| 품목명   | 문자열 | Y    |                        |
+| 규격     | 문자열 | N    | 예: 100ml              |
+| 활성여부 | 불리언 | Y    | 소프트 삭제 플래그     |
+
+키/제약:
+
+- 식별 키: ID
+- 비즈니스 키: 품목코드
+
+## 9. 외부 인터페이스
+
+## 10. 본문 외 확정 사항

package/claude/skills/sd-spec/evals/golden.jsonl

@@ -0,0 +1,2 @@
+{"id": "case-a-split", "input": "/sd-spec 회의록.md 로 요구사항 분석 시작해줘. eval 단축 모드: 분석 분할 1사이클만(§2/§3 헤더 생성까지) 후 종료.", "rubric": ["워크스페이스에 .specs/ 하위 경로로 spec.md 파일이 1개 이상 생성되었는가", "생성된 spec.md 에 §1~§10 골격 섹션 헤더가 모두 생성되었는가", "spec.md 본문에 [OPEN: 날짜] 형식의 헤더 마커가 1개 이상 존재하는가", "assistant 응답에 업무 프로세스·기타 요구사항 등으로 분류된 항목 목록이 출력되었는가"], "fixture": "case-a-split"}
+{"id": "case-b-detail", "input": "/sd-spec .specs/260513120000_warehouse/spec.md 4.1. eval 단축 모드: 기능 개요·와이어프레임·항목 1건까지만 작성 후 종료.", "rubric": ["워크스페이스 spec.md 의 §4.1 본문에 기능 개요가 작성되었는가", "워크스페이스 spec.md 의 §4.1 본문에 와이어프레임(ASCII 영역 구획 또는 영역 라벨 표기)이 작성되었는가", "워크스페이스 spec.md 의 §4.1 본문에 항목을 정의하는 마크다운 표가 1개 이상 생성되었는가"], "fixture": "case-b-detail"}

package/claude/skills/sd-spec/references/example-spec.md

@@ -85,11 +85,11 @@ flowchart LR
 
 관련 섹션: [화면.재고 확인], [자동 처리.재고 스냅샷]
 
-### 3.2 마스터 데이터 변경 이력 [확정: 2026-04-01]
+### 3.2 시스템 기반 [확정: 2026-04-01]
 
-모든 마스터 데이터의 변경 (등록·편집·활성/비활성 전환) 이력을 자동으로 기록해야 함. 목적은 변경 추적·감사.
+앱 운영을 떠받치는 기반 구조 — 메뉴 트리·화면 접근 권한·기능 모듈 구성 — 를 한 곳에서 정의·관리할 수 있어야 함.
 
-관련 섹션: [횡단 처리.마스터 데이터 변경 이력]
+관련 섹션: [기반.앱 구조 정의]
 
 ## 4. 화면
 
@@ -409,41 +409,27 @@ Actor: 창고 관리자
   - 대처: 관리자에게 알림 발송. 동일 일자에 재실행할 경우 (날짜, 박스) 유일성 제약으로 중복 생성을 방지
   - 재시도 한계: 자동 재시도 없음 (다음 날 0시에 정상 동작)
 
-## 6. 횡단 처리
+## 6. 공통·기반 기능
 
-### 6.1 마스터 데이터 변경 이력 [확정: 2026-04-01]
+### 6.1 앱 구조 정의 [확정: 2026-04-01]
 
-목적: 마스터 데이터 변경의 추적·감사 (누가, 언제, 무엇을, 어떻게 바꿨는지 기록)
+목적: 앱의 메뉴 트리·화면 접근 권한·기능 모듈 구성을 한 곳에서 정의
 
-트리거 (부수효과 발동 조건):
-- 마스터 엔티티의 insert·update·delete 트랜잭션 commit 시점
-- 적용 대상 모델: [모델.품목], [모델.Location]
-- 적용 제외 모델 (트랜잭션 모델): [모델.재고], [모델.재고 스냅샷]
+트리거·적용 범위: 앱 부팅 시 / admin·PDA 클라이언트별 (클라이언트마다 자기 메뉴 배열을 정의)
 
-관련 섹션: [기타.마스터 데이터 변경 이력], [모델.품목], [모델.Location], [모델.DataLog]
+관련 섹션: [기타.시스템 기반], [화면.품목 관리], [화면.Location 관리], [화면.입고 스캔], [화면.재고 확인]
 
-#### 처리
+참조 매뉴얼: client-app-structure.md
 
-- 변경 전 값과 변경 후 값을 캡처 (insert 시 변경 전 = null, delete 시 변경 후 = null)
-- [모델.DataLog] 에 1행 적재 (테이블명·키·변경 전·변경 후·작업자·시각)
+### 6.2 마스터 변경 시 캐시 무효화 [확정: 2026-04-01]
 
-#### 예외 처리
+목적: 마스터 변경이 전 클라이언트 조회에 지체 없이 반영되도록 보장
 
-- DataLog 적재 실패 시:
-  - 위험: 변경 이력 추적 누락
-  - 대처: 원본 마스터 트랜잭션은 정상 commit 유지하고, DataLog 적재 실패만 별도 큐에 적재한 뒤 관리자에게 알림
-  - 재시도 한계: 큐에서 지수 백오프로 5회까지 재시도 후 운영팀에 알림
+트리거·적용 범위: [모델.품목]·[모델.Location] 의 insert·update·delete commit 시점 (부수효과) / 전체 클라이언트
 
-#### 모델 매핑
+관련 섹션: [프로세스.입고], [모델.품목], [모델.Location]
 
-| 필드 ([모델.DataLog]) | 용도                            |
-| --------------------- | ------------------------------- |
-| [모델.DataLog.테이블명] | 변경 대상 모델명 (예: `품목`) |
-| [모델.DataLog.키]       | 변경 대상 ID                  |
-| [모델.DataLog.변경 전]  | 컬럼별 변경 전 값 (JSON)      |
-| [모델.DataLog.변경 후]  | 컬럼별 변경 후 값 (JSON)      |
-| [모델.DataLog.작업자]   | 세션 사용자                   |
-| [모델.DataLog.시각]     | 변경 commit 시각              |
+해당 마스터의 공유 캐시를 무효화하여 클라이언트가 다음 조회 시 최신 데이터를 재적재하도록 함.
 
 ## 7. 공통 정의
 
@@ -571,25 +557,6 @@ Actor: 창고 관리자
 - 식별 키: ID (자동 부여)
 - 비즈니스 키: (날짜, 박스) 조합이 유일
 
-### 8.6 DataLog [확정: 2026-04-01]
-
-필드:
-
-| 필드     | 타입 | 필수 | 비고                                  |
-| -------- | ---- | ---- | ------------------------------------- |
-| ID       | 숫자 | O    | 자동 부여                             |
-| 테이블명 | 문자 | O    | 변경 대상 모델명 (예: `품목`)         |
-| 키       | 숫자 | O    | 변경 대상 ID                          |
-| 변경 전  | JSON | X    | 컬럼별 이전 값. insert 시 null        |
-| 변경 후  | JSON | X    | 컬럼별 변경 후 값. delete 시 null     |
-| 작업자   | 문자 | O    | 세션 사용자                           |
-| 시각     | 일시 | O    | 변경 commit 시각                      |
-
-키/제약:
-
-- 식별 키: ID (자동 부여)
-- 인덱스: (테이블명, 키, 시각) — 특정 엔티티의 변경 이력 조회 용도
-
 ## 9. 외부 인터페이스
 
 ### 9.1 ERP 입고 통보 [확정: 2026-04-01]

package/package.json

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