# Start full cycle with work content
/dev:run  " 저자 목록 화면 추가 "

/dev:run 1810
# 또는
/dev:issue 1810

# Specify type
/dev:run --type feat  " Add author list screen " 

 # Specify scope
/dev:run --scope console-author  " Add author list screen " 

 # Specify point
/dev:run --point 5  " Add author list screen " 

 # Sprint assignment
/dev:run --sprint current  " Add author list screen " 

 # PR only (no merge wait)
/dev:run --no-merge  " Add author list screen " 

 # Explicit base branch (manual parent branch setting)
/dev:run --base epic/1810-author-feature 1812

# Skip review (urgent hotfix)
/dev:run --skip-review  " Urgent fix " 

 # Force BDD scenarios (even for non-screen features)
/dev:run --bdd  " API client refactoring " 

 # Skip BDD scenarios and BDD Coverage Gate (even for screen features)
/dev:run --skip-bdd  " Simple list modification " 

 # Skip tests (urgent)
/dev:run --skip-tests  " Urgent fix " 

 # Skip local full-stack integration verification (Step 7.7, default on)
# 로컬 풀스택(serverpod start, 내장 Postgres) 통합 검증을 건너뜀
/dev:run --skip-local-integration  " Backend-only config tweak " 

 # Skip PM requirements refinement (Step 1.5, default on)
# 이슈를 만들기 전 PM 요구사항 정제 단계를 건너뛰고 Step 1의 키워드 추론만 사용
/dev:run --skip-pm  " Urgent one-liner " 

 # Skip design verification (Step 7.3, default on for screen features) — still requires AskUserQuestion confirmation
/dev:run --skip-design-verify  " Urgent hotfix without a simulator handy " 

 # Explicit design-verification target/tolerance
/dev:run --design-target=android --design-tolerance pixel=1,color_delta_e=2  " 저자 상세 화면 추가 "

# loop/단계 진입 전 1회 — 결과를 capability 맵으로 보관
for tool in melos serverpod dart flutter gh; do
  command -v  " $tool "   > /dev/null 2 > & 1  & &   echo  " $tool: ok "   || echo  " $tool: MISSING " 
 done

# 디자인 검증 도구(Step 7.3 전용) — 아래  " 예외 "   참고, melos/serverpod 등과 취급이 다르다
claude mcp list 2 > /dev/null | grep -Eq  " figma.*connected "   & &   echo  " figma-mcp: ok "   || echo  " figma-mcp: MISSING " 
 command -v maestro  > /dev/null 2 > & 1  & &   echo  " maestro: ok "   || echo  " maestro: MISSING " 
 claude mcp list 2 > /dev/null | grep -Eq  " dart.*connected "   & &   echo  " dart-mcp: ok "   || echo  " dart-mcp: MISSING " 
 flutter devices 2 > /dev/null | grep -Eq  " • "   & &   echo  " device: ok "   || echo  " device: MISSING "

┌─────────────────────────────────────────────────────────────────┐
│                    /dev:run  " 작업 내용 "                           │
├─────────────────────────────────────────────────────────────────┤
│                                                                 │
│  Step 1: 작업 내용 분석                                          │
│  ├── 작업 유형 추론 (feat/fix/chore/refactor)                    │
│  ├── 스코프 추출 (feature명)                                     │
│  ├── 화면 타입 감지 (목록/상세/폼)                                │
│  └── 예상 복잡도 산정 (Story Point)                              │
│                                                                 │
│  Step 1.5: PM 요구사항 정제 ⚠️ (--skip-pm 시 스킵)                │
│  ├── pm-spec-agent 호출                                         │
│  ├── (피그마 링크 있으면) get_design_context/get_screenshot 조회  │
│  ├── LOCKED seed-spec 있으면 우선 정합                           │
│  ├── FR/AC, 스코프 In/Out, Story Point 재산정                    │
│  ├── 명시적 --type/--scope/--point 는 그대로 존중                │
│  └── 애매한 부분은  " 가정 " 으로 명시하고 진행 (되묻지 않고 자동 진행)│
│                                                                 │
│  Step 2: ZenHub 이슈 생성                                        │
│  ├── mcp__zenhub__createGitHubIssue                             │
│  ├── 이슈 타입 자동 설정 (Feature/Task/Bug)                      │
│  ├── 라벨 자동 지정                                              │
│  └── Estimate 설정                                              │
│                                                                 │
│  Step 3: Product Backlog 이동                                   │
│  ├── mcp__zenhub__moveIssueToPipeline                           │
│  └── Pipeline: Product Backlog                                  │
│                                                                 │
│  Step 4: 브랜치 생성 ⚠️ 필수 (계층 브랜치 전략)                    │
│  ├── 부모 이슈 감지 (ZenHub parentIssueId 조회)                  │
│  ├── base 브랜치 결정:                                          │
│  │   ├── Sub-task → Story 브랜치 기반                            │
│  │   ├── Story → Epic 브랜치 기반                                │
│  │   ├── Epic → development 기반                                │
│  │   └── 독립 이슈 → development 기반                            │
│  ├── 부모 브랜치 미존재 시 자동 생성                               │
│  ├── issue-branch-agent 호출 (base_branch 전달)                 │
│  ├── {type}/{number}-{slug} 형식                                │
│  └── ⚠️ development/main에 직접 커밋 금지                        │
│                                                                 │
│  Step 5: In Progress 이동                                       │
│  ├── issue-state-agent 호출                                     │
│  └── Pipeline: In Progress                                      │
│                                                                 │
│  Step 6: BDD 시나리오 작성 (screen feature 시)                          │
│  ├── bdd-scenario-agent 호출                                    │
│  ├── Gherkin Feature 파일 생성                                   │
│  ├── Step Definition 생성                                       │
│  └── 커밋:  " test({scope}): ✅ BDD 시나리오 작성 "                    │
│                                                                 │
│  Step 7: 구현 작업                                               │
│  ├── 이슈 내용 기반 구현                                         │
│  └── 증분 커밋 생성                                              │
│                                                                 │
│  Step 7.2: CoUI 패키지 변경 분리 (on CoUI 수정/확장 필요) ⚠️        │
│  ├── composition ladder 선행 (as-is→style→compose→extend)        │
│  ├── extend 필요 확정 시: CoUI 저장소 별도 이슈/브랜치/PR          │
│  │   (additive · coui_flutter + coui_web 양쪽 · 버전범프)         │
│  ├── CoUI PR 선행 머지 → 프로젝트 의존성 갱신                     │
│  └── ⚠️ 화면 PR diff에 CoUI 소스 변경 포함 금지 (Step 9 게이트)    │
│                                                                 │
│  Step 7.3: 디자인 검증 게이트 (screen feature + Figma 소스 시) ⚠️      │
│  ├── (도구/기기 부재 또는 --skip-design-verify 시 AskUserQuestion 확인)│
│  ├── flutter run -d {target} --print-dtd (백그라운드, 별도 프로세스) │
│  ├── [선택·비차단] marionette:smoke — 조립/반응 여부만 빠르게 확인   │
│  ├── pixel-loop:loop  < figma-url >   --mode=create|repair --route=...  │
│  ├── inspector:visual-verify --mode=regression (읽기전용 최종 판정) │
│  ├── 실패 시 pixel-loop repair 1회 재시도 → 그래도 실패면 사용자 확인│
│  └── ⚠️ 무음 스킵 금지 — PR body에 상태(pass/skip/미해결) 영구 기록  │
│                                                                 │
│  Step 7.5: Backend 코드 생성 (on Backend changes) ⚠️                │
│  ├── melos run backend:pod:generate                             │
│  └── 커밋:  " chore(backend): 🔧 코드 생성 "                          │
│                                                                 │
│  Step 7.7: 로컬 풀스택 통합 검증 (Backend/screen feature 시) ⚠️       │
│  ├── (--skip-local-integration 시 스킵, 기본 on)                  │
│  ├── serverpod start (백엔드+내장 Postgres+앱 풀스택 기동)         │
│  ├── [Backend 변경] dart test -t integration (로컬, Docker 불필요) │
│  ├── [screen feature] 프론트를 로컬 백엔드 대상 통합 스모크         │
│  ├── 마이그레이션/로그 → Serverpod MCP 활용                       │
│  ├── 검증 후 serverpod start 종료                                │
│  ├── (3.x 폴백: docker compose up -d + dart run bin/main.dart)   │
│  └── ⚠️ 게이트 실패 시 Step 8 진행 차단                           │
│                                                                 │
│  Step 8: 테스트 작성 및 검증 (필수 게이트) ⚠️                      │
│  ├── [Phase 8a: 테스트 코드 작성]                                  │
│  │   ├── [프론트엔드 - 필수]                                       │
│  │   │   ├── UseCase 단위 테스트 (unit-test-agent)               │
│  │   │   └── BLoC 단위 테스트 (bloc-test-agent)                  │
│  │   ├── [백엔드 - on Backend changes 필수]                       │
│  │   │   ├── 엔드포인트/서비스 단위 테스트 (serverpod-test-agent) │
│  │   │   └── 엔드포인트 통합 테스트 (serverpod-test-agent)        │
│  │   ├── BDD Widget 테스트 (screen feature 시, bdd_test_gen 활용) │
│  │   └── 커밋:  " test({scope}): ✅ 테스트 작성 "                     │
│  ├── [Phase 8b: PR Preflight 게이트] /pr:preflight --auto-scope  │
│  │   ├── 변경 패키지 자동 감지 (git diff {base}..HEAD)            │
│  │   ├── Unit 레이어 (변경 패키지) — 실패 시 즉시 중단             │
│  │   ├── Widget 레이어 (변경 패키지, BDD widget_test 포함)        │
│  │   └── Integration @smoke (디바이스 있으면 조건부 실행)          │
│  └── ⚠️ 게이트 실패 시 Step 8.3 진행 불가 → PR 생성 차단           │
│     정책: cc-dev-cycle/rules/pr-preflight-policy.md               │
│                                                                 │
│  Step 8.3: BDD Coverage Gate ⚠️ (--skip-bdd 시 스킵)              │
│  ├── .feature 파일 스캔 (현재 feature 범위)                        │
│  ├── Given/When/Then 스텝 파싱                                    │
│  ├── step/ 폴더에서 매칭 step 함수 검증                             │
│  ├── 각 step 함수 내 assertion (expect/verify) 존재 확인            │
│  ├── ⚠️ step_coverage  <   100% 시 PR 생성 차단                      │
│  └── --skip-bdd 시 경고 메시지와 함께 스킵                          │
│                                                                 │
│  Step 8.5: Pre-push 검증 + DCM format/lint 0건 + DCM 품질 개선 ⚠️ 필수│
│  ├── [Phase 1: DCM 포맷팅 + Dart 린트 자동 수정 + 0건 게이트]      │
│  │   ├── melos run format (dcm format — dart format 대체)         │
│  │   ├── dart fix --apply (린트 자동 수정)                         │
│  │   ├── melos run analyze (Dart SDK 분석)                   │
│  │   ├── error/warning/info 잔존 시 수동 수정 (최대 2회 반복)      │
│  │   └── ⚠️ 2회 시도 후에도 이슈 잔존 시 PR 생성 차단              │
│  ├── [Phase 2: DCM 코드 품질 개선]                                 │
│  │   ├── melos run dcm:analyze (DCM 린트 + 메트릭)               │
│  │   ├── melos run dcm:fix (자동 수정 가능 항목 수정)             │
│  │   ├── melos run dcm:unused-code (미사용 코드 검사)           │
│  │   ├── melos run dcm:analyze (수정 후 재검증)                   │
│  │   └── ⚠️ error 심각도 이슈 잔존 시 PR 생성 차단                 │
│  ├── [Phase 3: 최종 린트 검증]                                     │
│  │   ├── melos run analyze (DCM 수정 후 Dart 재확인)         │
│  │   ├── melos run dcm:analyze (DCM 최종 재확인)                  │
│  │   └── ⚠️ 이슈 0건 필수 — 잔존 시 PR 생성 차단                   │
│  └── 검증 실패 시 Step 9 진행 불가                                │
│                                                                 │
│  Step 8.7: Code Review Gate ⚠️ (gstack 패턴)                    │
│  ├── /code-review --quick 자동 실행                              │
│  ├── 2-pass 분석:                                               │
│  │   ├── Pass 1: Critical (차단) - 보안, 데이터 안전성, 레이스컨디션 │
│  │   └── Pass 2: Informational (PR body 포함)                   │
│  ├── Critical 발견 시:                                          │
│  │   ├── 자동 수정 시도 (최대 2회)                                │
│  │   └── 수정 불가 시 PR 생성 차단                                │
│  ├── Informational 항목 → PR description에 자동 포함             │
│  └── --skip-review 시 경고 메시지와 함께 스킵                     │
│                                                                 │
│  Step 9: PR 생성 (검증 게이트 통과 후, 계층 머지)                  │
│  ├── ⚠️ 브랜치 형식 검증 필수                                    │
│  ├── PR base 결정 (계층 브랜치 전략):                             │
│  │   ├── Sub-task → Story 브랜치 (base)                          │
│  │   ├── Story → Epic 브랜치 (base)                              │
│  │   ├── Epic → development (base)                              │
│  │   └── 독립 이슈 → development (base)                          │
│  ├── gh pr create --base {target_branch}                        │
│  ├── Closes #{issue_number} 자동 포함                           │
│  └── ZenHub PR 연결                                             │
│                                                                 │
│  Step 10: Review/QA 이동                                        │
│  ├── mcp__zenhub__moveIssueToPipeline                           │
│  └── Pipeline: Review/QA                                        │
│                                                                 │
│  Step 11: 추가 리뷰 피드백 반영                                   │
│  ├── Step 8.7에서 자동 코드 review complete됨                           │
│  ├── PR 리뷰 코멘트 확인 및 추가 피드백 반영                      │
│  ├── 재검토 필요 시 반복                                         │
│  └── /checklist:feature-complete 실행                           │
│                                                                 │
│  Step 12: 머지 승인 대기 (머지 = Close)                          │
│  ├── user approval 요청                                            │
│  ├── 승인 시 스쿼시 머지                                         │
│  └── GitHub  " Closes # "   키워드로 이슈 자동 Close 시도            │
│                                                                 │
│  Step 12.5: 이슈 Close 검증 + 폴백 ⭐ (ZenHub 2-상태 모델) ⚠️     │
│  ├── GitHub state 확인 (open/closed의 source of truth)           │
│  │   └── 미close 시 gh issue close 로 명시적 종료                 │
│  ├── ZenHub Closed 동기화 확인 (GitHub closed = Closed 1:1)      │
│  │   └── 동기화 지연 시 updateIssue state:CLOSED 강제            │
│  └── PR base 브랜치로 이동 + git pull (최신화) ⭐               │
│                                                                 │
└─────────────────────────────────────────────────────────────────┘

# 현재 브랜치 확인
BRANCH=$(git rev-parse --abbrev-ref HEAD)

# development/main 체크
if [[ $BRANCH ==  " development "   || $BRANCH ==  " main "   ]]; then
  echo  " ❌ development/main에 직접 커밋할 수 없습니다 " 
   echo  "     /dev:run 스킬은 반드시 feature 브랜치에서 작업합니다 " 
   echo  " " 
   echo  "     올바른 사용법: " 
   echo  "     1. /dev:run \ " 작업 내용\ "   - 이슈 생성부터 시작 " 
   echo  "     2. /dev:issue {number} - 기존 이슈로 시작 " 
   exit 1
fi

# ⭐ 이슈번호 포함 검증 (이슈 추적 용이): {type}/{issue_number}-{slug}
#    브랜치 생성 직후 조기 게이트 — 번호 누락을 Step 9(PR 직전)까지 미루지 않고 즉시 차단
if [[ ! $BRANCH =~ ^(epic|story|task|feature|fix|refactor|chore)/[0-9]+- ]]; then
  echo  " ❌ 브랜치명에 이슈번호가 없습니다: $BRANCH " 
   echo  "     형식: {type}/{issue_number}-{slug}  (예: feature/1810-author-list) " 
   echo  "     이슈 추적을 위해 브랜치명에 반드시 이슈번호가 포함돼야 합니다. " 
   echo  "     /dev:run 은 이슈 생성(Step 2) 후 자동으로 번호를 포함해 브랜치를 만듭니다. " 
   exit 1
fi

// 단계 전제조건 검증
async function validateStepPrerequisites(stepNumber: number) {
  const todos = await getTodoList();

  // 이전 단계들이 모두 completed인지 확인
  for (let i = 1; i  <   stepNumber; i++) {
    const step = todos.find(t = >   t.content.startsWith(`Step ${i}`));
    if (step?.status !==  " completed "   & &   step?.status !==  " skipped " ) {
      throw new Error(`
        ❌ Step ${i}이(가) 완료되지 않았습니다.
        현재 상태: ${step?.status ||  ' unknown ' }

        먼저 Step ${i}을(를) 완료해주세요.
      `);
    }
  }
}

// 키워드 기반 타입 자동 추론
const typeKeywords = {
  feat: [ " 추가 " ,  " 구현 " ,  " 생성 " ,  " 만들기 " ,  " 화면 " ],
  fix: [ " 수정 " ,  " 고치기 " ,  " 버그 " ,  " 에러 " ,  " 문제 " ],
  refactor: [ " 개선 " ,  " 리팩토링 " ,  " 정리 " ,  " 최적화 " ],
  chore: [ " 설정 " ,  " 빌드 " ,  " 환경 " ,  " 배포 " ],
  docs: [ " 문서 " ,  " README " ,  " 주석 " ],
  test: [ " 테스트 " ,  " test " ,  " 검증 " ],
};

// 화면 타입 감지
const screenKeywords = {
  list: [ " 목록 " ,  " 리스트 " ,  " list " ,  " 조회 " ,  " 검색 " ],
  detail: [ " 상세 " ,  " detail " ,  " 보기 " ],
  form: [ " 추가 " ,  " 생성 " ,  " 수정 " ,  " 편집 " ,  " form " ,  " 등록 " ],
};

const analysis = {
  type: inferType(workContent),      // feat/fix/refactor...
  scope: extractScope(workContent),  // feature명
  screenType: detectScreen(workContent), // list/detail/form/null
  point: estimatePoint(workContent), // 1/3/5/8
  requiresBdd: screenType !== null,  // screen feature이면 true
};

if (!options.skipPm) {
  // work_content에서 URL 추출 (피그마 등)
  const figmaUrl = extractFigmaUrl(workContent);

  // 기존 확정(LOCKED) 기획 명세가 있으면 우선 사용
  const lockedSeedSpec = await findLockedSeedSpec(analysis.scope); // docs/seed-spec-*.md

  let pmSpec;
  try {
    pmSpec = await Task({
      subagent_type:  " pm-spec-agent " ,
      prompt: `
        work_content: ${workContent}
        initial_analysis: ${JSON.stringify(analysis)}
        explicit_options: ${JSON.stringify({ type: options.type, scope: options.scope, point: options.point })}
        figma_url: ${figmaUrl ??  " none " }
        locked_seed_spec: ${lockedSeedSpec ??  " none " }

        이 작업 요청을 PM 관점(FR/AC, 스코프 In/Out, Fibonacci Story Point)으로 정리해줘.
        애매한 부분은 묻지 말고 합리적으로 가정한 뒤  " Assumptions " 에 명시하고 진행해.
      `,
    });
  } catch (e) {
    console.warn( " ⚠️ PM 요구사항 정제 실패 — Step 1 키워드 추론 결과로 폴백: " , e?.message ?? e);
    pmSpec = null; // degrade, don ' t throw (GD-01과 동일한 계약)
  }

  if (pmSpec) {
    // 명시적 옵션은 그대로 유지, 나머지는 pmSpec으로 승격
    analysis.type = options.type ?? pmSpec.type;
    analysis.scope = options.scope ?? pmSpec.scope;
    analysis.point = options.point ?? pmSpec.point;
    analysis.requiresBdd = pmSpec.screenTypes.length  >   0;
    analysis.issueBody = pmSpec.body; // Step 2가 그대로 사용
  }
} else {
  console.warn( " ⚠️ PM 요구사항 정제를 건너뜁니다 (--skip-pm) " );
}

// 이슈 타입 매핑
const issueTypeMap = {
  feat:  " Feature " ,
  fix:  " Bug " ,
  refactor:  " Task " ,
  chore:  " Task " ,
  docs:  " Task " ,
  test:  " Task " ,
};

// GitHub 이슈 생성
// analysis.issueBody는 Step 1.5(pm-spec-agent)가 채운 PM 정제본 — --skip-pm 이거나 정제 실패 시 폴백
const issue = await mcp__zenhub__createGitHubIssue({
  repositoryId: githubRepoId,
  title: `${gitmoji} ${analysis.scope}: ${workContent}`,
  body: analysis.issueBody ?? generateIssueBody(workContent, analysis),
  issueTypeId: getIssueTypeId(issueTypeMap[analysis.type]),
  labels: generateLabels(analysis),
});

// Estimate 설정
await mcp__zenhub__setIssueEstimate({
  issueId: issue.id,
  estimate: analysis.point,
});

// 읽기 전용: 생성된 이슈가 Jira에서도 조회되는지 확인 (예: GitHub 이슈 번호로 검색)
// ⛔ createJiraIssue / editJiraIssue / transitionJiraIssue 금지 — 조회 도구만 사용
try {
  const found = await mcp__atlassian__searchJiraIssuesUsingJql({
    jql: `text ~  " #${issue.number} "   ORDER BY created DESC`,
    maxResults: 5,
  });
  if (found?.issues?.length) {
    console.log(`🔎 Jira 확인: ${found.issues.map(i = >   i.key).join( " ,  " )}`);
  } else {
    console.log( " 🔎 Jira 확인: 매칭 이슈 없음 (읽기 전용 확인, 워크플로 계속) " );
  }
} catch (e) {
  console.warn( " 🔎 Jira 조회 건너뜀 (읽기 전용, non-blocking): " , e?.message ?? e);
}

// ── 파이프라인 ID 일괄 해석 (fail-closed) ─────────────────────────
// ⚠️ 과거엔 productBacklogPipelineId/inProgressPipelineId/reviewQaPipelineId 가
//    어디에서도 해석되지 않아 move 가 pipelineId=undefined 로 silent no-op 였다(C3).
//    이름이 라이브 파이프라인과 다르면 throw — 무음 누락 금지.
const workspace = await mcp__zenhub__getWorkspacePipelinesAndRepositories();
const pipelineId = (name) = >   {
  const p = workspace.pipelines.find(p = >   p.name === name);
  if (!p) throw new Error(`파이프라인  ' ${name} '   없음. 라이브: ${workspace.pipelines.map(p = >   p.name).join( " ,  " )}`);
  return p.id;
};
const productBacklogPipelineId = pipelineId( " Product Backlog " );
const inProgressPipelineId     = pipelineId( " In Progress " );
const reviewQaPipelineId       = pipelineId( " Review/QA " );

// Product Backlog 이동
await mcp__zenhub__moveIssueToPipeline({
  issueId: issue.id,
  pipelineId: productBacklogPipelineId,
});

// ── Step 2.5: 스프린트 배정 (타임라인 가시성) ─────────────────────
// 저수준 타입(Feature/Bug/Task)은 setDatesForIssue(상위 타입 전용)를 쓰지 않고
// 활성 스프린트에 넣어 로드맵/번다운에 노출한다. 기본 on, --no-sprint 로 opt-out.
if (!options.noSprint) {
  // --sprint 셀렉터: next → 다음(getUpcomingSprint), 그 외(기본 current) → 활성(getSprint)
  const sprint = options.sprint ===  " next " 
     ? await mcp__zenhub__getUpcomingSprint()
    : await mcp__zenhub__getSprint();            // id 없음 = 활성 스프린트
  if (sprint?.id) {
    await mcp__zenhub__addIssuesToSprints({ issueIds: [issue.id], sprintIds: [sprint.id] });
    console.log(`📅 스프린트 배정: ${sprint.name ?? sprint.id}`);
  } else {
    console.warn( " ⚠️ 활성 스프린트 없음 — 스프린트 미배정(로드맵 비가시 가능) " );
  }
}

// ═══════════════════════════════════════════════════════════
// Step 4: 계층 브랜치 전략 - base 브랜치 동적 결정
// ═══════════════════════════════════════════════════════════

// 4-1. 부모 이슈 감지
let baseBranch = options.base ||  " development " ;
let parentIssue = null;

if (!options.base) {
  // ⚠️ ZenHub MCP 에는 id 로 단건 이슈를 가져오는 도구가 없다(getIssue/getChildrenOfParent 미존재).
  //    이슈와 그 부모는 searchLatestIssues 의 nested parentIssue 로 조회한다.
  const issueDetails = await mcp__zenhub__searchLatestIssues({
    query: `#${issue.number}`,
  });
  const self = issueDetails.find(i = >   i.number === issue.number);
  parentIssue = self?.parentIssue ?? null;   // { id, number, title, issueType }

  if (parentIssue) {
    // 부모 브랜치를 확보(없으면 조부모 기반으로 재귀 생성)하고 그 위에서 분기한다.
    // resolveBaseBranch 가 searchLatestIssues 로 계층을 거슬러 올라가며 브랜치를 보장한다.
    baseBranch = await resolveBaseBranch(parentIssue.number);
    console.log(`📐 계층 브랜치: ${baseBranch} 기반으로 분기`);
  }
}

// 4-4. 브랜치 생성 (base 브랜치에서 분기)
await Task({
  subagent_type:  " issue-branch-agent " ,
  prompt: `이슈 #${issue.number} 브랜치 생성 (base: ${baseBranch})`,
  // base_branch 파라미터 전달
});

// In Progress 이동
await mcp__zenhub__moveIssueToPipeline({
  issueId: issue.id,
  pipelineId: inProgressPipelineId,
});

// 재귀적 base 브랜치 결정
async function resolveBaseBranch(issueNumber: number): Promise < string >   {
  // ⚠️ getIssue 미존재 → searchLatestIssues 로 이슈 + nested parentIssue 조회
  const _found = await mcp__zenhub__searchLatestIssues({ query: `#${issueNumber}` });
  const issue = _found.find(i = >   i.number === issueNumber);
  if (!issue) throw new Error(`이슈 #${issueNumber} 조회 실패 — base 브랜치 해석 불가`);
  // 계층 브랜치 prefix (branch-hierarchy 스킬 기준):
  //   Epic → epic/ · Sub-task → task/ · parent 있는 Feature/Bug/Task(=Story) → story/
  //   parent 없는 단독 이슈 → 기존 feature/ (기존 동작 유지, 이 함수는 계층 케이스 전용)
  const branchPrefix =
    issue.issueType ===  " Epic "   ?  " epic "   :
    issue.issueType ===  " Sub-task "   ?  " task "   :
    issue.parentIssue ?  " story "   :
     " feature " ;
  // createSlug romanizes non-ASCII and never returns  ' '   (see issue-branch-agent.md). Pass type word for the empty-guard fallback.
  const slug = createSlug(issue.title, branchPrefix);
  const branchName = `${branchPrefix}/${issue.number}-${slug}`;
  // Defense-in-depth (LANG-05): a non-romanized Korean-only title must not yield  " feature/25- " .
  if (!slug || branchName.endsWith( " - " )) throw new Error(`빈 slug — 브랜치명 비정상(${branchName}). 제목 로마자 변환 확인 필요`);

  // 브랜치 존재 확인
  const exists = await Bash(
    `git rev-parse --verify origin/${branchName} 2 > /dev/null  & &   echo  " exists "   || echo  " missing " `
  );

  if (exists.trim() ===  " exists " ) {
    return branchName;
  }

  // 부모가 있으면 재귀, 없으면 development
  if (issue.parentIssue?.number) {
    const parentBranch = await resolveBaseBranch(issue.parentIssue.number);
    await Bash(`
      git checkout ${parentBranch}  & &   git pull origin ${parentBranch}
      git checkout -b ${branchName}
      git push -u origin ${branchName}
    `);
    return branchName;
  }

  // 최상위 → development 기반
  await Bash(`
    git checkout development  & &   git pull origin development
    git checkout -b ${branchName}
    git push -u origin ${branchName}
  `);
  return branchName;
}

if (analysis.requiresBdd  & &   !options.skipBdd) {
  // ⚠️ bdd-scenario-agent 는 cc-flutter-dev 가 제공하는 cross-plugin 선택 의존이다(F3).
  //    미설치면 throw 하지 말고 BDD 단계를 skip + 경고하라(미존재 dispatch 를 PASS 로 간주 금지):
  //    if (!isAgentAvailable( " bdd-scenario-agent " )) { console.warn( " ⚠️ BDD skip — cc-flutter-dev 미설치 " ); /* skip BDD */ }
  await Task({
    subagent_type:  " bdd-scenario-agent " ,
    prompt: `
      feature_name: ${analysis.scope}
      screen_type: ${analysis.screenType}

      화면 타입에 맞는 BDD 시나리오를 생성해주세요.
    `,
  });

  // 커밋
  await Bash(`
    git add .
    git commit -m  " test(${analysis.scope}): ✅ BDD 시나리오 작성

    - ${analysis.screenType} 화면 시나리오 추가
    - Step Definition 생성

    Co-Authored-By: Claude  < noreply@anthropic.com > " 
   `);
}

사전 확인 (Step 7 시작 전):
1. CLAUDE_CODE_EXPERIMENTAL_AGENT_TEAMS 환경변수 확인
2. teams_available = true → 병렬 모드 진입
3. teams_available = false → 순차 실행 (아래  " 순차 실행 흐름 "   섹션)
4. 병렬 모드 진입 시 사용자에게 팀 구성 계획 출력 후 승인 요청

Agent Teams 사용 가능 시:
  ├─ Teammate 1: Backend 구현
  │   ├─ Serverpod model 정의
  │   ├─ Endpoint 구현
  │   ├─ Service 로직
  │   └─ melos run backend:pod:generate
  │
  └─ Teammate 2: Frontend 구현
      ├─ Domain Layer (Entity, UseCase, Repository 인터페이스)
      ├─ Data Layer (Repository 구현, DataSource)
      └─ Presentation Layer (BLoC, Page, Widget)

  → 완료 후 Lead가 통합 검증:
    - 프론트/백엔드 인터페이스 일치 확인
    - Import 참조 정합성 확인

Fallback (순차):
  Backend → Frontend 순차 실행

Agent Teams 사용 가능 시:
  ├─ Teammate 1: Frontend Unit + BLoC 테스트
  │   ├─ UseCase 단위 테스트 (unit-test-agent)
  │   └─ BLoC 단위 테스트 (bloc-test-agent)
  │
  ├─ Teammate 2: Backend Unit + Integration 테스트
  │   ├─ 엔드포인트 단위 테스트 (serverpod-test-agent)
  │   ├─ 서비스 로직 단위 테스트
  │   └─ 엔드포인트 통합 테스트
  │
  └─ Teammate 3: BDD Widget 테스트 (screen feature 시)
      ├─ Gherkin 시나리오 검증
      └─ Step Definition 실행

  → 완료 후 Lead가 결과 병합:
    - 전체 tests passed 여부 집계
    - 실패 시 PR 생성 차단

Fallback (순차):
  Unit → BLoC → Backend → BDD 순차 실행

// 구현 작업
await Task({
  subagent_type:  " implementation-agent " ,
  prompt: `이슈 #${issue.number} 구현`,
});

// Backend 변경 감지
const hasBackendChanges = detectBackendChanges(issue);

// 테스트 작성 및 검증 (필수 게이트) ⚠️
if (!options.skipTests) {
  const testTypes = [ " unit " ,  " bloc " ];
  if (analysis.requiresBdd) testTypes.push( " bdd " );
  if (hasBackendChanges) testTypes.push( " backend_unit " ,  " backend_integration " );

  // ──────────────────────────────────────────────────
  // Phase 1: 테스트 플랜 작성
  // ──────────────────────────────────────────────────
  // PR의 Test Plan 항목을 먼저 정의 — 구현 코드의 핵심 동작 시나리오
  const testPlan = generateTestPlan({
    workContent,
    scope: analysis.scope,
    testTypes,
    hasBackendChanges,
    requiresBdd: analysis.requiresBdd,
  });

  // ──────────────────────────────────────────────────
  // Phase 2: 테스트 플랜 기반 테스트 코드 작성
  // ──────────────────────────────────────────────────
  await Task({
    subagent_type:  " test-runner-agent " ,
    prompt: `
      feature_name: ${analysis.scope}
      test_types: ${JSON.stringify(testTypes)}
      test_plan: ${JSON.stringify(testPlan)}
      auto_fix: true
      require_tests: true
      write_tests_for_plan: true
    `,
  });

  // ──────────────────────────────────────────────────
  // Phase 3: 테스트 실행 및 결과 수집
  // ──────────────────────────────────────────────────
  // 3-1. 정적 분석 (dart analyze) — 테스트 코드 컴파일 검증
  // FO-10: 파이프 `| grep -c` 는 grep 의 exit code 만 남겨 dart analyze 의 실패(미설치/크래시)를
  //   0( " clean " )으로 가린다. analyze 를 직접 실행해 exit code 로 판정하고,
  //   명령 미실행/비정상 종료는 0 이 아니라 명시 FAIL 로 둔다(검증 불가 ≠ 통과).
  const analyzeRaw = await Bash(
    `dart analyze ${testPlan.map(t = >   t.file).join( '   ' )} 2 > & 1`
  );
  if (analyzeRaw.exitCode === 127 /* command not found */) {
    throw new Error( " dart analyze 실행 실패(도구/스크립트 부재) — 검증 불가 = 차단 (Step 0 도구 점검 참조) " );
  }
  // dart analyze: exit 0 = 이슈 없음, 그 외 = 이슈 존재(또는 실행 오류 → 차단)
  const analyzeErrors = analyzeRaw.exitCode === 0
    ? 0
    : ((analyzeRaw.stdout.match(/^\s*error\b/gim) || []).length || 1);

  // 3-2. 테스트 실행 (정적 분석 통과 시)
  let testResults = { totalPassed: 0, totalFailed: 0, items: [] };
  if (analyzeErrors === 0) {
    const testOutput = await Bash(
      `flutter test ${testPlan.map(t = >   t.file).filter(Boolean).join( '   ' )} 2 > & 1`
    );
    testResults = parseTestOutput(testOutput.stdout);
  }

  // ──────────────────────────────────────────────────
  // Phase 4: 결과를 PR Test Plan에 반영
  // ──────────────────────────────────────────────────
  prBodyExtras.testPlanResults = testPlan.map(item = >   ({
    ...item,
    analyzePass: analyzeErrors === 0,
    testPass: testResults.items.find(r = >   r.name === item.item)?.passed ?? null,
  }));
  prBodyExtras.testSummary = {
    analyzeErrors,
    totalPassed: testResults.totalPassed,
    totalFailed: testResults.totalFailed,
  };

  // ⚠️ 게이트: 정적 분석 실패 시 PR 생성 차단
  if (analyzeErrors  >   0) {
    throw new Error(`테스트 코드 정적 분석 실패 (${analyzeErrors}건) - 에러 수정 후 재시도`);
  }
  // ⚠️ 게이트: 테스트 실패 시 PR 생성 차단 (런타임 실행 가능했던 경우)
  if (testResults.totalFailed  >   0) {
    throw new Error(`테스트 ${testResults.totalFailed}건 실패 - 수정 후 재시도`);
  }
  // ⚠️ 게이트(FO-04): 실행되지 않은(미검증) 테스트는 PASS 로 간주하지 않는다.
  //   testPass === null 은  " 실패 아님 " 이 아니라  " 검증 안 됨 "   → 차단 상태.
  const unverified = prBodyExtras.testPlanResults.filter(r = >   r.testPass === null);
  if (unverified.length  >   0) {
    throw new Error(`테스트 미실행 ${unverified.length}건 — 검증되지 않은 항목은 PASS 로 간주하지 않음(차단)`);
  }
} else {
  // --skip-tests 사용 시 사용자 확인 필수
  const confirm = await AskUserQuestion({
    questions: [{
      header:  " 테스트 스킵 확인 " ,
      question:  " 테스트를 스킵하면 검증 없이 PR이 생성됩니다. 계속하시겠습니까? " ,
      options: [
        { label:  " 스킵 확인 " , description:  " 테스트 없이 진행 (긴급 핫픽스용) "   },
        { label:  " 테스트 실행 " , description:  " 테스트를 실행합니다 "   },
      ],
    }],
  });
}

1. CoUI 컴포넌트 as-is 사용                    → 해결되면 Step 7.2 불필요
2. Core < X > Style / typed param 오버라이드        → 해결되면 Step 7.2 불필요
3. Composition (CoUI behavior + 커스텀 content) → 해결되면 Step 7.2 불필요 (프로젝트 내 해결)
4. CoUI 확장 필요 확정                          → Step 7.2 진입 ⚠️

// Step 7 구현 중 CoUI 확장 필요 감지 시
if (needsCouiExtension) {
  // 1. 화면 작업 일시 정지 — composition으로 진행 가능한 부분은 계속
  //    (CoUI 신규 capability에 막힌 부분만 보류)

  // 2. CoUI 저장소(coco-de/coui)에서 별도 dev 사이클 실행
  //    - 별도 이슈/브랜치/PR (화면 이슈와 상호 링크)
  //    - additive · backward-compatible 확장만 (기존 기본값/동작 보존)
  //    - ⚠️ coui_core 계약 + coui_flutter + coui_web 양쪽 모두 반영 (한쪽만 금지)
  //    - Widgetbook use-case + minor 버전 범프 + CHANGELOG

  // 3. CoUI PR 선행 머지 (CoUI 저장소 자체 게이트/리뷰 통과)

  // 4. 프로젝트로 복귀: CoUI 의존성 갱신 후 화면 조립 재개
  //    - pubspec 버전 범프 / vendored copy 갱신 / submodule 포인터 업데이트
  //    - 커밋:  " chore(deps): 🔧 coui 버전 범프 (vX.Y.Z) " 
   //    - 이후 화면 브랜치에서 컴포넌트 조립(assembly)만 계속
}

# 화면 PR diff에 CoUI 패키지 소스 변경이 포함되면 PR 생성 차단
COUI_TOUCHED=$(git diff --name-only ${BASE_BRANCH}..HEAD | grep -E  ' (^|/)(packages/)?coui(_flutter|_web|_core)?/ '   || true)
if [ -n  " $COUI_TOUCHED "   ]; then
  echo  " ❌ 화면 PR에 CoUI 소스 변경 포함 — Step 7.2 절차로 CoUI 저장소 별도 PR로 분리하세요 " 
   echo  " $COUI_TOUCHED " 
   exit 1
fi
# 허용: pubspec.yaml/lockfile 버전 범프, submodule 포인터 커밋 (의존성 반영)

// ══════════════════════════════════════════════════════════
// Step 7.3: 디자인 검증 게이트 (Figma ↔ 실기기/시뮬레이터)
// ══════════════════════════════════════════════════════════
const figmaDocPath = `.claude/docs/${analysis.scope}/figma_analysis.md`;
const figmaDocExists = (await Bash(`test -f  " ${figmaDocPath} "   & &   echo yes || echo no`)).trim() ===  " yes " ;
const hasDesignSource = analysis.requiresBdd  & &   figmaDocExists;

if (!hasDesignSource) {
  console.log( " ℹ️ Step 7.3 skip — screen feature 아님 또는 Figma 소스 없음 (대조 대상 없음) " );
} else if (analysis.platform ===  " web " ) {
  // Maestro는 Flutter Web 미지원 — cc-flutter-dev:figma:analyze 의 Playwright 폴백 경로 안내
  console.warn( " ⚠️ Flutter Web 대상 — pixel-loop/visual-verify 미지원. Playwright 폴백은 /figma:analyze 참고 " );
  prBodyExtras.designVerification = { status:  " skipped " , reason:  " flutter-web (see /figma:analyze Playwright fallback) "   };
} else {
  // ── 1. 도구/기기 가용성 확인 (Step 0 capability map 확장분 참조) ──
  // ⚠️ Step 0의  " 미설치→degrade+경고(무음) "   기본 계약의 예외: 여기서는 무음 스킵 금지.
  const designToolingOk =
    capabilityMap.figmaMcp  & &   capabilityMap.maestro  & &   capabilityMap.dartMcp  & &   capabilityMap.device;

  if (!designToolingOk || options.skipDesignVerify) {
    const confirm = await AskUserQuestion({
      questions: [{
        header:  " 디자인 검증 스킵 확인 " ,
        question: !designToolingOk
          ?  " figma/maestro/dart MCP 또는 시뮬레이터·기기가 준비되지 않았습니다. 디자인 검증 없이 진행할까요? " 
           :  " 화면 실기기 검증 없이 진행하면 디자인 드리프트가 PR에 그대로 실릴 수 있습니다. 계속할까요? " ,
        options: [
          { label:  " 스킵 확인 " , description:  " 디자이너 수동 확인 필요 — PR에 경고 영구 기록 "   },
          { label:  " 검증 실행 " , description:  " 지금 도구를 갖추고 검증을 실행합니다 "   },
        ],
      }],
    });
    if (confirm !==  " 검증 실행 " ) {
      console.warn( " ⚠️ Step 7.3 스킵 확인됨 — PR body에  ' 디자인 검증 미실행 '   경고 기록 " );
      prBodyExtras.designVerification = {
        status:  " skipped " ,
        reason: !designToolingOk ?  " tooling/device unavailable "   :  " --skip-design-verify (user confirmed) " ,
      };
    }
  }

  if (!prBodyExtras.designVerification) {
    // ── 2. 앱 기동 — 별도 프로세스 (Step 7.7의 serverpod 로컬 앱과 공유하지 않음, 7.3이 7.7보다 먼저 실행) ──
    const target = options.designTarget ||  " auto " ;
    const boot = await Bash(`flutter run -d ${target} --print-dtd 2 > & 1  & `, { run_in_background: true });
    const dtdUri = extractDtdUri(boot.stdout); //  " ws://127.0.0.1:PORT/token "   패턴 파싱

    const figmaUrl = extractFigmaUrl(await Read(figmaDocPath)); // pixel-loop-handoff 와 동일 추출 규칙, 재구현 금지
    const resolvedRoute = resolveRouteForScope(analysis.scope);  // lib/router.dart TypedRoute 또는 *_route.dart 매칭
    const mode = isReworkPass ?  " repair "   :  " create " ;
    const tolerance =
      options.designTolerance || (mode ===  " create "   ?  " pixel=2,color_delta_e=3 "   :  " pixel=1,color_delta_e=2 " );

    // ── 3. (선택·비차단) Marionette 스모크 —  " 보이지만 안 눌리는 "   버그를 조기 포착 ──
    await Skill({ skill:  " cc-flutter-marionette:marionette:smoke " , args: `--routes=${resolvedRoute}` })
      .catch(e = >   console.warn(`⚠️ marionette smoke 실패(informational, 비차단): ${e?.message ?? e}`));

    // ── 4. pixel-loop — 실제 저작/수렴 (코드를 고침) ──
    await Skill({
      skill:  " cc-flutter-pixel-loop:pixel-loop:loop " ,
      args: `${figmaUrl} --mode=${mode} --route=${resolvedRoute} --target=${target} --tolerance ${tolerance}`,
    });

    // ── 5. visual-verify — 읽기 전용 최종 판정 (이 화면이 건드린 모든 라우트) ──
    let verify = await Skill({
      skill:  " cc-flutter-inspector:visual-verify " ,
      args: `--figma=${figmaUrl} --routes=${touchedRoutesForScope(analysis.scope).join( " , " )} --mode=regression --target=${target} --tolerance ${tolerance}`,
    });

    if (!verify.pass) {
      // 1회 repair 재시도 (pixel-loop 자체 진동-감지와 별개로, 여기서도 무음 통과는 금지)
      await Skill({
        skill:  " cc-flutter-pixel-loop:pixel-loop:loop " ,
        args: `${figmaUrl} --mode=repair --route=${resolvedRoute} --target=${target} --tolerance ${tolerance}`,
      });
      verify = await Skill({
        skill:  " cc-flutter-inspector:visual-verify " ,
        args: `--figma=${figmaUrl} --routes=${touchedRoutesForScope(analysis.scope).join( " , " )} --mode=regression --target=${target} --tolerance ${tolerance}`,
      });
    }

    await Bash(`kill %1 2 > /dev/null || true`); // flutter run 프로세스 종료

    if (!verify.pass) {
      // ⚠️ FO-04와 동일 원칙: 미해결 diff를 무음으로 통과시키지 않는다
      const decision = await AskUserQuestion({
        questions: [{
          header:  " 디자인 검증 실패 " ,
          question: `재시도 후에도 디자인 불일치가 남아 있습니다(${verify.diffCount}건). 어떻게 할까요?`,
          options: [
            { label:  " Step 7로 복귀 " , description:  " 코드를 더 고친 후 재시도 (권장) "   },
            { label:  " 그대로 진행 " , description:  " 디자이너 수동 확인 필요 — PR에 미해결로 기록 "   },
          ],
        }],
      });
      if (decision !==  " 그대로 진행 " ) {
        throw new Error(`디자인 검증 실패 — 잔존 diff ${verify.diffCount}건, Step 7 재작업 필요`);
      }
      prBodyExtras.designVerification = { status:  " fail-acknowledged " , tolerance, target, ...verify };
    } else {
      prBodyExtras.designVerification = { status:  " pass " , tolerance, target, ...verify };
    }
  }
}

console.log(`✅ Step 7.3 complete — ${prBodyExtras.designVerification?.status ??  " not-applicable " }`);

// ══════════════════════════════════════════════════════════
// Step 7.7: 로컬 풀스택 통합 검증
// ══════════════════════════════════════════════════════════
// Serverpod 4 (tech preview):  ' serverpod start '   하나로 백엔드 서버 +
//   내장 Postgres + Flutter 앱을 함께 기동. Docker/docker-compose 불필요.
//   재컴파일·재시작 없이 서버·DB·웹·앱 전체 stateful 핫리로드.
//   (kobic 프로덕션은 3.x — 아래 3.x 폴백 경로 참조)

const needsLocalIntegration = hasBackendChanges || analysis.requiresBdd;

if (needsLocalIntegration  & &   !options.skipLocalIntegration) {
  // 7.7-1. 로컬 풀스택 기동 (백그라운드)
  //   Serverpod 4: 내장 Postgres 포함 → 완전 로컬, Docker 불필요
  //   핫리로드가 막히면  ' serverpod start '   터미널에서 R 키로 서버+앱 강제 재시작
  await Bash(`serverpod start`, { run_in_background: true });
  // → 서버 부팅 대기 (http://localhost:8080/ 헬스 확인)

  // ── 3.x / legacy 폴백 (로컬 불가 / nightly) ──────────────
  //   v3 경로는 그대로 보존:
  //     docker compose up -d        # Postgres 등 의존 서비스 기동
  //     dart run bin/main.dart      # 백엔드 서버 기동
  //   Staging 백엔드는 로컬 풀스택 불가 시 폴백으로 사용.

  let localIntegrationPass = true;

  // 7.7-2. [Backend 변경 시] 로컬 통합 테스트
  //   withServerpod 헬퍼 +  ' dart test -t integration '   (v3와 동일 API).
  //   Serverpod 4 내장 Postgres 덕분에 Docker 없이 완전 로컬 실행.
  if (hasBackendChanges) {
    const integrationOut = await Bash(`dart test -t integration 2 > & 1`);
    const integrationResult = parseTestOutput(integrationOut.stdout);
    if (integrationResult.totalFailed  >   0) localIntegrationPass = false;
    prBodyExtras.localIntegration = integrationResult;
  }

  // 7.7-3. [screen feature 시] 프론트를 로컬 백엔드 대상으로 통합 스모크
  //   앱은 dev flavor에서 로컬 서버(http://localhost:8080/)로 연결.
  //   Staging은 폴백. 앱의 기존 client/OpenApiService/flavor 설정에 맞춤
  //   — base-URL 하드코딩 금지.
  if (analysis.requiresBdd) {
    const smokeOut = await Bash(
      `flutter test integration_test --dart-define=flavor=dev 2 > & 1`
    );
    const smokeResult = parseTestOutput(smokeOut.stdout);
    if (smokeResult.totalFailed  >   0) localIntegrationPass = false;
    prBodyExtras.localSmoke = smokeResult;
  }

  // 7.7-4. 마이그레이션 / 서버 로그는 Serverpod MCP 활용
  //   Serverpod MCP 서버(번들)로 실행 중 로컬 서버에 연결 →
  //   DB 마이그레이션 생성·적용, 서버 로그 읽기, 앱 구동+스크린샷 검토.
  //   (tool ID는 preview라 변동 가능 — 능력 기준으로 사용. serverpod-mcp-guide 참조)

  // 7.7-5. 검증 후 로컬 풀스택 종료
  //    ' serverpod start '   프로세스 종료 (3.x 폴백 시 docker compose down)
  await stopLocalFullstack();

  // ⚠️ 게이트: 로컬 통합 검증 실패 시 Step 8 진행 차단
  if (!localIntegrationPass) {
    throw new Error(
       " 로컬 풀스택 통합 검증 실패 - 수정 후 재시도  "   +
       " (또는 --skip-local-integration 으로 스킵) " 
     );
  }
  console.log(`✅ Step 7.7 complete — 로컬 풀스택 통합 검증 PASS`);
} else if (options.skipLocalIntegration) {
  console.warn(`⚠️ 로컬 풀스택 통합 검증 스킵 (--skip-local-integration)`);
} else {
  console.log(`ℹ️ Step 7.7 skip — Backend 변경/screen feature 아님`);
}

// ══════════════════════════════════════════════════════════
// Step 8.3: BDD Coverage Gate
// ══════════════════════════════════════════════════════════
// .feature 파일의 모든 Gherkin step이 구현된 step 함수를 갖고 있는지 검증
// step 함수에 assertion이 포함되어 있는지 검증

if (!options.skipBdd) {
  // 1. .feature 파일 스캔 (현재 feature 범위)
  const featureDir = findFeatureTestDir(scope); // test/src/bdd/ 하위
  const featureFiles = await Glob(`${featureDir}/**/*.feature`);

  if (featureFiles.length === 0) {
    // FO-03: screen feature(BDD 필수)인데 .feature 가 0개면  " 스킵 " 이 아니라 FAIL — 검증 불가 ≠ 통과.
    if (analysis.requiresBdd) {
      throw new Error(`BDD Coverage Gate failed: screen feature 인데 .feature 파일이 0개 (검증 불가 ≠ 통과). /bdd:generate ${scope} 로 작성`);
    }
    console.warn(`⚠️ .feature 파일 없음 (${featureDir}) — BDD 비대상 scope, gate not-applicable`);
  } else {
    // 2. Given/When/Then 스텝 파싱
    const allSteps = [];
    for (const file of featureFiles) {
      const content = await Read(file);
      const steps = content.match(/^\s*(Given|When|Then|And|But)\s+(.+)$/gm) || [];
      for (const step of steps) {
        const keyword = step.match(/^\s*(Given|When|Then|And|But)/)[1];
        const pattern = step
          .replace(/^\s*(Given|When|Then|And|But)\s+/,  ' ' )
          .replace(/#.*$/,  ' ' )  // 한글 주석 제거
          .trim();
        allSteps.push({ file, keyword, pattern });
      }
    }

    // 3. step/ 폴더에서 매칭 step 함수 검증
    const stepDir = `${featureDir}/step`;
    const stepFiles = await Glob(`${stepDir}/**/*.dart`);
    const stepContents = {};
    for (const f of stepFiles) {
      stepContents[f] = await Read(f);
    }
    const allStepCode = Object.values(stepContents).join( ' \n ' );

    // step 패턴 → camelCase 함수명 변환 후 존재 여부 확인
    const missingSteps = allSteps.filter(step = >   {
      const funcName = stepPatternToFunctionName(step.pattern);
      return !allStepCode.includes(funcName);
    });

    // FO-03: BDD 필수 scope 에서 step 0개는  " 100% 커버리지 " 가 아니라 FAIL(검증할 게 없음 ≠ 통과).
    const stepCoverage = allSteps.length  >   0
      ? (allSteps.length - missingSteps.length) / allSteps.length
      : (analysis.requiresBdd ? 0.0 : 1.0);

    // 4. 각 step 함수 내 assertion 존재 확인
    const filesWithoutAssertions = stepFiles.filter(f = >   {
      const content = stepContents[f];
      // UnimplementedError는 stub → assertion 미구현으로 간주
      if (content.includes( ' UnimplementedError ' )) return true;
      // expect, verify, expectVisible, expectTextVisible 등 확인
      return !content.match(/expect\(|verify\(|expectVisible|expectTextVisible|expectAsync/);
    });

    // 5. Gate 판정
    if (stepCoverage  <   1.0) {
      console.error(`❌ BDD step coverage: ${(stepCoverage * 100).toFixed(1)}% (required: 100%)`);
      missingSteps.forEach(s = > 
         console.error(`   Missing: ${s.keyword} ${s.pattern} (${s.file})`)
      );
      console.error(`\n   💡 step 함수 생성: /bdd:generate ${scope} --only-steps true`);
      throw new Error(`BDD Coverage Gate failed: step_coverage=${(stepCoverage * 100).toFixed(1)}%`);
    }

    if (filesWithoutAssertions.length  >   0) {
      console.error(`❌ Assertion 없는 step 파일 ${filesWithoutAssertions.length}건:`);
      filesWithoutAssertions.forEach(f = >   console.error(`   ${f}`));
      console.error(`\n   💡 UnimplementedError stub을 실제 assertion으로 교체하세요`);
      throw new Error(`BDD Coverage Gate failed: ${filesWithoutAssertions.length} step files missing assertions`);
    }

    console.log(`✅ Step 8.3 complete — BDD coverage 100%, all ${allSteps.length} steps have assertions`);
  }
} else {
  console.warn(`⚠️ BDD Coverage Gate skipped (--skip-bdd)`);
}

// ══════════════════════════════════════════════════════════
// Phase 1: DCM 포맷팅 + Dart 린트 자동 수정 (0건 목표)
// ══════════════════════════════════════════════════════════
// ⚠️ 포매터: dcm format으로 통일 (dart format 사용 금지)
//    melos run format → 내부적으로 dcm format lib 실행

// 1-1. DCM 포맷팅 적용
await Bash(`melos run format`);  // dcm format (dart format 대체)

// 1-2. dart fix --apply 로 자동 수정 가능한 린트 이슈 일괄 수정
//      (deprecated API 대체, unnecessary_import 제거, prefer_const 적용 등)
await Bash(`dart fix --apply`);

// 1-3. 포맷팅 + fix 변경 커밋 (변경 있을 때만)
const hasFixChanges = await Bash(`git diff --name-only`);
if (hasFixChanges.trim()) {
  await Bash(`
    git add .
    git commit -m  " style: 🎨 dart fix + format 자동 수정

    - dart fix --apply 린트 자동 수정
    - dcm format 코드 스타일 정리

    Co-Authored-By: Claude  < noreply@anthropic.com > " 
   `);
}

// 1-4. Dart SDK analyze 실행 및 결과 파싱 (dart analyze — DCM과 별도)
const analyzeOutput = await Bash(`melos run analyze 2 > & 1`);
const analyzeLines = analyzeOutput.split( ' \n ' )
  .filter(line = >   line.match(/\s+(info|warning|error)\s+[•·-]/));

const totalAnalyzeIssues = analyzeLines.length;

// 1-5. 린트 이슈가 남아있으면 수동 수정 시도 (최대 2회 반복)
if (totalAnalyzeIssues  >   0) {
  console.warn(`⚠️ dart analyze 이슈 ${totalAnalyzeIssues}건 발견`);

  for (let attempt = 0; attempt  <   2; attempt++) {
    // 각 이슈의 소스 파일을 읽고 린트 규칙에 맞게 직접 수정
    for (const issue of analyzeLines) {
      // 파일 경로, 라인, 규칙명을 파싱하여 해당 코드를 수정
      await fixAnalyzeIssue(issue);
    }

    // 수정 후 재포맷 + 재분석
    await Bash(`dart fix --apply`);
    await Bash(`melos run format`);  // dcm format
    const recheck = await Bash(`melos run analyze 2 > & 1`);
    const recheckLines = recheck.split( ' \n ' )
      .filter(line = >   line.match(/\s+(info|warning|error)\s+[•·-]/));

    if (recheckLines.length === 0) {
      console.log(`✅ dart analyze 이슈 0건 — 린트 게이트 통과`);
      break;
    }

    if (attempt === 1  & &   recheckLines.length  >   0) {
      // 2회 시도 후에도 이슈가 남아있으면 상세 출력 + PR 차단
      console.error(`❌ dart analyze 이슈 ${recheckLines.length}건 미해결 — PR 생성 차단`);
      recheckLines.forEach(l = >   console.error(`   ${l.trim()}`));
      throw new Error(`Dart lint gate blocked: ${recheckLines.length} issues remaining`);
    }
  }

  // 수정된 파일 커밋
  const hasLintFixes = await Bash(`git diff --name-only`);
  if (hasLintFixes.trim()) {
    await Bash(`
      git add .
      git commit -m  " fix: 🐛 flutter analyze 린트 이슈 수정

      - error/warning/info 이슈 0건 달성
      - 정적 분석 클린 상태 확보

      Co-Authored-By: Claude  < noreply@anthropic.com > " 
     `);
  }
} else {
  console.log(`✅ flutter analyze 이슈 0건 — 린트 게이트 통과`);
}

// ══════════════════════════════════════════════════════════
// Phase 2: DCM 코드 품질 개선 (dcm-code-quality 스킬 활용)
// ══════════════════════════════════════════════════════════

// 2-1. DCM 린트 + 메트릭 검사 실행
const dcmRunResult = await Bash(`melos run dcm:analyze 2 > & 1`);

// 2-2. 자동 수정 가능 항목 수정
await Bash(`melos run dcm:fix`);

// 2-3. 미사용 코드 검사
await Bash(`melos run dcm:unused-code`);

// 2-4. 수정 후 재검증
const dcmVerifyResult = await Bash(`melos run dcm:analyze 2 > & 1`);

// 2-5. 수정된 파일 커밋
const hasDcmChanges = await Bash(`git diff --name-only`);
if (hasDcmChanges.trim()) {
  await Bash(`
    git add .
    git commit -m  " refactor: ♻️ DCM 코드 품질 자동 수정

    - dcm fix . 자동 수정 적용
    - 미사용 코드 정리

    Co-Authored-By: Claude  < noreply@anthropic.com > " 
   `);
}

// 2-6. 잔여 이슈 요약 → PR body에 포함
const remainingIssues = parseDcmOutput(dcmVerifyResult);
if (remainingIssues.length  >   0) {
  prBodyExtras.dcmFindings = remainingIssues;
  console.log(`ℹ️ DCM 잔여 이슈 ${remainingIssues.length}건 → PR body에 포함`);
}

// 2-7. error 심각도 이슈가 남아있으면 차단
const errorIssues = remainingIssues.filter(i = >   i.severity ===  " error " );
if (errorIssues.length  >   0) {
  console.error(`❌ DCM error 이슈 ${errorIssues.length}건 미해결 — PR 생성 차단`);
  throw new Error( " DCM quality gate blocked " );
}

// ══════════════════════════════════════════════════════════
// Phase 3: 최종 린트 검증 (DCM 수정이 새로운 린트 이슈를 만들지 않았는지 확인)
// ⚠️ dart analyze + dcm analyze 모두 실행 (검사 범위가 다름)
//    - dart analyze: Dart SDK 기본 린트 + 타입 체크 + 언어 수준 오류
//    - dcm analyze: DCM 전용 린트 규칙 + 메트릭 + 안티패턴
// ══════════════════════════════════════════════════════════

// 3-1. Dart SDK 최종 검증
const finalDartAnalyze = await Bash(`melos run analyze 2 > & 1`);
const finalDartIssues = finalDartAnalyze.split( ' \n ' )
  .filter(line = >   line.match(/\s+(info|warning|error)\s+[•·-]/));

if (finalDartIssues.length  >   0) {
  console.error(`❌ 최종 검증 실패: dart analyze 이슈 ${finalDartIssues.length}건`);
  finalDartIssues.forEach(l = >   console.error(`   ${l.trim()}`));
  throw new Error(`Final dart lint gate blocked: ${finalDartIssues.length} issues remaining`);
}

// 3-2. DCM 최종 검증
const finalDcmAnalyze = await Bash(`melos run dcm:analyze 2 > & 1`);
const finalDcmErrors = parseDcmOutput(finalDcmAnalyze).filter(i = >   i.severity ===  " error " );

if (finalDcmErrors.length  >   0) {
  console.error(`❌ 최종 검증 실패: dcm analyze error ${finalDcmErrors.length}건`);
  throw new Error(`Final DCM lint gate blocked: ${finalDcmErrors.length} error issues remaining`);
}

console.log(`✅ Step 8.5 complete — dart analyze 0건, dcm analyze error 0건`);

// ♻️ 위 Phase 1~3 전체가 runPrePushGate() — Step 11 등 이후의 모든 push 직전에 재호출된다.

Agent Teams 사용 가능 시:
  ├─ Teammate 1: 보안 + 성능 (Critical Focus)
  │   ├─ 보안 취약점 (injection, XSS, 인증 우회)
  │   ├─ 데이터 안전성 (null safety, race condition)
  │   └─ 성능 (N+1, 메모리 누수, 불필요한 rebuild)
  │
  ├─ Teammate 2: 아키텍처 + 상태관리
  │   ├─ Clean Architecture 준수 (레이어 의존성)
  │   ├─ BLoC 패턴 (상태 전이, 이벤트 처리)
  │   └─ DI / Repository 인터페이스 준수
  │
  └─ Teammate 3: 가독성 + i18n + 접근성 (Informational)
      ├─ 코드 가독성 (네이밍, 구조, 복잡도)
      ├─ i18n (하드코딩 문자열, 번역 키)
      └─ 접근성 (semanticLabel, 터치 타겟)

  → Lead가 결과 병합:
    - Critical 이슈 (Teammate 1, 2) → Gate 차단 판정
    - Informational (Teammate 3) → PR body에 포함
    - Critical 발견 시 자동 수정 시도 (최대 2회)

Fallback (순차):
  8개 카테고리 순차 검사

if (!options.skipReview) {
  // Pass 1: Critical 이슈 검사
  const reviewResult = await Skill({
    skill:  " code-review " ,
    args:  " --quick --gate-mode " ,
  });

  const criticalIssues = reviewResult.issues.filter(i = >   i.severity ===  " critical " );
  const informationalIssues = reviewResult.issues.filter(i = >   i.severity !==  " critical " );

  if (criticalIssues.length  >   0) {
    // 자동 수정 시도 (최대 2회)
    for (let attempt = 0; attempt  <   2; attempt++) {
      await autoFixCriticalIssues(criticalIssues);
      const recheck = await Skill({ skill:  " code-review " , args:  " --quick --gate-mode "   });
      if (recheck.criticalCount === 0) break;
    }

    // 재검증 후에도 Critical 남아있으면 차단
    if (finalCheck.criticalCount  >   0) {
      console.error(`❌ Code Review Gate 실패: ${finalCheck.criticalCount}건의 Critical 이슈`);
      console.error( "     --skip-review 옵션으로 우회하거나, 수동 수정 후 재시도하세요 " );
      throw new Error( " Code Review Gate blocked " );
    }
  }

  // Pass 2: Informational 항목은 PR body에 포함할 데이터로 저장
  prBodyExtras.reviewFindings = informationalIssues;
} else {
  console.warn( " ⚠️ Code Review Gate를 건너뜁니다 (--skip-review) " );
  console.warn( "     프로덕션 배포 전 반드시 /code-review를 실행하세요 " );
}

// PR base 브랜치 결정 (계층 브랜치 전략)
// baseBranch는 Step 4에서 결정된 값 사용
const prBaseBranch = baseBranch; // epic/xxx, story/xxx, task/xxx, feature/xxx(단독 이슈), 또는 development

// PR 생성
await Bash(`
  gh pr create --base  " ${prBaseBranch} "   \
    --title  " ${gitmoji} ${analysis.scope}: ${workContent} "   \
    --body  " $(cat  < < ' EOF ' 
 ## Summary
- ${workContent}

## Test Plan
${prBodyExtras.testPlanResults?.map(t = >   {
  const check = t.testPass === true ?  ' x '   : (t.testPass === false ?  '   '   :  ' ~ ' );
  const status = t.analyzePass
    ? (t.testPass === true ?  ' ✅ '   : (t.testPass === false ?  ' ❌ '   :  ' ⚠️ 분석만 통과 ' ))
    :  ' ❌ 분석 실패 ' ;
  return `- [${check}] ${t.item} (${status})`;
}).join( ' \n ' ) ?? `
- [ ] UseCase 단위 tests passed
- [ ] BLoC 단위 tests passed
${hasBackendChanges ?  ' - [ ] 백엔드 엔드포인트 통합 tests passed '   :  ' ' }
${analysis.requiresBdd ?  ' - [ ] BDD 시나리오 통과 '   :  ' ' }
`}
${prBodyExtras.testSummary ? `
 >   테스트 결과: ${prBodyExtras.testSummary.totalPassed}건 통과` +
  (prBodyExtras.testSummary.totalFailed  >   0 ? `, ${prBodyExtras.testSummary.totalFailed}건 실패` :  ' ' ) +
  (prBodyExtras.testSummary.analyzeErrors  >   0 ? ` | 정적 분석 에러: ${prBodyExtras.testSummary.analyzeErrors}건` :  '   | 정적 분석: ✅ ' )
:  ' ' }
${prBodyExtras.designVerification ? `
## Design Verification
${prBodyExtras.designVerification.status ===  " pass "   ? `✅ PASS — tolerance ${prBodyExtras.designVerification.tolerance}, target ${prBodyExtras.designVerification.target}` :  ' ' }
${prBodyExtras.designVerification.status ===  " skipped "   ? `⚠️ 디자인 검증 미실행 (${prBodyExtras.designVerification.reason}) — 디자이너 수동 확인 필요` :  ' ' }
${prBodyExtras.designVerification.status ===  " fail-acknowledged "   ? `⚠️ 잔존 불일치 ${prBodyExtras.designVerification.diffCount}건 — 사용자 확인 후 진행 (수동 검토 필요)` :  ' ' }
${prBodyExtras.designVerification.artifactPath ? `- Artifacts: \`${prBodyExtras.designVerification.artifactPath}\`` :  ' ' }
` :  ' ' }

Closes #${issue.number}

${prBodyExtras.dcmFindings?.length  >   0 ? `
## DCM Quality Report
${prBodyExtras.dcmFindings.map(f = >   `- **[${f.severity}]** ${f.rule}: ${f.message} (${f.file}:${f.line})`).join( ' \n ' )}
` :  ' ' }
${prBodyExtras.reviewFindings?.length  >   0 ? `
## Review Findings (Informational)
${prBodyExtras.reviewFindings.map(f = >   `- **[${f.category}]** ${f.message} (${f.file}:${f.line})`).join( ' \n ' )}
` :  ' ' }
🤖 Generated with [Claude Code](https://claude.com/claude-code)
EOF
) " 
 `);

// Review/QA 이동
await mcp__zenhub__moveIssueToPipeline({
  issueId: issue.id,
  pipelineId: reviewQaPipelineId,
});

// Step 8.7에서 자동 코드 review complete됨
// Step 11은 PR 생성 후 추가 리뷰 피드백 반영 단계
if (!options.skipReview) {
  // PR 리뷰 코멘트 확인 및 추가 피드백 반영
  await Skill({ skill:  " code-review "   });

  // 피드백 반영 커밋 (변경 있을 때만)
  const hasFeedbackChanges = await Bash(`git status --porcelain`);
  if (hasFeedbackChanges.trim()) {
    await Bash(`
      git add .
      git commit -m  " refactor: ♻️ PR 리뷰 피드백 반영

      Co-Authored-By: Claude  < noreply@anthropic.com > " 
     `);

    // ⚠️ Per-Push Verification Gate: push 직전 Step 8.5 게이트 전체 재실행
    //    (format → dart fix → analyze 0건 → dcm:analyze error 0건)
    //    PR이 이미 존재해도 예외 없음 — 실패 시 throw로 push 차단
    await runPrePushGate();   // = Step 8.5 Phase 1~3

    await Bash(`git push`);
  }

  // /checklist:feature-complete 실행
  await Skill({ skill:  " checklist:feature-complete "   });
}

// 최종 상태 요약
displayMergeSummary(issue, pr, testResults, reviewResults);

// user approval 요청
const approval = await AskUserQuestion({
  questions: [{
    header:  " 머지 " ,
    question:  " PR을 머지하시겠습니까? " ,
    options: [
      { label:  " 머지 승인 " , description:  " 스쿼시 머지 후 이슈 클로즈 "   },
      { label:  " 수정 필요 " , description:  " Step 7로 돌아가서 수정 "   },
      { label:  " 취소 " , description:  " 현재 상태 유지 "   },
    ],
    multiSelect: false,
  }],
});

if (approval ===  " 머지 승인 " ) {
  // 스쿼시 머지 → GitHub  " Closes # "   키워드로 이슈 자동 Close
  // 정책:  " 머지 = Close "   (AI agent가 머지 전 풀스택 E2E/리뷰 완료). Done 파이프라인 미사용.
  await Bash(`gh pr merge --squash --delete-branch`);

  // ══════════════════════════════════════════════════════════
  // Step 12.5: 이슈 Close 검증 + 폴백 ⚠️ (ZenHub 2-상태 모델)
  // ══════════════════════════════════════════════════════════
  // ZenHub는 두 상태를 따로 관리한다:
  //   - Pipeline(보드 칼럼): Done으로 옮겨도 GitHub 이슈는 open 그대로
  //   - GitHub state(open/closed): Closed 파이프라인 = GitHub closed와 1:1
  // 따라서  " 닫혔다 " 의 진실은 pipeline이 아니라 GitHub state로 판단한다.
  // `Closes #N` 자동 close가 누락/지연될 수 있으므로 머지 후 반드시 검증·폴백한다.

  // 12.5-1. GitHub 이슈 상태 확인 (open/closed의 source of truth)
  const ghState = (await Bash(`gh issue view ${issue.number} --json state -q .state`)).trim();
  if (ghState !==  " CLOSED " ) {
    // `Closes #N`이 발화하지 않음(키워드 누락/크로스리포 링크 등) → 명시적 close
    console.warn(`⚠️ #${issue.number} 자동 close 안 됨 → 명시적으로 close합니다`);
    await Bash(`gh issue close ${issue.number} --reason completed`);
  }

  // 12.5-2. ZenHub가 Closed 파이프라인으로 동기화됐는지 확인 (GitHub close → 자동 동기화)
  //         동기화 지연 시 ZenHub state를 직접 CLOSED로 강제
  const closedOnZh = await mcp__zenhub__searchClosedIssues({ query: `#${issue.number}` });
  if (!closedOnZh.find(i = >   i.number === issue.number)) {
    console.warn(`⚠️ ZenHub Closed 동기화 지연 → state를 CLOSED로 강제`);
    await mcp__zenhub__updateIssue({ issueId: issue.id, state:  " CLOSED "   });
  }
  console.log(`✅ Step 12.5 — #${issue.number} GitHub + ZenHub 모두 Closed 확정`);

  // ⭐ 계층 재귀 확인: 방금 닫힌 이슈가 Epic이면, 그 위 Project(→ Initiative)까지
  // 모든 자식이 닫혔는지 재귀 확인 후 자동 종료한다. Story 레벨 close는 여기서
  // 재귀를 타지 않는다 — Epic 자신은 아래  " 계층 브랜치 "   블록의 안내를 거쳐 사람이
  // Epic PR을 머지해야 닫히므로, Story close만으로 Epic을 앞질러 닫지 않는다.
  if (issue.issueType ===  " Epic " ) {
    await checkAndCloseParent(issue.number); // see commands/agents/dev/issue-state-agent.md
  }

  // ⭐ 머지 후: PR base 브랜치로 이동 + 최신 상태로 동기화 + 서브모듈 최신화 (필수)
  // - gh pr merge --delete-branch 는 base 브랜치를 체크아웃하지만 pull 하지 않는다.
  // - release 자동화가 머지 직후 chore(release) 커밋을 origin에 추가하므로,
  //   base 브랜치를 명시적으로 최신화하여 로컬을 항상 최신 상태로 둔다.
  // - git pull 은 superproject가 기록한 서브모듈 포인터만 갱신할 뿐 서브모듈 워킹트리는
  //   체크아웃하지 않는다. git submodule update 없이는 서브모듈이 머지 이전 리비전에 머물러
  //   Serverpod/Melos 모노레포에서 빌드/코드젠 drift가 발생한다.
  //   git submodule sync 로 .gitmodules URL 변경을 먼저 반영한 뒤 update 한다.
  //   서브모듈이 없는 리포지토리에서는 두 명령 모두 no-op 이므로 항상 실행해도 안전하다.
  // - baseBranch 는 Step 4에서 결정된 PR base (계층: 부모 브랜치, 독립: development).
  await Bash(`
    git checkout ${baseBranch}
    git pull --ff-only origin ${baseBranch}
    git submodule sync --recursive
    git submodule update --init --recursive
  `);
  console.log(`✅ 머지 후 ${baseBranch} 브랜치로 이동 + 최신화 + 서브모듈 동기화 완료`);

  // 계층 브랜치: 부모 브랜치가 Epic이고 모든 Story가 완료되면 안내
  if (parentIssue  & &   parentIssue.issueType ===  " Epic " ) {
    const siblings = await mcp__zenhub__searchLatestIssues({
      query: `parent:${parentIssue.id}`,
    });
    // 상태 비교는 대소문자 정규화 (ZenHub 는  " OPEN " / " CLOSED "   대문자 반환 — :1398 과 일관)
    const openSiblings = siblings.filter(s = >   (s.state ||  " " ).toUpperCase() !==  " CLOSED " );
    if (openSiblings.length === 0) {
      console.log(`\n🎉 Epic #${parentIssue.number}의 모든 Story가 완료되었습니다.`);
      console.log(`   Epic 브랜치를 development에 머지하세요:`);
      console.log(`   /dev:run ${parentIssue.number}`);
    } else {
      console.log(`\nℹ️ Epic #${parentIssue.number}: ${openSiblings.length}개 Story 남음`);
    }
  }
}

╔════════════════════════════════════════════════════════════════╗
║  /dev:run Progress                                            ║
╠════════════════════════════════════════════════════════════════╣
║                                                                ║
║  [████████░░░░░░░░░░░░] 50% - Step 6/12                       ║
║                                                                ║
║  ✅ Step 1: 작업 내용 분석 완료 (screen feature 감지: List)          ║
║  ✅ Step 2: 이슈 #1810 생성 완료                                ║
║  ✅ Step 3: Product Backlog 이동                               ║
║  ✅ Step 4: 브랜치 생성 완료                                   ║
║  ✅ Step 5: In Progress 이동                                   ║
║  🔄 Step 6: BDD 시나리오 작성 중...                            ║
║  ⏳ Step 7: 구현 작업 대기                                     ║
║  ⏳ Step 8: 테스트 작성/실행 대기                               ║
║  ⏳ Step 9: PR 생성 대기                                       ║
║  ⏳ Step 10: Review/QA 이동 대기                               ║
║  ⏳ Step 11: 코드 리뷰 대기                                    ║
║  ⏳ Step 12: 머지 승인 대기                                    ║
║                                                                ║
╚════════════════════════════════════════════════════════════════╝