@simplysm/sd-claude 14.0.98 → 14.0.99

package/claude/references/sd-simplysm14/manuals/client-crud.md

@@ -46,7 +46,7 @@
 
 | 슬롯                | 용도                                                                       |
 | ------------------- | -------------------------------------------------------------------------- |
-| `#filterTpl`        | 검색 폼 필드. 있으면 상단에 조회 버튼과 함께 노출.                         |
+| `#filterTpl`        | 검색 폼 필드. 있으면 상단에 조회 버튼과 함께 노출. 내부는 이미 `form-box-inline` 으로 감싸진 상태이므로, 슬롯 내용물을 별도 `form-box-inline` 으로 다시 묶지 말 것. |
 | `#toolTpl`          | 등록/삭제 버튼 옆 추가 도구 버튼.                                          |
 | `#commandTpl`       | 상단 명령 영역(viewType 이 `modal`·`control` 인 경우 해당 모드의 명령 영역)에 추가 액션 버튼. |
 | `#bottomCommandTpl` | modal 하단 좌측 영역. modal + selectMode 인 경우 "선택 해제/확인" 버튼과 함께 표시. |

package/claude/references/sd-simplysm14/manuals/client-orm.md

@@ -51,3 +51,4 @@ const rows = await this._appOrm.connectAsync(async (db) => {
 ## 지킬 것
 
 - DB 옵션(`DbClass`·`connOpt`·`dbContextOpt`)은 `AppOrmProvider` 한 곳에만 두고, 화면·프로바이더는 `connectAsync` 만 호출. 옵션을 호출부에 흩뿌리지 않음.
+- 프리렌더(SSG) 대상 화면의 초기화 경로에서는 `connectAsync` 호출 금지 — 제약은 [client-ssg.md](./client-ssg.md) 참조.

package/claude/references/sd-simplysm14/manuals/client-service.md

@@ -71,6 +71,7 @@ provideAppInitializer(async () => {
 ```
 
 - `connectAsync()` 의 Promise 를 **반환**해야 Angular 가 연결 완료까지 부트스트랩을 대기. 반환을 빠뜨리면 연결 전에 화면이 떠 통신 호출이 실패함.
+- 프리렌더(SSG) 클라이언트면 이 배선은 `main.ts` 에만 둠 — 제약은 [client-ssg.md](./client-ssg.md) 참조.
 
 ## 새 서비스 호출을 추가하려면
 

package/claude/references/sd-simplysm14/manuals/client-shared-data.md

@@ -235,3 +235,4 @@ constructor() {
 - 항목 추가 시 세 곳(`register` · `TAppSharedData` · 인터페이스)을 모두 갱신. 하나라도 빠지면 타입 불일치 또는 미등록 데이터가 됨.
 - select 결과에 매직 필드(`__valueKey` · `__searchText` · `__isHidden`)를 빠짐없이 포함.
 - `changeKeys` 분기를 생략하지 않음 — incremental refresh 가 동작하지 않으면 변경 시 전체 재조회가 됨.
+- 공유데이터는 서버 연결을 전제하므로 프리렌더(SSG) 대상 화면의 초기화 경로에서 사용 금지 — 제약은 [client-ssg.md](./client-ssg.md) 참조.

package/claude/references/sd-simplysm14/manuals/client-ssg.md

@@ -79,6 +79,7 @@ if (isPlatformBrowser(inject(PLATFORM_ID))) {
 ```
 
 - 또는 `afterNextRender(() => { ... })` — 브라우저에서만 실행됨.
+- **프리렌더 시점에는 서버 연결이 없음** — 프리렌더 화면의 초기화 경로에서 서비스 RPC·ORM(`connectAsync`)·공유데이터 호출 금지. 데이터가 필요하면 브라우저 시점(hydration 후)으로 미루거나, 그 화면을 비프리렌더 라우트로 둠. `main.server.ts` 에 `connectAsync()` 부트스트랩 배선을 복사하지 않는 것도 같은 이유.
 - `@simplysm/angular` 부트스트랩 경로(provideSdAngular·테마·busy 등)는 이미 가드되어 그대로 사용 가능. 그 외 컴포넌트는 프리렌더 화면에 쓸 때 개별 확인 — 빌드가 깨지면 그 컴포넌트의 초기화 경로를 가드.
 
 ## 지킬 것

package/claude/sd-system-prompt.md

@@ -153,35 +153,17 @@ X 함수에 캐시 도입 검토 중. 기존 의존성 확인 결과 lru-cache
 - [사용자 발언 의도 파악](#사용자-발언-의도-파악) 의 "의문·요청 (원인·방법·가능성)" 또는 "문제 기술·현상 보고" 의도로 분류된 경우.
 - 에이전트가 실행 중 마주친 실패 — 도구 에러, 테스트·빌드·lint·typecheck·check 실패, 예상과 다른 런타임 결과 등. 수단만 바꾼 재시도 전에 본 워크플로 적용 (시스템 섹션의 "도구 호출이 에러를 반환하면 멈추고..." 항목과 연동).
 
-**근본 원인 우선**:
+**근본 원인 우선**: 증상이 아닌 근본 원인부터 분석.
 
-- 증상이 아닌 근본 원인부터 분석.
-- 원인·해결 방법을 먼저 제시.
+**응답 구조 (과정 위 / 결론 아래)**:
 
-**강제 출력 포맷**:
+응답을 "과정" 과 "결론" 으로 나눔. CLI 특성상 사용자가 마지막에 읽고 답하는 위치가 맨 아래이므로, **과정은 위, 결론은 맨 아래**에 배치 (전역 "두괄식" 룰의 본 섹션 한정 예외). 맨 위 [의도 표기](#사용자-발언-의도-파악) 1줄 → 과정 → 맨 아래 결론 순서로 출력 (도구 호출 전).
 
-[의도 표기](#사용자-발언-의도-파악) 1줄 다음에 아래 3개 블록 순서대로 출력 (도구 호출 전):
-
-```
-원인 가설:
-
-1. <가설1>
-2. <가설2>
-...
-
-검증:
-
-- 가설1: <[결정 근거](#결정-근거) 인용> → <채택/기각>
-- 가설2: ...
-- 채택 가설 정합성 검증: 그 원인이 참이라 가정하면 보고된 증상이 반드시 도출되는가 + 이를 반박할 증거는 없는가 → <통과 / 실패 시 가설 재검토>
-
-해결책:
-
-- <원인 + 해결 방법. 결정 대상 여러개면 [사용자 질의 시](#사용자-질의-시) 형식 따름>
-```
-
-- 가설 1개만 떠올라도 다른 가능성 명시적으로 탐색 (최소 2개 시도, 정말 없으면 1개로 진행).
-- 블록 누락·순서 변경 금지 — 자가 검증 신호.
+- **과정** (위, 분량 무관·사용자가 안 읽어도 무방): 원인 가설 탐색 + 검증을 사고 과정으로 기재.
+    - 가설은 최소 2개 탐색 — 1개만 떠올라도 다른 가능성을 명시적으로 탐색 (정말 없으면 1개로 진행).
+    - 각 가설을 [결정 근거](#결정-근거) 인용으로 채택·기각.
+    - 채택 가설 정합성 검증: 그 원인이 참이라 가정하면 보고된 증상이 반드시 도출되는가 + 반박 증거는 없는가 → 통과 / 실패 시 가설 재검토.
+- **결론** (맨 아래, 간결·명확): 형식 고정 없이 상황에 맞춰 사용자에게 필요한 것만 기재 (원인·해결책·질문 등). 과정에 쓴 내용을 반복하지 않고 행동·답에 필요한 핵심만. 결정 대상 여러개면 [사용자 질의 시](#사용자-질의-시) 형식 따름.
 
 ## 사용자 발언 의도 파악
 
@@ -225,11 +207,14 @@ X 함수에 캐시 도입 검토 중. 기존 의존성 확인 결과 lru-cache
 
 **적용**: 모든 응답 + 산출물(spec.md·문서·발표자료·코드 주석 등).
 
+**과정·최종출력 분리**: 응답을 "과정"(추론·검토·분석)과 "최종 출력"(사용자가 반드시 읽어야 할 결론·답·요청)으로 명확히 분리. 과정은 길이·노출 제한 없음 — 길게 출력돼도 무방, 읽을지는 사용자 선택. 최종 출력은 반드시 간결·명확. 압축 대상은 최종 출력이며, 과정을 줄이지 않음. 과정을 함께 출력한 경우, 과정과 최종 출력 사이에 구분선(`---`)을 넣고 그 아래에 결론 제목(`## 결론`)을 붙여 최종 출력을 시작.
+
 ### 어휘·태도
 
 - **한국어** 원어민 수준으로 자연스럽게 응답.
 - 통용 표현 우선. 단, 구어·속어·비속어는 통용되더라도 금지 (예: "퉁치다"→"대신하다"). LLM이 자체 조합한 신조어·합성어도 금지 — 글에서 흔히 쓰는 단어로.
 - 직설적이고 솔직하게 응답. 형식어·완곡어·균형형 응답 금지.
+- **무조건적 동의 금지**: 사용자 발언·제안에 반사적으로 맞장구치거나 수긍하지 않음. 동의 전에 비판적으로 검토해 문제·이견·반례가 있으면 근거와 함께 먼저 제시. 최종 결정권은 사용자에게 있으나, 평가를 생략한 무비판 동의는 금지.
 - 결론·답·핵심 먼저, 근거·맥락·세부는 그 다음 (두괄식).
     - 나쁜 예: "X 는 ~한 특성이 있어 ~합니다. 따라서 추천."
     - 좋은 예: "X 추천. 이유: ~한 특성이 있어 ~함."

package/claude/skills/sd-docs/references/subagent-prompt.md

@@ -70,7 +70,7 @@ entry 의 export 심볼들을 "한 작업 컨텍스트에서 함께 참조될
 각 심볼별로 짧은 시그니처 + 옵션·prop·필드·enum literal(열거형 리터럴 값) 1줄 풀이 + 즉시 사용 가능한 사용법을 작성. 본질적으로 큰 군이라 분할된 경우 이 섹션은 두지 않고, 위 인덱스에서 `자세히:` 링크로 안내.
 ```
 
-**식별자 풀이 의무**: 시그니처에 나오는 옵션·prop·필드·enum literal 각각에 1줄 풀이 부착. 풀이 구성 = `<무엇을 함>` + (enum/boolean 인 경우) `<값별 동작 차이>` + `<언제 쓰는지 단서 1조각>`. 이름만 나열하는 형식 금지.
+**식별자 풀이 의무**: 시그니처에 나오는 옵션·prop·필드·enum literal 각각에 1줄 풀이 부착. 풀이 구성 = `<무엇을 함>` + (enum/boolean 인 경우) `<값별 동작 차이>` + `<언제 쓰는지 단서 1조각>`. 단 각 조각은 §7 의 검증 게이트를 통과한 것만 기재 — 근거 못 대는 조각은 지어내지 말고 생략. 이름만 콤마로 나열하고 끝내는 형식 금지(최소 타입·리터럴 값은 기재).
 
 예 (나쁨/좋음):
 
@@ -102,8 +102,9 @@ inputs: selectMode, autoSelect: "click"|"focus", useAutoSort, focusMode: "row"|"
 ## 7. 작성 원칙
 
 - 산출물의 소비자는 Claude 에이전트. 사람 가독성보다 에이전트가 즉시 따를 수 있는 간결·명확성이 우선.
-- **코드 본문에 드러난 동작은 JSDoc 이 없어도 기재**. 옵션·prop·필드·enum literal 의 동작을 본문(분기·기본값·사용처) 에서 추론해 풀이. 단, 본문에서 확인 불가한 외부 추측·미검증 동작은 기재 금지.
-- **식별자만 나열 금지** — 위 "식별자 풀이 의무" 강제. 이름을 콤마로 나열하고 끝내지 말 것. 자명해 보여도 enum literal 의 값별 동작, boolean 의 토글 효과, 함수형 prop 의 호출 시점은 반드시 풀이.
+- **코드 본문에 드러난 동작은 JSDoc 이 없어도 기재**. 옵션·prop·필드·enum literal 의 동작을 본문(분기·기본값·사용처) 에서 추론해 풀이.
+- **검증 게이트 (추측 절대 금지)**: 풀이의 각 조각(`무엇을 함`·`값별 동작 차이`·`언제 쓰는지`)은 §1 의 4개 소스 안 **특정 위치**(시그니처·분기·기본값·사용처·JSDoc·테스트)를 근거로 댈 수 있을 때만 기재. 근거 못 대는 조각은 지어내지 말고 그 조각만 생략. 코드에 없는 동작·기본값·권장 시나리오를 자명하다고 단정해 메우는 것 = 추측, 금지.
+- **식별자만 나열 금지** — 위 "식별자 풀이 의무" 강제. 이름을 콤마로 나열하고 끝내지 말 것(최소 타입·리터럴 값 기재). enum literal 의 값별 동작·boolean 토글 효과·함수형 prop 호출 시점은 검증 게이트를 통과하면 반드시 풀이하고, 코드로 확인 불가하면 그 조각만 생략.
 - 사용 예는 실제 호출 코드 형태로 1~3줄 분량, 군마다 1개 가량.
 - 분량을 늘리기 위한 부연·중복·꾸밈 금지. 단, 식별자 풀이는 "분량 늘리기" 가 아니라 필수 정보로 취급 — 풀이 생략을 통한 분량 절약 금지.
 

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 로 구조화 — 초안 배치(요건→설계 순차 빌드) + init 배치(코드-first 역작성 + [구현] 마킹) + 부분 수정 인라인 처리. Use when "요구사항 분석", "SI 분석", "업무시스템 spec 작성", "/sd-spec init" 을 요청할 때.
 ---
 
 # sd-spec
@@ -17,17 +17,19 @@ description: SI/업무시스템 요구사항을 분석해 spec.md 로 구조화.
 
 ## 연산
 
-sd-spec 은 2종의 연산으로 동작. 사용자 지시를 받으면 아래 디스패치로 분기. 작성은 배치로 한 번에 하고, 사용자가 사후 검토(검토 패키지)로 정정.
+sd-spec 은 3종의 연산으로 동작. 사용자 지시를 받으면 아래 디스패치로 분기. 작성은 배치로 한 번에 하고, 사용자가 사후 검토(검토 패키지)로 정정.
 
 ### 디스패치
 
 | 지시 유형                                              | 연산        | 처리 경로                                     |
 | ----------------------------------------------------- | ----------- | --------------------------------------------- |
 | "분석해줘"·"요구사항 분석"·"초안 작성"·"spec 작성" 류 (신규 spec.md 작성) | 초안 배치   | 메인 에이전트가 직접 순차 수행 (아래 "초안 배치")    |
+| arg `init` (`/sd-spec init [범위]`) — 기존 코드베이스를 근거로 신규 spec.md 역작성 | init 배치   | 메인 에이전트가 직접 순차 수행 (아래 "init 배치")    |
 | 그 외 모든 지시 ("X를 Y로"·"A를 B와 합쳐"·"이 섹션 이상해"·"설계만 다시"·재진입 정정) | 부분 수정   | SKILL.md 인라인 처리 (아래 "부분 수정")        |
 
-- 초안 배치는 메인 에이전트가 자율 진행. 실행 중 사용자에게 묻지 않음 (모르는 건 [OPEN]).
-- 초안 배치는 **신규 spec.md 작성 전용** (요건→설계를 한 흐름으로 통합). 기존 spec.md 가 있는 재진입(부분 재작업·정정·"설계만 다시")은 모두 부분 수정 경로.
+- 초안 배치·init 배치는 메인 에이전트가 자율 진행. 실행 중 사용자에게 묻지 않음 (모르면 [OPEN]) — sd-requirement-source-handling.md 의 "사용자에게 즉시 확인" 항목도 배치 중에는 [OPEN] + 검토 패키지 보고로 대체 (부분 수정 등 대화형 연산에서는 원문대로 즉시 확인).
+- 초안 배치·init 배치는 **신규 spec.md 작성 전용**. 기존 spec.md 가 있는 재진입(부분 재작업·정정·"설계만 다시")은 모두 부분 수정 경로.
+- arg `init` 없이 "코드(베이스) 기반 spec 작성"·"현황 spec 화" 류 발화만 온 경우: init 배치 의도로 추정하되 **진입 전 사용자 확인 필수** — 확인 없이 init 배치 진입 금지.
 
 ### 초안 배치 (메인 직접 순차 수행)
 
@@ -40,7 +42,7 @@ sd-spec 은 2종의 연산으로 동작. 사용자 지시를 받으면 아래
 
 **단계 (직렬 — 각 단계는 그 시점에 확정된 것만 다룸)**:
 
-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].
+1. **요건 (§1~3 + §7)**: `references/format.md` 의 요건·공통 작성법(§1·§2·§3·§7)을 Read 하고, 공유 형식은 본 SKILL.md 의 "spec.md 형식" 절을 따름. 자료를 직접 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 불변식은 "섹션 구조" 절 참조).
 
@@ -48,9 +50,77 @@ sd-spec 은 2종의 연산으로 동작. 사용자 지시를 받으면 아래
 
 4. **검토 패키지 + 정지**: "연산 사이 검토" 의 검토 패키지를 제시하고 정지.
 
+### init 배치 (코드-first)
+
+기존 코드베이스를 Requirement Source 로 삼아 신규 spec.md 를 역작성하고, §4~6 각 단위를 코드와 대조 검증 후 `[구현]` 마킹. 코드가 결정 근거 — 대조 차이는 전부 spec 수정으로 해소.
+
+**범위**: `init` 뒤에 범위(앱·패키지·경로)가 오면 그 범위로 한정, 없으면 전체 코드베이스. 코드 조사는 워킹트리 파일을 Read·Grep·Glob 로만 수행.
+
+**준비**: 초안 배치 준비와 동일 (폴더·골격·시스템명·날짜). 자료 = 분석 범위의 코드.
+
+**단계 (직렬)**:
+
+1. **요건 (§1~3 + §7)**: 초안 배치 1단계와 동일하되 자료 = 코드. 라우트·화면·처리 흐름에서 업무 프로세스를 역추론해 작성. 역추론 항목은 전부 비자명 취급 — `(근거: <파일 경로[:라인]>)` 부착, 추론 한계(업무 의도·왜)는 [OPEN].
+
+2. **설계 (§4~6 + §8·§9·§7)**: 초안 배치 2단계와 동일하되, 단위·항목·동작·로직을 코드에서 직접 도출. 코드에 없는 동작 작성 금지.
+
+3. **전수 커버리지 역대조 (독립 Agent)**: 코드의 화면·라우트·자동 처리·공통 기능 전수 목록 ↔ §4~6 단위 목록을 역대조 — spec 에 단위 자체가 없는 누락 발견. 누락 발견 시 2단계로 회귀해 단위 추가 후 재대조.
+
+4. **단위 검토 + `[구현]` 마킹**: §4.x/§5.x/§6.x 단위마다 검토 subagent 1개를 병렬 실행 (`Agent`, `subagent_type: general-purpose`). subagent 는 **보고 전용** — spec.md 를 수정하지 않음. prompt 는 아래 "단위 검토 subagent prompt".
+   - 보고 처리 (메인이 일괄 Edit — 차이는 전부 spec 수정으로 해소):
+     - (a) 코드 위반 → spec 작성 오류. 문서를 코드에 맞게 수정.
+     - (b) spec 내부 모순 → 코드 기준으로 정정.
+     - (c) spec 미정의 + 코드 채움 → 코드 동작을 spec 에 추가.
+   - 수정한 단위만 재대조 subagent 재실행. **차이 0건 단위의 헤더에 `[구현]` 부착** (테스트·시연 불요 — 기존 운영 코드는 동작하는 것으로 간주). 코드로 확인 불가한 [OPEN] 항목이 남은 단위는 마킹 보류.
+
+5. **검증 (독립 Agent)**: ① 근거 좌표(파일 경로·라인) 실재 대조, ② dangling 참조 grep. (초안 배치 3단계의 번안 — 누락 역대조는 3단계가 수행, 요구 커버리지는 §1~3 자체가 §4~6 역추론이므로 생략.)
+
+6. **검토 패키지 + 정지**: "연산 사이 검토" 동일.
+
+#### 단위 검토 subagent prompt
+
+아래를 그대로 복사 후 `<…>` 만 채움:
+
+````
+sd-spec init 배치의 spec ↔ 코드 단위 대조를 수행해줘.
+
+**대상**:
+- spec.md 경로: <절대경로>
+- 단위 식별자: <§4.x / §5.x / §6.x>
+- 코드 분석 범위: <경로 목록 또는 "전체">
+
+**작업**:
+
+1. spec.md 의 §<단위> 본문 + 그 본문이 참조하는 §5/§6/§7/§8/§9 항목을 읽기.
+2. 분석 범위에서 해당 단위를 구현하는 코드를 Grep·Glob·Read 로 찾아 모두 읽기.
+3. spec ↔ 코드를 항목(필드·동작·분기·계산식) 단위로 1:1 대조.
+4. 차이 발견 시 아래 3분류로 보고:
+
+   - (a) **코드 위반**: spec 에 적혔는데 코드에 없거나 다름.
+   - (b) **spec 내부 모순**: §A 정의 vs §B 정의 충돌. (양쪽 인용 명시)
+   - (c) **spec 미정의 + 코드 존재**: 코드 동작인데 spec 본문에 정의·분기·경계 케이스 명시 없음.
+
+5. 보고 형식 (각 차이 1건마다):
+
+   ### 차이 N: <도메인 어휘로 표현된 한줄 요약>
+   - 분류: (a) / (b) / (c)
+   - spec 위치: §X.x line Y
+   - spec 인용: "..."
+   - 코드 위치: <file:line>
+   - 코드 동작: <도메인 어휘로>
+
+6. 코드로 존재·동작을 확인할 수 없는 spec 항목(외부 연동 동작 등)은 "확인 불가" 로 별도 목록 보고.
+7. 차이 0건 + 확인 불가 0건이면 `차이 없음, 검증 통과` 1줄만 응답.
+
+**제약**:
+
+- 파일 수정 금지 — 보고 전용.
+- 보고 본문에 코드 식별자(변수명·SQL 함수명·타입 키워드 등) 노출 금지. 도메인 어휘로 풀어 쓸 것.
+````
+
 ### 부분 수정 (인라인)
 
-초안 배치(신규 spec.md 작성) 외의 모든 지시는 SKILL.md 가 메인 에이전트로 직접 처리. 재진입(기존 spec.md 에 대한 추가 작업 — "설계만 다시"·재설계 포함)도 이 경로.
+초안 배치·init 배치(신규 spec.md 작성) 외의 모든 지시는 SKILL.md 가 메인 에이전트로 직접 처리. 재진입(기존 spec.md 에 대한 추가 작업 — "설계만 다시"·재설계 포함)도 이 경로.
 
 - **정밀 지시** ("§4.2 의 X 컬럼을 Y로", "이 항목 [OPEN] 으로") → 바로 Edit. 무관 섹션은 건드리지 않음 (일괄 치환 금지 — Edit 의 `old_string` 을 유일 매칭되게 좁혀서 수정).
 - **모호 지적** ("이 섹션 이상해", "여기 흐름이 안 맞아") → 무엇이 문제인지 진단을 먼저 제시 → 사용자 합의 → Edit. 추측으로 바로 고치지 않음.
@@ -58,7 +128,7 @@ sd-spec 은 2종의 연산으로 동작. 사용자 지시를 받으면 아래
   - `[화면.X]`·`[모델.X]`·`[프로세스.X]` 등 이름 기반 참조("본문 내 참조" 절)를 grep 으로 전수 추적해, 병합·분할·삭제로 끊기는 참조를 함께 갱신.
   - § 번호는 자주 바뀌므로 이름으로 추적. 변경 후 dangling 참조가 남지 않게 확인.
 - **구현 마커 제거** (§4~6 자신 또는 그 의존 § 를 수정한 경우) → 아래 "§4~6 `[구현]` 마커 제거" 절을 따라 영향 §4~6 의 `[구현]` 마커를 제거.
-- 작성 형식·신뢰도 표기는 아래 "작성 원칙" 과 **대상 섹션의 작성법** (아래 "§별 작성법" 절 표에서 해당 ref 를 Read) 을 따름.
+- 작성 형식·신뢰도 표기는 아래 "작성 원칙" 과 **대상 섹션의 작성법** (아래 "§별 작성법" 절에 따라 references/format.md 의 대상 § 작성법을 Read) 을 따름.
 
 ### §4~6 `[구현]` 마커 제거
 
@@ -108,7 +178,7 @@ spec.md 의 § 별 섹션 이름과 분류:
 **분류 기준**:
 
 - **요건**: 고객 입장 As-Is/To-Be — 무엇을·왜.
-- **설계**: 그걸 어떻게 만드나 — 구현 + 구현에 필요한 정보(UI·데이터구조·외부API).
+- **설계**: 그것을 어떻게 만드나 — 구현 + 구현에 필요한 정보(UI·데이터구조·외부API).
 - **공통**: 요건·설계 양쪽에서 도출·편집되는 어휘·규격.
 - **자연 도출**: 직접 작성하는 단위가 아니라 다른 섹션을 쓰다 파생되는 섹션. 출처가 공통(§7 — 양쪽)인지 설계(§8·§9 — §4~6 파생)인지로 구분.
 - **§8·§9 불변식**: §4~6 에 없는 기능의 도메인 모델·외부 인터페이스는 존재할 수 없음 — 설계 산물로서 §4~6 의 종속.
@@ -135,11 +205,11 @@ spec.md 본문에서 항목의 신뢰도를 나타내는 표기. 전부 날짜
 | (무표기)            | 직접·자명, 또는 미검토 초안. 기본 상태.                                                                    |
 | 줄끝 `(근거: 출처)` | 자료에서 해석·도출한 **비자명** 항목의 근거 (예: `(근거: 회의록 L12)`). 사용자가 직접 말한 자명 항목엔 안 붙임. 위치 = 표는 비고 칸, 산문은 줄 끝. |
 | `[OPEN]`            | 근거 없음. 필요 시 추측·필요자료 메모 동반 (예: `[OPEN] 박스당 수량 — As-Is상 24 추정, 미확인`).            |
-| `[구현]`            | §4~6 구현 완료 표시. 부착은 sd-impl 소관. §4~6 또는 그 의존 § 수정 시 제거는 sd-spec·sd-impl 양쪽 수행 (아래 "§4~6 `[구현]` 마커 제거" 절).                                                  |
+| `[구현]`            | §4~6 구현 완료 표시. 부착은 sd-impl·sd-spec init 배치 소관 (init 배치는 코드 대조 차이 0건 시 부착). §4~6 또는 그 의존 § 수정 시 제거는 sd-spec·sd-impl 양쪽 수행 (아래 "§4~6 `[구현]` 마커 제거" 절).                                                  |
 
 - `[OPEN]` 판정: 근거 부족(상위 행동 규칙 "결정 근거" 적용). As-Is 만 근거 / 추정 / 답변 범위 흡수 = 근거 없음 → `[OPEN]`.
 - 확정 여부는 사용자가 직접 관리 — 헤더에 상태 마커(`[확정: 날짜]`·`[OPEN: 날짜]` 등)를 붙이지 않음.
-- 예외: §10 "본문 외 확정 사항" 의 로그 항목은 순서 보존용 날짜를 유지(`- YYYY-MM-DD: ...`). 이건 신뢰도 마커가 아니라 로그 타임스탬프.
+- 예외: §10 "본문 외 확정 사항" 의 로그 항목은 순서 보존용 날짜를 유지(`- YYYY-MM-DD: ...`). 이는 신뢰도 마커가 아니라 로그 타임스탬프.
 
 ### 본문 내 참조 (이름 기반)
 
@@ -150,7 +220,7 @@ spec.md 본문에서 항목의 신뢰도를 나타내는 표기. 전부 날짜
 - `[화면.재고 확인]`·`[프로세스.입고]`·`[기타.과거 재고 조회]`.
 - `[자동 처리.재고 스냅샷]`·`[기반.DataLog 기록]`·`[외부 인터페이스.ERP 입고 통보]`·`[공통 정의.Location 라벨]`.
 
-**관련 섹션 한 줄**: §2~§9 본문에 `관련 섹션: [카테고리.이름], ...` 형식의 한 줄로 참조·의존 섹션을 콤마로 나열 (카테고리 제한 없음). 별도 작성 단위가 아님 — 다른 sub-section 작성 시 곁가지로 자동 누적.
+**관련 섹션 한 줄**: §2~§6·§9 본문에 `관련 섹션: [카테고리.이름], ...` 형식의 한 줄로 참조·의존 섹션을 콤마로 나열 (카테고리 제한 없음). 별도 작성 단위가 아님 — 다른 sub-section 작성 시 곁가지로 자동 누적.
 
 ### sub-section 헤더 레벨
 
@@ -164,7 +234,6 @@ spec.md 본문에서 항목의 신뢰도를 나타내는 표기. 전부 날짜
 | §6 | 목적 · 트리거·적용 범위 (해당) · 관련 섹션 · 참조 매뉴얼 (기본 기능) | (없음 — bespoke 만 본문 자유 서술, 필요 시 h4 자유 추가) |
 | §9 | 기본 정보 (라벨 bullet 3) · 관련 섹션 (한 줄)                 | 자료 매핑 · 예외 처리                                                |
 
-본 SKILL.md 내의 `#### BPMN`·`#### 목적` 등의 표기는 작성법 설명용 sub-section 분류 표기. 실제 spec.md 본문에서의 표기는 위 표의 룰 따름.
 
 ### 진행 방법 누적
 
@@ -183,7 +252,7 @@ spec.md 본문에서 항목의 신뢰도를 나타내는 표기. 전부 날짜
 
 - 공유 형식(위 "spec.md 형식" 절: 섹션 구조·신뢰도 표기·본문 내 참조·sub-section 헤더 레벨·진행 방법)·골격·§10 은 본 SKILL.md 에 유지.
 - **부분 수정** 시: `references/format.md` 의 편집 대상 섹션 작성법을 Read 한 뒤 편집.
-- **초안 배치** 는 메인이 요건 단계·설계 단계에서 `references/format.md` 를 Read.
+- **초안 배치·init 배치** 는 메인이 요건 단계·설계 단계에서 `references/format.md` 를 Read.
 
 ## §10 본문 외 확정 사항
 
@@ -197,7 +266,7 @@ spec.md 본문에서 항목의 신뢰도를 나타내는 표기. 전부 날짜
 
 - **헤더 1줄** (필수): `- YYYY-MM-DD: <결정 한 줄>`.
   - 분석 제외 시: `- YYYY-MM-DD [제외]: <결정 한 줄>`.
-  - 날짜는 "초안 배치" 준비 단계에서 PowerShell `Get-Date` 로 생성한 값. 순서 보존용 로그 타임스탬프이며 신뢰도 마커가 아님.
+  - 날짜는 항목 작성 시점에 PowerShell `Get-Date -Format "yyyy-MM-dd"` 로 생성 (초안·init 배치는 준비 단계 생성값 재사용). 순서 보존용 로그 타임스탬프이며 신뢰도 마커가 아님.
 - **자식 bullet**: 형식 자유 (개수·내용 모두 자유).
   - **결정 근거 1개 이상 필수**.
   - 자유 항목 예시: 자료 위치·영향 범위·대화 발췌·메모·관련 § 등.
@@ -233,9 +302,9 @@ spec.md 본문에서 항목의 신뢰도를 나타내는 표기. 전부 날짜
   - 근거: 사용자 합의 — 와이어 분량 관리
 ```
 
-## spec.md 골격 (초안 배치)
+## spec.md 골격 (초안·init 배치)
 
-초안 배치에서 spec.md 를 신규 생성할 때 사용하는 골격. `{name}` 은 사용자와 합의한 시스템명.
+초안 배치·init 배치에서 spec.md 를 신규 생성할 때 사용하는 골격. `{name}` 은 사용자와 합의한 시스템명.
 
 ```markdown
 # {name} 요구 분석서
@@ -269,8 +338,8 @@ spec.md 본문에서 항목의 신뢰도를 나타내는 표기. 전부 날짜
 ## 10. 본문 외 확정 사항
 ```
 
-초안 배치 작성 범위 (골격은 요건 단계에서 생성, 본문은 두 단계로 채워짐):
-- 요건 단계: 골격(§1~§10 헤더) 생성 + §1 개요·§2.x/§3.x 헤더·본문 (BPMN·흐름 설명 등)·§7 공통 정의(공통 자연 도출) 작성. 미확정 항목은 인라인 `[OPEN]`. §4~6·§8·§9 는 헤더만 두고 본문은 비움.
+초안 배치 작성 범위 (골격 §1~§10 헤더는 준비 단계에서 생성됨, 본문은 두 단계로 채워짐):
+- 요건 단계: §1 개요·§2.x/§3.x 헤더·본문 (BPMN·흐름 설명 등)·§7 공통 정의(공통 자연 도출) 작성. 미확정 항목은 인라인 `[OPEN]`. §4~6·§8·§9 는 헤더만 두고 본문은 비움.
 - 설계 단계: §4 화면·§5 자동 처리·§6 공통·기반 기능 본문 작성 → 그 §4~6 이 참조한 모델·외부호출을 모아 §8 도메인 모델·§9 외부 인터페이스를 파생 작성.
 - §10 에는 자료에서 도출된 제외 결정 (`[제외]` 마커) 을 반영.
 

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

@@ -294,9 +294,9 @@ bullet 을 `- <트리거>: 처리 내용` 형식으로 작성.
 
 ### 마스터 화면 표준
 
-화면 목록 표에서 유형이 "마스터" 인 §4.x 에 적용. 화면 정의 sub-header (와이어프레임·항목·동작) 와 함께 작성.
+화면 목록 표에서 유형이 "마스터" 인 §4.x 중 편집을 모달로 처리하는 마스터(조회 전용 시트 + 편집 모달) 기준. 화면 정의 sub-header (와이어프레임·항목·동작) 와 함께 작성.
 
-- ID 컬럼은 편집 버튼 (`[E N]`) 으로 표현.
+- ID 컬럼 종류는 "숫자 + 편집 버튼", 비고에 "클릭 시 편집 모달" 명시.
 - 첫 컬럼은 선택 체크박스 (`[ ]`).
 - 시트 상단 버튼바: `[등록] [선택 삭제] [선택 복구] [엑셀 업로드] [엑셀 다운로드]`.
 - ID 정렬은 역방향 (내림차순).

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "@simplysm/sd-claude",
-  "version": "14.0.98",
+  "version": "14.0.99",
   "description": "심플리즘 패키지 - Claude Code 셋업",
   "author": "심플리즘",
   "license": "Apache-2.0",