jira-task-approachlisted

# jira-task-approach: Generate Approach Document (level-aware) **Language Rule**: 프로젝트 CLAUDE.md의 Conventions 섹션 참고 (한국어 출력, Jira 코멘트 제목은 영어). ## Overview `jira-task-approach`는 기존 `plan` + `design` 두 단계를 단일 단계로 통합한다. 작업 규모(L1/L2/L3)에 따라 분량과 깊이를 조정한다 — 작은 작업에 무거운 설계 문서를 쓰지 않는다. **입력:** - `<TASK-ID>` (필수) - `.jira-context.json.cachedIssue` (Cache-First Fetch) - `.jira-context.json.breakdownLevel` (있으면 우선) - discover 산출물 `docs/requirements/<slug>.requirements.md`의 `Technical Approach Hint` 섹션 (있으면 입력) **출력:** - `docs/approach/<TASK-ID>.approach.md` - Jira 코멘트 + 첨부 (가능 시) **비목표:** - 코드 작성/실행 (impl 단계 책임) - 테스트 작성/실행 (test 단계 책임) ## Workflow ### Step 0: Determine Breakdown Level 레벨 결정 우선순위: 1. **`.jira-context.json.breakdownLevel`** (`"L1"` | `"L2"` | `"L3"`) — Sub 1.3에서 기록된 값. hit이면 그대로 사용. 2. **Jira issuetype 폴백 추론** — context에 값 없으면 cachedIssue의 issuetype으로: - `Subtask`, `Task`, `Bug` → **L1** - `Story` → **L2** - `Epic` → **L3** - 그 외 → **L1** (보수적) 3. **설계 차원 승급 체크** — 1~2로 정한 레벨이 L1이어도, 작업이 다음 중 하나라도 건드리면 최소 **L2로 격상**(이미 L2/L3면 유지): 데이터 모델/스키마 변경 · 트랜잭션·원자성 경계 · 외부 노출 인터페이스/API 계약 · 동시성·멱등성·순서 · 보안·권한 경계. 이 차원들이 곧 "코딩 전에 못 박아야 하는 비가역 결정"이므로 5줄 요약으로는 부족하다. 4. 결정된 레벨을 사용자에게 1줄로 알린다 — 예: `📐 Approach level: L2 (issuetype Story 폴백)` / 격상 시 사유 명시 `📐 L2 (Task지만 스키마 변경 → 격상)`. 사용자가 다음 턴에 자연어로 변경 요청 시("L1로 줄여줘") 그대로 따른다 — 별도 플래그 없음. ### Step 1: Cache-First Fetch `.jira-context.json`의 `cachedIssue`를 먼저 확인 (CLAUDE.md "Cache-First Fetch" 참고). - **hit 조건**: `