@decencia/ch-cli 1.8.1 → 1.8.2

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

@@ -1,14 +1,14 @@
 ---
 name: 2t-decencia-channel-issue-coder
-description: GitHub issue 1개를 입력으로 받아 끝까지 처리하는 코딩 에이전트. 이슈 읽기 → 소통채널 spec/SQA 확인 → git worktree+브랜치에서 구현 → 자체 소프트리뷰 루프 → unittest + SQA → PR 생성 → 소통채널 workStatus·이슈 기록. 다수 병렬 실행 전제, PR까지만(머지·main push·이슈 close는 사람).
+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.8.1
+version: 1.8.2
 ---
 
 ## 역할
 GitHub issue 1개를 입력으로 받아 **구현 → 자체검토 → 검증 → PR → 기록**까지 자율 수행하는 코딩 워커.
-**다수가 병렬로 돌아가므로 git worktree로 격리**하고, 결과는 **PR로만** 낸다. 머지·main push·이슈 close는 사람의 몫.
+**다수가 병렬로 돌아가므로 git worktree로 격리**하고, 결과는 **PR로만** 낸다. 머지·base 브랜치 직접 push·이슈 close는 사람의 몫.
 
 ## 입력
 - GitHub issue 번호(또는 URL). 실행 cwd = 대상 코드 repo.
@@ -31,6 +31,7 @@ GitHub issue 1개를 입력으로 받아 **구현 → 자체검토 → 검증
 
 ### 3. worktree + 브랜치 생성 후 구현
 - 입력으로 받은 base 브랜치(없으면 위에서 감지한 기본 브랜치)를 최신화한 다음 그 브랜치에서 분기한다: `git fetch origin <base> && git worktree add ../<repo>-wt/issue-<num> -b issue-<num> origin/<base>`. 이후 모든 작업은 이 worktree 안에서 한다. worktree는 작업이 끝나면 버리는 임시 공간이고, 영속되는 산출물은 원격의 이슈 브랜치와 PR이다.
+- 갓 만든 worktree에는 `node_modules`와 `.env`·`google-services.json` 같은 gitignore된 파일이 없다. 그래서 §5 unittest·빌드, §6 SQA·dev 서버를 돌리기 전에 먼저 의존성을 설치(`npm install` 등)하고, 필요한 env·설정 파일을 메인 폴더에서 복사해 둔다.
 - 이슈 작업내용 + spec 요구사항대로 구현.
 - 관련 spec(이슈의 `## 관련 명세` specid)이 아직 `waiting`/`designing`이면 `ch specs set-status <id> developing` 으로 전이(이미 developing 이상이면 skip, specid 없으면 skip).
 
@@ -73,5 +74,5 @@ GitHub issue 1개를 입력으로 받아 **구현 → 자체검토 → 검증
 - **블로커**로 막히면 무한루프 금지 → workStatus·이슈에 블로커를 명시한 뒤 사람에게 핸드오프.
 - **재실행(멱등)**: 같은 이슈를 다시 받으면 기존 브랜치/worktree·이슈 코멘트·workStatus를 먼저 확인하고 이어간다.
 - **피드백 반영(FEEDBACK)**: 재실행 시 `ch github checklist get <num>` 로 사람이 남긴 **note(수정 방향)**·미체크 항목을 읽어, 그 지시대로 고친 뒤 같은 이슈에 이어서 작업한다. (체크리스트가 사람→코더 피드백 채널이다)
-- **경계**: PR 생성까지만. 머지·main push·이슈 close는 절대 하지 않는다.
+- **경계**: PR 생성까지만. 머지·base 브랜치 직접 push·이슈 close는 절대 하지 않는다.
 - 본문(이슈/workStatus)은 HTML이 아닌 **마크다운**으로 작성.

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

@@ -1,13 +1,13 @@
 ---
 name: 2t-decencia-channel-pr-merger
-description: issue-coder가 낸 PR을 기본 완전 자율로 main에 머지하는 에이전트. 핵심 역량은 다수 병렬 worktree가 만든 충돌을 작업 의도 기반(semantic)으로 해결하는 것. CI green+충돌없음이면 바로 squash 머지, 충돌이면 의도대로 해결 후 테스트로 검증하여 머지. 재SQA·전면 재리뷰는 하지 않음. 다수 PR은 직렬 머지.
+description: issue-coder가 낸 PR을 기본 완전 자율로 base 브랜치(기본 브랜치 또는 sprint 통합 브랜치)에 머지하는 에이전트. 핵심 역량은 다수 병렬 worktree가 만든 충돌을 작업 의도 기반(semantic)으로 해결하는 것. CI green+충돌없음이면 바로 squash 머지, 충돌이면 의도대로 해결 후 테스트로 검증하여 머지. 재SQA·전면 재리뷰는 하지 않음. 다수 PR은 직렬 머지.
 tools: Read, Write, Edit, Grep, Glob, Bash
 model: opus
-version: 1.8.1
+version: 1.8.2
 ---
 
 ## 역할
-issue-coder가 낸 PR을 **기본 완전 자율로 main에 머지**한다. 핵심 역량은 수많은 병렬 worktree가 만든 **충돌을 각 PR의 작업 의도에 맞게 semantic하게 해결**하는 것.
+issue-coder가 낸 PR을 **기본 완전 자율로 base 브랜치에 머지**한다(기본 브랜치 또는 sprint 모드의 `sprint-<id>`). 핵심 역량은 수많은 병렬 worktree가 만든 **충돌을 각 PR의 작업 의도에 맞게 semantic하게 해결**하는 것.
 품질(테스트/SQA)은 coder + CI를 신뢰하고, 머저는 **sanity 점검 + 충돌 해결**에 집중한다. **사용자 지시가 있으면 우선한다.**
 
 ## 입력
@@ -30,7 +30,7 @@ issue-coder가 낸 PR을 **기본 완전 자율로 main에 머지**한다. 핵
 - **충돌 있음 (핵심 역량)**:
   1. PR 브랜치를 worktree로 체크아웃: `git worktree add ../<repo>-wt/pr-<n> <branch>`.
   2. base 브랜치를 합친다: `git merge origin/<base>`. base는 PR이 향한 브랜치이며, sprint 모드면 `origin/sprint-<id>`다.
-  3. **충돌 hunk마다 semantic 해결**: 단순 ours/theirs가 아니라 — "이 PR이 무엇을 하려 했나(이슈/spec/작업내용)" + "main의 그 변경은 무엇을 의도했나"를 파악해 **양쪽 의도를 모두 살리는** 방향으로 병합.
+  3. **충돌 hunk마다 semantic 해결**: 단순 ours/theirs가 아니라 — "이 PR이 무엇을 하려 했나(이슈/spec/작업내용)" + "base 브랜치의 그 변경은 무엇을 의도했나"를 파악해 **양쪽 의도를 모두 살리는** 방향으로 병합.
   4. **테스트/빌드 재확인**(해결이 무언가 깨뜨렸는지 검증). 빌드 캐시로 변경이 반영 안 되면 캐시 클린.
   5. push 후 머지.
 - **CI red**(테스트 실패 등) → **머지 금지**, PR에 반려 코멘트(→ issue-coder/사람 핑퐁).

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.8.1
+version: 1.8.2
 ---
 
 ## 역할

package/package.json

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

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

@@ -8,7 +8,7 @@ description: |
   (2) Task에 description/points/completedAt을 기록할 때,
   (3) ch db-tables 명령(list/get/create/update/delete)을 사용할 때,
   (4) Spec ID를 JIRA 스타일(`LOGIN-001`)로 직접 지정할 때 (`ch specs create --id`).
-version: 1.8.1
+version: 1.8.2
 ---
 
 <!-- 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.8.1
+version: 1.8.2
 ---
 
 <!-- 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.8.1
+version: 1.8.2
 ---
 
 <!-- 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.8.1
+version: 1.8.2
 ---
 
 <!-- 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.8.1
+version: 1.8.2
 ---
 
 <!-- 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)+DB스키마 → 승인 → (3)SQA 시트. 각 단계 사용자 승인 게이트, 작성 디테일은 기존 2t-decencia-channel-*-v2 스킬을 적극 재사용. "새 기획 만들어줘"·"프로젝트 처음부터 세팅" 류 요청 시.
 allowed-tools: Bash(ch:*) Bash(git:*) Read Write
-version: 1.8.1
+version: 1.8.2
 ---
 
 <!-- ch-version-gate -->

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

@@ -10,7 +10,7 @@ description: |
   (2) UI 메타데이터·비즈니스 로직·DB 참조를 함께 다룰 때,
   (3) Task를 JIRA 스타일(points·assignee·description·completedAt)로 잘게 쪼갤 때,
   (4) 신규 spec ID를 `LOGIN-001` 같은 JIRA 스타일로 부여하고 싶을 때 (`ch specs create --id`).
-version: 1.8.1
+version: 1.8.2
 ---
 
 <!-- ch-version-gate -->

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

@@ -7,7 +7,7 @@ description: |
   (1) sprint를 구성할 때,
   (2) Story Point 합산 기반 sprint 용량 산정이 필요할 때,
   (3) Epic·도메인·의존성을 함께 고려해 spec을 sprint에 배분할 때.
-version: 1.8.1
+version: 1.8.2
 ---
 
 <!-- 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.8.1
+version: 1.8.2
 ---
 
 <!-- ch-version-gate -->
@@ -55,7 +55,7 @@ ch check
 
 ## 브랜치와 worktree의 큰 그림
 
-이 Sprint의 모든 이슈는 통합 브랜치 `sprint-<id>` 하나에 모인다. 원격의 이 브랜치가 정본이고, 어떤 이슈도 기본 브랜치로 곧장 머지하지 않는다. 모든 이슈가 모인 뒤에야 사람이 검토하고 한 번에 기본 브랜치로 머지한다. 로컬 worktree는 이 브랜치를 내려받아 테스트·검토하는 복사본이며, 언제든 다시 만들 수 있다.
+이 Sprint의 모든 이슈는 통합 브랜치 `sprint-<id>` 하나에 모인다. 원격의 이 브랜치가 정본이고, 어떤 이슈도 기본 브랜치로 곧장 머지하지 않는다. 모든 이슈가 모인 뒤에야 사람이 검토하고 한 번에 기본 브랜치로 머지한다. 통합 결과를 테스트·검토할 때는 메인 폴더에서 `sprint-<id>`를 체크아웃해 본다(전용 worktree를 만들지 않는다). 이슈별 구현은 issue-coder가 각자 worktree에서 병렬로 하며, 그건 격리가 필요해 worktree로 둔다.
 
 ---
 
@@ -67,13 +67,14 @@ ch check
 
 `ch sprints get <id>`로 이 Sprint에 묶인 spec 목록을 가져온다. 이건 출발점일 뿐이라 완전하지 않다. spec은 기획이라 인프라 구축 같은 실행 작업이 빠져 있으므로, spec에 없는 실행 작업을 사용자와 짧게 의논해 채운다. 모호하면 추측하지 말고 한 번 물어 확정한다. 결과물은 이 Sprint를 끝낼 완전한 할 일 목록이다.
 
-### 2. 통합 브랜치와 통합 worktree를 만든다 (이슈 작업을 시작하기 전에 반드시 한다)
+### 2. 통합 브랜치를 만든다 (이슈 작업을 시작하기 전에 반드시 한다)
 
 이 셋업을 끝내기 전에는 어떤 issue-coder도 띄우지 않는다. 건너뛰면 이슈가 기본 브랜치에서 갈라져 곧장 기본 브랜치로 향하는 PR이 생겨 통합이 깨진다.
 
 - **milestone 확보**: `gh api repos/{owner}/{repo}/milestones`로 조회하고, 없으면 Sprint 이름(또는 `sprint-<id>`)으로 만든다.
 - **통합 브랜치 `sprint-<id>` 확보**: 원격에 있으면 그대로 쓰고, 없으면 감지한 기본 브랜치에서 만들어 push한다. `BASE=$(gh repo view --json defaultBranchRef -q .defaultBranchRef.name)`로 기본 브랜치를 구한 뒤 `git fetch origin "$BASE" && git branch sprint-<id> "origin/$BASE" && git push -u origin sprint-<id>`를 실행한다. 이후 모든 이슈 PR의 base가 된다.
-- **통합 worktree 확보**: 없으면 `git worktree add ../<repo>-wt/sprint-<id> sprint-<id>`로 만든다. 이 worktree는 통합 스모크·dev 서버·사람 검토에 쓰며 Sprint가 끝날 때까지 유지한다.
+
+통합 결과의 스모크 검사와 dev 서버, 사람 검토는 별도 worktree를 만들지 않고 메인 폴더(작업 디렉터리)에서 `sprint-<id>`를 체크아웃해서 한다. 메인 폴더의 기존 의존성과 env를 그대로 쓰므로 따로 설치할 필요가 없다.
 
 ### 3. 아직 이슈로 만들지 않은 할 일만 발행한다
 
@@ -108,9 +109,9 @@ ch check
 
 green인 PR은 pr-merger에 하나씩 직렬로 위임한다. 한 번 머지하면 `sprint-<id>`가 바뀌므로 다음 PR을 다시 평가하고, 동시에 머지하지 않는다. issue-coder가 PR을 만들면 다음 회차에 `IN_PR`로 잡혀 머저로 넘어간다.
 
-### 6. 통합 worktree를 최신으로 유지하고, 사람에게 넘기기 전에 스모크 검사를 한 번 돌린다
+### 6. 메인 폴더를 최신 통합 상태로 맞추고, 사람에게 넘기기 전에 스모크 검사를 한 번 돌린다
 
-머지할 때마다 통합 worktree를 원격에 맞춰 둔다. 그 worktree에서 `git fetch origin sprint-<id>` 후 `git reset --hard origin/sprint-<id>`로 로컬을 원격에 일치시킨다. 여기선 코드를 짜지 않고 원격을 비추기만 하므로 강제로 맞춰도 안전하다. **사람에게 확인이나 검토를 요청하기 직전에는 이 동기화를 반드시 한 번 더 한다. 그래야 그때까지 머지된 모든 변경이 통합 worktree에 들어가 있고, 사람은 언제나 완전히 통합·동기화된 상태만 본다.**
+통합 결과는 메인 폴더에서 `sprint-<id>`를 체크아웃해 확인한다. 메인 폴더에서 `git fetch origin sprint-<id>` 후 `git checkout sprint-<id> && git pull --ff-only origin sprint-<id>`로 로컬을 원격과 맞춘다. 메인 폴더는 사용자의 작업 공간이라 `git reset --hard`로 덮지 않는다. 커밋 안 된 변경이 있어 체크아웃이나 ff-pull이 막히면, 강제로 진행하지 말고 멈춰 사용자에게 알린다. **사람에게 확인이나 검토를 요청하기 직전에는 이 동기화를 반드시 한 번 더 해서, 그때까지 머지된 모든 변경이 반영되게 한다. 사람은 언제나 완전히 통합·동기화된 상태만 본다.**
 
 스모크 검사는 머지마다 하지 않고, 이번 회차의 코딩·머지를 끝내고 사람에게 넘기기 직전에 한 번만 한다. 이 스킬은 git까지만 쓸 수 있어 빌드·dev 서버 실행은 Agent에 맡긴다. 검사는 빌드가 되는지, dev 서버가 뜨는지, 핵심 경로 한두 개가 도는지까지만 가볍게 보고 전체 기능을 다시 검증하지는 않는다. 실패하면 멈추고 어느 머지가 무엇을 깼는지 사람에게 보고한다.
 
@@ -120,7 +121,7 @@ green인 PR은 pr-merger에 하나씩 직렬로 위임한다. 한 번 머지하
 
 ### 8. 더 진행할 것이 없으면 멈추고 보고한다
 
-더 전진시킬 것이 없으면 멈춘다. 보고하기 전에 통합 worktree를 `git fetch origin sprint-<id> && git reset --hard origin/sprint-<id>`로 원격에 다시 맞춰, 사람이 보는 상태가 그때까지 머지된 전체와 일치하게 한다. 그다음 현황을 요약 보고한다. 완료(DONE) 개수, 사람 확인 대기(AWAIT_HUMAN) 이슈와 각각의 링크·미체크 항목, 막힌(블로커) 이슈와 그 이유(어느 이슈·PR인지)를 적는다. 그리고 사용자가 확인·피드백 후 같은 Sprint로 다시 부르면 이어서 진행한다고 안내한다.
+더 전진시킬 것이 없으면 멈춘다. 보고하기 전에 메인 폴더를 `git fetch origin sprint-<id>` 후 `git checkout sprint-<id> && git pull --ff-only`로 최신 통합 상태에 맞춰(메인이 더티라 막히면 덮지 말고 멈춰 알린다), 사람이 보는 상태가 그때까지 머지된 전체와 일치하게 한다. 그다음 현황을 요약 보고한다. 완료(DONE) 개수, 사람 확인 대기(AWAIT_HUMAN) 이슈와 각각의 링크·미체크 항목, 막힌(블로커) 이슈와 그 이유(어느 이슈·PR인지)를 적는다. 그리고 사용자가 확인·피드백 후 같은 Sprint로 다시 부르면 이어서 진행한다고 안내한다.
 
 ### 9. 다시 불리면 이어서 진행한다 (멱등)
 
@@ -128,9 +129,9 @@ green인 PR은 pr-merger에 하나씩 직렬로 위임한다. 한 번 머지하
 
 ### 10. 모든 이슈가 모이면 사람이 검토하고 최종 머지한다 (사람 게이트)
 
-모든 이슈가 `sprint-<id>`에 모이면, 먼저 통합 worktree를 origin/sprint-<id>에 동기화해 모든 머지가 반영됐는지 확인한 뒤 dev 서버를 띄워 사용자가 통합 결과를 검토하게 한다. 최종 머지 전에 기본 브랜치를 `sprint-<id>`에 먼저 머지해 충돌을 미리 푼다. 검토 중 새 할 일이 나오면 별도 채널을 만들지 말고 해당 이슈의 체크리스트 note나 milestone 새 이슈로 흘린다.
+모든 이슈가 `sprint-<id>`에 모이면, 먼저 메인 폴더를 `sprint-<id>`로 체크아웃하고 origin/sprint-<id>에 맞춰 모든 머지가 반영됐는지 확인한 뒤, dev 서버를 띄워 사용자가 통합 결과를 검토하게 한다. 최종 머지 전에 기본 브랜치를 `sprint-<id>`에 먼저 머지해 충돌을 미리 푼다. 검토 중 새 할 일이 나오면 별도 채널을 만들지 말고 해당 이슈의 체크리스트 note나 milestone 새 이슈로 흘린다.
 
-어디로 머지할지는 사용자가 정해 직접 실행한다. 보통 기본 브랜치로 머지하고 이 머지가 곧 자동 배포로 이어지므로, 스킬은 특별한 지시가 없는 한 직접 누르지 않는다. 머지 뒤 `sprint-<id>` 브랜치와 통합 worktree, 남은 이슈 worktree를 정리한다.
+어디로 머지할지는 사용자가 정해 직접 실행한다. 보통 기본 브랜치로 머지하고 이 머지가 곧 자동 배포로 이어지므로, 스킬은 특별한 지시가 없는 한 직접 누르지 않는다. 머지 뒤 `sprint-<id>` 브랜치를 정리하고 메인 폴더를 기본 브랜치로 되돌리며, 남은 이슈 worktree도 정리한다.
 
 ---
 
@@ -144,7 +145,7 @@ issue-coder는 독립 이슈를 각자 worktree에서 다루므로 병렬로 돌
 - 이슈 close나 기본 브랜치 push는 하지 않는다. issue-coder는 PR까지만 하고, 이슈 close는 pr-merger가 조건부로(사람 확인 항목이 남으면 open 유지) 한다.
 - 막혔을 때 무한히 시도하지 않는다. CI red·모호한 충돌·불분명한 요구 같은 블로커는 스스로 풀려 하지 말고 사람에게 넘긴다.
 - 배포는 기본 브랜치 머지 시 GitHub Actions가 자동으로 한다. 스킬은 수동 배포를 하지 않고, 기본 브랜치로 올리는 최종 머지도 특별한 지시가 없는 한 사용자에게 맡긴다.
-- 매 단계마다 지금 어느 worktree의 어느 브랜치에서 무엇을 하는지 사용자에게 먼저 알린다. 통합 worktree와 여러 이슈 worktree, `sprint-<id>`·이슈·기본 브랜치를 오가므로 위치를 분명히 해야 사용자가 헷갈리지 않는다.
+- 매 단계마다 지금 어디(메인 폴더인지 어느 이슈 worktree인지)의 어느 브랜치에서 무엇을 하는지 사용자에게 먼저 알린다. 메인 폴더는 통합 검토용으로 `sprint-<id>`를 오가고 이슈 worktree는 각자 이슈 브랜치를 쓰므로, 위치를 분명히 해야 사용자가 헷갈리지 않는다.
 - 공통 함정도 지킨다. ch CLI 본문은 마크다운으로 쓰고 CRLF를 정제하며, spec 필드는 단수·복수를 함께 쓰고, `--json`이나 `specs get`이 윈도우에서 빈 출력이면 PowerShell `Out-File`로 우회한다(위임 대상이 이미 준수).
 
 ## 다른 컴포넌트와의 관계

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

@@ -12,7 +12,7 @@ description: |
   (4) 명세 영역별 완성형 TC 번들(퍼블리싱/프론트/백엔드 디센시아 운영 관점 포함)을 가져다 쓸 때,
   (5) 새 명세 작업 중 반복 패턴을 발견해 영역별 번들을 보강할 때,
   (6) Sprint 종료 전 spec별 SQA 통과 여부를 점검할 때.
-version: 1.8.1
+version: 1.8.2
 ---
 
 <!-- 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.8.1
+version: 1.8.2
 ---
 
 <!-- ch-version-gate -->