@decencia/ch-cli 1.32.1 → 1.32.3

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.32.1
+version: 1.32.3
 ---
 
 ## 역할

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.32.1
+version: 1.32.3
 ---
 
 ## 역할

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.32.1
+version: 1.32.3
 ---
 
 ## 역할

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "@decencia/ch-cli",
-  "version": "1.32.1",
+  "version": "1.32.3",
   "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.32.1
+version: 1.32.3
 ---
 
 <!-- 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.32.1
+version: 1.32.3
 ---
 
 <!-- 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.32.1
+version: 1.32.3
 ---
 
 <!-- ch-version-gate -->
@@ -211,9 +211,10 @@ ch ia versions
 ```
 
 - `--file`은 **트리 JSON**이다(`IaNode[]`). 노드는 두 종류다 — 분류 `{"type":"group","name":"…","children":[…]}`,
-  화면 `{"type":"screen","screenId":"SCR-…"}`. **배열 순서가 곧 표시 순서**이고 **통째 교체**다.
-  수정 전 `ch ia get --json`으로 받아 편집한다(Read-before-Write).
-- `--content`는 **고른 축과 배치 근거** 마크다운이다. 트리 자체는 `--file`이 갖는다.
+  화면 `{"type":"screen","screenId":"SCR-…","children":[…]}`. **화면 노드도 자식을 가진다** —
+  관문 화면이 부모가 되는 게 기본이고, 분류 노드는 관문 페이지가 없을 때만 쓴다([[2t-decencia-channel-ia-v2]]).
+  **배열 순서가 곧 표시 순서**이고 **통째 교체**다. 수정 전 `ch ia get --json`으로 받아 편집한다(Read-before-Write).
+- `--content`는 **배치 근거** 마크다운이다. 트리 자체는 `--file`이 갖는다.
 - `screenId`는 실존 화면이어야 하고(없으면 400), 같은 화면을 두 번 배치해도 400이다.
 - `--expected-version`을 주면 그 사이 남이 저장했을 때 409로 막는다. 트리가 통째 교체라 이게 없으면
   나중에 저장한 쪽이 앞사람 작업을 통째로 덮는다.

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

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

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

@@ -1,15 +1,9 @@
 ---
 name: 2t-decencia-channel-ia-v2
 description: |
-  [2t][v2] 소통채널 화면 IA(정보구조) 설계 가이드.
-  화면을 만들기 전에 화면들을 어떻게 묶어 보여줄지 정한다 — 분류 노드와 화면 노드로 트리를 세운다.
-  뼈대(개인 허브·운영)를 놓고 본편의 축을 판정 순서로 정하며, 배치는 "사용자가 어디를 먼저
-  클릭하는가"로 판단한다. Epic·개발 모듈·URL은 기준이 아니다.
-  Use when:
-  (1) 화면설계서를 쓰기 전에 화면들의 배치를 정할 때,
-  (2) 기존 프로젝트의 IA가 어색해 재배치를 검토할 때,
-  (3) "이 화면이 왜 여기 있지" 같은 구조 문제를 점검할 때.
-version: 1.32.1
+  [2t][v2] 소통채널 화면 IA(정보구조) 설계. 화면들의 도달 구조를 트리로 세운다 — 관문이 부모다.
+  Use when: (1) 화면설계서 전에 화면 배치를 정할 때, (2) 기존 IA 재배치를 검토할 때.
+version: 1.32.3
 ---
 
 <!-- ch-version-gate -->
@@ -29,127 +23,19 @@ ch check
 
 # 화면 IA(정보구조) 설계
 
-화면을 만들기 전에, 화면들을 어떻게 묶어 보여줄지 정한다. 산출물은 **트리 하나**다.
-분류 노드(사람이 이름 붙인 묶음)와 화면 노드로 세우고, `ch ia set`으로 저장한다(§5).
+유저플로우 뒤, 화면설계서 앞(④)에 화면들의 도달 구조를 트리 하나로 세운다.
 
-> 작성 순서는 ④다. ①기능명세 → ②유저플로우 → ③정책정의서 → DB 스키마 → **④IA** → ⑤화면설계서.
-> 유저플로우가 먼저다. 여정을 알아야 배치할 수 있다.
+**원리: 관문이 부모다.** 화면마다 "사용자가 어디를 먼저 클릭해 들어오나"를 묻고, 거쳐 가는
+화면 밑에 단다(목록→상세→후속). 어디도 거치지 않는 화면이 루트다 — 유저플로우의 여정
+시작점과 일치해야 한다.
 
-## 1. 판단 기준은 하나다
+- 분류 노드(이름표)는 관문 페이지가 없는 묶음(인증 등)에만 쓴다. 화면 노드도 자식을 가진다.
+- Epic·모듈·URL로 묶지 않는다 — 그건 코드의 분류다.
+- 진입로가 여럿이면 사용자가 찾으러 갈 곳 하나만 부모로. 나머지 길은 유저플로우 몫이다.
 
-**"사용자가 이 화면을 찾을 때 어디를 먼저 클릭하는가."**
+**절차**: ① `ch ia get`으로 기존 IA 확인 ② 관문을 물어 배치 ③ 표가 아니라 트리로 사용자 승인
+④ `ch ia set --file 트리.json --content 근거.md` 저장 (통째 교체 — 형식은
+[[2t-decencia-channel-cli-v2]]).
 
-§3의 규칙들은 이 질문의 결과일 뿐이다. 규칙과 답이 어긋나면 **답을 따른다.**
-
-- 🚫 **Epic·개발 모듈로 묶지 마라.** 사용자는 모듈 이름을 모른다.
-- 🚫 **URL로 계층을 만들지 마라.** 슬래시 개수는 계층이 아니다.
-- 계층은 기능의 포함 관계다. 목록 다음에 상세가 온다고 상세가 목록의 하위 분류는 아니다.
-
-## 2. 뼈대를 놓고, 본편의 축을 정한다
-
-### 뼈대 — 선택이 아니다
-
-- 개인 데이터가 있으면 → **개인 허브** 하나 (마이페이지류)
-- 운영자가 있으면 → **운영 구역** 하나
-- 나머지가 **본편**이다
-
-로그인 경계는 뼈대가 처리한다. "로그인 전후로 갈리나"는 거의 모든 서비스가 "예"라서 축이 되지
-못한다. 없는 조각은 놓지 않는다 — 사내 툴은 개인 허브 없이 바로 본편으로 간다.
-
-### 본편의 축 — 여기서부터가 판정이다
-
-트리의 한 층은 **한 가지 기준**으로만 가른다. **위에서부터 물어 처음 "예"에서 멈춘다.**
-
-1. 둘러보고 소비하는 것이 중심인가? → **주제**로 가른다 (분야별 / 종류별)
-2. 목적을 갖고 와서 일하는 것이 중심인가? → **하려는 일**로 가른다 (만들기 / 관리 / 분석)
-3. 이용자 군이 겹치지 않고 각자 다른 일을 하나? → **사용자 유형**으로 가른다
-
-층을 내려갈 때마다 다시 묻되, 위에서 답한 질문은 건너뛴다. 갈리면 "어느 쪽이 그 층을 5~7개로
-고르게 가르나"로 정한다.
-
-- **시작 전에 `ch ia get`으로 기존 IA를 읽는다.** 축이 이미 있으면 따른다. 바꾸려면 사용자
-  합의를 받는다.
-- **정한 축과 이유를 `--content`에 적는다.**
-
-## 3. 배치 규칙
-
-1. **같은 성격은 한 부모 아래 모은다.** 하나만 밖에 있다면 이유를 한 줄로 답할 수 있어야 한다.
-
-2. **소속은 진입점으로 가른다. 화면 이름으로 가르지 마라.**
-
-   | 어디서 들어오나 | 자리 |
-   |---|---|
-   | 내 목록 → 그 항목 (상세·수정·딸린 후속 작업) | 개인 허브 **안** |
-   | 공용 화면의 버튼·GNB (새로 만들기, 남의 항목에 응답) | 개인 허브 **밖** |
-
-3. **역할은 축이 아니다.** 권한이 다른 두 사람이 같은 화면을 열면 각자의 것이 보이게 한다.
-   (운영 구역은 예외가 아니라 뼈대다 — §2.)
-
-4. **분류 노드는 화면이 없어도 된다. 이름은 필수다.** 한 층의 형제는 5~7개, 깊이는 3~4단까지.
-
-## 4. 절차
-
-1. `ch ia get` — 기존 IA가 있으면 축을 따른다(§2).
-2. 유저플로우에서 여정 시작점을 모은다.
-3. 뼈대를 놓고 본편의 축을 정한다(§2).
-4. 화면을 배치한다. 화면마다 §1 질문에 답한다. 답이 막히면 자리가 틀린 것이다.
-5. route는 여기서 정하지 않는다. 화면을 만들 때 따로 정한다.
-6. 트리를 그려 사용자 승인을 받는다. **표로 보여주지 마라** — 구조가 안 보인다.
-7. 저장한다(§5). §6 검증을 통과할 때까지 4~7을 되풀이한다.
-
-기존 프로젝트에서 트리만 고치는 건 싸다(`ch ia set` 한 번). route·화면 ID까지 바꾸면 spec 연결과
-와이어프레임 링크가 같이 깨진다 — 비용을 먼저 알리고 사용자 판단을 받는다.
-
-## 5. 산출물과 저장
-
-승인받은 트리를 그대로 저장한다. 웹 "IA" 페이지가 이 트리를 그대로 그린다.
-
-```
-둘러보기                     (본편 — 주제 축)
-├─ 분야 A                    (분류)
-│  └─ 항목 목록              SCR-ITEMS-A
-└─ 분야 B                    (분류)
-   └─ 항목 목록              SCR-ITEMS-B
-마이페이지                   (뼈대 — 개인 허브)
-├─ 내 항목                   SCR-MY-ITEMS
-└─ 계정 관리                 SCR-ACCOUNT
-운영                         (뼈대 — 운영 구역)
-└─ 운영 대시보드             SCR-ADMIN
-```
-
-> **한 사례**다. 본편의 축이 다르면 트리가 완전히 달라진다. 베끼지 마라.
-
-```bash
-ch ia get [--json]                  # Read-before-Write
-ch ia set --title "정보구조" --file ./ia-tree.json --content ./ia.md
-ch ia versions
-```
-
-`ia-tree.json` (통째 교체):
-
-```json
-[
-  { "type": "group", "name": "둘러보기", "note": "본편 — 주제 축", "children": [
-      { "type": "group", "name": "분야 A", "children": [
-          { "type": "screen", "screenId": "SCR-ITEMS-A" } ] } ] }
-]
-```
-
-- `group`은 `name` 필수. 화면이 없어도 노드가 된다.
-- `screen`은 `screenId`만 적는다. 이름·route는 화면에서 가져와 라벨로 쓴다.
-- 배열 순서가 곧 표시 순서다.
-- `screenId`는 실존 화면만, 중복 배치 불가(서버가 400으로 막는다).
-- 동시 편집은 `--expected-version <n>`으로 막는다(통째 교체라 나중 저장이 앞을 덮는다).
-- `--content`에는 축 선택 이유와 배치 근거를 적는다.
-
-## 6. 검증 (승인 전 필수)
-
-- [ ] 축과 그 이유가 `--content`에 적혀 있다
-- [ ] 한 층 = 한 기준
-- [ ] 같은 성격의 화면이 다른 부모에 흩어져 있지 않다
-- [ ] IA 미배치 0건 (IA 페이지가 모아서 보여준다)
-- [ ] 이름 없는 분류가 없다
-- [ ] 화면마다 "어디부터 클릭해서 오나"에 한 줄로 답할 수 있다 — **작성·수정 화면도 빠짐없이**
-- [ ] 한 층의 형제 5~7개, 깊이 3~4단
-- [ ] 유저플로우의 화면들이 트리 위에서 이어진다
-      (화면 누락 전수 대조는 [[2t-decencia-channel-screen-v2]] §5-1에서 따로 한다)
+**검증**: 부모=관문이 사실인가 · 분류 노드마다 관문 부재를 답할 수 있는가 · IA 미배치 0건
+(IA 페이지가 세어 준다).

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.32.1
+version: 1.32.3
 ---
 
 <!-- ch-version-gate -->

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

@@ -8,7 +8,7 @@ description: |
   (1) 정책정의서를 새로 쓰거나 수정할 때,
   (2) 유저플로우·기능명세를 검토하다 "이건 정해진 게 없다"는 질문이 나왔을 때,
   (3) 알림 발송 매트릭스·크레딧 지급 기준·타임아웃 처리 같은 횡단 정책을 정리할 때.
-version: 1.32.1
+version: 1.32.3
 ---
 
 <!-- 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.32.1
+version: 1.32.3
 ---
 
 <!-- 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.32.1
+version: 1.32.3
 ---
 
 <!-- ch-version-gate -->
@@ -146,20 +146,19 @@ ch specs create --id PROJ-001 --name "프로젝트 목록" \
 **절차**
 1. 기능을 **사용자 맥락**으로 묶어 화면 목록을 만든다. 같은 사용자가 한 자리에서 연달아 하는 일이면 한 화면이다.
    (묶는 원칙과 이름 규칙은 아래 "🚫 1 spec = 1 화면으로 뽑지 마라"·"🔴 화면 이름" 참조)
-2. **뼈대를 놓고 본편의 축을 정한다** — [[2t-decencia-channel-ia-v2]] §2.
-   개인 허브·운영 구역은 뼈대로 놓고(있을 때만), 나머지 본편을 주제·하려는 일·사용자 유형 중
-   하나로 가른다. 이유를 한 줄로 남긴다. 축 없이 화면부터 놓으면 형제끼리 기준이 달라진다.
-3. 화면들을 **정보구조 트리에 배치**한다 — [[2t-decencia-channel-ia-v2]] §1·§3·§4.
-   배치 기준은 "사용자가 이 화면을 찾을 때 어디를 먼저 클릭하는가"다. **Epic을 그대로 그룹으로 쓰지 않는다.**
-   ⚠️ **route는 여기서 부여하지 않는다** — 트리의 경로를 route로 옮기지 않는다(§4-4). route는 화면을
+2. 화면들의 **도달 구조를 트리로 세운다** — [[2t-decencia-channel-ia-v2]]. 원리는 하나다:
+   **관문이 부모다.** 화면마다 "사용자가 어디를 먼저 클릭해 들어오나"를 물어, 거쳐 가는 화면
+   밑에 단다. 루트는 유저플로우의 여정 시작점이다. 분류 노드(이름표)는 관문 페이지가 없는
+   묶음에만 쓴다. **Epic을 그대로 그룹으로 쓰지 않는다.**
+   ⚠️ **route는 여기서 부여하지 않는다** — 트리의 경로를 route로 옮기지 않는다. route는 화면을
    만들 때 개발·SEO 제약을 함께 보고 따로 정한다.
-4. [[2t-decencia-channel-ia-v2]] §6 **구조 검증**을 돌린다(축 명시·한 층 한 기준·형제 일관성·
-   IA 미배치 0건·탐색 역질문·깊이/폭).
-5. → **[게이트] 사람이 승인한다.** **배치표가 아니라 트리로** 보여준다 — 표에서는 구조가 보이지 않아
+3. [[2t-decencia-channel-ia-v2]]의 **검증**을 돌린다(부모=관문 사실 확인·분류 노드 정당성·
+   루트=여정 시작점·형제 일관성·IA 미배치 0건·깊이/폭).
+4. → **[게이트] 사람이 승인한다.** **배치표가 아니라 트리로** 보여준다 — 표에서는 구조가 보이지 않아
    잘못된 배치가 그대로 통과한다. 승인 전에는 아무것도 만들지 않는다.
-6. 승인받은 결과를 **저장한다** — `ch ia set --title "정보구조" --file ./ia-tree.json --content ./ia.md`
-   ([[2t-decencia-channel-ia-v2]] §5). `--file`은 분류 노드·화면 노드로 세운 **트리 JSON**이고,
-   `--content`에는 고른 축과 배치 근거를 적는다. 대화에만 남기면 나중에 무엇이 진실인지 판별할 수 없다.
+5. 승인받은 결과를 **저장한다** — `ch ia set --title "정보구조" --file ./ia-tree.json --content ./ia.md`
+   ([[2t-decencia-channel-ia-v2]]). `--file`은 트리 JSON(화면 노드도 자식을 가진다)이고,
+   `--content`에는 배치 근거를 적는다. 대화에만 남기면 나중에 무엇이 진실인지 판별할 수 없다.
    웹 "IA" 탭에서 같은 트리를 본다.
 - → OK면 8단계.
 

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

@@ -9,7 +9,7 @@ description: |
   (1) 화면(screens) 문서를 작성·수정할 때,
   (2) 화면의 표시 데이터·액션·입력 검증·예외상태를 기재할 때,
   (3) 웹 "화면" 탭의 화면 구조 뷰·화면 상세에 올릴 내용을 쓸 때.
-version: 1.32.1
+version: 1.32.3
 ---
 
 <!-- ch-version-gate -->
@@ -82,8 +82,8 @@ ch check
 - 노드를 클릭하면 화면 상세가 열린다: **좌측 와이어프레임 뷰 · 우측 디스크립션**(§1 항목들).
 - 트리가 읽히려면 route를 계층적으로 짓는다 (`/store/orders` → `/store/orders/[id]`). 화면 ID 슬러그도 계층을 반영한다.
 - 🚫 **이건 IA가 아니다.** 화면 목록을 경로로 정렬해 훑는 개발자용 그림이다. 정보구조는 **IA 페이지**에 따로 있고,
-  거기 트리는 사람이 이름 붙인 분류 노드로 세운다([[2t-decencia-channel-ia-v2]]).
-  슬래시 개수는 계층이 아니므로, 이 화면의 깊이를 IA 깊이로 읽지 않는다.
+  거기 트리는 관문 화면을 부모로 세운 도달 구조다([[2t-decencia-channel-ia-v2]]).
+  슬래시 개수는 도달 관계가 아니므로, 이 화면의 깊이를 IA 깊이로 읽지 않는다.
 - 배치가 어색해 보이면 화면을 고치지 말고 ④ IA 설계로 되돌아간다.
 
 ## 4-1. 와이어프레임 — HTML로 실제 렌더
@@ -212,7 +212,7 @@ IA는 낡아 있던 적이 있다. `ch ia get`으로 IA 트리를 받아 두 가
 - [ ] **죽은 참조** — 트리의 `screenId`가 전부 실존 화면인가. (서버가 저장 시 막지만, 화면을
       지운 뒤에는 트리에 그대로 남는다)
 
-어긋나면 화면이 아니라 **IA를 고친다**([[2t-decencia-channel-ia-v2]] §5의 `ch ia set`).
+어긋나면 화면이 아니라 **IA를 고친다**([[2t-decencia-channel-ia-v2]]의 `ch ia set`).
 
 ## 6. 흔한 함정
 

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.32.1
+version: 1.32.3
 ---
 
 <!-- ch-version-gate -->

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.32.1
+version: 1.32.3
 ---
 
 <!-- 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.32.1
+version: 1.32.3
 ---
 
 <!-- ch-version-gate -->

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

@@ -12,7 +12,7 @@ description: |
   (4) 보안/성능/접근성/호환성 비기능 TC를 시트에 채워야 할 때,
   (5) 명세 영역별 완성형 TC 번들(퍼블리싱/프론트/백엔드 디센시아 운영 관점 포함)을 가져다 쓸 때,
   (6) Sprint 종료 전 spec별 TC 통과·시나리오 통과 여부를 점검할 때.
-version: 1.32.1
+version: 1.32.3
 ---
 
 <!-- ch-version-gate -->

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

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