@decencia/ch-cli 1.31.4 → 1.31.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.31.4
+version: 1.31.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.31.4
+version: 1.31.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.31.4
+version: 1.31.5
 ---
 
 ## 역할

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "@decencia/ch-cli",
-  "version": "1.31.4",
+  "version": "1.31.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.31.4
+version: 1.31.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.31.4
+version: 1.31.5
 ---
 
 <!-- ch-version-gate -->
@@ -335,7 +335,7 @@ ch db-tables update <tableId> --file /tmp/t.json --no-version
 # 2) db-schema (전체)
 ch db-schema get --json | jq -r '.content' > /tmp/dbschema.md
 # … 편집 (테이블 인벤토리 / ERD / 마이그레이션 노트) …
-ch db-schema set --file /tmp/dbschema.md --no-version
+ch db-schema set --title "{프로젝트명} DB 스키마" --file /tmp/dbschema.md --no-version
 
 # 3) spec — [[2t-decencia-channel-spec-v2]]
 ch specs get <specId> --json > /tmp/s.json

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.4
+version: 1.31.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.31.4
+version: 1.31.5
 ---
 
 <!-- ch-version-gate -->
@@ -65,14 +65,14 @@ PRD·spec·SQA 등 다른 어떤 산출물에도 스키마를 **정의**하지
 # 전체 스펙 문서
 ch db-schema get --json > /tmp/schema.json   # 먼저
 # content 편집
-ch db-schema set --content /tmp/schema.md --dbtype firestore
+ch db-schema set --title "{프로젝트명} DB 스키마" --file /tmp/schema.md --db-type firestore
 
 # 테이블 문서
 ch db-tables get <tableId> --json > /tmp/tbl.json
 ch db-tables update <tableId> --columns /tmp/cols.json
 ```
 
-`--content` 통째 교체, `--columns/--indexes/--security/--state-machine` 각각 통째 교체. 기존 내용 보존하려면 반드시 `get` 후 편집.
+본문(`--file`)은 통째 교체, `--columns/--indexes/--security/--state-machine` 각각 통째 교체. 기존 내용 보존하려면 반드시 `get` 후 편집.
 
 ---
 
@@ -85,7 +85,7 @@ ch db-tables update <tableId> --columns /tmp/cols.json
 | **mysql** | MySQL / MariaDB | `mysql2`, `prisma` (mysql provider) |
 | **generic** | 미정 또는 혼합 | 위 어느 것도 아닐 때 |
 
-`ch db-schema set --dbtype <type>` 로 명시. 미정이면 `generic`. DB 유형에 따라 컬럼 `type` 값·보안 규칙 `type` 값이 달라진다.
+`ch db-schema set --db-type <type>` 로 명시. 미정이면 `generic`. DB 유형에 따라 컬럼 `type` 값·보안 규칙 `type` 값이 달라진다.
 
 ---
 
@@ -172,11 +172,16 @@ erDiagram
 
 ```bash
 # 1) 위 §2 템플릿 기반으로 schema.md 작성 (테이블 인벤토리는 비어있는 상태로 시작)
-# 2) 업로드
-ch db-schema set --content schema.md --dbtype firestore
-ch db-schema get --json | jq '.content' | head        # 검증
+# 2) 업로드 — 파일은 --file로 준다 (--content는 리터럴 문자열 전용, --title 필수)
+ch db-schema set --title "{프로젝트명} DB 스키마" --file schema.md --db-type firestore
+# 3) 🚨 BLOCKING: get 라운드트립 검증 — 생략 금지
+ch db-schema get --json | jq '.content' | head
 ```
 
+> 검증에서 content가 마크다운 본문이 아니라 **한 줄짜리 파일 경로**(예: `C:/.../schema.md`)면
+> `--content`에 경로를 넘긴 사고다 — 경로도 유효한 마크다운이라 에러 없이 그대로 저장된다.
+> `--file`로 재업로드해 복구한다.
+
 ### 3-2. 새 테이블 추가 시 — 두 곳 동기화
 
 ```bash
@@ -188,7 +193,8 @@ ch db-tables create --name orders --description "주문" \
 # 2) 전체 스펙 문서의 §4 테이블 인벤토리 + §5 ERD에 orders 추가
 ch db-schema get --json | jq -r '.content' > /tmp/schema.md
 # /tmp/schema.md 편집: 인벤토리에 행 추가, ERD에 관계 추가
-ch db-schema set --content /tmp/schema.md
+ch db-schema set --title "{프로젝트명} DB 스키마" --file /tmp/schema.md
+ch db-schema get --json | jq '.content' | head   # 🚨 BLOCKING 검증(§3-1)
 ```
 
 > 테이블 생성/삭제할 때마다 전체 스펙 문서의 인벤토리·ERD·마이그레이션 노트를 함께 갱신한다.
@@ -373,9 +379,10 @@ spec은 이 상태머신을 **`columnRef`로 잇는다**. spec의 dataFlow ref
 
 ## 8. 흔한 함정
 
+- **`--content`는 리터럴 문자열이다 — 파일 경로를 주면 경로 그 자체가 본문으로 저장된다(에러 없음).** 파일은 `--file <path>`, stdin은 `--file -`. 그래서 set 후 `get` 라운드트립 검증이 BLOCKING이다(§3-1).
 - columns/indexes/securityRules/stateMachines JSON은 **전체 교체**. 일부 수정 시 반드시 `get` 후 편집.
 - 상태 컬럼의 생애주기(주문 status 등)를 spec 쪽(흐름·레거시 stateTransitions)에 정의하면 SSOT 위반 — 저장되는 엔티티 상태는 db-tables.stateMachines가 SSOT. spec의 흐름은 `toState` 링크로 참조만 한다.
-- 전체 스펙 문서의 `--content`도 통째 교체. 작은 수정도 `get` 후 부분 편집해 통째 전송.
+- 전체 스펙 문서의 본문도 통째 교체. 작은 수정도 `get` 후 부분 편집해 `--file`로 통째 전송.
 - `relatedSpecIds`를 JSON에 명시해도 서버가 무시 (자동 관리 영역).
 - 새 테이블을 만들고 전체 스펙 인벤토리 갱신을 잊으면, 문서 읽는 사람이 그 테이블의 존재를 모른다.
 - 보안 정책을 테이블별 securityRules에만 적고 전체 스펙의 §7에 적지 않으면 일관성 검토가 누락된다.
@@ -389,7 +396,7 @@ spec은 이 상태머신을 **`columnRef`로 잇는다**. spec의 dataFlow ref
 
 신규 프로젝트의 DB를 처음 설계할 때:
 
-1. DB 유형 확정 → `ch db-schema set --dbtype firestore` 등
+1. DB 유형 확정 → 문서 업로드 시 `--db-type firestore` 등으로 명시
 2. 전체 스펙 문서 초안 (§1 개요 / §2 설계 원칙 / §3 네이밍 규칙 / §7 보안 일관성) 작성
 3. 핵심 테이블 1~2개를 `ch db-tables create`로 등록 (users 먼저)
 4. 전체 스펙 §4 인벤토리에 추가, §5 ERD에 노드 추가

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.4
+version: 1.31.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.31.4
+version: 1.31.5
 ---
 
 <!-- ch-version-gate -->

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

@@ -8,7 +8,7 @@ description: |
   (1) 정책정의서를 새로 쓰거나 수정할 때,
   (2) 유저플로우·기능명세를 검토하다 "이건 정해진 게 없다"는 질문이 나왔을 때,
   (3) 알림 발송 매트릭스·크레딧 지급 기준·타임아웃 처리 같은 횡단 정책을 정리할 때.
-version: 1.31.4
+version: 1.31.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.31.4
+version: 1.31.5
 ---
 
 <!-- ch-version-gate -->
@@ -41,14 +41,17 @@ PRD는 **무엇을 왜 만드는가(기능·가치·범위)의 개요**만 다
 
 ## 0. Read-before-Write
 
-PRD content는 마크다운 한 덩어리. 일부만 바꿔도 `--content`는 통째 덮어쓰므로:
+PRD content는 마크다운 한 덩어리. 일부만 바꿔도 본문은 통째 덮어쓰므로:
 
 ```bash
 ch prd get --json > /tmp/prd.json                  # 1) 현재 본문 추출
 # 본문 편집
-ch prd set --content /tmp/prd-edited.md            # 2) 통째 교체 (버전 기록됨)
+ch prd set --title "{프로젝트명} PRD" --file /tmp/prd-edited.md   # 2) 통째 교체 (버전 기록됨)
+ch prd get --json | jq '.content' | head           # 3) 🚨 검증 — 경로 한 줄이면 --content 사고
 ```
 
+> `--content`는 **리터럴 문자열 전용**이다 — 파일 경로를 주면 에러 없이 경로가 본문으로 저장된다. 파일은 반드시 `--file <path>`.
+
 ## 1. 권장 목차 (Epic-Story 추적성)
 
 ```markdown

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.4
+version: 1.31.5
 ---
 
 <!-- ch-version-gate -->

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

@@ -9,7 +9,7 @@ description: |
   (1) 화면(screens) 문서를 작성·수정할 때,
   (2) 화면의 표시 데이터·액션·입력 검증·예외상태를 기재할 때,
   (3) 웹 "화면" 탭의 IA 트리·화면 상세에 올릴 내용을 쓸 때.
-version: 1.31.4
+version: 1.31.5
 ---
 
 <!-- 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.4
+version: 1.31.5
 ---
 
 <!-- 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.31.4
+version: 1.31.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.31.4
+version: 1.31.5
 ---
 
 <!-- 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.31.4
+version: 1.31.5
 ---
 
 <!-- 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.31.4
+version: 1.31.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.31.4
+version: 1.31.5
 ---
 
 <!-- ch-version-gate -->