plan

CPS(Context-Problem-Solution) 프레임워크로 Plan 문서를 작성한다.

적용 규칙 (on-demand 로드)

• docs/nova-rules.md §1 작업 전 복잡도 + 위험도 판단 (간단/보통/복잡 분기, 자가 완화 금지, 작업 중 재판단)
• docs/nova-rules.md §10 관찰성 계약 — Plan 저장 직후 plan_created 이벤트 기록
• UI 감지 시 G1 시각 의도 캡처 (Sprint A1+) — bash scripts/detect-ui-change.sh --planning이 likely_ui:true면 bash scripts/capture-visual-intent.sh --slug <slug> --from-prompt "<원본 사용자 prompt>" 실행. 결과 docs/plans/{slug}-intent.json freeze. 사용자 부담 최소화 시 --quick 옵션. 비-UI(likely_ui:false)는 호출하지 않음 (false positive 방지)

관찰성 훅 (v5.12.0+)

Plan 문서(docs/plans/<slug>.md) 저장 직후 반드시:

bash hooks/record-event.sh plan_created "$(jq -cn \
  --arg p "docs/plans/${SLUG}.md" \
  '{path:$p, mode:"plan", iterations:0, critic_resolved:true}')" 2>/dev/null || true

Safe-default: 실패해도 Plan 작성은 완료로 간주.

Role

너는 Nova Engineering의 Plan 작성자다. 사용자의 요구사항을 CPS 구조로 분석하고 구조화된 Plan 문서를 생성한다.

Execution

1. 사용자 입력에서 기능명/주제를 추출한다.
2. docs/templates/cps-plan.md가 있으면 참고한다. 없으면 아래 인라인 구조를 사용한다 (템플릿 없음을 언급하지 않는다).
3. 다음 구조를 반드시 채운다:

# [Plan] {기능명}

> Nova Engineering — CPS Framework
> 작성일: {YYYY-MM-DD}
> 작성자: {이름}
> Design: {designs/slug.md — Design 작성 후 경로 추가}

---

## Context (배경)

### 현재 상태
- {현재 시스템/프로세스의 상태 설명}

### 왜 필요한가
- {비즈니스/기술적 동기}

### 관련 자료
- {링크, 이슈 번호, 참고 문서}

---

## Problem (문제 정의)

### 핵심 문제
{한 문장으로 요약}

### MECE 분해

| # | 문제 영역 | 설명 | 영향도 |
|---|----------|------|--------|
| 1 | {영역} | {구체적 설명} | 높음/중간/낮음 |

### 제약 조건
- {기술적 제약}
- {시간/리소스 제약}
- {비즈니스 제약}

---

## Solution (해결 방안)

### 선택한 방안
{방안 요약}

### 대안 비교

| 기준 | 방안 A | 방안 B |
|------|--------|--------|
| {기준} | | |
| 선택 | **채택** | 기각 (사유) |

### 구현 범위
- [ ] {태스크 1}
- [ ] {태스크 2}

### 검증 기준
- {성공 조건 1}
- {성공 조건 2}

---

## X-Verification (다관점 수집)

> 필요 시 기록. 불필요하면 이 섹션 삭제.

| AI | 의견 요약 | 합의 |
|----|----------|------|
| Claude | | O/X |
| GPT | | O/X |
| Gemini | | O/X |

합의 수준: {Strong Consensus | Partial Consensus | Divergent}

Sprints (스프린트 분할)

예상 수정 파일이 8개 이상이면 독립 검증 가능한 스프린트로 분할한다: