# 검증 시나리오 시스템 구현 계획서

## 목표
코드 수정 후 "되겠지" 완료 선언 → 실제 안 됨 → 재수정 왕복을 물리적으로 차단하는 자동 검증 시스템 구축.

## 범위

### 포함
- Layer 1: Smart Test Filtering (기존 pytest 활용, 변경 파일 기반 자동 필터링)
- Layer 2: 시나리오 게이트 (impact_analyzer + scenario_runner + YAML)
- Layer 3: E2E Smoke (Playwright storageState, Lv.3+ 전용)
- qc_verify.py 통합 (scenario_gate verifier)

### 제외
- LLM 자율 시나리오 발산 (환각 리스크 — 미팅 합의)
- 기존 verifier 12개 수정 (그대로 유지)
- Firestore Emulator 도입 (별도 프로젝트)

## Phase 분리

### Phase 1 — Smart Test Filtering + 시나리오 게이트 기반
- `impact_analyzer.py`: AST + grep 기반 변경 영향 분석
- `scenario_runner.py`: YAML 시나리오 → pytest parametrize 실행
- `qc_verify.py`에 `scenario_gate` verifier 추가
- 초기 시나리오 YAML 시드 (insuwiki 5개, dashboard 5개)
- 빈 시나리오 = FAIL 정책

### Phase 2 — Playwright E2E + 인증
- storageState 기반 Firebase Auth 세션 관리
- P0 시나리오 5~10개 (InsuWiki 핵심 경로)
- boundingBox + overflow 조상 검사 포함
- Lv.3+ 작업에서만 필수 게이트

### Phase 3 — 운영 안정화
- 시나리오 YAML 축적 (프로젝트당 20~30개)
- LLM 초안 생성 → 아누 승인 워크플로우
- 실행 시간 최적화 (병렬화, 캐싱)

## 위임 계획
- Phase 1: dev1 + dev2 병렬 (impact_analyzer + scenario_runner 분리)
- Phase 2: dev3 (Playwright 전문)
- Phase 3: 운영 중 점진 축적

## 검증 기준
- Phase 1 완료 조건: qc_verify.py --gate에서 scenario_gate가 실행되고, must 시나리오 FAIL 시 .done 미생성
- Phase 2 완료 조건: InsuWiki 문서 페이지에서 Playwright가 렌더링 검증 통과