live-verifylisted

# Live Verify: 실제 제품을 유저처럼 조작하여 E2E 검증 작업 계획에서 검증 기준을 설정하고(Phase 1), 구현 후 실제 제품을 브라우저/CLI/API로 조작하여 검증한다(Phase 2). 코드 리뷰나 린트가 아닌, **유저와 완전히 동일한 방식**으로 동작을 확인한다. > **핵심 철학**: "코드가 맞다"가 아니라 "제품이 동작한다"를 증명한다. --- ## 절대 원칙 1. **실제 제품을 조작한다.** 단위 테스트/코드 리뷰가 아닌, 로컬에서 띄운 제품을 에이전트가 직접 클릭/입력/확인한다. 2. **모든 질문은 AskUserQuestion 도구로.** 일반 텍스트로 질문하지 않는다. 3. **가설 기반 질문.** 열린 질문 대신 구체적 옵션을 제시한다. 4. **실패하면 고친다.** 검증 실패 시 원인을 분석하고 코드를 수정한 뒤 재검증한다. **시나리오당 최대 5회** (`수정 예산` 절 참조). 5. **중간 저장.** Phase 1 완료 시 시나리오 파일을, Phase 2 완료 시 보고서 파일을 반드시 저장한다. 6. **PASS는 증거로만 선언한다.** 관측된 값(snapshot 텍스트, stdout, HTTP 상태·본문) 없이 PASS를 적지 않는다. "동작하는 것 같다"는 FAIL이다. 7. **시나리오를 고쳐서 통과시키지 않는다.** 기대결과를 실제 결과에 맞추는 것은 검증이 아니라 은폐다. 시나리오가 틀렸다고 판단되면 코드를 고치지 말고 멈추고 사용자에게 확인한다. 8. **고친 뒤에는 이미 통과한 것을 다시 돌린다.** 회귀 가드 없는 순차 검증은 앞 시나리오를 조용히 깨뜨린다. --- ## 호출 방식 | 명령 | 동작 | |------|------| | `/live-verify` | 자동 감지 — `docs/verify/` 에 시나리오 파일이 있으면 Phase 2, 없으면 Phase 1부터 | | `/live-verify plan` | Phase 1만 실행 (검증 시나리오 생성) | | `/live-verify run` | Phase 2만 실행 (기존 시나리오 파일 필요) | --- ## 진입 판단 스킬 호출 시 자동으로 상태를 판단한다: 1. 사용자가 `plan` 또는 `run`을 명시했으면 해당 Phase로 직행 2. 명시하지 않았으면: - `docs/verify/` 에서 최신 시나리오 파일(`*-scenarios.md`)을 Glob으로 검색 - 있으면 → Phase 2로 진행 (해당 파일 사용) - 없으면 → Phase 1부터 시작 입력 소스 판단: | 입력 상태 | 판단 기준 | 행동 | |-----------|-----------|------| | **인자로 경로 제공** | 파일 경로가 함께 전달됨 | 해당 파일을 읽고 분석 | | **PRD 자동 감지** | `docs/prd/` 에 PRD 파일 존재 | 최신 PRD를 읽어 시나리오 생성 | | **코드 경로 제공** | src/, app/ 등 코드 디렉토리 | 코드를 분석하여 기능 도출 → 시