verify-fix

name	verify-fix
version	0.3.0
description	개발자가 수정한 버그를 재테스트합니다. Jira에서 원본 버그를 가져오고, 브라우저에서 재현 단계를 다시 실행하며, 회귀 여부를 확인하고, 버그 상태를 업데이트합니다. 티켓이 Done으로 넘어가기 전 SDT 워크플로우의 마지막 단계입니다. 사용 시점: "수정 검증", "재테스트", "이거 고쳐졌어?", "BUG-123 확인", "BUG-123 검증". 사용하지 않는 경우: 최초 QA 실행(/qa 사용), 새 버그 등록, 기능을 처음 테스트할 때.
tool-groups	["bash","read","write","edit","glob","grep","ask","jira","browser"]
preamble-tier	2

/verify-fix: 버그 수정 재테스트 및 검증

SDT 파트너로서 개발자의 버그 수정이 정상 동작하는지 검증합니다. Jira에서 원본 버그를 가져오고, 브라우저에서 재현 단계를 다시 실행하며, 관련 기능의 회귀 여부를 확인하고, 결과에 따라 버그 상태를 업데이트합니다.

이 스킬은 코드를 수정하지 않습니다. 다른 사람이 수정한 내용을 검증합니다.

제약 조건

1. 원본 재현 단계를 정확히 따르세요. 임의로 변경하지 마세요. 단계가 불명확하면 SDT나 개발자에게 확인하세요.
2. 코드를 수정하지 마세요. 수정이 동작하지 않으면 개발자에게 돌려보내세요.
3. 항상 회귀 여부를 확인하세요. 다른 곳을 망가뜨리는 수정은 수정이 아닙니다.
4. 수정 전후 증거를 확보하세요. 원본 스크린샷이 없으면 그 사실을 기록하세요 — 비교할 수 없는 상태에서 비교했다고 주장하지 마세요.
5. SDT가 Jira 변경을 승인합니다. SDT 확인 없이 버그 상태를 전환하거나 회귀 버그를 등록하지 마세요.
6. 회귀 테스트 부재를 표시하세요. 섹션 9.5에 따라, 검증된 수정에는 재발을 방지하는 테스트가 있어야 합니다.
7. 반드시 브라우저를 사용하세요. 코드만 읽고 검증하지 마세요.

---

1단계: 버그 컨텍스트 로드

입력: 사용자가 버그 키(예: BUG-123)를 제공하거나 "PROJ-789 수정 검증해줘"라고 요청합니다.

방법론 참조 문서를 로드합니다 ({{REFERENCE_PATH}}/playbook/):

• defect-lifecycle.md — 버그 상태, SLA 기대치, 회귀 테스트 요구사항

버그 컨텍스트 가져오기 (Jira MCP가 있으면 사용, 없으면 SDT에게 요청)

1. .qabuddy.json 확인 (파일이 있으면) — 컨텍스트 소스와 팀 모드를 읽습니다.
   • contextSource: "spec" → 질문 전에 워크스페이스에서 스펙 파일을 먼저 검색
   • contextSource: "chat" → Jira를 건너뛰고 SDT에게 직접 컨텍스트 요청
   • contextSource: "jira" 또는 설정 없음 → 기본 동작
2. 버그 티켓: 요약, 설명, 재현 단계, 심각도, 우선순위, 상태, 연결된 상위 티켓, 수정 버전 / PR 링크, 보고자, 담당자
   • 상태가 "Fixed" 또는 그에 해당하는 상태가 아니면 경고합니다: "이 버그가 아직 수정 완료로 표시되지 않았습니다. 그래도 검증할까요?"
3. 원본 QA 보고서 (/qa로 버그를 등록한 경우):
   • features-kb/features/{EPIC-KEY}/qa-reports/에서 찾습니다
   • 원본 실패 테스트 케이스와 스크린샷("수정 전")을 로드합니다
4. 연결된 PR / 커밋: Jira 코멘트에서 PR 링크를 확인하고, git log에서 버그 키를 참조하는 커밋을 확인합니다

수정 배포 확인

테스트 전에 수정 사항이 접근 가능한지 확인합니다:

• 로컬호스트: 수정 브랜치가 체크아웃 또는 머지되었는지 확인
• 스테이징: 배포에 수정 사항이 포함되었는지 확인 (커밋 해시, 배포 로그, 또는 SDT에게 확인)

배포되지 않은 경우 BLOCKED로 보고합니다: "{BUG-KEY}의 수정 사항이 {URL}에 배포되지 않은 것으로 보입니다."

---

2단계: 재현 단계 재실행

버그 티켓에 기록된 원본 재현 단계를 정확히 따릅니다.

각 단계별 절차:

1. 브라우저에서 실행합니다
2. 실제와 기대를 비교합니다 (기대 = 원래 버그가 아닌 수정된 동작)
3. 스크린샷을 캡처합니다 ("수정 후" 증거)
4. 콘솔에서 새로운 오류를 확인합니다

결과를 기록합니다:

### 재현 시도
**Bug:** {BUG-KEY}
**티켓의 재현 단계:** 정확히 따름 / 수정함 (사유 설명)

| 단계 | 수행 내용 | 기대 결과 (수정 후) | 실제 결과 | 일치 여부 |
|------|--------|------------------|--------|--------|

**스크린샷 (수정 전 — 원본 보고서):** {경로}
**스크린샷 (수정 후 — 이번 검증):** {경로}
**Console:** {정상 / 오류}

수정이 동작하지 않는 경우:

• 버그가 지속되는 증거를 캡처합니다
• 원본과의 차이를 기록합니다 (동일한 현상? 부분 수정? 새로운 현상?)
• 직접 수정하지 마세요

---

3단계: 회귀 확인

3.1 관련 테스트 케이스 재실행

원본 버그가 KB 테스트 케이스가 있는 티켓에 연결된 경우:

• 버그가 등록된 AC에 대한 테스트 케이스를 다시 실행합니다
• 같은 티켓의 인접 AC에 대한 테스트 케이스를 다시 실행합니다
• 모두 PASS여야 합니다

3.2 인접 페이지 확인

• 관련 페이지 2-3개를 이동하며 확인합니다
• 시각적 깨짐, 콘솔 오류, 동작 불량을 점검합니다
• 동일한 사용자 플로우와 업스트림/다운스트림 각 한 단계에 집중합니다

3.3 회귀 테스트 존재 여부

섹션 9.5에 따라, 검증된 수정에는 회귀 테스트가 있어야 합니다:

• 개발자가 이 버그에 대한 테스트(Playwright 또는 단위 테스트)를 추가했는지 확인합니다
• 없는 경우: "{BUG-KEY}에 대한 회귀 테스트가 없습니다. /test-cases {TICKET-KEY} --update로 추가하는 것을 권장합니다."

---

4단계: 자체 검증

판정을 내리기 전에 다음을 확인합니다:

1. 재현 단계를 정확히 따랐는지 (변경한 경우 사유가 문서화되었는지)
2. 수정 전후 스크린샷이 있는지 (없으면 그 사실을 기록했는지)
3. 회귀 확인이 정확한 버그뿐 아니라 관련 기능을 포함했는지
4. 수정 검증과 회귀 확인 후 콘솔을 확인했는지
5. 형식 확인: 보고서에 판정, 재현 테이블, 회귀 테이블, 다음 단계가 포함되어 있는지

누락된 항목을 보완합니다. 한 번만 확인합니다.

---

5단계: 판정 및 업데이트

판정

판정	의미	Jira 조치
VERIFIED	수정이 동작하며 회귀 없음	버그를 Verified/Closed로 전환
FAILED	버그가 여전히 재현됨	새로운 증거와 함께 버그를 Open으로 되돌림
REGRESSION	수정은 동작하나 다른 곳이 깨짐	원본은 Verified로 유지하고 회귀에 대해 새 버그 등록

검증 보고서

다음 두 위치에 작성합니다:

• features-kb/features/{EPIC-KEY}/qa-reports/{BUG-KEY}-verify-{YYYY-MM-DD}.md
• .qa-reports/{BUG-KEY}-verify-{YYYY-MM-DD}.md

# 수정 검증: {BUG-KEY}
**Bug:** {BUG-KEY} — {요약}
**상위 티켓:** {TICKET-KEY}
**수정자:** {담당자 / PR 링크}
**검증일:** {YYYY-MM-DD}
**URL:** {대상}

## 판정: {VERIFIED | FAILED | REGRESSION}
{한 줄 요약}

## 재현 결과
| 단계 | 수행 내용 | 기대 결과 | 실제 결과 | 일치 여부 |
|------|--------|----------|--------|--------|

**수정 전:** {원본 보고서의 스크린샷}
**수정 후:** {이번 검증의 스크린샷}

## 회귀 확인
| 확인 항목 | 결과 | 비고 |
|-------|--------|-------|
| 관련 테스트 케이스 | {N}/{N} 통과 | |
| 인접 페이지 | 정상 / 이슈 있음 | |
| Console | 정상 / 오류 | |
| 회귀 테스트 존재 | 있음 / 없음 | |

## 다음 단계

**Status:** DONE | DONE_WITH_CONCERNS | BLOCKED
**Summary:** {한 줄 요약}
**다음 단계:** {다음에 할 일, 또는 "없음"}

상태 업데이트

변경 전에 SDT에게 제시합니다:

Jira MCP가 있는 경우:

• VERIFIED: Verified/Closed로 전환하고, 수정 확인 및 회귀 없음을 코멘트로 남깁니다.
• FAILED: Open으로 되돌리고, 새로운 재현 증거를 코멘트로 남깁니다.
• REGRESSION: 원본은 Verified로 유지하고, /qa 버그 등록 워크플로우를 통해 새 버그를 등록합니다.

Jira가 없는 경우:

• features-kb/features/{EPIC-KEY}/bugs/의 버그 파일에 판정을 업데이트합니다.
• REGRESSION인 경우: 새 버그 파일을 생성합니다. SDT가 직접 관리 도구에 등록합니다.

---

일괄 처리 모드

SDT가 "PROJ-789 수정 검증해줘" (여러 버그가 연결된 상위 티켓)라고 요청한 경우:

1. Fixed 상태의 연결된 버그를 모두 가져옵니다 (Jira에서 또는 SDT에게 목록 요청)
2. 각 버그를 순서대로 검증합니다
3. 요약을 제공합니다:

## 수정 검증 요약: {TICKET-KEY}
| Bug | Summary | 판정 | 회귀 여부 | 비고 |
|-----|---------|---------|-------------|-------|

**전체 결과:** {N}/{전체} 검증 완료. {N}건 여전히 실패. {N}건 회귀 등록.