@simplysm/sd-claude 14.0.91 → 14.0.92

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

@@ -1,11 +1,11 @@
 ---
 name: sd-spec
-description: SI/업무시스템 요구사항을 분석해 spec.md 로 구조화. Use when "요구사항 분석", "SI 분석", "업무시스템 spec 작성" 을 요청할 때.
+description: SI/업무시스템 요구사항을 분석해 spec.md 로 구조화. 배치 작성(분석/설계 워크플로) + 부분 수정 인라인 처리. Use when "요구사항 분석", "SI 분석", "업무시스템 spec 작성" 을 요청할 때.
 ---
 
 # sd-spec
 
-요구사항을 분석하여 spec.md 1개로 산출. 사이클 반복으로 채워나감.
+요구사항을 분석하여 spec.md 1개로 산출. 최우선 목적 = 정확한 spec (환각 차단·누락 차단). 연산 단위로 채워나감 — 호출 1회 = 연산 1개, spec.md 라는 영속 산출물에 대한 연산의 모음.
 
 ## 입출력
 
@@ -15,205 +15,81 @@ description: SI/업무시스템 요구사항을 분석해 spec.md 로 구조화.
   - `yyMMddHHmmss`: PowerShell `Get-Date -Format "yyMMddHHmmss"` 명령으로 생성 (예: `260513204500` = 2026-05-13 20:45:00).
   - `slug`: 짧은 한·두 단어. 허용 문자는 한글·영문·`_`·`-`·공백 (그 외 문자는 금지).
 
-## 사이클 (본체)
+## 연산
 
-초안 1건 당 1 사이클. 6단계 모두 거치는 것이 강제.
+sd-spec 은 3종의 연산으로 동작. 사용자 지시를 받으면 아래 디스패치로 분기. per-unit "맞나요?" 확인 루프는 없음 — 배치로 한 번에 작성하고 사용자가 사후 검토(검토 패키지)로 정정.
 
-```
-1. 무엇 선정 → 2. 초안 작성 → 3. "맞나요?" 합의 → 4. spec.md 반영 → 5. 곁가지로 나온 것 점검 → 6. 다음 단위 연속
-```
-
-### 1단계: 무엇 선정
-
-사용자 지시가 우선. 지시가 없으면 LLM 의 권장 순서 따름.
-#### 큰 순서 (권장)
-
-각 단계별 진입 조건·spec.md 매핑·절차 위치·다음 단계:
-
-| 단계      | 진입                     | spec.md 매핑                        | 절차 위치               | 다음             |
-| --------- | ------------------------ | ----------------------------------- | ----------------------- | ---------------- |
-| 분석 분할 | Requirement Source 수집  | §2/§3 헤더 분할 + spec.md 골격 생성 | §2 의 "분할 절차"       | §x.x 분석 명세   |
-| 분석 명세 | 분석 분할 완료 §x.x      | §1 + §2/§3 본문                     | §별 작성법 (사이클 2~6) | §x.x 설계 분할   |
-| 설계 분할 | 분석 명세 §x.x 본문 확정 | §4/§5/§6 헤더 분할                  | §4 의 "설계 분할 절차"  | §x.x 설계 명세   |
-| 설계 명세 | 설계 분할 §x.x [OPEN]    | §4/§5/§6 본문                       | §별 작성법 (사이클 2~6) | (반복 / 종료)    |
-
-- **분할 단계 사이클** (분석 분할 / 설계 분할 공통, 6단계 적용 — 아래 1~4 는 본체 step 2~4 의 분할 단계용 변형. 본체 step 1·5·6 은 그대로 적용):
-  1. 초안 = 분류별 평면 목록을 채팅 출력 + 순서·명칭 제시.
-    - 분석 분할 시 분류 = §2 후보 / §3 후보 / 미분류 (분류 룰 = §2 "분할 절차").
-    - 설계 분할 시 분류 = §4 후보 / §5 후보 / §6 후보 (분류 룰 = §4 "설계 분할 절차").
-  2. 사용자 피드백 종류 = 분류 이동 / 순서 변경 / 명칭 변경 / 항목 추가·제거 / "전부 확정".
-  3. 피드백 반영 → 구성 갱신 → 채팅 재출력 → 위 2번 단계로 재진입 (**루프**).
-  4. 사용자가 "전부 확정" 발언 → 헤더 일괄 Write (헤더 마커 `[OPEN: 날짜]` + 본문 = 분석 방법 자동 작성).
-    - 분석 분할 시 = spec.md 골격을 신규 생성 + §2.x/§3.x 헤더 일괄 작성.
-    - 설계 분할 시 = §4.x/§5.x/§6.x 헤더 일괄 작성.
-- **명세 단계**: §x.x 본문을 §별 초안 단위에 따라 1건씩 사이클 진행 (본체 2~6단계).
-
-#### 자유 진입
-
-- 큰 순서 내부에서 어떤 §x.x 를 선택할지는 사용자의 자유 (지시가 없으면 LLM 이 권장).
-- 큰 순서들 간에는 §x.x 단위로 파이프라인 진행 — 큰 순서 전체 완료를 강제하지 않음.
-  - 예: §2.1 본문 확정 → §2.1 관련 §4/§5/§6 분할 진입 (§2.2 본문 미시작 상태에서도 허용).
-  - 의존성 엄격 적용: §x.x 단위로 직전 큰 순서가 완료된 후에 다음 큰 순서 진입 (예: §4.1 본문 진입 조건 = §4.1 헤더 분할 완료 + §2.1 본문 확정).
-- 서브섹션 간 순서는 자유 (예: §4.1 내부의 와이어·항목·동작 등의 순서).
-- §7/§8/§9 는 작업 중에 자연스럽게 도출됨 ("다른 섹션 반영거리" 절차이며, 5단계 참조).
-- §10 은 결정이 발생할 때마다 누적 (확정 항목 1건당 1 사이클).
-
-#### 재진입 분기 (spec.md 첨부 시)
-
-spec.md 첨부 재진입 시 상황별 권장 진입점:
-
-| 상황                                       | 권장 진입점                                                                |
-| ------------------------------------------ | -------------------------------------------------------------------------- |
-| 헤더 `[OPEN: 날짜]` 있는 섹션 존재         | 첫 OPEN 섹션의 본문 분석 방법대로 재분석 → 초안 작성 → 사이클 진입         |
-| 헤더는 `[확정]` 이고 본문에 인라인 `[OPEN]` 만 존재 | 첫 OPEN 항목부터 1건씩 처리                                       |
-| 모든 섹션이 `[확정]`                       | 사용자의 추가 요구 대기                                                    |
-
-### 2단계: 초안 작성
-
-#### 초안 단위
-
-행동 규칙 "묶음 채택 금지" 적용 — 사용자가 한 번에 yes/no 로 답할 수 있는 최소 단위. 응답 1건에 선택지 세트 1개. §별 작성법 첫머리에 단위 명시.
-
-#### 스스로 검증 게이트
-
-초안 출력 직전마다 자문. 한 가지라도 실패 시 초안 폐기 후 재작성 또는 사용자에게 질문. 행동 규칙 "응답 전송 직전 자가 점검" 에 더해 적용되는 sd-spec 고유 검증.
-
-1. **형식** — 해당 § 작성법 규약을 따랐는지. 점검 전 2개를 모두 로딩: ① 해당 § 작성법 절 재독, ② 그 § 첫머리 "모범" 에 적힌 example-spec.md 의 모범 §번호를 `Read` (offset/limit 로 해당 §만). 두 자료에 헤더 구조·표 형식·마커 표기를 직접 대조 (모범 Read 없이 텍스트 규칙만으로 작성 금지).
-2. **출처** — 각 항목·필드·동작 1건마다 사용자 발언·자료를 인용할 수 있는지.
-  - 인용 불가 = As-Is 답습 / 다른 §·example 패턴 복제 의심 → 제거 또는 별도 질문.
-  - As-Is (회의록·매뉴얼·현행 화면) 는 추정 자료 (행동 규칙 "결정 근거 안티패턴").
-  - 다른 §·example 에서는 **형식만** 가져오고, **내용물** (항목·컬럼·필드·액션·동작) 은 본 §의 §2.x/§3.x 본문·사용자 발언에서 직접 도출.
-3. **단순화 차단** — spec 명시 정의·식·분기·경계에 대해 초안에서 자체 단순화·근사화·안전 처리 (NULL 강제·0 클램프·방어 가드·분기 생략) 를 임의로 추가하지 않았는지.
-  - 식은 그대로 풀어쓸 것.
-  - 정확 풀이 부담이 크면 단순화안을 사용자에게 보고 후 합의.
-
-### 3단계: "맞나요?" 합의
-
-- "맞나요?" 라고 묻고 사용자 답변 대기.
-- 답변 종류: 확정 / 수정 / 보류.
-
-### 4단계: spec.md 반영
-
-#### 확정 → Write
-
-헤더 마커 `[확정: YYYY-MM-DD]` 부착 (날짜는 PowerShell `Get-Date -Format "yyyy-MM-dd"` 로 생성).
-
-#### 수정 → 재작성
-
-- 사용자의 정정을 반영 → 2단계로 돌아가 초안 재작성 → 3단계 재진행.
-
-#### 보류 → Write (분석 방법)
-
-OPEN 섹션의 본문 = **분석 방법** (초안 아님) — 재분석할 절차 또는 접근 방식을 자유롭게 작성. 헤더 마커 `[OPEN: YYYY-MM-DD]`.
+### 디스패치
 
-분석 방법 가이드 (해당 시 자유 조합):
+| 지시 유형                                              | 연산        | 처리 경로                                     |
+| ----------------------------------------------------- | ----------- | --------------------------------------------- |
+| "분석해줘"·"요구사항 분석"·"업무 프로세스 분석" 류     | 분석 배치   | Workflow 도구로 `workflow-analyze.js` 실행    |
+| "설계해줘"·"화면 설계"·"자동 처리 설계" 류             | 설계 배치   | Workflow 도구로 `workflow-design.js` 실행     |
+| 그 외 모든 지시 ("X를 Y로"·"A를 B와 합쳐"·"이 섹션 이상해"·재진입 정정) | 부분 수정   | SKILL.md 인라인 처리 (아래 "부분 수정")        |
 
-- 자료 참고 시 자료 위치 명시 (예: `회의록.md L12-30`, `As-Is 매뉴얼 X.pdf p.3`).
-- 사용자의 보류 발언 인용 (1~2줄).
-- 한 섹션이 여러 자료에 걸쳐있으면 자료 연결 추정을 한 줄로 기록.
-- 다른 § 확정이 본 OPEN 재분석에 영향을 줄 경우 한 줄씩 누적 (운용 절차 = 5단계 OPEN 푸시. 형식: `§X.Y <섹션명> 확정 — <결정 한 줄>`).
+- 분석/설계 배치는 백그라운드 자율 실행. 실행 중 사용자에게 묻지 않음 (모르는 건 [OPEN]).
+- 재진입(기존 spec.md 첨부 후 추가 지시)은 기본적으로 부분 수정 경로. 단 지시가 "다음 단계 전체를 배치로 진행"이면 해당 배치 연산.
 
-**발생 경로** (본문이 분석 방법인 점은 공통):
+### 분석 배치
 
-- 사용자가 명시적으로 보류 (초안 제시 후 보류 지시) — 분석 방법을 자유롭게 작성.
-- 헤더 분할 직후 자동 (본문 미작성 상태로 일괄 OPEN 처리):
-  - 분석 분할의 §2.x/§3.x — 분석 방법 = Requirement Source 자료의 위치·접근 방식.
-  - 설계 분할의 §4.x/§5.x/§6.x — 분석 방법 = 관련 §2.x/§3.x 본문 참고.
+"분석해줘" 류 지시. 메인 에이전트가 Workflow 도구를 호출해 분석 워크플로에 위임:
 
-**재개**: 본문에 적힌 분석 방법대로 자료 재독·분석 → 초안 도출 → 확정되면 본문을 초안으로 교체 + 헤더 마커 `[확정: 날짜]` 로 갱신.
+- `Workflow({ scriptPath: "<이 스킬 폴더>/workflow-analyze.js", args: { specPath: "<spec.md 경로>", sourcePaths: ["<자료 경로>", ...], systemName: "<시스템명>", today: "<yyyy-MM-dd>", skillDir: "<이 스킬 폴더>" } })`.
+  - `specPath`: 산출 대상 spec.md 경로. 없으면 위 "입출력" 의 폴더 규칙으로 신규 경로 생성 후 전달.
+  - `sourcePaths`: Requirement Source 자료 경로 목록 (사용자 첨부·발화 기록 포함).
+  - `systemName`: 사용자와 합의한 시스템명 (spec.md 골격의 `{name}`).
+  - `today`: 현재 날짜 (PowerShell `Get-Date -Format "yyyy-MM-dd"`). §10 로그 타임스탬프용. 워크플로는 전역 현재시각을 쓰지 않으므로 필요한 시각은 args 로 전달.
+  - `skillDir` / `<이 스킬 폴더>`: 이 SKILL.md 가 위치한 디렉터리의 절대경로 — 에이전트가 런타임에 채움 (워크플로가 SKILL.md·example-spec.md 를 읽는 데 사용). 배포 환경마다 경로가 다르므로 하드코딩하지 말 것.
+- 워크플로가 §1~§3 (분석 명세) + 자연 도출 §7~§9 + §10 을 자율 작성해 spec.md 에 write.
+- 완료 후 메인 에이전트는 "연산 사이 검토" 의 검토 패키지를 제시하고 정지.
 
-### 5단계: 곁가지로 나온 것 점검
+### 설계 배치
 
-사이클 종료 직전마다 자문. 해당하는 경우에만 처리.
+"설계해줘" 류 지시. 확정된 §1~§3 을 입력으로 설계 워크플로에 위임:
 
-#### 다른 섹션 반영거리
+- `Workflow({ scriptPath: "<이 스킬 폴더>/workflow-design.js", args: { specPath: "<spec.md 경로>", skillDir: "<이 스킬 폴더>" } })` (설계는 확정 §1~3 만 입력 — `sources`/`today` 불필요).
+- 워크플로가 §4 화면 / §5 자동 처리 / §6 공통·기반 기능 (+ 그 과정에서 도출되는 §7~§9 보강) 을 자율 작성해 spec.md 에 write.
+- 완료 후 검토 패키지 제시 후 정지.
 
-발견 경로는 무관 — 본문 작성 중·자료 재독 중·외부 조사·OPEN 섹션 재분석 곁가지 등 어디서든, 다른 § (기존 §x.x 본문 보강·신규 §x.x 추가·§7/§8/§9 공통 섹션 추가) 에 반영할 정보를 발견했을 때:
+### 부분 수정 (인라인)
 
-**처리 갈래** (영향 크기 + 영향 섹션 상태별):
+분석/설계 배치 외의 모든 지시는 SKILL.md 가 메인 에이전트로 직접 처리. 워크플로 호출 없음. 재진입(기존 spec.md 에 대한 추가 작업)도 이 경로.
 
-- 영향 작음 (한 줄 보강·기존 본문 초안 1건 정도) → 같은 턴에 처리. 해당 § 사이클 진입 (초안 → 합의 → 반영) → 원 작업 재개.
-- 영향 큼 (새 §x.x 신설·여러 초안 필요) → 영향 섹션의 상태에 따라:
-  - 영향 섹션 헤더가 `[OPEN]` 상태 → 그 본문 분석 방법에 한 줄 추가 (`<날짜> 추가: <내용>`).
-  - 영향 섹션 헤더가 `[확정]` 상태 → 본문 안에 인라인 `[OPEN]` 항목을 추가 (헤더 [확정] 은 유지).
-  - 영향 섹션 헤더가 존재하지 않음 → 헤더 신설 + `[OPEN: 날짜]` + 본문에 분석 방법 작성.
-  - 처리 후 사용자에게 한 줄 보고. 원 작업 (현재 진입 단위) 완료 후 6단계에서 같은 세션 내 이어받아 처리 — 다음 세션으로 미루지 않음.
+- **정밀 지시** ("§4.2 의 X 컬럼을 Y로", "이 항목 [OPEN] 으로") → 바로 Edit. 무관 섹션은 건드리지 않음 (일괄 치환 금지 — Edit 의 `old_string` 을 유일 매칭되게 좁혀서 수정).
+- **모호 지적** ("이 섹션 이상해", "여기 흐름이 안 맞아") → 무엇이 문제인지 진단을 먼저 제시 → 사용자 합의 → Edit. 추측으로 바로 고치지 않음.
+- **구조 변경** (병합·분할·추가: "A 화면과 B 화면을 합쳐", "이 프로세스를 둘로 나눠") → 이름 기반 참조 cascade:
+  - `[화면.X]`·`[모델.X]`·`[프로세스.X]` 등 이름 기반 참조("본문 내 참조" 절)를 grep 으로 전수 추적해, 병합·분할·삭제로 끊기는 참조를 함께 갱신.
+  - § 번호는 자주 바뀌므로 이름으로 추적. 변경 후 dangling 참조가 남지 않게 확인.
+- 작성 형식·신뢰도 표기는 아래 "작성 원칙" 과 **대상 섹션의 작성법** (아래 "§별 작성법" 절 표에서 해당 ref 를 Read) 을 따름.
 
-- ❌ §2.1 작성 중에 "BOA 는 매일 갱신되고 라인은 며칠 내 사라짐" 을 발견 → 아무 처리 없이 §2.1 만 계속 진행.
-- ✅ (영향 작음) §7.x 보강 사이클로 즉시 진입 → 확정 → §7.x 에 반영 → §2.1 재개.
-- ✅ (영향 큼) §7.x 본문에 `[OPEN]` 항목 추가 → 사용자에게 한 줄 보고 → §2.1 재개.
+### 워크플로 부재 시
 
-#### 지나가는 말 챙기기
+`disableWorkflows` 등으로 Workflow 도구를 쓸 수 없으면, 분석/설계 배치는 fallback 없이 "이 연산은 workflow 가 필요합니다 (현재 비활성)" 라고 명확히 안내하고 정지. 부분 수정은 워크플로 없이 정상 동작.
 
-사용자가 지나가듯 한 말 (가드레일·단서·미반영 의견) 은 영향 받는 § 초안 작성 시 반영. 놓치는 것 금지.
+### 연산 사이 검토
 
-- ❌ §1 단계에서 사용자가 "Location 코드는 영문 대문자만" 이라고 지나가듯 말함 → §7.1 초안에 미반영.
-- ✅ §7.1 초안에 "Location 코드는 영문 대문자·숫자·하이픈 허용" 을 포함.
+각 연산(배치·부분 수정) 완료 후 동일하게:
 
-영향 받는 §가 현재 §와 다르면 위 "다른 섹션 반영거리" 절차 적용.
+1. spec.md 갱신 (write/Edit 완료).
+2. **검토 패키지** 를 채팅으로 제시:
+   - 이번에 쓴 섹션의 한 줄 요약.
+   - `[OPEN]` 목록 (이번 연산이 남긴 미확정 항목).
+   - verify 결과 요약 (배치 연산의 경우 워크플로 verify 단계가 반환한 근거 위조·누락·커버리지·dangling 참조 보고).
+   - 자료 커버리지 보고 (쓴 자료 중 spec 에 미반영된 부분).
+   - **워크플로 에러 시** (배치): 분석·설계 워크플로는 fail-fast — 에이전트(자료 추출·섹션 작성·검증 등)가 하나라도 실패하면 부분 결과 없이 throw 함. 배치가 에러로 끝나면 검토 패키지를 만들지 말고 실패 사실을 [error] 로 알린 뒤 resume 로 재실행. 정상 완료 시에만 검토 패키지를 제시.
+3. **정지**. 자동 진행하지 않음 — 분석이 끝나도 설계로 자동 진입 금지. 다음 연산은 사용자가 호출.
 
-#### 진행 방법 누적
+## 작성 원칙
 
-사이클 중 사용자와 진행 방식을 합의하면 즉시 누적. 형식·운용은 `## spec.md 형식` 의 "진행 방법 누적" 절 참조.
+배치·부분 수정 모두에 적용되는 spec 정확성 원칙 (상위 행동 규칙·sd-design-rules 와 중복 금지, sd-spec 고유분만).
 
-#### OPEN 섹션 영향 푸시
+- **비자명 항목 inline 근거** — 자료에서 해석·도출한 비자명 항목에는 근거를 부착(아래 "신뢰도 표기"). 사용자가 직접 말한 자명한 항목엔 붙이지 않음.
+- **모르면 [OPEN]** — 근거가 없으면 임의로 채우지 말고 [OPEN] 으로 표기. As-Is (회의록·매뉴얼·현행 화면) 만 근거인 항목·답변 범위 흡수는 근거 없음 → [OPEN].
+- **결측 보존** — `""`·`0`·`false`·임의값으로 치환 금지. nullable 은 nullable 로.
+- **단순화 차단** — spec 명시 정의·식·분기·경계를 자체 단순화·근사화·방어 처리(NULL 강제·0 클램프·가드·분기 생략) 로 임의 변형하지 않음. 식은 그대로 풀어쓰기. 정확 풀이 부담이 크면 단순화안을 [OPEN] 으로 표기하거나 검토 패키지에서 사용자에게 보고.
+- **형식 준수** — 각 § 작성법 규약 + 그 § 첫머리 "모범" 의 example-spec.md 모범 §를 형식 모범으로 직접 대조 (모범 Read 없이 텍스트 규칙만으로 작성 금지). 다른 §·example 에서는 **형식만** 가져오고 **내용물**(항목·컬럼·필드·액션·동작) 은 본 §의 자료·발언에서 직접 도출.
 
-확정된 결정이 OPEN 상태의 다른 §의 재분석에 영향을 줄 수 있는지 자문.
-
-- 영향이 있으면 해당 OPEN 의 본문 분석 방법에 `§X.Y <섹션명> 확정 — <결정 한 줄>` 메모 추가.
-- 같은 작업 안에서 함께 처리. 사용자에게 한 줄 보고.
-- 별도의 "맞나요?" 합의는 진행하지 않음 (확정 기록일 뿐, 초안 아님).
-
-#### §4/§5/§6 구현 마커 제거
-
-§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]`.
-- §7 외부 자료 명세를 컬럼명 일치로 끌어다 쓴 양식 매핑 표 (해당 §7.x).
-- 모달 호출 `→ [화면.X]` 의 그 §4.x.
-
-**전파 방향**: 참조 대상 → 참조하는 §4.x/§5.x/§6.x 단방향.
-
-**처리** (영향 §4/§5/§6 개수별 갈래):
-
-- 적음 (5개 내외) → "다른 섹션 반영거리" 와 같은 턴에 처리. 영향 받는 §4.x/§5.x/§6.x 를 번호를 매겨 각각 한 줄 이유와 함께 묶어 "맞나요?" 합의 요청.
-  - 사용자가 전부 동의 → 일괄 마커 제거.
-  - 사용자가 일부 유지를 지목 (예: "3~5는 유지") → 지목된 항목은 마커 유지, 나머지만 제거.
-- 많음 → 즉시 일괄 제거 + 사용자에게 한 줄 보고 (제거된 §4/§5/§6 목록 포함). 유지 검토는 이후 그 §4/§5/§6 에 진입할 때 본문 재검토 단계에서 수행.
-
-### 6단계: 다음 단위 연속
-
-사이클 5단계 처리 후마다 자문 — "진입 단위가 완결됐는가? 남은 결정 대상은 무엇인가?"
-
-세션을 끝내거나 "새 세션에서 진행" 을 권하지 않음. 상위 행동 규칙 ("결정 대상 여러개 → 보고 직후 즉시 진행, 트리거 위임 금지") 적용 — 컨텍스트 한도는 자동 압축이 처리하므로 분량을 이유로 멈추지 않음.
-
-**다음 대상 선택** (위→아래 우선순위. 멈추지 말고 해당 사이클로 즉시 진입):
-
-1. **현재 사이클의 남은 초안 단위** — 진입한 §x.x 의 §별 초안 단위가 남아 있으면 다음 단위로 진입.
-2. **현재 묶음의 파생·의존 항목** — 방금 확정한 §x.x 에서 5단계로 도출된 곁가지 (신규 §4.x·관련 §5/§6 분할·구현 마커 제거 등). OPEN 메모로 남겨둔 것 포함 — 다음 세션으로 미루지 말고 그 §x.x 사이클로 즉시 진입.
-3. **독립적인 다음 큰 단위** — 위 1·2 가 모두 없을 때만. 현재 묶음과 무관한 새 작업 (다른 §2.x 프로세스·다음 최상위 [OPEN] 섹션 등).
-  - 우선순위 근거 (사용자 지시·의존 순서) 가 있으면 묻지 않고 그 단위로 진입.
-  - 근거가 없으면 다음 대상을 **인세션 옵션 질문** 으로 제시 (행동 규칙 "사용자 질의 시" 형식). "새 세션" 프레이밍·"골라서 진행" 위임 금지 — 답을 받으면 같은 세션에서 계속 진행.
-
-**사용자 입력 대기** (아래 중 하나일 때만 진행을 멈춤):
-- 모든 섹션이 `[확정]` 이고 본문 인라인 `[OPEN]` 도 없음 → 추가 요구 대기.
-- 남은 결정 대상이 전부 사용자 자료·결정을 기다리는 OPEN 게이트 (자료 부족·외부 의존) 라 에이전트가 더 진행할 수 없음 → 무엇이 필요한지 보고 후 대기.
-- 3번 경로에서 우선순위 근거가 없어 옵션 질문을 제시한 직후.
-
-옵션 질문 모범 (3번 경로, 우선순위 근거 없을 때):
-
-```
-§4.2 화면 본문 모든 초안 확정. 현재 묶음 파생 없음.
-
-다음 분석 명세 단위를 고르는 단계 (현재 묶음 외 독립 작업):
-
-옵션 1. §2.2 본문 — 다음 업무 프로세스 분석
-옵션 2. §7.2 신규 — 이번 작업 곁가지로 도출된 공통 규격
-
-추천: 1 — 분석 명세를 먼저 마치고 설계로 내려가는 큰 순서에 부합.
-```
+워크플로의 verify 단계는 위 원칙의 준수를 독립 컨텍스트에서 사후 검증(근거 좌표 1:1 대조·원자료↔spec 전수 누락 대조·요구목록 역대조·dangling 참조 grep). 사람 사후 검토(검토 패키지)가 최종 안전망.
 
 ## spec.md 형식
 
@@ -224,42 +100,30 @@ spec.md 의 § 별 섹션 이름과 분류:
 | §   | 섹션             | 분류                         |
 | --- | ---------------- | ---------------------------- |
 | §1  | 개요             | 분석 명세                    |
-| §2  | 업무 프로세스    | 분석 분할/명세               |
-| §3  | 기타 요구사항    | 분석 분할/명세               |
-| §4  | 화면             | 설계 분할/명세               |
-| §5  | 자동 처리        | 설계 분할/명세               |
-| §6  | 공통·기반 기능   | 설계 분할/명세               |
+| §2  | 업무 프로세스    | 분석                         |
+| §3  | 기타 요구사항    | 분석                         |
+| §4  | 화면             | 설계                         |
+| §5  | 자동 처리        | 설계                         |
+| §6  | 공통·기반 기능   | 설계                         |
 | §7  | 공통 정의        | 자연 도출 (다른 섹션 반영거리) |
 | §8  | 도메인 모델      | 자연 도출 (다른 섹션 반영거리) |
 | §9  | 외부 인터페이스  | 자연 도출 (다른 섹션 반영거리) |
 | §10 | 본문 외 확정 사항 | 메타 (결정이 발생할 때마다 누적)     |
 
-### 마커
+### 신뢰도 표기
 
-#### 헤더 마커 (섹션 상태)
+spec.md 본문에서 항목의 신뢰도를 나타내는 표기. 전부 날짜 없음 (§10 로그 타임스탬프 제외).
 
-섹션 헤더에 부착하는 마커:
+| 표기                | 의미                                                                                                       |
+| ------------------- | ---------------------------------------------------------------------------------------------------------- |
+| (무표기)            | 직접·자명, 또는 미검토 초안. 기본 상태.                                                                    |
+| 줄끝 `(근거: 출처)` | 자료에서 해석·도출한 **비자명** 항목의 근거 (예: `(근거: 회의록 L12)`). 사용자가 직접 말한 자명 항목엔 안 붙임. 위치 = 표는 비고 칸, 산문은 줄 끝. |
+| `[OPEN]`            | 근거 없음. 필요 시 추측·필요자료 메모 동반 (예: `[OPEN] 박스당 수량 — As-Is상 24 추정, 미확인`).            |
+| `[구현]`            | sd-impl 소관. sd-spec 은 존재만 인지, 부착·제거하지 않음.                                                  |
 
-| 마커                                   | 의미                                                                                                                                                                       |
-| -------------------------------------- | -------------------------------------------------------------------------------------------------------------------------------------------------------------------------- |
-| `[확정: YYYY-MM-DD]`                   | 섹션 확정. 본문에 인라인 `[OPEN]` 이 있어도 무방.                                                                                                                          |
-| `[OPEN: YYYY-MM-DD]`                   | 섹션 미확정 상태 (사용자가 보류했거나, 헤더 분할 직후 자동으로 부착). 본문 = 분석 방법. 초안 (BPMN·와이어프레임·항목 등) 은 채우지 않음.                                       |
-| `[확정: YYYY-MM-DD, 구현: YYYY-MM-DD]` | §4/§5/§6 에만 적용. `[확정]` 에 `구현: 날짜` 를 콤마로 결합. sd-impl 의 시연 검증 통과 시 부착. 본문이 변경되면 `, 구현: …` 부분만 제거 (구버전 구현 무효화). 운용 절차는 5단계의 "구현 마커 제거". |
-
-대괄호 쌍 연이은 표기(`[확정: …][구현: …]`) 는 마크다운이 reference-style 링크로 해석함 → 단일 대괄호 안에 콤마로 결합하는 형식 사용.
-
-#### 본문 인라인 마커
-
-본문 안에서 사용하는 인라인 마커:
-
-| 마커     | 의미                                      |
-| -------- | ----------------------------------------- |
-| `[OPEN]` | 정보 부족·근거 없는 항목. 향후 확정 필요. |
-
-- 임의로 채우거나 누락하지 말고 `[OPEN]` 으로 표기.
-- 근거 부족 판정 기준은 행동 규칙의 "결정 근거" 적용. As-Is 만 근거인 항목·답변 범위 흡수 등 안티패턴 자료는 근거 없음으로 보고 `[OPEN]` 으로 표기.
-- 헤더 `[확정]` + 본문 `[OPEN]` 조합은 OPEN 을 인정한 상태로 섹션을 확정. 이후에는 OPEN 항목만 처리.
-- 사용자에게 물을 때 선택지: `맞나요? [OPEN 상태로 확정 / 섹션 전체 보류 / OPEN 하나씩 해결]`.
+- `[OPEN]` 판정: 근거 부족(상위 행동 규칙 "결정 근거" 적용). As-Is 만 근거 / 추정 / 답변 범위 흡수 = 근거 없음 → `[OPEN]`.
+- `[확정]` 마커는 없음. 확정 여부는 사용자가 필요 시 직접 관리 (헤더에 `[확정: 날짜]`·`[OPEN: 날짜]` 등의 상태 마커를 붙이지 않음).
+- 예외: §10 "본문 외 확정 사항" 의 로그 항목은 순서 보존용 날짜를 유지(`- YYYY-MM-DD: ...`). 이건 신뢰도 마커가 아니라 로그 타임스탬프.
 
 ### 본문 내 참조 (이름 기반)
 
@@ -268,9 +132,9 @@ spec.md 의 § 별 섹션 이름과 분류:
 예:
 - `[모델.재고]`·`[모델.박스.수량]`·`[모델.박스.품목.코드]`.
 - `[화면.재고 확인]`·`[프로세스.입고]`·`[기타.과거 재고 조회]`.
-- `[자동 처리.재고 스냅샷]`·`[기반.DataLog 기록]`·`[외부인터페이스.ERP 입고 통보]`·`[공통 정의.Location 라벨]`.
+- `[자동 처리.재고 스냅샷]`·`[기반.DataLog 기록]`·`[외부 인터페이스.ERP 입고 통보]`·`[공통 정의.Location 라벨]`.
 
-**관련 섹션 한 줄**: §2~§9 본문에 `관련 섹션: [카테고리.이름], ...` 형식의 한 줄로 참조·의존 섹션을 콤마로 나열 (카테고리 제한 없음). **초안 단위가 아님** — 다른 sub-section 작성 시 곁가지로 자동 누적.
+**관련 섹션 한 줄**: §2~§9 본문에 `관련 섹션: [카테고리.이름], ...` 형식의 한 줄로 참조·의존 섹션을 콤마로 나열 (카테고리 제한 없음). 별도 작성 단위가 아님 — 다른 sub-section 작성 시 곁가지로 자동 누적.
 
 ### sub-section 헤더 레벨
 
@@ -288,480 +152,27 @@ spec.md 의 § 별 섹션 이름과 분류:
 
 ### 진행 방법 누적
 
-사이클 중 사용자와 진행 방식을 합의하면 (예: "시트별로 분석", "시트별 분석 = 6단계 답습") 즉시 누적. 적용 범위에 따라 2 경로:
+작업 중 사용자와 진행 방식을 합의하면 (예: "시트별로 분석") 즉시 누적. 적용 범위에 따라 2 경로:
 
 **spec 전체에 적용되는 경우** → §10 의 진행 방법 항목으로 누적 (`- YYYY-MM-DD: ...` bullet 형식).
 
 **분석 단위 한정** (§X.Y 또는 그 내부의 sub-section/sub-단위) → 해당 단위 도입부에 NOTE blockquote 작성:
 - 형식: `> **NOTE** (진행 방법): <한 줄 요약>` blockquote + 다단 (`> 1. ...`·`> 2. ...` 형식).
-- 분석 단위 헤더가 `[OPEN]` 상태면 본 NOTE 가 다른 대화 재진입 시 진행 룰 회복의 출처가 됨.
-- 본 단위의 모든 sub-단위 합의 후 `[확정]` 환원 시, NOTE 는 유지 (진행 이력 기록 보존) 하거나 제거 (분석 단위에만 적용되었던 룰이므로) 가능.
-
-별도의 "맞나요?" 합의는 진행하지 않음 (사용자 발언을 직접 기록하는 행위이므로).
-
-## §1 개요
-
-**초안 단위**: §1.1·§1.2·§1.3·§1.4 가 각각 1건씩 총 4건. 단, §1.4 는 ASCII 구성도 1건 + 장치 목록 1건으로 총 2건.
-
-**모범**: example-spec.md §1.1~§1.4.
-
-### §1.1 핵심 목적
-
-- 한 줄 동사형의 큰 단위로 작성.
-- 분석 분할 단계의 도메인 관계도를 기반으로 사이클·관계를 표현.
-- §2.x 의 동사구 항목 나열 금지 (해당 표현은 §1.2 의 역할).
-
-### §1.2 주요 목표
-
-- 단위: 최종 사용자의 업무 흐름 1건 (화면·기능 단위가 아님).
-- 표현: 한 줄 동사구. 최종 사용자 도메인 어휘 사용.
-- §2 업무 프로세스 헤더와 1:1 매핑되는 것이 일반적.
-- §2.x 본문의 핵심 항목은 한 줄에 모두 담아야 하며, 임의 축약·누락 금지.
-
-### §1.3 최종 사용자/이해관계자
-
-- 실제 담당자의 이름 사용 금지.
-- 역할로 일반화하여 표현.
-
-### §1.4 환경/장치
-
-분석 단계에서 초안을 합의한 뒤, 설계 단계 진행 중에도 보강 가능 (5단계의 다른 섹션 반영거리 절차).
-
-구성도와 장치 목록은 목적이 별개이므로 각각 독립적으로 작성.
-
-- **ASCII 구성도**: 현장 물리 구성 시각화 — 이해당사자 간 그림 맞추기.
-  - 포함 대상: 솔루션 노드 (서버·DB·클라이언트) + 노드 간 연결선 + 물리 위치 그룹 (IDC·사무실·창고) + 자동 연동되는 외부 시스템.
-  - 제외 대상: Actor, 외부 관계자 (인적·조직), 수동 채널 (메일·종이), 구체 제품명 (MySQL)·통신 프로토콜 (HTTPS), 장치 사양 (OS·해상도).
-- **장치 목록**: 솔루션이 대상으로 하는 장치·환경 스펙 — 서버·DB·클라이언트 등. OS·버전·제품명·모델·해상도·하드웨어.
-  - 명시한 스펙에 맞게 개발하며, 그 외 스펙 환경에서의 동작은 책임 범위 외.
-
-## §2 업무 프로세스
-
-**초안 단위**: §2.x 1개당 위→아래 순서로 1건씩 진행:
-1. BPMN (사용자에게 보여줄 때는 ASCII, 확정 후 mermaid 형식으로 저장).
-2. 흐름 설명 bullet.
-
-**모범**: example-spec.md §2.1.
-
-### 분할 단위 = BPMN end-to-end process
-
-§2.x 1건 = BPMN end-to-end process 1건 (= Value Stream L1). start event ~ end event 의 풀 사이클. 사이클 내부의 handoff (역할 전환·시간 지연·외부 채널·동일인의 다른 시점) 도 포함 — BPMN swim lane 또는 노드 분기로 표현. **handoff 는 §2.x 분리 사유가 아님**.
-
-- **start event** (BPMN 시작 트리거):
-  - Message — 외부 actor 의 메시지·자료가 도착 (구매처 발주·고객 주문·거래처 EDI).
-  - Timer — 시간이 도래 (세무 신고일·정산 마감일).
-  - Signal — 외부 조건 신호.
-- **end event** (BPMN 종결 outcome):
-  - 외부 가치 전달 또는 외부 자료 송신 (출하 완료·세금 제출·EDI 송신).
-- **분리 기준 = pivotal event** (Event Storming 의 pivotal event 개념):
-  1. start event 가 별개 (입고 start ↔ 출고 start).
-  2. end event 가 별개.
-  3. 도메인 어휘 자체의 전환점 (DDD 경계).
-
-### 분할 절차 (분석 분할 단계)
-
-분석 분할 단계에서 §2/§3 분할을 동시에 진행. 절차는 4단계.
-
-1. **domain event 추출** (Event Storming 의 "chaotic events" 단계) — Requirement Source 에서 동사 과거형 사건을 모두 평면적으로 추출. 원본 구조 (메일·슬라이드·문서) 와는 무관.
-2. **timeline 정렬** (Event Storming 의 "Enforce timeline" 단계) — 비즈니스 시간 순으로 정렬. 시점이 모호한 항목은 인접 후보로 보류.
-3. **pivotal event 식별** — start/end/도메인 어휘 전환점을 마킹. 외부 관계자 평면 (구매처·공급처·고객·하청·감독기관) 이 이 단계에서 자연스럽게 도출됨 — 이 결과가 §1 작성용 도메인 관계도 자료가 됨.
-4. **bounded subdomain 그룹화** — 한 pivotal trigger ~ 다음 pivotal outcome 까지가 1 사이클. 사이클 내부의 handoff 도 포함.
-
-#### 분할 결과 매핑 (분석 분할 출력)
-
-3가지로 분류:
-- **사이클** (multi-event handoff 포함) → §2.x.
-- **단일 user goal 완결** → §3.x.
-- **사이클도 user goal 단위도 아닌 것** (도메인 룰·계산식·기존 화면 미세 변경·자료 해석 파라미터·기타 규칙) → **미분류**.
-
-#### 분석 분할 채팅 출력 형식
-
-- 3가지 분류를 일괄 나열 (§2 / §3 / 미분류).
-- 자문·내부 절차 해설·출처 인용은 출력에 포함 금지.
-- 화면·마스터를 포함한 들여쓰기 표기 금지 (들여쓰기는 설계 분할 단계의 시야이므로).
-- 자료가 부족하여 분리해야 하는 항목은 별도 질문으로 함께 제시.
-- 사이클 2단계의 "스스로 검증 게이트" 중 출처 항목 적용 — 인용이 불가능한 항목은 후보에서 빼고 별도 질문으로 분리.
-
-### 헤더 명칭
-
-- 외부 관계자 평면 기반의 도메인 업무 동사구 사용.
-- 시스템·문서·메뉴·양식의 명칭을 그대로 사용 금지.
-  - ❌ `발주서 변경 요청` (발주서 = 시스템 문서).
-  - ✅ `구매처 발주 변경 요청`.
-
-### 본문 구조
-
-sub-section 헤더 레벨은 `## spec.md 형식` 의 "sub-section 헤더 레벨" 표 참조.
-
-**평문 sub-section** (§2.x 헤더 바로 아래에 위→아래 순서로 작성):
-
-- **BPMN** (mermaid fence):
-  - 사용자에게 보여줄 때는 ASCII, 확정 후 mermaid 형식으로 저장.
-  - 노드 = 최종 사용자 액션 또는 시스템 핵심 트랜잭션 (1행 동사구). 줄바꿈 `<br/>` 사용 금지.
-  - Actor·장치·매체 (PDA·PC·종이) 는 액션 컨텍스트로 노드 안에 명시 허용 (예: `창고 작업자: PDA 박스 바코드 스캔`). OS·해상도·API·DB 등 시스템 내부 디테일은 제외.
-  - 외부 채널 송신 (메일·파일 다운로드) 과 외부 응답 수신 (다음 사이클 자료 도착) 도 노드로 표현. 처리 노드는 사각 (`T[...]`), 이벤트 노드는 둥근 (`E([...])`).
-  - 분기는 사용자의 의사결정 분기만 표현.
-- **흐름 설명 bullet** (BPMN 아래, 관련 섹션 위에 자유롭게 나열):
-  - 노드 동사구만으로는 표현되지 않는 룰·조건·계산식·외부 약속·자료 출처 인용 등을 한 줄씩 기재.
-  - §4/§5/§6 본문 작성 시 이 bullet 들을 근거로 매핑하여 누락 방지.
-  - 단, §4/§5/§6 자체의 디테일 (필드·UI·파일 확장자) 과 §7/§8/§9 의 정형 명세는 여기에 작성 금지 — 각 § 본문에서는 이름으로만 참조.
-- **관련 섹션** (`관련 섹션: [카테고리.이름], ...` 형식의 한 줄, 자동 누적): "본문 내 참조" 절의 룰 따름.
-
-### 안티패턴 (분할)
-
-- ❌ 같은 사이클의 A→B→C 단계별로 담당자·산출물이 다르다는 이유로 §2.A·§2.B·§2.C 로 쪼개는 행위.
-- ❌ 메뉴 그룹·기존 화면 폴더·코드 As-Is 구조를 기준으로 묶거나 쪼개는 행위.
-
-## §3 기타 요구사항
-
-**초안 단위**: §3.x 1개당 본문이 짧으면 전체를 1건으로. 본문이 길어지면 "요구 의도" 와 "관련 섹션" 으로 분리하여 별건으로 진행.
-
-**모범**: example-spec.md §3.1.
-
-### 분할 단위 = Cockburn sea level use case
-
-- Cockburn 의 정의: "primary actor go away happy after having done this in a single sitting?".
-- 행위자가 1회 작업으로 끝내고 만족하여 떠나는 단일 user goal.
-- 사이클·handoff·지연이 없음.
-- 정형 분해 (화면 / 자동 처리 / 공통·기반 기능) 를 동반하는, 사용자의 직접 요구.
-- 시스템 전반 자동 룰 (예: "모든 데이터 수정 시 변경 이력 기록") 과 프레임워크 운영 기반 (앱 구조·접근 권한·부트스트랩 등) 도 §3 에 포함 — 그에 대한 설계는 §6 공통·기반 기능에서 수행.
-
-### 본문 구조
-
-- 요구 의도 (한 줄 또는 한 문단).
-- 관련 섹션 한 줄 ("본문 내 참조" 절 룰 따름).
-- 구현 디테일은 §4 화면 / §5 자동 처리 / §6 공통·기반 기능 본문에 작성.
-
-## §4 화면
-
-**초안 단위**: §4.x 1개당 "§4.x 표준 구조" 절의 단위로 위→아래 순서로 진행. 각 단위 확정 후 다음 단위로 이동:
-1. 기능 개요 — 1건.
-2. 와이어프레임 — 1건.
-3. 항목 — 다단으로 분할:
-  - 1차 분할: 영역 (좌/우 등) 단위 — 와이어프레임의 영역 라벨 기준.
-  - 2차 분할: 영역 내부의 하위 요소 (필터·시트 컬럼·입력 폼·상세 폼) 단위.
-  - 초안 1건 = (영역, 하위 요소) 쌍 1건 — 예: `좌측 영역 — 필터` 1건, `좌측 영역 — 시트 컬럼` 은 별건.
-4. 동작 — 1건.
-5. 시각 규칙 (해당 시) — 1건.
-6. 도메인 규칙·로직 (해당 시) — 규칙별 1건.
-7. 자유 추가 sub-section (해당 시) — sub-section 별 1건 (예: 업로드 양식·다운로드 양식 각각 별건). 복잡 양식 내부의 sub-단위 (시트 등) 는 sub-단위별 1건.
-
-(헤더 인덱스 = Actor + 관련 섹션 으로 구성되며, 둘 다 자동 누적 — 초안 단위가 아님).
-
-신규 작성·정정·골격 신설 어느 경우든 동일하게 적용.
-
-**모범** (와이어 패턴별):
-- 시트 화면: example-spec.md §4.1·§4.3.
-- 폼 모달: §4.2·§4.4.
-- PDA: §4.5.
-- 분석 시트: §4.6.
-
-### 설계 분할 절차 (§4/§5/§6 공통)
-
-설계 분할 단계에서 §4/§5/§6 헤더를 §2/§3 본문 (+ §8 마스터 엔티티) 에서 도출. 절차:
-
-1. **§4 화면 도출**:
-  - §2 BPMN 의 최종 사용자 액션 노드 + §3 의 사용자 직접 요구 → 트랜잭션 화면 또는 조회 화면.
-  - §8 의 마스터 엔티티 → 마스터 화면.
-  - 도메인 묶음 또는 장치별로 그룹화 → 화면 목록 표.
-2. **§5 자동 처리 도출** — §2/§3 의 시스템 백그라운드 처리 (스케줄·이벤트 트리거·외부 자료 수집·적재) 를 추출.
-3. **§6 공통·기반 기능 도출** — §4 화면·§5 자동 처리에 속하지 않는 모든 개발 단위를 추출: 부수효과로 발동되는 동작 + 앱 전역 정적 골격(앱 구조[메뉴·권한·모듈]·로깅·부트스트랩 초기화). §3 의 "시스템 기반" 류 요구가 주 도출원. 프레임워크 기본 기능(매뉴얼 존재)은 매뉴얼 참조로, 앱 고유 부수효과는 인라인으로 명세.
-
-각 § 헤더 분할 직후 자동 OPEN 상태가 됨 (4단계의 "보류 발생 경로" 참조).
-
-### 화면 목록 표 (§4 첫머리)
-
-5컬럼 구조: `§ | 분류 | 화면 | 유형 | 장치`.
-
-- 분류: 도메인 묶음·메뉴 그룹의 자유 명칭 (예: `기준정보`·`입고`·`재고`). LLM 이 초안을 제시 후 사용자와 확정.
-- 유형: 마스터 / 트랜잭션 / 조회 중 택1.
-- 장치: PC / PDA / 기타 중 택1.
-- 화면이 추가·제거되면 표도 함께 갱신. 같은 분류끼리 인접 배치.
-
-### 화면 정의 (§4.x 표준 구조)
-
-화면 헤더에 (장치) 표기를 유지: `### N.N 화면명 (PC) [확정: 날짜]` 또는 `(PDA)`.
-
-sub-section 헤더 레벨은 `## spec.md 형식` 의 "sub-section 헤더 레벨" 표 참조.
-
-**평문 sub-section** (§4.x 헤더 바로 아래에 위→아래 순서로 작성):
-
-- **헤더 인덱스** (한 줄씩 작성, 자동 누적 — 초안 단위가 아님):
-  - `Actor: <역할>` — §2 BPMN 의 swim lane 또는 §3 의 사용자 직접 요구에서 자연 도출.
-  - `관련 섹션:` "본문 내 참조" 절 룰 따름 — 모달 호출·시트 영역 재활용 등 화면 간 의존 포함.
-- **기능 개요**: `기능 개요:` 라벨 다음에 bullet 로 화면 기능을 설명.
-
-**h4 sub-section** (평문 아래, 고정 순서, 위→아래):
-
-#### 와이어프레임 (텍스트)
-
-**형식 일탈 금지**:
-- example-spec.md 의 가장 가까운 화면 패턴 라인을 형식 모범으로 직접 참조 — 시트 형식은 §4.1·§4.3 / 폼 모달은 §4.2·§4.4 / PDA 는 §4.5 / 분석 시트는 §4.6.
-- ASCII 박스 (┌─┐ │ └┘) ·영역 추상화 표기 (`<필터>`·`<시트>`·`<폼>` 등) ·액션 버튼 텍스트 표기를 임의로 변형 금지.
-
-**원칙**: 영역 배치·구획만 표현. 디테일 (필드·시트 컬럼·실제 값·아이콘 placeholder·fixed 경계·비활성 행 등 시각 표현) 은 와이어에 두지 않음 — 항목 표·동작 절·도메인 규칙 절이 단일 출처.
-
-- 데이터 영역: 영역 타입 + 짧은 라벨로 추상화 — `<필터>`·`<폼>`·`<시트>`·`<목록>`·`<PO 목록>`·`<라인 시트 - 작성영역>` 등. 영역 종류가 한눈에 잡히지 않으면 라벨을 보강.
-- 액션 버튼: 텍스트를 유지 (`[조회]`·`[저장]`·`[등록]`) — 버튼 위치 자체가 와이어가 전달하는 정보. 아이콘만 있는 버튼도 텍스트로 표기.
-- 영역 (좌/우 분할·탭·상단 command 바·시트 상단 버튼바) 으로 나뉠 경우 박스 라인으로 구획.
-- 상태 (작성중·확정 등) 에 따라 영역 구획이 크게 달라지면 상태별로 분리. 제목 형식: `와이어프레임 (<상태명>):` (예: `와이어프레임 (확정 전):`).
-
-#### 항목
-
-데이터 항목만 작성 (필터·시트 컬럼·입력 폼·상세 폼). 액션 버튼은 "동작" 절에 작성.
-
-- **표 제목 = 와이어의 영역 라벨과 동일 명칭** 을 굵게 표기 — 와이어의 `<필터>` → `**필터**`, `<품목 목록 시트>` → `**품목 목록 시트**`, `<스캔 입력 폼>` → `**스캔 입력 폼**`.
-- 한 영역에 종류가 다른 표가 여러 개 있을 경우 종류를 부기 — `**<영역 라벨> — <필터|시트 컬럼|입력 폼>**` (예: `**헤더 목록 — 필터**`, `**BOA 시트 — 시트 컬럼**`).
-- 시트 화면의 기본 구성: 상단 command 바의 `<필터>` + 시트 영역 (시트 컬럼) 총 2 그룹.
-
-**표 형식** — 도메인 매핑은 별도 컬럼으로 (필터는 시트 컬럼과 중복되므로 도메인 매핑 컬럼 없음):
-- 입력 폼: `항목 | 종류 | 필수 | 도메인 매핑 | 비고`.
-- 시트 컬럼: `컬럼 | 종류 | 필수 | 도메인 매핑 | 비고`.
-- 필터: `항목 | 종류 | 필수 | 비고`.
-
-- 필수 컬럼: 의미가 없는 경우 (조회 시트 컬럼 등) 는 `-`.
-- 도메인 매핑: `[모델.X.Y]` 형식 (양식 매핑과 일관). 매핑이 없는 항목 (선택 체크박스 등) 은 `-`.
-- 비고: 표시 내용 (이름과 도메인만으로 자명하지 않을 때 어떤 값이 표시되는지) / 편집 방법 (편집 가능 항목 — 예: 클릭 시 모달, 인라인 편집) / 기타 자유 설명.
-
-**시트 컬럼 그룹핑** (해당 시): 컬럼들이 도메인적으로 묶일 경우 표 안에 그룹 표시.
-- 그룹 헤더 행을 1줄 (`**그룹명**` 표시, 다른 셀은 빈 칸).
-- 자식 컬럼은 `└ ` 들여쓰기 prefix 부착.
-- 표의 컬럼 수는 유지.
-
-#### 동작
-
-bullet 을 `- <트리거>: 처리 내용` 형식으로 작성.
-
-- 트리거 예시: `` `[버튼]` 클릭 ``, `박스 바코드 스캔`, `Enter 키`.
-- 처리 내용: 동사구 + 대상 (예: `[화면.X] 을 모달로 띄움`, `검색 필터 조건으로 목록 갱신`).
-
-#### 시각 규칙 (해당 시)
-
-행 단위·조건부 시각 표현 (비활성 행 취소선·상태별 강조 색·아이콘 등) 을 작성. 컬럼 단위 표현은 항목 표의 비고에 작성하므로 여기에는 작성하지 않음.
-
-#### 도메인 규칙·로직 (해당 시)
-
-표준 sub-section 으로 담기지 않는, 화면 고유의 도메인 요구를 작성. 자유 명칭의 절을 필요한 만큼 추가. 누락 없이 적는 것이 핵심.
-
-**자유 추가 sub-section** (`#### 도메인 규칙·로직` 아래, 화면별 필요 시 h4 자유 추가):
-
-- **양식 입출력** (예: `#### 업로드 양식`·`#### 다운로드 양식`) — 양식별로 별도 sub-section 작성.
-  - 단순 양식: 내부에 단순 표 — 컬럼은 `파일 컬럼` + `도메인 모델 ([모델.X.Y])` + `변환·규칙 (해당 시)`. §7.x 에 명세된 양식이면 컬럼명을 일치시키고, 일회성 양식이면 sub-section 내부에서 직접 명세.
-  - 복잡 양식 (다중 시트·구조 분할): 내부의 sub-단위 (시트 등) 는 h5 (`##### <시트>` 등) 로 작성. sub-단위 내부에 진행 방법 NOTE 작성 가능 (`## spec.md 형식` 의 "진행 방법 누적" 절 참조).
-- **기타 화면 고유 정보** — sub-section 이름은 자유. 표준 sub-section 으로 담기지 않는 화면 고유 정보의 누락 방지 목적.
-
-### 마스터 화면 표준
-
-화면 목록 표에서 유형이 "마스터" 인 §4.x 에 적용. 화면 정의 sub-header (와이어프레임·항목·동작) 와 함께 작성.
-
-- ID 컬럼은 편집 버튼 (`[E N]`) 으로 표현.
-- 첫 컬럼은 선택 체크박스 (`[ ]`).
-- 시트 상단 버튼바: `[등록] [선택 삭제] [선택 복구] [엑셀 업로드] [엑셀 다운로드]`.
-- ID 정렬은 역방향 (내림차순).
-
-### 상단 command 바
-
-화면 정의 sub-header 의 와이어프레임·동작과 함께 작성. 페이지 제목 바로 아래, 시트·폼 영역 위에 배치. 페이지 전체 또는 현재 레코드 단위의 액션 바.
-
-- 좌측: 필터 입력 + 조회 (list 화면) / 진입 컨텍스트 표시 (detail 화면).
-- 우측: 페이지 단위·레코드 단위 액션 (있는 경우에만).
-- 좌·우 사이에 ` │ ` 세로 구분선.
-
-**우측 버튼 그룹 순서** (좌→우):
-1. 기본 CRUD (저장 / 삭제 / 복구).
-2. 워크플로 상태 전환 (확정 / 취소 / 승인 / 반려).
-3. 유틸리티 (원본 다운로드 / 프린트 / PDF).
-
-list 화면과 detail 화면 모두 동일. 새 버튼은 해당 그룹의 끝에 추가. 시트 상단 버튼바도 동일한 그룹 순서를 따름 (마스터 화면 표준은 그 구체 인스턴스).
-
-### 모달 처리
-
-호출하는 쪽 §4.x 의 동작 sub-header 와 호출되는 쪽 §4.x 양쪽 모두에 적용.
-
-- 모달 화면도 별도의 §4.x. 호출하는 쪽의 동작에 "→ [화면.X] 을 모달로 띄움" 을 명시.
-- 화면명에 "(모달)" 등의 사용 맥락 표기 금지 — 같은 화면이 다른 곳에서는 다른 방식으로 호출될 수 있음.
-- 화면의 일부 영역 (시트·탭) 이 다른 화면에서 모달로 재활용되는 경우, 별도 §4.x 로 분리하지 않음. 대신 그 화면의 동작 절 끝에 "영역별로 모달 호출 시 제약" (편집 가능 여부 / 선택 전용 / multiselect) 을 한 줄씩 명시. 호출하는 쪽의 동작은 "→ [화면.X] 의 <영역> 을 모달로 띄움" 으로 표기.
-
-## §5 자동 처리
-
-**초안 단위**: §5.x 1개당 위→아래 순서로 1건씩:
-1. 목적 / 트리거 (한 묶음).
-2. 처리.
-3. 예외 처리.
-4. 자유 추가 sub-section (해당 시) — sub-section 별 1건 (예: 읽기 양식·쓰기 양식 각각 별건). 복잡 양식 내부의 sub-단위 (시트 등) 는 sub-단위별 1건.
-
-**모범**: example-spec.md §5.1.
-
-### 정의
-
-스케줄러 또는 이벤트 트리거로 동작하는 시스템 백그라운드 처리. 표준 프로토콜·채널을 통한 외부 자료 수집·적재 (메일 폴링 + 첨부 적재, FTP 자료 수집 등) 도 §5 에 포함 — 시스템별 협상이 필요 없는 표준 인터페이싱은 §9 가 아님.
-
-§6 공통·기반 기능과의 차이: §5 = 스케줄·이벤트로 명시적인 트리거가 있음. §6 = 명시적 트리거가 없는 것 (부수효과로 발동되거나 전역에 상시 구성되는 것).
-
-### 본문 구조
-
-sub-section 헤더 레벨은 `## spec.md 형식` 의 "sub-section 헤더 레벨" 표 참조.
-
-**평문 sub-section** (§5.x 헤더 바로 아래에 "라벨 + 본문" 형식으로 작성):
-
-- `목적:` 도메인 목적을 한 줄로.
-- `트리거:` 스케줄·이벤트 명시.
-- `관련 섹션:` "본문 내 참조" 절 룰 따름.
-
-**h4 sub-section** (평문 아래에 고정 순서로 위→아래 작성):
-
-#### 처리
-
-처리 단계 작성.
-
-#### 예외 처리
-
-실패 케이스별 위험·대처·재시도 한계 작성.
-
-**자유 추가 sub-section** (`#### 예외 처리` 아래에, §5.x 별로 필요 시 h4 자유 추가):
-
-- **양식 입출력** (예: `#### 읽기 양식`·`#### 쓰기 양식`) — §4 의 "양식 입출력" sub-section 룰과 동일. 방향은 읽기·쓰기. 일회성 양식이면 sub-section 안에서 직접 명세.
-- **기타 자동 처리 고유 정보** — sub-section 이름은 자유.
-
-## §6 공통·기반 기능
-
-화면(§4)도 명시적 트리거 자동 처리(§5)도 아닌, 시스템을 떠받치는 공통·기반 개발 단위 전부 (캐치올). §4·§5 에 속하지 않는 개발 entry 는 전부 여기로 모임 — 갈 곳 없는 항목을 §7(공통 정의) 등 명세 섹션으로 올리지 말 것.
-
-포괄 대상 (두 성격이 한 섹션에 섞임. 항목을 어느 한쪽으로 미리 분류하지 않음 — 애매하거나 두 성격을 겸하는 항목도 그대로 수용):
-- 부수효과로 발동되는 동작 — DataLog 기록·권한 체크·캐시 무효화·알림 발송·감사 로그.
-- 전역에 상시 구성되는 정적 골격 — 앱 구조(메뉴·권한·모듈)·로깅 정책·부트스트랩 초기화.
-
-**초안 단위**: §6.x 1개당 위→아래 순서로 1건씩:
-1. 목적 / 트리거·적용 범위 (한 묶음).
-2. 참조 매뉴얼 (프레임워크 기본 기능) 또는 본문 자유 서술 (bespoke) — 1건.
-3. 자유 추가 sub-section (bespoke 가 실제로 요구할 때만) — sub-section 별 1건.
-
-**모범**: example-spec.md §6.1·§6.2.
-
-### 정의
-
-§4 화면·§5 자동 처리에 속하지 않는 모든 개발 단위. §3 기타 요구사항의 시스템 전반 자동 룰을 설계 차원에서 풀이하는 것도 포함. 부수효과로 발동되는 동작과 전역 상시 골격을 모두 포괄하되, 두 성격이 한 항목에 섞일 수 있으므로 미리 가르지 않음.
-
-§5 자동 처리와의 차이: §5 = 스케줄·이벤트로 명시적 트리거 (예: 매일 자정·메일 도착). §6 = 명시적 트리거가 없는 것 — 부수효과로 발동되거나 전역에 상시 존재.
-
-### 본문 구조
-
-§6 은 항목 성격이 제각각인 캐치올이라 §4/§5 같은 고정 sub-section 구조가 없음. 항목은 두 갈래로 작성:
-
-- **프레임워크 기본 기능** (앱 구조·로깅·부트스트랩·데이터 변경 이력 등 — 매뉴얼이 존재) → 매뉴얼 참조 stub. 평문 라벨 + `참조 매뉴얼:` 한 줄. 처리·구성·예외 detail 은 매뉴얼로 위임하고 spec 에 적지 않음.
-- **bespoke** (앱 고유 부수효과 — 매뉴얼 없음) → 평문 라벨 + 본문 한두 줄 자유 서술.
-
-sub-section 헤더 레벨은 `## spec.md 형식` 의 "sub-section 헤더 레벨" 표 참조.
-
-**평문 sub-section** (§6.x 헤더 바로 아래에 "라벨 + 본문" 형식, 위→아래):
-
-- `목적:` 도메인 목적 (필수).
-- `트리거·적용 범위:` (해당 시) 어떤 동작의 부수로 발동되는지 / 어디에 상시 적용되는지 + 적용 시점. (예: "모든 엔티티 update 시 / 전체", "앱 부팅 시 / 전체 클라이언트").
-- `관련 섹션:` "본문 내 참조" 절 룰 따름.
-- `참조 매뉴얼:` (프레임워크 기본 기능인 경우) 구현 매뉴얼 파일명 (`.claude/references/sd-simplysm14/manuals/` 기준). 이 줄이 있으면 처리·구성·예외 detail 은 적지 않음.
-
-**본문** (bespoke 항목만, 평문 아래에 작성):
-
-- 설계 내용을 한두 줄로 자유 서술 — 설계 고도까지만 (구현 디테일은 sd-impl).
-- 처리 절차·모델 매핑·예외 처리 같은 고정 sub-section 은 두지 않음. 양식·매핑 등 정말 필요한 정보만 h4 자유 추가 (이름 자유).
-
-## §7 공통 정의
-
-작성 중 자연스럽게 도출됨 (5단계의 "다른 섹션 반영거리" 절차). 새로운 도메인 어휘·시스템 규격을 발견하면 사이클 진입.
-
-**모범**: example-spec.md §7.1~§7.4.
-
-### §7.1 용어 사전 (고정)
-
-도메인 어휘·약어·시스템 내 의미를 정의.
-
-### §7.2~ 기타 공통 규격
-
-시스템 전반 규격 (바코드 형식·라벨·공통 정책 등) 작성.
-
-특정 §2/§3 본문 단계에서 자연스럽게 포함되는 규칙 (업로드 자료 컬럼 매핑·자료 해석 규칙 등) 은 §7 에 두지 않음 → 사용처 본문에 둠.
-
-### 외부 자료 명세
-
-§7 의 외부 자료 = **시스템 외부에서 정의되어 도메인 모델로 자명하지 않은** 자료 (예: 외부 시스템 송신 파일, 거래처 표준 양식, 정해진 외부 규격). 도메인 모델의 자체 엑셀 업로드·다운로드 양식은 §7 가 아님 — §8 도메인 모델 + §4/§5/§6 의 양식 매핑으로 자명.
-
-자료별로 표가 필수. 외부 자료의 모든 컬럼·필드를 1행 1정의로 작성 (자료 자체의 객관 명세).
-
-**자료-레벨 메타** (송신 측·자료 라이프사이클·갱신 주기·식별 키 구조 등 자료 *전체* 에 적용되는 객관 명세):
-- 근거가 있을 때만 컬럼 표 위에 자유 작성 (불릿·단락·`라벨: 값` 형식 모두 허용).
-- 컬럼 표 안에 억지로 담지 않음.
-
-**컬럼 표**:
-- 외부 자료가 여러 개 (`SAP.XML`·`D1.CSV` 등) 이면 자료별로 별도의 표 작성.
-- 컬럼 구성은 자료 성격에 따라 LLM 이 초안 제시 후 사용자와 확정. 예: `컬럼명/식별자 | 필수/선택 | 설명/규칙`.
-- 모든 컬럼에 대한 행을 유지.
-- "설명/규칙" 류 컬럼에는 **그 컬럼이 무엇인지** (데이터 정의: 형식·값 범위·의미·제약) 만 작성. **용도** (어디에 어떻게 쓰이는지) 는 작성 금지 — 용도·매핑은 사용처 (§4/§5/§6 의 양식 매핑) 에서 작성.
-- 각 셀 값은 근거로 채택 가능한 자료가 있을 때만 작성. 추정·임의 작성 금지.
-- "원본 따름"·"전체 명세는 X.xlsx 참조" 등 외부 참조로 본문 정의를 대체 금지.
-- 원본 자료에 LLM 이 접근 불가하거나 누락·모호 → 임의 처리 금지. 사용자에게 자료 또는 명세 정보 요청.
-
-## §8 도메인 모델
-
-작성 중 자연스럽게 도출됨. 새로운 엔티티를 발견하면 사이클 진입.
-
-**모범**: example-spec.md §8.1~§8.6.
-
-섹션 구조: `필드:` 표 + `키/제약:` 불릿.
-
-### 필드 표
-
-컬럼 구성: `필드 | 타입 | 필수 | 비고`.
-
-- 비고에는 **그 필드가 무엇인지** (데이터 정의: 형식·값 범위·의미·제약·예시) 만 작성. **용도·출처·외부 양식·외부 시스템과의 매핑** 은 작성 금지 — §4/§5/§6 의 양식 매핑·모델 매핑 / §9 의 자료 매핑에서 작성.
-
-### 키/제약 불릿
-
-- **식별 키**: 모든 엔티티에 `ID` 필드 (숫자, 자동 부여) 를 명시.
-- **비즈니스 키** (코드 등): 별도로 명시. 수정 가능 (PK 가 아님).
-- **활성/비활성 boolean** = 소프트 삭제 플래그. 마스터에는 완전 삭제가 없음. UI 의 "삭제/복구" 액션과 매핑됨 → §7.1 용어 사전에 한 줄로 명문화.
-
-## §9 외부 인터페이스
-
-**초안 단위** (한 §9.x 당 2회 진행):
-1. 기본 정보 + 자료 매핑 → "맞나요?" 합의.
-2. 예외 처리 → "맞나요?" 합의.
-
-작성 중 자연스럽게 도출됨. 외부 시스템 호출을 발견하면 사이클 진입.
-
-**모범**: example-spec.md §9.1.
-
-### 정의
-
-§9 = 상대 시스템 고유의 인터페이스 약속 (시스템마다 자료 매핑·방식이 달라 협상이 필요한 것).
-
-- 포함 예시: 상대 ERP·거래처가 자체 정의한 API·EDI 규격, 외부 시스템의 webhook 페이로드.
-- 제외 예시: 표준 프로토콜·채널 (메일 SMTP·IMAP·Exchange·Graph, FTP, 표준 OAuth 등). 시스템별 협상이 없음 → §5 자동 처리에서 트리거·처리·양식 매핑으로 처리.
-
-### 디테일 범위
-
-도메인 약속 레벨까지만 작성. 구체 endpoint URL·HTTP method·query 파라미터·인증 흐름 단계 (grant_type·scope·token endpoint 등) ·SDK 메소드명 등 구현 디테일은 제외 — 구현 단계에서 처리. (§2 BPMN·§4 와이어·§8 도메인 모델과 동일한 원칙).
-
-### 본문 구조
-
-sub-section 헤더 레벨은 `## spec.md 형식` 의 "sub-section 헤더 레벨" 표 참조.
-
-**평문 sub-section** (§9.x 헤더 바로 아래에 위→아래 순서로 작성):
-
-- **기본 정보** (라벨 bullet 3건):
-  - `상대 시스템: <시스템명>`.
-  - `방향: <방향 표기>`.
-  - `전송 방식: <방식>`.
-- **관련 섹션** (`관련 섹션: [카테고리.이름], ...` 형식의 한 줄, 자동 누적): "본문 내 참조" 절 룰 따름. 호출자 등 참조·의존 섹션 포함.
-
-**h4 sub-section** (평문 아래에 고정 순서로 위→아래 작성):
+- 분석 단위에 `[OPEN]` 항목이 남아 있으면 본 NOTE 가 다른 대화 재진입 시 진행 룰 회복의 출처가 됨.
+- 본 단위가 모두 확정되면, NOTE 는 유지 (진행 이력 기록 보존) 하거나 제거 (분석 단위에만 적용되었던 룰이므로) 가능.
 
-#### 자료 매핑
+## §별 작성법
 
-표 형식 — 상대 시스템의 필드 ↔ 본 시스템의 출처.
+각 § 의 작성법(분할 절차·본문 구조·sub-section·모범)은 단계별 reference 로 분리됨. 작성·부분 수정 시 대상 § 에 맞는 파일을 Read:
 
-#### 예외 처리
+| 대상 §                                                                              | 작성법 위치                   |
+| ----------------------------------------------------------------------------------- | ----------------------------- |
+| §1 개요 · §2 업무 프로세스 · §3 기타 요구사항 · §7 공통 정의 · §8 도메인 모델 · §9 외부 인터페이스 | `references/format-analyze.md` |
+| §4 화면 · §5 자동 처리 · §6 공통·기반 기능                                          | `references/format-design.md`  |
 
-실패 케이스별 위험·대처·재시도 한계 작성.
+- 공유 형식(위 "spec.md 형식" 절: 섹션 구조·신뢰도 표기·본문 내 참조·sub-section 헤더 레벨·진행 방법)·골격·§10 은 본 SKILL.md 에 유지.
+- **부분 수정** 시: 편집 대상 섹션이 위 표의 어느 파일에 속하는지 보고 그 파일의 작성법을 Read 한 뒤 편집.
+- **배치** 는 워크플로(analyze/design)가 해당 ref 를 Read.
 
 ## §10 본문 외 확정 사항
 
@@ -775,6 +186,7 @@ sub-section 헤더 레벨은 `## spec.md 형식` 의 "sub-section 헤더 레벨"
 
 - **헤더 1줄** (필수): `- YYYY-MM-DD: <결정 한 줄>`.
   - 분석 제외 시: `- YYYY-MM-DD [제외]: <결정 한 줄>`.
+  - 날짜는 args 로 전달받은 `today` (전역 현재시각 사용 금지). 순서 보존용 로그 타임스탬프이며 신뢰도 마커가 아님.
 - **자식 bullet**: 형식 자유 (개수·내용 모두 자유).
   - **결정 근거 1개 이상 필수**.
   - 자유 항목 예시: 자료 위치·영향 범위·대화 발췌·메모·관련 § 등.
@@ -810,9 +222,9 @@ sub-section 헤더 레벨은 `## spec.md 형식` 의 "sub-section 헤더 레벨"
   - 근거: 사용자 합의 — 와이어 분량 관리
 ```
 
-## spec.md 골격 (분석 분할 단계)
+## spec.md 골격 (분석 배치)
 
-분석 분할 단계에서 spec.md 를 신규 생성할 때 사용하는 골격. `{name}` 은 사용자와 합의한 시스템명.
+분석 배치에서 spec.md 를 신규 생성할 때 사용하는 골격. `{name}` 은 사용자와 합의한 시스템명 (args 의 `systemName`).
 
 ```markdown
 # {name} 요구 분석서
@@ -846,13 +258,18 @@ sub-section 헤더 레벨은 `## spec.md 형식` 의 "sub-section 헤더 레벨"
 ## 10. 본문 외 확정 사항
 ```
 
-분석 분할 결과 반영:
-- §2.x/§3.x 헤더를 일괄 추가 (헤더 마커 `[OPEN: 날짜]` + 본문 = 분석 방법).
-- §10 에는 분석 분할 단계에서 사용자가 명시한 제외 결정 (`[제외]` 마커) 을 반영.
+분석 배치 작성 범위:
+- §2.x/§3.x 헤더 + 본문 (BPMN·흐름 설명 등) 을 작성. 미확정 항목은 인라인 `[OPEN]`.
+- §1 개요 + 자연 도출되는 §7~§9 도 함께 작성.
+- §10 에는 분석 배치 중 자료에서 도출된 제외 결정 (`[제외]` 마커) 을 반영.
 
 ## 외부 참조
 
 | 자료                                                                                                       | 용도                                                                               |
 | ---------------------------------------------------------------------------------------------------------- | ---------------------------------------------------------------------------------- |
+| [references/format-analyze.md](references/format-analyze.md) | 분석 작성법 (§1·§2·§3·§7·§8·§9). 분석 배치·§1~3·§7~9 부분 수정에서 Read |
+| [references/format-design.md](references/format-design.md) | 설계 작성법 (§4·§5·§6). 설계 배치·§4~6 부분 수정에서 Read |
 | [references/example-spec.md](references/example-spec.md)                                                   | spec.md 형식 모범 (WMS 예시 1건). 각 § 작성법의 "모범" 표기에서 참조               |
+| [workflow-analyze.js](workflow-analyze.js)                                                                 | 분석 배치 워크플로 (map→reduce→verify). 분석 연산에서 Workflow 도구로 실행          |
+| [workflow-design.js](workflow-design.js)                                                                   | 설계 배치 워크플로 (map→reduce→verify). 설계 연산에서 Workflow 도구로 실행          |
 | [.claude/references/sd-requirement-source-handling.md](../../references/sd-requirement-source-handling.md) | Requirement Source 부정확성 처리 (STT 오타·화자 모호·발화 모호·도메인 용어 다의성) |