@simplysm/sd-claude 14.0.48 → 14.0.49

This diff represents the content of publicly available package versions that have been released to one of the supported registries. The information contained in this diff is provided for informational purposes only and reflects changes between package versions as they appear in their respective public registries.
@@ -81,7 +81,7 @@ Bash 출력이 길면 잘리므로 **반드시 파일로 리다이렉트**한
81
81
  탐지된 check 스크립트:
82
82
  1. typecheck → pnpm run typecheck
83
83
  2. lint → pnpm run lint
84
- 3. test → pnpm vitest run
84
+ 3. test → pnpm vitest run --reporter=dot --silent=passed-only
85
85
  ```
86
86
 
87
87
  탐지된 스크립트가 없으면 오류 메시지를 출력하고 종료한다.
@@ -106,6 +106,28 @@ typecheck 명령어를 실행한다. (`출력 캡처 규칙`에 따라 파일로
106
106
  - 에러 발생 시: `에러 분석 및 수정`에 따라, 테스트 실패의 원인을 분석하고 코드를 수정한다.
107
107
  - 코드 수정후, 테스트 변경이 누락되었을 수 있음. 의도파악을 위해서 history확인이 필요할 수 있다.
108
108
 
109
- ## Step 5: 반복 혹은 완료
109
+ ## Step 5: .verify.md 재검증
110
110
 
111
- typecheck, lint, test를 수행하는 동안 코드 수정이 있었으면 `typecheck`부터 다시 시작한다. 수정이 없었으면 완료.
111
+ `에러 처리 범위` 규칙에 따라 대상 `.verify.md`를 결정한다:
112
+ - sd-check 단독 실행: 모든 `.verify.md`
113
+ - 직전 수정 있음: 수정과 관련된 `.verify.md`만
114
+
115
+ 각 `.verify.md`는 체크박스가 없는 검증 항목 명세이다. 항목을 순회하며 LLM이 매번 재수행한다 — 코드를 읽고, 명령을 실행하고, 설정을 확인하여 각 항목의 통과 여부를 판단한다. 판단 결과는 파일에 기록하지 않는다 (파일은 명세 그대로 유지).
116
+
117
+ - 문제 발견 시: test 실패와 동일하게 `에러 분석 및 수정` 규칙을 따른다.
118
+
119
+ ## Step 6: .spec.md 정합성 확인
120
+
121
+ `에러 처리 범위` 규칙에 따라 대상 `.spec.md`를 결정한다 (Step 5와 동일).
122
+
123
+ `.spec.md`는 사용자 수동 검증 문서이다. 각 문서의 전제 조건·수행 절차·기대 결과를 읽고, 관련 코드를 읽어 **의미적 정합성**을 LLM이 추론한다:
124
+ - 절차에 등장하는 UI 요소·메서드·이벤트가 실제 코드에 존재하는가
125
+ - 기대 결과가 현재 코드 동작과 일치하는가
126
+
127
+ - 불일치 발견 시: 사용자에게 보고한다. **자동 수정 금지** — 코드가 맞는지 문서가 맞는지 LLM이 판단할 수 없으므로 사용자가 결정한다.
128
+
129
+ ## Step 7: 반복 혹은 완료
130
+
131
+ typecheck, lint, test, `.verify.md` 재검증을 수행하는 동안 코드 수정이 있었으면 `typecheck`부터 다시 시작한다. 수정이 없었으면 완료.
132
+
133
+ (`.spec.md` 정합성 확인은 코드 수정을 유발하지 않으므로 반복 트리거가 아니다.)
@@ -81,9 +81,11 @@ region 주석이 없으면, re-export되는 파일의 디렉토리 구조를 카
81
81
 
82
82
  ### 작성 원칙
83
83
 
84
+ - **기존 문서가 없으면** Step 2 분석 결과로 신규 작성한다. **있으면** `docs/` 하위 모든 파일(서브디렉토리 포함)을 읽어 분석 결과를 기준으로 정합성을 맞춘다.
84
85
  - **대화언어로 작성**한다
85
86
  - **소스에서 읽은 내용만** 문서화한다 — 시그니처는 직접 복사하고, 존재하지 않는 파라미터·반환 타입·동작을 만들어내지 않는다
86
- - **기존 문서의 시그니처를 신뢰하지 않는다** — 기존 README.md/docs/*.md의 코드블록(시그니처·멤버 이름·타입·required 여부 등)을 그대로 재사용하지 않는다. 반드시 소스 파일을 Read하여 확인한 내용만 작성한다. 단, 소스 코드와 무관한 내용(사용 가이드, 주의사항, 규칙 등)은 그대로 보존한다
87
+ - **기존 문서의 시그니처를 신뢰하지 않는다** — 기존 README.md/docs/**/*.md의 코드블록(시그니처·멤버 이름·타입·required 여부 등)을 그대로 재사용하지 않는다. 반드시 소스 파일을 Read하여 확인한 내용만 작성한다.
88
+ - **소스 코드와 무관한 내용(사용 가이드, 주의사항, 규칙 등)은 보존하는 것이 원칙이되, 현재 소스와 상충하면(없어진 API 언급, 옛 동작 기준 설명, 더 이상 유효하지 않은 규칙 등) 소스 기준으로 수정한다.**
87
89
  - **모든 export를 빠짐없이 문서화한다** — Step 2에서 수집한 export 목록의 모든 항목이 문서에 포함되어야 한다. "덜 중요하다"는 이유로 생략하지 않는다
88
90
  - **interface/type은 필드별 설명 테이블을 포함한다** — 시그니처만 나열하지 않고, 각 필드의 타입과 설명을 테이블로 작성한다. 소스에 필드가 있는 interface를 빈 `{}`로 표시하는 것은 금지한다 — 필드가 많더라도 모든 필드를 테이블로 나열한다
89
91
  - **union type은 discriminant와 각 variant를 설명한다** — discriminated union인 경우, 어떤 필드로 분기되는지와 각 variant를 나열한다
@@ -197,12 +199,13 @@ Step 2B에서 스타일 항목이 수집된 경우, `{출력 경로}/docs/stylin
197
199
 
198
200
  ### Step 4-4: 완전성 및 정확성 검증
199
201
 
200
- 문서 생성 후, Step 2에서 수집한 export 목록과 생성된 문서를 대조한다.
202
+ 문서 작업 후, Step 2에서 수집한 export 목록과 `docs/` 하위 모든 파일(서브디렉토리 포함) 및 README.md를 대조한다.
201
203
 
202
204
  #### 완전성 검증
203
205
 
204
- 1. export 목록의 각 항목이 README.md 또는 docs/*.md에 존재하는지 확인한다
206
+ 1. export 목록의 각 항목이 README.md 또는 `docs/` 하위 어느 파일(서브디렉토리 포함)에 존재하는지 확인한다
205
207
  2. 누락된 항목이 있으면 해당 API를 문서에 추가한다
208
+ 3. 문서에 있는 심볼 참조 중 **현재 export에 없는 것**(제거·이름 변경된 API)은 소스 기준으로 수정하거나 제거한다
206
209
 
207
210
  #### 정확성 검증
208
211
 
@@ -47,21 +47,20 @@ Scenario의 검증 항목을 분해하고, 각 항목별로 분류한다:
47
47
  자동 테스트(`.spec.ts`)로는 검증할 수 없지만, LLM이 코드 읽기·명령 실행·설정 확인 등으로 직접 검증할 수 있는 항목을 다룬다.
48
48
  콜백 등록 코드의 정확성, 설정 파일 값, 에러 핸들링 경로 존재 여부, 타입 정합성 등이 해당한다.
49
49
 
50
- `.verify.md`는 `.spec.ts`와 동급의 테스트 산출물이다. 본 문서에서 "테스트 실행"은 `.spec.ts` 실행과 `.verify.md` 검증을 모두 포함한다.
50
+ `.verify.md`는 `.spec.ts`와 동급의 테스트 산출물이다. `.spec.ts`처럼 **검증 항목 명세**만 담고, 실행 결과는 파일에 기록하지 않는다 — 결과는 sd-check 등 검증 도구가 실행 시점에 산출한다. 본 문서에서 "테스트 실행"은 `.spec.ts` 실행과 `.verify.md` 검증을 모두 포함한다.
51
51
 
52
52
  **수행 절차:**
53
- 1. 검증 항목 중 "LLM 검증" 분류 항목을 `.verify.md`에 체크리스트로 작성한다.
53
+ 1. 검증 항목 중 "LLM 검증" 분류 항목을 `.verify.md`에 명세로 작성한다.
54
54
  2. 각 항목을 순회하며 검증을 수행한다 — 코드를 읽고, 명령을 실행하고, 결과를 확인한다.
55
- 3. 검증 결과를 체크리스트에 기록한다 — 통과하면 `[x]`, 문제 발견 시 `[!]`와 함께 내용을 기록하고 코드를 수정한다.
55
+ 3. 문제 발견 시 코드를 수정한다. 통과 항목은 문서에 별도로 기록하지 않는다.
56
56
 
57
57
  ```markdown
58
58
  # {Scenario 제목} — LLM 검증
59
59
 
60
60
  ## 검증 항목
61
61
 
62
- - [x] {항목}: {수행한 검증 내용과 결과}
63
- - [x] {항목}: {수행한 검증 내용과 결과}
64
- - [!] {항목}: {발견된 문제} → {수정 내용}
62
+ - {항목}: {검증 방법 / 기대 결과}
63
+ - {항목}: {검증 방법 / 기대 결과}
65
64
  ```
66
65
 
67
66
  #### 수동 테스트 문서 (.spec.md)
package/package.json CHANGED
@@ -1,6 +1,6 @@
1
1
  {
2
2
  "name": "@simplysm/sd-claude",
3
- "version": "14.0.48",
3
+ "version": "14.0.49",
4
4
  "description": "심플리즘 패키지 - Claude Code 셋업",
5
5
  "author": "심플리즘",
6
6
  "license": "Apache-2.0",