@simplysm/sd-claude 14.0.94 → 14.0.96

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

@@ -1,6 +1,6 @@
 ---
 name: sd-spec
-description: SI/업무시스템 요구사항을 분석해 spec.md 로 구조화. 배치 작성(분석/설계 워크플로) + 부분 수정 인라인 처리. Use when "요구사항 분석", "SI 분석", "업무시스템 spec 작성" 을 요청할 때.
+description: SI/업무시스템 요구사항을 분석해 spec.md 로 구조화. 초안 배치(요건→설계 순차 빌드) + 부분 수정 인라인 처리. Use when "요구사항 분석", "SI 분석", "업무시스템 spec 작성" 을 요청할 때.
 ---
 
 # sd-spec
@@ -17,43 +17,40 @@ description: SI/업무시스템 요구사항을 분석해 spec.md 로 구조화.
 
 ## 연산
 
-sd-spec 은 3종의 연산으로 동작. 사용자 지시를 받으면 아래 디스패치로 분기. per-unit "맞나요?" 확인 루프는 없음 — 배치로 한 번에 작성하고 사용자가 사후 검토(검토 패키지)로 정정.
+sd-spec 은 2종의 연산으로 동작. 사용자 지시를 받으면 아래 디스패치로 분기. 작성은 배치로 한 번에 하고, 사용자가 사후 검토(검토 패키지)로 정정.
 
 ### 디스패치
 
 | 지시 유형                                              | 연산        | 처리 경로                                     |
 | ----------------------------------------------------- | ----------- | --------------------------------------------- |
-| "분석해줘"·"요구사항 분석"·"업무 프로세스 분석" 류     | 분석 배치   | Workflow 도구로 `workflow-analyze.js` 실행    |
-| "설계해줘"·"화면 설계"·"자동 처리 설계" 류             | 설계 배치   | Workflow 도구로 `workflow-design.js` 실행     |
-| 그 외 모든 지시 ("X를 Y로"·"A를 B와 합쳐"·"이 섹션 이상해"·재진입 정정) | 부분 수정   | SKILL.md 인라인 처리 (아래 "부분 수정")        |
+| "분석해줘"·"요구사항 분석"·"초안 작성"·"spec 작성" 류 (신규 spec.md 작성) | 초안 배치   | 메인 에이전트가 직접 순차 수행 (아래 "초안 배치")    |
+| 그 외 모든 지시 ("X를 Y로"·"A를 B와 합쳐"·"이 섹션 이상해"·"설계만 다시"·재진입 정정) | 부분 수정   | SKILL.md 인라인 처리 (아래 "부분 수정")        |
 
-- 분석/설계 배치는 백그라운드 자율 실행. 실행 중 사용자에게 묻지 않음 (모르는 건 [OPEN]).
-- 재진입(기존 spec.md 첨부 후 추가 지시)은 기본적으로 부분 수정 경로. 단 지시가 "다음 단계 전체를 배치로 진행"이면 해당 배치 연산.
+- 초안 배치는 메인 에이전트가 자율 진행. 실행 중 사용자에게 묻지 않음 (모르는 건 [OPEN]).
+- 초안 배치는 **신규 spec.md 작성 전용** (요건→설계를 한 흐름으로 통합). 기존 spec.md 가 있는 재진입(부분 재작업·정정·"설계만 다시")은 모두 부분 수정 경로.
 
-### 분석 배치
+### 초안 배치 (메인 직접 순차 수행)
 
-"분석해줘" 류 지시. 메인 에이전트가 Workflow 도구를 호출해 분석 워크플로에 위임:
+신규 spec.md 작성 지시("분석해줘"·"초안 작성"·"spec 작성" 류). 메인 에이전트가 spec.md 를 **한 줄기로 순차 빌드**함 (코딩하듯 — 앞 단위가 만든 §7·§8·§9 를 뒤 단위가 재사용·확장). 작성은 전부 메인 직접, **검증만 독립 Agent**.
 
-- `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.
-- 완료 후 메인 에이전트는 "연산 사이 검토" 의 검토 패키지를 제시하고 정지.
+**준비**:
 
-### 설계 배치
+- 폴더·경로: "입출력" 의 폴더 규칙으로 신규 `.specs/{yyMMddHHmmss}_{slug}/spec.md` 경로를 만들고, "spec.md 골격" 으로 골격(§1~§10 빈 헤더)을 Write.
+- 시스템명: 사용자와 합의한 시스템명(제목 `{name}`). 날짜: PowerShell `Get-Date -Format "yyyy-MM-dd"` (§10 로그 타임스탬프용). 자료(Requirement Source)는 직접 Read.
 
-"설계해줘" 류 지시. 확정된 §1~§3 을 입력으로 설계 워크플로에 위임:
+**단계 (직렬 — 각 단계는 그 시점에 확정된 것만 다룸)**:
 
-- `Workflow({ scriptPath: "<이 스킬 폴더>/workflow-design.js", args: { specPath: "<spec.md 경로>", skillDir: "<이 스킬 폴더>" } })` (설계는 확정 §1~3 만 입력 — `sources`/`today` 불필요).
-- 워크플로가 §4 화면 / §5 자동 처리 / §6 공통·기반 기능 (+ 그 과정에서 도출되는 §7~§9 보강) 을 자율 작성해 spec.md 에 write.
-- 완료 후 검토 패키지 제시 후 정지.
+1. **요건 (§1~3 + §7)**: `references/format.md` 의 요건·공통 작성법(§1·§2·§3·§7) + 공유 형식("spec.md 형식" 절)을 Read. 자료를 직접 Read 해 §1 개요·§2 업무 프로세스(pivotal event 로 §2/§3 분할)·§3 기타 요구를 작성. 작성 중 나오는 도메인 어휘·공통 규격은 §7 에 누적. **§4~9 는 빈 헤더로 두고 손대지 않음** (설계가 아직임). 비자명 항목엔 근거, 모르면 [OPEN].
+
+2. **설계 (§4~6 순차 빌드 + §8·§9·§7 점진 누적)**: `references/format.md` 의 설계 작성법(§4~9)을 Read. §1~3·§7 을 입력으로 §4 화면 → §5 자동 처리 → §6 공통·기반 의 단위를 **하나씩 순차로** 작성. 각 단위(§4.x 등)를 작성하면서 그 단위가 참조하는 §8 도메인 모델·§9 외부 인터페이스를 **그 자리에서 즉시 spec 에 추가·갱신** (없으면 신설, 있으면 재사용·필드 확장)하고, 새 용어는 §7 에 누적. §4 첫머리 화면 목록 표도 단위가 늘 때마다 갱신. 별도 "집계" 단계는 없음 — 누적이 곧 §8·§9 작성임 (§8·§9 불변식은 "섹션 구조" 절 참조).
+
+3. **검증 (독립 Agent, 규모 비례)**: 작성 완료 spec 을, 작성한 메인이 아닌 **독립 서브에이전트(Agent 도구)로 검증**함 (자기검증 편향 차단). 검증 항목 — ① 근거 좌표 1:1 실재 대조(원자료 재독), ② 원자료↔spec 전수 누락 역대조 + 자료 커버리지, ③ 요구 커버리지(요건 → §4~6 역대조), ④ dangling 참조 grep. 규모(자료 수·근거 수)에 비례해 항목별/자료별로 Agent 를 병렬로 펼치되, 대상이 아주 작으면 메인 직접도 허용. 근거 위조로 판정된 항목은 `(근거: …)` 를 떼고 [OPEN] 으로 강등(원 좌표는 메모로 보존).
+
+4. **검토 패키지 + 정지**: "연산 사이 검토" 의 검토 패키지를 제시하고 정지.
 
 ### 부분 수정 (인라인)
 
-분석/설계 배치 외의 모든 지시는 SKILL.md 가 메인 에이전트로 직접 처리. 워크플로 호출 없음. 재진입(기존 spec.md 에 대한 추가 작업)도 이 경로.
+초안 배치(신규 spec.md 작성) 외의 모든 지시는 SKILL.md 가 메인 에이전트로 직접 처리. 재진입(기존 spec.md 에 대한 추가 작업 — "설계만 다시"·재설계 포함)도 이 경로.
 
 - **정밀 지시** ("§4.2 의 X 컬럼을 Y로", "이 항목 [OPEN] 으로") → 바로 Edit. 무관 섹션은 건드리지 않음 (일괄 치환 금지 — Edit 의 `old_string` 을 유일 매칭되게 좁혀서 수정).
 - **모호 지적** ("이 섹션 이상해", "여기 흐름이 안 맞아") → 무엇이 문제인지 진단을 먼저 제시 → 사용자 합의 → Edit. 추측으로 바로 고치지 않음.
@@ -62,10 +59,6 @@ sd-spec 은 3종의 연산으로 동작. 사용자 지시를 받으면 아래
   - § 번호는 자주 바뀌므로 이름으로 추적. 변경 후 dangling 참조가 남지 않게 확인.
 - 작성 형식·신뢰도 표기는 아래 "작성 원칙" 과 **대상 섹션의 작성법** (아래 "§별 작성법" 절 표에서 해당 ref 를 Read) 을 따름.
 
-### 워크플로 부재 시
-
-`disableWorkflows` 등으로 Workflow 도구를 쓸 수 없으면, 분석/설계 배치는 fallback 없이 "이 연산은 workflow 가 필요합니다 (현재 비활성)" 라고 명확히 안내하고 정지. 부분 수정은 워크플로 없이 정상 동작.
-
 ### 연산 사이 검토
 
 각 연산(배치·부분 수정) 완료 후 동일하게:
@@ -74,22 +67,21 @@ sd-spec 은 3종의 연산으로 동작. 사용자 지시를 받으면 아래
 2. **검토 패키지** 를 채팅으로 제시:
    - 이번에 쓴 섹션의 한 줄 요약.
    - `[OPEN]` 목록 (이번 연산이 남긴 미확정 항목).
-   - verify 결과 요약 (배치 연산의 경우 워크플로 verify 단계가 반환한 근거 위조·누락·커버리지·dangling 참조 보고).
+   - 검증 결과 요약 (배치 연산의 경우 검증 Agent 가 반환한 근거 위조·누락·dangling 참조 보고).
    - 자료 커버리지 보고 (쓴 자료 중 spec 에 미반영된 부분).
-   - **워크플로 에러 시** (배치): 분석·설계 워크플로는 fail-fast — 에이전트(자료 추출·섹션 작성·검증 등)가 하나라도 실패하면 부분 결과 없이 throw 함. 배치가 에러로 끝나면 검토 패키지를 만들지 말고 실패 사실을 [error] 로 알린 뒤 resume 로 재실행. 정상 완료 시에만 검토 패키지를 제시.
-3. **정지**. 자동 진행하지 않음 — 분석이 끝나도 설계로 자동 진입 금지. 다음 연산은 사용자가 호출.
+   - **검증 Agent 실패 시** (배치): 검증 서브에이전트가 하나라도 실패하면 부분 결과로 검토 패키지를 만들지 말고 실패 사실을 [error] 로 알린 뒤 해당 검증만 재실행해 보완. 전건 정상 반환이어야 검증 완료로 간주.
+3. **정지**. 초안 배치가 끝나도 후속 수정으로 자동 진입 금지. 다음 연산은 사용자가 호출.
 
 ## 작성 원칙
 
 배치·부분 수정 모두에 적용되는 spec 정확성 원칙 (상위 행동 규칙·sd-design-rules 와 중복 금지, sd-spec 고유분만).
 
 - **비자명 항목 inline 근거** — 자료에서 해석·도출한 비자명 항목에는 근거를 부착(아래 "신뢰도 표기"). 사용자가 직접 말한 자명한 항목엔 붙이지 않음.
-- **모르면 [OPEN]** — 근거가 없으면 임의로 채우지 말고 [OPEN] 으로 표기. As-Is (회의록·매뉴얼·현행 화면) 만 근거인 항목·답변 범위 흡수는 근거 없음 → [OPEN].
-- **결측 보존** — `""`·`0`·`false`·임의값으로 치환 금지. nullable 은 nullable 로.
-- **단순화 차단** — spec 명시 정의·식·분기·경계를 자체 단순화·근사화·방어 처리(NULL 강제·0 클램프·가드·분기 생략) 로 임의 변형하지 않음. 식은 그대로 풀어쓰기. 정확 풀이 부담이 크면 단순화안을 [OPEN] 으로 표기하거나 검토 패키지에서 사용자에게 보고.
+- **모르면 [OPEN]** — 근거가 없으면 임의로 채우지 말고 [OPEN] 으로 표기 (판정 기준은 "신뢰도 표기" 절).
+- **단순화 차단** — spec 의 식·분기·경계를 그대로 풀어쓰기. 방어 처리(NULL 강제·0 클램프·가드·분기 생략)로 임의 변형 금지(상위 "인터페이스 설계 시"·"결측 보존"의 spec 적용). 정확 풀이 부담이 크면 단순화안을 [OPEN] 표기하거나 검토 패키지에서 보고.
 - **형식 준수** — 각 § 작성법 규약 + 그 § 첫머리 "모범" 의 example-spec.md 모범 §를 형식 모범으로 직접 대조 (모범 Read 없이 텍스트 규칙만으로 작성 금지). 다른 §·example 에서는 **형식만** 가져오고 **내용물**(항목·컬럼·필드·액션·동작) 은 본 §의 자료·발언에서 직접 도출.
 
-워크플로의 verify 단계는 위 원칙의 준수를 독립 컨텍스트에서 사후 검증(근거 좌표 1:1 대조·원자료↔spec 전수 누락 대조·요구목록 역대조·dangling 참조 grep). 사람 사후 검토(검토 패키지)가 최종 안전망.
+검증 단계(독립 Agent)는 위 원칙의 준수를 독립 컨텍스트에서 사후 검증함 (검증 항목은 "초안 배치" 3단계 참조). 사람 사후 검토(검토 패키지)가 최종 안전망.
 
 ## spec.md 형식
 
@@ -97,17 +89,25 @@ sd-spec 은 3종의 연산으로 동작. 사용자 지시를 받으면 아래
 
 spec.md 의 § 별 섹션 이름과 분류:
 
+**분류 기준**:
+
+- **요건**: 고객 입장 As-Is/To-Be — 무엇을·왜.
+- **설계**: 그걸 어떻게 만드나 — 구현 + 구현에 필요한 정보(UI·데이터구조·외부API).
+- **공통**: 요건·설계 양쪽에서 도출·편집되는 어휘·규격.
+- **자연 도출**: 직접 작성하는 단위가 아니라 다른 섹션을 쓰다 파생되는 섹션. 출처가 공통(§7 — 양쪽)인지 설계(§8·§9 — §4~6 파생)인지로 구분.
+- **§8·§9 불변식**: §4~6 에 없는 기능의 도메인 모델·외부 인터페이스는 존재할 수 없음 — 설계 산물로서 §4~6 의 종속.
+
 | §   | 섹션             | 분류                         |
 | --- | ---------------- | ---------------------------- |
-| §1  | 개요             | 분석 명세                    |
-| §2  | 업무 프로세스    | 분석                         |
-| §3  | 기타 요구사항    | 분석                         |
+| §1  | 개요             | 요건 명세                    |
+| §2  | 업무 프로세스    | 요건                         |
+| §3  | 기타 요구사항    | 요건                         |
 | §4  | 화면             | 설계                         |
 | §5  | 자동 처리        | 설계                         |
 | §6  | 공통·기반 기능   | 설계                         |
-| §7  | 공통 정의        | 자연 도출 (다른 섹션 반영거리) |
-| §8  | 도메인 모델      | 자연 도출 (다른 섹션 반영거리) |
-| §9  | 외부 인터페이스  | 자연 도출 (다른 섹션 반영거리) |
+| §7  | 공통 정의        | 공통 자연 도출 (요건·설계 양쪽에서 도출·편집) |
+| §8  | 도메인 모델      | 설계 자연 도출 (§4~6 에서 파생)              |
+| §9  | 외부 인터페이스  | 설계 자연 도출 (§4~6 에서 파생)              |
 | §10 | 본문 외 확정 사항 | 메타 (결정이 발생할 때마다 누적)     |
 
 ### 신뢰도 표기
@@ -122,7 +122,7 @@ spec.md 본문에서 항목의 신뢰도를 나타내는 표기. 전부 날짜
 | `[구현]`            | sd-impl 소관. sd-spec 은 존재만 인지, 부착·제거하지 않음.                                                  |
 
 - `[OPEN]` 판정: 근거 부족(상위 행동 규칙 "결정 근거" 적용). As-Is 만 근거 / 추정 / 답변 범위 흡수 = 근거 없음 → `[OPEN]`.
-- `[확정]` 마커는 없음. 확정 여부는 사용자가 필요 시 직접 관리 (헤더에 `[확정: 날짜]`·`[OPEN: 날짜]` 등의 상태 마커를 붙이지 않음).
+- 확정 여부는 사용자가 직접 관리 — 헤더에 상태 마커(`[확정: 날짜]`·`[OPEN: 날짜]` 등)를 붙이지 않음.
 - 예외: §10 "본문 외 확정 사항" 의 로그 항목은 순서 보존용 날짜를 유지(`- YYYY-MM-DD: ...`). 이건 신뢰도 마커가 아니라 로그 타임스탬프.
 
 ### 본문 내 참조 (이름 기반)
@@ -163,16 +163,11 @@ spec.md 본문에서 항목의 신뢰도를 나타내는 표기. 전부 날짜
 
 ## §별 작성법
 
-각 § 의 작성법(분할 절차·본문 구조·sub-section·모범)은 단계별 reference 로 분리됨. 작성·부분 수정 시 대상 § 에 맞는 파일을 Read:
-
-| 대상 §                                                                              | 작성법 위치                   |
-| ----------------------------------------------------------------------------------- | ----------------------------- |
-| §1 개요 · §2 업무 프로세스 · §3 기타 요구사항 · §7 공통 정의 · §8 도메인 모델 · §9 외부 인터페이스 | `references/format-analyze.md` |
-| §4 화면 · §5 자동 처리 · §6 공통·기반 기능                                          | `references/format-design.md`  |
+각 § 의 작성법(분할 절차·본문 구조·sub-section·모범)은 `references/format.md` 에 있음 — 요건·공통(§1·§2·§3·§7)과 설계(§4·§5·§6·§8·§9)를 한 파일로 통합. 작성·부분 수정 시 Read:
 
 - 공유 형식(위 "spec.md 형식" 절: 섹션 구조·신뢰도 표기·본문 내 참조·sub-section 헤더 레벨·진행 방법)·골격·§10 은 본 SKILL.md 에 유지.
-- **부분 수정** 시: 편집 대상 섹션이 위 표의 어느 파일에 속하는지 보고 그 파일의 작성법을 Read 한 뒤 편집.
-- **배치** 는 워크플로(analyze/design)가 해당 ref 를 Read.
+- **부분 수정** 시: `references/format.md` 의 편집 대상 섹션 작성법을 Read 한 뒤 편집.
+- **초안 배치** 는 메인이 요건 단계·설계 단계에서 `references/format.md` 를 Read.
 
 ## §10 본문 외 확정 사항
 
@@ -186,7 +181,7 @@ spec.md 본문에서 항목의 신뢰도를 나타내는 표기. 전부 날짜
 
 - **헤더 1줄** (필수): `- YYYY-MM-DD: <결정 한 줄>`.
   - 분석 제외 시: `- YYYY-MM-DD [제외]: <결정 한 줄>`.
-  - 날짜는 args 로 전달받은 `today` (전역 현재시각 사용 금지). 순서 보존용 로그 타임스탬프이며 신뢰도 마커가 아님.
+  - 날짜는 "초안 배치" 준비 단계에서 PowerShell `Get-Date` 로 생성한 값. 순서 보존용 로그 타임스탬프이며 신뢰도 마커가 아님.
 - **자식 bullet**: 형식 자유 (개수·내용 모두 자유).
   - **결정 근거 1개 이상 필수**.
   - 자유 항목 예시: 자료 위치·영향 범위·대화 발췌·메모·관련 § 등.
@@ -222,9 +217,9 @@ spec.md 본문에서 항목의 신뢰도를 나타내는 표기. 전부 날짜
   - 근거: 사용자 합의 — 와이어 분량 관리
 ```
 
-## spec.md 골격 (분석 배치)
+## spec.md 골격 (초안 배치)
 
-분석 배치에서 spec.md 를 신규 생성할 때 사용하는 골격. `{name}` 은 사용자와 합의한 시스템명 (args 의 `systemName`).
+초안 배치에서 spec.md 를 신규 생성할 때 사용하는 골격. `{name}` 은 사용자와 합의한 시스템명.
 
 ```markdown
 # {name} 요구 분석서
@@ -258,18 +253,15 @@ spec.md 본문에서 항목의 신뢰도를 나타내는 표기. 전부 날짜
 ## 10. 본문 외 확정 사항
 ```
 
-분석 배치 작성 범위:
-- §2.x/§3.x 헤더 + 본문 (BPMN·흐름 설명 등) 을 작성. 미확정 항목은 인라인 `[OPEN]`.
-- §1 개요 + 자연 도출되는 §7~§9 도 함께 작성.
-- §10 에는 분석 배치 중 자료에서 도출된 제외 결정 (`[제외]` 마커) 을 반영.
+초안 배치 작성 범위 (골격은 요건 단계에서 생성, 본문은 두 단계로 채워짐):
+- 요건 단계: 골격(§1~§10 헤더) 생성 + §1 개요·§2.x/§3.x 헤더·본문 (BPMN·흐름 설명 등)·§7 공통 정의(공통 자연 도출) 작성. 미확정 항목은 인라인 `[OPEN]`. §4~6·§8·§9 는 헤더만 두고 본문은 비움.
+- 설계 단계: §4 화면·§5 자동 처리·§6 공통·기반 기능 본문 작성 → 그 §4~6 이 참조한 모델·외부호출을 모아 §8 도메인 모델·§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 도구로 실행          |
+| [references/format.md](references/format.md) | §별 작성법 — 요건·공통 (§1·§2·§3·§7) + 설계 (§4·§5·§6·§8·§9). 초안 배치 요건·설계 단계 및 §1~9 부분 수정에서 Read |
+| [references/example-spec.md](references/example-spec.md)                                                   | spec.md 형식 모범 (WMS 예시 1건). 각 § 작성법의 "모범" 표기에서 참조 |
 | [.claude/references/sd-requirement-source-handling.md](../../references/sd-requirement-source-handling.md) | Requirement Source 부정확성 처리 (STT 오타·화자 모호·발화 모호·도메인 용어 다의성) |