A-1. 요청 파싱 — 자연어 요청 + 전달 옵션 분리. Figma URL/이미지는 breakdown 으로 전달할 목록에 보관.
A-2. 규모 사전 판단 (LLM-SEMANTIC) — breakdown Step 1.5  " Hierarchy Scale Inference "   와 같은 신호를
     가볍게 선판정: {no-epic | epic | project | initiative} + ambiguity {low | high}
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 를 포함하고, 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 를 직접 축적한다.

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) "   축을 대신 쓴다.
     - 이유: 없는 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`).
     - 같은 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/DCM/리뷰 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.5. 작업내역 아티팩트: 각 PR 생성 시 run.md **Step 9** 가 리뷰어용 작업내역을 먼저 발행해
     그 링크를 **PR 본문에** 심은 채로 PR을 만든다 (댓글 아님 — 여기서 다시 구현하지 않는다).
     이후 **Step 10.5** 가 CI 대기와 병행해 같은 URL 을 CI 결과로 갱신한다.
     - merge pre-authorization 은 이 단계를 바꾸지 않는다 — 게이트가 아니다
     - 발행 실패·도구 부재는 비차단 (마크다운 폴백). **CI 통과 요구는 사전 승인이 덮지 못한다**
     - Phase E 집계를 위해 { issue, prNumber, artifactUrl | fallback } 을 모은다
D-4.7. 내구 원장(ledger) — D-4 의 진행 1줄은 콘솔에만 두지 않는다. **새 상태 파일은 만들지 않고**
     (Resume Contract 유지) 이미 존재하는 표면에 항목이 확정되는 **즉시** 얹는다:
     - 머지된 항목: 그 PR 의 작업내역 아티팩트 / PR body 에 `- #{n} MERGED` 1줄 추가 — Step 10.5 가
       이미 그 표면을 소유하므로 새 표면을 만들지 않는다(D-4.5).
     - [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 항목(+재개 명령)
     + 작업내역 아티팩트 링크 목록 (PR 별 1건). 발행이 폴백된 PR 은 `— 마크다운 폴백` 으로 표기한다.
       링크는 **발행 시점 비공개**이므로 공유 안내 문구를 한 번만 덧붙인다 (`rules/artifact-publishing.md` §2)
     + 디자인 결정 집계: 총 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 이 있으면 당연히 열려 있는 게 정상)