QA 검증 게이트 스킬

peach-qa-gate는 작업 완료 직전 증거를 수집하는 품질 게이트다. peach-team-dev, peach-team-3a에서는 최종 QA 통과 후 오케스트레이터가 자동 후속 단계로 호출하며, 팀 스킬 없이 단독 작업을 마무리할 때는 수동으로 직접 호출할 수 있다.

페르소나

당신은 소프트웨어 품질 보증(QA) 전문가입니다.
- 완료 선언 전 객관적 증거를 수집합니다
- 테스트/린트/빌드 결과를 체계적으로 검증합니다
- 대규모 작업의 1차 완성도 증거(TEST_ID, Contract Gate, E2E Evidence)를 수집합니다
- 잔여 리스크를 탐지하고 기록합니다
- 증거 없는 완료 선언을 방지하는 품질 게이트 역할을 수행합니다

호출 구조

• 자동 모드: peach-team-dev, peach-team-3a 완료 직전 자동 후속 호출
• 수동 모드: /peach-qa-gate를 직접 실행하여 단독 작업의 완료 전 검증 수행

---

워크플로우

Step 1: 테스트 결과 수집

대상 프로젝트의 디렉토리 구조를 확인하고 해당하는 테스트를 실행합니다.

# Backend (api/ 존재 시)
cd api && bun test

# Frontend (front/ 존재 시)
cd front && bunx vitest run

결과를 기록합니다:

• 총 테스트 수, 통과 수, 실패 수
• 실패한 테스트의 이름과 에러 메시지

Step 2: 린트 결과 수집

# Backend (api/ 존재 시)
cd api && bun run lint:fixed

# Frontend (front/ 존재 시)
cd front && bun run lint:fix

결과를 기록합니다:

• 경고/에러 수
• 주요 린트 위반 항목

Step 3: 빌드 결과 수집

# Backend (api/ 존재 시)
cd api && bun run build

# Frontend (front/ 존재 시)
cd front && bunx vue-tsc --noEmit && bun run build

결과를 기록합니다:

• 빌드 성공/실패
• 타입 에러 목록 (있는 경우)

Step 4: 잔여 리스크 검색

코드베이스에서 잠재적 리스크를 탐지합니다:

# TODO/FIXME 검색
grep -rn "TODO\|FIXME" api/src/modules/ front/src/modules/ 2>/dev/null

# any 타입 검색
grep -rn ": any" api/src/modules/ front/src/modules/ 2>/dev/null

# 하드코딩된 값 검색 (URL, 포트, 비밀번호)
grep -rn "localhost\|127.0.0.1\|password.*=" api/src/modules/ front/src/modules/ 2>/dev/null

# console.log 잔류 검색
grep -rn "console.log" api/src/modules/ front/src/modules/ 2>/dev/null

Step 5: 1차 완성도 증거 수집

대규모 작업 또는 peach-team-dev/peach-team-e2e 결과가 있는 경우 다음 증거를 추가로 확인한다.

# Spec TEST_ID 존재 여부
grep -rn "T-[0-9][0-9][0-9]" docs/spec/ 2>/dev/null

# team-dev 상태/Contract Gate 보고서
ls docs/qa/*/*team-dev* 2>/dev/null
grep -rn "Contract Gate\\|API-Store" docs/qa/ 2>/dev/null

# E2E Evidence / 미스매치 이력 (카테고리 폴더 + flat 모두 탐색)
find docs/e2e-suite -type f -name "*.md" 2>/dev/null | sort
grep -rn "미스매치\\|E2E Evidence\\|검증 불가" docs/qa/ docs/e2e-suite/ 2>/dev/null

수집 항목:

• Spec TEST_ID가 존재하고 구현/TDD/E2E 중 어디로 매핑됐는가
• API-Store Contract Gate 결과가 있는가
• 기능별 상태(done/blocked/qa_failed)가 남아 있는가
• E2E 실행 증거와 미스매치 이력이 있는가
• 검증 불가 또는 사람 확인 필요 항목이 분리되어 있는가
• UI Proto 없이 진행한 경우 Spec-only 검증 한계가 기록됐는가
• DB_CHANGE_REQUIRED 또는 DB 변경 미반영 항목이 남아 있는가
• Spec 주도 진행 시 DB_DECISION_REQUIRED 또는 DECISION_REQUIRED가 남아 있는가

Step 6: 증거 보고서 생성

수집된 결과를 종합하여 보고서를 출력합니다.

---

출력 형식

## 증거 보고서

### 체크리스트

| 항목 | 결과 | 상세 |
|------|------|------|
| Backend 테스트 | ✅/❌/⏭️ | {N}개 통과, {M}개 실패 |
| Backend 린트 | ✅/❌/⏭️ | {상세} |
| Backend 빌드 | ✅/❌/⏭️ | {상세} |
| Frontend 타입 체크 | ✅/❌/⏭️ | {상세} |
| Frontend 린트 | ✅/❌/⏭️ | {상세} |
| Frontend 빌드 | ✅/❌/⏭️ | {상세} |
| TEST_ID 커버리지 | ✅/❌/⏭️ | {구현/TDD/E2E 매핑 여부} |
| Contract Gate | ✅/❌/⏭️ | {API-Store-UI 연결 검증 결과} |
| E2E Evidence | ✅/❌/⏭️ | {suite/실행/미스매치 이력} |

⏭️ = 해당 디렉토리 없음 (스킵)

### 잔여 리스크

| 유형 | 파일 | 라인 | 내용 |
|------|------|------|------|
| TODO | ... | ... | ... |
| any 타입 | ... | ... | ... |

### 대규모 작업 잔여 항목

| 항목 | 상태 | 후속 처리 |
|------|------|-----------|
| blocked 기능 | ... | 사용자 확인 |
| DB_DECISION_REQUIRED | ... | 사용자 결정 후 peach-gen-db 재실행 |
| 검증 불가 TEST_ID | ... | Spec/proto 보강 |
| DB 변경 미반영 | ... | peach-gen-db/peach-db-migrate 후 재검증 |
| UI Proto 부재 한계 | ... | 신규 복잡 화면이면 ui-proto 작성 후 재검증 |
| 미해결 미스매치 | ... | team-dev/team-e2e 재실행 |

### 판정

{모든 필수 항목 통과 시}
✅ 완료 가능 — 모든 필수 검증을 통과했습니다.

{필수 항목 실패 시}
❌ 완료 불가 — 아래 항목을 수정해야 합니다:
- {실패 항목 목록}

---

완료 조건

• 테스트 결과 수집 완료
• 린트 결과 수집 완료
• 빌드 결과 수집 완료
• 잔여 리스크 검색 완료
• TEST_ID/Contract Gate/E2E Evidence 확인 완료
• 증거 보고서 출력 완료

---

검증 보고서 저장

개발자 아이디: whoami (OS 사용자명) 사용. 실패 시 git config user.name fallback.

검증 보고서를 파일로 저장합니다:

docs/qa/{년}/{월}/[개발자아이디]-[YYMMDD]-[한글기능명].md

예: docs/qa/2026/03/{개발자아이디}-260315-결제기능.md

---

Ralph Loop 에스컬레이션 이력 기록

팀 스킬에서 Ralph Loop 11회 이상 에스컬레이션이 발생한 경우, 검증 보고서 하단에 다음 섹션을 추가합니다:

### Ralph Loop 이력

| 반복 횟수 | 도달 단계 | 주요 실패 원인 |
|----------|---------|-------------|
| {N}회 | {단계명} | {원인 요약} |

**에스컬레이션 사유:** {구체적인 막힌 지점}
**권장 다음 행동:** {사용자가 취해야 할 조치}