/cc-dev:go — 말만 하면 머지까지, 원스톱 파이프라인

A-0. 그린필드 풀스택 요청(빈 제품 저장소, 사이트+앱+Serverpod 생성)이면
     cc-product-auto:product-autopilot의 다섯 단계로 라우팅한다. 그 스킬의
     사이트 포함 4-surface/백엔드 검증이 완료되기 전에는 go의 Phase B/D를
     성공으로 보고하지 않는다. 기존 제품에 기능을 추가하는 경우만 아래로 계속한다.
A-1. 요청 파싱 — 자연어 요청 + 전달 옵션 분리. Figma URL/이미지는 breakdown 으로 전달할 목록에 보관.
A-2. 규모 사전 판단 (LLM-SEMANTIC) — breakdown Step 1.5 "Hierarchy Scale Inference" 와 같은 신호를
     가볍게 선판정: {no-epic | epic | project | initiative} + ambiguity {low | high}
     - 규모는 먼저 반사 판정(`cc-dev:jev-reflex` 세트 `scale`)에 묻는다: reflex 면 그 규모를 쓰고, deliberate 면
       Claude 가 규모를 정하면서 **ambiguity=high** 로 둔다(신뢰도가 낮다는 것 자체가 요청이 모호하다는 신호다).
       ⚠️ reflex 라고 ambiguity 를 low 로 두지 않는다 — 모호성 판단은 여전히 Claude 의 것이다(규모가 분명해도 목표가
       모호할 수 있다). unavailable(0·4 가 아닌 종료 코드)이면 이 판정 없이 예전처럼 판단한다.
A-3. 브레인스토밍 (조건부):
     - 조건: 규모 ≥ project 또는 ambiguity=high, 그리고 --no-brainstorm 미지정
     - 방법: cc-product:creative-intelligence 스킬 프레임(SCAMPER/역발상 중 택1)을 **비대화형**으로 적용
       → 산출: 목표 1문장, In/Out 범위, 후보 Epic 목록(이름+한 줄), 리스크 3개 이하
     - 결과는 Phase B 의 breakdown 입력(요구사항 텍스트)으로 합쳐진다. 파일로는 남기지 않는다
       (breakdown 이 .claude/docs/{feature}/ 문서화를 담당).
A-4. 소규모 경로: 규모 ≤ epic 이고 ambiguity=low 면 브레인스토밍 없이 pm-spec-agent 정제만 거친다
     (agents/dev/pm-spec-agent.md — 비대화형, 가정은 기록하고 진행).
A-5. 디자인 판단 선확정 (screen 계열 요청일 때만):
     - 조건: 요청이 화면·UI 를 포함하고(A-2 의 같은 요청에서 `involves_ui` 가 reflex true 거나, 애매하면
       Claude 판단), AC 를 쓰려면 결정이 필요한 디자인 질문이 남아 있을 때
       (빈 상태·에러 처리 방식·입력 포맷·상태 동작·문구 등 — 시안/스펙에 답이 없는 것)
     - 방법: cc-designer `design-decision` 프로토콜을 각 질문에 적용 (근거 사다리 R0→R5).
       R2(코드 선례 전수 조사)를 반드시 수행한다 — 저장소에 이미 답이 있는 질문을 새로 결정하지 않기 위함.
     - 산출: DDR 목록. **AC 에 흡수시킨다** — "가정(Assumption)" 이 아니라 근거가 붙은 결정으로 이슈 본문에 들어간다.
       (pm-spec-agent 의 assumptions 는 디자인 외 영역에만 남는다)
     - 에스컬레이션 4종에 해당하는 질문만 권고안 1개 + 근거와 함께 확인을 받는다.
     - 결정 0건도 정상 — 시안이 이미 답했다면(R1) DDR 을 만들지 않는다.

B-1. /cc-dev:zenhub:breakdown 프로토콜 실행:
     - 입력: Phase A 산출(정리된 요구사항 텍스트 + A-5 DDR 목록) + 전달 옵션(--images, --sprint, --labels 등)
       DDR 은 해당 Epic/Story 본문의 AC 로 내려간다 — 구현 단계가 같은 판단을 다시 하지 않게 한다
     - breakdown Step 1.5(스케일 추론) + Step 1.6(우선순위 표)의 "사용자 확인"은 /cc-dev:go 안에서는
       즉시 확정하지 않고 **Phase C 통합 게이트로 이월**한다 — 같은 내용을 두 번 묻지 않기 위함.
       (--auto 모드에서는 추론 결과를 그대로 채택)
B-2. 생성 결과 캡처 — issueMap:
     { initiative?: #, project?: #, epics: [{number, title, priority, children: [#…]}], standalone: [#…] }
     breakdown 출력 로그의 이슈 번호를 파싱하지 말고, 생성 시점에 반환된 id/number 를 직접 축적한다.
B-3. 상세 기획 HTML 은 **로컬 대기 파일**로 남는다 — breakdown 이 `.claude/docs/{scope}/issue-{n}.html` 을
     쓰지만 커밋할 브랜치가 아직 없다. Phase D 의 batch/run 이 각 이슈의 작업 브랜치를 만들 때 첫
     커밋으로 넣고 이슈 본문에 링크를 붙인다(`rules/artifact-publishing.md` §6). 그래서 Phase D 는
     Phase B 와 **같은 체크아웃**에서 시작한다 — 병렬 워크트리로는 batch 가 파일을 옮겨 준다.

C-1. 요약 출력: 계층 트리(이슈 번호·타입·포인트) + 우선순위 근거 표 + 실행 큐(순서) + 머지 정책
     + A-5 디자인 결정 요약 (DDR id · 결정문 · R번호 · 신뢰도). `신뢰도: low` 는 ⚠️ 로 표시한다.
     ⚠️ 이것은 승인 요청이 아니라 **열람**이다 — 결정별로 확인을 받지 않는다.
     (사용자가 이 요약을 보고 특정 결정을 뒤집고 싶으면 [게이트 유지하며 진행] 을 고르거나
      해당 이슈에서 별도로 지시하면 된다 — 새 질문을 만들지 않는 것이 이 Phase 의 계약이다)
C-2. AskUserQuestion (단일 질문):
     "이 계획대로 PR 머지까지 자동 진행할까요?"
     - [원스톱 진행] — 이후 모든 머지 pre-authorized (기본 권장)
     - [이슈만 남기고 중단] — --plan-only 와 동일하게 종료, 재개 방법 안내
     - [게이트 유지하며 진행] — --gated 와 동일: 실행은 하되 PR 머지마다 승인
C-3. --auto: 이 게이트를 생략하고 [원스톱 진행] 으로 간주. --plan-only: C-2 를 [이슈만 남기고 중단] 으로 강제.

D-1. 실행 큐 구성: epics를 priority(P0→P1→P2) → 생성 순으로 정렬, 그 뒤에 standalone 이슈(P0→P2).
     이 정렬은 **실행 순서**만 정한다 — 우선순위는 의존성이 아니다(D-2.5). 기질은 그대로
     **순차 큐**다(`rules/orchestration-graph.md` §4: 머지는 항상 직렬 · "순차/변경 없음" 이 기본값).
     여기서 팬아웃을 새로 만들지 않는다 — 병렬은 batch 안쪽에서만, 승인과 width cap 아래서 일어난다.
D-2. for epic of queue.epics:
       /cc-dev:batch {epic.number} --merge=pre-authorized
       - batch Phase 3(Epic PR 최종 승인)도 pre-authorized 로 자동 머지
       - Story BLOCKED('unstuck_exhausted') 발생 시: Epic 은 batch 의 Stall Budget 계약대로 계속 진행,
         Phase 3 완료성 Hard Gate 가 OPEN child 를 감지하면 그 Epic 은 [INCOMPLETE] 로 기록하고
         **다음 Epic 으로 계속** (전체 파이프라인 중단 금지 — 예외는 D-2.5 의존 후속과
         D-2.7 회로 차단 둘뿐이며, 그 둘도 "품질 게이트를 낮추는" 예외가 아니다)
     for issue of queue.standalone:
       /cc-dev:run {issue} --merge=pre-authorized
D-2.5. Dependency Invariant — **우선순위는 의존성이 아니다**:
     - [INCOMPLETE] 인 Epic 의 산출물에 의존하는 후속 Epic/이슈는 착수하지 않고
       `[SKIPPED-BLOCKED: blockedBy #N]` 으로 기록한다. 의존 축은 새로 정의하지 않는다 — breakdown
       Step 2.5(`rules/zenhub-conventions.md` → "Epic Dependency & Parallel Scheduling")가 생성
       시점에 `createBlockage` 로 남긴 실제 엣지가 있으면 그것을 우선 조회하고, 그 Epic 이 이 방식
       으로 만들어지지 않아 엣지가 없으면 우선순위 스코어링의 "Dependency (blocker)" 축을 대신 쓴다.
       그 축의 판단은 `cc-dev:jev-reflex` 세트 `depends-on`(`a` = [INCOMPLETE] 인 Epic, `b` = 착수 후보)에
       먼저 묻는다 — reflex true 면 의존, reflex false 면 의존 없음, deliberate·unavailable 이면 예전처럼
       Claude 가 판단하고 그래도 판정할 수 없으면 아래 규칙대로 판정 불가다.
     - 이유: 없는 base(머지되지 않은 상위 브랜치·생성되지 않은 Entity/API) 위에서 착수하면
       빈 diff PR · 잘못된 base · **거짓 완료**가 만들어지고, 그 뒤 게이트가 그걸 통과시킨다.
     - 의존 여부를 판정할 수 없으면 통과가 아니다 — 순차/안전 쪽으로 기울여 [SKIPPED-BLOCKED] 로
       남긴다(`rules/orchestration-graph.md` §3: undetermined 의 기본값은 fail).
     - 의존이 없는 형제는 영향받지 않는다 — 그대로 다음 항목으로 계속한다.
     - [SKIPPED-BLOCKED] 는 실패가 아니라 **미착수**다: 재개 명령은 blocker 를 해결한 뒤의
       `/cc-dev:batch {n}` / `/cc-dev:run {n}` 이며, D-2.7 의 연속 실패 카운트에 포함하지 않는다.
D-2.6. Occupancy Invariant — **미착수와 실패를 섞지 않는다**:
     - 하위 호출이 `[INCOMPLETE: issue_occupied]` 로 돌아오면(그 이슈를 다른 세션이 잡고 있다는
       뜻 — `commands/run.md` Step 0.4 · `rules/zenhub-conventions.md` → Work Claim Contract),
       그 항목을 `[SKIPPED-OCCUPIED: heldBy {owner}]` 로 확정하고 **다음 항목으로 계속**한다.
     - **[SKIPPED-BLOCKED] 와 구분한다** — 앞은 "선행 결과가 없다", 이쪽은 "지금 남이 하고 있다".
       사용자 행동이 다르다: 전자는 blocker 를 해결해야 하고, 후자는 **상대 세션이 끝나기를 기다리면
       된다**(또는 상대가 죽었으면 TTL 경과 후 자동 인수된다). 한 통에 담으면 고칠 것이 없는 항목을
       고치라고 보고하게 된다.
     - 보드도 대장도 **건드리지 않는다** — 남의 점유다. 우리 쪽 기록은 큐 상태와 Phase E 보고뿐이다.
     - D-2.7 의 연속 실패 카운트에 **포함하지 않는다**([SKIPPED-BLOCKED] 와 동일 — 실패가 아니라 미착수).
       ⛔ 이것을 실패로 세면, 큰 병렬 세션 하나가 도는 것만으로 회로 차단이 걸려 남은 큐가 통째로 멈춘다.
D-2.7. Circuit Breaker (contract:go.phaseD-execution-queue — 값은 아래 "Loop Contract" 에 있다):
     - causeKey: 하위 호출이 보고한 `[INCOMPLETE: <reason>]` 슬러그를 그대로 쓴다
       (`commands/batch.md` → "Unattended & Approval Contract": `issue_not_found` ·
       `children_blocked` · `merge_approval_unavailable` 등). ⛔ `issue_occupied` 는 예외다 —
       실패가 아니라 미착수이므로 causeKey 로 세지 않는다(D-2.6). 슬러그가 없는 실패는
       도구/환경 층위로 정규화한다(예: `gh_unauthenticated` · `stale_submodule` · `base_missing`).
       정규화는 반사 판정(`cc-dev:jev-reflex` 세트 `failure-cause`, 실패 출력 꼬리를 `failure` 로)에 먼저 묻는다:
       - **환경·도구 키**(`gh_unauthenticated` · `stale_submodule` · `base_missing` · `network` · `rate_limited`)는
         큐의 모든 항목이 똑같이 걸리는 원인이라 reflex 답을 그대로 causeKey 로 쓴다.
       - **증상 키**(`tests_failed` · `lint_failed` · `build_failed` · `dependency_resolution` · `merge_conflict`)는
         원인이 아니라 증상이다 — 서로 무관한 테스트 실패 두 건이 연달아 나도 같은 키가 된다. 그래서 직전 실패와
         `same-failure` 가 **reflex true** 일 때만 같은 causeKey 로 세고, 그 밖에는 항목별 고유 키(`tests_failed#{n}`)로 둔다.
       - deliberate 면 Claude 가 의미로 정한다 · `other` 이거나 그래도 정할 수 없으면 `unknown`(아래 규칙대로 다른
         unknown 과 묶지 않는다) · unavailable 이면 예전처럼 Claude 가 정한다.
     - 같은 causeKey 가 **연속 2건**(K=2) 나오면 남은 큐를 정지한다 — 큐 전체를 원인 하나에 대해
       재지불하지 않는다. 원인이 서로 다른 실패 2건은 breaker 를 켜지 않는다(D-2 규칙 유효).
     - 판정 불가는 `unknown` 이며 **다른 unknown 과 같은 원인으로 묶지 않는다** — 판정 불가를
       일치로 읽으면 breaker 가 무관한 실패 2건에 오작동한다.
     - 정지 시 출력(콘솔 + D-4.7 내구 표면): 공통 원인 1줄 · 그 원인으로 실패한 이슈 목록 ·
       아직 착수하지 않은 남은 항목 목록 · **재개 명령**(원인 해결 후 남은 항목의
       `/cc-dev:batch {n}` / `/cc-dev:run {n}` — 멱등이므로 `/cc-dev:go` 재실행이 아니다).
     - breaker 는 품질 게이트가 아니다 — 이미 통과한 머지를 되돌리지 않는다.
D-3. merge pre-authorization 의 의미 (run.md Step 12 / batch.md Phase 3 에서 해석):
     - AskUserQuestion 머지 승인 스킵 → 즉시 squash merge + Step 12.5 Close 검증 수행
     - 단, 다음은 pre-authorization 이 **덮지 못한다** (여전히 멈추거나 실패):
       ① 테스트/lint/리뷰 Critical 하드 게이트  ② seed-alignment MAJOR-DRIFT 확인
       ③ batch Phase 3 완료성 Hard Gate  ④ gh 미인증 등 Step 0 조기 중단
       ⑤ **Parent Closure Invariant** — run.md Step 9 gate 0(PR 생성 전) · Step 11.9(머지 직전) ·
         batch Phase 3-4.9. 열린 자식이 있으면 그 컨테이너는 머지되지 않는다
         (`rules/zenhub-conventions.md` → "Parent Closure Invariant"). 이 사유로 막힌 Epic 은
         D-2 의 [INCOMPLETE] 처리와 동일하게 기록하고 **다음 Epic 으로 계속**한다 — 전체 중단 금지
         (D-2.5 / D-2.7 예외는 동일하게 적용된다)
       ⑥ **병렬 스폰 계획 승인** — `commands/batch.md` → "2. 병렬 계획 승인"(Orca 워크트리 디스패치
         직전) 과 `commands/run.md` → "Agent Teams Parallel Mode" 사전 확인 4번(팀 구성 계획 승인).
         이 둘은 "머지해도 되는가" 가 아니라 "**세션/워크트리를 늘려도 되는가**" 라서 대상이 다르다
         (`rules/orchestration-graph.md` §4 기질 매트릭스: Agent Teams = 필수, Orca 디스패치 =
         항상 · `--merge=pre-authorized` 도 면제 못 함).
     - `--auto` 는 **승인 클릭만** 생략한다 — 스폰 승인 권한을 주지 않는다. `--auto` 는 하위 호출에
       `--unattended`(답할 사람 없음)를 전파하고, ⑥ 처럼 스폰 승인이 필요한 자리는 **승인 없이
       스폰하지 않고 순차로 강등**된다(`--no-parallel`). 하드 실패가 아니라 기능 차이 없는 강등이며
       소요 시간만 늘어난다(`skills/agent-teams/SKILL.md` → "Fallback Principle").
       무인(`--auto`) 환경에서 응답이 불가하면 그 자리를 순차로 내리는 것은 디자인 에스컬레이션
       4종의 무인 처리와 같은 원칙이다 — **어느 쪽도 무승인 진행을 허가로 바꾸지 않는다.**
       강등은 내구 기록을 남긴다 (batch 쪽 degrade 로그 + 그 레벨 PR body `## Dispatch`).
     - --gated 모드에서는 이 플래그를 전달하지 않는다 (기존 게이트 그대로)
D-4. 각 Epic/이슈 완료 시 1줄 진행 보고: "✅ Epic #N 머지·종료 (Story 3/3) | 다음: #M"
D-4.8. 머지된 항목의 워크트리 회수. 절차·안전 판정·순서·금지의 SoT 는
      `skills/orca-worktree-lifecycle/SKILL.md` — 여기서 재구현하지 않는다.
      - Epic: `/cc-dev:batch` 가 머지 큐 5번에서 자식 워크트리를 이미 회수한다.
        go 는 그 회수를 다시 하지 않고, batch 가 `leak` 으로 남긴 행만 1회 재시도한다.
      - 단독 이슈: `/cc-dev:run` 은 표시만 한다(자기 제거 금지). 그 이슈를 위해 go 가 연
        자식 워크트리가 있으면, `gh pr view` 로 MERGED 를 확인한 직후 go 가 회수한다.
      - ⛔ 지금 이 go 세션이 돌고 있는 워크트리는 여기서 지우지 않는다. Phase E 보고를
        내구 표면에 적은 뒤 E-5 에서만 지운다.
      - `--keep-worktrees` 면 이 절은 no-op 이고, 미회수 목록을 로그에 남긴다.
      - 회수 실패는 경고 후 계속. 머지를 되돌리거나 큐를 멈추지 않는다.
D-4.5. 작업내역 HTML: 각 PR 생성 시 run.md **Step 9** 가 리뷰어용 작업내역을
     `.claude/docs/{scope}/pr-work-{issue}.html` 로 커밋·push 하고 그 경로와 링크를 **PR 본문에**
     넣은 채로 PR을 만든다 (댓글 아님 — 여기서 다시 구현하지 않는다). **Step 10.5** 는 CI 를 기다려
     판정할 뿐 문서를 고치지 않는다 — CI 결과의 정본은 PR 체크다.
     - merge pre-authorization 은 이 단계를 바꾸지 않는다 — 게이트가 아니다
     - 문서 커밋 실패는 비차단 (마크다운 폴백). **CI 통과 요구는 사전 승인이 덮지 못한다**
     - Phase E 집계를 위해 { issue, prNumber, workDocPath | fallback } 을 모은다
D-4.7. 내구 원장(ledger) — D-4 의 진행 1줄은 콘솔에만 두지 않는다. **새 상태 파일은 만들지 않고**
     (Resume Contract 유지) 이미 존재하는 표면에 항목이 확정되는 **즉시** 얹는다:
     - 머지된 항목: 그 PR body 에 `- #{n} MERGED` 1줄 추가 — Step 9 가 이미 만든 표면이므로 새 표면을
       만들지 않는다(D-4.5). 작업내역 HTML 은 고치지 않는다 — 고치려면 커밋이 필요하고, 머지 뒤라
       브랜치도 없다.
     - [INCOMPLETE] · [SKIPPED-BLOCKED] 항목: 해당 이슈 코멘트에 상태 + causeKey(또는 blockedBy #N)
       + 재개 명령. BLOCKED 표기는 `rules/zenhub-conventions.md` → "Blocked Issue Contract" 를 쓴다.
     - **보드(파이프라인)도 이 원장의 일부다** — 코멘트만 남기고 칸을 그대로 두면 보드는 계속
       "진행 중"이라고 말한다. 하위 호출이 `blockIssue()`/`reflectBoardState(_, "aborted")` 로
       이미 반영했어야 하므로, 여기서는 **다시 옮기지 않고 반영됐는지만 확인**한다(이중 이동 금지).
       미반영이면 그 사실을 Phase E 에 `보드 미반영` 으로 함께 싣는다.
     - [SKIPPED-OCCUPIED] 항목: ⛔ **이슈에 아무것도 쓰지 않는다** — 남의 작업 이슈에 우리 상태를
       남기면 상대 세션의 대장·코멘트와 섞인다. 큐 로그와 Phase E 보고에만 남긴다.
     - 이유: Phase E 는 이 기록의 **집계**이며 유일한 사본이 아니다. 큐 중간에 크래시가 나면
       콘솔만 있던 원장은 사라진다(`rules/orchestration-graph.md` §2 `log:` — 잔여 상태와
       탈락시킨 것의 내구 기록. 콘솔은 내구가 아니다).
D-5. 디자인 결정 전파: 구현 중 발생하는 판단은 run.md Step 7.1 이 처리한다 (여기서 다시 구현하지 않는다).
     - merge pre-authorization 은 Step 7.1 의 성격을 바꾸지 않는다 — 애초에 게이트가 아니다
     - 각 이슈의 DDR 은 PR body `## Design Decisions` + `.claude/docs/{scope}/design-decisions.md` 에 남고,
       Phase E 집계를 위해 { issue, ddrCount, lowConfidence[] } 만 모은다
     - 에스컬레이션 4종이 실행 중 발생하면 그 이슈만 확인 대기 — **다른 Epic 은 계속 진행한다**
       (INCOMPLETE 처리 원칙과 동일: 파이프라인 전체를 세우지 않는다. 예외는 D-2.7 회로 차단)

inv:      큐의 각 항목은 정확히 한 번만 착수된다 · 착수 시점에 그 항목의 base 브랜치가 실재한다
          · 착수 시점에 그 항목이 다른 세션에 점유돼 있지 않다 (D-2.6)
          항목은 {MERGED | INCOMPLETE | SKIPPED-BLOCKED | SKIPPED-OCCUPIED} 중 하나로 확정되기
          전까지 pending 이며 확정 즉시 D-4.7 내구 표면에 기록된다 (pending 으로 방치 금지.
          단 SKIPPED-OCCUPIED 의 표면은 큐 로그와 Phase E 뿐이다 — 남의 이슈에 쓰지 않는다)
prog:     remaining = 큐에 남은 항목 수, 항목 1건 확정마다 1 강한 감소
          no-prog: 같은 항목을 이 루프에서 재착수하지 않는다 — 재시도는 batch/run 의 stall ladder
          소관이며(`agents/sequential-workflow.md`), 이 루프는 결과를 받아 적기만 한다
term:     remaining == 0 (또는 D-2.7 breaker 정지)
budget:   큐 1회 순회 = 항목 수만큼 착수, 재순회 0회 / breaker: 동일 causeKey 연속 2건 (K=2 —
          SKIPPED-BLOCKED·SKIPPED-OCCUPIED 는 세지 않는다)
exhaust:  breaker 발동 → 큐 정지 + 공통 원인 1줄 + 실패·미착수 목록 + 재개 명령 (무음 계속 금지)
resume:   ZenHub 이슈 상태 + 열린/머지된 PR 재조회로 위치 판정 — go.md 는 자체 상태 파일이 없다.
          `/cc-dev:batch {n}` / `/cc-dev:run {n}` 은 멱등(Closed 항목 건너뜀)
log:      항목당 1줄(D-4) + 같은 줄을 D-4.7 내구 표면에 즉시 기록. 정지 시 남은 항목을 이름으로
          남긴다 — 조용한 절단 금지 (`rules/orchestration-graph.md` §5)

E-1. 결과 표: 생성 이슈 수 / 머지 PR 목록 / 닫힌 이슈 / BLOCKED·INCOMPLETE 항목(+재개 명령)
     + 작업내역 HTML 경로 목록 (PR 별 1건 — `.claude/docs/{scope}/pr-work-{issue}.html`). 머지된 PR 의
       문서는 base 브랜치의 같은 경로에 있다 — 브랜치 링크는 머지 후 브랜치가 지워지면 404 이므로
       경로로 적는다(`rules/artifact-publishing.md` §7). 커밋이 폴백된 PR 은 `— 마크다운 폴백` 으로 표기한다.
     + 디자인 결정 집계: 총 DDR 수, `신뢰도: low` 항목(⚠️ 재검토 — 이슈 번호와 함께),
       에스컬레이션으로 사람에게 올라간 건수. 결정 0건이면 이 줄은 생략한다.
     이 표는 D-4.7 내구 원장의 **집계**다 — 새로 계산하지 않고 그 기록을 읽어 모은다.
E-1.5. INCOMPLETE / SKIPPED-BLOCKED 는 **causeKey 별로 묶어** 보고한다 — 평평한 목록 금지
     (원인 하나가 N줄로 흩어지면 사람이 N개 문제로 읽는다). 그룹당:
     - causeKey 1줄 + 그 원인에 걸린 이슈 번호 목록 + 그룹 공통 재개 명령 1개
     - D-2.7 breaker 로 정지했다면 그 그룹을 맨 위에 `⛔ 회로 차단 (동일 원인 연속 2건)` 으로 표시하고,
       **착수하지 않은 남은 항목**을 별도 줄로 함께 보여준다 (실패와 미착수를 섞지 않는다)
     - SKIPPED-BLOCKED 는 `blockedBy #N` 을 함께 적는다 — 원인이 자기 자신이 아니다
     - causeKey=`unknown` 은 묶지 않고 항목별로 나열한다 (D-2.7 과 같은 이유)
     - **SKIPPED-OCCUPIED 는 실패 그룹에 넣지 않는다** — 별도 줄로, **점유자별**로 묶는다
       (`🔒 다른 세션 진행 중 — {owner}: #A #B`). causeKey 그룹이 아닌 이유는 원인이 결함이 아니라
       **동시 실행**이기 때문이다. 재개 안내는 "상대 세션 종료 후 `/cc-dev:batch {n}`" 한 줄이며,
       고칠 것이 없다는 사실을 명시한다.
     - 보드 반영이 확인되지 않은 항목(D-4.7)은 `보드 미반영` 을 그 항목 줄에 덧붙인다 —
       조용히 넘기면 다음 실행이 같은 이슈를 In Progress 로 보고 점유 오판을 반복한다.
E-2. BLOCKED 항목이 있으면: "재개하려면 /cc-dev:batch {epic}" (batch Phase 0 멱등 resume 계약)
E-3. --wrap 지정 시 /cc-dev:session:wrap 실행
E-4. Initiative/Project 가 전부 닫혔는지는 batch/run 의 checkAndCloseParent 재귀가 이미 보장 —
      여기서 중복 확인하지 않는다 (미완 Epic 이 있으면 당연히 열려 있는 게 정상)
E-5. 세션 워크트리 회수 — 최상위 `/cc-dev:go` 만. SoT 는
      `skills/orca-worktree-lifecycle/SKILL.md` §1 "최상위 go".
      - 이 실행이 부모 batch 에 디스패치된 워커면 `markWorktreeReclaimable` 만 하고
        제거하지 않는다. 부모가 회수한다.
      - 최상위면 E-1 보고를 PR body 또는 이슈 코멘트에 **먼저** 적는다. 콘솔만 남기고
        워크트리를 지우면 보고가 사라진다.
      - 그 다음 §4 순서로 **이 세션의 워크트리**를 회수한다. R3(자기 제거 금지)는
        이 한 자리에서만 해제된다 — 머지 이후 단계와 Phase E 내구 기록이 끝났고,
        이 체크아웃을 기다리는 부모 머지 큐가 없다. R1·R2·R4 는 그대로다.
        하나라도 미확정이면 보존한다.
      - Orca 없음 · 워크트리 밖 · `--keep-worktrees` 는 조용한 no-op.
      - 실패는 경고 1줄. 사이클을 실패로 만들지 않는다.