Verification

---
name: verification
description: 구현 결과 검증 및 품질 게이트 통과 스킬
compatibility: omp
---

# Verification Skill

구현 완료를 실제 실행 증거로 판정합니다. 실행한 것만 검증으로 보고합니다.

## 검증 단계

### 0단계: 기준선 (코드를 고치기 전)

첫 수정 전에 변경이 닿을 범위의 테스트를 실행하고 명령, 통과·실패 수, 이미 실패하는 테스트 이름을 기록합니다. 기준선이 없으면 최종 실행에서 나온 실패가 이번 변경의 회귀인지 원래 있던 문제인지 가를 수 없습니다.

- 기준선에서 실패하는 테스트는 기존 실패로 적고, 작업과 관련 있을 때만 고칩니다.
- 기준선을 놓쳤는데 실패가 나오면 base 커밋의 별도 worktree에서 같은 테스트를 다시 실행해 판정합니다. 전체 실행에서만 실패하고 단독 실행에서 통과하면 부하에 따른 flake로 기록합니다.
- 기존 실패가 남아 있으면 "전부 green"이라고 보고하지 않습니다.

### 1단계: 요구사항과 수락 기준

요구사항과 acceptance 시나리오마다 조건 설정 → 동작 실행 → 결과 확인을 수행하고, 관찰한 출력값을 근거로 남깁니다. 엣지 케이스 처리 여부도 함께 확인합니다.

### 2단계: 자동화 게이트

Stack Profile 또는 project context에서 확인한 프로젝트 표준 명령으로 실행합니다.

- 빌드 또는 타입 체크
- 테스트 (동시성 코드는 race/thread-safety 플래그 포함)
- 린트
- 커버리지 — 기본 85% 이상, 프로젝트가 `workflow.coverage_threshold`로 다른 값을 선언하면 그 값 (`0`이면 수치 게이트 해제)

### 3단계: 동작 확인 (smoke)

변경된 경로를 실제로 실행해 관찰합니다. CLI/TUI/UI 변경은 해당 표면을 직접 띄워 확인하고, 런타임이 없으면 일회성 스크립트로 확인한 뒤 시각 검증을 못 했다는 사실을 함께 보고합니다.

### 4단계: 회귀 확인

프로젝트 테스트 스위트로 기존 동작이 유지되는지 확인합니다. 버그 수정이면 재현 케이스가 더 이상 실패하지 않는지 확인하고, 재현 테스트를 회귀 테스트로 남깁니다.

## 통과한 검사의 재사용

같은 검사를 반복하기 전에 `auto spec gates <SPEC-ID> --read-only --json`으로
현재 입력과 기존 근거를 확인합니다. `reusable`은 기록한 파일 범위가 일치한다는
뜻입니다. 명령·옵션·도구 버전·환경·외부 상태까지 같다고 보장하지는 않습니다.
그 조건이 달라졌거나 확인할 수 없으면 `--no-reuse`로 새 검증을 계획합니다.

실패·부분 실행·오래된 결과는 재사용하지 않습니다. 수정 후에는 영향받은 검사와
열린 리뷰 항목을 확인하고, 변경 없는 통과 검사는 단계가 바뀌었다는 이유만으로
반복하지 않습니다. 필수 보안·데이터 보호·인수 검사는 유효한 근거가 필요합니다.
공통 전체 검증은 작업자별로 반복하지 않고 통합한 변경에 대해 수행합니다.

## 검증 보고서

```markdown
## 검증 결과

- 요구사항: [x] {요구사항} — {확인 방법과 관찰 결과}
- 기준선: {명령} → N passed·M failed (기존 실패: {테스트 이름, 없으면 none})
- 게이트: {명령} → {결과} (빌드 / 테스트 N passed·M failed / 린트 / 커버리지 X% vs 임계값 Y%)
- 회귀 판정: {최종 실패 중 기준선에 없던 것, 없으면 none}
- 동작 확인: {실행한 명령 또는 시나리오} → {관찰 결과}
- 남은 리스크: {미검증 영역, 없으면 none}
```