# 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 "

┌─────────────────────────────────────────────────────────────────┐
│                    /dev:run  " 작업 내용 "                           │
├─────────────────────────────────────────────────────────────────┤
│                                                                 │
│  Step 1: 작업 내용 분석                                          │
│  ├── 작업 유형 추론 (feat/fix/chore/refactor)                    │
│  ├── 스코프 추출 (feature명)                                     │
│  ├── 화면 타입 감지 (목록/상세/폼)                                │
│  └── 예상 복잡도 산정 (Story 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.5: Backend 코드 생성 (on Backend changes) ⚠️                │
│  ├── melos run backend:pod:generate                             │
│  └── 커밋:  " chore(backend): 🔧 코드 생성 "                          │
│                                                                 │
│  Step 8: 테스트 작성 및 검증 (필수 게이트) ⚠️                      │
│  ├── [프론트엔드 테스트 - 필수]                                    │
│  │   ├── UseCase 단위 테스트 (unit-test-agent)                   │
│  │   └── BLoC 단위 테스트 (bloc-test-agent)                      │
│  ├── [백엔드 테스트 - on Backend changes 필수]                        │
│  │   ├── 엔드포인트 단위 테스트 (serverpod-test-agent)            │
│  │   ├── 서비스 로직 단위 테스트 (serverpod-test-agent)           │
│  │   └── 엔드포인트 통합 테스트 (serverpod-test-agent)            │
│  ├── BDD Widget 테스트 (screen feature 시)                             │
│  ├── test-runner-agent 호출 (require_tests: true)              │
│  ├── ⚠️ 모든 tests passed 필수 (게이트 실패 시 PR 생성 차단)        │
│  └── 커밋:  " test({scope}): ✅ 테스트 작성 "                          │
│                                                                 │
│  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 (Dart SDK 분석)                   │
│  │   ├── error/warning/info 잔존 시 수동 수정 (최대 2회 반복)      │
│  │   └── ⚠️ 2회 시도 후에도 이슈 잔존 시 PR 생성 차단              │
│  ├── [Phase 2: DCM 코드 품질 개선]                                 │
│  │   ├── melos run analyze:dcm (DCM 린트 + 메트릭)               │
│  │   ├── melos run fix:dcm (자동 수정 가능 항목 수정)             │
│  │   ├── melos run check:unused-code (미사용 코드 검사)           │
│  │   ├── melos run analyze:dcm (수정 후 재검증)                   │
│  │   └── ⚠️ error 심각도 이슈 잔존 시 PR 생성 차단                 │
│  ├── [Phase 3: 최종 린트 검증]                                     │
│  │   ├── melos run analyze:dart (DCM 수정 후 Dart 재확인)         │
│  │   ├── melos run analyze:dcm (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: 머지 승인 대기                                         │
│  ├── user approval 요청                                            │
│  ├── 승인 시 스쿼시 머지                                         │
│  └── GitHub  " Closes # "   키워드로 이슈 자동 Close                 │
│                                                                 │
└─────────────────────────────────────────────────────────────────┘

# 현재 브랜치 확인
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

// 단계 전제조건 검증
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
};

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

// GitHub 이슈 생성
const issue = await mcp__zenhub__createGitHubIssue({
  repositoryId: githubRepoId,
  title: `${gitmoji} ${analysis.scope}: ${workContent}`,
  body: generateIssueBody(workContent, analysis),
  issueTypeId: getIssueTypeId(issueTypeMap[analysis.type]),
  labels: generateLabels(analysis),
});

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

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

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

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

if (!options.base) {
  // ZenHub에서 부모 이슈 조회
  const issueDetails = await mcp__zenhub__searchLatestIssues({
    query: `#${issue.number}`,
  });
  const parentId = issueDetails[0]?.parentIssueId;

  if (parentId) {
    parentIssue = await mcp__zenhub__getIssue({ issueId: parentId });
    const parentType = parentIssue.issueType; //  " Epic "   |  " Feature "   | ...
    const parentNumber = parentIssue.number;

    // 4-2. 부모 브랜치 존재 확인
    const parentBranchPrefix = parentType ===  " Epic "   ?  " epic "   :  " feature " ;
    const parentSlug = createSlug(parentIssue.title);
    const expectedParentBranch = `${parentBranchPrefix}/${parentNumber}-${parentSlug}`;

    const branchExists = await Bash(
      `git rev-parse --verify origin/${expectedParentBranch} 2 > /dev/null  & &   echo  " exists "   || echo  " missing " `
    );

    if (branchExists.trim() ===  " missing " ) {
      // 4-3. 부모 브랜치 자동 생성 (development 기반)
      // 부모의 부모가 있으면 재귀적으로 base 결정
      const grandparentBranch = parentIssue.parentIssueId
        ? await resolveBaseBranch(parentIssue.parentIssueId)
        :  " development " ;

      await Bash(`
        git checkout ${grandparentBranch}
        git pull origin ${grandparentBranch}
        git checkout -b ${expectedParentBranch}
        git push -u origin ${expectedParentBranch}
      `);
      console.log(`🌿 부모 브랜치 자동 생성: ${expectedParentBranch}`);
    }

    baseBranch = expectedParentBranch;
    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(issueId: string): Promise < string >   {
  const issue = await mcp__zenhub__getIssue({ issueId });
  const branchPrefix = issue.issueType ===  " Epic "   ?  " epic "   :  " feature " ;
  const slug = createSlug(issue.title);
  const branchName = `${branchPrefix}/${issue.number}-${slug}`;

  // 브랜치 존재 확인
  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.parentIssueId) {
    const parentBranch = await resolveBaseBranch(issue.parentIssueId);
    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) {
  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) — 테스트 코드 컴파일 검증
  const analyzeResult = await Bash(
    `dart analyze ${testPlan.map(t = >   t.file).join( '   ' )} 2 > & 1 | grep -c  " error " `
  );
  const analyzeErrors = parseInt(analyzeResult.stdout.trim());

  // 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}건 실패 - 수정 후 재시도`);
  }
} else {
  // --skip-tests 사용 시 사용자 확인 필수
  const confirm = await AskUserQuestion({
    questions: [{
      header:  " 테스트 스킵 확인 " ,
      question:  " 테스트를 스킵하면 검증 없이 PR이 생성됩니다. 계속하시겠습니까? " ,
      options: [
        { label:  " 스킵 확인 " , description:  " 테스트 없이 진행 (긴급 핫픽스용) "   },
        { label:  " 테스트 실행 " , description:  " 테스트를 실행합니다 "   },
      ],
    }],
  });
}

// ══════════════════════════════════════════════════════════
// 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) {
    console.warn(`⚠️ .feature 파일 없음 (${featureDir}) — BDD gate 스킵`);
  } 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);
    });

    const stepCoverage = allSteps.length  >   0
      ? (allSteps.length - missingSteps.length) / allSteps.length
      : 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:dart 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:dart 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 analyze:dcm 2 > & 1`);

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

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

// 2-4. 수정 후 재검증
const dcmVerifyResult = await Bash(`melos run analyze:dcm 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:dart 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 analyze:dcm 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건`);

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, 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}건` :  '   | 정적 분석: ✅ ' )
:  ' ' }

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 "   });

  // 피드백 반영 (자동 가능한 것만)
  await Bash(`melos run format`);       // dcm format
  await Bash(`dart fix --apply`);
  await Bash(`melos run analyze:dart`);
  await Bash(`melos run analyze:dcm`);

  // /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
  // Done 파이프라인 이동 불필요 (머지 = 완료)
  await Bash(`gh pr merge --squash --delete-branch`);

  // 계층 브랜치: 부모 브랜치가 Epic이고 모든 Story가 완료되면 안내
  if (parentIssue  & &   parentIssue.issueType ===  " Epic " ) {
    const siblings = await mcp__zenhub__searchLatestIssues({
      query: `parent:${parentIssue.id}`,
    });
    const openSiblings = siblings.filter(s = >   s.state ===  " open " );
    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: 머지 승인 대기                                    ║
║                                                                ║
╚════════════════════════════════════════════════════════════════╝

╔════════════════════════════════════════════════════════════════╗
║  Workflow Complete: #1810                                      ║
╠════════════════════════════════════════════════════════════════╣
║                                                                ║
║  📋 Issue: #1810 - 저자 목록 화면 추가                          ║
║  🔀 PR: #1815                                                  ║
║  🌿 Branch: feature/1810-author-list (deleted)                 ║
║                                                                ║
║  📝 Changes:                                                   ║
║    - 12 files changed                                         ║
║    - +520 / -30 lines                                         ║
║                                                                ║
║  ✅ Tests: 35/35 passed                                        ║
║    - UseCase Unit: 10/10                                      ║
║    - BLoC Unit: 8/8                                           ║
║    - Backend Unit: 6/6 (endpoint: 3, service: 3)              ║
║    - Backend Integration: 4/4                                 ║
║    - BDD: 7/7 scenarios                                       ║
║                                                                ║
║  ✅ Review: All issues resolved                                ║
║  ✅ Checklist: 11/11 passed                                   ║
║  ✅ CI: All checks passed                                      ║
║                                                                ║
║  📊 Duration: 22m 15s                                          ║
║  🏁 Final State: CLOSED (by merge)                             ║
║                                                                ║
╚════════════════════════════════════════════════════════════════╝

TodoWrite([
  { content:  " Step 1: 작업 내용 분석 " , status:  " in_progress " , activeForm:  " 작업 내용 분석 중 "   },
  { content:  " Step 2: ZenHub 이슈 생성 " , status:  " pending " , activeForm:  " 이슈 생성 대기 "   },
  { content:  " Step 3: Product Backlog 이동 " , status:  " pending " , activeForm:  " Pipeline 이동 대기 "   },
  { content:  " Step 4: 브랜치 생성 " , status:  " pending " , activeForm:  " 브랜치 생성 대기 "   },
  { content:  " Step 5: In Progress 이동 " , status:  " pending " , activeForm:  " Pipeline 이동 대기 "   },
  { content:  " Step 6: BDD 시나리오 " , status:  " pending " , activeForm:  " BDD 작성 대기 "   },
  { content:  " Step 7: 구현 작업 " , status:  " pending " , activeForm:  " 구현 대기 "   },
  { content:  " Step 7.5: Backend 코드 생성 " , status:  " pending " , activeForm:  " Backend 생성 대기 "   },
  { content:  " Step 8: 테스트 작성 및 검증 (필수 게이트) " , status:  " pending " , activeForm:  " 테스트 대기 "   },
  { content:  " Step 8.3: BDD Coverage Gate " , status:  " pending " , activeForm:  " BDD 커버리지 검증 대기 "   },
  { content:  " Step 8.5: Pre-push 검증 + 린트 0건 + DCM 품질 개선 " , status:  " pending " , activeForm:  " 검증 대기 "   },
  { content:  " Step 8.7: Code Review Gate " , status:  " pending " , activeForm:  " 리뷰 게이트 대기 "   },
  { content:  " Step 9: PR 생성 " , status:  " pending " , activeForm:  " PR 생성 대기 "   },
  { content:  " Step 10-12: 리뷰/머지 " , status:  " pending " , activeForm:  " 리뷰 대기 "   },
]);

// Step 4 complete 후 예시
TodoWrite([
  { content:  " Step 1: 작업 내용 분석 " , status:  " completed " , activeForm:  " 작업 분석 완료 "   },
  { content:  " Step 2: ZenHub 이슈 생성 " , status:  " completed " , activeForm:  " 이슈 생성 완료 "   },
  { content:  " Step 3: Product Backlog 이동 " , status:  " completed " , activeForm:  " Pipeline 이동 완료 "   },
  { content:  " Step 4: 브랜치 생성 " , status:  " completed " , activeForm:  " 브랜치 생성 완료 "   },
  { content:  " Step 5: In Progress 이동 " , status:  " in_progress " , activeForm:  " Pipeline 이동 중 "   },
  // ... 나머지 pending 유지
]);

/dev:run  " 저자 목록 화면 추가 " 
 → 키워드  " 추가 " ,  " 화면 "   감지 → feat

/dev:run  " 로그인 버그 수정 " 
 → 키워드  " 버그 " ,  " 수정 "   감지 → fix

/dev:run  " API 응답 캐싱 개선 " 
 → 키워드  " 개선 "   감지 → refactor

/dev:run  " 저자 목록 화면 추가 " 
 → 키워드  " 목록 "   감지 → List → BDD 자동 생성

/dev:run  " 도서 상세 화면 구현 " 
 → 키워드  " 상세 "   감지 → Detail → BDD 자동 생성

/dev:run  " 저자 등록 폼 추가 " 
 → 키워드  " 등록 "   감지 → Form → BDD 자동 생성

/dev:run  " API 응답 캐싱 추가 " 
 → 화면 키워드 없음 → BDD 스킵