fz-plan

name: fz-plan description: >- 계획 수립 + 영향 범위 분석 + 설계. 요구사항 분해와 Serena 기반 코드베이스 탐색. 예: 계획 세워줘, 설계해줘, 아키텍처 잡아줘, 요구사항 분석 user-invocable: true argument-hint: "[기능/요구사항 설명] [light]" allowed-tools: >- mcp__serena__find_symbol, mcp__serena__get_symbols_overview, mcp__serena__find_referencing_symbols, mcp__serena__activate_project, mcp__serena__read_memory, mcp__serena__write_memory, mcp__serena__edit_memory, mcp__serena__list_memories, mcp__context7__resolve-library-id, mcp__context7__query-docs, mcp__sequential-thinking__sequentialthinking, mcp__atlassian__get-issue, mcp__atlassian__search-issues, Read, Grep, Glob, Workflow team-agents: primary: plan-structure supporting: [plan-impact, plan-edge-case, review-arch, review-direction, memory-curator] composable: true provides: [planning, architecture-analysis] needs: [none] intent-triggers: - "계획|설계|아키텍처|요구사항" - "plan|design|architect|requirement" - "리팩토링|치환|흡수|이전|migration|refactor" model-strategy: main: opus verifier: sonnet

/fz-plan - 계획 + 설계 스킬

행동 원칙: 요구사항을 구조적으로 분해하고, 코드베이스 영향 분석을 통해 정확한 구현 계획을 수립한다.

개요

⛔ Phase 0 (ASD Pre-flight) → Phase 0b (Context) → Phase 0c (Constraint Probe Pre-flight) → Phase 0.5 (Direction Challenge) → Phase 0.7 (Sprint Contract, TEAM 5+ Step) → Phase 1 (Deep Planning) → Phase 2 (Validation) ↔ Phase 3 (Feedback) → Gate 2 → /fz-code 루프 프리미티브: Plan-Execute + Evaluator-Optimizer (H6, Inside the Scaffold)

요구사항 구조 분해 + 영향 범위 분석. Serena 심볼 도구 기반 정밀 탐색.

/fz-plan "새 기능 계획해줘"        /fz-plan "피드백 반영해서 수정해줘"
/fz-plan "아키텍처를 더 상세하게"   /fz-plan "Gate 2 통과 확인해줘"

Prerequisites

• 팀 에이전트 모드(Workflow pilot)는 네이티브 Workflow 도구 가용 환경 필요 — 미가용 시 SOLO 계획 수립 폴백
• 참조: guides/agent-team-guide.md §8 (공식 사양)

모듈 참조

sc: 활용 (SuperClaude 연계)

Plugin 참조 (Swift Concurrency)

참조: modules/plugin-refs.md — Swift Concurrency(계획 시) 섹션 iOS 16 minimum target 제약: CLAUDE.md ## Plugins 참조. 계획에 iOS 17+ API (@Observable, @Bindable, onChange new signature) 사용 명시 시 #available 가드 step 포함 의무. availability 사전 결정: SwiftUI State 설계 (iOS 16: ObservableObject + @StateObject / iOS 17+: @Observable + @State) → plan에 #available 분기 명시

팀 에이전트 모드

팀 모드 규칙은 modules/team-core.md 참조

TEAM(TeamCreate+SendMessage) 모드를 네이티브 Workflow 결정적 스크립트로 대체한 Wave 2 전환. Collaborative Design 패턴 canonical: modules/patterns/collaborative.md (보존 — 라운드 의미론은 스크립트가 구현). 스크립트: workflows/plan-collaborative.js (플러그인 루트 상대) — agents/의 plan-structure·plan-impact·plan-edge-case·review-arch·review-direction 정의를 agentType(fz:)으로 재사용. 규약: guides/skill-authoring.md §12. 동시 opus ≤2(Lead 포함)는 workflows/plan-collaborative.js가 구조적으로 보장 (parallel 블록 sonnet 전용, opus 호출 전부 순차) — 구 Sequential Operating Contract(UC-6+ISSUE-016)의 보장을 스크립트 구조로 이전.

실행 절차 (Lead)

1. codeContext 선행 기록: 심볼 탐색 산출 요약을 {WORK_DIR}/plan/code-context.md로 기록 (대형 입력은 파일 경로 전달 — §12)
2. args 조립: requirement(필수)=요구사항 원문 / codeContextPath(필수)=요약 파일 절대 경로 / constraintsKnown=수집 제약 / discoverJournalPath=discover 산출물 경로(있으면 — 전제 아닌 참고)
3. Workflow 호출: Workflow({ scriptPath: '{플러그인 루트}/workflows/plan-collaborative.js', args })
   • Stage 0 direction(opus, PROCEED면 1-call·비-PROCEED만 반박 왕복 +2) → Stage 1 초안(opus) → Stage 2 병렬 3렌즈(sonnet) → Stage 3 CC 교차(edge↔impact) → Stage 4 통합(opus — 다운스트림 계약 전체) → Stage 5 아키 재검증. 9-11 call
4. 반환 처리:
   • mode:'workflow' → plan(§X readScope/§Y writeScope/§Z acceptanceCriteria + RTM 5필드 + implicationRegister + unresolvedPeerIssues[archVerdict])을 Phase 1 산출물로 통합 → plan-v{N}.md 기록 + top-level directionAlternatives(plan 객체 밖 — PlanSchema에 없음)를 plan 문서 '구조 결정 옵션 테이블' 섹션으로 별도 병합 (병합 누락 시 옵션이 사용자에게 미도달)
   • mode:'direction_escalation' → 대안 비교표 제시 + 사용자 확인 (Phase 0.5 RECONSIDER/REDIRECT 절차 준용)
   • mode:'fallback' → SOLO 계획 수립 수행 + 사유 experiment-log 기록
5. Workflow 외부 Lead 책임 (이관 아님 — 회귀 확인 의무, 15차): 설계 스트레스 테스트 Q1-Q6 + RTM 검증 + Phase 0.7 Sprint Contract(Codex 회복 시) + Codex verify(Phase 2) + memory-curator recall + plan 파일 기록은 기존 Phase 절차대로 Lead가 반환 후 실수행 — Workflow는 Phase 1의 협업 분석 부분만 대체
6. 지표 기록: return.metrics + wall-clock(Lead 측정) → experiment-log.md §5.7 fz-plan 테이블

6개 차별화된 렌즈 (같은 질문 금지 — ICLR 2025 근거. Workflow stage에 동일 적용):

통신 기록: plan-team.md 미생성 — Workflow transcript(runId)가 대체. TEAM 메커니즘 일몰은 확산 판정 시 결정.

⛔ Phase 0: ASD Pre-flight

참조: modules/context-artifacts.md → "Work Dir Resolution" 섹션. Phase 0b 전에 반드시 실행.

1. 인자에서 ASD-\d+ 패턴 추출
2. 패턴 있으면 → {CWD}/ASD-xxxx/ 폴더 + index.md 생성 (없으면) + WORK_DIR 설정
3. 패턴 없으면 → 브랜치명 확인 → 없으면 AskUserQuestion(저장 여부) → 예: {CWD}/NOTASK-{YYYYMMDD}/ + index.md 생성 / 아니오: Serena fallback

Gate 0: Work Dir Ready

• ⛔ ASD 패턴 또는 저장 여부 질문 완료?
• WORK_DIR 결정됨? (ASD / NOTASK / Serena fallback)
• index.md 존재 확인 완료? (없으면 생성)

Phase 0b: Context Loading

절차

1. 세션 감지: 참조 modules/session.md

2. 이전 세션 복원:

   • mcp__serena__list_memories → 관련 이전 세션 검색
   • mcp__serena__read_memory → 결정사항, 잔여 이슈 로드

3. 프로젝트 활성화:

   • mcp__serena__activate_project → LSP 서버 활성화

4. 대상 모듈 심볼 파악:

   • mcp__serena__get_symbols_overview → 작업 대상 파일 심볼 구조
   • mcp__serena__find_symbol → 컴포넌트 탐색

5. 이전 Discover 결과 로드 (ASD 폴더 활성 시):

   • {WORK_DIR}/discover/discover-journal.md 읽기 → Landscape Map + Trade-off Table + Open Questions 복원
   • {WORK_DIR}/discover/discover-plan.md 읽기 → mid-pipeline discover 결과 (있으면)
   • ⛔ discover 결과는 "전제"가 아닌 "참고": plan은 discover의 경로 중 하나를 선택하거나, 새 경로를 설계할 수 있음
   • 🔒불변 조건만 plan의 제약으로 채택. 🔓가변 조건은 비용 비교 대상으로만 활용
   • Open Questions는 plan Phase 1에서 추가 탐색 대상
   • ⛔ Scope Expansion: discover 변경 대상의 상위 모듈/프로토콜에서 get_symbols_overview → 놓친 형제 타입/간접 소비자를 탐색 범위에 추가

Gate 0b: Context Ready

• 프로젝트 활성화 완료?
• 대상 심볼 구조 파악?
• 이전 컨텍스트 로드? (해당 시)

Phase 0c: Constraint Probe Pre-flight (31차 방어)

Plan 핵심 차원이 primitive(CLI flag / config key / value enum / env precondition)에 의존하면 추측 위에 작성하지 않는다. 실측으로 가정 검증 후 차원 포함. 참조: feedback_plan_before_probe.md.

발동: 외부 primitive 의존 시 필수. 코드베이스 내부 패턴만 의존하면 스킵.

절차

1. 가정 추출: 요구사항/discover 결과에서 primitive 의존 가정 식별
   • 가정의 3 axes 점검 (32차 방어 — Probe Coverage Gap):
     • (a) 존재 가정: primitive가 작동하는가? (existence)
     • (b) 권한/경계 가정: 호출 측 SKILL.md allowed-tools / Bash(*) 패턴이 호출 허용? (boundary)
     • (c) 결과 contract 가정: 결과 형식/verdict가 호출자 해석과 일치? (contract)
   • 3 axes 모두 점검. 어느 하나라도 미검증이면 차원에서 제외 또는 explicit assumption tag.
2. 검증 분류 (각 가정 × 3 axes 별):
   • 이미 verified → [verified: source] 태그 보유 (코드/문서/명령어 출력)
   • 미검증 → [미검증: 이유] 태그 + Plan 차원에서 제외
   • probe 필요 → /fz-discover Phase 1.5 (Constraint Probe) 호출
   • Codex Micro-Eval Assist (optional): 핵심 가정 + [verified: source] 부재 + primitive/contract 확인 비용 높음 시 → /fz-codex micro-eval "이 가정 검증" (effort=medium, 1-shot). Lead 판단으로 호출, 자동 발동 ❌ — 새 Phase/Gate 신설 ❌ (33차 default = action 정합).
3. probe 결과 통합: discover 산출물에서 3 axes 모두 verified 가정만 Plan 차원에 포함

Gate 0c: Constraints Verified for Plan

• primitive 의존 가정 모두 식별?
• 각 가정의 3 axes (존재 / 권한·경계 / 결과 contract) 모두 분류 완료? (32차 방어)
• 미검증 axis는 Plan 차원에서 제외 또는 explicit assumption tag?
• probe 필요 시 /fz-discover 선행 완료?
• 미통과 시 → ⛔ Plan 작성 차단

Phase 0.5: Direction Challenge

Default = action with proportional verification (참조: modules/lead-action-default.md). verification escalation은 명시적 risk signal 발생 시에만.

발동 조건

절차

1. 요구사항 + 현재 아키텍처 대조:

   • Grep → 기존 유사 구현 탐색
   • mcp__serena__get_symbols_overview → 대상 영역 구조 파악
   • CLAUDE.md ## Architecture 기준으로 접근 방향 평가

2. 6개 관점 비판적 검토 (TEAM: review-direction, SOLO: Lead 직접):

   • Structural Fit: 현재 구조에 자연스러운가?
   • Alternative Paths: 근본적으로 다른 접근은? (대안 최소 2개)
   • Extensibility: N배 확장 시 유지 가능한가?
   • Existing Pattern Reuse (41차 Reuse-First): 기존 패턴을 재활용할 수 있는가? 신호 기준: universal*/extensible*/generic*/common* 명명 + 5+ 사용처 + URL-agnostic API 시그니처 → 신규 작성 default 차단. 예외: 레거시 (마지막 수정 6개월+ 또는 deprecated 태그) 시 신규 작성 정당
   • Maintenance Cost: 장기 유지보수 비용은 합리적인가?
   • Over-Engineering Risk: 현재 요구 대비 과하지 않은가?

3. 방향 판정:

   • PROCEED → Phase 1 진입
   • RECONSIDER → 대안 비교표 + 사용자 확인 후 진입
   • REDIRECT → 대안 강력 권고 + 사용자 확인 필수

4. ⛔ 방향 판정 기록 (항상):

   • ASD 활성: {WORK_DIR}/plan/direction-challenge.md에 판정 결과 + 대안 비교 기록
   • 비ASD: write_memory("fz:checkpoint:plan-direction", "판정: {PROCEED/RECONSIDER/REDIRECT}. 대안: {요약}. 선택근거: {1줄}") 형식 참조: modules/context-artifacts.md

Gate 0.5: Direction Validated

• 6개 관점 검토 완료?
• 대안 최소 2개 제시?
• 구조 결정별 대안 ≥2 + trade-off 기록? (SOLO 조기 체크 — Workflow 모드의 병합 확인은 Gate 1 담당. 답습/미러링이면 3축 — 45차)
• 방향 판정 (PROCEED/RECONSIDER/REDIRECT)?
• RECONSIDER/REDIRECT 시 사용자 확인?
• 구조/경계 포크 결단 시 유형 분류 — (가) 코드 read/grep으로 정답이 1개로 좁혀지는 엔지니어링 판단 → 확신 권고+근거+"이의 없으면 진행"(옵션 메뉴화 금지) / (나) 제품·디자인·팀 컨벤션 소유 → AskUserQuestion. ⛔ 경계(PR/커밋): plan 분할 제안=판단 입력≠경계 권위 (1커밋=1관심사+컴파일+1결정 trace). [candidate: 2 session evidence] (F5·F6, active:≥3 — project_fz_harness_holes.md)

Phase 0.7: Sprint Contract (T2-B, TEAM mode)

발동: TEAM mode + (5+ Step Plan 또는 Cross-skill 변경). 단순 수정/탐색 스킵.

Codex가 구현 시작 전 "성공 기준" Sprint Contract 작성 → Claude 동의/수정 → Phase 1 진입. 사후 수정 비용 감소.

• 절차: modules/sprint-contract.md §절차 (4-step)
• Schema: modules/sprint-contract.md §Schema (yaml: success_criteria + anti_criteria + scope_boundary)
• Lead Decision: agree → Phase 1 / modify → Codex re-verify 1회 (한도) / reject → Phase 0.5 재진입

Gate 0.7: Sprint Contract Agreed

• Codex Sprint Contract 작성 완료? (sprint-contract-codex.md 또는 fz:checkpoint:sprint-contract)
• 모든 SC가 measurable + binary 판정 가능?
• anti_criteria 명시? (제거/리팩토링 작업 시)
• Lead 동의 (agree) 또는 modify 후 합의?
• 미통과 시 → ⛔ Phase 1 작성 차단

Phase 0.7 출처: Anthropic Harness Engineering 패턴 B (2026-03) + Plan v3.1.3 §T2-B. 학술 근거: modules/cross-validation.md §이론 근거 (Generator≠Evaluator + MoA collaborativeness).

Phase 1: Deep Planning

프로젝트 규칙: CLAUDE.md ## Architecture 섹션을 따른다. 본문: modules/plan-deep-planning.md 참조 (Level 3) — 9 절차 (요구사항 분해, Exhaustive Impact Scan a-f, API 확인, Clean Architecture, SuperClaude, 설계 스트레스 테스트 Q1-Q6, RTM, 계획 출력, Transformation Spec, 계획 파일 기록).

절차 요약

1. 요구사항 구조 분해 (discover 산출물 활용)
2. 코드베이스 영향 분석 + ⛔ Exhaustive Impact Scan a-f (텍스트 검색/런타임 도달성/사이드이펙트/Dead code/소비자 스캔/Symbol Inventory)
3. API/라이브러리 문서 확인 (Context7)
4. Clean Architecture 원칙 확인 5a. SuperClaude 연계 (sc: 명령어) 5b. 설계 스트레스 테스트 Q1-Q6 (Evaluator-Optimizer 패턴, max 2회 반복)
5. ⛔ RTM 작성
6. 구조화된 계획 출력 (리스크 매트릭스 + Anti-Pattern Constraints + Implication Register)
7. ⛔ Transformation Spec 작성 (패턴 변환 Step 시)
8. ⛔ 계획 파일 기록 (compact recovery)

각 절차 상세는 modules/plan-deep-planning.md 참조. 트리밍 비저하 원칙(single source: guides/prompt-optimization.md §1 보충 3a)으로 Gate 1 + Why(H1)는 본 SKILL에 보존.

Gate 1: Plan Ready

Why (H1): 영향 범위가 불완전하면 구현 시 예상 외 파일을 건드리게 되고, 리뷰에서도 범위 밖 변경을 놓친다.

• ⛔ Gate 0 (ASD Pre-flight) 통과했는가?
• 영향 범위 분석 완료?
• ⛔ Exhaustive Impact Scan 4단계 수행 완료? (반성 5차)
  • 텍스트 전수 검색(Grep)으로 심볼 기반 결과와 대조했는가? Evidence: Grep("{타입명}") → {N}건 vs find_referencing_symbols → {M}건
  • 각 진입점의 런타임 도달성을 검증했는가? (latent 표기 포함)
  • 기존 액션 패턴의 사이드이펙트/순서 의존성을 분석했는가?
  • 관련 파일의 dead code를 감지했는가?
  • ⛔ 모듈화 작업이면 소비자 코드 품질 스캔(e단계)을 수행했는가?
  • ⛔ import 제거 작업이면 Symbol Inventory(f단계)를 수행했는가?
• API 문서 확인 완료? (새 API 사용 시)
• 기존 패턴과 일관성 확인?
• 구현 단계가 명확하게 정의?
• 설계 스트레스 테스트(Q1-Q6) 수행 완료?
• 소비자 영향이 식별되었으면 계획에 반영?
• 대안 패턴 최소 1개 제시?
• 리팩토링 작업이면 Anti-Pattern Constraints 작성?
• ⛔ 새 SPM 패키지 생성이면 Chore Step 포함? (.gitignore .build, Package.resolved, pbxproj 등록)
• ⛔ 모듈화 작업이면 Concern Classification 수행? (각 public type의 관심사가 모듈 책임에 부합)
• ⛔ 패턴 변환 Step에 Transformation Spec 작성? (원본 스레드/에러/추상화/언어 제약 확인)
• ⛔ Transformation Spec의 기술적 주장에 [verified: source] 태그가 있는가? (Default-Deny)
• ⛔ "실행 스레드"가 Zero-Exception 규칙을 준수하는가?
• ⛔ 요청 파라미터 키 목록이 원본과 일치하는가?
• 구조 결정 옵션 테이블 포함 + 사용자 보고 제시? (Workflow 모드면 directionAlternatives 병합 확인. 답습/미러링이면 3축 필수 — 45차)
• ⛔ 계획 기록 완료? (ASD: 파일, 비ASD: Serena checkpoint)

Gate 증거 첨부 (H2 원칙 — self-check 보완): 결정론적 도구 출력이 있는 Gate 항목은 Evidence: 행에 도구 결과 요약을 기록한다. self-check "완료?"보다 도구 출력이 신뢰할 수 있다.

Phase 1.5: Swift Anti-Pattern Pre-block (Swift/iOS 프로젝트 한정)

발동: CLAUDE.md ## Architecture가 Swift/iOS 지정 + Plan에 SwiftUI/Concurrency/패턴 변환 포함 시 필수. 비Swift/iOS는 스킵. 본문: modules/swift-anti-pattern-preblock.md 참조 (Level 3) — 3 원칙(P1 SwiftUI 결정 / P2 Concurrency isolation / P3 패턴 변환 보존) + 각 원칙 token + Few-shot.

Gate 1.5: Swift Anti-Pattern Pre-block 통과

• Swift/iOS 프로젝트 + SwiftUI/Concurrency/패턴 변환 plan? (해당 시 modules/swift-anti-pattern-preblock.md Read 후 진입)
• P1 SwiftUI 결정 명시? (owner / availability / View 책임)
• P2 Concurrency isolation 범위 결정? (scope / 병렬화 / continuation 정당화)
• P3 패턴 변환 시 원본 동작 보존? (스레드 / defer-await / enum catch)
• 1건 미해결 → ⛔ Phase 2 차단

발동 시 행동: modules/swift-anti-pattern-preblock.md Read + modules/plugin-refs.md 역방향 트리거 섹션 강제 참조 + 3 원칙 점검표 통과 후 Phase 2 진입.

Phase 2: Plan Validation

절차

# 계획 검증 실행
검증 도구로 계획 검증 위임

검증이 수행하는 작업:

• 계획 전송 (cross-model 검증, effort: high)
• 응답 파싱
• Issue Tracker에 이슈 자동 기록
• 이슈 요약 반환

3.5. ⛔ 검증 결과 기록 (항상):

• ASD 활성: {WORK_DIR}/plan/verify-result.md에 verdict + 이슈 요약 기록
• 비ASD: write_memory("fz:checkpoint:plan-verify", "verdict: {approved/rejected}. 이슈: {N}개. Critical: {요약}")

Gate 2 전제조건

• 검증 verdict가 approved 또는 사용자 승인

Phase 3: Feedback Integration

절차

1. 피드백 심화 분석:
   • mcp__sequential-thinking__sequentialthinking → 이슈별 심각도 분류
     • Critical: 즉시 수정 필수
     • Major: 수정 권장
     • Minor: 선택적 수정

1b. ⛔ Scope Challenge (이슈당 필수): 각 Codex 이슈를 플랜에 반영 전 modules/scope-challenge.md Q-S1~S4 실행 → scope_disposition 분류. Lead는 Codex 결과를 읽기 전 독립 판정 후 비교 (Generator≠Evaluator).

2. 요구사항 일치 검증:

   • mcp__sequential-thinking__sequentialthinking → 수정 전후 요구사항 부합도 단계별 비교
   • /sc:reflect → 자체 검증

3. 사용자 의사결정 (AskUserQuestion):

   • 수정 후 Phase 2 재검증
   • 현재 계획으로 구현 진행
   • 추가 논의

4. ⛔ 수정 계획 기록 (항상 — compact recovery 필수):

   • ASD 활성: plan-v{N+1}.md 생성 + 최종 승인 시 plan-final.md 복사 + index.md 업데이트
   • 비ASD: write_memory("fz:checkpoint:plan-final", "최종 계획: Steps {N}개. 피드백 반영: {요약}. verdict: approved")

5. Refactoring Mode 감지 (P0-light): intent-triggers에 리팩토링/치환/흡수/migration 매칭 시 AskUserQuestion 1회 — "이 작업은 리팩토링 감지. refactoring-aware 분류(Q-S5 Appendix 활성)를 적용할까요?" 사용자 예 시 Q-S5 활성, 아니오 시 기존 flow.

Gate 2: Validation Passed

• Critical 이슈 모두 해결?
• 사용자 승인 완료?
• 수정된 계획이 요구사항과 일치?

Few-shot 예시

BAD (구조 분해 부족):
## 계획: 새 ContentDetail 화면 추가
Step 1: ContentDetailRIB 만들기
Step 2: API 연동
Step 3: UI 구현
→ 영향 분석 없음, Step이 막연

GOOD:
## 계획: 새 ContentDetail 화면 추가
### 영향 분석
- 변경: HomeInteractor (라우팅), HomeRouter (child 추가)
- 생성: ContentDetail{Builder,Router,Interactor,ViewController}
- 참조: ContentRepository (기존), ContentUseCase (기존)
### Steps
Step 1: ContentDetailBuilder 생성 (DI: ContentRepository, ImageCacheUseCase)
Step 2: HomeRouter에 ContentDetail attach/detach 추가
Step 3: ContentDetailInteractor → ContentUseCase → ContentDetailPresenter 데이터 흐름
Step 4: ContentDetailViewController SwiftUI 기반 UI
### 리스크 매트릭스
| Q1 다중성 | ContentDetail이 여러 진입점(Home/Search/MyPage)에서 호출 | listener 프로토콜 통일 필요 |

Boundaries

Will: 요구사항 분해, 영향 분석, Serena 탐색, 구현 계획 출력, 계획 검증 Will Not: 코드 수정 (→ /fz-code), 빌드 실행 (→ /fz-code)

light 모드 (40차 simplified mode)

사용자 신호 "그냥/가볍게/단순/빠르게" 감지 또는 /fz-plan light "..." 호출 시:

• Phase 1 (Deep Planning)만 실행 — 구조 분해 + 영향 분석 + Step 출력
• Phase 0.5 (Direction Challenge) 생략 (단순 수정 patterns 대상)
• Phase 2 (Validation) + Phase 3 (Feedback) 생략 (Codex verify 미호출)
• Stress Test Q1-Q6 생략, 리스크 매트릭스 간소화
• Anti-Pattern Constraints 작성 생략 (리팩토링 작업 외)
• 단 산출물이 전수/카운트/부정 주장 포함 시 Coverage Gate(cross-validation.md §Coverage Gate) 적용 — light에서도 생략 불가 (검증 경계)
• 산출물: {WORK_DIR}/plan/plan-light.md (간소화 형식)

조건: 메모리 40차 trigger 키워드 + 단순 수정/추가 작업에만. 새 아키텍처 결정 시 full 모드 강제.

에러 대응

Completion → Next

Gate 2 통과 후:

/fz-code "검증된 계획대로 구현해줘"