SDD - Scenario-Driven Detection

SKILL.md

---
name: sdd
description: "Scenario-Driven Detection — AI 자율 추론 기반 논리 결함 탐지/수정 프레임워크. 기능 에러(crash, 500)가 아닌 '논리적으로 비정상인 동작'을 찾아 자동 수정한다. 사용 시점: (1) URL을 주고 웹사이트 논리 테스트 요청, (2) 소스코드 프로젝트의 UI/API 논리 검증 요청, (3) '시나리오 테스트', 'SDD 돌려줘', '논리 결함 찾아줘' 등의 요청. 플랫폼 무관(웹/모바일/API)."
---

# SDD — Scenario-Driven Detection

> 합리적 추론으로 "기능은 되지만 논리적으로 이상한" 동작을 찾아 고친다.

## 핵심 개념

기존 테스트가 잡지 못하는 영역:
- "편집" 버튼 → 대시보드로 이동 (crash 아님, 하지만 비정상)
- 삭제 후 목록에 여전히 존재 (API 200 반환, 하지만 비정상)
- 빈 목록인데 empty state 없이 그냥 빈 화면 (에러 아님, 하지만 비정상)

SDD는 AI가 코드 구조/네이밍/DOM을 보고 "이건 이렇게 동작해야 한다"를 스스로 추론하여 검증한다.

## 워크플로우

```
SCAN → INFER → VERIFY → FIX → CONFIRM
```

## Phase 1: SCAN — 탐색

입력에 따라 모드 자동 선택:

### Mode A: 소스코드 분석
트리거: 프로젝트 경로가 주어졌을 때

1. 프로젝트 구조 파악 (프레임워크, 라우팅, 컴포넌트)
2. 인터랙션 포인트 수집:
   - 클릭 핸들러 (onClick, @click, onPress 등)
   - 라우팅 정의 (routes, pages, navigation)
   - API 엔드포인트 (controllers, handlers)
   - 상태 변경 포인트 (setState, dispatch, mutation)
3. 각 포인트를 시나리오 단위로 목록화

### Mode B: URL 크롤링 (DOM 기반)
트리거: URL이 주어졌을 때

1. 대상 URL 진입, DOM 스냅샷 캡처
2. 클릭 가능한 요소 전수 수집:
   - `<a>`, `<button>`, `[role="button"]`, `[onclick]`, 클릭 가능한 `<div>` 등
3. 각 요소를 순차 클릭하며 결과 페이지 DOM 캡처
4. 계층 사이트맵 생성:

```
/ (대시보드)
├── /users (사용자 목록)
│   ├── [편집 버튼] → ?
│   ├── [삭제 버튼] → ?
│   └── [행 클릭] → ?
├── /settings (설정)
│   └── [저장 버튼] → ?
```

5. 사이트맵을 깊이 우선(DFS) 순회하며 시나리오 단위 분해
6. 로그인이 필요한 경우: 인증 정보를 먼저 요청하거나 쿠키/토큰 제공받기

### SCAN 산출물
```
# SDD 사이트맵
- 총 페이지: N개
- 총 인터랙션 포인트: M개
- 시나리오 후보: K건
```

## Phase 2: INFER — 시나리오 추론

AI가 각 인터랙션 포인트에 대해 "합리적 기대 결과"를 자율 생성한다.

### 추론 카테고리

**네비게이션 추론**
- `편집/수정/edit` → 해당 항목의 편집 화면/모달
- `상세/detail/view` → 해당 항목의 상세 화면
- `목록/list/back` → 상위 목록으로 복귀
- `삭제/delete` → 확인 다이얼로그 → 삭제 후 목록 갱신
- `생성/추가/new/create` → 생성 폼/모달

**상태 변경 추론**
- `저장/save/submit` → 성공 피드백(토스트/알림) + 데이터 반영
- `취소/cancel/close` → 변경사항 버리고 이전 상태 복귀
- `토글/switch` → 상태 즉시 반전 + 시각적 피드백

**데이터 정합성 추론**
- 생성 후 → 목록에 새 항목 존재
- 삭제 후 → 목록에서 해당 항목 소멸
- 수정 후 → 상세에서 변경값 반영
- 검색 후 → 결과가 검색어와 관련

**접근성/UX 추론**
- 빈 목록 → empty state 표시 (빈 화면 X)
- 로딩 중 → 로딩 인디케이터 표시
- 에러 발생 → 에러 메시지 표시 (무반응 X)
- 필수 필드 미입력 → 유효성 검증 피드백

### 추론 신뢰도
- **HIGH** — 네이밍/패턴이 명확 (예: `editUser` → 편집)
- **MEDIUM** — 추론 가능하나 여러 해석 가능
- **LOW** — 확신 없음 → UNCERTAIN 판정으로 분류

### INFER 산출물
각 시나리오에 대해:
```
[SDD-001]
- 요소: 편집 버튼
- 위치: /users > 테이블 3행
- 기대 결과: 해당 사용자의 편집 모달/화면 오픈
- 신뢰도: HIGH
```

## Phase 3: VERIFY — 런타임 검증

사이트맵 기준 깊이 우선 순회하며 각 시나리오 실행:

1. 해당 페이지 진입
2. 대상 요소 클릭/실행
3. 결과 DOM 스냅샷 캡처
4. INFER의 기대 결과와 비교

### 판정 기준
- **✅ PASS** — 기대와 실제가 일치
- **❌ LOGIC DEFECT** — 명확한 불일치 (신뢰도 HIGH/MEDIUM)
- **❓ UNCERTAIN** — AI가 확신 못 함 (신뢰도 LOW) → 수동 검토 태그

### VERIFY 산출물
```
검증 완료: 42건
- ✅ PASS: 36건
- ❌ LOGIC DEFECT: 4건
- ❓ UNCERTAIN: 2건
```

## Phase 4: FIX — 자동 수정

### Mode A (소스코드 있을 때)
LOGIC DEFECT 각 건에 대해:
1. 원인 코드 위치 특정 (파일:라인)
2. 수정 코드 작성
3. 기존 테스트 실행 → 사이드이펙트 확인
4. 사이드이펙트 없으면 수정 적용 + 커밋
5. 사이드이펙트 있으면 → 수동 검토 태그

### Mode B (URL만 있을 때)
소스코드 없으므로 직접 수정 불가:
1. **수정 제안서** 생성
2. 포함 내용:
   - 원인 추정 (DOM 구조/이벤트 핸들러 기반)
   - 수정 방향 (의사코드 또는 예상 코드 변경)
   - 우선순위 (HIGH/MEDIUM/LOW)

## Phase 5: CONFIRM — 수정 검증

1. 수정된 시나리오만 재실행 (전체 재실행 X → 효율)
2. 판정:
   - PASS → **✅ FIXED**
   - FAIL → **⚠️ RETRY NEEDED** + 수동 검토 요청
3. Mode B는 수정 제안서 제출로 CONFIRM 대체

## 최종 보고서 포맷

```markdown
# SDD 테스트 보고서

## 개요
- 대상: [URL 또는 프로젝트 경로]
- 일시: YYYY-MM-DD HH:mm
- 모드: URL 크롤링 / 소스코드 분석
- 소요 시간: Nm Ns

## 사이트맵
(계층 트리)

## 검증 요약
| 구분 | 건수 |
|------|------|
| 전체 시나리오 | 42 |
| ✅ PASS | 36 |
| ❌ LOGIC DEFECT | 4 |
| ❓ UNCERTAIN | 2 |
| ✅ FIXED | 3 |
| ⚠️ RETRY NEEDED | 1 |

## 상세 결과

### [SDD-001] 편집 버튼 클릭
- 위치: /users > 테이블 3행 > 편집 버튼
- 기대: 해당 사용자 편집 모달 오픈
- 실제: 대시보드(/)로 이동
- 판정: ❌ LOGIC DEFECT
- 신뢰도: HIGH
- 원인: onClick → navigate('/') 호출
- 수정: navigate('/') → openEditModal(userId)
- 검증: ✅ FIXED

### [SDD-002] ...

## 수정 이력
| ID | 내용 | 결과 |
|----|------|------|
| SDD-001 | onClick 핸들러 수정 | ✅ FIXED |
| SDD-017 | API 응답 후 목록 미갱신 | ✅ FIXED |
| SDD-028 | empty state 추가 | ✅ FIXED |
| SDD-031 | 삭제 확인 누락 | ⚠️ 수동 검토 |
```

## 실행 트리거 예시

사용자가 이렇게 요청하면 SDD를 실행:
- "이 URL 논리 테스트해줘: https://example.com"
- "SDD 돌려줘"
- "이 프로젝트 시나리오 검증해"
- "화면 흐름 논리적으로 맞는지 확인해"

## 보고서 출력

최종 보고서는 반드시 **md 파일로 저장하고 전달**한다.

- 파일명: `sdd-report-{대상명}-{YYYY-MM-DD}.md`
- 저장 위치: 작업 디렉토리 또는 지정 경로
- 채널에 파일 첨부로 전달 (Discord, Slack 등)
- 보고서 본문도 채팅에 요약 표시하되, 전체 내용은 md 파일로 제공

## 제약사항

- UNCERTAIN 판정은 절대 자동 수정하지 않는다 (수동 검토만)
- 수정 시 기존 테스트를 깨뜨리지 않는다
- 파괴적 동작(DELETE, DROP 등)은 실제 실행하지 않고 시뮬레이션
- 인증이 필요한 페이지는 사전에 인증 정보 확보 후 진행
- Mode B에서 SPA(Single Page App)의 경우 URL 변화 없이 DOM만 바뀔 수 있으므로 DOM diff 기반으로 판정