@decencia/ch-cli 1.31.2 → 1.31.4

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.31.2
+version: 1.31.4
 ---
 
 ## 역할

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.31.2
+version: 1.31.4
 ---
 
 ## 역할

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.31.2
+version: 1.31.4
 ---
 
 ## 역할

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "@decencia/ch-cli",
-  "version": "1.31.2",
+  "version": "1.31.4",
   "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.31.2
+version: 1.31.4
 ---
 
 <!-- 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.31.2
+version: 1.31.4
 ---
 
 <!-- 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.31.2
+version: 1.31.4
 ---
 
 <!-- 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.31.2
+version: 1.31.4
 ---
 
 <!-- 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.31.2
+version: 1.31.4
 ---
 
 <!-- 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.31.2
+version: 1.31.4
 ---
 
 <!-- ch-version-gate -->

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

@@ -8,7 +8,7 @@ description: |
   (1) 정책정의서를 새로 쓰거나 수정할 때,
   (2) 유저플로우·기능명세를 검토하다 "이건 정해진 게 없다"는 질문이 나왔을 때,
   (3) 알림 발송 매트릭스·크레딧 지급 기준·타임아웃 처리 같은 횡단 정책을 정리할 때.
-version: 1.31.2
+version: 1.31.4
 ---
 
 <!-- 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.31.2
+version: 1.31.4
 ---
 
 <!-- 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.31.2
+version: 1.31.4
 ---
 
 <!-- ch-version-gate -->
@@ -109,13 +109,14 @@ ch specs create --id PROJ-001 --name "프로젝트 목록" \
 - ⚠️ **이 시점엔 흐름 `refs`를 넣지 않는다** — 테이블이 아직 없고, 서버가 refs의 tableId를 실존 검증해 400이 난다. 완결 문장으로만 쓰고 §6에서 refs를 보강한다.
 - `--ui`도 넣지 않는다. 화면이 아직 없다 — 연결은 §7에서 `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`로 먼저 만든다. 권한·상태 누적 검증은 여기서 하지 않는다(§8의 시나리오·B축 몫).
 - → **[게이트] 사용자 확인.** OK면 4단계.
 
 ## 4. 유저플로우
 *(spec 업로드 후)*
 - [[2t-decencia-channel-userflow-v2]]대로 **분기 있는 여정만** 골라 Mermaid로 그린다 (프로젝트당 3~7장, 해피패스 중앙 일직선).
 - 대상은 PRD·Epic-Story 목록에서 뽑는다: 돈이 흐르는 경로·최빈 경로·역방향·역할별 여정 우선.
-- `ch userflows create --name "<여정>" --file ./flow.mmd`로 업로드. 웹 "유저플로우" 탭에서 확인.
+- `ch userflows create --name "<여정>" --file ./flow.mmd --order <n>`로 업로드 — **order는 여정의 자연 순서**(가입→로그인→핵심→역방향)대로 1부터 필수로 매긴다. 웹 "유저플로우" 탭에서 확인.
 - → **[게이트] 사용자 확인.** OK면 5단계.
 
 ## 5. 정책정의서
@@ -215,8 +216,8 @@ ch specs screen-refs PROJ-002 --screens SCR-PROJECTS,SCR-PROJECT-DETAIL   # 화
 탭·모달·바텀시트는 별도 화면이 아니다. 그 화면의 `states`·`entryPoints`로 적는다.
 
 ## 8. 검증기준서 (SQA)
-*(화면 연결 후에만 — 작성 순서 마지막)*
-- `2t-decencia-channel-sqa-v2`로 작성: **A축**(명세별 기능 TC — Story당 4겹: 해피패스/경계·예외/권한/상태반영) + **B축**(비기능 표준 40) + **시나리오**(§4.6 — ⑤단계에서 유저플로우 기반 5~10개, Sprint 완료조건으로 할당).
+*(화면 연결 후에만 — 작성 순서 마지막. Story TC는 §3에서 이미 등록됨)*
+- `2t-decencia-channel-sqa-v2`로 마무리한다: **시나리오**(§4.6 — 유저플로우 기반 5~10개, 역할별 여정·상태 누적 확인 포인트, 대응 TC 등록·매핑, Sprint 완료조건으로 할당) + **B축**(비기능 핵심 9개) + **§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) 웹 "화면" 탭의 IA 트리·화면 상세에 올릴 내용을 쓸 때.
-version: 1.31.2
+version: 1.31.4
 ---
 
 <!-- ch-version-gate -->

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

@@ -12,7 +12,7 @@ description: |
   (3) 스토리문장·사전 조건·로직 플로우·비즈니스 규칙을 작성할 때,
   (4) Story 규모를 Story Point(`--points`)로 매길 때,
   (5) 신규 spec ID를 `AUTH-001` 같은 JIRA 스타일로 부여할 때 (`ch specs create --id`).
-version: 1.31.2
+version: 1.31.4
 ---
 
 <!-- ch-version-gate -->
@@ -433,8 +433,9 @@ ch specs create --id AUTH-001 --name "로그인" \
 ```
 
 10. `ch specs get <id> --json`으로 결과 검증
-11. 이후 문서는 작성 순서대로: 유저플로우(②) → 정책정의서(③) → DB 스키마(이때 dbTableRefs·refs 보강) → 화면설계서(④, 이때 화면 연결) → 검증기준서(⑤, [[2t-decencia-channel-sqa-v2]])
-12. 개발 착수 후 진행 일지는 [[2t-decencia-channel-work-status-v2]]
+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]])
+13. 개발 착수 후 진행 일지는 [[2t-decencia-channel-work-status-v2]]
 
 ---
 

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.31.2
+version: 1.31.4
 ---
 
 <!-- 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.31.2
+version: 1.31.4
 ---
 
 <!-- ch-version-gate -->

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

@@ -2,9 +2,9 @@
 name: 2t-decencia-channel-sqa-v2
 description: |
   [2t][v2] 소통채널 SQA(검증기준서) 운영 가이드 — 검증 = TC 검증 + 시나리오 검증.
-  TC는 Story 완료조건(Story당 4겹: 해피패스/경계·예외/권한/상태반영 — §2, §4.3 영역별 번들에서 도출),
-  시나리오는 Sprint 완료조건(유저플로우 기반 5~10개, TC 사이 빈틈 검증 — §4.6).
-  실행은 시나리오로 하되 판정·기록은 TC 단위.
+  TC는 Story 완료조건(2겹: 해피패스(결과 상태까지)·경계/예외 — 플로우에서 도출, 기능명세와 동시 등록 — §2),
+  시나리오는 Sprint 완료조건(유저플로우 기반 5~10개, 상태 누적·역할 여정 검증 — §4.6).
+  권한·상태반영은 시나리오+B축(핵심 9개)이 담당. 실행은 시나리오로 하되 판정·기록은 TC 단위.
   Use when:
   (1) SQA 시트를 새로 작성하거나 항목을 보강할 때,
   (2) spec에서 도출한 검증 항목(TC)을 SQA 시트에 등록할 때,
@@ -12,7 +12,7 @@ description: |
   (4) 보안/성능/접근성/호환성 비기능 TC를 시트에 채워야 할 때,
   (5) 명세 영역별 완성형 TC 번들(퍼블리싱/프론트/백엔드 디센시아 운영 관점 포함)을 가져다 쓸 때,
   (6) Sprint 종료 전 spec별 TC 통과·시나리오 통과 여부를 점검할 때.
-version: 1.31.2
+version: 1.31.4
 ---
 
 <!-- ch-version-gate -->
@@ -46,7 +46,7 @@ ch check
 | | TC 검증 | 시나리오 검증 |
 |---|---|---|
 | 단위 | Story마다 대응되는 검증 리스트 | 한 Story에 종속되지 않음 — 유저플로우 기반 |
-| 잡는 것 | 기능·경계·예외·권한·상태반영 | 개별 TC만으로 못 잡는 **TC 사이의 빈틈** |
+| 잡는 것 | 기능 동작·결과, 경계·예외 | 상태 누적·역할별 여정·권한 실사용 — 개별 TC만으로 못 잡는 **빈틈** |
 | 완료조건 | Story(spec) 완료 | Sprint 완료 |
 | 작성 | §2~§4.5 | §4.6 |
 
@@ -65,19 +65,21 @@ SQA 항목은 spec이 정의한 동작·규칙에서 도출한다. Story는 Task
 
 **1:N 관계**: spec 1개가 여러 SQA 항목을 유발한다. SQA 항목 작성 시 `relatedSpec`으로 spec에 연결해 추적한다.
 
-### Story당 TC 구성 4겹 — 전부 있어야 한다
+### Story당 TC 구성 2겹 — 발명하지 않고 플로우에서 도출한다
 
-| # | 겹 | 내용 |
-|---|---|---|
-| 1 | **해피패스** | 기본 기능검증 — 정상 경로가 끝까지 동작 |
-| 2 | **경계·예외** | 경계값(길이·0건·최대치)과 실패·차단 경로. 플로우의 실패 분기는 1:1 이상 |
-| 3 | **권한** | 역할별 허용/차단 (§4.3.1 번들) |
-| 4 | **상태반영 여부** | 액션 후 DB·화면 상태가 실제로 바뀌었는가 — 흐름 refs의 WRITE·`toState`를 확인 TC로 |
+| # | 겹 | 도출 기준 | 개수 |
+|---|---|---|---|
+| 1 | **해피패스** | 시나리오의 주 경로당 1개. 문장은 **"동작 + 결과 상태까지"** 적는다(예: "저장 클릭 시 목록에 반영되고 상태가 작성완료로 바뀜") | 시나리오 수만큼 (1~3) |
+| 2 | **경계·예외** | 플로우의 **실패·차단 분기당 1개**. 같은 겹의 변형(형식 오류 이메일/숫자/날짜 등)은 대표 1개로 묶는다 | 분기 수만큼 |
 
-넷 중 하나라도 비면 그 Story의 TC는 미완성이다. §8 체크리스트로 최종 확인한다.
+- **Story당 표준 2~5개.** 12개를 넘으면 TC를 줄일 게 아니라 Story가 크다는 신호다([[2t-decencia-channel-spec-v2]] §14).
+- **작성 시점 = 기능명세와 동시.** spec을 쓴 그 자리에서 등록한다(시트가 없으면 §3의 0번으로 먼저 생성). 검증 불가능한 spec을 그 시점에 걸러내는 게 목적이다.
+- **권한·상태반영은 Story TC의 몫이 아니다** — 권한 차단 대표 검증은 B축(§4.2), 역할별 실사용·상태 누적 확인은 시나리오(§4.6)가 담당한다. 단, 그 Story 고유의 권한 규칙(예: "본인 문서만")은 businessRules의 경계·예외 TC로 자연 도출된다.
 
 ## 3. 신규 SQA 작성 워크플로우
 
+> A축(Story TC 2겹)은 **기능명세 작성과 동시에** 이 절차로 등록하는 것이 표준이다(§2). ⑤검증기준서 단계에서는 시나리오·확인 포인트 TC·B축을 더하고 §4.5 커버리지 게이트를 돌린다.
+
 0. **시트 생성** (없으면 먼저):
    ```bash
    # --date 생략 시 오늘로 자동 채움 (서버 DTO가 performDate 필수)
@@ -125,8 +127,8 @@ ch sqa reorder-items <sheetId> --file order.json   # ["id1","id2",...] 또는 {
 
 | 축 | 단위 | 출처 / 도출 방법 | 비고 |
 |---|---|---|---|
-| A. 명세별 기능 TC | spec 1개당 | spec.ui/logic을 읽고 **§4.3 영역별 TC 번들 라이브러리**에서 해당 영역들을 골라 명세 맥락으로 구체화 | spec당 보통 5~15개 |
-| B. 비기능 4축 표준 TC | 시트 1개당 묶음 | 표준(OWASP/Core Web Vitals/WCAG/호환성)을 그대로 등록 | **시트당 40개** (보안 12 + 성능 10 + 접근성 10 + 호환성 8) |
+| A. 명세별 기능 TC | spec 1개당 | 로직 플로우에서 **도출**(§2 — 해피패스·분기당 1개). §4.3 번들은 빠진 관점 확인용 체크리스트 | spec당 보통 **2~5개** |
+| B. 비기능 표준 TC | 시트 1개당 묶음 | §4.2 핵심 9개를 그대로 등록 | **시트당 9개** |
 
 축 B는 spec 단위가 아니므로 `relatedSpec`을 비워두거나 "common"/"standard" 가상 specId로 일관 관리.
 
@@ -140,69 +142,23 @@ ch sqa reorder-items <sheetId> --file order.json   # ["id1","id2",...] 또는 {
 | Medium | 30% | 부가 기능, 성능, 접근성, 호환성 |
 | Low | 10% | UI 디테일, 반응형, 에지 케이스 |
 
-## 4.2 비기능 4축 표준 TC (40개)
-
-모든 SQA 시트에 아래 항목을 포함한다. "ISO/IEC 25010 + OWASP Top 10:2025 + WCAG 2.2 AA + Core Web Vitals" 기반.
+## 4.2 비기능 표준 TC (핵심 9개)
 
-### 4.2.1 Security — OWASP Top 10:2025 (12개)
+모든 SQA 시트에 아래 9개를 포함한다. **실제로 검증하는 항목만 남긴 최소 세트다** — 형식적으로 등록만 되고 체크되지 않는 항목은 두지 않는다.
 
-| # | subType | TC 항목 | 근거 |
+| # | 분류 | subType | TC 항목 |
 |---|---|---|---|
-| 1 | access-control | 비인가 역할로 관리자 페이지 접근 시 차단/리다이렉트 | A01 |
-| 2 | access-control | 권한별 API 엔드포인트 403 반환 | A01 |
-| 3 | config | 보안 헤더(CSP, X-Frame-Options, X-Content-Type) 설정 | A02 |
-| 4 | config | 에러 응답에 스택트레이스/디버그 정보 미노출 | A02 |
-| 5 | input-validation | `<script>` 삽입 시 이스케이프 처리 (XSS) | A03 |
-| 6 | input-validation | NoSQL/SQL 인젝션 패턴 필터링 | A03 |
-| 7 | input-validation | 서버사이드 유효성 검증 (클라이언트 우회 방지) | A03 |
-| 8 | auth-security | 만료 토큰으로 API 호출 시 401 | A07 |
-| 9 | auth-security | 로그인 실패 N회 시 잠금/지연 | A07 |
-| 10 | auth-security | 세션 만료 후 재인증 요구 | A07 |
-| 11 | data-protection | 모든 통신 HTTPS 강제 | A08 |
-| 12 | supply-chain | `npm audit` / 의존성 취약점 스캔 통과 | A06 |
-
-### 4.2.2 Performance — Core Web Vitals + ISO 25010 (10개)
-
-| # | subType | TC 항목 | 기준 |
-|---|---|---|---|
-| 1 | loading | LCP ≤ 2.5s | CWV |
-| 2 | loading | FCP ≤ 1.8s | CWV |
-| 3 | interactivity | INP ≤ 200ms | CWV |
-| 4 | visual-stability | CLS < 0.1 | CWV |
-| 5 | server-response | TTFB ≤ 800ms | CWV |
-| 6 | server-response | API P95 ≤ 500ms | ISO 25010 |
-| 7 | resource | 이미지 최적화 (WebP/AVIF, lazy load) | ISO 25010 |
-| 8 | resource | JS 번들 gzip ≤ 200KB | ISO 25010 |
-| 9 | caching | 정적 자산 Cache-Control 헤더 | ISO 25010 |
-| 10 | memory | SPA 장시간 사용 시 메모리 누수 없음 | ISO 25010 |
-
-### 4.2.3 Accessibility — WCAG 2.2 Level AA (10개)
-
-| # | subType | TC 항목 | 근거 |
-|---|---|---|---|
-| 1 | perceivable | 의미 있는 이미지에 alt 제공 | WCAG 1.1.1 |
-| 2 | color-contrast | 일반 텍스트 대비 4.5:1 이상 | WCAG 1.4.3 |
-| 3 | color-contrast | 대형 텍스트(18pt+) 대비 3:1 이상 | WCAG 1.4.3 |
-| 4 | keyboard | Tab/Enter/Esc로 주요 기능 사용 가능 | WCAG 2.1.1 |
-| 5 | keyboard | 포커스 표시(outline) 시각적으로 확인 가능 | WCAG 2.4.7 |
-| 6 | operable | Skip to content 링크 제공 | WCAG 2.4.1 |
-| 7 | understandable | 페이지별 고유 `<title>` | WCAG 2.4.2 |
-| 8 | understandable | 모든 폼 input에 `<label>` 연결 | WCAG 1.3.1 |
-| 9 | understandable | 폼 에러 위치/내용 식별 가능 | WCAG 3.3.1 |
-| 10 | touch-target | 터치 타겟 최소 24×24px | WCAG 2.5.8 |
-
-### 4.2.4 Compatibility — 크로스 브라우저/디바이스 (8개)
-
-| # | subType | TC 항목 |
-|---|---|---|
-| 1 | browser | Chrome 최신 2버전 정상 동작 |
-| 2 | browser | Safari 최신 2버전 정상 동작 |
-| 3 | browser | Edge 최신 버전 정상 동작 |
-| 4 | browser | Firefox 최신 버전 정상 동작 |
-| 5 | mobile | iOS Safari 정상 동작 |
-| 6 | mobile | Android Chrome 정상 동작 |
-| 7 | responsive | 375 / 768 / 1440 레이아웃 정상 |
-| 8 | responsive | 가로/세로 회전 시 레이아웃 유지 |
+| 1 | 보안 | access-control | 비인가 역할로 보호된 페이지 접근 시 차단/리다이렉트 |
+| 2 | 보안 | access-control | 권한 없는 역할의 API 호출을 서버가 403으로 거절 |
+| 3 | 보안 | input-validation | 서버사이드 유효성 검증 (클라이언트 우회 방지) |
+| 4 | 보안 | auth-security | 만료 토큰·세션으로 호출 시 401 / 재인증 요구 |
+| 5 | 성능 | loading | 주요 화면이 체감상 지연 없이 뜬다 (로딩 상태 표시 포함) |
+| 6 | 성능 | interaction | 대량 데이터 목록에서 검색·페이징 조작이 멈춤 없이 동작 |
+| 7 | 접근성 | keyboard | 주요 폼을 키보드만으로 입력·제출 가능 (Tab/Enter/Esc) |
+| 8 | 호환성 | browser | 기본 브라우저(Chrome 최신)에서 주요 플로우 정상 |
+| 9 | 호환성 | responsive | 모바일 폭(375px)에서 주요 화면 레이아웃 정상 |
+
+> 대외 서비스·결제 포함 프로젝트처럼 더 높은 기준이 필요하면 OWASP Top 10 / Core Web Vitals / WCAG 2.2 AA에서 필요한 항목을 **그 프로젝트 시트에만** 보강한다 — 기본 세트를 도로 불리지 않는다.
 
 ## 4.3 명세별 기능 TC 도출 가이드 (A축) — 영역별 TC 번들 라이브러리
 
@@ -228,10 +184,12 @@ ch sqa reorder-items <sheetId> --file order.json   # ["id1","id2",...] 또는 {
 
 → 한 영역의 번들만 펼쳐도 "그 영역 명세를 쓸 때 검토해야 할 모든 관점"이 한 곳에 있다.
 
-**명세 복잡도별 권장 TC 수**:
-- 단순(조회만): 5~8개
-- 보통(CRUD): 8~12개
-- 복잡(다기능): 12~20개
+**번들은 체크리스트이지 등록 목록이 아니다.** TC는 플로우에서 도출하는 게 원칙(§2)이고, 번들은 도출을 마친 뒤 "빠진 관점이 없나" 훑는 용도다. 이미 도출된 TC와 겹치면 등록하지 않는다.
+
+**명세 복잡도별 권장 TC 수** (도출 기반):
+- 단순(조회만): 2~3개
+- 보통(CRUD): 3~5개
+- 복잡(다기능·분기 많음): 5~8개 — 12개를 넘으면 Story 분할 신호
 
 ---
 
@@ -378,7 +336,7 @@ ch sqa reorder-items <sheetId> --file order.json   # ["id1","id2",...] 또는 {
 
 ### relatedSpec
 - A축(§4.3 영역별 번들에서 도출한 모든 항목): 반드시 해당 명세의 specId 명시
-- B축(비기능 4축 표준 40개): 비워두거나 "common"/"standard" 가상 specId 사용 — 프로젝트 정책 결정 후 일관 적용
+- B축(비기능 표준 9개): 비워두거나 "common"/"standard" 가상 specId 사용 — 프로젝트 정책 결정 후 일관 적용
 
 ### Windows CRLF 주의
 파일 기반 입력 시 `\r`이 specId 끝에 붙어 연결이 깨진다. heredoc 권장, 부득이 파일이면 `tr -d '\r'`로 정제.
@@ -423,7 +381,7 @@ ch specs list --json --per-page 100 | node -e "
 | 종료 | **최종 데이터 정합 확인** — 여정이 끝난 뒤 DB·화면 상태가 맞는가 |
 
 - 스텝의 확인 포인트는 단순 TC 재확인이 아니다. **이 스텝까지 오면서 변한 상태**를 본다.
-- 종료의 정합 확인도 TC 항목으로 등록해 마지막 스텝에 매핑한다 — "판정·기록은 TC 단위" 원칙.
+- **상태 누적·권한(역할별 여정) 검증은 시나리오의 몫이다** — Story TC(2겹)에는 없다. 확인 포인트에 대응하는 TC가 시트에 없으면 **이때 등록해 매핑**한다(스텝·종료 모두) — "판정·기록은 TC 단위" 원칙.
 - 시나리오가 참조하는 유저플로우가 있으면 링크한다.
 
 ### 4.6.3 Sprint 연결 — Sprint의 완료조건
@@ -505,11 +463,11 @@ ch specs update <specId> --status completed --no-version
 ## 8. 시트 작성 완료 자가 점검 체크리스트
 
 - [ ] A축: 모든 spec에 최소 3개 이상 TC가 있는가? (§4.5 커버리지 통과)
-- [ ] A축: 모든 Story에 TC 4겹(해피패스/경계·예외/권한/상태반영)이 있는가? (§2)
+- [ ] A축: 모든 Story에 TC 2겹(해피패스(결과 상태까지)·경계/예외)이 플로우에서 도출돼 있는가? Story당 2~5개 범위인가? (§2)
 - [ ] A축 항목 작성 시 §4.3 영역별 번들(Functional/Publishing/Frontend/Backend)을 명세 성격에 맞게 적용했는가?
 - [ ] 시나리오: 유저플로우 기반 5~10개 — 돈 경로·최빈 경로·역방향·역할별 1개 포함? (§4.6.1)
 - [ ] 시나리오: 스텝마다 확인 포인트·TC 매핑이 있고, 종료 정합 TC가 있는가? Sprint에 할당했는가?
-- [ ] B축: 보안 12 / 성능 10 / 접근성 10 / 호환성 8 — 40개 모두 포함?
+- [ ] B축: 핵심 9개(§4.2) 포함? (필요 이상으로 불리지 않았는가?)
 - [ ] High 우선순위 TC가 60% 이상인가?
 - [ ] 정상 경로 + 비정상 경로(에러) 모두 커버?
 - [ ] 빈 상태(데이터 없음) 테스트 포함?
@@ -525,7 +483,7 @@ ch specs update <specId> --status completed --no-version
 - **시나리오를 TC 재확인 목록으로 쓰지 말 것** — 확인 포인트는 플로우에 따라 변한 상태(잔액·재고·상태 컬럼·알림)다.
 - **시나리오도 Run 생성 시점 스냅샷 기준이다** — Run 시작 후 추가·수정한 시나리오는 그 Run에 없으므로 새 `start-run` 전까지 무조건 미통과로 집계된다(항목 CRUD의 스냅샷 규칙과 동일).
 - **시나리오가 참조 중인 TC 항목은 삭제할 수 없다(400)** — 시나리오의 매핑(tcRefs·종료 정합 TC)을 먼저 제거한 뒤 항목을 지운다.
-- **명세별 E2E만 넣고 끝내지 말 것** — §4.3 번들에서 Publishing/Frontend/Backend 카테고리 누락, §4.2 비기능 4축 미등록이 가장 흔한 실수.
+- **TC를 발명하지 말 것** — 플로우에서 도출한다(§2). 번들 전개·역할 전수 조합으로 TC를 불리는 것이 가장 흔한 실수다. 반대로 §4.2 핵심 9개 미등록도 누락이다.
 - §4.3 번들을 **별도 시트 묶음으로 등록**하지 말 것 — 각 명세의 A축 항목으로 풀어 써야 한다. 추상 문구 그대로 박아넣지 말 것.
 - 항목 단위 CRUD(§3.5)는 **시트 템플릿**만 변경 — 진행 중 Run에는 반영 안 됨. Run 항목 결과는 `check`/`check-bulk`로.
 - `update-item`/`delete-item`/`reorder-items`는 `itemId` 키 기반 → 반드시 `ch sqa get --json`으로 최신 id 확보 후 실행(stale id 주의).

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

@@ -8,7 +8,7 @@ description: |
   (1) 유저플로우(사용자 여정 분기도)를 새로 그리거나 수정할 때,
   (2) PRD·Epic-Story 목록에서 플로우로 그릴 대상을 고를 때,
   (3) 웹 "유저플로우" 탭에 올릴 Mermaid 코드를 작성할 때.
-version: 1.31.2
+version: 1.31.4
 ---
 
 <!-- ch-version-gate -->
@@ -107,11 +107,12 @@ flowchart TD
 ```bash
 ch userflows list                                   # 표: order | id | name
 ch userflows get <flowId>                           # 상세 (--json 이면 순수 JSON)
-ch userflows create --name "로그인·계정 복구" --file ./login-flow.mmd
+ch userflows create --name "로그인·계정 복구" --file ./login-flow.mmd --order 2
 ch userflows update <flowId> --file ./login-flow.mmd
 ch userflows delete <flowId>
 ```
 
+- **`--order`를 반드시 매긴다** — 여정의 자연 순서(가입 → 로그인 → 핵심 여정 → 역방향·후기)대로 1부터. 안 매기면 목록이 이름 가나다순으로 흩어진다.
 - `--file`은 Mermaid 코드 파일(.mmd). CRLF는 자동 정제된다.
 - 웹 "유저플로우" 탭이 같은 문서를 zoom in/out·pan 렌더러로 보여준다.
 - Read-before-Write: 수정 전 `get`으로 현재 코드를 받아 편집한다.

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.31.2
+version: 1.31.4
 ---
 
 <!-- ch-version-gate -->