@decencia/ch-cli 1.32.0 → 1.32.1

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.0
+version: 1.32.1
 ---
 
 ## 역할

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.0
+version: 1.32.1
 ---
 
 ## 역할

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.0
+version: 1.32.1
 ---
 
 ## 역할

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "@decencia/ch-cli",
-  "version": "1.32.0",
+  "version": "1.32.1",
   "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.0
+version: 1.32.1
 ---
 
 <!-- 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.0
+version: 1.32.1
 ---
 
 <!-- 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.0
+version: 1.32.1
 ---
 
 <!-- ch-version-gate -->
@@ -206,13 +206,19 @@ ch specs update <specId> --db-tables ""              # 모두 해제
 
 ```bash
 ch ia get [--json]
-ch ia set --title "<제목>" --file ./ia.md   --navigations ./navigations.json --hubs ./hubs.json --entry-rules ./entry-rules.json
+ch ia set --title "<제목>" --file ./ia-tree.json --content ./ia.md [--expected-version <n>]
 ch ia versions
 ```
 
-- `--navigations`·`--hubs`·`--entry-rules`는 각각 **JSON 배열 파일**이고 **통째 교체**다. 수정 전 `ch ia get --json`으로 받아 편집한다(Read-before-Write).
-- 메뉴의 `screenId`는 실존 화면이어야 한다(없으면 400). 죽은 메뉴를 서버가 막는다.
-- **route는 여기 넣지 않는다** — 배치의 SSOT는 `ch screens --route`다.
+- `--file`은 **트리 JSON**이다(`IaNode[]`). 노드는 두 종류다 — 분류 `{"type":"group","name":"…","children":[…]}`,
+  화면 `{"type":"screen","screenId":"SCR-…"}`. **배열 순서가 곧 표시 순서**이고 **통째 교체**다.
+  수정 전 `ch ia get --json`으로 받아 편집한다(Read-before-Write).
+- `--content`는 **고른 축과 배치 근거** 마크다운이다. 트리 자체는 `--file`이 갖는다.
+- `screenId`는 실존 화면이어야 하고(없으면 400), 같은 화면을 두 번 배치해도 400이다.
+- `--expected-version`을 주면 그 사이 남이 저장했을 때 409로 막는다. 트리가 통째 교체라 이게 없으면
+  나중에 저장한 쪽이 앞사람 작업을 통째로 덮는다.
+- **route는 여기 넣지 않는다** — route의 SSOT는 `ch screens --route`다. IA 계층에서 route를 유도하지도
+  않는다(둘은 별개 그림이다).
 
 ### 화면 연결 (`ch specs screen-refs`)
 

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

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

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

@@ -2,13 +2,14 @@
 name: 2t-decencia-channel-ia-v2
 description: |
   [2t][v2] 소통채널 화면 IA(정보구조) 설계 가이드.
-  화면을 만들기 전에 정보구조를 먼저 정한다 — 사람이 이름 붙인 분류 노드와 화면 노드로 트리를 세운다.
-  배치 기준은 "사용자가 어디서 찾는가"(탐색)이지 "어느 기능에 속하는가"(도메인·Epic)도, URL 경로도 아니다.
+  화면을 만들기 전에 화면들을 어떻게 묶어 보여줄지 정한다 — 분류 노드와 화면 노드로 트리를 세운다.
+  뼈대(개인 허브·운영)를 놓고 본편의 축을 판정 순서로 정하며, 배치는 "사용자가 어디를 먼저
+  클릭하는가"로 판단한다. Epic·개발 모듈·URL은 기준이 아니다.
   Use when:
-  (1) 화면설계서를 쓰기 전에 화면들의 배치·route를 정할 때,
+  (1) 화면설계서를 쓰기 전에 화면들의 배치를 정할 때,
   (2) 기존 프로젝트의 IA가 어색해 재배치를 검토할 때,
   (3) "이 화면이 왜 여기 있지" 같은 구조 문제를 점검할 때.
-version: 1.32.0
+version: 1.32.1
 ---
 
 <!-- ch-version-gate -->
@@ -28,164 +29,127 @@ ch check
 
 # 화면 IA(정보구조) 설계
 
-화면들을 어떤 구조로 배치할지 정하는 단계다. 산출물은 **내비게이션 트리 + 화면별 route**다.
+화면을 만들기 전에, 화면들을 어떻게 묶어 보여줄지 정한다. 산출물은 **트리 하나**다.
+분류 노드(사람이 이름 붙인 묶음)와 화면 노드로 세우고, `ch ia set`으로 저장한다(§5).
 
-> **작성 순서상 ④다** — ①기능명세 → ②유저플로우 → ③정책정의서 → DB 스키마 다음, **⑤화면설계서 앞**이다.
-> 유저플로우 뒤여야 한다. 여정을 알아야 "사용자가 어디서 찾는가"로 배치할 수 있다.
+> 작성 순서는 ④다. ①기능명세 → ②유저플로우 → ③정책정의서 → DB 스키마 → **④IA** → ⑤화면설계서.
+> 유저플로우가 먼저다. 여정을 알아야 배치할 수 있다.
 
-## 0. 이 단계가 없으면 무슨 일이 생기나
+## 1. 판단 기준은 하나다
 
-IA를 따로 정하지 않으면 화면마다 route를 개별로 적게 되고, 그 route들이 모여 트리로 그려진다.
-IA가 설계물이 아니라 **부산물**이 되는 것이다. 그러면 각 화면은 그 순간 손에 잡히는 분류를 근거로
-삼는데, 보통 그게 Epic이다.
+**"사용자가 이 화면을 찾을 때 어디를 먼저 클릭하는가."**
 
-실제로 겪은 사고: 내 문의·신고·계정은 `/my` 아래 넣고, 내 공고·내 견적·내 거래는 `/buyer`·`/supplier`로
-갈랐다. 똑같은 "내 데이터"인데 왜 문의는 마이페이지이고 견적은 아닌지 설명할 근거가 없었다.
-기준 없이 두 방식을 섞은 것이다.
+§3의 규칙들은 이 질문의 결과일 뿐이다. 규칙과 답이 어긋나면 **답을 따른다.**
 
-## 1. IA의 축은 탐색이다
+- 🚫 **Epic·개발 모듈로 묶지 마라.** 사용자는 모듈 이름을 모른다.
+- 🚫 **URL로 계층을 만들지 마라.** 슬래시 개수는 계층이 아니다.
+- 계층은 기능의 포함 관계다. 목록 다음에 상세가 온다고 상세가 목록의 하위 분류는 아니다.
 
-**기준 질문: "사용자가 이 화면을 찾을 때 어디를 먼저 클릭하는가."**
-모든 배치 판단은 이 질문 하나로 한다.
+## 2. 뼈대를 놓고, 본편의 축을 정한다
 
-- 🚫 **Epic을 IA로 쓰지 마라.** Epic(AUTH·ORDER·BID…)은 명세를 관리하는 축이다. 사용자가 화면을
-  찾아가는 축과 다르다. 우연히 겹칠 수는 있지만, 겹치는지 확인하지 않고 복사하면 안 된다.
-- 🚫 **기능 소속으로 route를 정하지 마라.** "견적 작성은 공급자 기능이니 `/supplier`"는 개발자의 분류다.
-  공급회원이 "내가 낸 견적"을 찾을 때 실제로 어디를 누르는지와는 별개다.
+### 뼈대 — 선택이 아니다
 
-### 계층은 route가 아니라 기능의 포함 관계로 나눈다
+- 개인 데이터가 있으면 → **개인 허브** 하나 (마이페이지류)
+- 운영자가 있으면 → **운영 구역** 하나
+- 나머지가 **본편**이다
 
-**URL은 결과이지 기준이 아니다.** 슬래시 개수는 계층이 아니다.
+로그인 경계는 뼈대가 처리한다. "로그인 전후로 갈리나"는 거의 모든 서비스가 "예"라서 축이 되지
+못한다. 없는 조각은 놓지 않는다 — 사내 툴은 개인 허브 없이 바로 본편으로 간다.
 
-Depth를 가르는 것은 "이 화면이 저 화면의 하위 기능인가"다. 실무 예로 1차 "주문하기" → 2차
-"배송지 확인"·"결제" → 3차 "주소 검색"처럼 나눈다. 순서(Step)와 계층(Depth)도 다르다 —
-목록 다음에 상세가 온다고 해서 상세가 목록의 하위 분류인 것은 아니다.
+### 본편의 축 — 여기서부터가 판정이다
 
-route는 개발 편의·REST 관례·SEO로 정해진다. 그 값으로 계층을 유도하면 IA가 URL에 종속된다.
-IA 트리와 route는 별개로 정하고, route는 노드에 붙는 부가 정보로 본다.
+트리의 한 층은 **한 가지 기준**으로만 가른다. **위에서부터 물어 처음 "예"에서 멈춘다.**
 
-**묶음의 근거가 흐릿하면 카드소팅을 쓴다.** 화면 이름을 카드로 만들어 사용자가 직접 묶게 하는
-표준 방법이고, 결과가 곧 분류 노드의 후보가 된다.
+1. 둘러보고 소비하는 것이 중심인가? → **주제**로 가른다 (분야별 / 종류별)
+2. 목적을 갖고 와서 일하는 것이 중심인가? → **하려는 일**로 가른다 (만들기 / 관리 / 분석)
+3. 이용자 군이 겹치지 않고 각자 다른 일을 하나? → **사용자 유형**으로 가른다
 
-## 2. 배치 규칙 4가지
+층을 내려갈 때마다 다시 묻되, 위에서 답한 질문은 건너뛴다. 갈리면 "어느 쪽이 그 층을 5~7개로
+고르게 가르나"로 정한다.
 
-1. **"내 ○○"는 한 부모 아래 모은다.** 내 공고·내 견적·내 거래·내 문의·내 계정은 역할이 달라도
-   같은 허브에 둔다. 하나만 밖에 있다면 그 이유를 한 줄로 답할 수 있어야 한다.
-2. **역할 차이는 부모를 나누는 축이 아니다.** 같은 위치에서 내용이 갈리게 한다.
-   구매회원이 `/my/deals`를 열면 구매 거래가, 공급회원이 열면 공급 거래가 보인다.
-3. **분류 노드는 화면이 없어도 된다.** "공개 영역"·"회원 영역"처럼 사람이 이름 붙인 묶음은
-   그 자체로 노드다. 다만 **이름이 있어야 한다** — 이름 없는 경로 조각을 노드로 남기지 않는다.
-   묶음에 입구 화면이 필요하다고 판단되면 그건 별개의 화면으로 만든다.
-4. **최상위는 GNB에 담기는 수만큼.** 보통 5~7개다. 넘으면 묶고, 3~4단계보다 깊어지면 평평하게 편다.
+- **시작 전에 `ch ia get`으로 기존 IA를 읽는다.** 축이 이미 있으면 따른다. 바꾸려면 사용자
+  합의를 받는다.
+- **정한 축과 이유를 `--content`에 적는다.**
 
-## 3. 절차
+## 3. 배치 규칙
 
-입력: 화면 목록(아직 route는 없는 상태) · 유저플로우 · 역할 정의 · 허브 성격 spec
+1. **같은 성격은 한 부모 아래 모은다.** 하나만 밖에 있다면 이유를 한 줄로 답할 수 있어야 한다.
 
-1. **역할별 진입 직후 화면**을 정한다. 로그인하면 어디로 가나. 그 화면이 그 역할의 허브다.
-2. **최상위 내비게이션 항목**을 뽑는다. 비회원에게 보이는 것과 회원에게 보이는 것을 나눈다.
-3. 화면을 항목 아래 **배치**한다. 배치할 때마다 §1의 기준 질문에 답한다. 답이 막히면 그 화면은
-   자리가 틀린 것이다.
-4. **route는 따로 정한다.** 트리의 경로를 route로 그대로 옮기지 않는다. IA는 사용자가 찾는 길이고
-   route는 개발·SEO 제약을 받는다. 둘이 닮을 수는 있지만 한쪽이 다른 쪽을 결정하지는 않는다.
-5. **트리를 그려 사용자 승인을 받고, 그대로 저장한다**(§4).
-6. §5 구조 검증을 통과할 때까지 3~5를 되풀이한다.
+2. **소속은 진입점으로 가른다. 화면 이름으로 가르지 마라.**
 
-## 4. 산출물 — 트리로 제시한다
+   | 어디서 들어오나 | 자리 |
+   |---|---|
+   | 내 목록 → 그 항목 (상세·수정·딸린 후속 작업) | 개인 허브 **안** |
+   | 공용 화면의 버튼·GNB (새로 만들기, 남의 항목에 응답) | 개인 허브 **밖** |
 
-```
-공개 영역                                  (분류)
-├─ 인증                                    (분류)
-│  ├─ 로그인                               SCR-LOGIN           누구나
-│  └─ 회원가입                             SCR-SIGNUP          누구나
-├─ 제품·공고                               (분류)
-│  ├─ 제품 검색                            SCR-PRODUCTS        누구나
-│  └─ 공개 공고                            SCR-RFQ-LIST        누구나
-└─ 고객지원                                (분류)
-   └─ 문의                                 SCR-SUPPORT         누구나
-회원 영역                                  (분류)
-├─ 구매 활동                               (분류)
-│  ├─ 내 구매공고                          SCR-MY-RFQS         구매회원
-│  └─ 내 견적                              SCR-MY-BIDS         공급회원
-└─ 계정                                    (분류)
-   └─ 계정·회사 관리                        SCR-MY-ACCOUNT      회원
-관리자                                     (분류)
-└─ 관리자 콘솔                             SCR-ADMIN-DASH      관리자
-```
+3. **역할은 축이 아니다.** 권한이 다른 두 사람이 같은 화면을 열면 각자의 것이 보이게 한다.
+   (운영 구역은 예외가 아니라 뼈대다 — §2.)
+
+4. **분류 노드는 화면이 없어도 된다. 이름은 필수다.** 한 층의 형제는 5~7개, 깊이는 3~4단까지.
+
+## 4. 절차
 
-**배치표(행=화면, 열 하나가 route)로 승인받지 않는다.** 표에서는 구조가 보이지 않아서, 잘못된 배치가
-그대로 통과한다. 사람은 트리를 봐야 "견적이 왜 마이페이지 밖에 있지"를 즉시 알아챈다.
+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 연결과
+와이어프레임 링크가 같이 깨진다 — 비용을 먼저 알리고 사용자 판단을 받는다.
 
-트리를 승인받고 대화에만 남기면, 나중에 구조가 바뀌었을 때 무엇이 진실인지 판별할 수 없다.
-**IA 리소스**(프로젝트당 1건)에 올린다 — 웹 "IA" 페이지가 이 트리를 그대로 그린다.
+## 5. 산출물과 저장
+
+승인받은 트리를 그대로 저장한다. 웹 "IA" 페이지가 이 트리를 그대로 그린다.
+
+```
+둘러보기                     (본편 — 주제 축)
+├─ 분야 A                    (분류)
+│  └─ 항목 목록              SCR-ITEMS-A
+└─ 분야 B                    (분류)
+   └─ 항목 목록              SCR-ITEMS-B
+마이페이지                   (뼈대 — 개인 허브)
+├─ 내 항목                   SCR-MY-ITEMS
+└─ 계정 관리                 SCR-ACCOUNT
+운영                         (뼈대 — 운영 구역)
+└─ 운영 대시보드             SCR-ADMIN
+```
 
-사람이 승인한 트리와 화면에 뜨는 트리는 **같아야 한다.** 도구가 route로 다시 그리던 시절에는
-둘이 갈라졌고, 그게 이 개편의 이유다.
+> **한 사례**다. 본편의 축이 다르면 트리가 완전히 달라진다. 베끼지 마라.
 
 ```bash
-ch ia get [--json]                  # 현재 IA (Read-before-Write)
-ch ia set --title "LUBridge 정보구조" \
-  --file ./ia-tree.json \           # 트리 (아래 형식)
-  --content ./ia.md                 # 배치 근거(마크다운)
-ch ia versions                      # 변경 이력
+ch ia get [--json]                  # Read-before-Write
+ch ia set --title "정보구조" --file ./ia-tree.json --content ./ia.md
+ch ia versions
 ```
 
-`ia-tree.json` — 노드는 두 종류다 (통째 교체):
+`ia-tree.json` (통째 교체):
 
 ```json
 [
-  { "type": "group", "name": "공개 영역", "note": "로그인 없이 접근", "children": [
-      { "type": "group", "name": "인증", "children": [
-          { "type": "screen", "screenId": "SCR-LOGIN" },
-          { "type": "screen", "screenId": "SCR-SIGNUP" } ] },
-      { "type": "screen", "screenId": "SCR-PRODUCTS" } ] },
-  { "type": "group", "name": "관리자", "children": [
-      { "type": "screen", "screenId": "SCR-ADMIN-DASH" } ] }
+  { "type": "group", "name": "둘러보기", "note": "본편 — 주제 축", "children": [
+      { "type": "group", "name": "분야 A", "children": [
+          { "type": "screen", "screenId": "SCR-ITEMS-A" } ] } ] }
 ]
 ```
 
-- `group`은 `name`이 필수다. **화면이 없어도 노드가 된다** — 분류 노드가 여기 산다.
-- `screen`은 `screenId`만 갖는다. 이름·route는 화면에서 가져와 라벨로 쓰므로 **적지 않는다.**
-  같은 값을 두 곳에 두면 반드시 어긋난다.
-- **배열 순서가 곧 표시 순서다.** 순서 필드를 따로 두지 않는다.
-- `screenId`는 **실존 화면만 허용**한다(없으면 서버가 400). 같은 화면을 두 번 배치해도 400이다.
-- 트리에 없는 화면은 IA 페이지에서 **"IA 미배치"**로 모여 보인다. 화면을 새로 만들고 IA에 안 넣으면
-  거기 쌓이므로, 작업을 끝낼 때 0건인지 본다.
-- `--content`에는 **배치 근거**를 적는다. 근거가 사라지면 다음 사람은 이유를 모른 채 트리만 보게 되고,
-  그때부터 IA는 다시 흐트러진다.
-
-## 5. 구조 검증 (승인 전 필수)
-
-- [ ] **형제 일관성** — 같은 성격의 화면이 서로 다른 부모에 흩어져 있지 않은가. ("내 ○○"가 대표적)
-- [ ] **IA 미배치 0건** — 트리에 안 들어간 화면이 남아 있지 않은가. IA 페이지가 따로 모아 보여준다.
-- [ ] **이름 없는 분류 없음** — 모든 `group`에 사람이 읽을 이름이 있는가. 경로 조각을 이름 대신 쓰지 않았는가.
-- [ ] **탐색 역질문** — 화면마다 "사용자가 이걸 찾으려면 어디부터 클릭하나"를 한 줄로 답할 수 있는가.
-      답이 "URL 직접 입력"이면 그 화면은 IA에 자리가 없는 것이다.
-- [ ] **명세 대조** — 허브 성격 spec(마이페이지 등)이 "무엇을 담는다"고 적어놨으면 IA가 그대로 따르는가.
-      어긋나면 둘 중 하나가 틀린 것이므로 임의로 정하지 말고 사용자에게 묻는다.
-- [ ] **깊이·폭** — 최상위 5~7개, 경로 3단계 이내.
-- [ ] **유저플로우 도달** — 각 플로우의 화면들이 트리 위에서 이어지는가.
-      (누락 화면 전수 대조는 화면을 만든 뒤 [[2t-decencia-channel-screen-v2]] §5-1에서 따로 한다)
-
-## 6. 기존 프로젝트의 IA를 고칠 때
-
-IA 트리만 고치는 것은 싸다. 트리는 통째 교체라 `ch ia set` 한 번이면 되고, route도 화면 ID도
-건드리지 않는다. **IA가 어색하다고 route부터 고치지 마라.**
-
-route까지 함께 바꾸기로 했다면 그때 비용이 든다. **화면 ID는 불변**이라 재배치하면 ID와 경로가
-어긋나 보인다(`SCR-SUPPLIER-BID-LIST`가 `/my/bids`에 놓이는 식). 감수하거나 삭제 후 재생성해야
-하는데, 후자는 spec 연결(`screenRefs`)이 끊긴다. 와이어프레임의 GNB·서브내비와 `data-screen-link`도
-함께 고쳐야 한다. **비용을 먼저 알리고 사용자 판단을 받는다.**
-
-## 7. 흔한 함정
-
-- **Epic을 그대로 그룹으로 쓰기** — 이 단계가 생긴 이유다 (§1).
-- **URL로 IA를 짜기** — **슬래시 개수는 계층이 아니다.** route를 그대로 트리로 옮기면 성격이 다른
-  화면이 한 줄에 서고, 목록과 상세가 부모-자식이 되며, 깊이가 아무 정보도 주지 않는다 (§1).
-- **역할로 최상위를 가르기** — `/buyer`·`/supplier`로 시작하면 "내 것"이 두 곳으로 찢어진다 (§2-2).
-- **배치표로 승인받기** — 구조가 안 보인다 (§4).
-- **화면을 다 만든 뒤에 IA를 보기** — 그때는 되돌리는 비용이 크다 (§6).
-- **IA를 대화에만 남기기** — 승인받은 트리를 `ch ia set`으로 저장하지 않으면, 나중에 GNB가 바뀌어도
-  무엇이 진실인지 판별할 수 없다. 배치 근거는 특히 잃기 쉽다 (§4).
+- `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에서 따로 한다)

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.0
+version: 1.32.1
 ---
 
 <!-- ch-version-gate -->

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

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

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

@@ -9,7 +9,7 @@ description: |
   (1) 화면(screens) 문서를 작성·수정할 때,
   (2) 화면의 표시 데이터·액션·입력 검증·예외상태를 기재할 때,
   (3) 웹 "화면" 탭의 화면 구조 뷰·화면 상세에 올릴 내용을 쓸 때.
-version: 1.32.0
+version: 1.32.1
 ---
 
 <!-- ch-version-gate -->
@@ -212,7 +212,7 @@ IA는 낡아 있던 적이 있다. `ch ia get`으로 IA 트리를 받아 두 가
 - [ ] **죽은 참조** — 트리의 `screenId`가 전부 실존 화면인가. (서버가 저장 시 막지만, 화면을
       지운 뒤에는 트리에 그대로 남는다)
 
-어긋나면 화면이 아니라 **IA를 고친다**([[2t-decencia-channel-ia-v2]] §4의 `ch ia set`).
+어긋나면 화면이 아니라 **IA를 고친다**([[2t-decencia-channel-ia-v2]] §5의 `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.0
+version: 1.32.1
 ---
 
 <!-- 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.0
+version: 1.32.1
 ---
 
 <!-- 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.0
+version: 1.32.1
 ---
 
 <!-- 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.0
+version: 1.32.1
 ---
 
 <!-- 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.0
+version: 1.32.1
 ---
 
 <!-- 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.0
+version: 1.32.1
 ---
 
 <!-- ch-version-gate -->