@decencia/ch-cli 1.33.3 → 1.33.5

package/agent/2t-decencia-channel-issue-coder.md

@@ -3,7 +3,7 @@ name: 2t-decencia-channel-issue-coder
 description: GitHub issue 1개를 입력으로 받아 끝까지 처리하는 코딩 에이전트. 이슈 읽기 → 소통채널 spec/SQA 확인 → git worktree+브랜치에서 구현 → 자체 소프트리뷰 루프 → unittest + SQA → PR 생성 → 소통채널 workStatus·이슈 기록. 다수 병렬 실행 전제, PR까지만(머지·base 브랜치 직접 push·이슈 close는 사람).
 tools: Read, Write, Edit, Grep, Glob, Bash, Agent
 model: opus
-version: 1.33.3
+version: 1.33.5
 ---
 
 ## 역할

package/agent/2t-decencia-channel-pr-merger.md

@@ -3,7 +3,7 @@ name: 2t-decencia-channel-pr-merger
 description: issue-coder가 낸 PR을 기본 완전 자율로 base 브랜치(기본 브랜치 또는 sprint 통합 브랜치)에 머지하는 에이전트. 핵심 역량은 다수 병렬 worktree가 만든 충돌을 작업 의도 기반(semantic)으로 해결하는 것. CI green+충돌없음이면 바로 squash 머지, 충돌이면 의도대로 해결 후 테스트로 검증하여 머지. 재SQA·전면 재리뷰는 하지 않음. 다수 PR은 직렬 머지.
 tools: Read, Write, Edit, Grep, Glob, Bash
 model: opus
-version: 1.33.3
+version: 1.33.5
 ---
 
 ## 역할

package/agent/2t-decencia-channel-terraformer.md

@@ -3,7 +3,7 @@ name: 2t-decencia-channel-terraformer
 description: 소통채널을 쓰지 않던 기존 코드베이스를 역분석하여 소통채널 프로젝트로 편입(terraforming)하는 자율 에이전트. 코드가 single source of truth — 코드를 읽어 DB 스키마 → 기능명세(spec) → PRD를 bottom-up으로 역생성한다(SQA 제외). 대량 분석은 서브에이전트 병렬, 코드로 못 메우는 의도는 [추정]으로 채우고 "사람확인 질문 리스트"를 산출물로 남긴다. PR/머지·이슈 발행은 하지 않음.
 tools: Read, Write, Edit, Grep, Glob, Bash, Agent
 model: opus
-version: 1.33.3
+version: 1.33.5
 ---
 
 ## 역할

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "@decencia/ch-cli",
-  "version": "1.33.3",
+  "version": "1.33.5",
   "description": "Decencia Communication Channel CLI",
   "main": "dist/index.js",
   "bin": {

package/skill/2t-decencia-channel-change-manager/SKILL.md

@@ -2,7 +2,7 @@
 name: 2t-decencia-channel-change-manager
 description: 기존 소통채널 프로젝트의 기능 추가/수정을 사용자와 대화로 명확화 → 전파 스킬로 연관 PRD/spec/DB/SQA 일괄 갱신 → 변경으로 생긴 새 할일을 GitHub 이슈로 발행하는 오케스트레이터 스킬. (1)대화로 변경 내용 확정 → (2)[게이트] 영향 범위 확인 후 전파 적용 → (3)[게이트] 할일 목록 확인 후 이슈 발행. "이 기능 바꿀래"·"기획 수정"·"이거 추가해줘(기존 프로젝트)" 류 요청 시.
 allowed-tools: Bash(ch:*) Bash(git:*) Bash(gh:*) Read Write
-version: 1.33.3
+version: 1.33.5
 ---
 
 <!-- ch-version-gate -->

package/skill/2t-decencia-channel-change-propagation-v2/SKILL.md

@@ -10,7 +10,7 @@ description: |
   (3) 명세·DB·SQA가 서로 어긋나 있는 의심이 들 때 (정합성 점검),
   (4) PRD 갱신 후 하위 spec/db/SQA로 변경분을 흘려보내야 할 때,
   (5) Sprint 진행 중 도메인 규칙·스키마가 흔들렸을 때 연쇄 갱신이 필요할 때.
-version: 1.33.3
+version: 1.33.5
 ---
 
 <!-- ch-version-gate -->

package/skill/2t-decencia-channel-cli-v2/SKILL.md

@@ -10,7 +10,7 @@ description: |
   (4) ch screens 명령(list/get/create/update/delete/migrate)으로 화면을 다루거나 레거시 프로젝트를 화면 모드로 이관할 때,
   (5) spec의 화면 연결을 CLI로 걸거나 풀 때 (`ch specs screen-refs`),
   (6) Spec ID를 JIRA 스타일(`LOGIN-001`)로 직접 지정할 때 (`ch specs create --id`).
-version: 1.33.3
+version: 1.33.5
 ---
 
 <!-- ch-version-gate -->

package/skill/2t-decencia-channel-db-schema-v2/SKILL.md

@@ -8,7 +8,7 @@ description: |
   (2) DB 테이블 단위로 컬럼·인덱스·보안규칙을 등록·수정할 때,
   (3) 새 테이블을 추가하면서 전체 인벤토리도 함께 업데이트할 때,
   (4) spec.dbTableRefs와 양방향 동기화가 필요한 작업 시.
-version: 1.33.3
+version: 1.33.5
 ---
 
 <!-- ch-version-gate -->

package/skill/2t-decencia-channel-github-issue/SKILL.md

@@ -2,7 +2,7 @@
 name: 2t-decencia-channel-github-issue
 description: gh CLI로 현재 repo에 GitHub 이슈를 작성한다. 이슈 1개=유형 1개(feat/fix/bug), 표준 본문 양식(작업내용·관련 명세 백링크·완료조건)으로 발행. "이슈 만들어줘"/"깃헙 이슈로 등록해줘" 요청 시, 또는 소통채널 기획·명세 작업 후 처리할 일들을 GitHub 이슈로 옮길 때 사용. 멱등성/중복방지·확인단계는 다루지 않음(요청대로 바로 생성).
 allowed-tools: Bash(gh:*) Bash(git:*) Read Write
-version: 1.33.3
+version: 1.33.5
 ---
 
 <!-- ch-version-gate -->

package/skill/2t-decencia-channel-ia-v2/SKILL.md

@@ -3,7 +3,7 @@ name: 2t-decencia-channel-ia-v2
 description: |
   [2t][v2] 소통채널 화면 IA(정보구조) 설계. 화면들의 도달 구조를 트리로 세운다 — 관문이 부모다.
   Use when: (1) 화면설계서 전에 화면 배치를 정할 때, (2) 기존 IA 재배치를 검토할 때.
-version: 1.33.3
+version: 1.33.5
 ---
 
 <!-- ch-version-gate -->

package/skill/2t-decencia-channel-orchestrator/SKILL.md

@@ -2,7 +2,7 @@
 name: 2t-decencia-channel-orchestrator
 description: 소통채널 작업의 단일 진입점(디스패처). 사용자 요청을 듣고 7종(bootstrap·terraformer·change-manager·github-issue·issue-coder·pr-merger·sprint-runner) 중 적절한 곳으로 라우팅하고, 필요하면 여러 단계를 순차 오케스트레이션한다. 대화형 스킬은 메인 세션에서 Skill로, 자율 에이전트는 Agent로 위임. "소통채널 작업 해줘"·"이거 어떻게 처리하지?"처럼 무엇부터 할지 모를 때, 또는 신규기획/코드편입/기획변경/이슈/구현/머지/스프린트실행 어디로든 시작할 때.
 allowed-tools: Skill Agent Read Bash(ch:*) Bash(gh:*) Bash(git:*)
-version: 1.33.3
+version: 1.33.5
 ---
 
 <!-- ch-version-gate -->

package/skill/2t-decencia-channel-policy-v2/SKILL.md

@@ -8,7 +8,7 @@ description: |
   (1) 정책정의서를 새로 쓰거나 수정할 때,
   (2) 유저플로우·기능명세를 검토하다 "이건 정해진 게 없다"는 질문이 나왔을 때,
   (3) 알림 발송 매트릭스·크레딧 지급 기준·타임아웃 처리 같은 횡단 정책을 정리할 때.
-version: 1.33.3
+version: 1.33.5
 ---
 
 <!-- ch-version-gate -->

package/skill/2t-decencia-channel-prd-v2/SKILL.md

@@ -7,7 +7,7 @@ description: |
   (1) PRD를 작성하거나 갱신할 때,
   (2) PRD 구성에서 Epic/스토리 구조를 후속 spec 작성에 매핑할 때,
   (3) Read-before-Write 규칙으로 PRD content를 안전하게 수정해야 할 때.
-version: 1.33.3
+version: 1.33.5
 ---
 
 <!-- ch-version-gate -->

package/skill/2t-decencia-channel-project-bootstrap/SKILL.md

@@ -2,7 +2,7 @@
 name: 2t-decencia-channel-project-bootstrap
 description: 신규 기획을 사용자와 대화하며 step-by-step으로 소통채널 프로젝트로 만드는 오케스트레이터 스킬. (1)대화로 PRD 완성 → (2)기능명세(spec) 내용 확정 → (3)spec 업로드 → (4)유저플로우 → (5)정책정의서 → (6)DB 스키마·spec 연결 → (7)화면설계서(화면 생성·연결) → (8)검증기준서(SQA). 각 단계 사용자 승인 게이트, 작성 디테일은 기존 2t-decencia-channel-*-v2 스킬을 적극 재사용. "새 기획 만들어줘"·"프로젝트 처음부터 세팅" 류 요청 시.
 allowed-tools: Bash(ch:*) Bash(git:*) Read Write
-version: 1.33.3
+version: 1.33.5
 ---
 
 <!-- ch-version-gate -->
@@ -111,7 +111,7 @@ ch specs create --id PROJ-001 --name "프로젝트 목록" \
 - ⚠️ **이 시점엔 흐름 `refs`를 넣지 않는다** — 테이블이 아직 없고, 서버가 refs의 tableId를 실존 검증해 400이 난다. 완결 문장으로만 쓰고 §6에서 refs를 보강한다.
 - `--ui`도 넣지 않는다. 화면이 아직 없다 — 연결은 §8에서 `ch specs screen-refs`로 건다.
 - 레거시 프로젝트(§0-1)는 종전 플래그(`--type`·`--content`·`--ui ui.json`)를 그대로 쓴다 — [[2t-decencia-channel-cli-v2]] §1.
-- **spec마다 Story TC 2겹을 함께 등록한다** — 해피패스(결과 상태까지)+실패 분기당 1개, Story당 2~5개([[2t-decencia-channel-sqa-v2]] §2). SQA 시트가 없으면 `ch sqa create`로 먼저 만든다. 권한·상태 누적 검증은 여기서 하지 않는다(§9의 시나리오·B축 몫).
+- **spec마다 Testable 자문만 한다** — 이 스토리로 통과/실패를 판정하는 TC 문장이 나오는가? 안 나오면 스토리를 다시 쓰거나 쪼갠다([[2t-decencia-channel-spec-v2]] §13-11). **TC 등록은 여기서 하지 않는다** — §9 검증기준서에서 A축·B축·시나리오를 일괄 등록한다.
 - → **[게이트] 사용자 확인.** OK면 4단계.
 
 ## 4. 유저플로우
@@ -242,8 +242,8 @@ ch specs screen-refs PROJ-002 --screens SCR-PROJECTS,SCR-PROJECT-DETAIL   # 화
 탭·모달·바텀시트는 별도 화면이 아니다. 그 화면의 `states`·`entryPoints`로 적는다.
 
 ## 9. 검증기준서 (SQA)
-*(화면 연결 후에만 — 작성 순서 마지막. Story TC는 §3에서 이미 등록됨)*
-- `2t-decencia-channel-sqa-v2`로 마무리한다: **시나리오**(§4.6 — 유저플로우 기반 5~10개, 역할별 여정·상태 누적 확인 포인트, 대응 TC 등록·매핑, Sprint 완료조건으로 할당) + **B축**(비기능 핵심 9개) + **§4.5 커버리지 게이트**(전 spec에 TC 2겹이 있는지 최종 검증).
+*(화면 연결 후에만 — 작성 순서 마지막. SQA 전체를 여기서 한번에 쓴다)*
+- `2t-decencia-channel-sqa-v2`로 마무리한다(시트가 없으면 `ch sqa create` 먼저): **A축(Story TC 2겹)**(§2 — spec당 2~5개, 플로우 있으면 분기당·없으면 규칙당, 여정형은 유저플로우 분기당) + **B축**(비기능 핵심 9개) + **시나리오**(§4.6 — 유저플로우 기반 5~10개, 역할별 여정·상태 누적 확인 포인트, 대응 TC 등록·매핑, Sprint 완료조건으로 할당) + **§4.5 커버리지 게이트**(전 spec에 TC 2겹이 있는지 최종 검증).
 
 ### 디자인 핸드오프로 이어가기 (안내만)
 화면이 다 짜였으면 **디자인 핸드오프**로 넘어갈 수 있다. 디자이너가 웹 화면 탭 **[통합 핸드오프 zip 받기]** 또는 `ch handoff export --dir <폴더>`로 화면 기획 묶음을 받아 Claude Design에 넣는다. 절차는 `docs/design-handoff-sop.md`. 읽기전용 export라 이 스킬이 대신 실행하지 않는다 — 화면이 막 만들어진 이 지점에서 **사용자에게 안내만** 한다. (명령 상세는 [[2t-decencia-channel-cli-v2]] handoff 명령.)

package/skill/2t-decencia-channel-screen-v2/SKILL.md

@@ -9,7 +9,7 @@ description: |
   (1) 화면(screens) 문서를 작성·수정할 때,
   (2) 화면의 표시 데이터·액션·입력 검증·예외상태를 기재할 때,
   (3) 웹 "화면" 탭의 화면 구조 뷰·화면 상세에 올릴 내용을 쓸 때.
-version: 1.33.3
+version: 1.33.5
 ---
 
 <!-- ch-version-gate -->

package/skill/2t-decencia-channel-spec-v2/SKILL.md

@@ -3,7 +3,7 @@ name: 2t-decencia-channel-spec-v2
 description: |
   [2t][v2] 소통채널 기능명세(=Story) 작성/수정 표준.
   스토리 명세 구조(storySpecsEnabled)가 기본이다: 사용자 스토리(As a/I want/So that)·사전 조건·
-  로직 플로우(복잡 spec에만 선별 작성 — §7-0)·비즈니스 규칙·화면 연결·DB 참조.
+  로직 플로우(시스템 동작이 주체인 spec에만 선별 작성, 유저플로우와 동형 금지 — §7-0)·비즈니스 규칙·화면 연결·DB 참조.
   Story 분해는 INVEST + 수직 분할(§2), Epic은 도메인 단위 코드(AUTH/ORDER 등, §3).
   레거시(ui/logic 섹션) 프로젝트 규칙은 §L 부록 — 기존 프로젝트는 영향받지 않는다.
   Use when:
@@ -12,7 +12,7 @@ description: |
   (3) 사용자 스토리·사전 조건·로직 플로우·비즈니스 규칙을 작성할 때,
   (4) Story 규모를 Story Point(`--points`)로 매길 때,
   (5) 신규 spec ID를 `AUTH-001` 같은 JIRA 스타일로 부여할 때 (`ch specs create --id`).
-version: 1.33.3
+version: 1.33.5
 ---
 
 <!-- ch-version-gate -->
@@ -202,25 +202,31 @@ Story가 무엇인지 **As a / I want / So that** 형식의 줄글로 적는다.
 
 ### 7-0. 먼저 — 쓸지 말지부터 정한다 (선별 작성)
 
-**로직 플로우는 검수 비용이 비싸다. 복잡한 흐름이 있는 spec에만 쓰고, 무차별로 작성하지 않는다.**
-작성은 에이전트가 하니 공짜지만 검토는 사람 몫이다 — 전수 작성하면 승인 게이트에서 사람이
-읽어야 할 양이 몇 배가 되고, 검토 안 된 문서는 낡은 문서와 같은 속도로 거짓말이 된다.
+**로직 플로우는 검수 비용이 비싸다. 무차별로 작성하지 않는다.** 작성은 에이전트가 하니
+공짜지만 검토는 사람 몫이다 — 전수 작성하면 승인 게이트에서 사람이 읽어야 할 양이 몇 배가
+되고, 검토 안 된 문서는 낡은 문서와 같은 속도로 거짓말이 된다.
 
-판정 기준 — 다음 중 하나라도 해당하면 쓴다:
+**① 유저플로우와 동형이 될 플로우는 그리지 않는다.** 사용자가 보는 분기(입력 실패 재시도·
+차단 안내·이탈)의 정본은 유저플로우(②)다. 로그인·작성·제출 같은 여정형 spec의 플로우는
+해당 유저플로우를 spec 하나 분량으로 오려 그린 같은 그림이 된다 — 두 벌 유지는 중복 검수에
+어긋남만 남긴다. 그 여정은 유저플로우에 맡기고, spec에는 비즈니스 규칙·dbTableRefs만 남긴다.
 
-- **실패·차단 분기**가 있다 (검증 실패 하나뿐인 건 해당 안 됨 — 그건 비즈니스 규칙 한 줄이다)
-- **상태 전이**가 있다 (엔티티 status가 바뀐다 → db-table.stateMachines와 연결되는 흐름)
-- **여러 시스템**이 얽힌다 (외부 API·배치·웹훅·알림 발송)
-- 데이터 변형이 **비자명**하다 (읽고 쓰는 것만으로 설명이 안 되는 계산·집계·파생)
+**② 로직 플로우는 사용자 눈에 안 보이는 시스템 동작이 흐름의 주체일 때만 쓴다:**
+
+- **배치·자동 처리** — 마감·만료·유예기간 경과·자동 완료처럼 사용자 행위 없이 진행되는 흐름
+- **다중 시스템 연동** — 외부 API·웹훅·알림 발송이 흐름의 마디를 이룬다
+- **자동 상태 전이** — 사용자 클릭이 아니라 시스템 조건으로 status가 바뀐다 (db-table.stateMachines와 연결)
+- **비자명한 데이터 변형** — 읽고 쓰는 것만으로 설명이 안 되는 계산·집계·파생
 
 해당 없으면 **쓰지 않는다.** 단일 경로 CRUD(성공 아니면 검증 실패뿐)는 사용자 스토리·사전 조건·
-비즈니스 규칙으로 충분하다. TC 도출도 플로우 없이 된다([[2t-decencia-channel-sqa-v2]] §2).
+비즈니스 규칙으로 충분하다. TC 도출도 플로우 없이 된다([[2t-decencia-channel-sqa-v2]] §2 —
+여정형은 유저플로우 분기에서 도출).
 
-역방향 검증: 플로우를 썼는데 **시나리오 1개 + 분기 없는 직선**이면 그 플로우는 지운다 —
-위 기준에 안 걸렸다는 뜻이다.
+역방향 검증 둘: 플로우를 썼는데 **시나리오 1개 + 분기 없는 직선**이면 지운다(기준에 안 걸렸다는
+뜻이다). 플로우의 **모든 마디가 사용자 행위·화면 이동**이면 지운다(그건 유저플로우다).
 
-이 선별의 부수 효과: **플로우의 존재 자체가 복잡도 신호**가 된다. 검토자는 플로우 있는 spec만
-주의 깊게 보면 된다.
+이 선별의 부수 효과: **플로우의 존재 자체가 "여기엔 눈에 안 보이는 시스템 동작이 있다"는
+신호**가 된다. 검토자는 플로우 있는 spec만 주의 깊게 보면 된다.
 
 동작 경로를 **시나리오 단위**로 적는다. 정상·예외를 따로 나누지 않는다 — **실패·차단·이탈 경로는 흐름 안의 분기로 포함**한다(분기는 nodes/edges — §7-2).
 
@@ -457,8 +463,8 @@ ch specs create --id AUTH-001 --name "로그인" \
 ```
 
 10. `ch specs get <id> --json`으로 결과 검증
-11. **Story TC 2겹을 지금 등록한다** — 해피패스(결과 상태까지) 1개 + 실패·차단 분기당 1개, Story당 2~5개. 발명하지 않고 도출한다: 플로우가 있으면 플로우에서, 없으면 사용자 스토리·비즈니스 규칙에서 — [[2t-decencia-channel-sqa-v2]] §2 (시트가 없으면 `ch sqa create` 먼저)
-12. 이후 문서는 작성 순서대로: 유저플로우(②) → 정책정의서(③) → DB 스키마(이때 dbTableRefs·refs 보강) → 화면설계서(④, 이때 화면 연결) → 검증기준서(⑤ — 시나리오·B축·커버리지 게이트, [[2t-decencia-channel-sqa-v2]])
+11. **Testable 자문** — 이 스토리로 통과/실패를 판정하는 TC 문장이 나오는가? 안 나오면 스토리가 물렁한 것이다 — §5로 돌아가 다시 쓰거나 §2로 쪼갠다. **등록은 여기서 하지 않는다** — TC는 ⑤ 검증기준서에서 A축·B축·시나리오와 함께 일괄 등록한다([[2t-decencia-channel-sqa-v2]] §2)
+12. 이후 문서는 작성 순서대로: 유저플로우(②) → 정책정의서(③) → DB 스키마(이때 dbTableRefs·refs 보강) → 화면설계서(④, 이때 화면 연결) → 검증기준서(⑤ — **TC(A축)·B축·시나리오를 여기서 일괄 등록** + 커버리지 게이트, [[2t-decencia-channel-sqa-v2]])
 13. 개발 착수 후 진행 일지는 [[2t-decencia-channel-work-status-v2]]
 
 ---
@@ -489,6 +495,7 @@ ch specs create --id AUTH-001 --name "로그인" \
 - **흐름을 단어 나열로 적기** — 완결 문장으로 (§7-1).
 - **실패·차단 경로 누락** — 해피패스만 적고 끝내지 않는다. 실패·차단·이탈은 분기(nodes/edges의 실패 가지)나 별도 시나리오로 반드시 포함한다.
 - **모든 spec에 로직 플로우 전수 작성** — 검수 비용이 비싸다. §7-0 기준에 걸리는 spec에만 쓴다. 단일 경로 CRUD에 직선 플로우를 쓰면 지운다.
+- **유저플로우를 spec 단위로 오려 로직 플로우로 재작성** — 같은 그림 두 벌이다. 사용자가 보는 분기는 유저플로우가 정본, 로직 플로우는 시스템 동작(배치·알림·자동 전이·계산)이 주체일 때만 (§7-0).
 - 스토리 명세 프로젝트에 interactionMap·stateTransitions·기능유형을 쓰지 않는다 — 레거시 전용(§L).
 
 ---

package/skill/2t-decencia-channel-sprint-builder-v2/SKILL.md

@@ -7,7 +7,7 @@ description: |
   (1) sprint를 구성할 때,
   (2) Σ spec.points 기반 sprint 용량 산정이 필요할 때,
   (3) Epic·도메인·의존성을 함께 고려해 spec을 sprint에 배분할 때.
-version: 1.33.3
+version: 1.33.5
 ---
 
 <!-- ch-version-gate -->

package/skill/2t-decencia-channel-sprint-runner/SKILL.md

@@ -2,7 +2,7 @@
 name: 2t-decencia-channel-sprint-runner
 description: 특정 Sprint를 끝까지 실행(run)하는 오케스트레이터 스킬. Sprint의 spec을 시드로 이슈 목록을 분해·발행(github-issue)하고, GitHub milestone에 묶인 이슈를 상태별로 분류해 issue-coder(병렬)·pr-merger(직렬)로 전진시킨 뒤, 사람확인이 필요한 곳에서 멈춘다. 사람이 확인·체크 후 재호출하면 멱등하게 이어간다(반복 루프). "스프린트 돌려줘"·"sprint N 실행"·"이 스프린트 개발 진행해줘" 류 요청 시.
 allowed-tools: Skill Agent Read Bash(ch:*) Bash(gh:*) Bash(git:*)
-version: 1.33.3
+version: 1.33.5
 ---
 
 <!-- ch-version-gate -->

package/skill/2t-decencia-channel-sqa-v2/SKILL.md

@@ -2,7 +2,7 @@
 name: 2t-decencia-channel-sqa-v2
 description: |
   [2t][v2] 소통채널 SQA(검증기준서) 운영 가이드 — 검증 = TC 검증 + 시나리오 검증.
-  TC는 Story 완료조건(2겹: 해피패스(결과 상태까지)·경계/예외 — spec에서 도출, 기능명세와 동시 등록 — §2),
+  TC는 Story 완료조건(2겹: 해피패스(결과 상태까지)·경계/예외 — spec에서 도출, ⑤ 검증기준서에서 일괄 등록 — §2),
   시나리오는 Sprint 완료조건(유저플로우 기반 5~10개, 상태 누적·역할 여정 검증 — §4.6).
   권한·상태반영은 시나리오+B축(핵심 9개)이 담당. 실행은 시나리오로 하되 판정·기록은 TC 단위.
   Use when:
@@ -12,7 +12,7 @@ description: |
   (4) 보안/성능/접근성/호환성 비기능 TC를 시트에 채워야 할 때,
   (5) 명세 영역별 완성형 TC 번들(퍼블리싱/프론트/백엔드 디센시아 운영 관점 포함)을 가져다 쓸 때,
   (6) Sprint 종료 전 spec별 TC 통과·시나리오 통과 여부를 점검할 때.
-version: 1.33.3
+version: 1.33.5
 ---
 
 <!-- ch-version-gate -->
@@ -61,7 +61,7 @@ SQA 항목은 spec이 정의한 동작·규칙에서 도출한다. Story는 Task
 - 도출 입력 (스토리 명세 모드 — [[2t-decencia-channel-spec-v2]] §0): 사용자 스토리(`story`)·사전 조건(`preconditions`)·로직 플로우(`logic.dataFlowScenarios`, **있으면**)·비즈니스 규칙(`logic.businessRules`)·연결 화면(screens)
 - 도출 입력 (레거시): spec.ui(화면·상호작용), spec.logic(dataFlow·businessRules)
 - 플로우의 **실패·차단 분기는 비정상 TC로 1:1 이상** 옮긴다 — 분기가 있는데 비정상 TC가 없으면 누락이다.
-- **로직 플로우는 선별 작성이다**(spec-v2 §7-0) — 단순 spec은 플로우가 없는 게 정상이다. 플로우 없음 ≠ 도출 불가. 아래 표의 "플로우 없으면" 열로 도출한다.
+- **로직 플로우는 선별 작성이다**(spec-v2 §7-0 — 시스템 동작이 주체일 때만, 유저플로우와 동형 금지) — 대부분의 spec은 플로우가 없는 게 정상이다. 플로우 없음 ≠ 도출 불가. 아래 표의 "플로우 없으면" 열로 도출하고, **여정형 spec은 그 여정을 그린 유저플로우에서 해당 spec 구간의 분기를 가져온다.**
 - SQA 항목: QA가 검증할 시나리오 (예: "잘못된 비밀번호 5회 시 잠금")
 
 **1:N 관계**: spec 1개가 여러 SQA 항목을 유발한다. SQA 항목 작성 시 `relatedSpec`으로 spec에 연결해 추적한다.
@@ -71,15 +71,15 @@ SQA 항목은 spec이 정의한 동작·규칙에서 도출한다. Story는 Task
 | # | 겹 | 플로우 있으면 | 플로우 없으면 (단순 spec) |
 |---|---|---|---|
 | 1 | **해피패스** | 시나리오의 주 경로당 1개 (1~3개). 문장은 **"동작 + 결과 상태까지"** 적는다(예: "저장 클릭 시 목록에 반영되고 상태가 작성완료로 바뀜") | 사용자 스토리의 가치가 실현되는 경로 1개, 같은 문장 규칙 |
-| 2 | **경계·예외** | 플로우의 **실패·차단 분기당 1개**. 같은 겹의 변형(형식 오류 이메일/숫자/날짜 등)은 대표 1개로 묶는다 | **비즈니스 규칙당 위반 1개** + 사전 조건 미충족 대표 1개 |
+| 2 | **경계·예외** | 플로우의 **실패·차단 분기당 1개**. 같은 겹의 변형(형식 오류 이메일/숫자/날짜 등)은 대표 1개로 묶는다 | **비즈니스 규칙당 위반 1개** + 사전 조건 미충족 대표 1개. 여정형이면 **유저플로우의 해당 spec 구간 분기당 1개**도 더한다 |
 
 - **Story당 표준 2~5개.** 12개를 넘으면 TC를 줄일 게 아니라 Story가 크다는 신호다([[2t-decencia-channel-spec-v2]] §14).
-- **작성 시점 = 기능명세와 동시.** spec을 쓴 그 자리에서 등록한다(시트가 없으면 §3의 0번으로 먼저 생성). 검증 불가능한 spec을 그 시점에 걸러내는 게 목적이다.
+- **작성 시점 = ⑤ 검증기준서에서 일괄.** A축·B축·시나리오를 한 자리에서 등록한다 — ①~④를 거치며 기획이 계속 바뀌는데 TC를 미리 등록하면 그 변경을 따라다니는 유지 대상만 는다. ⑤ 시점이 도출 재료(유저플로우 분기·정책·stateMachines·화면)도 가장 풍부하다. 검증 불가능한 spec 걸러내기는 ①의 Testable 자문이 맡는다([[2t-decencia-channel-spec-v2]] §13) — 자문은 ①에서, 등록은 ⑤에서.
 - **권한·상태반영은 Story TC의 몫이 아니다** — 권한 차단 대표 검증은 B축(§4.2), 역할별 실사용·상태 누적 확인은 시나리오(§4.6)가 담당한다. 단, 그 Story 고유의 권한 규칙(예: "본인 문서만")은 businessRules의 경계·예외 TC로 자연 도출된다.
 
 ## 3. 신규 SQA 작성 워크플로우
 
-> A축(Story TC 2겹)은 **기능명세 작성과 동시에** 이 절차로 등록하는 것이 표준이다(§2). ⑤검증기준서 단계에서는 시나리오·확인 포인트 TC·B축을 더하고 §4.5 커버리지 게이트를 돌린다.
+> SQA는 **⑤ 검증기준서에서 한번에** 쓴다(§2) — A축(Story TC 2겹) → B축(핵심 9개) → 시나리오·확인 포인트 TC 순으로 채우고 §4.5 커버리지 게이트를 돌린다.
 
 0. **시트 생성** (없으면 먼저):
    ```bash

package/skill/2t-decencia-channel-userflow-v2/SKILL.md

@@ -8,7 +8,7 @@ description: |
   (1) 유저플로우(사용자 여정 분기도)를 새로 그리거나 수정할 때,
   (2) PRD·Epic-Story 목록에서 플로우로 그릴 대상을 고를 때,
   (3) 웹 "유저플로우" 탭에 올릴 Mermaid 코드를 작성할 때.
-version: 1.33.3
+version: 1.33.5
 ---
 
 <!-- ch-version-gate -->

package/skill/2t-decencia-channel-work-status-v2/SKILL.md

@@ -8,7 +8,7 @@ description: |
   (2) "작업 현황 적어줘", "workStatus 갱신해줘" 요청 시,
   (3) Sprint 종료 회고나 인수인계용으로 spec별 진행 상태를 정리할 때,
   (4) `ch specs update --work-status` 또는 웹 "작업 현황" 탭에서 갱신할 때.
-version: 1.33.3
+version: 1.33.5
 ---
 
 <!-- ch-version-gate -->