@simplysm/sd-claude 14.0.95 → 14.0.97
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.
- package/claude/references/sd-simplysm14/README.md +1 -0
- package/claude/references/sd-simplysm14/apis/angular/README.md +2 -0
- package/claude/references/sd-simplysm14/apis/sd-cli/sd-config-types.md +5 -0
- package/claude/references/sd-simplysm14/apis/service-server/transport-internals.md +1 -1
- package/claude/references/sd-simplysm14/manuals/client-app-structure.md +1 -1
- package/claude/references/sd-simplysm14/manuals/client-component.md +8 -3
- package/claude/references/sd-simplysm14/manuals/client-crud.md +7 -4
- package/claude/references/sd-simplysm14/manuals/client-orm.md +3 -12
- package/claude/references/sd-simplysm14/manuals/client-service.md +18 -7
- package/claude/references/sd-simplysm14/manuals/client-shared-data.md +19 -3
- package/claude/references/sd-simplysm14/manuals/client-ssg.md +89 -0
- package/claude/sd-system-prompt.md +1 -0
- package/claude/settings.json +1 -0
- package/claude/skills/sd-impl/SKILL.md +4 -3
- package/claude/skills/sd-spec/SKILL.md +68 -61
- package/claude/skills/sd-spec/references/format.md +476 -0
- package/package.json +1 -1
- package/claude/skills/sd-spec/references/format-analyze.md +0 -232
- package/claude/skills/sd-spec/references/format-design.md +0 -248
- package/claude/skills/sd-spec/workflow-analyze.js +0 -615
- package/claude/skills/sd-spec/workflow-design.js +0 -667
|
@@ -1,232 +0,0 @@
|
|
|
1
|
-
# sd-spec 분석 작성법 (§1·§2·§3·§7·§8·§9)
|
|
2
|
-
|
|
3
|
-
분석 배치(`workflow-analyze.js`)와 부분 수정(§1~3·§7~9 편집)이 따르는 §별 작성법.
|
|
4
|
-
|
|
5
|
-
- **공유 형식**(섹션 구조·신뢰도 표기·본문 내 참조·sub-section 헤더 레벨·진행 방법)·**골격**·**§10** 은 `SKILL.md` 참조.
|
|
6
|
-
- **설계 작성법**(§4~6)은 `format-design.md`.
|
|
7
|
-
- §7·§8·§9 는 분석이 주로 생성하지만 설계 배치도 보강하므로 여기 둠 — 설계 시 §7~9 작성법은 본 파일을 참조.
|
|
8
|
-
|
|
9
|
-
## §1 개요
|
|
10
|
-
|
|
11
|
-
**작성 단위**: §1.1·§1.2·§1.3·§1.4. 단, §1.4 는 ASCII 구성도 + 장치 목록의 2 부분.
|
|
12
|
-
|
|
13
|
-
**모범**: example-spec.md §1.1~§1.4.
|
|
14
|
-
|
|
15
|
-
### §1.1 핵심 목적
|
|
16
|
-
|
|
17
|
-
- 한 줄 동사형의 큰 단위로 작성.
|
|
18
|
-
- 분석 단계의 도메인 관계도를 기반으로 사이클·관계를 표현.
|
|
19
|
-
- §2.x 의 동사구 항목 나열 금지 (해당 표현은 §1.2 의 역할).
|
|
20
|
-
|
|
21
|
-
### §1.2 주요 목표
|
|
22
|
-
|
|
23
|
-
- 단위: 최종 사용자의 업무 흐름 1건 (화면·기능 단위가 아님).
|
|
24
|
-
- 표현: 한 줄 동사구. 최종 사용자 도메인 어휘 사용.
|
|
25
|
-
- §2 업무 프로세스 헤더와 1:1 매핑되는 것이 일반적.
|
|
26
|
-
- §2.x 본문의 핵심 항목은 한 줄에 모두 담아야 하며, 임의 축약·누락 금지.
|
|
27
|
-
|
|
28
|
-
### §1.3 최종 사용자/이해관계자
|
|
29
|
-
|
|
30
|
-
- 실제 담당자의 이름 사용 금지.
|
|
31
|
-
- 역할로 일반화하여 표현.
|
|
32
|
-
|
|
33
|
-
### §1.4 환경/장치
|
|
34
|
-
|
|
35
|
-
분석 단계에서 작성한 뒤, 설계 단계 진행 중에도 보강 가능 (다른 섹션 반영거리 — 부분 수정으로 처리).
|
|
36
|
-
|
|
37
|
-
구성도와 장치 목록은 목적이 별개이므로 각각 독립적으로 작성.
|
|
38
|
-
|
|
39
|
-
- **ASCII 구성도**: 현장 물리 구성 시각화 — 이해당사자 간 그림 맞추기.
|
|
40
|
-
- 포함 대상: 솔루션 노드 (서버·DB·클라이언트) + 노드 간 연결선 + 물리 위치 그룹 (IDC·사무실·창고) + 자동 연동되는 외부 시스템.
|
|
41
|
-
- 제외 대상: Actor, 외부 관계자 (인적·조직), 수동 채널 (메일·종이), 구체 제품명 (MySQL)·통신 프로토콜 (HTTPS), 장치 사양 (OS·해상도).
|
|
42
|
-
- **장치 목록**: 솔루션이 대상으로 하는 장치·환경 스펙 — 서버·DB·클라이언트 등. OS·버전·제품명·모델·해상도·하드웨어.
|
|
43
|
-
- 명시한 스펙에 맞게 개발하며, 그 외 스펙 환경에서의 동작은 책임 범위 외.
|
|
44
|
-
|
|
45
|
-
## §2 업무 프로세스
|
|
46
|
-
|
|
47
|
-
**작성 단위**: §2.x 1개당 위→아래 순서로:
|
|
48
|
-
1. BPMN (mermaid 형식으로 저장).
|
|
49
|
-
2. 흐름 설명 bullet.
|
|
50
|
-
|
|
51
|
-
**모범**: example-spec.md §2.1.
|
|
52
|
-
|
|
53
|
-
### 분할 단위 = BPMN end-to-end process
|
|
54
|
-
|
|
55
|
-
§2.x 1건 = BPMN end-to-end process 1건 (= Value Stream L1). start event ~ end event 의 풀 사이클. 사이클 내부의 handoff (역할 전환·시간 지연·외부 채널·동일인의 다른 시점) 도 포함 — BPMN swim lane 또는 노드 분기로 표현. **handoff 는 §2.x 분리 사유가 아님**.
|
|
56
|
-
|
|
57
|
-
- **start event** (BPMN 시작 트리거):
|
|
58
|
-
- Message — 외부 actor 의 메시지·자료가 도착 (구매처 발주·고객 주문·거래처 EDI).
|
|
59
|
-
- Timer — 시간이 도래 (세무 신고일·정산 마감일).
|
|
60
|
-
- Signal — 외부 조건 신호.
|
|
61
|
-
- **end event** (BPMN 종결 outcome):
|
|
62
|
-
- 외부 가치 전달 또는 외부 자료 송신 (출하 완료·세금 제출·EDI 송신).
|
|
63
|
-
- **분리 기준 = pivotal event** (Event Storming 의 pivotal event 개념):
|
|
64
|
-
1. start event 가 별개 (입고 start ↔ 출고 start).
|
|
65
|
-
2. end event 가 별개.
|
|
66
|
-
3. 도메인 어휘 자체의 전환점 (DDD 경계).
|
|
67
|
-
|
|
68
|
-
### 분할 절차 (분석)
|
|
69
|
-
|
|
70
|
-
분석 배치에서 §2/§3 분할을 동시에 진행. 절차는 4단계 (워크플로 reduce 단계가 pivotal event 로 §2/§3 분할 결정).
|
|
71
|
-
|
|
72
|
-
1. **domain event 추출** (Event Storming 의 "chaotic events" 단계) — Requirement Source 에서 동사 과거형 사건을 모두 평면적으로 추출. 원본 구조 (메일·슬라이드·문서) 와는 무관.
|
|
73
|
-
2. **timeline 정렬** (Event Storming 의 "Enforce timeline" 단계) — 비즈니스 시간 순으로 정렬. 시점이 모호한 항목은 인접 후보로 보류.
|
|
74
|
-
3. **pivotal event 식별** — start/end/도메인 어휘 전환점을 마킹. 외부 관계자 평면 (구매처·공급처·고객·하청·감독기관) 이 이 단계에서 자연스럽게 도출됨 — 이 결과가 §1 작성용 도메인 관계도 자료가 됨.
|
|
75
|
-
4. **bounded subdomain 그룹화** — 한 pivotal trigger ~ 다음 pivotal outcome 까지가 1 사이클. 사이클 내부의 handoff 도 포함.
|
|
76
|
-
|
|
77
|
-
#### 분할 결과 매핑
|
|
78
|
-
|
|
79
|
-
3가지로 분류:
|
|
80
|
-
- **사이클** (multi-event handoff 포함) → §2.x.
|
|
81
|
-
- **단일 user goal 완결** → §3.x.
|
|
82
|
-
- **사이클도 user goal 단위도 아닌 것** (도메인 룰·계산식·기존 화면 미세 변경·자료 해석 파라미터·기타 규칙) → **미분류**.
|
|
83
|
-
|
|
84
|
-
미분류 항목 중 근거가 자료에서 인용 불가능한 것(As-Is 답습·답변 범위 흡수)은 [OPEN] 으로 보고 (작성 원칙 참조).
|
|
85
|
-
|
|
86
|
-
### 헤더 명칭
|
|
87
|
-
|
|
88
|
-
- 외부 관계자 평면 기반의 도메인 업무 동사구 사용.
|
|
89
|
-
- 시스템·문서·메뉴·양식의 명칭을 그대로 사용 금지.
|
|
90
|
-
- ❌ `발주서 변경 요청` (발주서 = 시스템 문서).
|
|
91
|
-
- ✅ `구매처 발주 변경 요청`.
|
|
92
|
-
|
|
93
|
-
### 본문 구조
|
|
94
|
-
|
|
95
|
-
sub-section 헤더 레벨은 `## spec.md 형식` 의 "sub-section 헤더 레벨" 표 참조.
|
|
96
|
-
|
|
97
|
-
**평문 sub-section** (§2.x 헤더 바로 아래에 위→아래 순서로 작성):
|
|
98
|
-
|
|
99
|
-
- **BPMN** (mermaid fence):
|
|
100
|
-
- mermaid 형식으로 저장.
|
|
101
|
-
- 노드 = 최종 사용자 액션 또는 시스템 핵심 트랜잭션 (1행 동사구). 줄바꿈 `<br/>` 사용 금지.
|
|
102
|
-
- Actor·장치·매체 (PDA·PC·종이) 는 액션 컨텍스트로 노드 안에 명시 허용 (예: `창고 작업자: PDA 박스 바코드 스캔`). OS·해상도·API·DB 등 시스템 내부 디테일은 제외.
|
|
103
|
-
- 외부 채널 송신 (메일·파일 다운로드) 과 외부 응답 수신 (다음 사이클 자료 도착) 도 노드로 표현. 처리 노드는 사각 (`T[...]`), 이벤트 노드는 둥근 (`E([...])`).
|
|
104
|
-
- 분기는 사용자의 의사결정 분기만 표현.
|
|
105
|
-
- **흐름 설명 bullet** (BPMN 아래, 관련 섹션 위에 자유롭게 나열):
|
|
106
|
-
- 노드 동사구만으로는 표현되지 않는 룰·조건·계산식·외부 약속·자료 출처 인용 등을 한 줄씩 기재.
|
|
107
|
-
- §4/§5/§6 본문 작성 시 이 bullet 들을 근거로 매핑하여 누락 방지.
|
|
108
|
-
- 단, §4/§5/§6 자체의 디테일 (필드·UI·파일 확장자) 과 §7/§8/§9 의 정형 명세는 여기에 작성 금지 — 각 § 본문에서는 이름으로만 참조.
|
|
109
|
-
- **관련 섹션** (자동 누적): "본문 내 참조" 절의 룰 따름.
|
|
110
|
-
|
|
111
|
-
### 안티패턴 (분할)
|
|
112
|
-
|
|
113
|
-
- ❌ 같은 사이클의 A→B→C 단계별로 담당자·산출물이 다르다는 이유로 §2.A·§2.B·§2.C 로 쪼개는 행위.
|
|
114
|
-
- ❌ 메뉴 그룹·기존 화면 폴더·코드 As-Is 구조를 기준으로 묶거나 쪼개는 행위.
|
|
115
|
-
|
|
116
|
-
## §3 기타 요구사항
|
|
117
|
-
|
|
118
|
-
**작성 단위**: §3.x 1개당 본문이 짧으면 전체를 한 단위로. 본문이 길어지면 "요구 의도" 와 "관련 섹션" 으로 분리.
|
|
119
|
-
|
|
120
|
-
**모범**: example-spec.md §3.1.
|
|
121
|
-
|
|
122
|
-
### 분할 단위 = Cockburn sea level use case
|
|
123
|
-
|
|
124
|
-
- Cockburn 의 정의: "primary actor go away happy after having done this in a single sitting?".
|
|
125
|
-
- 행위자가 1회 작업으로 끝내고 만족하여 떠나는 단일 user goal.
|
|
126
|
-
- 사이클·handoff·지연이 없음.
|
|
127
|
-
- 정형 분해 (화면 / 자동 처리 / 공통·기반 기능) 를 동반하는, 사용자의 직접 요구.
|
|
128
|
-
- 시스템 전반 자동 룰 (예: "모든 데이터 수정 시 변경 이력 기록") 과 프레임워크 운영 기반 (앱 구조·접근 권한·부트스트랩 등) 도 §3 에 포함 — 그에 대한 설계는 §6 공통·기반 기능에서 수행.
|
|
129
|
-
|
|
130
|
-
### 본문 구조
|
|
131
|
-
|
|
132
|
-
- 요구 의도 (한 줄 또는 한 문단).
|
|
133
|
-
- 관련 섹션 한 줄 ("본문 내 참조" 절 룰 따름).
|
|
134
|
-
- 구현 디테일은 §4 화면 / §5 자동 처리 / §6 공통·기반 기능 본문에 작성.
|
|
135
|
-
|
|
136
|
-
## §7 공통 정의
|
|
137
|
-
|
|
138
|
-
작성 중 자연스럽게 도출됨 (다른 섹션 반영거리). 새로운 도메인 어휘·시스템 규격을 발견하면 추가.
|
|
139
|
-
|
|
140
|
-
**모범**: example-spec.md §7.1~§7.4.
|
|
141
|
-
|
|
142
|
-
### §7.1 용어 사전 (고정)
|
|
143
|
-
|
|
144
|
-
도메인 어휘·약어·시스템 내 의미를 정의.
|
|
145
|
-
|
|
146
|
-
### §7.2~ 기타 공통 규격
|
|
147
|
-
|
|
148
|
-
시스템 전반 규격 (바코드 형식·라벨·공통 정책 등) 작성.
|
|
149
|
-
|
|
150
|
-
특정 §2/§3 본문 단계에서 자연스럽게 포함되는 규칙 (업로드 자료 컬럼 매핑·자료 해석 규칙 등) 은 §7 에 두지 않음 → 사용처 본문에 둠.
|
|
151
|
-
|
|
152
|
-
### 외부 자료 명세
|
|
153
|
-
|
|
154
|
-
§7 의 외부 자료 = **시스템 외부에서 정의되어 도메인 모델로 자명하지 않은** 자료 (예: 외부 시스템 송신 파일, 거래처 표준 양식, 정해진 외부 규격). 도메인 모델의 자체 엑셀 업로드·다운로드 양식은 §7 가 아님 — §8 도메인 모델 + §4/§5/§6 의 양식 매핑으로 자명.
|
|
155
|
-
|
|
156
|
-
자료별로 표가 필수. 외부 자료의 모든 컬럼·필드를 1행 1정의로 작성 (자료 자체의 객관 명세).
|
|
157
|
-
|
|
158
|
-
**자료-레벨 메타** (송신 측·자료 라이프사이클·갱신 주기·식별 키 구조 등 자료 *전체* 에 적용되는 객관 명세):
|
|
159
|
-
- 근거가 있을 때만 컬럼 표 위에 자유 작성 (불릿·단락·`라벨: 값` 형식 모두 허용).
|
|
160
|
-
- 컬럼 표 안에 억지로 담지 않음.
|
|
161
|
-
|
|
162
|
-
**컬럼 표**:
|
|
163
|
-
- 외부 자료가 여러 개 (`SAP.XML`·`D1.CSV` 등) 이면 자료별로 별도의 표 작성.
|
|
164
|
-
- 컬럼 구성은 자료 성격에 따라 LLM 이 도출. 예: `컬럼명/식별자 | 필수/선택 | 설명/규칙`.
|
|
165
|
-
- 모든 컬럼에 대한 행을 유지.
|
|
166
|
-
- "설명/규칙" 류 컬럼에는 **그 컬럼이 무엇인지** (데이터 정의: 형식·값 범위·의미·제약) 만 작성. **용도** (어디에 어떻게 쓰이는지) 는 작성 금지 — 용도·매핑은 사용처 (§4/§5/§6 의 양식 매핑) 에서 작성.
|
|
167
|
-
- 각 셀 값은 근거로 채택 가능한 자료가 있을 때만 작성. 추정·임의 작성 금지 → 근거 없으면 [OPEN].
|
|
168
|
-
- "원본 따름"·"전체 명세는 X.xlsx 참조" 등 외부 참조로 본문 정의를 대체 금지.
|
|
169
|
-
- 원본 자료에 LLM 이 접근 불가하거나 누락·모호 → 임의 처리 금지. [OPEN] 으로 표기하고 검토 패키지에서 자료·명세 정보를 요청.
|
|
170
|
-
|
|
171
|
-
## §8 도메인 모델
|
|
172
|
-
|
|
173
|
-
작성 중 자연스럽게 도출됨. 새로운 엔티티를 발견하면 추가.
|
|
174
|
-
|
|
175
|
-
**모범**: example-spec.md §8.1~§8.5.
|
|
176
|
-
|
|
177
|
-
섹션 구조: `필드:` 표 + `키/제약:` 불릿.
|
|
178
|
-
|
|
179
|
-
### 필드 표
|
|
180
|
-
|
|
181
|
-
컬럼 구성: `필드 | 타입 | 필수 | 비고`.
|
|
182
|
-
|
|
183
|
-
- 비고에는 **그 필드가 무엇인지** (데이터 정의: 형식·값 범위·의미·제약·예시) 만 작성. **용도·출처·외부 양식·외부 시스템과의 매핑** 은 작성 금지 — §4/§5/§6 의 양식 매핑·모델 매핑 / §9 의 자료 매핑에서 작성.
|
|
184
|
-
|
|
185
|
-
### 키/제약 불릿
|
|
186
|
-
|
|
187
|
-
- **식별 키**: 모든 엔티티에 `ID` 필드 (숫자, 자동 부여) 를 명시.
|
|
188
|
-
- **비즈니스 키** (코드 등): 별도로 명시. 수정 가능 (PK 가 아님).
|
|
189
|
-
- **활성/비활성 boolean** = 소프트 삭제 플래그. 마스터에는 완전 삭제가 없음. UI 의 "삭제/복구" 액션과 매핑됨 → §7.1 용어 사전에 한 줄로 명문화.
|
|
190
|
-
|
|
191
|
-
## §9 외부 인터페이스
|
|
192
|
-
|
|
193
|
-
**작성 단위** (한 §9.x 당):
|
|
194
|
-
1. 기본 정보 + 자료 매핑.
|
|
195
|
-
2. 예외 처리.
|
|
196
|
-
|
|
197
|
-
작성 중 자연스럽게 도출됨. 외부 시스템 호출을 발견하면 추가.
|
|
198
|
-
|
|
199
|
-
**모범**: example-spec.md §9.1.
|
|
200
|
-
|
|
201
|
-
### 정의
|
|
202
|
-
|
|
203
|
-
§9 = 상대 시스템 고유의 인터페이스 약속 (시스템마다 자료 매핑·방식이 달라 협상이 필요한 것).
|
|
204
|
-
|
|
205
|
-
- 포함 예시: 상대 ERP·거래처가 자체 정의한 API·EDI 규격, 외부 시스템의 webhook 페이로드.
|
|
206
|
-
- 제외 예시: 표준 프로토콜·채널 (메일 SMTP·IMAP·Exchange·Graph, FTP, 표준 OAuth 등). 시스템별 협상이 없음 → §5 자동 처리에서 트리거·처리·양식 매핑으로 처리.
|
|
207
|
-
|
|
208
|
-
### 디테일 범위
|
|
209
|
-
|
|
210
|
-
도메인 약속 레벨까지만 작성. 구체 endpoint URL·HTTP method·query 파라미터·인증 흐름 단계 (grant_type·scope·token endpoint 등) ·SDK 메소드명 등 구현 디테일은 제외 — 구현 단계에서 처리. (§2 BPMN·§4 와이어·§8 도메인 모델과 동일한 원칙).
|
|
211
|
-
|
|
212
|
-
### 본문 구조
|
|
213
|
-
|
|
214
|
-
sub-section 헤더 레벨은 `## spec.md 형식` 의 "sub-section 헤더 레벨" 표 참조.
|
|
215
|
-
|
|
216
|
-
**평문 sub-section** (§9.x 헤더 바로 아래에 위→아래 순서로 작성):
|
|
217
|
-
|
|
218
|
-
- **기본 정보** (라벨 bullet 3건):
|
|
219
|
-
- `상대 시스템: <시스템명>`.
|
|
220
|
-
- `방향: <방향 표기>`.
|
|
221
|
-
- `전송 방식: <방식>`.
|
|
222
|
-
- **관련 섹션** (자동 누적): "본문 내 참조" 절 룰 따름. 호출자 등 참조·의존 섹션 포함.
|
|
223
|
-
|
|
224
|
-
**h4 sub-section** (평문 아래에 고정 순서로 위→아래 작성):
|
|
225
|
-
|
|
226
|
-
#### 자료 매핑
|
|
227
|
-
|
|
228
|
-
표 형식 — 상대 시스템의 필드 ↔ 본 시스템의 출처.
|
|
229
|
-
|
|
230
|
-
#### 예외 처리
|
|
231
|
-
|
|
232
|
-
실패 케이스별 위험·대처·재시도 한계 작성.
|
|
@@ -1,248 +0,0 @@
|
|
|
1
|
-
# sd-spec 설계 작성법 (§4·§5·§6)
|
|
2
|
-
|
|
3
|
-
설계 배치(`workflow-design.js`)와 부분 수정(§4~6 편집)이 따르는 §별 작성법.
|
|
4
|
-
|
|
5
|
-
- **입력**: spec.md 의 확정된 §1~3 (설계는 이 분석 결과에서 §4~6 을 도출).
|
|
6
|
-
- **§7·§8·§9 작성법**(설계가 보강할 때)은 `format-analyze.md` 참조.
|
|
7
|
-
- **공유 형식**(섹션 구조·신뢰도 표기·본문 내 참조·sub-section 헤더 레벨)·**골격**·**§10** 은 `SKILL.md` 참조.
|
|
8
|
-
|
|
9
|
-
## §4 화면
|
|
10
|
-
|
|
11
|
-
**작성 단위**: §4.x 1개당 "§4.x 표준 구조" 절의 단위로 위→아래 순서로 작성:
|
|
12
|
-
|
|
13
|
-
1. 기능 개요.
|
|
14
|
-
2. 와이어프레임.
|
|
15
|
-
3. 항목 — 다단으로 분할:
|
|
16
|
-
- 1차 분할: 영역 (좌/우 등) 단위 — 와이어프레임의 영역 라벨 기준.
|
|
17
|
-
- 2차 분할: 영역 내부의 하위 요소 (필터·시트 컬럼·입력 폼·상세 폼) 단위.
|
|
18
|
-
- 작성 단위 = (영역, 하위 요소) 쌍 — 예: `좌측 영역 — 필터`, `좌측 영역 — 시트 컬럼` 은 별건.
|
|
19
|
-
4. 동작.
|
|
20
|
-
5. 시각 규칙 (해당 시).
|
|
21
|
-
6. 도메인 규칙·로직 (해당 시) — 규칙별.
|
|
22
|
-
7. 자유 추가 sub-section (해당 시) — sub-section 별 (예: 업로드 양식·다운로드 양식 각각). 복잡 양식 내부의 sub-단위 (시트 등) 는 sub-단위별.
|
|
23
|
-
|
|
24
|
-
(헤더 인덱스 = Actor + 관련 섹션 으로 구성되며, 둘 다 자동 누적 — 별도 작성 단위 아님).
|
|
25
|
-
|
|
26
|
-
신규 작성·정정·골격 신설 어느 경우든 동일하게 적용.
|
|
27
|
-
|
|
28
|
-
**모범** (와이어 패턴별):
|
|
29
|
-
|
|
30
|
-
- 시트 화면: example-spec.md §4.1·§4.2·§4.4.
|
|
31
|
-
- PDA: §4.3.
|
|
32
|
-
- 폼 모달: §4.1·§4.2 의 중첩 "등록·편집 (모달)" sub-section.
|
|
33
|
-
|
|
34
|
-
### 설계 분할 절차 (§4/§5/§6 공통)
|
|
35
|
-
|
|
36
|
-
설계 배치에서 §4/§5/§6 헤더를 §2/§3 본문 (+ §8 마스터 엔티티) 에서 도출. 절차:
|
|
37
|
-
|
|
38
|
-
1. **§4 화면 도출**:
|
|
39
|
-
- §2 BPMN 의 최종 사용자 액션 노드 + §3 의 사용자 직접 요구 → 트랜잭션 화면 또는 조회 화면.
|
|
40
|
-
- §8 의 마스터 엔티티 → 마스터 화면.
|
|
41
|
-
- 도메인 묶음 또는 장치별로 그룹화 → 화면 목록 표.
|
|
42
|
-
2. **§5 자동 처리 도출** — §2/§3 의 시스템 백그라운드 처리 (스케줄·이벤트 트리거·외부 자료 수집·적재) 를 추출.
|
|
43
|
-
3. **§6 공통·기반 기능 도출** — §4 화면·§5 자동 처리에 속하지 않는 모든 개발 단위를 추출: 부수효과로 발동되는 동작 + 앱 전역 정적 골격(앱 구조[메뉴·권한·모듈]·로깅·부트스트랩 초기화). §3 의 "시스템 기반" 류 요구가 주 도출원. 프레임워크 기본 기능(매뉴얼 존재)은 매뉴얼 참조로, 앱 고유 부수효과는 인라인으로 명세.
|
|
44
|
-
|
|
45
|
-
워크플로 reduce 단계가 화면 목록 표·모달/시트 재활용 교차참조를 정합. 도출 근거가 없는 항목은 [OPEN].
|
|
46
|
-
|
|
47
|
-
### 화면 목록 표 (§4 첫머리)
|
|
48
|
-
|
|
49
|
-
5컬럼 구조: `§ | 분류 | 화면 | 유형 | 장치`.
|
|
50
|
-
|
|
51
|
-
- 분류: 도메인 묶음·메뉴 그룹의 자유 명칭 (예: `기준정보`·`입고`·`재고`).
|
|
52
|
-
- 유형: 마스터 / 트랜잭션 / 조회 중 택1.
|
|
53
|
-
- 장치: PC / PDA / 기타 중 택1.
|
|
54
|
-
- 화면이 추가·제거되면 표도 함께 갱신. 같은 분류끼리 인접 배치.
|
|
55
|
-
|
|
56
|
-
### 화면 정의 (§4.x 표준 구조)
|
|
57
|
-
|
|
58
|
-
화면 헤더에 (장치) 표기를 유지: `### N.N 화면명 (PC)` 또는 `(PDA)`.
|
|
59
|
-
|
|
60
|
-
sub-section 헤더 레벨은 `## spec.md 형식` 의 "sub-section 헤더 레벨" 표 참조.
|
|
61
|
-
|
|
62
|
-
**평문 sub-section** (§4.x 헤더 바로 아래에 위→아래 순서로 작성):
|
|
63
|
-
|
|
64
|
-
- **헤더 인덱스** (한 줄씩 작성, 자동 누적 — 별도 작성 단위 아님):
|
|
65
|
-
- `Actor: <역할>` — §2 BPMN 의 swim lane 또는 §3 의 사용자 직접 요구에서 자연 도출.
|
|
66
|
-
- `관련 섹션:` "본문 내 참조" 절 룰 따름 — 모달 호출·시트 영역 재활용 등 화면 간 의존 포함.
|
|
67
|
-
- **기능 개요**: `기능 개요:` 라벨 다음에 bullet 로 화면 기능을 설명.
|
|
68
|
-
|
|
69
|
-
**h4 sub-section** (평문 아래, 고정 순서, 위→아래):
|
|
70
|
-
|
|
71
|
-
#### 와이어프레임 (텍스트)
|
|
72
|
-
|
|
73
|
-
**형식 일탈 금지**:
|
|
74
|
-
|
|
75
|
-
- example-spec.md 의 가장 가까운 화면 패턴 라인을 형식 모범으로 직접 참조(매핑은 본 §4 작성법 첫머리 "모범 (와이어 패턴별)" 참조).
|
|
76
|
-
- ASCII 박스 (┌─┐ │ └┘) ·영역 추상화 표기 (`<필터>`·`<시트>`·`<폼>` 등) ·액션 버튼 텍스트 표기를 임의로 변형 금지.
|
|
77
|
-
|
|
78
|
-
**원칙**: 영역 배치·구획만 표현. 디테일 (필드·시트 컬럼·실제 값·아이콘 placeholder·fixed 경계·비활성 행 등 시각 표현) 은 와이어에 두지 않음 — 항목 표·동작 절·도메인 규칙 절이 단일 출처.
|
|
79
|
-
|
|
80
|
-
- 데이터 영역: 영역 타입 + 짧은 라벨로 추상화 — `<필터>`·`<폼>`·`<시트>`·`<목록>`·`<PO 목록>`·`<라인 시트 - 작성영역>` 등. 영역 종류가 한눈에 잡히지 않으면 라벨을 보강.
|
|
81
|
-
- 액션 버튼: 텍스트를 유지 (`[조회]`·`[저장]`·`[등록]`) — 버튼 위치 자체가 와이어가 전달하는 정보. 아이콘만 있는 버튼도 텍스트로 표기.
|
|
82
|
-
- 영역 (좌/우 분할·탭·상단 command 바·시트 상단 버튼바) 으로 나뉠 경우 박스 라인으로 구획.
|
|
83
|
-
- 상태 (작성중·확정 등) 에 따라 영역 구획이 크게 달라지면 상태별로 분리. 제목 형식: `와이어프레임 (<상태명>):` (예: `와이어프레임 (확정 전):`).
|
|
84
|
-
|
|
85
|
-
#### 항목
|
|
86
|
-
|
|
87
|
-
데이터 항목만 작성 (필터·시트 컬럼·입력 폼·상세 폼). 액션 버튼은 "동작" 절에 작성.
|
|
88
|
-
|
|
89
|
-
- **표 제목 = 와이어의 영역 라벨과 동일 명칭** 을 굵게 표기 — 와이어의 `<필터>` → `**필터**`, `<품목 목록 시트>` → `**품목 목록 시트**`, `<스캔 입력 폼>` → `**스캔 입력 폼**`.
|
|
90
|
-
- 한 영역에 종류가 다른 표가 여러 개 있을 경우 종류를 부기 — `**<영역 라벨> — <필터|시트 컬럼|입력 폼>**` (예: `**헤더 목록 — 필터**`, `**BOA 시트 — 시트 컬럼**`).
|
|
91
|
-
- 시트 화면의 기본 구성: 상단 command 바의 `<필터>` + 시트 영역 (시트 컬럼) 총 2 그룹.
|
|
92
|
-
|
|
93
|
-
**표 형식** — 도메인 매핑은 별도 컬럼으로 (필터는 시트 컬럼과 중복되므로 도메인 매핑 컬럼 없음):
|
|
94
|
-
|
|
95
|
-
- 입력 폼: `항목 | 종류 | 필수 | 도메인 매핑 | 비고`.
|
|
96
|
-
- 시트 컬럼: `컬럼 | 종류 | 필수 | 도메인 매핑 | 비고`.
|
|
97
|
-
- 필터: `항목 | 종류 | 필수 | 비고`.
|
|
98
|
-
|
|
99
|
-
- 필수 컬럼: 의미가 없는 경우 (조회 시트 컬럼 등) 는 `-`.
|
|
100
|
-
- 도메인 매핑: `[모델.X.Y]` 형식 (양식 매핑과 일관). 매핑이 없는 항목 (선택 체크박스 등) 은 `-`.
|
|
101
|
-
- 비고: 표시 내용 (이름과 도메인만으로 자명하지 않을 때 어떤 값이 표시되는지) / 편집 방법 (편집 가능 항목 — 예: 클릭 시 모달, 인라인 편집) / 비자명 항목의 근거 (`(근거: 출처)`) / 기타 자유 설명.
|
|
102
|
-
|
|
103
|
-
**시트 컬럼 그룹핑** (해당 시): 컬럼들이 도메인적으로 묶일 경우 표 안에 그룹 표시.
|
|
104
|
-
|
|
105
|
-
- 그룹 헤더 행을 1줄 (`**그룹명**` 표시, 다른 셀은 빈 칸).
|
|
106
|
-
- 자식 컬럼은 `└ ` 들여쓰기 prefix 부착.
|
|
107
|
-
- 표의 컬럼 수는 유지.
|
|
108
|
-
|
|
109
|
-
#### 동작
|
|
110
|
-
|
|
111
|
-
bullet 을 `- <트리거>: 처리 내용` 형식으로 작성.
|
|
112
|
-
|
|
113
|
-
- 트리거 예시: `` `[버튼]` 클릭 ``, `박스 바코드 스캔`, `Enter 키`.
|
|
114
|
-
- 처리 내용: 동사구 + 대상 (예: `[화면.X] 을 모달로 띄움`, `검색 필터 조건으로 목록 갱신`).
|
|
115
|
-
|
|
116
|
-
#### 시각 규칙 (해당 시)
|
|
117
|
-
|
|
118
|
-
행 단위·조건부 시각 표현 (비활성 행 취소선·상태별 강조 색·아이콘 등) 을 작성. 컬럼 단위 표현은 항목 표의 비고에 작성하므로 여기에는 작성하지 않음.
|
|
119
|
-
|
|
120
|
-
#### 도메인 규칙·로직 (해당 시)
|
|
121
|
-
|
|
122
|
-
표준 sub-section 으로 담기지 않는, 화면 고유의 도메인 요구를 작성. 자유 명칭의 절을 필요한 만큼 추가. 누락 없이 적는 것이 핵심.
|
|
123
|
-
|
|
124
|
-
**자유 추가 sub-section** (`#### 도메인 규칙·로직` 아래, 화면별 필요 시 h4 자유 추가):
|
|
125
|
-
|
|
126
|
-
- **양식 입출력** (예: `#### 업로드 양식`·`#### 다운로드 양식`) — 양식별로 별도 sub-section 작성.
|
|
127
|
-
- 단순 양식: 내부에 단순 표 — 컬럼은 `파일 컬럼` + `도메인 모델 ([모델.X.Y])` + `변환·규칙 (해당 시)`. §7.x 에 명세된 양식이면 컬럼명을 일치시키고, 일회성 양식이면 sub-section 내부에서 직접 명세.
|
|
128
|
-
- 복잡 양식 (다중 시트·구조 분할): 내부의 sub-단위 (시트 등) 는 h5 (`##### <시트>` 등) 로 작성. sub-단위 내부에 진행 방법 NOTE 작성 가능 (`## spec.md 형식` 의 "진행 방법 누적" 절 참조).
|
|
129
|
-
- **기타 화면 고유 정보** — sub-section 이름은 자유. 표준 sub-section 으로 담기지 않는 화면 고유 정보의 누락 방지 목적.
|
|
130
|
-
|
|
131
|
-
### 마스터 화면 표준
|
|
132
|
-
|
|
133
|
-
화면 목록 표에서 유형이 "마스터" 인 §4.x 에 적용. 화면 정의 sub-header (와이어프레임·항목·동작) 와 함께 작성.
|
|
134
|
-
|
|
135
|
-
- ID 컬럼은 편집 버튼 (`[E N]`) 으로 표현.
|
|
136
|
-
- 첫 컬럼은 선택 체크박스 (`[ ]`).
|
|
137
|
-
- 시트 상단 버튼바: `[등록] [선택 삭제] [선택 복구] [엑셀 업로드] [엑셀 다운로드]`.
|
|
138
|
-
- ID 정렬은 역방향 (내림차순).
|
|
139
|
-
|
|
140
|
-
### 상단 command 바
|
|
141
|
-
|
|
142
|
-
화면 정의 sub-header 의 와이어프레임·동작과 함께 작성. 페이지 제목 바로 아래, 시트·폼 영역 위에 배치. 페이지 전체 또는 현재 레코드 단위의 액션 바.
|
|
143
|
-
|
|
144
|
-
- 좌측: 필터 입력 + 조회 (list 화면) / 진입 컨텍스트 표시 (detail 화면).
|
|
145
|
-
- 우측: 페이지 단위·레코드 단위 액션 (있는 경우에만).
|
|
146
|
-
- 좌·우 사이에 `│` 세로 구분선.
|
|
147
|
-
|
|
148
|
-
**우측 버튼 그룹 순서** (좌→우):
|
|
149
|
-
|
|
150
|
-
1. 기본 CRUD (저장 / 삭제 / 복구).
|
|
151
|
-
2. 워크플로 상태 전환 (확정 / 취소 / 승인 / 반려).
|
|
152
|
-
3. 유틸리티 (원본 다운로드 / 프린트 / PDF).
|
|
153
|
-
|
|
154
|
-
list 화면과 detail 화면 모두 동일. 새 버튼은 해당 그룹의 끝에 추가. 시트 상단 버튼바도 동일한 그룹 순서를 따름 (마스터 화면 표준은 그 구체 인스턴스).
|
|
155
|
-
|
|
156
|
-
### 모달 처리
|
|
157
|
-
|
|
158
|
-
호출하는 쪽 §4.x 의 동작 sub-header 와 호출되는 쪽 §4.x 양쪽 모두에 적용.
|
|
159
|
-
|
|
160
|
-
- 모달 화면도 별도의 §4.x. 호출하는 쪽의 동작에 "→ [화면.X] 을 모달로 띄움" 을 명시.
|
|
161
|
-
- 화면명에 "(모달)" 등의 사용 맥락 표기 금지 — 같은 화면이 다른 곳에서는 다른 방식으로 호출될 수 있음.
|
|
162
|
-
- 화면의 일부 영역 (시트·탭) 이 다른 화면에서 모달로 재활용되는 경우, 별도 §4.x 로 분리하지 않음. 대신 그 화면의 동작 절 끝에 "영역별로 모달 호출 시 제약" (편집 가능 여부 / 선택 전용 / multiselect) 을 한 줄씩 명시. 호출하는 쪽의 동작은 "→ [화면.X] 의 <영역> 을 모달로 띄움" 으로 표기.
|
|
163
|
-
|
|
164
|
-
## §5 자동 처리
|
|
165
|
-
|
|
166
|
-
**작성 단위**: §5.x 1개당 위→아래 순서로:
|
|
167
|
-
|
|
168
|
-
1. 목적 / 트리거 (한 묶음).
|
|
169
|
-
2. 처리.
|
|
170
|
-
3. 예외 처리.
|
|
171
|
-
4. 자유 추가 sub-section (해당 시) — sub-section 별 (예: 읽기 양식·쓰기 양식 각각). 복잡 양식 내부의 sub-단위 (시트 등) 는 sub-단위별.
|
|
172
|
-
|
|
173
|
-
**모범**: example-spec.md §5.1.
|
|
174
|
-
|
|
175
|
-
### 정의
|
|
176
|
-
|
|
177
|
-
스케줄러 또는 이벤트 트리거로 동작하는 시스템 백그라운드 처리. 표준 프로토콜·채널을 통한 외부 자료 수집·적재 (메일 폴링 + 첨부 적재, FTP 자료 수집 등) 도 §5 에 포함 — 시스템별 협상이 필요 없는 표준 인터페이싱은 §9 가 아님.
|
|
178
|
-
|
|
179
|
-
§6 공통·기반 기능과의 차이: §5 = 스케줄·이벤트로 명시적인 트리거가 있음. §6 = 명시적 트리거가 없는 것 (부수효과로 발동되거나 전역에 상시 구성되는 것).
|
|
180
|
-
|
|
181
|
-
### 본문 구조
|
|
182
|
-
|
|
183
|
-
sub-section 헤더 레벨은 `## spec.md 형식` 의 "sub-section 헤더 레벨" 표 참조.
|
|
184
|
-
|
|
185
|
-
**평문 sub-section** (§5.x 헤더 바로 아래에 "라벨 + 본문" 형식으로 작성):
|
|
186
|
-
|
|
187
|
-
- `목적:` 도메인 목적을 한 줄로.
|
|
188
|
-
- `트리거:` 스케줄·이벤트 명시.
|
|
189
|
-
- `관련 섹션:` "본문 내 참조" 절 룰 따름.
|
|
190
|
-
|
|
191
|
-
**h4 sub-section** (평문 아래에 고정 순서로 위→아래 작성):
|
|
192
|
-
|
|
193
|
-
#### 처리
|
|
194
|
-
|
|
195
|
-
처리 단계 작성.
|
|
196
|
-
|
|
197
|
-
#### 예외 처리
|
|
198
|
-
|
|
199
|
-
실패 케이스별 위험·대처·재시도 한계 작성.
|
|
200
|
-
|
|
201
|
-
**자유 추가 sub-section** (`#### 예외 처리` 아래에, §5.x 별로 필요 시 h4 자유 추가):
|
|
202
|
-
|
|
203
|
-
- **양식 입출력** (예: `#### 읽기 양식`·`#### 쓰기 양식`) — §4 의 "양식 입출력" sub-section 룰과 동일. 방향은 읽기·쓰기. 일회성 양식이면 sub-section 안에서 직접 명세.
|
|
204
|
-
- **기타 자동 처리 고유 정보** — sub-section 이름은 자유.
|
|
205
|
-
|
|
206
|
-
## §6 공통·기반 기능
|
|
207
|
-
|
|
208
|
-
화면(§4)도 명시적 트리거 자동 처리(§5)도 아닌, 시스템을 떠받치는 공통·기반 개발 단위 전부 (캐치올). §4·§5 에 속하지 않는 개발 entry 는 전부 여기로 모임 — 갈 곳 없는 항목을 §7(공통 정의) 등 명세 섹션으로 올리지 말 것.
|
|
209
|
-
|
|
210
|
-
포괄 대상 (두 성격이 한 섹션에 섞임. 항목을 어느 한쪽으로 미리 분류하지 않음 — 애매하거나 두 성격을 겸하는 항목도 그대로 수용):
|
|
211
|
-
|
|
212
|
-
- 부수효과로 발동되는 동작 — DataLog 기록·권한 체크·캐시 무효화·알림 발송·감사 로그.
|
|
213
|
-
- 전역에 상시 구성되는 정적 골격 — 앱 구조(메뉴·권한·모듈)·로깅 정책·부트스트랩 초기화.
|
|
214
|
-
|
|
215
|
-
**작성 단위**: §6.x 1개당 위→아래 순서로:
|
|
216
|
-
|
|
217
|
-
1. 목적 / 트리거·적용 범위 (한 묶음).
|
|
218
|
-
2. 참조 매뉴얼 (프레임워크 기본 기능) 또는 본문 자유 서술 (bespoke).
|
|
219
|
-
3. 자유 추가 sub-section (bespoke 가 실제로 요구할 때만) — sub-section 별.
|
|
220
|
-
|
|
221
|
-
**모범**: example-spec.md §6.1·§6.2.
|
|
222
|
-
|
|
223
|
-
### 정의
|
|
224
|
-
|
|
225
|
-
§4 화면·§5 자동 처리에 속하지 않는 모든 개발 단위. §3 기타 요구사항의 시스템 전반 자동 룰을 설계 차원에서 풀이하는 것도 포함. 부수효과로 발동되는 동작과 전역 상시 골격을 모두 포괄하되, 두 성격이 한 항목에 섞일 수 있으므로 미리 가르지 않음.
|
|
226
|
-
|
|
227
|
-
§5 자동 처리와의 차이: §5 = 스케줄·이벤트로 명시적 트리거 (예: 매일 자정·메일 도착). §6 = 명시적 트리거가 없는 것 — 부수효과로 발동되거나 전역에 상시 존재.
|
|
228
|
-
|
|
229
|
-
### 본문 구조
|
|
230
|
-
|
|
231
|
-
§6 은 항목 성격이 제각각인 캐치올이라 §4/§5 같은 고정 sub-section 구조가 없음. 항목은 두 갈래로 작성:
|
|
232
|
-
|
|
233
|
-
- **프레임워크 기본 기능** (앱 구조·로깅·부트스트랩·데이터 변경 이력 등 — 매뉴얼이 존재) → 매뉴얼 참조 stub. 평문 라벨 + `참조 매뉴얼:` 한 줄. 처리·구성·예외 detail 은 매뉴얼로 위임하고 spec 에 적지 않음.
|
|
234
|
-
- **bespoke** (앱 고유 부수효과 — 매뉴얼 없음) → 평문 라벨 + 본문 한두 줄 자유 서술.
|
|
235
|
-
|
|
236
|
-
sub-section 헤더 레벨은 `## spec.md 형식` 의 "sub-section 헤더 레벨" 표 참조.
|
|
237
|
-
|
|
238
|
-
**평문 sub-section** (§6.x 헤더 바로 아래에 "라벨 + 본문" 형식, 위→아래):
|
|
239
|
-
|
|
240
|
-
- `목적:` 도메인 목적 (필수).
|
|
241
|
-
- `트리거·적용 범위:` (해당 시) 어떤 동작의 부수로 발동되는지 / 어디에 상시 적용되는지 + 적용 시점. (예: "모든 엔티티 update 시 / 전체", "앱 부팅 시 / 전체 클라이언트").
|
|
242
|
-
- `관련 섹션:` "본문 내 참조" 절 룰 따름.
|
|
243
|
-
- `참조 매뉴얼:` (프레임워크 기본 기능인 경우) 구현 매뉴얼 파일명 (`.claude/references/sd-simplysm14/manuals/` 기준). 이 줄이 있으면 처리·구성·예외 detail 은 적지 않음.
|
|
244
|
-
|
|
245
|
-
**본문** (bespoke 항목만, 평문 아래에 작성):
|
|
246
|
-
|
|
247
|
-
- 설계 내용을 한두 줄로 자유 서술 — 설계 고도까지만 (구현 디테일은 sd-impl).
|
|
248
|
-
- 처리 절차·모델 매핑·예외 처리 같은 고정 sub-section 은 두지 않음. 양식·매핑 등 정말 필요한 정보만 h4 자유 추가 (이름 자유).
|