@simplysm/sd-claude 14.0.84 → 14.0.86

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

@@ -1,4 +1,4 @@
 {"id": "case-a-new-screen", "input": ".specs/260513120000_warehouse/spec.md §4.1 화면 풀 구현해줘. eval 환경 단축 모드: 단위 테스트 핵심 1건만, 6단계 subagent 대조·7단계 코드 정리·REFACTOR·dev 시연 스킵.", "rubric": ["fixture 의 spec.md 파일이 워크스페이스에 보존되었는가", "워크스페이스 spec.md 의 §4.1 헤더에 [확정: YYYY-MM-DD, 구현: YYYY-MM-DD] 형식 마커가 부착되었는가", "워크스페이스에 §4.1 화면 본체에 해당하는 코드 파일이 1개 이상 생성되었는가 (예: 박스 등록 화면 컴포넌트)", "assistant 응답에 spec 분해 표가 마크다운 표 형식(파이프 구분, 헤더 행 포함)으로 출력되었는가"], "fixture": "case-a-new-screen"}
 {"id": "case-b-update-with-demo", "input": ".specs/260513120000_warehouse/spec.md §4.1 데모를 실 구현으로 전환해줘. eval 환경 단축 모드: 단위 테스트 핵심 1건만, 6단계 subagent 대조·7단계 코드 정리·REFACTOR·dev 시연 스킵.", "rubric": ["fixture 의 데모 골격 파일(packages/app/src/screens/box-register/box-register.view.ts)이 워크스페이스에 보존되었는가 (삭제되지 않았는가)", "워크스페이스 spec.md 의 §4.1 헤더에 [확정: YYYY-MM-DD, 구현: YYYY-MM-DD] 형식 마커가 부착되었는가", "워크스페이스에 데모 골격 외의 코드 파일(데이터 접근 또는 단위 테스트 계층)이 1개 이상 추가되었는가", "assistant 응답에 spec 분해 표가 마크다운 표 형식(파이프 구분, 헤더 행 포함)으로 출력되었는가"], "fixture": "case-b-update-with-demo"}
-{"id": "case-c-new-cross", "input": ".specs/260513120000_warehouse/spec.md §6.1 횡단 처리 풀 구현해줘. eval 환경 단축 모드: 단위 테스트 핵심 1건만, 6단계 subagent 대조·7단계 코드 정리·REFACTOR·dev 시연 스킵.", "rubric": ["워크스페이스에 §6.1 횡단 처리 본체(부수효과 후크 또는 처리 로직)에 해당하는 코드 파일이 1개 이상 생성되었는가", "워크스페이스 spec.md 의 §6.1 헤더에 [확정: YYYY-MM-DD, 구현: YYYY-MM-DD] 형식 마커가 부착되었는가", "assistant 응답에 spec 분해 표가 마크다운 표 형식(파이프 구분, 헤더 행 포함)으로 출력되었는가"], "fixture": "case-c-new-cross"}
+{"id": "case-c-new-cross", "input": ".specs/260513120000_warehouse/spec.md §6.1 공통·기반 기능 풀 구현해줘. eval 환경 단축 모드: 단위 테스트 핵심 1건만, 6단계 subagent 대조·7단계 코드 정리·REFACTOR·dev 시연 스킵.", "rubric": ["워크스페이스에 §6.1 공통·기반 기능 본체(부수효과 후크 또는 처리 로직)에 해당하는 코드 파일이 1개 이상 생성되었는가", "워크스페이스 spec.md 의 §6.1 헤더에 [확정: YYYY-MM-DD, 구현: YYYY-MM-DD] 형식 마커가 부착되었는가", "assistant 응답에 spec 분해 표가 마크다운 표 형식(파이프 구분, 헤더 행 포함)으로 출력되었는가"], "fixture": "case-c-new-cross"}
 {"id": "case-d-spec-modify", "input": ".specs/260513120000_warehouse/spec.md §4.1 화면 풀 구현해줘. §8.1 의 인라인 [OPEN] 마커는 만나는 즉시 결정해서 spec.md 를 직접 수정하고 진행해줘. eval 환경 단축 모드: 단위 테스트 핵심 1건만, 6단계 subagent 대조·7단계 코드 정리·REFACTOR·dev 시연 스킵.", "rubric": ["fixture spec.md 안의 인라인 [OPEN] 마커가 워크스페이스 spec.md 의 §8.1 본문에서 제거 또는 결정 내용으로 치환되었는가 ('[OPEN]' 문자열이 §8.1 본문에 더 이상 존재하지 않는가)", "워크스페이스 spec.md 의 §4.1 헤더에 [확정: YYYY-MM-DD, 구현: YYYY-MM-DD] 형식 마커가 부착되었는가", "events 에 sd-spec 룰 자료(.claude/skills/sd-spec/SKILL.md 또는 동등 자료) 읽기 흔적(Read·Bash cat 등 동등 명령)이 1회 이상 있는가", "워크스페이스에 §4.1 화면 본체에 해당하는 코드 파일이 1개 이상 생성되었는가"], "fixture": "case-d-spec-modify"}

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

@@ -0,0 +1,51 @@
+---
+name: sd-manual
+description: `.claude/references/sd-simplysm14/manuals/` 에 주제 단위 목적 기반 개발 매뉴얼(how-to)을 작성·갱신. Use when 라이브러리·프레임워크 사용법을 "~하려면 ~한다" 식 매뉴얼로 새로 쓰거나 코드 변경을 반영해 갱신할 때.
+---
+
+# sd-manual
+
+독자(주로 코드 작업 중인 에이전트)가 어떤 작업을 하려 할 때 그 작업을 올바르게 수행하는 방법을 빠르게 얻도록, 주제 단위 목적 기반 매뉴얼을 작성·갱신.
+
+좋은 매뉴얼의 두 본질 축:
+
+- **축1 — 작업 목적 단위로 조직**: 독자는 "내가 무엇을 하려는지" 로 찾음. 매뉴얼은 "~하려면 ~한다" 구성이어야 하며, 구현 내부 동작을 설명 단위로 삼지 않음.
+- **축2 — 방법이 실제 동작과 일치**: 적은 방법이 코드의 실제 결과와 맞아야 함. 검증 기준은 **독자가 관찰하는 최종 결과**(화면·실제 동작)이며, 함수 내부 반환값이 아님.
+
+## 산출물
+
+- `.claude/references/sd-simplysm14/manuals/<주제>.md` — 매뉴얼 본문.
+- `.claude/references/sd-simplysm14/README.md` 의 매뉴얼 인덱스 표 — 트리거 + 링크 1행.
+
+## 워크플로
+
+### 1. 대상·범위 확정
+
+- 매뉴얼 주제와 대상 코드 범위 파악.
+- 신규 작성인지, 기존 매뉴얼 갱신인지 판별. 갱신이면 기존 파일을 먼저 읽어 현재 구조를 파악.
+- 독자가 이 매뉴얼로 하려는 **작업들**(use case)을 식별.
+
+### 2. 작업 목적 분해 → 목차
+
+- 1단계에서 식별한 작업들을 목차로 변환. 각 섹션 = 하나의 작업 목적("~하려면 ~한다").
+- 함수·옵션을 나열하는 레퍼런스 구조나, 내부 동작을 설명하는 구조로 만들지 않음(축1).
+
+### 3. 수행법 조사 + 결과 추적
+
+- 각 작업의 수행법을 대상 코드를 직접 읽어 근거 위에 확정.
+- 그 방법이 독자가 관찰하는 **최종 결과**(화면·실제 동작)로 이어지는지 끝까지 추적해 확인. 함수 반환값만 보고 결과를 단정하지 않음(축2).
+- 갱신이면 코드 변경분이 어떤 작업 목적에 해당하는지 짚어 반영 위치를 정함.
+
+### 4. 작성 + 인덱스 등재
+
+- 기존 `manuals/*.md` 의 톤·구조를 답습: 목적 설명 → 작성법 + 코드 예시 → 지킬 것.
+- 신규: README 매뉴얼 인덱스 표에 트리거 + 링크 1행 추가.
+- 갱신: 기존 매뉴얼 파일과 인덱스 행을 보존한 채 변경분만 반영. 합의 없이 무관한 부분을 고치지 않음.
+
+### 5. 자가 검증 게이트
+
+출력 전 자문:
+
+- 각 섹션이 작업 목적("~하려면") 단위인가, 구현 동작 설명이 아닌가?
+- 각 서술이 독자가 관찰하는 최종 결과와 일치하는가(함수 반환값이 아니라)?
+- 기존 매뉴얼의 톤·구조와 일관되는가?

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

@@ -11,9 +11,9 @@ description: 산출물(코드·문서 등) 을 적용 룰 기준으로 검증해
 
 2. **작업 도메인 명시** — 대상이 어떤 도메인의 산출물인가 식별 (예: LLM 문서 / 사람 문서 / UI / 코드).
 
-3. **적용 룰 인용** — 도메인의 적용 룰 인용 (sd-base-rules·sd-design-rules·스킬·도메인별 룰 등). 룰 항목 직접 표기.
+3. **적용 룰 인용** — 도메인의 적용 룰 인용 (행동 규칙·sd-design-rules·스킬·도메인별 룰 등). 룰 항목 직접 표기.
 
-4. **룰 부합 검증** — 대상이 인용 룰에 부합하는가 점검. 위반 항목 식별.
+4. **룰 부합 전수 검증** — 인용한 모든 룰 항목을 대상의 모든 단위(코드: 함수·라인 / 문서: 섹션·문장)에 대해 빠짐없이 대조. 표본·대표 패턴만 검사하거나 일부 단위만 보고 조기 종료하는 것 금지.
 
 5. **발견 사항 분류** — 각 항목을 다음 기준으로 분류:
 
@@ -30,4 +30,4 @@ description: 산출물(코드·문서 등) 을 적용 룰 기준으로 검증해
    - `[자동]` 판정 항목: `[자동]` 마커 표기 (변경 완료).
    - 결정 대상 항목: 마커 없음.
 
-8. **결정 진행 모드 전환** — 결정 대상이 1건 이상이면 `sd-base-rules.md` 의 "사용자 질의 시" 섹션이 정의한 결정 진행 모드로 전환 (사용자 트리거 대기 금지). 0건이면 종료.
+8. **결정 진행 모드 전환** — 결정 대상이 1건 이상이면 행동 규칙의 "사용자 질의 시" 섹션이 정의한 결정 진행 모드로 전환 (사용자 트리거 대기 금지). 0건이면 종료.

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

@@ -240,6 +240,6 @@ stdout 으로 summary JSON 출력. 포함 필드는 다음과 같음.
 
 ### 리뷰
 
-전 케이스 PASS 후 sd-review 호출. 적용 룰: sd-base-rules 와 3단계의 "본문 작성 원칙"·"파일 분리 기준".
+전 케이스 PASS 후 sd-review 호출. 적용 룰: 행동 규칙과 3단계의 "본문 작성 원칙"·"파일 분리 기준".
 
 리뷰 결과로 수정 발생 시 4단계 재실행.

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 매핑·절차 위치·다음 단계:
@@ -73,16 +72,16 @@ spec.md 첨부 재진입 시 상황별 권장 진입점:
 
 #### 초안 단위
 
-sd-base-rules 의 "묶음 채택 금지" 적용 — 사용자가 한 번에 yes/no 로 답할 수 있는 최소 단위. 응답 1건에 선택지 세트 1개. §별 작성법 첫머리에 단위 명시.
+행동 규칙 "묶음 채택 금지" 적용 — 사용자가 한 번에 yes/no 로 답할 수 있는 최소 단위. 응답 1건에 선택지 세트 1개. §별 작성법 첫머리에 단위 명시.
 
 #### 스스로 검증 게이트
 
-초안 출력 직전마다 자문. 한 가지라도 실패 시 초안 폐기 후 재작성 또는 사용자에게 질문. sd-base-rules "응답 전송 직전 자가 점검" 에 더해 적용되는 sd-spec 고유 검증.
+초안 출력 직전마다 자문. 한 가지라도 실패 시 초안 폐기 후 재작성 또는 사용자에게 질문. 행동 규칙 "응답 전송 직전 자가 점검" 에 더해 적용되는 sd-spec 고유 검증.
 
 1. **형식** — 해당 § 작성법 규약을 따랐는지 (해당 § 작성법 절을 재독한 후 헤더 구조·표 형식·마커 표기 점검).
 2. **출처** — 각 항목·필드·동작 1건마다 사용자 발언·자료를 인용할 수 있는지.
    - 인용 불가 = As-Is 답습 / 다른 §·example 패턴 복제 의심 → 제거 또는 별도 질문.
-   - As-Is (회의록·매뉴얼·현행 화면) 는 추정 자료 (sd-base-rules "결정 근거 안티패턴").
+   - As-Is (회의록·매뉴얼·현행 화면) 는 추정 자료 (행동 규칙 "결정 근거 안티패턴").
    - 다른 §·example 에서는 **형식만** 가져오고, **내용물** (항목·컬럼·필드·액션·동작) 은 본 §의 §2.x/§3.x 본문·사용자 발언에서 직접 도출.
 3. **단순화 차단** — spec 명시 정의·식·분기·경계에 대해 초안에서 자체 단순화·근사화·안전 처리 (NULL 강제·0 클램프·방어 가드·분기 생략) 를 임의로 추가하지 않았는지.
    - 식은 그대로 풀어쓸 것.
@@ -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  | 외부 인터페이스  | 자연 도출 (다른 섹션 반영거리) |
@@ -252,7 +257,7 @@ spec.md 의 § 별 섹션 이름과 분류:
 | `[OPEN]` | 정보 부족·근거 없는 항목. 향후 확정 필요. |
 
 - 임의로 채우거나 누락하지 말고 `[OPEN]` 으로 표기.
-- 근거 부족 판정 기준은 sd-base-rules 의 "결정 근거" 적용. As-Is 만 근거인 항목·답변 범위 흡수 등 안티패턴 자료는 근거 없음으로 보고 `[OPEN]` 으로 표기.
+- 근거 부족 판정 기준은 행동 규칙의 "결정 근거" 적용. As-Is 만 근거인 항목·답변 범위 흡수 등 안티패턴 자료는 근거 없음으로 보고 `[OPEN]` 으로 표기.
 - 헤더 `[확정]` + 본문 `[OPEN]` 조합은 OPEN 을 인정한 상태로 섹션을 확정. 이후에는 OPEN 항목만 처리.
 - 사용자에게 물을 때 선택지: `맞나요? [OPEN 상태로 확정 / 섹션 전체 보류 / OPEN 하나씩 해결]`.
 
@@ -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"}