@simplysm/sd-claude 14.0.91 → 14.0.93

package/claude/skills/sd-spec/references/example-spec.md

@@ -6,24 +6,20 @@
 
 ## 1. 개요
 
-### 1.1 핵심 목적 [확정: 2026-04-01]
-
+### 1.1 핵심 목적
 박스 단위로 Location 을 추적하고, 입출고 발생을 ERP 와 연동하는 WMS (Warehouse Management System).
 
-### 1.2 주요 목표 [확정: 2026-04-01]
-
+### 1.2 주요 목표
 - 박스 입고 처리
 - 박스 출고 처리
 - 입출고에 따른 재고 확인
 - 입출고 정보의 ERP 동기화
 
-### 1.3 최종 사용자/이해관계자 [확정: 2026-04-01]
-
+### 1.3 최종 사용자/이해관계자
 - 창고 작업자: 현장에서 PDA 를 들고 물건을 옮기는 작업자
 - 창고 관리자: 사무실에서 PC 로 마스터·재고·지시서를 관리하는 담당자
 
-### 1.4 환경/장치 [확정: 2026-04-01]
-
+### 1.4 환경/장치
 ```
    ┌─────────┐              ┌─────────┐
    │   PC    │              │   PDA   │
@@ -57,8 +53,7 @@
 
 ## 2. 업무 프로세스
 
-### 2.1 입고 [확정: 2026-04-01]
-
+### 2.1 입고
 ```mermaid
 flowchart LR
     S([물건 도착]) --> T1[창고 작업자: PDA 박스 바코드 스캔]
@@ -73,20 +68,18 @@ flowchart LR
 
 관련 섹션: [화면.입고 스캔], [화면.품목 관리], [화면.Location 관리], [화면.재고 확인]
 
-### 2.2 출고 [OPEN: 2026-04-01]
+### 2.2 출고
 
-분석 방법: 입고 분석 종료 후 회의록.md L40-50 재독. 사용자 보류 발언 — "출고 부분은 입고 끝나고 다음 단계에서 보자".
+[OPEN] 출고 프로세스 미분석 — 입고 분석 종료 후 회의록.md L40-50 재독 필요. 사용자 보류 — "출고 부분은 입고 끝나고 다음 단계에서 보자".
 
 ## 3. 기타 요구사항
 
-### 3.1 과거 재고 조회 [확정: 2026-04-01]
-
+### 3.1 과거 재고 조회
 특정 일자 기준의 재고 상태를 조회할 수 있어야 함.
 
 관련 섹션: [화면.재고 확인], [자동 처리.재고 스냅샷]
 
-### 3.2 시스템 기반 [확정: 2026-04-01]
-
+### 3.2 시스템 기반
 앱 운영을 떠받치는 기반 구조 — 메뉴 트리·화면 접근 권한·기능 모듈 구성 — 를 한 곳에서 정의·관리할 수 있어야 함.
 
 관련 섹션: [기반.앱 구조 정의]
@@ -100,9 +93,9 @@ flowchart LR
 | 4.3 | 입고     | 입고 스캔     | 트랜잭션 | PDA  |
 | 4.4 | 재고     | 재고 확인     | 조회     | PC   |
 
-전용 모달(품목 등록·편집·Location 등록·편집)은 각각 호출 화면(품목 관리·Location 관리) 한 곳에서만 쓰이므로 별도 §4.x 로 분리하지 않고 부모 §4.x 안에 포함 (sub-section). 자세한 배치 규칙은 spec-authoring.md "모달 처리" 참조.
+전용 모달(품목 등록·편집·Location 등록·편집)은 각각 호출 화면(품목 관리·Location 관리) 한 곳에서만 쓰이므로 별도 §4.x 로 분리하지 않고 부모 §4.x 안에 포함 (sub-section).
 
-### 4.1 품목 관리 (PC) [확정: 2026-04-01, 구현: 2026-04-05]
+### 4.1 품목 관리 (PC) [구현]
 
 Actor: 창고 관리자
 관련 섹션: [프로세스.입고]
@@ -196,8 +189,7 @@ Actor: 창고 관리자
 - `[저장]` 클릭: 활성 품목 내에서 코드·명칭 유일성을 검증한 뒤 저장하고 모달 닫음
 - `[취소]` 클릭: 변경 사항을 폐기하고 모달 닫음
 
-### 4.2 Location 관리 (PC) [확정: 2026-04-01]
-
+### 4.2 Location 관리 (PC)
 Actor: 창고 관리자
 관련 섹션: [프로세스.입고]
 
@@ -288,8 +280,7 @@ Location 신규 등록 또는 기존 Location 편집 (호출하는 쪽에서 빈
 - `[저장]` 클릭: 활성 Location 내에서 코드 유일성을 검증한 뒤 저장하고 모달 닫음
 - `[취소]` 클릭: 변경 사항을 폐기하고 모달 닫음
 
-### 4.3 입고 스캔 (PDA) [확정: 2026-04-01]
-
+### 4.3 입고 스캔 (PDA)
 Actor: 창고 작업자
 관련 섹션: [프로세스.입고], [외부 인터페이스.ERP 입고 통보]
 
@@ -328,8 +319,7 @@ Actor: 창고 작업자
     3. [모델.재고] 레코드 생성
     4. [외부 인터페이스.ERP 입고 통보] 호출
 
-### 4.4 재고 확인 (PC) [확정: 2026-04-01]
-
+### 4.4 재고 확인 (PC)
 Actor: 창고 관리자
 관련 섹션: [프로세스.입고], [기타.과거 재고 조회], [자동 처리.재고 스냅샷]
 
@@ -380,8 +370,7 @@ Actor: 창고 관리자
 
 ## 5. 자동 처리
 
-### 5.1 재고 스냅샷 [확정: 2026-04-01]
-
+### 5.1 재고 스냅샷
 목적: 과거 시점 재고 조회를 지원
 
 트리거: 매일 0시 정각 (자정)
@@ -401,8 +390,7 @@ Actor: 창고 관리자
 
 ## 6. 공통·기반 기능
 
-### 6.1 앱 구조 정의 [확정: 2026-04-01]
-
+### 6.1 앱 구조 정의
 목적: 앱의 메뉴 트리·화면 접근 권한·기능 모듈 구성을 한 곳에서 정의
 
 트리거·적용 범위: 앱 부팅 시 / admin·PDA 클라이언트별 (클라이언트마다 자기 메뉴 배열을 정의)
@@ -411,8 +399,7 @@ Actor: 창고 관리자
 
 참조 매뉴얼: client-app-structure.md
 
-### 6.2 마스터 변경 시 캐시 무효화 [확정: 2026-04-01]
-
+### 6.2 마스터 변경 시 캐시 무효화
 목적: 마스터 변경이 전 클라이언트 조회에 지체 없이 반영되도록 보장
 
 트리거·적용 범위: [모델.품목]·[모델.Location] 의 insert·update·delete commit 시점 (부수효과) / 전체 클라이언트
@@ -423,19 +410,17 @@ Actor: 창고 관리자
 
 ## 7. 공통 정의
 
-### 7.1 용어 사전 [확정: 2026-04-01]
-
+### 7.1 용어 사전
 - 박스: 외부에서 이미 바코드(품목코드 + 수량 + 박스번호 합성)가 부착된 상태로 도착하는 입고 단위
 - Location: 창고 내 적치 위치. 라벨 규격은 [공통 정의.Location 라벨] 참조
 - ERP 통보: 입출고 발생 시 WMS 에서 ERP 로 보내는 단방향 알림
 - 활성 여부: 마스터 데이터의 소프트 삭제 플래그 (true = 정상, false = 삭제 처리됨). UI 의 "삭제·복구" 액션과 매핑됨. 마스터 데이터는 DB 레코드를 물리적으로 삭제하지 않음
 
-### 7.2 박스 바코드 형식 [OPEN: 2026-04-01]
+### 7.2 박스 바코드 형식
 
-분석 방법: 첨부B.pdf p.5 "박스 코드 체계" (외부 송장 시스템 규격) 분석. [모델.박스] 의 비즈니스 키 구조와 직결되므로, [모델.박스] 확정과 함께 검토 필요.
-
-### 7.3 Location 라벨 [확정: 2026-04-01]
+[OPEN] 박스 바코드 형식 미확정 — 첨부B.pdf p.5 "박스 코드 체계" (외부 송장 시스템 규격) 분석 필요. [모델.박스] 의 비즈니스 키 구조와 직결되므로 [모델.박스] 와 함께 검토.
 
+### 7.3 Location 라벨
 ```
 ┌────────────────────────────────┐
 │                                │
@@ -451,8 +436,7 @@ Actor: 창고 관리자
 - 라벨 크기: 100 × 50 mm
 - 라벨 재질: 유포지, 흰색 무지
 
-### 7.4 화주 품목 자료 [확정: 2026-04-01]
-
+### 7.4 화주 품목 자료
 화주(품목을 본 WMS 에 보관 위탁한 거래처)가 자체 ERP 에서 수시로 다운로드한 뒤, 화주별로 별도 파일을 전달함. 신규 화주 등록 시점이나 화주 측 품목 마스터 변경 시점에 본 WMS 로 1회 일괄 업로드함. 식별 키는 `화주코드` + `SEQ` 2개 컬럼의 합성값.
 
 | 컬럼     | 필수 | 설명                                                |
@@ -464,8 +448,7 @@ Actor: 창고 관리자
 
 ## 8. 도메인 모델
 
-### 8.1 품목 [확정: 2026-04-01]
-
+### 8.1 품목
 필드:
 
 | 필드      | 타입    | 필수 | 비고                 |
@@ -481,8 +464,7 @@ Actor: 창고 관리자
 - 비즈니스 키: 코드 (사용자 부여, 수정 가능)
 - 유일성 제약: 활성 품목 범위 내에서 코드, 명칭 각각 유일
 
-### 8.2 박스 [확정: 2026-04-01]
-
+### 8.2 박스
 필드:
 
 | 필드     | 타입        | 필수 | 비고                                  |
@@ -499,8 +481,7 @@ Actor: 창고 관리자
 - 박스 1개는 단일 품목만 가짐
 - 유일성 제약: 박스번호는 전체 박스에서 유일
 
-### 8.3 Location [확정: 2026-04-01]
-
+### 8.3 Location
 필드:
 
 | 필드      | 타입    | 필수 | 비고                                                                |
@@ -515,8 +496,7 @@ Actor: 창고 관리자
 - 비즈니스 키: 코드 (사용자 부여, 수정 가능)
 - 유일성 제약: 활성 Location 범위 내에서 코드는 유일
 
-### 8.4 재고 [확정: 2026-04-01]
-
+### 8.4 재고
 필드:
 
 | 필드     | 타입            | 필수 | 비고      |
@@ -531,8 +511,7 @@ Actor: 창고 관리자
 - 박스 1개는 동시에 1개 Location 에만 존재 (박스-재고 = 1:1)
 - Location 1개에 박스 다수 적치 가능
 
-### 8.5 재고 스냅샷 [확정: 2026-04-01]
-
+### 8.5 재고 스냅샷
 필드:
 
 | 필드     | 타입            | 필수 | 비고        |
@@ -549,8 +528,7 @@ Actor: 창고 관리자
 
 ## 9. 외부 인터페이스
 
-### 9.1 ERP 입고 통보 [확정: 2026-04-01]
-
+### 9.1 ERP 입고 통보
 - 상대 시스템: ERP
 - 방향: WMS → ERP
 - 전송 방식: REST API (POST)

package/claude/skills/sd-spec/references/format-analyze.md

@@ -0,0 +1,232 @@
+# sd-spec 분석 작성법 (§1·§2·§3·§7·§8·§9)
+
+분석 배치(`workflow-analyze.js`)와 부분 수정(§1~3·§7~9 편집)이 따르는 §별 작성법.
+
+- **공유 형식**(섹션 구조·신뢰도 표기·본문 내 참조·sub-section 헤더 레벨·진행 방법)·**골격**·**§10** 은 `SKILL.md` 참조.
+- **설계 작성법**(§4~6)은 `format-design.md`.
+- §7·§8·§9 는 분석이 주로 생성하지만 설계 배치도 보강하므로 여기 둠 — 설계 시 §7~9 작성법은 본 파일을 참조.
+
+## §1 개요
+
+**작성 단위**: §1.1·§1.2·§1.3·§1.4. 단, §1.4 는 ASCII 구성도 + 장치 목록의 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 환경/장치
+
+분석 단계에서 작성한 뒤, 설계 단계 진행 중에도 보강 가능 (다른 섹션 반영거리 — 부분 수정으로 처리).
+
+구성도와 장치 목록은 목적이 별개이므로 각각 독립적으로 작성.
+
+- **ASCII 구성도**: 현장 물리 구성 시각화 — 이해당사자 간 그림 맞추기.
+  - 포함 대상: 솔루션 노드 (서버·DB·클라이언트) + 노드 간 연결선 + 물리 위치 그룹 (IDC·사무실·창고) + 자동 연동되는 외부 시스템.
+  - 제외 대상: Actor, 외부 관계자 (인적·조직), 수동 채널 (메일·종이), 구체 제품명 (MySQL)·통신 프로토콜 (HTTPS), 장치 사양 (OS·해상도).
+- **장치 목록**: 솔루션이 대상으로 하는 장치·환경 스펙 — 서버·DB·클라이언트 등. OS·버전·제품명·모델·해상도·하드웨어.
+  - 명시한 스펙에 맞게 개발하며, 그 외 스펙 환경에서의 동작은 책임 범위 외.
+
+## §2 업무 프로세스
+
+**작성 단위**: §2.x 1개당 위→아래 순서로:
+1. BPMN (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단계 (워크플로 reduce 단계가 pivotal event 로 §2/§3 분할 결정).
+
+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 단위도 아닌 것** (도메인 룰·계산식·기존 화면 미세 변경·자료 해석 파라미터·기타 규칙) → **미분류**.
+
+미분류 항목 중 근거가 자료에서 인용 불가능한 것(As-Is 답습·답변 범위 흡수)은 [OPEN] 으로 보고 (작성 원칙 참조).
+
+### 헤더 명칭
+
+- 외부 관계자 평면 기반의 도메인 업무 동사구 사용.
+- 시스템·문서·메뉴·양식의 명칭을 그대로 사용 금지.
+  - ❌ `발주서 변경 요청` (발주서 = 시스템 문서).
+  - ✅ `구매처 발주 변경 요청`.
+
+### 본문 구조
+
+sub-section 헤더 레벨은 `## spec.md 형식` 의 "sub-section 헤더 레벨" 표 참조.
+
+**평문 sub-section** (§2.x 헤더 바로 아래에 위→아래 순서로 작성):
+
+- **BPMN** (mermaid fence):
+  - 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개당 본문이 짧으면 전체를 한 단위로. 본문이 길어지면 "요구 의도" 와 "관련 섹션" 으로 분리.
+
+**모범**: 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 공통·기반 기능 본문에 작성.
+
+## §7 공통 정의
+
+작성 중 자연스럽게 도출됨 (다른 섹션 반영거리). 새로운 도메인 어휘·시스템 규격을 발견하면 추가.
+
+**모범**: 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 의 양식 매핑) 에서 작성.
+- 각 셀 값은 근거로 채택 가능한 자료가 있을 때만 작성. 추정·임의 작성 금지 → 근거 없으면 [OPEN].
+- "원본 따름"·"전체 명세는 X.xlsx 참조" 등 외부 참조로 본문 정의를 대체 금지.
+- 원본 자료에 LLM 이 접근 불가하거나 누락·모호 → 임의 처리 금지. [OPEN] 으로 표기하고 검토 패키지에서 자료·명세 정보를 요청.
+
+## §8 도메인 모델
+
+작성 중 자연스럽게 도출됨. 새로운 엔티티를 발견하면 추가.
+
+**모범**: example-spec.md §8.1~§8.5.
+
+섹션 구조: `필드:` 표 + `키/제약:` 불릿.
+
+### 필드 표
+
+컬럼 구성: `필드 | 타입 | 필수 | 비고`.
+
+- 비고에는 **그 필드가 무엇인지** (데이터 정의: 형식·값 범위·의미·제약·예시) 만 작성. **용도·출처·외부 양식·외부 시스템과의 매핑** 은 작성 금지 — §4/§5/§6 의 양식 매핑·모델 매핑 / §9 의 자료 매핑에서 작성.
+
+### 키/제약 불릿
+
+- **식별 키**: 모든 엔티티에 `ID` 필드 (숫자, 자동 부여) 를 명시.
+- **비즈니스 키** (코드 등): 별도로 명시. 수정 가능 (PK 가 아님).
+- **활성/비활성 boolean** = 소프트 삭제 플래그. 마스터에는 완전 삭제가 없음. UI 의 "삭제/복구" 액션과 매핑됨 → §7.1 용어 사전에 한 줄로 명문화.
+
+## §9 외부 인터페이스
+
+**작성 단위** (한 §9.x 당):
+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** (평문 아래에 고정 순서로 위→아래 작성):
+
+#### 자료 매핑
+
+표 형식 — 상대 시스템의 필드 ↔ 본 시스템의 출처.
+
+#### 예외 처리
+
+실패 케이스별 위험·대처·재시도 한계 작성.