@decencia/ch-cli 1.31.1 → 1.31.2
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/agent/2t-decencia-channel-issue-coder.md +1 -1
- package/agent/2t-decencia-channel-pr-merger.md +1 -1
- package/agent/2t-decencia-channel-terraformer.md +1 -1
- package/package.json +1 -1
- package/skill/2t-decencia-channel-change-manager/SKILL.md +1 -1
- package/skill/2t-decencia-channel-change-propagation-v2/SKILL.md +1 -1
- package/skill/2t-decencia-channel-cli-v2/SKILL.md +3 -3
- package/skill/2t-decencia-channel-db-schema-v2/SKILL.md +4 -2
- package/skill/2t-decencia-channel-github-issue/SKILL.md +1 -1
- package/skill/2t-decencia-channel-orchestrator/SKILL.md +1 -1
- package/skill/2t-decencia-channel-policy-v2/SKILL.md +1 -1
- package/skill/2t-decencia-channel-prd-v2/SKILL.md +1 -1
- package/skill/2t-decencia-channel-project-bootstrap/SKILL.md +34 -27
- package/skill/2t-decencia-channel-screen-v2/SKILL.md +2 -2
- package/skill/2t-decencia-channel-spec-v2/SKILL.md +46 -39
- package/skill/2t-decencia-channel-sprint-builder-v2/SKILL.md +1 -1
- package/skill/2t-decencia-channel-sprint-runner/SKILL.md +1 -1
- package/skill/2t-decencia-channel-sqa-v2/SKILL.md +2 -2
- package/skill/2t-decencia-channel-userflow-v2/SKILL.md +1 -1
- package/skill/2t-decencia-channel-work-status-v2/SKILL.md +1 -1
|
@@ -3,7 +3,7 @@ name: 2t-decencia-channel-issue-coder
|
|
|
3
3
|
description: GitHub issue 1개를 입력으로 받아 끝까지 처리하는 코딩 에이전트. 이슈 읽기 → 소통채널 spec/SQA 확인 → git worktree+브랜치에서 구현 → 자체 소프트리뷰 루프 → unittest + SQA → PR 생성 → 소통채널 workStatus·이슈 기록. 다수 병렬 실행 전제, PR까지만(머지·base 브랜치 직접 push·이슈 close는 사람).
|
|
4
4
|
tools: Read, Write, Edit, Grep, Glob, Bash, Agent
|
|
5
5
|
model: opus
|
|
6
|
-
version: 1.31.
|
|
6
|
+
version: 1.31.2
|
|
7
7
|
---
|
|
8
8
|
|
|
9
9
|
## 역할
|
|
@@ -3,7 +3,7 @@ name: 2t-decencia-channel-pr-merger
|
|
|
3
3
|
description: issue-coder가 낸 PR을 기본 완전 자율로 base 브랜치(기본 브랜치 또는 sprint 통합 브랜치)에 머지하는 에이전트. 핵심 역량은 다수 병렬 worktree가 만든 충돌을 작업 의도 기반(semantic)으로 해결하는 것. CI green+충돌없음이면 바로 squash 머지, 충돌이면 의도대로 해결 후 테스트로 검증하여 머지. 재SQA·전면 재리뷰는 하지 않음. 다수 PR은 직렬 머지.
|
|
4
4
|
tools: Read, Write, Edit, Grep, Glob, Bash
|
|
5
5
|
model: opus
|
|
6
|
-
version: 1.31.
|
|
6
|
+
version: 1.31.2
|
|
7
7
|
---
|
|
8
8
|
|
|
9
9
|
## 역할
|
|
@@ -3,7 +3,7 @@ name: 2t-decencia-channel-terraformer
|
|
|
3
3
|
description: 소통채널을 쓰지 않던 기존 코드베이스를 역분석하여 소통채널 프로젝트로 편입(terraforming)하는 자율 에이전트. 코드가 single source of truth — 코드를 읽어 DB 스키마 → 기능명세(spec) → PRD를 bottom-up으로 역생성한다(SQA 제외). 대량 분석은 서브에이전트 병렬, 코드로 못 메우는 의도는 [추정]으로 채우고 "사람확인 질문 리스트"를 산출물로 남긴다. PR/머지·이슈 발행은 하지 않음.
|
|
4
4
|
tools: Read, Write, Edit, Grep, Glob, Bash, Agent
|
|
5
5
|
model: opus
|
|
6
|
-
version: 1.31.
|
|
6
|
+
version: 1.31.2
|
|
7
7
|
---
|
|
8
8
|
|
|
9
9
|
## 역할
|
package/package.json
CHANGED
|
@@ -2,7 +2,7 @@
|
|
|
2
2
|
name: 2t-decencia-channel-change-manager
|
|
3
3
|
description: 기존 소통채널 프로젝트의 기능 추가/수정을 사용자와 대화로 명확화 → 전파 스킬로 연관 PRD/spec/DB/SQA 일괄 갱신 → 변경으로 생긴 새 할일을 GitHub 이슈로 발행하는 오케스트레이터 스킬. (1)대화로 변경 내용 확정 → (2)[게이트] 영향 범위 확인 후 전파 적용 → (3)[게이트] 할일 목록 확인 후 이슈 발행. "이 기능 바꿀래"·"기획 수정"·"이거 추가해줘(기존 프로젝트)" 류 요청 시.
|
|
4
4
|
allowed-tools: Bash(ch:*) Bash(git:*) Bash(gh:*) Read Write
|
|
5
|
-
version: 1.31.
|
|
5
|
+
version: 1.31.2
|
|
6
6
|
---
|
|
7
7
|
|
|
8
8
|
<!-- ch-version-gate -->
|
|
@@ -10,7 +10,7 @@ description: |
|
|
|
10
10
|
(4) ch screens 명령(list/get/create/update/delete/migrate)으로 화면을 다루거나 레거시 프로젝트를 화면 모드로 이관할 때,
|
|
11
11
|
(5) spec의 화면 연결을 CLI로 걸거나 풀 때 (`ch specs screen-refs`),
|
|
12
12
|
(6) Spec ID를 JIRA 스타일(`LOGIN-001`)로 직접 지정할 때 (`ch specs create --id`).
|
|
13
|
-
version: 1.31.
|
|
13
|
+
version: 1.31.2
|
|
14
14
|
---
|
|
15
15
|
|
|
16
16
|
<!-- ch-version-gate -->
|
|
@@ -56,8 +56,7 @@ ch specs create --id AUTH-001 \
|
|
|
56
56
|
--points 5 \
|
|
57
57
|
--story "회원은 이메일과 비밀번호로 로그인해서, 재인증 없이 자신의 프로젝트에 바로 접근하고 싶다." \
|
|
58
58
|
--preconditions ./preconditions.md \
|
|
59
|
-
--logic ./logic.json
|
|
60
|
-
--db-tables tbl_users,tbl_sessions
|
|
59
|
+
--logic ./logic.json
|
|
61
60
|
|
|
62
61
|
# 수정: 지정한 플래그만 PATCH. --no-version 시 버전 기록 생략.
|
|
63
62
|
ch specs update <specId> --story "..." --no-version
|
|
@@ -70,6 +69,7 @@ ch specs update <specId> --points 8 --no-version
|
|
|
70
69
|
- `--domain`은 쉼표로 **복수** 지정 (`--domain 회원,관리자`).
|
|
71
70
|
- `--type`(기능유형)·`--content`는 스토리 명세 모드에서 쓰지 않는다 (레거시 전용).
|
|
72
71
|
- `--ui`는 생성 시 보통 생략한다 — 화면설계서는 spec보다 나중(작성 순서 ④)이라, 화면을 만든 뒤 `ch specs screen-refs`로 연결한다(§1 화면 연결).
|
|
72
|
+
- `--db-tables`·흐름 `refs`도 생성 시 생략한다 — DB 스키마는 ③정책정의서 뒤라, 테이블을 만든 뒤 `ch specs update --db-tables`·`--logic`(refs 보강)으로 연결한다([[2t-decencia-channel-spec-v2]] §10-3).
|
|
73
73
|
|
|
74
74
|
**레거시 모드** (`storySpecsEnabled` 미설정·false — 기존 프로젝트):
|
|
75
75
|
|
|
@@ -8,7 +8,7 @@ description: |
|
|
|
8
8
|
(2) DB 테이블 단위로 컬럼·인덱스·보안규칙을 등록·수정할 때,
|
|
9
9
|
(3) 새 테이블을 추가하면서 전체 인벤토리도 함께 업데이트할 때,
|
|
10
10
|
(4) spec.dbTableRefs와 양방향 동기화가 필요한 작업 시.
|
|
11
|
-
version: 1.31.
|
|
11
|
+
version: 1.31.2
|
|
12
12
|
---
|
|
13
13
|
|
|
14
14
|
<!-- ch-version-gate -->
|
|
@@ -26,7 +26,9 @@ ch check
|
|
|
26
26
|
구버전 스킬·CLI 사용을 막기 위한 게이트다. 건너뛰지 말 것.
|
|
27
27
|
|
|
28
28
|
|
|
29
|
-
# DB 스키마
|
|
29
|
+
# DB 스키마
|
|
30
|
+
|
|
31
|
+
> **작성 순서상 ③정책정의서 뒤 · ④화면설계서 앞이다** — 정책(만료·상태·타임아웃)이 스키마를 결정하므로 정책 확정 후에 설계하고, 화면설계서가 `테이블.컬럼`을 참조하므로 그 앞이어야 한다. 테이블을 만들면 spec을 되짚어 `ch specs update --db-tables`·흐름 refs를 보강한다([[2t-decencia-channel-spec-v2]] §10-3). — 전체 스펙 + per-table 분담
|
|
30
32
|
|
|
31
33
|
소통채널은 두 개의 리소스를 함께 운영한다.
|
|
32
34
|
|
|
@@ -2,7 +2,7 @@
|
|
|
2
2
|
name: 2t-decencia-channel-github-issue
|
|
3
3
|
description: gh CLI로 현재 repo에 GitHub 이슈를 작성한다. 이슈 1개=유형 1개(feat/fix/bug), 표준 본문 양식(작업내용·관련 명세 백링크·완료조건)으로 발행. "이슈 만들어줘"/"깃헙 이슈로 등록해줘" 요청 시, 또는 소통채널 기획·명세 작업 후 처리할 일들을 GitHub 이슈로 옮길 때 사용. 멱등성/중복방지·확인단계는 다루지 않음(요청대로 바로 생성).
|
|
4
4
|
allowed-tools: Bash(gh:*) Bash(git:*) Read Write
|
|
5
|
-
version: 1.31.
|
|
5
|
+
version: 1.31.2
|
|
6
6
|
---
|
|
7
7
|
|
|
8
8
|
<!-- ch-version-gate -->
|
|
@@ -2,7 +2,7 @@
|
|
|
2
2
|
name: 2t-decencia-channel-orchestrator
|
|
3
3
|
description: 소통채널 작업의 단일 진입점(디스패처). 사용자 요청을 듣고 7종(bootstrap·terraformer·change-manager·github-issue·issue-coder·pr-merger·sprint-runner) 중 적절한 곳으로 라우팅하고, 필요하면 여러 단계를 순차 오케스트레이션한다. 대화형 스킬은 메인 세션에서 Skill로, 자율 에이전트는 Agent로 위임. "소통채널 작업 해줘"·"이거 어떻게 처리하지?"처럼 무엇부터 할지 모를 때, 또는 신규기획/코드편입/기획변경/이슈/구현/머지/스프린트실행 어디로든 시작할 때.
|
|
4
4
|
allowed-tools: Skill Agent Read Bash(ch:*) Bash(gh:*) Bash(git:*)
|
|
5
|
-
version: 1.31.
|
|
5
|
+
version: 1.31.2
|
|
6
6
|
---
|
|
7
7
|
|
|
8
8
|
<!-- ch-version-gate -->
|
|
@@ -1,8 +1,8 @@
|
|
|
1
1
|
---
|
|
2
2
|
name: 2t-decencia-channel-project-bootstrap
|
|
3
|
-
description: 신규 기획을 사용자와 대화하며 step-by-step으로 소통채널 프로젝트로 만드는 오케스트레이터 스킬. (1)대화로 PRD 완성 → (2)기능명세(spec) 내용 확정 → (3)
|
|
3
|
+
description: 신규 기획을 사용자와 대화하며 step-by-step으로 소통채널 프로젝트로 만드는 오케스트레이터 스킬. (1)대화로 PRD 완성 → (2)기능명세(spec) 내용 확정 → (3)spec 업로드 → (4)유저플로우 → (5)정책정의서 → (6)DB 스키마·spec 연결 → (7)화면설계서(화면 생성·연결) → (8)검증기준서(SQA). 각 단계 사용자 승인 게이트, 작성 디테일은 기존 2t-decencia-channel-*-v2 스킬을 적극 재사용. "새 기획 만들어줘"·"프로젝트 처음부터 세팅" 류 요청 시.
|
|
4
4
|
allowed-tools: Bash(ch:*) Bash(git:*) Read Write
|
|
5
|
-
version: 1.31.
|
|
5
|
+
version: 1.31.2
|
|
6
6
|
---
|
|
7
7
|
|
|
8
8
|
<!-- ch-version-gate -->
|
|
@@ -27,7 +27,9 @@ ch check
|
|
|
27
27
|
|
|
28
28
|
## 핵심 원칙
|
|
29
29
|
- **각 단계마다 사용자 승인 게이트.** "괜찮다"는 확인 없이는 절대 다음 단계로 넘어가지 않는다. 수정 요청이면 그 단계를 반복.
|
|
30
|
-
- **기획 문서 작성 순서는 고정이다: ①기능명세 → ②유저플로우 → ③정책정의서 → ④화면설계서 → ⑤검증기준서.**
|
|
30
|
+
- **기획 문서 작성 순서는 고정이다: ①기능명세 → ②유저플로우 → ③정책정의서 → ④화면설계서 → ⑤검증기준서.** 기능적 기획(①~③)을 다 끝낸 뒤 개발적 형상(DB·화면)으로 들어간다.
|
|
31
|
+
- **DB 스키마는 ③과 ④ 사이에 끼어든다** — 정책(만료·상태·타임아웃)이 스키마를 결정하므로 정책 뒤가 맞고, "테이블.컬럼"을 참조하는 첫 문서가 화면설계서라 그 앞이어야 한다.
|
|
32
|
+
- **화면·DB 모두 "비워뒀다 나중에 연결"이다** — spec보다 화면을 먼저 만들지 않고(§7에서 연결), 테이블도 먼저 만들지 않는다(§6에서 연결·refs 보강).
|
|
31
33
|
- 작성 디테일은 호출: PRD→`2t-decencia-channel-prd-v2`, 기능명세→`2t-decencia-channel-spec-v2`, 유저플로우→`2t-decencia-channel-userflow-v2`, 정책→`2t-decencia-channel-policy-v2`, 화면→`2t-decencia-channel-screen-v2`(+`cli-v2` §3 screens 명령), DB→`2t-decencia-channel-db-schema-v2`, SQA→`2t-decencia-channel-sqa-v2`, 업로드→`2t-decencia-channel-cli-v2`.
|
|
32
34
|
|
|
33
35
|
## Use when
|
|
@@ -36,14 +38,17 @@ ch check
|
|
|
36
38
|
## 전체 흐름
|
|
37
39
|
|
|
38
40
|
```
|
|
39
|
-
(1) PRD → (2) 기능명세 내용 확정 → (3)
|
|
40
|
-
→ (
|
|
41
|
+
(1) PRD → (2) 기능명세 내용 확정 → (3) spec 업로드(연결 없이)
|
|
42
|
+
→ (4) 유저플로우 → (5) 정책정의서
|
|
43
|
+
→ (6) DB 스키마 + spec 연결(dbTableRefs·흐름 refs 보강)
|
|
44
|
+
→ (7) 화면설계서(화면 생성·연결) → (8) 검증기준서(SQA)
|
|
41
45
|
```
|
|
42
46
|
|
|
43
|
-
(2)~(8)이 기획 문서 작성 순서 ①기능명세→②유저플로우→③정책정의서→④화면설계서→⑤검증기준서에
|
|
47
|
+
(2)~(8)이 기획 문서 작성 순서 ①기능명세→②유저플로우→③정책정의서→④화면설계서→⑤검증기준서에 대응하고, DB 스키마(6)는 ③과 ④ 사이에 끼어든다.
|
|
44
48
|
|
|
45
|
-
-
|
|
46
|
-
-
|
|
49
|
+
- spec은 **테이블·화면 연결 없이** 먼저 올린다. 로직 플로우도 이 시점엔 `refs` 없이 완결 문장으로만 쓴다(서버가 refs의 tableId를 실존 검증하므로).
|
|
50
|
+
- 테이블 연결(`dbTableRefs`)과 흐름 `refs`는 §6에서 `ch specs update`로 보강한다.
|
|
51
|
+
- 화면 연결(`screenRefs`)은 화면을 만든 뒤 §7에서 `ch specs screen-refs`로 건다.
|
|
47
52
|
|
|
48
53
|
---
|
|
49
54
|
|
|
@@ -81,21 +86,13 @@ ch check
|
|
|
81
86
|
- interactionMap·primaryActions·keyInformation·stateTransitions는 쓰지 않는다 — 스토리 명세에 없다.
|
|
82
87
|
- 화면 연결(`screenRefs`)은 지금은 비워둔다. 화면이 아직 없다 — §7에서 연결한다.
|
|
83
88
|
- 레거시 프로젝트(§0-1)는 예외다. 종전 ui/logic 구조([[2t-decencia-channel-spec-v2]] §L)로 쓴다.
|
|
84
|
-
- 이 단계의 산출물은 **기능 목록 + spec 본문 초안**이다. 항목: 이름 · Spec ID(EPIC-NNN) · epic · points · 스토리문장 · 필요 테이블
|
|
85
|
-
- ⚠️ **서버 업로드는 여기서 하지 않는다.** 테이블을 먼저 만들고 §4에서 `dbTableRefs`와 함께 생성한다.
|
|
89
|
+
- 이 단계의 산출물은 **기능 목록 + spec 본문 초안**이다. 항목: 이름 · Spec ID(EPIC-NNN) · epic · points · 스토리문장 · 필요 테이블 후보(§6에서 사용).
|
|
86
90
|
- → **[게이트] 사용자 확인.** OK면 3단계.
|
|
87
91
|
|
|
88
|
-
## 3.
|
|
89
|
-
*(기능명세 승인
|
|
90
|
-
- `2t-decencia-channel-db-schema-v2`로 db-schema(ERD/정책) + db-tables(컬럼·인덱스·보안규칙) 작성.
|
|
91
|
-
- `spec.dbTableRefs` ↔ `dbTable.relatedSpecIds` 양방향.
|
|
92
|
-
- **spec 업로드보다 앞선다.** spec 생성 시 `--db-tables`에 실제 tableId가 필요하기 때문이다([[2t-decencia-channel-spec-v2]] §10-3 — 테이블 먼저, spec 연결은 그 다음).
|
|
93
|
-
- → **[게이트] 사용자 확인.** OK면 4단계.
|
|
94
|
-
|
|
95
|
-
## 4. spec 업로드
|
|
96
|
-
*(테이블이 다 만들어진 뒤)*
|
|
92
|
+
## 3. spec 업로드
|
|
93
|
+
*(기능명세 승인 후)*
|
|
97
94
|
|
|
98
|
-
|
|
95
|
+
spec을 서버에 만든다. **테이블·화면 연결은 싣지 않는다** — DB는 §6, 화면은 §7에서 연결한다.
|
|
99
96
|
|
|
100
97
|
```bash
|
|
101
98
|
ch specs create --id PROJ-001 --name "프로젝트 목록" \
|
|
@@ -103,31 +100,41 @@ ch specs create --id PROJ-001 --name "프로젝트 목록" \
|
|
|
103
100
|
--epic PROJ --points 5 \
|
|
104
101
|
--story "관리자는 진행 중인 프로젝트를 한눈에 보고, 원하는 프로젝트로 바로 들어가고 싶다." \
|
|
105
102
|
--preconditions ./preconditions.md \
|
|
106
|
-
--logic logic.json
|
|
103
|
+
--logic logic.json
|
|
107
104
|
```
|
|
108
105
|
|
|
109
106
|
⚠️ `--device`·`--domain`은 **필수 플래그**다. 값은 `ch specs meta --json`이 준 스키마 안에서 고른다. `--domain`은 쉼표로 복수 지정 가능하다.
|
|
110
107
|
|
|
111
108
|
- `logic.json`은 로직 플로우 시나리오(실패·차단 분기 포함) + businessRules — [[2t-decencia-channel-spec-v2]] §7·§8.
|
|
112
|
-
-
|
|
109
|
+
- ⚠️ **이 시점엔 흐름 `refs`를 넣지 않는다** — 테이블이 아직 없고, 서버가 refs의 tableId를 실존 검증해 400이 난다. 완결 문장으로만 쓰고 §6에서 refs를 보강한다.
|
|
110
|
+
- `--ui`도 넣지 않는다. 화면이 아직 없다 — 연결은 §7에서 `ch specs screen-refs`로 건다.
|
|
113
111
|
- 레거시 프로젝트(§0-1)는 종전 플래그(`--type`·`--content`·`--ui ui.json`)를 그대로 쓴다 — [[2t-decencia-channel-cli-v2]] §1.
|
|
114
|
-
- → **[게이트] 사용자 확인.** OK면
|
|
112
|
+
- → **[게이트] 사용자 확인.** OK면 4단계.
|
|
115
113
|
|
|
116
|
-
##
|
|
114
|
+
## 4. 유저플로우
|
|
117
115
|
*(spec 업로드 후)*
|
|
118
116
|
- [[2t-decencia-channel-userflow-v2]]대로 **분기 있는 여정만** 골라 Mermaid로 그린다 (프로젝트당 3~7장, 해피패스 중앙 일직선).
|
|
119
117
|
- 대상은 PRD·Epic-Story 목록에서 뽑는다: 돈이 흐르는 경로·최빈 경로·역방향·역할별 여정 우선.
|
|
120
118
|
- `ch userflows create --name "<여정>" --file ./flow.mmd`로 업로드. 웹 "유저플로우" 탭에서 확인.
|
|
121
|
-
- → **[게이트] 사용자 확인.** OK면
|
|
119
|
+
- → **[게이트] 사용자 확인.** OK면 5단계.
|
|
122
120
|
|
|
123
|
-
##
|
|
121
|
+
## 5. 정책정의서
|
|
124
122
|
*(유저플로우 후)*
|
|
125
123
|
- [[2t-decencia-channel-policy-v2]]의 3단계: **수확**(유저플로우·로직 플로우의 분기에서 "정해진 게 없는" 질문 발굴) → **확정**(질문마다 선택지 2~4개를 사용자에게 제시해 결정받기 — 임의 결정 금지) → **명문화**(판정 가능한 문장).
|
|
126
124
|
- `ch policies create --id POL-001 --name "<정책명>" --category <영역> --file ./policy.md --related-specs <ids>`로 업로드.
|
|
125
|
+
- → **[게이트] 사용자 확인.** OK면 6단계.
|
|
126
|
+
|
|
127
|
+
## 6. DB 스키마 — 작성 + spec 연결·refs 보강
|
|
128
|
+
*(정책정의서 후에만 — 정책(만료·상태·타임아웃)이 스키마를 결정하므로 이 순서다)*
|
|
129
|
+
|
|
130
|
+
- `2t-decencia-channel-db-schema-v2`로 db-schema(ERD/정책) + db-tables(컬럼·인덱스·보안규칙·stateMachines) 작성. §2의 "필요 테이블 후보"와 §5의 정책(수치·상태)이 입력이다.
|
|
131
|
+
- 테이블이 생겼으니 **spec을 되짚어 연결·보강**한다 (spec마다):
|
|
132
|
+
1. `ch specs update <specId> --db-tables tbl_a,tbl_b` — `dbTableRefs` 연결 (서버가 `dbTable.relatedSpecIds`와 양방향 동기화)
|
|
133
|
+
2. 로직 플로우 `refs` 보강 — `ch specs get <id> --json`으로 logic을 받아 각 단계·노드에 `refs`(tableId·field·direction·toState)를 채우고 `ch specs update <id> --logic <파일>`로 통째 교체 (Read-before-Write — [[2t-decencia-channel-spec-v2]] §10-2)
|
|
127
134
|
- → **[게이트] 사용자 확인.** OK면 7단계.
|
|
128
135
|
|
|
129
136
|
## 7. 화면설계서 — 화면 생성·연결
|
|
130
|
-
*(
|
|
137
|
+
*(DB 스키마 후에만. 레거시 프로젝트는 건너뛴다 — §0-1)*
|
|
131
138
|
|
|
132
139
|
기능들을 **화면에 배치**한다. 화면은 사용자가 실제로 마주하는 단위다.
|
|
133
140
|
화면마다 적을 내용(필수 기재항목 6종·디스크립션 작성규칙·예외상태 4종)은 [[2t-decencia-channel-screen-v2]]를 따른다.
|
|
@@ -9,7 +9,7 @@ description: |
|
|
|
9
9
|
(1) 화면(screens) 문서를 작성·수정할 때,
|
|
10
10
|
(2) 화면의 표시 데이터·액션·입력 검증·예외상태를 기재할 때,
|
|
11
11
|
(3) 웹 "화면" 탭의 IA 트리·화면 상세에 올릴 내용을 쓸 때.
|
|
12
|
-
version: 1.31.
|
|
12
|
+
version: 1.31.2
|
|
13
13
|
---
|
|
14
14
|
|
|
15
15
|
<!-- ch-version-gate -->
|
|
@@ -33,7 +33,7 @@ ch check
|
|
|
33
33
|
|
|
34
34
|
역할 분담: 흐름(시나리오)은 spec([[2t-decencia-channel-spec-v2]] §7), 여정 갈림길은 유저플로우([[2t-decencia-channel-userflow-v2]]), 횡단 정책은 정책정의서([[2t-decencia-channel-policy-v2]]). 화면설계서는 **그 화면 안에서 보이는 것·눌리는 것**만 적는다.
|
|
35
35
|
|
|
36
|
-
> **작성 순서상 ④다** — ①기능명세 → ②유저플로우 →
|
|
36
|
+
> **작성 순서상 ④다** — ①기능명세 → ②유저플로우 → ③정책정의서 → DB 스키마가 끝난 뒤에 화면을 만든다. **spec보다 화면을 먼저 만들지 않는다.** 화면을 만들면서 `ch specs screen-refs <specId> --screens <ids>`로 기존 spec들과 연결하고, 그다음 ⑤검증기준서로 넘어간다. (영역별 표시 데이터의 `테이블.컬럼` 참조는 DB 스키마가 앞서 있어야 쓸 수 있다.)
|
|
37
37
|
|
|
38
38
|
## 1. 필수 기재항목
|
|
39
39
|
|
|
@@ -12,7 +12,7 @@ description: |
|
|
|
12
12
|
(3) 스토리문장·사전 조건·로직 플로우·비즈니스 규칙을 작성할 때,
|
|
13
13
|
(4) Story 규모를 Story Point(`--points`)로 매길 때,
|
|
14
14
|
(5) 신규 spec ID를 `AUTH-001` 같은 JIRA 스타일로 부여할 때 (`ch specs create --id`).
|
|
15
|
-
version: 1.31.
|
|
15
|
+
version: 1.31.2
|
|
16
16
|
---
|
|
17
17
|
|
|
18
18
|
<!-- ch-version-gate -->
|
|
@@ -34,8 +34,8 @@ ch check
|
|
|
34
34
|
|
|
35
35
|
CLI 명령은 [[2t-decencia-channel-cli-v2]], DB 테이블 작성은 [[2t-decencia-channel-db-schema-v2]] 참조.
|
|
36
36
|
|
|
37
|
-
> **기획 문서 작성 순서**: ①기능명세(이 문서) → ②유저플로우 → ③정책정의서 → ④화면설계서 → ⑤검증기준서.
|
|
38
|
-
>
|
|
37
|
+
> **기획 문서 작성 순서**: ①기능명세(이 문서) → ②유저플로우 → ③정책정의서 → (DB 스키마) → ④화면설계서 → ⑤검증기준서.
|
|
38
|
+
> **화면도 테이블도 먼저 만들지 않는다** — spec 작성 시점에 둘 다 없는 게 정상이다. DB는 ③ 뒤에 만들어 `--db-tables`·흐름 refs를 보강하고(§10), 화면은 ④에서 만들어 `ch specs screen-refs`로 연결한다(§9).
|
|
39
39
|
|
|
40
40
|
---
|
|
41
41
|
|
|
@@ -198,7 +198,10 @@ Story가 무엇인지 **As a / I want / So that** 형식의 줄글로 적는다.
|
|
|
198
198
|
|
|
199
199
|
## 7. 로직 플로우 (dataFlowScenarios)
|
|
200
200
|
|
|
201
|
-
동작 경로를 **시나리오 단위**로 적는다. 정상·예외를 따로 나누지 않는다 — **실패·차단·이탈 경로는 흐름 안의 분기로 포함**한다(
|
|
201
|
+
동작 경로를 **시나리오 단위**로 적는다. 정상·예외를 따로 나누지 않는다 — **실패·차단·이탈 경로는 흐름 안의 분기로 포함**한다(분기는 nodes/edges — §7-2).
|
|
202
|
+
|
|
203
|
+
- **별도 시나리오는 진입점이 다를 때만** 판다 — 다른 트리거·다른 액터·다른 시작 상태일 때. **같은 진입에서 조건으로 갈라지는 것(실패·차단·타임아웃·품절)은 전부 그 시나리오의 분기다.**
|
|
204
|
+
- 권장: **spec당 시나리오 1~3개.** 4개 이상이면 먼저 분기로 합칠 수 있는지 본다.
|
|
202
205
|
|
|
203
206
|
시나리오는 두 방식 중 하나로 쓴다. 선형이면 **순서 있는 단계(steps)**, 분기가 있으면 **분기 그래프(nodes/edges)**(§7-2). 각 단계·노드는 건드리는 테이블·컬럼을 `refs`로 가리킨다. steps와 nodes가 둘 다 비면 무효다.
|
|
204
207
|
|
|
@@ -227,20 +230,13 @@ Story가 무엇인지 **As a / I want / So that** 형식의 줄글로 적는다.
|
|
|
227
230
|
]
|
|
228
231
|
}
|
|
229
232
|
]
|
|
230
|
-
},
|
|
231
|
-
{
|
|
232
|
-
"name": "비밀번호 5회 실패로 잠금",
|
|
233
|
-
"description": "비밀번호를 5회 연속 틀리면 계정을 1시간 잠그고 로그인 시도를 차단한다.",
|
|
234
|
-
"steps": [
|
|
235
|
-
{ "description": "5회째 실패를 감지하면 계정 문서에 잠금 해제 시각을 기록한다.",
|
|
236
|
-
"refs": [ { "tableId": "tbl_users", "field": "lockedUntil", "direction": "WRITE" } ] },
|
|
237
|
-
{ "description": "잠금 중 로그인 시도에는 남은 잠금 시간을 안내하고 인증을 수행하지 않는다." }
|
|
238
|
-
]
|
|
239
233
|
}
|
|
240
234
|
]
|
|
241
235
|
}
|
|
242
236
|
```
|
|
243
237
|
|
|
238
|
+
> 로그인 실패·잠금 경로를 별도 시나리오로 파지 않는다 — 같은 진입이므로 **분기**다. 분기가 있는 순간 이 시나리오는 §7-2의 그래프로 옮긴다(아래 예시가 바로 그것).
|
|
239
|
+
|
|
244
240
|
구조:
|
|
245
241
|
|
|
246
242
|
| 필드 | 타입 | 의미 |
|
|
@@ -259,33 +255,43 @@ Story가 무엇인지 **As a / I want / So that** 형식의 줄글로 적는다.
|
|
|
259
255
|
- ⭕ `회원이 이메일과 비밀번호로 로그인하면, 인증 서버가 자격 증명을 확인한 뒤 마지막 로그인 시각을 갱신한다.`
|
|
260
256
|
- 한 단계 = 데이터가 한 번 이동·변형하는 매듭(외부 API 호출도 한 단계). 너무 잘게 쪼개지 않는다.
|
|
261
257
|
- 🔒 컬럼은 **이름으로만** 가리킨다. type/nullable 등 정의는 적지 않는다 (§10-1 SSOT 규칙).
|
|
258
|
+
- **spec 작성 시점(DB 스키마 전)에는 `refs`를 넣지 않는다** — 서버가 tableId를 실존 검증해 400이 난다. 완결 문장으로만 쓰고, DB 스키마 단계에서 refs를 보강한다(§10-3).
|
|
262
259
|
|
|
263
260
|
### 7-2. 분기 그래프 (nodes/edges)
|
|
264
261
|
|
|
265
262
|
흐름이 조건에 따라 갈리면 steps 대신 노드·간선으로 그린다. 성공·실패가 한 그래프에서 갈리면 시나리오 하나로 묶는다.
|
|
266
263
|
|
|
267
|
-
- **node**: `id`(시나리오 안 유일, 필수) · `kind`(`step` 기본 · `decision` 조건 갈림 · `terminal` 종료) · `description`(완결 문장, 필수) · `refs[]`(선택, §10-2)
|
|
264
|
+
- **node**: `id`(시나리오 안 유일, 필수 — `n1·d1·t1` 순번이면 충분하다) · `kind`(`step` 기본 · `decision` 조건 갈림 · `terminal` 종료) · `description`(완결 문장, 필수) · `refs[]`(선택, §10-2)
|
|
268
265
|
- **edge**: `from`/`to`(노드 id, 필수) · `label`(분기 조건 — decision에서 갈라지는 edge마다 붙인다)
|
|
269
266
|
- 선형이면 steps, 분기면 nodes/edges — 둘 중 하나로만(둘 다 비면 무효). 상태 컬럼을 WRITE하는 ref는 `toState`로 목표 상태를 명시한다(§10-2).
|
|
270
267
|
|
|
268
|
+
예시 — §7-1의 로그인을 분기까지 담아 **시나리오 하나**로 그린 것이다(성공·재입력·잠금을 시나리오 셋으로 나누지 않는다):
|
|
269
|
+
|
|
271
270
|
```json
|
|
272
271
|
{
|
|
273
272
|
"dataFlowScenarios": [
|
|
274
273
|
{
|
|
275
|
-
"name": "
|
|
274
|
+
"name": "로그인",
|
|
276
275
|
"nodes": [
|
|
277
|
-
{ "id": "n1", "kind": "step", "description": "
|
|
278
|
-
{ "id": "d1", "kind": "decision", "description": "
|
|
279
|
-
{ "id": "n2", "kind": "step", "description": "
|
|
280
|
-
"refs": [{ "tableId": "
|
|
281
|
-
{ "id": "
|
|
282
|
-
{ "id": "
|
|
276
|
+
{ "id": "n1", "kind": "step", "description": "회원이 입력한 이메일과 비밀번호를 인증 서버로 보낸다." },
|
|
277
|
+
{ "id": "d1", "kind": "decision", "description": "자격 증명이 유효한가?" },
|
|
278
|
+
{ "id": "n2", "kind": "step", "description": "ID 토큰을 발급하고 마지막 로그인 시각을 갱신한다.",
|
|
279
|
+
"refs": [{ "tableId": "tbl_users", "field": "lastLoginAt", "direction": "WRITE" }] },
|
|
280
|
+
{ "id": "t1", "kind": "terminal", "description": "로그인 완료 — 대시보드 진입" },
|
|
281
|
+
{ "id": "d2", "kind": "decision", "description": "연속 실패가 5회째인가?" },
|
|
282
|
+
{ "id": "n3", "kind": "step", "description": "계정을 1시간 잠그고 잠금 해제 시각을 기록한다.",
|
|
283
|
+
"refs": [{ "tableId": "tbl_users", "field": "lockedUntil", "direction": "WRITE" }] },
|
|
284
|
+
{ "id": "t2", "kind": "terminal", "description": "잠금 안내 후 종료" },
|
|
285
|
+
{ "id": "t3", "kind": "terminal", "description": "오류 표시 후 재입력 대기" }
|
|
283
286
|
],
|
|
284
287
|
"edges": [
|
|
285
288
|
{ "from": "n1", "to": "d1" },
|
|
286
|
-
{ "from": "d1", "to": "n2", "label": "
|
|
287
|
-
{ "from": "
|
|
288
|
-
{ "from": "
|
|
289
|
+
{ "from": "d1", "to": "n2", "label": "유효" },
|
|
290
|
+
{ "from": "n2", "to": "t1" },
|
|
291
|
+
{ "from": "d1", "to": "d2", "label": "무효" },
|
|
292
|
+
{ "from": "d2", "to": "n3", "label": "5회째" },
|
|
293
|
+
{ "from": "n3", "to": "t2" },
|
|
294
|
+
{ "from": "d2", "to": "t3", "label": "5회 미만" }
|
|
289
295
|
]
|
|
290
296
|
}
|
|
291
297
|
]
|
|
@@ -337,7 +343,7 @@ Story가 무엇인지 **As a / I want / So that** 형식의 줄글로 적는다.
|
|
|
337
343
|
|
|
338
344
|
### 10-1. 흐름과 SSOT 규칙
|
|
339
345
|
|
|
340
|
-
|
|
346
|
+
**DB 스키마는 작성 순서상 ③정책정의서 뒤·④화면설계서 앞이다** — 정책이 스키마를 결정하기 때문이다. spec 생성 시점에는 `dbTableRefs`를 비워두고, DB 단계에서 테이블을 만든 뒤(`ch db-tables create`) `ch specs update --db-tables tbl_a,tbl_b`로 연결한다. 서버가 `spec.dbTableRefs` ↔ `table.relatedSpecIds`를 양방향 동기화한다.
|
|
341
347
|
|
|
342
348
|
- **spec** = 이 Story가 어느 테이블·컬럼을 R/W하는가 — 흐름의 `refs`로 **이름 참조만**
|
|
343
349
|
- **db-tables** = 컬럼 정의·인덱스·보안 규칙·상태머신 (스키마의 SSOT — [[2t-decencia-channel-db-schema-v2]])
|
|
@@ -351,13 +357,16 @@ Story가 무엇인지 **As a / I want / So that** 형식의 줄글로 적는다.
|
|
|
351
357
|
- **`toState`** — `field`가 그 테이블 `stateMachines[].columnRef`와 같으면 상태머신 접근이다. WRITE면 목표 상태를 `toState`로 밝힌다(값은 그 머신 `states[].value` 중 하나).
|
|
352
358
|
- 레거시 `dataFlowRefs`/`businessRuleRefs`(logic 최상위)는 하위호환으로 읽히지만, 신규·수정 시에는 단계·노드의 refs로 옮긴다.
|
|
353
359
|
|
|
354
|
-
### 10-3.
|
|
360
|
+
### 10-3. DB 단계에서의 연결·refs 보강 절차
|
|
361
|
+
|
|
362
|
+
DB 스키마 단계(③ 뒤)에서 spec마다 되짚어 보강한다:
|
|
355
363
|
|
|
356
364
|
```bash
|
|
357
|
-
ch db-tables create --name users --columns ./cols.json ...
|
|
358
|
-
ch specs
|
|
359
|
-
|
|
360
|
-
|
|
365
|
+
ch db-tables create --name users --columns ./cols.json ... # 1) 테이블 생성 → {"id":"tbl_xyz"}
|
|
366
|
+
ch specs update <specId> --db-tables tbl_xyz,tbl_abc # 2) dbTableRefs 연결 (통째 교체)
|
|
367
|
+
ch specs get <specId> --json > spec.json # 3) 흐름 refs 보강 — Read-before-Write
|
|
368
|
+
# logic의 각 단계·노드에 refs(tableId·field·direction·toState) 채워 넣기
|
|
369
|
+
ch specs update <specId> --logic ./logic-with-refs.json --no-version
|
|
361
370
|
```
|
|
362
371
|
|
|
363
372
|
---
|
|
@@ -410,10 +419,9 @@ ch specs get <specId> --json | jq '.logic' # 3) 검증
|
|
|
410
419
|
4. **Epic 코드 결정**(§3) → **Spec ID 결정**(§4, `EPIC-NNN`)
|
|
411
420
|
5. `points` 산정 (§11, 보통 3~8)
|
|
412
421
|
6. 스토리문장(§5)·사전 조건(§6) 작성
|
|
413
|
-
7. `logic.json` 작성 — 로직 플로우 시나리오(실패·차단 분기 포함, §7), businessRules(§8)
|
|
414
|
-
8.
|
|
415
|
-
9.
|
|
416
|
-
10. 생성:
|
|
422
|
+
7. `logic.json` 작성 — 로직 플로우 시나리오(실패·차단 분기 포함, §7), businessRules(§8). **refs는 넣지 않는다**(테이블이 아직 없다 — §10-3에서 보강)
|
|
423
|
+
8. **DB·화면 연결은 여기서 하지 않는다** — DB 스키마 단계(③ 뒤)에서 `--db-tables`·refs 보강(§10-3), 화면설계서 단계(④)에서 `ch specs screen-refs` 연결(§9)
|
|
424
|
+
9. 생성:
|
|
417
425
|
|
|
418
426
|
```bash
|
|
419
427
|
ch specs create --id AUTH-001 --name "로그인" \
|
|
@@ -421,13 +429,12 @@ ch specs create --id AUTH-001 --name "로그인" \
|
|
|
421
429
|
--epic AUTH --points 5 \
|
|
422
430
|
--story "회원은 이메일과 비밀번호로 로그인해서, 재인증 없이 자신의 프로젝트에 바로 접근하고 싶다." \
|
|
423
431
|
--preconditions ./preconditions.md \
|
|
424
|
-
--logic ./logic.json
|
|
425
|
-
--db-tables tbl_users,tbl_sessions
|
|
432
|
+
--logic ./logic.json
|
|
426
433
|
```
|
|
427
434
|
|
|
428
|
-
|
|
429
|
-
|
|
430
|
-
|
|
435
|
+
10. `ch specs get <id> --json`으로 결과 검증
|
|
436
|
+
11. 이후 문서는 작성 순서대로: 유저플로우(②) → 정책정의서(③) → DB 스키마(이때 dbTableRefs·refs 보강) → 화면설계서(④, 이때 화면 연결) → 검증기준서(⑤, [[2t-decencia-channel-sqa-v2]])
|
|
437
|
+
12. 개발 착수 후 진행 일지는 [[2t-decencia-channel-work-status-v2]]
|
|
431
438
|
|
|
432
439
|
---
|
|
433
440
|
|
|
@@ -2,7 +2,7 @@
|
|
|
2
2
|
name: 2t-decencia-channel-sprint-runner
|
|
3
3
|
description: 특정 Sprint를 끝까지 실행(run)하는 오케스트레이터 스킬. Sprint의 spec을 시드로 이슈 목록을 분해·발행(github-issue)하고, GitHub milestone에 묶인 이슈를 상태별로 분류해 issue-coder(병렬)·pr-merger(직렬)로 전진시킨 뒤, 사람확인이 필요한 곳에서 멈춘다. 사람이 확인·체크 후 재호출하면 멱등하게 이어간다(반복 루프). "스프린트 돌려줘"·"sprint N 실행"·"이 스프린트 개발 진행해줘" 류 요청 시.
|
|
4
4
|
allowed-tools: Skill Agent Read Bash(ch:*) Bash(gh:*) Bash(git:*)
|
|
5
|
-
version: 1.31.
|
|
5
|
+
version: 1.31.2
|
|
6
6
|
---
|
|
7
7
|
|
|
8
8
|
<!-- ch-version-gate -->
|
|
@@ -12,7 +12,7 @@ description: |
|
|
|
12
12
|
(4) 보안/성능/접근성/호환성 비기능 TC를 시트에 채워야 할 때,
|
|
13
13
|
(5) 명세 영역별 완성형 TC 번들(퍼블리싱/프론트/백엔드 디센시아 운영 관점 포함)을 가져다 쓸 때,
|
|
14
14
|
(6) Sprint 종료 전 spec별 TC 통과·시나리오 통과 여부를 점검할 때.
|
|
15
|
-
version: 1.31.
|
|
15
|
+
version: 1.31.2
|
|
16
16
|
---
|
|
17
17
|
|
|
18
18
|
<!-- ch-version-gate -->
|
|
@@ -32,7 +32,7 @@ ch check
|
|
|
32
32
|
|
|
33
33
|
# SQA(검증기준서) — TC 검증 + 시나리오 검증
|
|
34
34
|
|
|
35
|
-
**작성 순서상 ⑤(마지막)다** —
|
|
35
|
+
**작성 순서상 ⑤(마지막)다** — ①기능명세·②유저플로우·③정책정의서·DB 스키마·④화면설계서가 갖춰진 뒤에 TC(spec에서)·시나리오(유저플로우에서)를 도출한다.
|
|
36
36
|
|
|
37
37
|
## 0. Read-before-Write
|
|
38
38
|
|