@simplysm/sd-claude 14.0.65 → 14.0.66

package/claude/skills/sd-plan/evals/fixtures/demo-built/src/pages/CustomerList.tsx

@@ -1,25 +0,0 @@
-// demo가 만든 UI scaffold (mock data 사용, 기능 미구현)
-import React, { useState } from 'react'
-import { Input, Table, Pagination } from '../components/Input'
-import { MOCK_CUSTOMER_LIST } from '../data/mock-customer'
-
-export const CustomerList: React.FC = () => {
-  const [search, setSearch] = useState('')
-  const [page, setPage] = useState(1)
-
-  const columns = [
-    { key: 'name', label: '이름' },
-    { key: 'bizNumber', label: '사업자번호' },
-    { key: 'manager', label: '담당자' },
-    { key: 'phone', label: '연락처' },
-  ]
-
-  // NOTE: mock 데이터 그대로 표시. 실제 검색/페이지네이션 로직 없음 (demo 단계)
-  return (
-    <div>
-      <Input value={search} onChange={setSearch} placeholder="거래처명 검색" />
-      <Table rows={MOCK_CUSTOMER_LIST} columns={columns} />
-      <Pagination page={page} total={2} onChange={setPage} />
-    </div>
-  )
-}

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

@@ -1,3 +0,0 @@
-{"id": "basic-greenfield-001", "input": "/sd-plan REQ-001 계획 짜줘", "rubric": [".specs/260503143025/REQ-001-입고지시서긴급표시/plan.md 파일이 생성되었는가?", "plan.md 본문에 '## 메타', '## R 단위 계획', '## 작업 순서' 3개 섹션 헤더가 모두 포함되어 있는가?", "plan.md 본문 메타에 '결과: proceed' 또는 '결과:proceed' 표기가 포함되어 있는가? (모든 R 미구현 케이스)", "plan.md 본문에 '미구현' 키워드가 1회 이상 포함되어 있는가? (현황 분류)", "plan.md 본문에 '- [ ] R' 패턴(R 항목) 1개 이상 포함되어 있는가?", "에이전트의 마지막 텍스트 응답에 'REQ-' 또는 'R1' 형태의 ID 매핑이 1개 이상 포함되어 있고, 변경 계획 요약(예: '변경'/'추가'/'수정'/'미구현'/'구현' 같은 단어)이 함께 등장하는가? (고객 친화적 보고 단계 도달 확인)"], "fixture": "basic-greenfield"}
-{"id": "demo-built-001", "input": "/sd-plan REQ-001 계획 짜줘", "rubric": [".specs/260503143025/REQ-001-거래처목록화면/plan.md 파일이 생성되었는가?", "plan.md 본문 메타에 '결과: proceed' 또는 '결과:proceed' 표기가 포함되어 있는가? (UI scaffold 있지만 기능 미구현, 변경 필요)", "plan.md 본문에 '부분' 또는 '차이있음' 키워드가 1회 이상 포함되어 있는가? (demo가 만든 scaffold가 부분 구현으로 분류)", "plan.md 본문에 'CustomerList' 또는 'mock' 키워드가 1회 이상 포함되어 있는가? (demo 결과 인지)", "plan.md 본문에 '**설계**:' 또는 '**설계**' 표기가 1회 이상 포함되어 있는가? (UI R 설계 서브섹션 작성)", "plan.md 본문에 'demo.md' 또는 'DEMO-001' 키워드가 1회 이상 포함되어 있는가? (demo 산출물 참조)", "에이전트의 마지막 텍스트 응답에 'REQ-' 또는 'R1' 형태의 ID 매핑이 1개 이상 포함되어 있고, 변경 계획 요약(예: '변경'/'추가'/'수정'/'미구현'/'구현' 같은 단어)이 함께 등장하는가? (고객 친화적 보고 단계 도달 확인)"], "fixture": "demo-built"}
-{"id": "already-implemented-001", "input": "/sd-plan REQ-001 계획 짜줘", "rubric": [".specs/260503143025/REQ-001-사용자목록/plan.md 파일이 생성되었는가?", "plan.md 본문 메타에 '결과: skip-to-verify' 또는 '결과:skip-to-verify' 표기가 포함되어 있는가? (모든 R 이미 구현됨)", "plan.md 본문에 '구현' 키워드가 1회 이상 포함되어 있는가? (현황 분류)", "에이전트의 마지막 텍스트 응답에 'REQ-' 또는 'R1' 형태의 ID 매핑이 1개 이상 포함되어 있고, 변경 계획 요약(예: '변경'/'추가'/'수정'/'미구현'/'구현' 같은 단어)이 함께 등장하는가? (고객 친화적 보고 단계 도달 확인)"], "fixture": "already-implemented"}

package/claude/skills/sd-plan/references/plan-md-template.md

@@ -1,138 +0,0 @@
-# plan.md 템플릿
-
-위치: `.specs/{yyMMdd_HHmmss}/REQ-XXX-슬러그/plan.md`
-
-## 템플릿
-
-```markdown
-# REQ-001-슬러그 / Plan
-
-## 메타
-- 상태: planning | planned
-- 생성일: YYYY-MM-DD
-- 마지막 갱신: YYYY-MM-DD
-- 결과: proceed | skip-to-verify
-
-## 결과 사유
-<proceed/skip 결정 근거 한두 줄>
-
-## R 단위 계획
-- [ ] R1: <요구 제목>
-  - **현황**: 구현 / 부분 / 미구현 / 차이있음 (사유)
-    - 근거: <항상 명시. 사용자 답변 (YYYY-MM-DD) / 코드경로:L범위 등>
-  - **설계**: (UI/API/데이터 모델/외부 연동에서 필요. 단순 변경은 생략)
-    - <자연어 우선. UI에 demo.md 있으면 "demo.md 참조" + 추가 결정 사항만>
-    - 근거: <항상 명시>
-  - **변경 위치**:
-    - `<파일경로>` - `<함수/컴포넌트명>`
-    - 근거: <항상 명시>
-  - **변경 방식**:
-    - <자연어 변경 방식>
-    - 근거: <항상 명시>
-  - **테스트**:
-    - 방식: TDD / 사후 / 생략
-    - 케이스: <시나리오>
-    - 근거: <항상 명시. 모드 결정 출처>
-  - [ ] **Q**: <확인 필요 사항> (있을 때만)
-
-- [ ] R2: ...
-
-## 작업 순서
-- **의존**:
-  - R3는 R1에 의존 (사유)
-  - R2는 독립
-- **권장 순서**: R1, R2, R3
-- **병렬 가능**: R1과 R2
-
-## 통합/E2E 테스트
-- <시나리오 1>
-- <시나리오 2>
-```
-
-## 섹션별 역할
-
-| 섹션 | 용도 |
-|---|---|
-| `## 메타` | 상태, 결과 분기 |
-| `## 결과 사유` | 분기 결정 근거 |
-| `## R 단위 계획` | R별 현황/변경/테스트 인라인 통합 |
-| `## 작업 순서` | R 간 의존성, 권장 순서, 병렬 가능 |
-| `## 통합/E2E 테스트` | R 간 흐름 검증 |
-
-## R 항목 내부 요소
-
-| 요소 | 의미 |
-|---|---|
-| **현황** | 4단계 분류 (구현/부분/미구현/차이있음) |
-| **설계** | (R 성격별 조건부) UI 레이아웃·이벤트 흐름 / API 엔드포인트·스키마 / 데이터 모델 / 외부 연동 시퀀스. 단순 변경은 생략 |
-| **변경 위치** | 파일 경로 + 함수/컴포넌트 이름 (라인 번호 X) |
-| **변경 방식** | 자연어. 복잡한 로직만 의사코드 |
-| **테스트** | 방식(TDD/사후/생략) + 케이스 |
-| **Q** | (있을 때만) 사용자 확인 필요 |
-
-각 요소(현황/설계/변경 위치/변경 방식/테스트) 아래에 들여쓴 `근거:` 줄로 출처를 항상 한 줄 명시한다.
-
-## 예시
-
-```markdown
-- [ ] R1: 입고지시서 관리 화면 — 좌우 분할, 우측 신규 등록 시 품목 선택 모달
-  - **현황**: 미구현
-    - 근거: src/pages/ 전수 grep 결과 InboundOrder 관련 파일 없음
-  - **설계**:
-    - 레이아웃: 좌측 입고지시서 목록(검색/페이징), 우측 선택 항목 상세 폼. 우상단 [+ 신규] 버튼.
-    - 이벤트 흐름:
-      - [+ 신규] 클릭 → 우측 폼 빈 상태로 초기화 → 폼 안 [품목 선택] 버튼 클릭 → 품목 선택 모달 오픈
-      - 모달에서 품목 선택 → 닫힘 → 폼의 품목 영역에 반영
-      - [저장] 클릭 → 검증 통과 시 API 호출 → 성공하면 좌측 목록에 새 항목 추가 + 우측 폼 그대로 유지(편집 모드)
-    - 상태: `selectedId | null`, `formMode = 'create' | 'edit'`, `pickerOpen`
-    - 근거: DEMO-001 demo.md 시나리오 그대로
-  - **변경 위치**:
-    - `src/pages/InboundOrder.tsx` - `InboundOrderPage` (분할 레이아웃)
-    - `src/pages/InboundOrder/PickerModal.tsx` - 신규 (품목 선택 모달)
-    - 근거: src/pages/Outbound.tsx:L10-L40 동일 좌우 분할 패턴
-  - **변경 방식**:
-    - 좌측은 기존 `InboundOrderList` 재사용, 우측은 `InboundOrderForm`을 페이지에 직접 임베드.
-    - 근거: 사용자 답변 (2026-05-04)
-  - **테스트**:
-    - 방식: 사후 테스트 (UI)
-    - 케이스: 신규 → 품목 선택 → 저장 → 좌측 목록 반영 확인
-    - 근거: UI 동작 → TDD 불가, 사후 검증 가능
-
-- [ ] R2: 입고지시서 저장 API
-  - **현황**: 미구현
-    - 근거: src/server/routes/ 에 inbound-order 라우트 파일 없음
-  - **설계**:
-    - 엔드포인트: `POST /api/inbound-orders`
-    - 요청: `{ itemId: string, quantity: number, urgent: boolean, note?: string }`
-    - 응답 200: `{ id: string, createdAt: string }`
-    - 에러: 400(검증 실패 — 필드별 메시지), 401(미인증), 409(중복 키)
-    - 권한: `inbound-order.write` 롤 필요
-    - 근거: 사용자 답변 (2026-05-04, 권한·중복 키 정책)
-  - **변경 위치**:
-    - `src/server/routes/inbound-order.ts` - `registerInboundOrderRoutes`
-    - `src/server/services/inbound-order-service.ts` - `createInboundOrder`
-    - 근거: src/server/routes/outbound.ts:L1-L30 동일 라우트·서비스 분리 패턴
-  - **변경 방식**:
-    - 라우트는 zod 스키마 검증 → 서비스 호출 → 결과 반환. 트랜잭션은 서비스 레이어.
-    - 근거: src/server/services/outbound-service.ts:L20 동일 트랜잭션 위치 패턴
-  - **테스트**:
-    - 방식: TDD
-    - 케이스: 정상 생성 / 필수 누락 400 / 권한 없음 401 / 중복 409
-    - 근거: 입력→출력 단언 가능 → TDD
-
-- [ ] R3: 긴급 표시 PDF 빨간색 강조
-  - **현황**: 부분 (PDF 출력 로직 있음, 색상 처리 없음)
-    - 근거: src/pdf/InboundOrderPdf.tsx:L40-L88 `renderHeader` 색상 분기 없음
-  - **변경 위치**:
-    - `src/pdf/InboundOrderPdf.tsx` - `renderHeader` 함수
-    - 근거: 색상 분기 들어갈 유일한 함수
-  - **변경 방식**:
-    - urgent === true 인 경우 헤더 배경색 #D32F2F 적용
-    - 근거: spec.md R2 A "PDF는 #D32F2F"
-  - **테스트**:
-    - 방식: 사후 테스트
-    - 케이스: 긴급 표시된 데이터 PDF 출력 → 빨간색 확인
-    - 근거: PDF 렌더 결과 픽셀 검증 비용 큼 → TDD 대신 사후
-```
-
-R1(UI), R2(API)는 성격에 따라 **설계** 추가, R3(단순 변경)은 생략.

package/claude/skills/sd-spec/evals/fixtures/bulk-multi-source/.docs/20260122_/352/263/240/352/260/235/354/202/254_/354/236/205/352/263/240/354/247/200/354/213/234/354/204/234/352/260/234/354/204/240/354/232/224/354/262/255.eml

@@ -1,20 +0,0 @@
-From: Ethan <ethan@example.com>
-To: 우리회사 <us@example.com>
-Date: 2026-01-22 16:31
-Subject: [ADTEK] 입고지시서 화면 개선 요청
-
-안녕하세요.
-
-입고지시서 화면을 사용하면서 몇 가지 개선이 필요한 부분이 있어 요청드립니다.
-
-1. 긴급 입고 건을 표시할 방법이 필요합니다. 현재는 전부 동일하게 보여서
-   우선순위 구분이 어렵습니다. 화면에 "긴급" 체크박스 같은 걸로 표시하고,
-   그 건들은 PDF 출력 시에도 빨간색으로 강조되었으면 합니다.
-
-2. 입고지시서 PDF 출력 시 회사 로고가 누락되는 경우가 있습니다.
-   확인 부탁드립니다.
-
-빠른 검토 부탁드립니다.
-
-감사합니다.
-Ethan

package/claude/skills/sd-spec/evals/fixtures/bulk-multi-source/.docs/20260205_/352/263/240/352/260/235/354/202/254_/354/266/234/352/263/240/355/231/224/353/251/264/352/264/200/353/240/250.eml

@@ -1,17 +0,0 @@
-From: Kaya <kaya@example.com>
-To: 우리회사 <us@example.com>
-Date: 2026-02-05 10:15
-Subject: [ADTEK] 출고관리 화면 추가 요청
-
-안녕하세요.
-
-현재 출고 처리 시 출고예정에서 출고로 바로 넘어가는 구조인데,
-실무에서는 그 사이에 "상차" 단계가 필요합니다.
-
-차량에 적재 중인 상태를 별도로 표시할 수 있어야 하고,
-상차 중에 취소되는 경우도 있어서 출고예정으로 되돌릴 수 있어야 합니다.
-
-검토 부탁드립니다.
-
-감사합니다.
-Kaya

package/claude/skills/sd-spec/evals/fixtures/bulk-multi-source/.docs/20260301_/352/263/240/352/260/235/354/202/254_/352/266/214/355/225/234/354/262/264/352/263/204.eml

@@ -1,18 +0,0 @@
-From: Ethan <ethan@example.com>
-To: 우리회사 <us@example.com>
-Date: 2026-03-01 09:42
-Subject: [ADTEK] 사용자 권한 체계 변경
-
-안녕하세요.
-
-WMS 사용자 권한 체계를 변경하려고 합니다.
-
-기존: 단일 권한 그룹 (전체 또는 무권한)
-변경: 역할별 권한 (입고담당 / 출고담당 / 관리자)
-
-각 역할별로 접근 가능한 화면과 액션이 구분되어야 합니다.
-
-세부 권한 매트릭스는 다음 회의에서 논의 예정입니다.
-
-감사합니다.
-Ethan

package/claude/skills/sd-spec/evals/fixtures/conflict-detection/.docs/20260317_/352/263/240/352/260/235/354/202/254_/352/270/264/352/270/211/354/262/230/353/246/254/353/260/251/354/271/250.eml

@@ -1,17 +0,0 @@
-From: Ethan <ethan@example.com>
-To: 우리회사 <us@example.com>
-Date: 2026-03-17 14:20
-Subject: [ADTEK] 긴급 입고 처리 방침
-
-안녕하세요.
-
-긴급 입고 처리 단위에 대해 정리하여 전달드립니다.
-
-긴급 처리는 **주문 단위**로 적용합니다.
-즉, 주문 한 건이 긴급으로 분류되면 그 주문에 포함된 모든 품목이
-긴급 처리됩니다. 일부 품목만 긴급 처리하는 경우는 없습니다.
-
-이 기준으로 시스템 반영 부탁드립니다.
-
-감사합니다.
-Ethan

package/claude/skills/sd-spec/evals/fixtures/conflict-detection/.docs//355/232/214/354/235/230/353/214/200/353/263/270_20260320.txt

@@ -1,13 +0,0 @@
-[회의 대본 — 2026-03-20]
-참석: B 차장, C 과장, D 대리 (고객사 측), 우리회사 PM
-
-...
-[14:30 경]
-B 차장: 긴급 처리 단위 다시 한번 확인하고 싶은데요. 저는 품목 단위가 맞다고 봅니다.
-C 과장: 네, 그게 현장에서 더 유용해요. 한 주문에 여러 품목이 섞여 있는데
-        일부만 급한 경우가 많거든요.
-B 차장: 그러니까 품목 단위로 가는 게 맞다고 봅니다. 주문 전체를 긴급 처리하면
-        오히려 비용이 늘어나요.
-PM: 메일에서는 주문 단위라고 하셨던 것 같은데...
-B 차장: 그건 다시 봐야겠네요. 일단 회의 결과로는 품목 단위로 가는 걸로 정리합시다.
-...

package/claude/skills/sd-spec/evals/fixtures/spec-md-input/.specs/260101120000/REQ-001-test/spec.md

@@ -1,19 +0,0 @@
-# REQ-001-test
-
-## 메타
-- 상태: specifying
-- 생성일: 2026-01-01
-- 마지막 갱신: 2026-01-01
-- 관련 영역: 테스트
-
-## 요약
-테스트용 REQ. 입력 분기 검증을 위한 fixture.
-
-## 세부 요구
-
-- [ ] R1: 테스트 기능 구현
-  > [2026-01-01, 사용자 요청] "테스트 기능을 추가해 주세요"
-  > 출처: 사용자 직접 요청 (2026-01-01)
-
-  - [ ] **Q**: 테스트 기능의 입력 형식은 무엇인가요? (예: JSON / CSV / 자유 텍스트)
-  - [ ] **Q**: 출력 형식은 어떻게 표시해야 하나요? (예: 화면 표시 / 파일 다운로드)

package/claude/skills/sd-spec/evals/fixtures/spec-md-input/.specs/260101120000/overview.md

@@ -1,18 +0,0 @@
-# Session 260101120000
-
-## 메타
-- 생성일: 2026-01-01 12:00
-- raw input 출처: (eval fixture — 5단계 완료된 가상 세션)
-- 입력 모드: Direct
-
-## 요약
-테스트용 단일 REQ 세션. 6단계 진입 검증.
-
-## REQ 목록
-- REQ-001-test: 테스트 항목
-
-## 도메인 그룹
-- 단일 도메인 (테스트)
-
-## 의존성
-없음

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

@@ -1,4 +0,0 @@
-{"id": "direct-simple-001", "input": "/sd-spec 입고지시서 지시 상태에 출고예정과 출고 사이에 상차 상태를 추가하고 싶어", "rubric": [".specs/ 디렉토리가 생성되었고 그 안에 정확히 12자리 숫자(yyMMdd_HHmmss 형식)로 된 디렉토리가 1개 이상 존재하는가?", "그 12자리 숫자 디렉토리(세션 폴더) 안에 'overview.md' 파일이 존재하는가?", "그 세션 폴더 안에 'REQ-' 로 시작하는 디렉토리가 1개 이상 존재하는가?", "각 REQ-* 디렉토리 안에 'spec.md' 파일이 존재하는가?", "spec.md 본문에 '## 메타', '## 요약', '## 세부 요구' 3개 섹션 헤더가 모두 포함되어 있는가?", "spec.md 본문에 '- [ ] R' 패턴(R 항목 체크리스트) 1개 이상 포함되어 있는가?", "에이전트의 마지막 텍스트 응답에 'REQ-' 로 시작하는 ID 매핑이 1개 이상 포함되어 있는가? (REQ specified 종료 안내 도달)", "에이전트의 마지막 텍스트 응답에 사용자 확인 요청 표현이 포함되어 있는가? (예: '진행할까요', '체크포인트', '맞나요', '괜찮을까요' 중 하나 이상)", "spec.md 본문에 '상태: specified' 또는 '최근 체크포인트' 표기가 포함되어 있는가? (체크포인트 적용 확인)"], "fixture": "direct-simple"}
-{"id": "bulk-multi-source-001", "input": "/sd-spec .docs/ 폴더의 자료들 정리해줘", "rubric": [".specs/ 디렉토리 안에 12자리 숫자 디렉토리(세션 폴더)가 1개 이상 존재하는가?", "세션 폴더 안에 'overview.md' 파일이 존재하는가?", "세션 폴더 안에 'REQ-' 로 시작하는 디렉토리가 2개 이상 존재하는가? (다중 출처 분류 결과로 여러 REQ 생성)", "각 REQ-* 디렉토리의 spec.md 본문에 '출처' 라는 인용 출처 표기가 1개 이상 포함되어 있는가?", "overview.md 본문에 'REQ-' 로 시작하는 ID 가 2개 이상 언급되어 있는가?", "에이전트의 마지막 텍스트 응답에 'REQ-' 로 시작하는 ID 매핑이 2개 이상 포함되어 있는가? (REQ specified 종료 안내 도달)", "에이전트의 마지막 텍스트 응답에 사용자 확인 요청 표현이 포함되어 있는가? (예: '진행할까요', '체크포인트', '맞나요', '괜찮을까요' 중 하나 이상)", "각 REQ-* 디렉토리의 spec.md 본문에 '상태: specified' 또는 '최근 체크포인트' 표기가 포함되어 있는가? (체크포인트 적용 확인)"], "fixture": "bulk-multi-source"}
-{"id": "conflict-detection-001", "input": "/sd-spec .docs/ 자료 정리해줘. 메일과 회의록에 충돌이 있을 수 있음", "rubric": [".specs/ 디렉토리 안에 12자리 숫자 디렉토리(세션 폴더)가 1개 이상 존재하는가?", "세션 폴더 안 어느 REQ의 spec.md 본문에 '주문 단위' 와 '품목 단위' 두 표현이 모두 포함되어 있는가? (양쪽 출처 인용 보존)", "spec.md 본문에 '주문 단위' 와 '품목 단위' 둘 다 포함되어 있어 한쪽만 자동 채택되어 다른 쪽이 폐기된 상태가 아닌가?", "에이전트의 마지막 텍스트 응답에 'REQ-' 로 시작하는 ID 매핑이 1개 이상 포함되어 있는가? (REQ specified 종료 안내 도달)", "에이전트의 마지막 텍스트 응답에 사용자 확인 요청 표현이 포함되어 있는가? (예: '진행할까요', '체크포인트', '맞나요', '괜찮을까요' 중 하나 이상)", "spec.md 본문에 '상태: specified' 또는 '최근 체크포인트' 표기가 포함되어 있는가? (체크포인트 적용 확인)"], "fixture": "conflict-detection"}
-{"id": "resume-from-spec-md-001", "input": "/sd-spec .specs/260101120000/REQ-001-test/spec.md 파일로 6단계부터 해줘", "rubric": [".specs/ 디렉토리 안에 12자리 숫자 디렉토리가 정확히 1개만 존재하는가? (새 세션 폴더 생성하지 않고 기존 세션의 6단계부터 시작했는지 검증)", ".specs/260101120000/REQ-001-test/spec.md 파일이 여전히 존재하는가? (입력 파일 보존)", ".specs/260101120000/REQ-001-test/spec.md 본문의 미해결 'Q:' 또는 '**Q**:' 패턴 개수가 fixture 시작 시점(2개)보다 줄었는가? (Q 다이얼로그 처리 진행)", ".specs/260101120000/REQ-001-test/spec.md 본문에 '상태: specified' 또는 '최근 체크포인트' 표기가 포함되어 있는가? (체크포인트 도달)", "에이전트의 마지막 텍스트 응답에 사용자 확인 요청 표현이 포함되어 있는가? (예: '진행할까요', '체크포인트', '맞나요', '괜찮을까요' 중 하나 이상)"], "fixture": "spec-md-input"}

package/claude/skills/sd-spec/references/overview-md-template.md

@@ -1,89 +0,0 @@
-# overview.md 템플릿 (세션 차원)
-
-세션 폴더 안에 위치 (`.specs/{yyMMdd_HHmmss}/overview.md`).
-spec 단계 워크플로 4번(전체 구조 잡기)에서 초안 작성. 이후 REQ 추가/폐기/분리/병합/번호 재배치/의존성 변경 시 즉시 갱신.
-
-## 템플릿
-
-```markdown
-# Session {yyMMdd_HHmmss}
-
-## 메타
-- 생성일: YYYY-MM-DD HH:MM
-- raw input 출처: <어디서 왔는지 — 폴더 경로/파일/채팅 paste 등>
-- 입력 모드: Bulk | Direct | Mixed
-
-## 요약
-<세션 전체에 대한 1~2줄 요약>
-
-## REQ 목록
-- REQ-001-슬러그: <한 줄 요약>
-- REQ-002-슬러그: <한 줄 요약>
-- REQ-003-슬러그: <한 줄 요약>
-
-## 도메인 그룹 (있을 때만)
-<같은 도메인의 REQ들이 명확히 묶이면 표시>
-- RTP: REQ-001, REQ-002
-- WMS: REQ-003
-
-## 의존성 (있을 때만)
-- REQ-002 depends on REQ-001 (이유)
-- REQ-003 depends on REQ-001 (이유)
-
-## Cross-cutting concerns (있을 때만)
-<여러 REQ를 가로지르는 메모. 예: "전체적으로 권한 체계 개편 필요">
-```
-
-## 섹션별 역할
-
-| 섹션 | 용도 |
-|---|---|
-| `## 메타` | 세션 시작 시점/입력 출처/모드 |
-| `## 요약` | 세션 전체 1~2줄 |
-| `## REQ 목록` | 세션 안의 모든 REQ를 한눈에 |
-| `## 도메인 그룹` | 도메인 명확할 때 grouping (선택) |
-| `## 의존성` | REQ 간 의존 (선택) |
-| `## Cross-cutting concerns` | 가로지르는 메모 (선택) |
-
-## 갱신 정책
-
-- **워크플로 4번(전체 구조 잡기)**에서 초안 작성
-- 이후 REQ 변경 (추가/폐기/분리/병합/번호 재배치/의존성 변경) 시 즉시 갱신
-- 갱신 책임:
-  - spec 단계 안에서 발생한 변경: spec 단계가 갱신
-  - demo 단계에서 발생한 변경: demo 단계가 갱신
-  - plan 단계에서 spec 모순 발견 시: plan이 갱신
-
-## 도메인 그룹/의존성 표기 정책
-
-- **도메인 그룹**: 명확히 묶이는 경우만 표시. 단일 REQ는 grouping 생략.
-- **의존성**: 한 REQ가 다른 REQ에 의존할 때만 표시. 독립 REQ는 표시 X.
-
-## 예시
-
-```markdown
-# Session 20260503143025
-
-## 메타
-- 생성일: 2026-05-03 14:30
-- raw input 출처: .docs/ 폴더 (메일 6개 + 회의록 5개)
-- 입력 모드: Bulk
-
-## 요약
-ADTEK WMS 입고/출고 관련 5개 기능 개선 요청 정리.
-
-## REQ 목록
-- REQ-001-입고지시서수정: 긴급 표시 체크박스 + PDF 강조
-- REQ-002-입고지시서Reporting: 입고 보고서 출력 기능
-- REQ-003-출고관리상차: 상차 상태 추가
-- REQ-004-WMS권한: 권한 체계 개편
-- REQ-005-알림: 긴급 입고 시 알림
-
-## 도메인 그룹
-- 입고: REQ-001, REQ-002
-- 출고: REQ-003
-- 시스템: REQ-004, REQ-005
-
-## 의존성
-- REQ-005 depends on REQ-001 (긴급 표시 후 알림)
-```

package/claude/skills/sd-spec/references/raw-input-handling.md

@@ -1,96 +0,0 @@
-# raw input 부정확성 처리
-
-raw input은 산출물 소비자 발화 원본이라 부정확/모호한 부분이 많다. 각 종류별 특성과 처리 정책.
-
-## 종류별 특성
-
-| 종류 | 부정확성 |
-|---|---|
-| **STT 회의록** | 텍스트 오타, 화자 잘못 매칭, 발화 끊김, 다중 화자 발언 섞임 |
-| **이메일** | 비격식 문장, 주어 생략, 지시대명사("그거", "이렇게") |
-| **채팅 paste** | 짧은 토막글, 맥락 부족 |
-| **사용자 직접 요청** | 도메인 전문용어 생략, 암묵 가정 많음 |
-
-## 처리 정책
-
-### STT 텍스트 보정
-
-**명백한 오타만 보정**. 보정 시 `[원문]` 인용으로 원본도 보존.
-
-```markdown
-> [2026-03-17 회의] "PDF에 빨간색으로 강조"
-> [원문] "PDF에 빨간색으루 강조"
-> 출처: .docs/회의대본_3.txt:L120
-```
-
-판정:
-- ✅ 명백 (오타 1~2글자, 의미 자명): 보정
-- ❌ 모호 (의미가 여러 갈래로 해석 가능): **Q로 등록**, 원문 그대로 인용
-
-### 화자 추정
-
-회의록 화자가 부정확/누락된 경우 컨텍스트로 추정. `[추정: ...]` 표기.
-
-```markdown
-> [2026-03-17 회의, 추정: B 차장] "주문 단위로 가는 게 맞다"
-> 출처: .docs/회의대본_3.txt:L78-L80
-```
-
-판정:
-- ✅ 컨텍스트로 명확 (예: 직전 발언자가 B 차장이고 응답 흐름 명확): 추정
-- ❌ 모호 (여러 화자 가능): **Q로 등록**, 화자 미상으로 인용
-
-### 모호 발화 처리
-
-지시대명사·생략 표현·비격식 발언:
-- "그거 그렇게" / "이렇게 가는 걸로" / "지난번처럼" / "알아서"
-
-처리:
-- **자동 해석 금지** (이전 발언/맥락 추측해서 채워 넣지 말 것)
-- **Q로 등록** — "그거"가 무엇인지, "그렇게"가 어떤 방식인지 사용자에게 확인
-
-### 다중 화자 발언 섞임 (회의록)
-
-여러 사람이 같은 주제를 다른 입장에서 말한 경우:
-- 양쪽(또는 모든) 발언 모두 인용 보존
-- 사용자에게 어느 의견 채택할지 Q (충돌 처리와 동일)
-
-### 비격식 메일 / paste
-
-주어 생략, 맥락 누락:
-- 보충 가능한 부분(자명한 주어 등): 인용 시 `[추정 보충: ...]` 표기로 원문에 덧붙이지 않고 명시
-- 모호한 부분: Q
-
-### 도메인 용어 다의성
-
-raw input은 시스템 용어가 아니라 **현장 은어**. 같은 단어가 시스템상 여러 동작에 매핑될 수 있음.
-
-- 예: "출고" → 창고간 재고이동 / 고객사 납품 / 차량 적재 / 그 외 — 현장에서는 이 모두를 "출고"로 부름
-- 예: "마감" → 일마감 / 월마감 / 정산마감 / 작업종료
-- 예: "주문" → 고객 발주 / 내부 작업지시 / 견적 단계
-
-**위험도 역설**: 일반적으로 들리는 업무 용어(출고/입고/재고/주문/마감/등록 등)일수록 더 의심. 낯선 용어는 자연스럽게 의문이 생기지만, 익숙한 용어는 모두가 안다고 착각함.
-
-처리:
-- **자동 매핑 금지** — 단어를 첫 번째로 떠오르는 시스템 동작에 임의 매핑하지 말 것
-- **Q로 등록** — "이 단어가 시스템상 어떤 동작을 가리키는지" 사용자에게 확인
-- **후보 나열 금지** — Claude가 추측한 후보를 제시하면 사용자가 그 안에서만 고르게 가둠. 후보는 사용자가 답하게 둘 것
-
-```markdown
-> [2026-03-17 회의] "출고 처리할 때 자동으로 라벨 출력되게"
-> 출처: .docs/회의대본_3.txt:L45
-> Q: 여기서 "출고"는 시스템상 어떤 동작을 가리키는가?
-```
-
-## 인용 출처 표기 (모드별)
-
-- 파일 입력: `<파일경로>:L<범위>`
-- 채팅 paste: `채팅 paste (YYYY-MM-DD)`
-- 사용자 직접 요청: `사용자 직접 요청 (YYYY-MM-DD)`
-
-## 핵심 원칙
-
-- **원본 인용을 spec.md inline에 풍부하게** (보정/추정 결과만 굳히지 말고 원문도 함께)
-- **자동 판단 금지** — 모호하면 무조건 Q
-- **현장 용어 ≠ 시스템 용어** — 익숙한 단어일수록 자동 매핑 금지
-- **raw input 자체 수정 X** — 보정/추정은 spec.md 인용 시점에만

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

@@ -1,96 +0,0 @@
----
-name: sd-verify
-description: overview/spec/plan/impl + 실제 코드를 REQ 단위로 통합 읽어 충돌·누락(문서 미업데이트 / 놓친 구현 / 단계 간 모순)을 발견하고 verify.md로 기록. Use when implement 단계 후 인수 검증이 필요할 때
----
-
-# verify 단계
-
-REQ 단위로 4문서(overview/spec/plan/impl) + 코드 통합 읽기. 자동 검증 + 사용자 시연 결합.
-
-## 산출물
-
-```
-.specs/{yyMMdd_HHmmss}/
-  overview.md                   ← 입력 (해당 REQ + 공통)
-  REQ-XXX-슬러그/
-    spec.md / plan.md / impl.md ← 입력
-    verify.md                   ← 산출물
-```
-
-## 워크플로
-
-1. 입력: 대상 REQ ID
-2. 읽기: 4문서 + 코드 (+ raw input 재참조)
-3. **충돌·누락 점검** (양방향, 자연어 추출 — 아래 표 참조)
-4. **테스트 실행**: impl.md 케이스 직접 실행, 보고와 비교
-5. **회귀 검증**: 전체 테스트
-6. **시연** (필요 R만, plan 모드 기준 — 아래 표 참조)
-7. 모든 R 충족 + 충돌·누락 0건 → 체크포인트 (메타 `상태: verified`, spec.md 메타 `상태: done`)
-
-발견 시: verify.md 기록 + 즉시 보고 + 해결방안 제안 (예: 새 REQ 분리 / 현 REQ 재작업 / 무시). 결정은 사용자.
-
-## 충돌·누락 (양방향 점검)
-
-페어 매트릭스로 정형화하지 말고, 다 읽은 뒤 발견된 것만 자연어로 추출.
-
-| 유형 | 의미 | 예 |
-|---|---|---|
-| **문서 미업데이트** (뒤 → 앞) | 코드/구현이 앞 문서를 추월 | 코드에 있는 동작이 spec엔 없음, plan 진행 중 추가된 의존성이 overview 미반영 |
-| **놓친 구현·문서화** (앞 → 뒤) | 앞 문서 항목이 뒤로 안 닿음 | spec R이 plan에 미매핑, plan 위치가 코드 미반영, impl이 보고 안 한 변경 |
-| **단계 간 모순** | 두 단계가 다른 결론 | plan은 분리, 코드는 단일 파일 |
-
-## 충족 판정
-
-| 분류 | 의미 |
-|---|---|
-| 충족 | R 의도 완전 만족 + 충돌·누락 없음 |
-| 부분충족 | 일부 sub-criteria 미만족 또는 충돌·누락 발견 |
-| 미충족 | 만족 X |
-
-종료 시 모든 R 충족 + 발견 0건. 미해소 항목 남은 채 done 금지.
-
-## 시연 (plan 모드 기준)
-
-| plan 모드 | 시연 |
-|---|---|
-| TDD | 불필요 |
-| 사후 테스트 | 필수 |
-| 생략 | 필수 |
-
-시나리오는 plan.md / impl.md 케이스 사용. 한 번에 하나씩, 결과 verify.md 기록.
-
-시연 도구·환경 실패(playwright 미동작, 빌드 실패, 접근 불가 등)는 **충족 판정 사유 아님**. 상황(도구·증상·재현 시도)을 사용자에 즉시 보고하고 판단 대기. 임의 스킵·done 금지.
-
-사용자가 명시적으로 미수행으로 결정한 R은 verify.md에 "시연 미수행 — <사유>"로 기록하고 REQ done 차단.
-
-## 예시 (보고 형식)
-
-```
-발견 — plan.md는 컴포넌트 분리 명시, 코드는 단일 파일 (모순).
-verify.md 기록 완료.
-제안:
- (a) 분리 유지가 맞다면 → 현 REQ 재작업 (코드 분리)
- (b) 단일 파일이 맞다면 → 현 REQ 재작업 (plan 갱신, 사유 기록)
- (c) 범위 큰 재설계라면 → 별도 REQ 분리
-결정 부탁.
-```
-
-## 핵심 원칙
-
-- **양방향 점검**: 뒤→앞과 앞→뒤 둘 다. 한 방향만 보면 절반 놓침.
-- **자연어 추출**: 페어 매트릭스로 정형화 X (OK 채우기 함정)
-- **발견은 보고·제안까지**: 직접 수정·재진입 X, 결정은 사용자
-- self-contained 블록 (R 블록 안에 검증/시연/판정 인라인)
-- raw input·ID 불변
-
-## 안티패턴
-
-- ❌ impl.md 보고 그대로 신뢰 (테스트 직접 실행 X)
-- ❌ overview/plan 안 읽고 spec+impl+코드만 보기
-- ❌ 한 방향만 점검 (문서 미업데이트 통째로 놓침)
-- ❌ 페어 매트릭스로 정형화
-- ❌ verify가 문서/코드 직접 수정 또는 임의 재진입 트리거
-- ❌ 시연 시나리오 새로 정의
-- ❌ TDD R에 시연 강요 / 사후·생략 R 시연 생략
-- ❌ 시연 도구(playwright 등) 실패·미실행을 보고 없이 넘기고 충족 판정 / REQ done
-- ❌ 미해소 항목 남은 채로 REQ done

package/claude/skills/sd-verify/evals/fixtures/all-satisfied/.specs/260503143025/REQ-001-/355/225/240/354/235/270/352/263/204/354/202/260/impl.md

@@ -1,20 +0,0 @@
-# REQ-001-할인계산 / Implementation
-
-## 메타
-- 상태: implemented
-
-## R 단위 구현 결과
-
-### R1: 할인율 계산 함수
-- **상태**: 완료
-- **모드**: TDD
-- **변경 파일**:
-  - `src/lib/discount.ts` (신설)
-    - 변경 함수: `calcDiscountRate`
-    - 변경 종류: 신설
-- **테스트**:
-  - 추가: `src/lib/discount.test.ts`
-    - 케이스: "0원 → 0", "99999원 → 0", "100000원 → 0.05", "499999원 → 0.05", "500000원 → 0.10", "999999원 → 0.10", "1000000원 → 0.15"
-    - 결과: PASS (7/7)
-- **plan 대비 차이**: 없음
-- **변경 의도**: spec.md R1 + plan.md R1 그대로

package/claude/skills/sd-verify/evals/fixtures/all-satisfied/.specs/260503143025/REQ-001-/355/225/240/354/235/270/352/263/204/354/202/260/plan.md

@@ -1,14 +0,0 @@
-# REQ-001-할인계산 / Plan
-
-## 메타
-- 상태: planned
-- 결과: proceed
-
-## R 단위 계획
-- [ ] R1: 할인율 계산 함수
-  - **현황**: 미구현
-  - **변경 위치**: `src/lib/discount.ts` - `calcDiscountRate`
-  - **변경 방식**: 100만↑ 0.15, 50만↑ 0.10, 10만↑ 0.05, 그 외 0
-  - **테스트**:
-    - 방식: TDD
-    - 케이스: 0, 99999, 100000, 499999, 500000, 999999, 1000000

package/claude/skills/sd-verify/evals/fixtures/all-satisfied/.specs/260503143025/REQ-001-/355/225/240/354/235/270/352/263/204/354/202/260/spec.md

@@ -1,12 +0,0 @@
-# REQ-001-할인계산
-
-## 메타
-- 상태: implemented
-- 관련 영역: 주문/결제
-
-## 요약
-주문 금액별 할인율 계산 함수.
-
-## 세부 요구
-- [ ] R1: 할인율 계산 함수 (10만↑ 5%, 50만↑ 10%, 100만↑ 15%)
-  - **A**: 큰 구간부터 비교