115 lines
6.0 KiB
Markdown
115 lines
6.0 KiB
Markdown
---
|
|
name: "review-verification"
|
|
description: "Review and validate SDLC Verification document for consistency, completeness, and readiness for approval"
|
|
argument-hint: "예: sdlc-001 또는 docs/sdlc/sdlc-001_20260417_stage-pilot/5_verification.md"
|
|
agent: "agent"
|
|
---
|
|
SDLC Verification 문서를 체계적으로 검토하고, 승인 가능한 상태인지 판단한다.
|
|
|
|
목표:
|
|
- `5_verification.md` 파일의 일관성 확인 (검증 항목/성공 기준/결과 간 중복 및 충돌)
|
|
- 기술적 오류, 잘못된 표현, 명확하지 않은 문구 식별
|
|
- AI agent에게 할당된 플레이스홀더(`{{...}}`) 중 판단/결정 가능한 항목 처리
|
|
- 플레이스홀더 중 사용자 결정이 정말 필요한 항목만 남겼는지 확인
|
|
- 최종 승인 가능 상태 판단
|
|
|
|
---
|
|
|
|
## 검토 절차
|
|
|
|
### 1. 입력 해석
|
|
|
|
- 사용자가 제공한 문서 경로 또는 CYCLE_ID에서 `5_verification.md` 파일 위치를 확정한다.
|
|
- 파일이 없으면 입력값을 다시 확인하도록 사용자에게 피드백하고 중단한다.
|
|
- `4_implementation.md`와 `1_discovery.md`도 함께 읽어 인계 내용 및 성공 기준 정합성 확인에 사용한다.
|
|
|
|
### 2. 인계 정합성 검토
|
|
|
|
- 구현 완료 태스크 목록이 Implementation `# 1`/`# 2`와 내용/수량이 일치하는가
|
|
- 검증 항목(VC-N)이 Discovery `# 7` 성공 기준(S-N) 및 FR과 연결되어 있는가 (`# 2` 성공 기준 연결 섹션 확인)
|
|
- 이월된 오픈 질문이 Implementation `# 4`의 `Deferred` 항목과 대응하는가
|
|
|
|
### 3. 일관성 검토 (모든 섹션 대상)
|
|
|
|
- **VC 번호 연속성**: `# 2` 검증 항목과 `# 3` 검증 결과의 VC-N 번호가 누락 없이 연속이고 일치하는가
|
|
- **성공 기준 측정 가능성**: `# 2` 각 VC 항목의 성공 기준이 구체적이고 측정 가능한가 ("정상 동작"처럼 모호한 표현 금지)
|
|
- **검증 결과 정합성**: `# 3` 통과/실패 집계가 실제 결과 테이블과 일치하는가
|
|
- **결함 연결성**: `# 4` BUG 항목이 검증 항목(VC-N)과 연결되는지 확인
|
|
- **숫자 연속성**: R-N, OQ-N, BUG-N 번호가 누락 없이 연속인지 확인
|
|
|
|
### 4. 표현 검토 (모든 텍스트)
|
|
|
|
- **문법**: 문장 구조, 주술 호응, 시제 일관성
|
|
- **명확성**: "정상적으로", "충분히", "대략" 같은 모호한 표현 식별
|
|
- **작성 수준**: 기술 문서 기준의 형식적 톤 유지. 비공식 표현 제거
|
|
- **오타**: 한글 띄어쓰기, 숫자 오류, 테이블 형식 검증
|
|
|
|
### 5. 플레이스홀더 처리
|
|
|
|
모든 `{{...}}` 플레이스홀더를 나열하고 각 항목의 의도를 파악한다.
|
|
|
|
AI agent가 채울 수 있는 항목:
|
|
- `{{..._DECISION:...}}` 형태 — 문서 내 다른 섹션이나 Discovery/Implementation 내용으로 추론 가능한지 확인
|
|
- 검증 방법(`VER_METHOD_N`), 결함 심각도(`BUG_SEVERITY_N`) 등 구조적으로 추론 가능한 항목
|
|
|
|
사용자 결정이 필요한 항목 (플레이스홀더 유지):
|
|
- 검증 담당자(`VER_OWNER_N`)
|
|
- 결함 재작업 내용(`BUG_FIX_N`): 실제 구현 변경 필요
|
|
- Freeze 확정 담당자(`CONFIRMED_BY`)
|
|
|
|
각 항목에 대해 아래 중 하나를 판단한다:
|
|
- **채울 수 있음**: 문서 내 맥락, Discovery/Implementation 내용으로 합리적 추론 가능 → 실제 내용으로 치환
|
|
- **판단 불가능**: 사용자/승인자 결정, 실제 검증 수행 필요 → 플레이스홀더 유지하되 명확성 강화
|
|
|
|
처리 결과를 별도 목록으로 보고한다.
|
|
|
|
### 6. 섹션별 최소 검수 기준
|
|
|
|
| 섹션 | 최소 기준 |
|
|
|------|---------|
|
|
| `# 0 문서 상태` | 메타데이터 완성도 확인 (CREATED_AT_KST, IMP_PATH 채워졌는가) |
|
|
| `# 1 Implementation 인계 요약` | 태스크 최소 1개 이상, Implementation 태스크와 1:1 대응 여부 |
|
|
| `# 2 검증 계획` | VC 최소 2개 이상, 각 VC에 검증 방법과 측정 가능한 성공 기준이 있는가 |
|
|
| `# 2 성공 기준 연결` | Discovery S-N이 하나 이상의 VC-N과 연결되었는가 |
|
|
| `# 3 검증 결과` | VC-N과 결과 테이블의 행 수가 일치하는가, 집계 숫자가 맞는가 |
|
|
| `# 4 결함` | BUG `Open` 상태가 있으면 재작업 내용이 명시되었는가 |
|
|
| `# 5 리스크/오픈 질문` | OQ `Open` 상태가 있으면 종료 조건이 명시되었는가 |
|
|
| `# 6 확인 체크` | 체크 항목이 구체적이고 측정 가능한가 |
|
|
| `# 8 사용자 결정 필요` | 플레이스홀더가 실제 `{{...}}` 형식인가 (단순 문장 아닌가) |
|
|
| `# 9 Freeze` | Handoff Decision과 Rationale이 채워졌는가 |
|
|
|
|
### 7. 최종 승인 판단
|
|
|
|
- **승인 가능 (Ready for Release)**:
|
|
- 모든 VC 항목이 "통과" 상태인가
|
|
- BUG `Open` 상태 항목이 없는가 (Deferred는 근거와 함께 허용)
|
|
- Discovery 성공 기준(S-N)이 모두 VC와 연결되어 검증되었는가
|
|
- `# 5` 오픈 질문에 `Open` 상태 항목이 없거나 모두 `Deferred` 처리 완료인가
|
|
- 남은 플레이스홀더는 모두 정당한가 (사용자/승인자 결정이 정말 필요)
|
|
- Freeze 플래그가 준비되었는가 (`READY_FOR_RELEASE: true`로 변경 가능한가)
|
|
- **조건부 (Pending Minor Changes)**:
|
|
- 일부 VC 항목이 아직 "미완료"이나 곧 완료 예정
|
|
- BUG 항목 심각도가 낮고 재작업 계획이 명확한 경우
|
|
- **보류 (Hold)**:
|
|
- VC 항목에 "실패" 또는 "블로킹" 상태 존재, BUG `Open` 잔여, S-N 연결 누락 등 근본적 재검토 필요
|
|
|
|
---
|
|
|
|
## 응답 형식
|
|
|
|
- **검토 결과 요약**
|
|
- Implementation 인계 정합성 오류 (있으면 나열)
|
|
- 발견된 일관성 오류 (있으면 나열)
|
|
- 표현/문법 오류 (있으면 나열)
|
|
- 섹션별 완성도 (예: `# 2` VC-3 성공 기준 모호)
|
|
|
|
- **플레이스홀더 처리 결과**
|
|
- 채워진 항목 (예: `{{VER_METHOD_2}}` → `자동` 로 치환)
|
|
- 유지된 항목 (예: `{{VER_OWNER_1:TBD}}` → 검증 담당자 지정 필요로 유지)
|
|
|
|
- **수정 사항 목록** (적용된 변경)
|
|
|
|
- **최종 판단**
|
|
- 승인 가능 / 조건부 / 보류
|
|
- 근거 및 남은 작업 사항
|