/cc-dev:batch {issue_number} [--merge=pre-authorized] [--no-parallel]
                             [--max-parallel N] [--worker-timeout {h}] [--unattended]
                             [--keep-worktrees]

development
 └── initiative/{n}-{slug}         ← 부모 없음(구조상 최상위). base: development
      └── project/{n}-{slug}       ← Initiative 부모가 있으면 그 브랜치, 없으면 development
           └── epic/{n}-{slug}     ← Project 부모가 있으면 그 브랜치, 없으면 development
                ├── story/{n}-{slug}      ← base: epic/{n}-{slug}
                │    ├── task/{n}-{slug}  ← base: story/{n}-{slug}
                │    └── task/{n}-{slug}
                └── story/{n}-{slug}

1. Skill(orca-cli) 호출 — discovery stub이므로 항상 최신 가이드를 로드한다. 캐시된
   서브커맨드를 추측해서 쓰지 않는다(버전마다 바뀐다).
2. Skill(orchestration) 호출 — 마찬가지로 최신 가이드를 로드한다.
3. `ORCA status --json` 로 앱 실행 확인. 미실행이면 `ORCA open --json` 시도.
4. 그래도 실패하거나 `--no-parallel`이 지정됐으면: 병렬 디스패치를 끄고 이 배치 실행 전체를
   순차 처리로 전환한다 — `skills/agent-teams/SKILL.md`의 Fallback Principle과 동일 원칙
   (기능 차이 없음, 소요 시간만 달라짐). 1회 경고 로그만 남기고 하드 실패하지 않는다.
5. **고아 스윕 1회**(`B0.r`) — 이전 실행이 죽거나 `/clear` 로 끊겨 **회수하지 못한 워크트리**를
   따라잡는다(`--keep-worktrees` 면 생략). 실행 시점은 **대상 이슈가 확정된 Phase 0.3 직후**다 —
   대장이 그 컨테이너 이슈의 마커 코멘트에 있으므로 그 전에는 읽을 수 없다. 대상은 시도 대장에
   `worktree` 가 적혔고 아직 `reclaimed` 가 아닌 행 ∩ 실재하는 워크트리 목록이며, 후보마다
   회수 안전 판정 5종을 그대로 적용한다. 절차·판정·금지의 SoT 는
   [orca-worktree-lifecycle](../skills/orca-worktree-lifecycle/SKILL.md) 다 — 여기서 재서술하지
   않는다. 스윕 실패는 **경고 후 계속**이며 배치를 막지 않는다.
     🧹 sweep: 후보 {n}건 · 회수 {k}건 · 보존 {m}건({사유 요약})
   ⛔ 대장에 없는 워크트리는 **남의 것**이다 — 보고만 하고 손대지 않는다.

확인 내용: 병렬 후보 목록(형제 이슈 번호·제목), 각자 배정될 워크트리/브랜치,
           순차로 남긴 형제와 그 이유,
           **동시 실행 수 N = min(병렬 후보 수, --max-parallel 기본 3)**,
           **1차로 동시에 열리는 형제**와 **대기줄에 남는 형제**(번호·제목) 목록,
           워커 1개당 wall-clock 예산(--worker-timeout 기본 4h)과 초과 시 동작

슬롯 루프 (contract:L-B2a — 필드는 아래  " Loop Contracts "   에 있다):
  1. 승인된 병렬 후보를 의존성 없는 것부터 순서대로 늘어놓고, 앞에서 width 개만
     **1차 착수**한다. 남은 형제는 **대기줄(wait queue)** 에 넣는다.
  2. cap 때문에 미룬 형제는 전부 **deferred 로그**에 이름으로 남긴다 — 조용한 절단 금지:
       ⏸️ deferred(cap=3): #{n} {title} · #{n} {title} … (슬롯 회수 시 착수)
  3. 워커 하나가 끝나(worker_done) 슬롯이 비면 대기줄 맨 앞을 착수하고, 그 전이를 로그에 남긴다.
  4. 대기줄이 비고 in-flight 가 0 이면 루프 종료.

착수되는 각 child 마다:
  - orca-cli 가이드가 제공하는 명령으로 `myBranch`(이 레벨 자신의 브랜치) 기준
    워크트리를 만든다 (tier: standard — `skills/agent-teams/SKILL.md` Effort Routing
    Convention. 미설정은 기본값이 아니라 width 배 승수다).
  - ⭐ **스폰 응답의 워크트리 id 를 즉시 시도 대장에 적는다** — ` < repoId > :: < worktreePath > `
    **두 조각이 붙은 한 값**을 통째로 적는다(repo id 만 잘라 적으면 나중에 그 워크트리를
    지목하지 못한다). 이 기록이 아래  " 4.5 회수 "   와 Phase 0 스윕의 **유일한 후보 명단**이고,
    워크트리 **경로**에서 파생된 자원(워크트리별 DB·포트 블록·컨테이너)의 주인을 되짚는
    유일한 근거다 — 체크아웃을 지운 뒤에는 되짚을 방법이 없다.
    (대장 위치·칸 정의는 아래  " 5.1 시도 대장 " , 회수 절차의 SoT 는
    [orca-worktree-lifecycle](../skills/orca-worktree-lifecycle/SKILL.md))
  - 그 워크트리 안에서 child를 처리한다. `{inherited}` = 이 실행이 받은 `--merge=pre-authorized`·
    `--unattended` 를 **문자 그대로** 옮겨 붙인 것이다(새로 판단하지 않는다):
      children(child)가 있으면 → /cc-dev:batch {child.number} {inherited} (재귀)
      없으면(leaf)             → /cc-dev:run {child.number} {inherited}
    resolveBaseBranch()(commands/run.md)가 이미 만들어진 `myBranch`를 child의 부모
    브랜치로 자동 인식하므로, 별도 --base 지정이 필요 없다.
    ⛔ `{inherited}` 를 빠뜨리면 그 child 워크트리 안에서 `/cc-dev:run` 의  " Unattended  &   Approval
       Contract " (`commands/run.md`)가 답할 사람 없는 `AskUserQuestion` 을 만나 조용히 멈춘다 —
       그 워크트리에는 콘솔을 볼 사람이 없다.
  - orchestration 가이드의 task 디스패치 / worker_done 대기 패턴으로 완료를 감시한다.
    ⏱️ **워커당 wall-clock 예산 = --worker-timeout(기본 4h)**. 숫자를 고르는 방식의 SoT 는
       `skills/job-timeout-budget/SKILL.md`(실측 최대 × 2, 표본 없으면 형제 잡에 정합) —
       표본이 없어 가장 무거운 형제 잡(배포 150분)에 정합시켜 4h 로 둔다.
    ⏱️ **on-timeout(선언된 행동, 침묵 금지)**: 그 child 를 `BLOCKED( ' worker_timeout ' )` 로
       표시하고(`blockIssue(child,  ' worker_timeout ' )` — holding 이동 + 사유 코멘트 + **점유 해제**.
       ⚠️ 해제를 빠뜨리면 죽은 워커의 점유가 TTL(4h)까지 그 child 를 잠근다) 워크트리
       세션을 종료한 뒤 **나머지 형제는 계속**한다 — stall ladder Rung 3 와 동일한 의미
       (`agents/sequential-workflow.md` →  " Rung 3 — BLOCKED + CONTINUE " ). 시도 기록은
       아래  " 5. Stall Ladder "   의 시도 대장에 남는다.
       ⛔ 이 행동이 없으면 worker_done 을 끝내 못 보내는 워커 하나가 Phase 2-d 를 영구히
          붙잡는다(완료성 게이트는 in-flight 형제가 있는 동안 평가되지 않는다).
순차로 남긴 child는 기존과 동일하게 하나씩 처리한다.

머지 큐 루프 (contract:L-B2b — 필드는 아래  " Loop Contracts "   에 있다). 큐 항목 하나마다:
  1. child 를 **현재 `myBranch` 위로 갱신**한다 — 앞 항목이 이미 squash 머지돼 base 가
     달라져 있다. (rebase 또는 `myBranch` 를 child 브랜치로 머지, 팀 관례에 맞게 택1)
  2. 갱신된 head 에서 **`runPrePushGate()` 재실행**(`run.md` Step 8.5 — 그 문서가 SoT,
     여기서 복제하지 않는다) 또는 **갱신된 head 에 대한 CI green 확인**.
     ⛔ 이 단계가 없으면 child #2 의 게이트는 **child #1 의 squash 이전 `myBranch`** 를
        기준으로 통과한 판정이 되고, 그 상태로 머지된다. `--merge=pre-authorized` 도
        이 재검사를 덮지 못한다(사전 승인은  " 승인 클릭 "   하나만 생략한다).
  3. 갱신 중 충돌이 나면 conflict rung 을 적용한다:
       rung C1 — `skills/merge-conflict-resolution/SKILL.md` 절차로 해소 후 2번으로 복귀
                 (해소 전략·파일 유형별 규칙은 그 문서가 SoT — 여기서 재서술하지 않는다)
       rung C2 — 같은 파일에서 의미상 동일 충돌이 반복되면 그 child 를 큐에서 빼고
                 `blockIssue(child,  ' merge_conflict ' )` 로 표시(보드 + 점유 해제), **나머지 큐는 계속** 진행
  4. squash merge → `myBranch` 를 `git pull --ff-only` 로 최신화 → 다음 항목.
  5. **머지된 child 의 워크트리를 회수한다** — 아래  " 4.5 머지된 형제의 워크트리 회수 " .
     ⛔ 이 자리이지 worker_done 자리가 아니다: 1~3번이 그 체크아웃을 아직 쓴다.
     회수 실패는 **경고 후 계속**이며 머지를 되돌리거나 큐를 멈추지 않는다.
  6. **큐 상태 전이는 전부 로그로 남긴다**(내구 — 조용한 재정렬 금지):
       🔀 queue: #{n} enqueued(arrival #k) / rebased onto {myBranch}@{sha} /
          re-gate pass|fail / merged({sha}) / dequeued(BLOCKED:{reason})
       🧹 reclaim: #{n} worktree={id} (merged {sha}) → removed | kept({사유}) | leak({사유})

- 위치: 이 컨테이너 이슈의 마커 코멘트 ` < !-- cc-dev:batch-attempt-ledger -- > `
  (upsert 방식은 `skills/pr-work-artifact/SKILL.md` 의 마커 코멘트 프로토콜 재사용 — 복제 금지)
- 항목: | child | attempts | last_cause(의미 요약) | worktree | state |
    - `worktree`: 스폰 응답의 id **전체**(` < repoId > :: < worktreePath > `). 순차 처리면 `-`.
      워크트리 회수와 고아 스윕의 **유일한 후보 명단**이다(위 4.5 · Phase 0-5).
    - `state`: open / blocked({reason}) / waived / closed / **reclaimed** / **leak({사유})**
- 예산: child 하나당 **누적 3회**(= batch 재실행을 가로질러 합산). 3회 소진 시 그 child 는
  더 재시도하지 않고 `blocked` 로 고정되며, 다음 재실행도 그 child 를 다시 돌리지 않는다.
- 로그: 매 시도마다 한 줄 — `🔁 #{child} attempt {k}/3 (누적) cause={요약}`
- ⛔ **회수용 대장을 따로 만들지 않는다** — 두 대장이 어긋나는 날 어느 쪽이 사실인지 아무도
  모른다. 워크트리 상태는 이 대장의 같은 행에 두 칸으로 붙인다.

# trunk 는 저장소 기본 브랜치가 아니라 **이 레벨의 myBranch** 다 — -b 를 반드시 명시한다.
# ⚠️ 인자 없이 `gh stack init` 을 실행하면 대화형이다. 무인 실행에서는 브랜치를 함께 준다
#    (인자 순서에 대한 명시는 문서에 없다 — bottom→top 이 명시된 것은 `gh stack link` 뿐이다).
gh stack init -b  " ${myBranch} "   task/101-entity task/102-data task/103-presentation

# push + PR 생성/갱신. --auto 는 에디터를 생략하며 **draft** 로 만든다.
# 바로 리뷰를 받아야 하면 --open 을 함께 준다.
gh stack submit --auto

# 상태는 항상 기계 판독으로 읽는다 (pager 를 통과하는 사람용 출력을 파싱하지 않는다).
gh stack view --json

# base 가 움직였을 때(앞 층 머지·trunk 갱신) — 위  " 머지 큐 루프 1번 "   의 대체물.
gh stack sync --prune

# 머지 — auto-merge 미지원이므로 `gh pr merge --auto` 를 쓰지 않는다. -y 로 확인 프롬프트 생략.
gh stack merge  " ${bottom_pr} "   --squash -y

# ⚠️ 전제: 아래 두 Story 는 #105 가 #101 의 산출물(목록 화면·라우트)을 전제하는
#    **순차 의존** 관계임이 위 판별 표에서 확인된 경우다. 독립 형제라면 link 하지 않는다.
# 인자는 반드시 bottom → top 순서. 브랜치는 자동 push 되고, 기존 PR 은 재사용되며,
# base 가 잘못 잡혀 있으면 교정된다.
gh stack link --base  " ${myBranch} "   story/101-author-list story/105-author-detail
gh stack view --json

B0     ACT   Phase 0 tooling preflight (GD-02)
B0.g   GATE  gh 인증 (머지 전에 실패)             verdict:gh auth status exit  undet:fail  fail:HALT
B0.3   ACT   Phase 0.3 레벨 판별 (getIssueTypes)
B0.3g  GATE  대상 이슈 존재                       verdict:searchLatestIssues 히트  undet:fail  fail:HALT
B0.r   ACT   고아 워크트리 스윕 (미회수 따라잡기)   writes:orca:worktree,ledger  skip:--keep-worktrees||!orca
B0.5p  ASK   Phase 0.5 pre-batch seed 정렬        options:계속|중단  unattended:계속+기록
B1     ACT   Phase 1 leaf/container 분기 판정
B1.g   GATE  listChildren(self).known             verdict:known  undet:fail  fail:HALT
B1a    ASK   children 0개가 맞나 (컨테이너 타입만)  options:leaf 진행|중단  unattended:정지
B1b    ACT   /cc-dev:run {n} 위임 (검증된 leaf)     tier:standard   # 이 실행은 여기서 끝난다
B1.5   ACT   Phase 1.5 자기 브랜치 + In Progress cascade  writes:git:branch,zenhub:pipeline,claim:acquire
B1.5b  GATE  브랜치 확보가 원격 권위 조회였나          verdict:git fetch --prune  & &   ls-remote  " {prefix}/{n}-* "   로 조회 후 확보  undet:fail  fail:HALT
B2ap   ASK   병렬 스폰 계획 승인 (최상위 1회, 전파)  options:승인|순차로  unattended:~~ > 순차
B2a.c  GATE  child 점유 확인 (디스패치 직전)         verdict:claimStatus(child)!== " other-live "    undet:브랜치/PR 활동으로 강등  fail:B2a.q
B2a    FORK  Phase 2-a 독립 형제 병렬 착수          isolate:worktree  width:3  tier:standard
B2a.q  LOOP  슬롯 회수 + 대기큐 드레인 (deferred 로그) contract:L-B2a
B2a.g  GATE  listChildren(child).known             verdict:known  undet:fail  fail:B2c
B2a.1  ACT   child 처리 (batch 재귀 | run)          own:child-worktree  tier:standard
B2w    WAIT  worker_done 대기                      timeout:4h  on-timeout:BLOCKED( ' worker_timeout ' )+형제 계속
B2b    JOIN  머지 꼬리                             mode:stream  serialize:1  order:worker_done-arrival  because:myBranch 충돌 방지
B2b.q  LOOP  머지 큐 (갱신→재게이트→머지)            contract:L-B2b
B2b.g  GATE  갱신된 head 재검증                    verdict:runPrePushGate() exit==0 || ci.bucket=== " pass "    undet:fail  fail:B2b.q
B2b.r  ACT   머지된 child 워크트리 회수 (큐 5번)    writes:orca:worktree,ledger  skip:--keep-worktrees||!orca  because:슬롯·디스크는 머지 시점에 반납된다
B2c    LOOP  stall ladder + 시도 대장 (child 단위)   contract:L-B2c
B2c.w  ASK   descope / waive 결정                  options:descope|waive|차단 유지  unattended:차단 유지
B2d    GATE  Phase 2-d 완료성 Hard Gate ①          mode:barrier  because:cross-item completeness, fresh re-query, no cache
                                                  verdict:mayClose(openChildrenStatus) || allOpenWaived(ledger)  undet:fail  fail:HALT
B3     ACT   Phase 3 컨테이너 최종 PR + Review/QA   writes:github:pr,zenhub:pipeline,claim:release(종료 시)  own:lead
B3.5   ACT   CI 대기 ∥ 작업내역 (run.md Step 10.5)   extern:true
B3.9   GATE  완료성 Hard Gate ② (머지 직전)         verdict:mayClose(openChildrenStatus) || allOpenWaived(ledger)  undet:fail  fail:HALT
B3.9b  GATE  PR base retarget (branch-hierarchy R7)  verdict:baseRefName==4.95에서 재해석한 myBaseBranch(조회만)  & &   merge-base --is-ancestor origin/{base} origin/{PR head}  & &   rev-list --count origin/{base}..origin/{PR head} > 0  undet:fail  fail:HALT  skip:스택모드
B3.12  ASK   최종 머지 승인                         options:승인|중단  pre:--merge=pre-authorized  unattended:pre 없으면 정지
B3.6   ACT   squash merge + close 검증 + 폴백       writes:github:issue,zenhub:state
B3.66  GATE  완료성 ③ (종료 직후 · 복구 전용)        verdict:openChildrenStatus!== " open "    undet:warn(머지 후 — 막을 대상이 이미 없다)  fail:B3.66r
B3.66r LOOP  재오픈 복구 + 남은 자식 재개            contract:L-B3.66r
B3.67  ACT   부모 완료 신호 (자동 병합 아님)         writes:github:comment
B3.8   ACT   post-merge base 최신화 + submodule sync writes:git:base
B3.r   ACT   이 레벨 워크트리 반납 표시 (자기 제거 금지) writes:orca:worktree-card  because:회수는 만든 쪽(부모)의 몫이다
B0.5q  ASK   Phase 0.5 post-batch seed 정렬         options:계속|보류  unattended:계속+기록

B0 -- >   B0.g -- >   B0.3 -- >   B0.3g -- >   B0.r -- >   B0.5p -- >   B1 -- >   B1.g
B1.g -- >   B1a -- >   B1b                 # children===0 (검증된 leaf) 경로 — 배타적, 여기서 종료
B1.g -- >   B1.5                        # children > 0 (container) 경로 — 배타적
B1.5 -- >   B1.5b -- >   B2ap -- >   B2a.c -- >   B2a -- >   B2a.q -- >   B2a.g -- >   B2a.1 -- >   B2w -- >   B2b -- >   B2b.q -- >   B2b.g
B2b.g -- >   B2b.r -- >   B2d -- >   B3 -- >   B3.5 -- >   B3.9 -- >   B3.9b -- >   B3.12 -- >   B3.6 -- >   B3.66 -- >   B3.67 -- >   B3.8 -- >   B3.r -- >   B0.5q
B2c  -- >   B2c.w -- >   B2d               # 영구 BLOCKED child 가 남았을 때만 지나는 자리
B0.5p ~~ >   B1     on:!LOCKED seed                   record:log( " seed 없음/DRAFT → skip " )   # 구조적 해당 없음
B0.5p ~~ >   B1     on:--unattended  & &   MAJOR-DRIFT    record:PR body(## Seed Alignment)+이슈 코멘트
B1a   ~~ >   HALT   on:--unattended                   record:blockIssue( ' childless_container_unconfirmed ' )(board+claim:release)+이슈 코멘트
B2ap  ~~ >   B2a.q  on:--unattended||--no-parallel     record:PR body(## Dispatch)+degrade 로그   # width:1 강등, 형제 처리는 그대로
B2w   ~~ >   B2b    on:worker_timeout                 record:blockIssue( ' worker_timeout ' )(board+claim:release)+시도 대장
B2a.c ~~ >   B2a.q  on:claim==other-live             record:SKIPPED-OCCUPIED(큐에서 제외, 보드·대장 손대지 않음)+형제 계속
B2c   ~~ >   B2b    on:rung3||attempts > =3             record:blockIssue( ' unstuck_exhausted ' )(board+claim:release)+시도 대장   # 형제는 계속
B2c.w ~~ >   B2d    on:--unattended||waive 거부        record:시도 대장(state=blocked)+child 코멘트+[INCOMPLETE]
B3.12 ~~ >   HALT   on:--unattended  & &   !--merge=pre-authorized  record:PR 유지+[INCOMPLETE: merge_approval_unavailable]
B0.r  ~~ >   B0.5p  on:--keep-worktrees||!orca       record:log(미회수 후보 목록 — 조용한 누적 금지)
B2b.r ~~ >   B2d    on:--keep-worktrees||!orca       record:log(미회수 child 목록)+대장 worktree 행 유지
B2b.r ~~ >   B2d    on:reclaim.fail||!safe5          record:대장 state=leak({사유}) → 다음 배치 B0.r 이 재시도   # 머지는 되돌리지 않는다
B3.r  ~~ >   B0.5q  on:!orca||워크트리 밖 실행         record:log(no-op — 부모가 만든 워크트리가 없다)
B2a.1 == >   B2c    on:child.fail            bound:3(누적, 시도 대장)  invalidates:B2a.1
B2a.g == >   B2c    on:known===false          bound:1  invalidates:B2a.1
B2b.g == >   B2b.q  on:reGate.fail||conflict  bound:2  invalidates:B2b.g
B3.66 == >   B3.66r on:status=== " open "          bound:1  invalidates:B2d,B3.9

L-B2a  디스패치 슬롯 + 대기큐  (위  " 3. 디스패치 " )
inv:      inFlight ≤ width  ·  대기큐 ∪ inFlight ∪ 완료 = 승인된 병렬 후보 전체
          (합집합이 깨지면 형제가 조용히 사라진 것이다 — 즉시 실패)
prog:     pending = 대기큐 길이, 슬롯 회수마다 강한 감소
          no-prog: 슬롯이 비었는데 pending 이 안 줄면 그 후보를 순차 경로로 넘기고 Rung 2 로 올린다
term:     pending === 0  & &   inFlight === 0
budget:   width = min(후보 수, --max-parallel 기본 3) 동시 · 후보당 착수 시도 2회
          · 워커당 wall-clock 4h(--worker-timeout)
exhaust:  착수 2회 실패 → 순차 경로로 강등 → 그래도 실패면 BLOCKED( ' dispatch_failed ' ) + 형제 계속
resume:   `ORCA status --json` 의 실재 워크트리 + 시도 대장 + 각 child 의 GitHub state 로 위치 판정
          (이미 Closed 인 child 는 착수하지 않는다 — 멱등)
          ⚠️ **이미 머지·Closed 인 child 의 잔존 워크트리는 재개 대상이 아니라 회수 대상이다**
          (대장 state 가 `reclaimed` 가 아닌 행) — B0.r 스윕이 처리한다. 거기에 워커를 다시
          띄우면 닫힌 이슈를 두 번 돌린다
log:       " slot 2/3: #123 착수 (pending 4→3) "   · ⏸️ deferred(cap=3) 는 **이슈 번호·제목으로** 남긴다
          · 스폰 직후 `worktree={id}` 를 대장에 적은 사실을 한 줄로 (회수의 유일한 명단)

L-B2b  머지 큐  (위  " 4. 머지는 항상 직렬화 " )
inv:      worker_done 이 도착한 child 만 큐에 있고 항상 1개만 머지 중(serialize:1)
          · 머지 직전 head 는 현재 myBranch 를 조상으로 갖는다
          · **회수는 머지된 항목에만 일어난다** — dequeue(BLOCKED) 된 항목의 워크트리는 보존
prog:     queued = 큐 길이, 항목 처리(머지 또는 dequeue)마다 강한 감소
          no-prog: 같은 child 가 같은 이유로 재게이트 2회 실패 → rung C2(dequeue + BLOCKED)
term:     queued === 0
budget:   항목당 갱신+재게이트 2회 · 충돌 rung C1 2회 · 큐 길이는 형제 수(증가 없음)
exhaust:  BLOCKED( ' merge_conflict ' ) 로 dequeue + 나머지 큐 계속 (이미 머지된 것은 되돌리지 않는다)
resume:   `gh pr list --base {myBranch} --state all` + `git log {myBranch}` 재실측으로 어디까지
          머지됐는지 판정 (큐 메모리는 /clear 를 못 넘는다). 머지된 child 재머지 금지 — 멱등
          · 머지는 됐는데 대장 state 가 `reclaimed` 가 아닌 행 = **회수 미완** → B0.r 스윕이 잇는다
            (이미 사라진 워크트리 id 는  " 없음 " 이 성공이다 — 대장만 맞춘다)
log:      🔀 queue 전이 한 줄씩(enqueued/rebased/re-gate/merged/dequeued) + 잔여 큐 길이
          🧹 reclaim 전이 한 줄씩(removed/kept({사유})/leak({사유})) — 조용한 정리·조용한 누수 금지

L-B2c  child stall ladder + 시도 대장  (위  " 5. Stall Ladder " )
inv:      한 child 의 실패가 형제 처리를 멈추지 않는다 · 보드 상태가 실제 상태와 일치한다
prog:     attempts(child) 단조 증가 **+ last_cause 가 의미상 달라져야 한다**
          no-prog: 의미상 동일 실패면 같은 예산을 더 쓰지 않고 Rung 2 로 올린다
term:     child 가 Closed · 또는 누적 attempts 3 소진 → `blocked` 고정
budget:   inner: Rung 1 재시도 2회 / Rung 2 리프레임 1회 · outer: child 당 **누적 3회**
          (batch 재실행을 가로질러 시도 대장에서 합산 — 대화 카운터는 예산이 아니다)
exhaust:  Rung 3 — blockIssue(child,  ' unstuck_exhausted ' ) (보드 + 점유 해제) + 형제 계속. 이 레벨의 마무리는
          §5.2 descope/waive 로만 열린다(자동 waive 없음)
resume:   시도 대장 마커 코멘트 + child 의 GitHub state/파이프라인 재조회
log:       " 🔁 #123 attempt 2/3(누적) cause={의미 요약} "   + 탈락 시 이유와 대장 state 전이

L-B3.66r  종료 후 복구 + 재개  (Phase 3-6.6)
inv:      머지는 되돌리지 않는다 · `gh issue reopen` **이후에만** In Progress 로 옮긴다
prog:     남은 open child 수, 재개 1회당 강한 감소
          no-prog: 재개했는데 open 수가 그대로면 그 child 를 §5.2 로 보낸다
term:     openChildrenStatus(issue) ===  " none "   (또는 남은 open 전부 `waived`)
budget:   reopen 1회 / batch 실행 · 재개는 `/cc-dev:batch {n}` 재실행 1회당 1 사이클
exhaust:  BLOCKED + 사람 호출 — 컨테이너를 열린 자식 위에서 닫힌 채로 두지 않는다
resume:   openChildrenStatus 재조회 + 시도 대장 (reopen·코멘트·파이프라인 이동 모두 멱등)
log:       " ♻️ #20 reopen: 남은 자식 #21,#22 "   + 세 완료성 체크포인트의 **타임스탬프**

1. Tooling preflight (진입 전 1회):
   - command -v gh  & &   gh auth status   → 미인증이면 즉시 중단(머지 전에 실패, 계층 중간 아님)
   - command -v melos / dart / flutter  → 부재 시 /cc-dev:run  " Step 0 Degradation Contract "   를 따른다(우회 + 경고)
   - Orca 가용성 확인 (위  " Orca Parallel Dispatch — 0. 가용성 확인 " ) — 실패해도 순차 폴백일 뿐 하드 실패 아님
   - 중복 착수 확인은 각 leaf 의 /cc-dev:run  " Step 0.5 Duplicate Work Preflight "   가 담당한다
     (컨테이너 레벨에서 미리 검사하지 않는다 — leaf 착수 직전이 가장 정확하다)
   - **대화 가능성 판정 1회**: `--unattended`(또는 `/cc-dev:go --auto` 전파)이면 이 실행 전체를
     무인으로 취급한다 → 위  " Unattended  &   Approval Contract "   표의 기본값이 적용되고, 스폰 승인이
     필요한 자리는 `--no-parallel` 로 강등된다. 이 판정은 하위 재귀 호출에 그대로 전파한다.
2. Resume 계약 (멱등):
   - 이미 Closed 인 child 는 건너뛴다(Phase 2에서 상태 확인).
   - ⭐ **놓친 워크트리 회수도 여기서 이어받는다**(`B0.r` — 대상 이슈가 확정된 Phase 0.3 직후,
     대장을 읽을 수 있게 된 시점에 1회). 세션이 죽거나 `/clear` 로 끊기면 머지 시점의 회수가
     통째로 날아가므로, 회수는 **이벤트 하나에만 매달지 않는다**. 절차는
     [orca-worktree-lifecycle](../skills/orca-worktree-lifecycle/SKILL.md) →  " 고아 스윕 " .
   - 중간 실패 시 `/cc-dev:batch {issue_number}` 를 다시 실행하면 마지막으로 머지된 child 다음부터 이어서 처리한다.
   - 따라서 한 child 실패가 이 레벨 전체를  " 절반-머지 "   로 영구 고착시키지 않는다.
   - ⭐ **재개는 같은 머신일 필요가 없다.** 다른 컴퓨터·다른 세션에서 재실행해도 같은 계층 브랜치를
     이어받는다 — 단, 그러려면 브랜치 조회가 **원격 권위 조회 + 번호 글롭 + 브랜치 대장**이어야 한다
     (Phase 1.5-0/2, branch-hierarchy R1~R3). 로컬 remote-tracking ref 나 재계산한 slug 에 의존하는
     순간 재개가  " 새 브랜치 생성 " 으로 갈라진다.

1. `getWorkspacePipelinesAndRepositories()` + `getIssueTypes({repositoryId})` 로
   워크스페이스의 이슈 타입 레벨 테이블 확보 (Initiative(1)/Project(2)/Epic(3)/
   Feature·Bug·Task(4)/Sub-task(5) — 워크스페이스에 없는 레벨은 생략될 수 있다,
   `rules/zenhub-conventions.md`  " Issue Type Hierarchy "   참조).
2. `searchLatestIssues({query:  " #{issue_number} " })` 로 대상 이슈 + `issueType` + `parentIssue` 조회.
3. 레벨에 맞는 브랜치 prefix 결정 — `resolveBaseBranch()`(commands/run.md)와 동일 매핑:
     Initiative → initiative/ · Project → project/ · Epic → epic/ ·
     parent 있는 Feature/Bug/Task → story/ · Sub-task → task/
4. 못 찾으면(이슈 없음) 사용자에게 정확한 번호를 확인받고 중단.

0.5-1. Seed 탐지 (게이트):
   - SEED=$(ls -1 docs/seed-spec-*.md 2 > /dev/null | tail -1)
   - SEED 가 없으면 → **no-op (조용히 skip)**. 경고도 차단도 없음.
   - SEED 가 있으나 머리글이 `Status: LOCKED` 가 아니면(DRAFT) → **no-op + 1줄 안내**( " 기획 명세 미확정 → 정렬 점검 skip " ). DRAFT 를 강제로 잠그지 않는다.
   - → 즉, 시드가 없거나 미확정인 저장소에서 `/cc-dev:batch` 는 **절대 하드페일하지 않는다**(submodule 동기화 no-op 와 동일한 graceful degradation 형태).

0.5-2. 정렬 점검 (LLM-SEMANTIC, /cc-spec:status 재사용):
   - 대조 대상:
     - pre-batch  → 이번 대상 이슈 아래 **계획된** 하위 이슈 집합(제목/본문/AC)
     - post-batch → 최종 병합 직후 **완료(Closed)된** 이슈 집합 + 이 레벨 브랜치 누적 변경(diff/PR)
   - `/cc-spec:status --against {계획/완료 이슈 집합 또는 최종 PR}` 를 실행해 LLM-SEMANTIC 정렬 리포트를 받는다:
     - **AC-ID 상태 echo** — Seed S4(Acceptance Boundaries)의 각 합격 기준을 `AC-01`, `AC-02` … 로 식별하고 PENDING / IN-PROGRESS / MET / FAILED / WAIVED 로 표기.
     - **목표 정렬 판정** — 작업 묶음의 의도가 Seed S1(Core Problem)과 같은 방향인지 ALIGNED / MINOR-DRIFT / MAJOR-DRIFT 로 판정.
     - **제약 위반 플래그** — 작업이 위반하는 것으로 보이는 Seed S2(Immutable Constraints) 항목을 나열.
   - ⚠️ **의미 기반 판단만 사용한다(절대 어휘/토큰 일치 아님)**: Seed 와 이슈/AC 텍스트는 **한국어 우선**이라 공백·토큰 겹침 매칭은 조사·띄어쓰기에서 깨진다. drift/정렬/AC 매칭은 모두 **LLM 의미 판단**으로 수행한다(`/cc-spec:status` 와 동일 원칙).

0.5-3. 판정별 행동:
   - ALIGNED / MINOR-DRIFT → 리포트만 출력하고 그대로 진행(차단 아님).
   - **MAJOR-DRIFT → 경고 후 일시정지(필수)**: 어긋난 지점을 요약해 보여주고 `AskUserQuestion` 으로  " 기획과 크게 어긋남 — 그래도 계속할까요? "   확인을 받는다.
     - pre-batch: 사용자가  " 중단 "   선택 시 배치를 시작하지 않고 종료(이슈/명세 조정 후 재실행).  " 계속 "   선택 시 사유를 로그에 남기고 Phase 1 로 진행.
     - post-batch:  " 중단 "   선택 시 이 레벨의 종료를 보류(이 레벨 PR 은 이미 병합됐으므로 추가 후속 이슈로 표류 항목을 추적).  " 계속 "   선택 시 그대로 마무리.
   - 이 점검은 **품질 게이트가 아니라 방향 점검**이다 — 테스트/lint/리뷰 Critical 처럼 hard fail 하지 않고, **MAJOR-DRIFT 에서만 사용자 확인으로 멈춘다**.

0.5-4. 멱등/재개: 읽기 전용이라 부작용이 없다. `/cc-dev:batch {issue_number}` 재실행 시 pre-batch 점검도 다시 도는 게 정상이며, 이미 Closed 인 child 는 Phase 2 에서 건너뛴다.

0. (Phase 0.5) Pre-batch seed-alignment checkpoint — LOCKED seed 있으면 LLM-SEMANTIC 정렬 점검(MAJOR-DRIFT 시 확인 후 진행), 없으면 no-op skip
1. `{ children, known } = listChildren(issue_number)` 로 직계 자식을 **전수** 조회한다 —
   **GD-04 방식**(`run.md` Step 0.6): GitHub 네이티브 `subIssues`(`totalCount`/`nodes`)가
   completeness source of truth 다. ZenHub `searchLatestIssues({query:  " parent:{issue.id} " })`
   단독 판정 금지( " 최신 20개 "   창 밖의 sub-issue 를 놓친다) — pipeline/issueType 같은 부가
   메타데이터가 필요하면 확인된 각 자식 번호로 `searchLatestIssues({query:  " #{n} " })` 를 보강
   조회한다. 이 조회의 단일 정의는 `rules/zenhub-conventions.md` →  " Child Enumeration Contract " .
   - `known === false` (조회 실패) → ⛔ **여기서 중단**한다. 조회 실패를  " 자식 없음 " 으로 읽으면
     컨테이너를 leaf 로 오판해 `/cc-dev:run` 이 자식을 무시하고 컨테이너를 닫아 버린다
     (`#3451` 사고 경로). `gh auth status` 확인 후 재실행하라고 안내하고 정지.
1.5. **기존 자식 재사용 계약** — children 이 1개 이상이면 **그 이슈들을 처리한다.** 같은 작업을
   담은 새 이슈를 만들어 그것만 처리하는 것은 금지다(`rules/zenhub-conventions.md` →
    " Existing-Children Reuse " , `run.md` Step 0.6 과 같은 규칙). 본문·AC 가 낡았으면
   `updateIssue` 로 **그 자식을 갱신**한다.
2. children.length === 0 **이고 `known === true`** (검증된 leaf) 이면:
   a. Initiative/Project/Epic 레벨이면 → ⚠️ 판정 불가:  " 자식이 없는 게 맞습니까? " 를
      AskUserQuestion 으로 확인받은 뒤에만 진행 (Story/Sub-task 는 확인 없이 정상 진행 —
      leaf 가 기본값이다).
   b. `/cc-dev:run {issue_number}` 를 그대로 호출한다 — batch.md 는 여기서 브랜치를 별도로
      만들지 않는다. `/cc-dev:run` 자신의 Step 4 `resolveBaseBranch()` 가 이 이슈의 레벨에
      맞는 브랜치(parent 있으면 그 브랜치 기반, 없으면 development 기반)를 스스로 만들고,
      Step 9~12.5 가 구현 → 테스트 → lint/DCM → 코드리뷰 게이트 → PR → squash merge →
      close+검증까지 전부 수행한다.
   c. 반환: 이 이슈는 완료. **이 실행은 여기서 끝난다** — 아래 Phase 1.5/2/3 는 container
      케이스 전용이다.
3. children.length  >   0 (container) 이면 → Phase 1.5 로 진행.

0. ⭐ **원격 동기화 먼저**: `git fetch origin --prune` — 이 배치가 **다른 머신·다른 세션이 만들어 둔
   브랜치를 이어받는** 경우가 정상 경로다(브레이크다운은 이슈만 만들고 브랜치는 만들지 않으므로,
   project/ 브랜치는  " 그 아래 Epic 을 처음 진행한 세션 " 이 만들어 둔 상태다). fetch 없이 origin/*
   를 읽으면 그 브랜치가  " 없음 "   으로 보이고 **가짜 부모 브랜치를 하나 더 만든다**.
1. myBaseBranch 결정: parentIssue 가 있으면 그 브랜치를 최신 pull(없으면 재귀적으로 생성 —
   resolveBaseBranch() 와 동일 절차), 없으면 development 를 최신 pull
2. 이 이슈 전용 브랜치 확보: **먼저 찾고, 없을 때만 만든다** —
   `git ls-remote --heads origin  " refs/heads/{levelPrefix}/{issue_number}-* " ` (번호 글롭)
   + 브랜치 대장(` < !-- cc-dev:branch-registry -- > `) 조회. 찾으면 그대로 체크아웃(멱등 재개),
   **2개 이상 나오면 R4 tie-break** 로 하나만 채택(대장 기록 + 경고 + 탈락본 삭제 금지),
   없으면 `{levelPrefix}/{issue_number}-{slug}` 로 만들고 **커밋이 0개여도 즉시
   `git push -u origin`** 한 뒤 대장에 이름을 기록한다.
   ⛔ **재계산한 전체 이름으로 완전일치 조회를 하지 않는다** — slug 는 제목을 로마자로 옮긴 것이라
      세션마다 갈린다(`저자 관리` → `jeoja-gwanli` / `jeoja-gwanri`). 이 한 줄이 어긋나면 같은
      Project 에 계층 브랜치가 둘 생기고, Epic 이 가짜 부모로 머지돼 진짜 Project 브랜치는 빈 채
      남는다. 절차 전문(R1~R7)의 SoT 는
      [branch-hierarchy](../skills/branch-hierarchy/SKILL.md) →  " 계층 브랜치 해석 계약 " .
3. 이 이슈를 In Progress 파이프라인으로 이동 — 이 이슈 자신의 parentIssue(Project/Initiative
   등)가 아직 착수 전 칸(New Issues/Icebox/Product Backlog/Sprint Backlog)에 있다면
   조부모까지 함께 cascade한다(`cascadeStartToParents`, `agents/dev/issue-state-agent.md`
   참조) — `/cc-dev:batch`가 중간 레벨 이슈로 직접 호출된 경우에도 그 위 계층이  " 아직
   손 안 댄 일 " 처럼 보드에 방치되지 않도록 한다.

const workspace = await mcp__zenhub__getWorkspacePipelinesAndRepositories();
const pid = (n) = >   { const p = workspace.pipelines.find(p = >   p.name === n);
  if (!p) throw new Error(`파이프라인  ' ${n} '   없음. 라이브: ${workspace.pipelines.map(p= > p.name).join( " ,  " )}`); return p.id; };

// 3-a. 이 컨테이너 자신을 In Progress 로
await mcp__zenhub__moveIssueToPipeline({ issueId: issue.id, pipelineId: pid( " In Progress " ) });
// 3-a2. 이 **레벨**의 점유 획득 — 같은 Epic 에 batch 가 두 번 도는 것을 막는 유일한 신호다.
//       (SoT: ../rules/zenhub-conventions.md → Work Claim Contract)
//       ⛔ 이 점유는 **자식 착수를 막지 않는다** — 자식은 이 batch 자신이 디스패치한다.
await acquireClaim(issue, { branch: myBranch });
// 3-b. 부모 체인이 아직 착수 전 칸이면 조부모까지 함께 (agents/dev/issue-state-agent.md)
//      ⛔ cascade 는 점유 대장을 쓰지 않는다 — 부모를 잡으면 형제 Epic 이 전부 막힌다.
await cascadeStartToParents(issue.number);
// 3-c. 읽어서 확인 — 무음 누락 금지
const after = (await mcp__zenhub__searchLatestIssues({ query: `#${issue.number}` }))
  .find(i = >   i.number === issue.number);
console.log(`📍 #${issue.number} 파이프라인: ${after?.pipelineIssue?.pipeline?.name}`);

a. 형제 children 중 서로 의존성 없는 것들은 **Orca 오케스트레이션으로 병렬 착수**한다
   (위  " Orca Parallel Dispatch "   절차 그대로 — **동시 워크트리 ≤ --max-parallel(기본 3)**, 넘치는
   형제는 대기큐 + deferred 로그, 워커당 wall-clock 4h 초과 시 `BLOCKED( ' worker_timeout ' )` 후
   형제 계속. 루프 계약은 위 `L-B2a`). 의존관계가 있는 children 은 순서를 지켜 직렬 디스패치.
   ⛔ **라우팅 판정 앞에 점유부터 본다.** 워커를 띄우는 것은 워크트리·세션을 소비하는 일이라,
   이미 남이 잡고 있는 child 를 디스패치하면 **두 세션이 같은 이슈를 각자 완주**한다
   (`../rules/zenhub-conventions.md` → Work Claim Contract):
     const claim = await claimStatus(child.number, me);
     claim ===  " other-live "   → 디스패치하지 않고 `SKIPPED-OCCUPIED` 로 큐에서 뺀다.
       **형제는 계속**한다(`BLOCKED` 형제 처리와 같은 원칙 — 큐를 잡아 두지 않는다).
       완료성 Hard Gate 에서는 **OPEN 자식과 동일 취급**이다 — 점유됐다고 컨테이너를 닫지 않는다.
     claim ===  " stale "   → 인수 기록 후 정상 디스패치 · `mine`/`none` → 정상 디스패치
   ⚠️ 워크트리 병렬은 **같은 계정·같은 머신**에서 형제 워커를 띄운다 — 점유 대장의 `owner` 가
   `host:워크트리경로` 인 이유가 이것이다(호스트만으로는 형제끼리 구분되지 않는다).

   각 child 의 라우팅은 **Phase 1 과 동일한 판정**을 쓴다 — `listChildren(child.number)` 로
   `{ children, known }` 을 받아:
     known === false                → ⛔ 이 child 는 라우팅하지 않는다(BLOCKED 표시 후 형제 계속).
       조회 실패를 leaf 로 읽으면 컨테이너가 /cc-dev:run 으로 흘러가 자식 위에서 닫힌다.
     children.length  >   0 (container) → /cc-dev:batch {child.number} {inherited} (이 알고리즘 재귀
       적용 — 재귀 호출도 동일하게 Phase 1 의 leaf/container 판정부터 다시 거친다)
     children.length === 0 (검증된 leaf) → /cc-dev:run {child.number} {inherited}
   `{inherited}` 는 위  " 3. 디스패치 " 와 같은 의미다 — 이 실행이 받은 `--merge=pre-authorized`·
   `--unattended` 를 그대로 옮겨 붙인다(새로 판단하지 않는다).
   resolveBaseBranch()(commands/run.md)가 이미 만들어진 `myBranch`를 child의 부모 브랜치로
   자동 인식하므로, 별도 --base 지정이 필요 없다.
b. **머지는 항상 직렬화**한다(병렬 구현과 별개) — 이 조인의 이름은
   **`mode:stream serialize:1 order:worker_done-arrival`** 이다(barrier 아님). 워커가 끝난
   순서대로 하나씩 처리하고, **머지 직전 그 child 를 현재 `myBranch` 위로 갱신한 뒤
   `runPrePushGate()` 를 재실행(또는 갱신된 head 의 CI green 확인)** 한 다음
   PR→squash merge 하며, 매 머지 후 `myBranch` 를 pull 해 다음 머지 전에 최신화(충돌 방지).
   충돌은 rung C1/C2(`skills/merge-conflict-resolution/SKILL.md`)로 처리하고 큐 상태 전이는
   전부 로그로 남긴다 — 상세·루프 계약은 위  " 4. 머지는 항상 직렬화 "   와 `L-B2b`.
   ⛔ **`BLOCKED` 형제는 큐를 잡아 두지 않는다** — 큐에서 빠지고 나머지 도착 순서대로 계속한다.
   ⭐ **머지된 child 의 워크트리는 그 자리에서 회수한다**(위  " 4.5 " ) — 슬롯·디스크가 회복돼야
   대기줄의 다음 형제가 착수한다. `BLOCKED` 로 빠진 형제의 워크트리는 **보존**한다(진단 현장).
c. child 하나가 반복 실패하면 위  " Stall Ladder "   를 적용: (1) 재시도 → (2) `/cc-dev:unstuck
   solo  < persona > ` 리프레임 → (3) `BLOCKED( ' unstuck_exhausted ' )` 표시 후 **나머지 형제는
   계속 진행**(이 이슈 전체를 막지 않음). 시도 횟수는 **시도 대장**(위 5.1)에 누적 기록되어
   batch 재실행을 가로질러 예산으로 쓰이고, 누적 3회 소진 시 그 child 는 `blocked` 로 고정된다.
d. **완료성 Hard Gate** (= `rules/zenhub-conventions.md`  " Parent Closure Invariant "   의 1번째 지점):
   이 자리 하나만 **`mode:barrier`** 다 — `because:` 는 *cross-item completeness, fresh re-query,
   no cache*(교차 항목 근거. `rules/orchestration-graph.md` §4.2 의 확인된 barrier 목록에 이미
   등재). 모든 children 을 **전수** 재조회해 전부 GitHub `CLOSED` 인지 확인한다 —
   **GD-04 방식 필수**(GitHub 네이티브 `subIssues` 를 근거로, ZenHub `parent:` 검색 단독 금지):
     const kids = await openChildrenStatus(issue.number);  // Child Enumeration Contract — tri-state
     if (kids.status !==  " none " ) → ⛔ 이 레벨의 PR/머지/종료 중단. BLOCKED( ' unstuck_exhausted ' )·
       BLOCKED( ' worker_timeout ' )·BLOCKED( ' merge_conflict ' ) 는 **그대로 OPEN 으로 간주**한다.
       `SKIPPED-OCCUPIED`(남이 잡고 있어 착수하지 않은 child)도 마찬가지다 — 남이 끝내 줄 수도 있지만
       **이 실행이 확인한 것은  " 안 닫혔다 "   뿐**이다. waive 대상도 아니다(사람 결정이 없었다).
       throw `#${issue_number} 미완료: ${kids.status ===  " unknown " 
          ?  " 자식 조회 실패(판정 불가) "   : `OPEN child ${kids.open.length}개 (${kids.open.map(c= > " # " +c.number)})`}. 해결/재시도 후 batch 재실행`

   ⛔ **판정을 `open.length  >   0` 로 쓰지 않는다.** 조회가 실패하면 결과가 `[]` 가 되고
   `open.length  >   0` 는 **`[]` 에서 통과**한다 — 즉 조회가 깨진 순간에 정확히 게이트가 열린다
   (`#3451` 사고 경로). tri-state 에서 통과는 `none` 하나뿐이고, `unknown` 은 차단이다.

   ✅ **유일한 예외 — `waived`**: `status ===  " open " ` 이어도 **열린 자식 전부**가 시도 대장에서
   `waived`(위 5.2, 사람 결정 + 내구 기록 완료)이면 통과한다. 판정 함수는 그대로
   `openChildrenStatus()` 이고 새 판정 함수를 만들지 않는다 — batch 가 그 `open` 목록을 대장과
   대조해 `open` / `waived` 로 분류할 뿐이다. `unknown` 은 예외 없이 차단이며, `blocked`(waive
   되지 않은 것)도 차단이다. 이 예외가 없으면 영구 BLOCKED child 하나가 이 레벨을 **영구히
   마무리 불가**로 고정한다(재실행할수록 같은 자리에서 같은 이유로 멈추는 livelock).
   🕒 **판정마다 타임스탬프를 남긴다** — `⏱️ gate① {ISO8601} status={none|open|unknown} waived={n}`.
   세 체크포인트(2-d / 3-4.9 / 3-6.6) 사이 간격이 감사 가능해야 한다(`#3451` 은 11시간이었다).
e. 전부 닫혔으면 `myBranch` 를 리뷰하고 PR 생성 (아래  " Phase 3 "   그대로 이어짐).

1. ⛔ 완료성 Hard Gate — 위 Phase 2-d 그대로(`waived` 예외와 타임스탬프 로그 포함).
   통과 못 하면 여기서 정지(재실행으로 재개).
1.5. ⭐ **myBaseBranch 재해석 (다른 머신이 그 사이 부모 브랜치를 만들었을 수 있다)** —
   Phase 1.5 이후 children 처리로 **수 시간~수 일**이 흐른다. 그 사이 다른 머신·세션이 부모
   브랜치를 만들었을 수 있고, Phase 1.5 에서 부모를 못 찾아 `development` 를 base 로 잡았다면
   지금 그 값은 낡았다. `git fetch origin --prune` 후 부모 브랜치를 **번호 글롭 + 대장**으로 다시
   해석한다(branch-hierarchy R1~R4). 바뀌었으면 myBaseBranch 를 갱신하고 로그에 남긴다:
   `🎯 base 재해석: {이전} → {지금}`.
2. Review changes against myBaseBranch
2.3. ⭐ **base 드리프트 흡수 — 일반 머지** (myBaseBranch 가 `development` 처럼 계속 움직이는
     브랜치일 때): children 처리 동안 base 가 수십 커밋 앞서 있으면 최종 PR 은 BEHIND·충돌로
     시작한다. `git fetch origin  & &   git merge origin/{myBaseBranch}` 로 흡수하고 충돌은 **파일별로**
     해소한다(`merge-conflict-resolution` 스킬 — 생성 파일은 재생성, 비즈니스 로직은 양쪽 의도
     이식). ⛔ `-s ours`·`-X ours`·일괄 `--ours` 금지 — base 의 변경이 조용히 되돌아가고
     되돌림을 잡을 테스트가 함께 삭제돼 CI 는 green 이다. 머지 후 리포에 되돌림 가드
     (`check_merge_revert.py` 류)가 있으면 돌리고, 정당한 재작성은 커밋 메시지에 예외 마커로
     남긴다. 머지 커밋 메시지도 리포 commit-msg 훅 형식(type·scope)을 따른다 — `merge:` 타입은
     흔히 거부된다.
2.5. ⭐ **승격 전  " 전체 CI 전용 "   게이트 로컬 선실행** — 계층 PR(`story→epic→project`)에는
     경량 검증(변경 패키지 분석·테스트·골든)만 돌고 **포맷 잡의 가드 스크립트·DCM·백엔드 unit·
     웹 빌드는 한 번도 돌지 않는다**. 그것들이 처음 도는 자리가 이 최종 PR 이라, 자식이 많을수록
     승격 PR 이 처음 만나는 실패가 누적되고 그 시점엔 수백 파일 diff 라 원인 자식을 되짚기
     어렵다. PR 을 열기 **전에** 로컬에서 돌린다:
     

 # ci.yml 의 단일행 가드 호출을 그대로 뽑아 전부 실행 (실측: 96개 · 수 분)
 grep -oE '^[[:space:]]*run: python3 \.github/scripts/[a-z_]+\.py[^#]*$' .github/workflows/ci.yml \
   | sed -E 's/^[[:space:]]*run: //' | sort -u | while IFS= read -r CMD; do
       eval "$CMD" >/dev/null 2>&1 || echo "❌ $CMD"; done
 bash scripts/lefthook/dcm_check.sh format --changed   # 리포에 있는 경우
 <pre><code>     실패한 가드가 **정상 코드를 오탐**하면(자식 Epic 의 리팩토링이 가드의 정규식 전제를 깬
 경우 — 실사고: 테마를 형제 파일로 분리하자 한 파일만 보던 버튼 규격 가드가 4개 테마를
 오탐) 예외 마커로 덮지 말고 가드의 해석 범위를 넓히고 회귀 테스트에 **실제 오탐 형태**를
 첫 케이스로 넣는다. 결과는 3번 PR 본문의 로컬 게이트 실측에 함께 적는다.

┌─────────────────────────────────────────────────────────────────┐
│  /cc-dev:batch {issue_number}   (어느 레벨이든)                    │
├─────────────────────────────────────────────────────────────────┤
│                                                                  │
│  Phase 0.3: 레벨 판별 (Initiative~Sub-task)                        │
│  Phase 1: Leaf/Container 판정 (children 전수 조회 — GitHub sub-issues)│
│  ├── 조회 실패(known=false) → ⛔ 중단 (leaf 로 오판 금지)              │
│  ├── children 없음(검증된 leaf) → /cc-dev:run {n} 위임 → 종료          │
│  └── children 있음(container) → 그 자식들을 처리 (새로 만들지 않음)      │
│                                                                  │
│  Phase 1.5: 이 이슈의 브랜치 확보 + 보드 반영 (container 전용)          │
│  ├── git fetch --prune → ls-remote  " {prefix}/{n}-* "   + 브랜치 대장  │
│  │     └── 있으면 그대로 채택 (다른 머신이 만든 것도 여기서 잡힌다)     │
│  ├── 없을 때만: parent 브랜치(없으면 development) 기반으로 생성       │
│  ├── git checkout -b {prefix}/{n}-{slug}  & &   git push -u origin   │
│  │     └── 커밋 0개여도 즉시 push + 대장에 이름 기록                  │
│  └── In Progress 이동 + cascadeStartToParents (부모 체인까지)         │
│                                                                  │
│  Phase 2: Recursive Child Processing (container 전용)             │
│  ├── 독립 형제 → Orca 병렬 디스패치 (승인 후, ≤3 + 대기큐)             │
│  │     └── 각 워크트리에서 /cc-dev:batch {child} 재귀 실행             │
│  │         (child 도 Phase 1 leaf/container 판정부터 다시 거침)       │
│  ├── 의존 형제 → 순차 디스패치                                       │
│  ├── 머지는 직렬 (도착 순, 갱신→재게이트→머지)                          │
│  └── 머지된 child 워크트리 회수 (파생 자원 반납 → 제거 → 대장)          │
│        └── BLOCKED 형제의 워크트리는 보존 (진단 현장)                  │
│                                                                  │
│  Phase 3: Container Finalization                                 │
│  ├── 완료성 Hard Gate ① (전 children CLOSED — tri-state)            │
│  ├── 작업내역 아티팩트 발행 → PR 본문에 링크 (run.md Step 9)          │
│  ├── 이 레벨 브랜치 → 부모 브랜치(또는 development) PR → Review/QA      │
│  ├── CI 대기 ∥ 아티팩트 CI 상태 갱신 (run.md Step 10.5)               │
│  ├── Review → 완료성 Hard Gate ② (머지 직전 재검증)                   │
│  ├── PR base 재해석 → 다르면 gh pr edit --base (retarget, R7)      │
│  ├── → Squash merge                                              │
│  ├── Close 검증 → 완료성 확인 ③ (위반 시 gh issue reopen 복구)         │
│  └── 부모 완료 신호 확인 (자동 병합 아님 — /cc-dev:batch {parent} 안내) │
│                                                                  │
└─────────────────────────────────────────────────────────────────┘

// Phase 0.3: 레벨 판별
const workspace = await mcp__zenhub__getWorkspacePipelinesAndRepositories();
const issueTypes = await mcp__zenhub__getIssueTypes({ repositoryId });
const target = (await mcp__zenhub__searchLatestIssues({ query: `#${issueNumber}` }))
  .find(i = >   i.number === issueNumber);

// Phase 1: leaf/container 판정 — /cc-dev:batch {issue_number} 는 이 함수 하나로 귀결된다
async function processIssue(issueNumber) {
  const issue = (await mcp__zenhub__searchLatestIssues({ query: `#${issueNumber}` }))
    .find(i = >   i.number === issueNumber);

  // ⚠️ 자식 조회는 Child Enumeration Contract 를 쓴다 (rules/zenhub-conventions.md).
  //    GD-04: ZenHub searchLatestIssues({query: " parent:… " }) 는  " 최신 20개 "   창 안에서만
  //    필터링하고 실패 시 [] 를 돌려주므로, leaf/container 판정과 완료성 게이트의 근거로
  //    쓸 수 없다. completeness 는 GitHub 네이티브 subIssues 로 확인한다(run.md Step 0.6).
  const { children, known } = await listChildren(issueNumber); // GD-04 subIssues 기반, tri-state 래퍼
  if (!known) {
    throw new Error(
      `#${issueNumber} 자식 조회 실패 — leaf/container 판정 불가. ` +
      `조회 실패를  " 자식 없음 " 으로 처리하면 컨테이너를 leaf 로 오판해 열린 자식 위에서 닫는다. ` +
      `gh auth status 확인 후 재실행하라.`
    );
  }

  if (children.length === 0) {
    // 검증된 leaf — batch.md 는 브랜치를 만들지 않는다. /cc-dev:run 에 그대로 위임한다.
    // resolveBaseBranch() (run.md) 가 이 이슈의 레벨/parent 에 맞는 브랜치를 스스로 찾거나 만든다.
    // await Task({ subagent_type:  " implementation-agent " , prompt: `/cc-dev:run ${issueNumber}` }) 등,
    // run.md Step 4~12.5 전체가 여기서 실행된다.
    return;
  }

  // container — Phase 1.5: 이 이슈 자신의 브랜치를 먼저 **찾고**, 없을 때만 만든다.
  // ⚠️ 조회는 `git fetch --prune` 후 `ls-remote  " refs/heads/{prefix}/{n}-* " ` + 브랜치 대장이다
  //    (branch-hierarchy  " 계층 브랜치 해석 계약 "   R1~R4). 재계산한 전체 이름으로 완전일치 조회를
  //    하면 다른 머신이 다른 로마자 표기로 만든 브랜치를 놓치고 가짜 부모를 하나 더 만든다.
  const myBranch = ensureOwnBranch(issue); // 찾으면 채택, 없으면 생성 → 즉시 push → 대장 기록
  // Phase 1.5-3: 보드 반영 — 컨테이너 자신 + 부모 체인 (누락 시 Epic 이 Product Backlog 에 방치된다)
  await mcp__zenhub__moveIssueToPipeline({ issueId: issue.id, pipelineId: pid( " In Progress " ) });
  await cascadeStartToParents(issue.number);   // agents/dev/issue-state-agent.md

  // Phase 2 — 독립 children 은 Orca 병렬, 의존 children 은 순차
  // ⚠️ 여기서 처리하는 것은 위에서 조회한 **기존** children 이다. 같은 작업의 새 이슈를 만들어
  //    그것만 처리하면 원본 자식이 열린 채 남아 부모가 불변식을 위반한다(Existing-Children Reuse).
  // (parallel dispatch 상세는 위  " Orca Parallel Dispatch "   절 참조)
  // width = min(후보 수, --max-parallel ?? 3). 초과분은 대기큐 + deferred 로그(조용한 절단 금지).
  for (const child of independentBatchesInDependencyOrder(children)) {
    // child 마다: processIssue(child.number) 를 재귀 호출(=별도 워크트리에서 /cc-dev:batch {child.number})
    // 워커 대기: wall-clock --worker-timeout ?? 4h → 초과 시 BLOCKED( ' worker_timeout ' ) + 형제 계속
    // 각 child 완료 후 머지는 직렬 — worker_done 도착 순서대로 하나씩:
    //   현재 myBranch 위로 갱신 → runPrePushGate() 재실행(또는 갱신 head CI green) → PR→merge
    //   (재검증 없이 머지하면 앞 형제의 squash 이전 base 로 통과한 판정을 그대로 쓰는 것이다)
  }

  // Phase 3-1: Hard Gate — GD-04 방식으로 **재조회** (Phase 2 도중 child 가 새로 만들어졌을
  // 수 있으므로 캐시된 children 을 재사용하지 않는다). tri-state —  " none "   만 통과하며,
  // `open.length  >   0` 식 판정은 `[]` 에서 공허하게 통과하므로 쓰지 않는다.
  const kids = await openChildrenStatus(issue.number);
  // waived 예외: 열린 자식 **전부** 가 시도 대장에서 waived 인 경우에만 통과 (Phase 2-d ✅ 항목).
  // unknown 은 예외 없이 차단. 판정 함수는 openChildrenStatus() 하나이며 새로 만들지 않는다.
  const allWaived = kids.status ===  " open "   & &   kids.open.every(c = >   ledgerState(c.number) ===  " waived " );
  console.log(`⏱️ gate① ${new Date().toISOString()} status=${kids.status} waived=${kids.open.filter(c = >   ledgerState(c.number) ===  " waived " ).length}`);
  if (kids.status !==  " none "   & &   !allWaived) {
    throw new Error(`#${issue.number} 미완료: ${kids.status ===  " unknown " 
       ?  " 자식 조회 실패(판정 불가) "   : `OPEN child ${kids.open.length}개`}`);
  }

  // Phase 3-2: 이 레벨 자신의 PR → 부모 브랜치(또는 development) → Review/QA 이동 → CI/리뷰
  // gh pr create --base  " ${issue.parentIssue ? myBaseBranch :  ' development ' } "   ...
  // Phase 3-4.9: 머지 **직전** 에 openChildrenStatus 를 다시 호출해 재확인 (CI/리뷰 사이에 자식이 늘 수 있다)
  // 머지 후 close+검증 → Phase 3-6.6 에서 한 번 더 확인, 위반이면 gh issue reopen 으로 복구.
  // 그리고 부모가 있으면 checkAndCloseParent(issue.number) 로 신호만 남기고 정지.
}

const workspace = await mcp__zenhub__getWorkspacePipelinesAndRepositories();
const pipelines = workspace.pipelines;
// Find by name in pipelines:  " New Issues " ,  " In Progress " ,  " Review/QA " , etc.
// Done pipeline is NOT used (Done ≠ closed). Merge = Close: `Closes #` → GitHub closed
// → ZenHub syncs to Closed. Verify with searchClosedIssues + fallback updateIssue.

gh pr create --base  " {parentBranch:-development} "   \
  --title  " {issue.title} "   --body  " $(cat  < < ' EOF ' 
 ## Summary
- {Change summary}

## Included Children
- ✅ #{child_1} - {title}
- ✅ #{child_2} - {title}

## Dispatch                      ← 병렬 승인/강등과 cap 결과의 내구 기록
- width {N}/{--max-parallel} · deferred: #{n}, #{n} (슬롯 회수 후 착수)
- degraded to sequential: {yes(--unattended: 스폰 승인 불가)|no}

## Waived Children               ← 있을 때만 포함 (§5.2 waive 결정의 내구 기록)
- ⏸️ #{child_k} - {title} — 사유 {요약} · 후속 이슈 #{follow_up}

## Seed Alignment                ← LOCKED seed 가 있을 때만 포함 (Phase 0.5)
- pre-batch {ALIGNED|MINOR-DRIFT|MAJOR-DRIFT} / post-batch {…} · MAJOR-DRIFT 처리 {확인|무인 경고}

## Related Issue
- Closes #{issue_number}
- Parent: #{parent_number}   ← parentIssue 가 있을 때만 포함

## Test Plan
- [ ] Full integration tests passed
- [ ] Manual testing complete (해당 레벨에 맞게 조정 — Sub-task/Story 는 unit/BLoC 위주)

🤖 Generated with [Claude Code](https://claude.ai/claude-code)
EOF
) "