@simplysm/sd-claude 14.0.65 → 14.0.66

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

@@ -1,105 +1,163 @@
----
-name: sd-spec
-description: raw input(메일/회의록/사용자 요청)을 구조화된 REQ로 정리해 spec.md 산출물로 만드는 스킬. Use when 산출물 소비자 요청을 구조화하거나 새 기능 요구사항을 정리할 때
----
-
-# spec 단계
-
-raw input → 세션 폴더 + REQ별 spec.md 생성. 사용자와 다이얼로그로 Q를 풀어가며 specified 도달.
-
-## 핵심 원칙
-
-- **self-contained 블록**: R 블록 안에 인용/A/Q 인라인. (별도 파일/섹션 분리 X)
-- **raw input 불변**: 어디 있든 수정·보정 X.
-- **Append-only**: R/REQ 자체 삭제 X. 폐기는 dropped 상태. 번호 재배치는 허용.
-- **자동 판단 금지**: 결정 근거 없으면 Q 등록. 모든 A에 근거 출처 명시.
-- **한 번에 하나씩 Q**: REQ 번호 순.
-- **즉시 갱신**: 매 답변마다 spec.md 갱신.
-- **체크리스트 유지**: R 항목 산문화 X.
-- **인용 출처 명시**: 파일경로:L범위 또는 채팅 paste + 일자.
-- **단계 전환 동의**: 5→6, 6단계 안 REQ 전환 모두 사용자 동의 후.
-- **specified 전환 전 전체 재검토**: 마지막 Q 답변 직후 전체 재검토 없이 specified 전환 X.
-
-## 입력 형태 (raw input 모드)
-
-| 형태 | 설명 |
-|---|---|
-| Bulk | 다중 출처 → 분류 작업 |
-| Direct | 1줄~몇 줄 요청 → cascading implications 발굴 |
-| Mixed | 둘 다 (분류 + 확장 병행) |
-
-## 산출물 구조
-
-```
-.specs/
-  {yyMMdd_HHmmss}/                       ← 세션 폴더
-    overview.md
-    REQ-001-슬러그/
-      spec.md
-```
-
-- 세션 폴더명 = `6자리 숫자 + "_" + 6자리 숫자` Bash(`date +%y%m%d_%H%M%S`)
-- REQ ID = `REQ-001` ... 슬러그는 한글 OK
-
-## REQ 상태 (spec 단계 한정)
-
-전체 라이프사이클은 spec.md 메타 참조. spec 단계가 다루는 4개:
-
-| 상태 | 진입 조건 |
-|---|---|
-| draft | spec.md 생성 직후 |
-| specifying | Q/A 진행 중 |
-| specified | REQ 종료 통과 (Q 0개 + 전체 재검토) |
-| dropped | 사용자 합의로 폐기 |
-
-## 워크플로
-
-1. 세션 폴더 `.specs/{yyMMdd_HHmmss}/` 생성 (raw input 모드만)
-
-2. raw input 읽기 — **불변**. STT 오타/화자 추정/모호 발화: [references/raw-input-handling.md](references/raw-input-handling.md)
-
-3. 입력 형태 식별 (Bulk/Direct/Mixed)
-
-4. overview.md 초안 + **도메인 검토 게이트** — 도메인 구성/순서 노출 → 합의 → 확정. 도메인 1개면 생략. REQ 디테일은 5단계 게이트에서. [references/overview-md-template.md](references/overview-md-template.md)
-
-5. REQ별 spec.md 작성 — 도메인 순서대로. 한 도메인 완료 → 다음 도메인 REQ 게이트로. **모든 도메인 5단계 완료 전 6단계 진입 금지.** [references/spec-md-template.md](references/spec-md-template.md)
-
-   **REQ 분할/순서**
-   - 분할 기준: 한 화면 / 독립 동작 가능 기능 / 응집된 입력·처리·출력 단위. 분할 모호 시 최대한 분할.
-   - 도메인 자기 완결: 각 도메인 REQ는 그 도메인이 자기 시점에 동작하기 위한 최소 구현. 뒷 도메인에서 쓸 것을 미리 챙기지 않음. 뒷 도메인 진입 시 앞 도메인 산출물 확장이 필요하면 그 도메인의 증분 REQ로 정의.
-   - REQ 검토 게이트: 각 도메인 첫 REQ 진입 시, REQ 구성/관계/순서를 도메인 성격에 맞춰 표현 → 합의 → 즉시 파급효과 반영 → spec.md 작성.
-
-   **모드별 처리**
-   - Bulk/Mixed: R 항목 추출 + 매핑 검증 + 충돌/모호 → Q 등록.
-   - Direct: 코드베이스 분석 + cascading implications → Q 등록.
-
-   **변경 시 동기화**
-   - 의존성/REQ 변경 발생 시 즉시 번호 재배치 + overview.md 갱신.
-
-   **5단계 종료**
-   - 남은 단계(6) 간략 안내 + 6단계 진행 Y/N. "다른 세션에서도 진행 가능" 정보 노출.
-   - 단, REQ 1개면 Y/N 묻지 않고 즉시 6단계 진입.
-
-6. Q 다이얼로그 루프 (한 번에 하나씩, REQ 번호 순)
-   - 관련자료 통독
-   - 관련 R/T + 컨텍스트 같이 보여줌
-   - 답변 → 즉시 spec.md 갱신 (Q 삭제 + A 전환 또는 항목 수정)
-   - **답변 반영 후 파급 분석**: 다른 R/T 영향 점검 → 새 Q 등록 또는 기존 항목 수정. 의존성/REQ 변경 시 즉시 반영. (Q 총량 일시적 증가 정상)
-   - **REQ 종료** (한 REQ Q 0개 도달 시):
-     ```
-     loop:
-         spec.md 전체 재검토 (R 정합성 / 누락 결정거리 / 모호 표현 / 미해결 의존)
-         if 신규 Q 등록됨:
-             "Q 다이얼로그 루프" 재진입 → Q 0 도달
-             continue
-         break
-     상태 ← specified
-     남은 REQ 안내 + 다음 REQ 진행 Y/N
-       ("다른 세션에서도 진행 가능 / specified 된 REQ 는 sd-plan 으로 바로 넘길 수 있음" 노출)
-       마지막 REQ면 Y/N 묻지 않고 즉시 종료.
-     ```
-   - **6단계 종료**: 모든 REQ specified 도달 시 종료.
-
-## 번호 재배치
-
-의존성이 4단계 이후 새로 발견되면 즉시 재배치. 재배치 시 동시 갱신: REQ 폴더명, spec.md `## 메타` 의존, `## 이력` REQ ID, overview.md REQ 목록/도메인 그룹/의존성. 흔적은 남기지 않음 (drop과 달리 단순 재정렬).
+---
+name: sd-spec
+description: SI/업무시스템 요구사항을 분석해 spec.md 로 구조화한다. Use when "요구사항 분석", "SI 분석", "업무시스템 spec 작성" 을 요청할 때
+---
+
+# sd-spec
+
+요구사항을 spec.md 로 구조화. 추상 흐름 → 구체 구현 순으로 사용자와 항목별 합의하며 진행.
+
+## 워크플로
+
+**진입 직후 MUST (BLOCKING)**: 어떤 작업도 시작하기 전에 `references/spec-authoring.md` 와 `references/example-spec.md` 두 파일을 Read 도구로 호출해 전체 본문을 읽는다. 미독 상태 작성 = 즉시 폐기 후 Read 부터.
+
+**진입 분기**: spec.md 가 첨부된 경우 → 0~3단계 건너뛰고, 같은 폴더의 `_wip.md` 도 동반 읽기. `_wip.md` 에 진행 중 §x.x 항목이 있으면 그 작업부터 재개 (사용자에게 우선순위 확인). 없으면 spec.md 의 첫 "헤더 `[OPEN: 날짜]` 이거나 본문에 인라인 `[OPEN]` 포함" 섹션에서 재개. 헤더 `[OPEN]` 이면 본문 참조 포인터로 자료 재독 → 임의안 도출 → "맞나요?". 인라인 `[OPEN]` 만이면 그 OPEN 항목부터 채움. 첨부 없으면 0단계부터.
+
+각 단계 = LLM 임의안 제시 → "맞나요?" 확정. 수정 지시 시 반영한 임의안 재제시. 확정되면 다음 단계.
+
+### references 사용 (BLOCKING)
+
+- 작성 규약: `references/spec-authoring.md` — 섹션 구조·헤더 마커·섹션별 표기 규약.
+- 풀 예시: `references/example-spec.md` — WMS 예시 spec.md. 형식 모범.
+- 빈 골격: `references/spec-md-template.md` — 초기 spec.md 골격.
+
+#### 단계별 Re-Read 매핑
+
+각 단계 임의안 작성 직전, 아래 행의 절을 다시 Read (진입 시 1회 읽었어도 컨텍스트가 길어지면 망각하므로 재독 필수).
+
+| 단계 | spec-authoring 절 | example-spec 절 |
+|------|-------------------|------------------|
+| 0단계 도메인 그림 | — | §1 (어휘 톤만 참고) |
+| 1단계 헤더 분류 | §2 헤더 명칭 / §3 | §2 / §3 |
+| 2단계 초기 생성 | §섹션 구조 + spec-md-template 전체 | — |
+| 3단계 §1 개요 | §1.1~§1.4 | §1.1~§1.4 |
+| 4단계 §2.x/§3.x 본문 | §2 (BPMN·흐름 설명 bullet·관련 섹션 포함) / §3 | §2.1, §3.1 |
+| 5단계 §4/§5 헤더 분할 | §4 화면 목록 표 | §4 헤더 + §5 헤더 |
+| 6단계 §4.x/§5.x 본문 | §4 화면 정의·와이어프레임 (텍스트)·마스터 화면 표준 / §5 / §5 Flowchart | §4.1~§4.6 (시트/폼/PDA 등 패턴), §5.1 |
+
+#### 임의안 제시 직전 자기검증 게이트
+
+매 단계 매 임의안마다, 사용자에게 보이기 **직전** 다음을 자문. 짐작·사전지식 갈음 금지.
+
+1. 이 산출물 구조·표기가 spec-authoring 의 어느 절(§) 규약을 따랐는가? — 절 식별 가능?
+2. 이 산출물 형식이 example-spec 의 어느 절(§Y.Z) 라인을 모범으로 했는가? — 절 식별 가능?
+3. 위 1·2 의 인용이 산출물의 모든 표·코드블록·표기·헤더에 1:1 매칭되는가? — 어느 표기가 references 의 어디에서 왔는지 거꾸로 추적 가능?
+4. 이번 작업 중 발견된 정보(자료 재독·사용자 발언·외부 조사·본문 작성 부산물 등) 중에 **현재 §x.x 외 다른 섹션**(특히 §6 공통 정의·§7 도메인 모델·§8 외부 인터페이스·관련 §2/§3) 에 추가·수정돼야 할 항목이 있는가? — 있으면 운용 "다른 섹션 변경·추가 발생 시" 적용해 함께 임의안 제시.
+5. 산출물의 각 항목·컬럼·필드·액션 버튼·동작 1건마다, 본 화면(§4.x) / 본 처리(§5.x) 의 관련 §2.x/§3.x 본문 또는 사용자 발언에서 도출 근거를 1:1 인용 가능한가? — 인용 불가능한 항목 = 다른 화면(example / 본 spec.md 다른 §4.x) 패턴 복제 의심. 제거하거나 사용자에게 "이 항목 누락된 요구사항인가?" 별도 질문.
+
+하나라도 비면 Re-Read 후 산출물 재작성. 한 단계 통과해도 다른 단계까지 면제 X — 매 임의안 신규 적용.
+
+### 1단계: 헤더 분류
+
+**Re-Read**: spec-authoring.md §2 헤더 명칭 + §3, example-spec.md §2 + §3.
+
+Requirement Source 의 모든 요구를 일괄 분류 → 채팅으로만 제시 (spec.md 는 2단계에서 생성).
+
+**절차 진입 전 자문 (내부)**: 외부 관계자 평면(구매처·공급처·고객·하청·감독기관 등) 식별 + 관계자별 흐름 한 줄("주는 것 / 받는 것 / 사이클"). 5번 헤더 명칭의 어휘 근거. spec.md 에 기록 X.
+
+**절차** (내부 수행, 사용자에겐 5번 결과만 제시):
+
+1. **평면화**: source 의 모든 요구 후보를 평면 목록으로. 메일 항목·슬라이드·첨부·원본 자체 카테고리(업데이트/추가 기능 등) 의 구조는 분류 단위와 무관.
+
+2. **항목별 자문 1줄**: "최종 사용자가 이걸 한 가지 업무로 인식하는가? 목적이 뭔가?" 답에 따라:
+   - **단일 명확한 목적** → §2.x 후보 (3번으로)
+   - **모호 / 여러 프로세스 걸친 다중 목적** → 별도 §2.x X. 사용 §2.x 들 안에서 각자의 목적에 맞게 흡수 (공통 utility 동작)
+   - **다른 흐름의 사전·부수·케이스/서브 타입** → 별도 §2.x X. 그 §2.x 안에서 흡수
+   - **데이터 적재·내부 조회·표시일 뿐 외부 effect X** → 별도 §2.x X. 사용 §2.x 본문에서 §4 화면으로 다룸
+   - **신규 §4 화면 또는 §5 자동 처리 등장 필요한 비-프로세스 요구** → §3.x
+   - **기존 화면/흐름 미세 변경 (필드 추가·라벨·동작 조정·버그 수정·인식률 개선) 또는 자료 해석·파라미터 규칙** → §9 분석 제외 항목
+
+3. **§2.x 후보 재검증**: business outcome 한 사이클 완결 (시작 트리거 → 종료 결과). 풀 BPMN (입고·출고) + 단순 조회 (과거 재고 조회) 모두 포함. 출력 산출물·트리거·대상이 명확히 다르면 합치지 X (같은 카테고리라도 별개 §2.x).
+
+4. **OPEN 표기**: 후속 요청 예정·구현 시점 미정 항목도 2~3번 동일 적용. 해당 카테고리에 추가하되 `[OPEN: YYYY-MM-DD]` 마커.
+
+5. **헤더 명칭 규칙**: 헤더는 위 외부 관계자 평면 기반 도메인 업무 동사구. 시스템·문서·메뉴·양식 명칭을 그대로 헤더에 쓰지 X. 외부 관계자 관계가 드러나야 함.
+   - ❌ 나쁜 예: `발주서 변경 요청` (발주서 = 시스템 문서)
+   - ✅ 좋은 예: `구매처 발주 변경 요청`
+
+6. **제시**: 분류별 헤더만 1줄씩. 자문 내용·근거·부연 묘사 X.
+
+### 2단계: 초기 생성
+
+**Re-Read**: spec-authoring.md §섹션 구조, references/spec-md-template.md 전체.
+
+- slug 임의안 (한글, 1단계 헤더가 주제를 드러내므로 그를 근거로 도출).
+- 폴더: `.specs/{yyMMddHHmmss}_{slug}/`
+- spec.md = [spec-md-template](references/spec-md-template.md) + 1단계 결과 (§2/§3 헤더 · §9 분석 제외 항목) 반영.
+
+### 3단계: §1 개요
+
+**Re-Read**: spec-authoring.md §1.1~§1.4, example-spec.md §1.1~§1.4.
+
+§1.1 → §1.2 → §1.3 → §1.4 순서로 각각 임의안.
+
+- §1.1 핵심 목적 = 0단계 관계도 기반 사이클·관계 표현. §2.x 동사구 항목 나열 X (그건 §1.2 역할).
+- §1.2 주요 목표 = §2 업무 프로세스 헤더 동사구로 자연 도출. §2.x 본문 핵심 항목을 임의 축약·누락 X.
+- §1.3 사용자 = §2 Actor 에서 도출
+- §1.4 환경/장치: ① ASCII 구성도 ② 장치 목록, 둘로 분리해 각각 묻기.
+
+### 4단계: §2.x/§3.x 본문 작성
+
+**Re-Read**: spec-authoring.md §2 (BPMN·흐름 설명 bullet·관련 섹션 포함) + §3, example-spec.md §2.1 + §3.1.
+
+분할된 단위 순서대로 한 항목씩.
+
+- **§2.x 업무 프로세스**: BPMN (사용자에겐 ASCII, 확정 후 mermaid 로 문서 저장) + 흐름 설명 bullet + 관련 섹션 (화면·자동 처리) 한꺼번에.
+- **§3.x 기타 요구사항**: 본문 전체 한꺼번에.
+
+### 5단계: §4/§5 헤더 분할
+
+**Re-Read**: spec-authoring.md §4 화면 목록 표, example-spec.md §4 헤더 + §5 헤더.
+
+§2.x/§3.x 가 매핑되는 화면(§4) / 자동 처리(§5) 의 §번호 + 이름만 순서대로 나열. §4 일 땐 화면 목록 표 (spec-authoring §4) 도 함께.
+
+### 6단계: §4.x/§5.x 본문 작성
+
+**Re-Read**: spec-authoring.md §4 화면 정의·와이어프레임 (텍스트)·마스터 화면 표준 + §5 + §5 Flowchart, example-spec.md §4.1~§4.6 + §5.1. **와이어프레임 작성 시 example-spec.md 의 가장 가까운 화면 패턴(시트=§4.1·§4.3, 폼 모달=§4.2·§4.4, PDA=§4.5, 분석 시트=§4.6) 라인을 형식 모범으로 직접 참조. ASCII 박스(┌─┐ │ └┘), 영역 추상화 표기(`<필터>`/`<시트>`/`<폼>` 등), 액션 버튼 텍스트 표기는 자체 변형 X.**
+
+**참조 범위 = 형식만, 내용물은 본 화면 요구사항에서 도출**: example-spec / 본 spec.md 의 다른 §4.x 에서 가져올 수 있는 것은 ASCII 박스 라인, 영역 추상화 표기, 액션 버튼 텍스트 표기, 항목 표 컬럼 구조(`항목 | 종류 | 필수 | 도메인 매핑 | 비고`), 마스터 화면 표준 버튼바 등 **형식**. 항목·컬럼·필드·액션 버튼·동작은 본 화면의 관련 §2.x/§3.x 본문 + 사용자 발언에서 직접 도출. 다른 화면이 가진 항목을 본 화면 요구사항 검증 없이 복제 금지 — 본 화면 요구사항에 해당 항목·기능이 명시되지 않았다면 제거. §5.x 자동 처리의 트리거·처리·예외 처리 동일.
+- ❌ 나쁜 예: 다른 화면 §4.A 에 "취소 요청" 컬럼·`[취소]` 버튼이 있었다는 이유로 §4.B 에도 그대로 복사 (§4.B 요구사항엔 취소 기능 없음)
+- ✅ 좋은 예: §4.B 의 §2.x/§3.x 본문·관련 섹션·사용자 발언에서 "취소" 언급 없음 확인 → 취소 관련 컬럼·버튼·동작 모두 제외
+
+확정된 구체 단위 순서대로 한 항목씩.
+
+- **§4.x 화면** — 합의 단위 크므로 사용자가 단번에 yes/no 판단할 수 있는 가장 작은 단위로 분리해 묻는다. spec-authoring §4.x 표준 구조 절 단위로 위→아래, 각 확정 후 다음:
+  1. 헤더 인덱스(Actor·관련 섹션) + 기능 개요 — 한 묶음
+  2. 와이어프레임 — 1건
+  3. 항목 — 영역(좌/우 등) → 하위 요소(필터·시트 컬럼·입력/상세 폼 등) 단위로 쪼개 묻기. 각 영역의 각 하위 요소별 1건.
+  4. 동작 — 1건
+  5. 도메인 규칙·로직(해당 시)
+  6. 양식 매핑(해당 시)
+
+  화면 패턴은 example-spec 의 §4.1~§4.6 라인 직접 참조 (위 Re-Read 기 명시).
+- **§5.x 자동 처리** (스케줄러/이벤트 백그라운드):
+  1. Flowchart (사용자에겐 ASCII, 확정 후 mermaid 로 문서 저장)
+  2. 목적 / 트리거 / 처리 / 예외 처리 / 관련 화면 한꺼번에
+
+이 단계에서 새 도메인 어휘·시스템 규격은 §6 공통 정의, 새 엔티티는 §7 도메인 모델, 외부 시스템 호출은 §8 외부 인터페이스 에 추가 (운용 "다른 섹션 변경·추가 발생 시" 적용).
+
+## 운용
+
+- **결정 근거**: sd-base-rules.md "결정 근거" 적용. 사용자 확정 = 헤더 `[확정: 날짜]` 마커로 표시. 확정 마킹도 상태 변경 → spec.md Write 직전 출력에 `> 진행 근거: 사용자 발언 "<verbatim 인용>" 의 "<신호 부분>"` 1줄 포함.
+- **사용자 흘림 반영**: 사용자가 흘리듯 말한 가드레일·단서·미반영 의견은 해당 발언이 영향을 주는 §의 임의안 작성 시 반영하여 "맞나요?" 절차에 포함. 휘발 금지. (영향 § 가 현재 작업 § 와 다르면 아래 "다른 섹션 변경·추가 발생 시" 와 동일 절차로 처리)
+  - ❌ 나쁜 예: §1 단계에서 "Location 코드는 영문 대문자만" 흘림 → §6.1 임의안에 미반영
+  - ✅ 좋은 예: 위 발언 인식 → §6.1 임의안에 "Location 코드 영문 대문자/숫자/하이픈" 포함
+- **Requirement Source 부정확성** (STT 오타 / 화자 추정 / 모호 발화 / 도메인 용어 다의성): [.claude/references/sd-requirement-source-handling.md](../../references/sd-requirement-source-handling.md).
+- **단계 순서**: 1~6단계는 권장 기본 진행 순서. 의존성(§4/§5 는 매핑 §2/§3 확정 필요)만 지키면 항목별 보류·점프 자유. 예: §2.1 확정 → §2.2/§2.3 보류 → §2.1 관련 §4.x 진행.
+- **보류·재개**: 임의안 제시 후 사용자가 보류 지시 → 해당 섹션 헤더 `[OPEN: 날짜]` + 본문은 재분석용 참조 포인터로 작성 (자료 라인 범위·대화 발췌·자료 연결 메모, spec-authoring "헤더 `[OPEN]` 본문" 참조). 임의안은 본문에 남기지 X. 보류 처리 자체는 추가 "맞나요?" 묻기 없이 즉시 다음 항목 진행. 재개 지시 시 본문 포인터로 자료 재독·임의안 재도출 → 확정되면 본문 임의안 교체 + 헤더 `[확정: 날짜]`.
+- **OPEN 섹션 영향 푸시**: 임의안 확정 시 그 결정이 현재 `[OPEN]` 인 다른 섹션의 재분석 결과에 영향을 줄 수 있는지 자기검증. 영향 있으면 해당 OPEN 섹션 본문 포인터에 "§X.Y `<섹션명>` 확정 — <결정 한 줄>" 메모 한 줄을 같은 작업에 함께 추가하고 사용자에 한 줄 보고. 별도 "맞나요?" X (확정된 결정의 기록일 뿐, 임의안 X).
+- **_wip.md**: sd-spec 은 _wip.md 를 직접 작성·갱신·삭제 X. 진행 중 분석 컨텍스트는 대화에 두고, 사용자가 sd-wip 호출 시 그 시점까지의 컨텍스트가 압축된다. sd-spec 은 진입 시 동반 읽기만.
+- **다른 섹션 변경·추가 발생 시**: 발견 경로 무관 — 본문 작성 중 / 자료 재독 중 / 사용자 흘림 / 외부 조사 / OPEN 섹션 재분석 부산물 등 **어디서든** 다른 섹션(기존 §x.x 본문 보강 포함, 신규 §x.x 추가 포함, §6/§7/§8 공통 섹션 추가 포함)에 반영할 정보가 발견되면, 해당 섹션 LLM 임의안 보여주고 "맞나요?" 확정 받은 후 원 작업 재개. 휘발·미루기 금지 — 발견 즉시 같은 턴에 처리.
+  - ❌ 나쁜 예: §2.1 본문 작성 중 자료 재독에서 "BOA 는 매일 갱신되며 라인이 며칠 내 사라짐" 발견 → 메모 없이 §2.1 본문만 계속 작성 (§6.3 BOA 자료 명세 보강 누락)
+  - ✅ 좋은 예: 위 발견 즉시 §6.3 보강 임의안("자료 라이프사이클: 매일 송신 단기 자료, 사라진 라인은 일자 스냅샷 누적으로 추적") 제시 → "맞나요?" 확정 → §6.3 반영 후 §2.1 재개
+- **§9 본문 외 결정사항**: 작업 중 발생 시 사용자 확인 후 추가. "분석 제외 항목" 절은 2단계에서 1단계 제외 결정으로 초기 채움, 이후 새 제외 결정 등장 시 같은 절에 추가.
+- **§4.x/§5.x 구현 마커 제거**: §4.x 화면 / §5.x 자동 처리 의 **본문 자체** 또는 **그 본문이 의존하는 다른 섹션의 본문**이 갱신되면, 헤더의 `[확정: …, 구현: …]` 중 `, 구현: 날짜` 부분만 제거해 `[확정: 날짜]` 로 환원 (이전 구현 무효화 → sd-impl 재실행 대기). 확정 날짜 갱신 여부는 무관. 마커 정의는 [spec-authoring.md 헤더 마커](references/spec-authoring.md) 표.
+  - **의존 식별**: §4.x/§5.x 본문에 다음 중 하나라도 나타나는 §x.x 가 그 §4.x/§5.x 의 의존.
+    - `관련 섹션:` 줄의 `[프로세스.X]`, `[기타.X]`, `[화면.X]`, `[자동 처리.X]`, `[외부인터페이스.X]`
+    - 본문 어느 위치든 등장하는 `[모델.X…]`, `[공통 정의.X]`
+    - §6 외부 자료 명세를 컬럼명 일치로 끌어다 쓰는 양식 매핑 표 (해당 §6.x)
+    - 모달 호출 `→ [화면.X]` 의 그 §4.x
+  - **전파 방향**: 참조 대상 → 참조하는 §4.x/§5.x 단방향.
+  - **처리 시점**: "다른 섹션 변경·추가 발생 시" 와 같은 턴. 변경 임의안 확정 시 영향 받는 §4.x/§5.x 를 번호 매겨 각 한 줄 이유(어느 §x.x 의 어떤 변경 때문에 무효화되는지)와 함께 모아 보여주고 "맞나요?" 확인. 사용자 답변에 따라 처리:
+    - 전부 동의 → 일괄 마커 제거.
+    - 일부 유지 지목 (예: "3~5는 유지") → 지목 항목은 마커 유지, 나머지만 제거.