# task-1921: 레드팀 적대적 QC 검증 — 거짓 보고서 공격 시나리오

## 목적
QC 파이프라인의 구멍을 찾기 위해, 의도적으로 거짓/부실 보고서를 만들어 QC가 탐지하는지 테스트.
탐지 못하는 케이스 = QC에 빠진 구멍 → 목록 작성.

## ★★★ 중요: 코드 수정 없음 ★★★
이 작업은 조사 + 보고서만. 코드 수정하지 마라.
QC 파이프라인을 "공격"하여 빈틈을 발견하고, 발견된 빈틈 목록을 보고서로 작성하라.

## 공격 시나리오 (최소 이것들은 테스트할 것)

### 시나리오 1: 거짓 테스트 결과
- 보고서에 "102 passed, 0 failed"라고 적었지만, 실제 pytest 실행하면 실패가 있는 경우
- qc_verify.py 또는 g3_independent_verifier.py가 이걸 잡는지?

### 시나리오 2: 수정 안 한 파일을 "verified"라고 보고
- 보고서 테이블에 파일을 "verified"로 적었지만, 실제 git diff에 해당 파일 변경이 없는 경우
- g3_independent_verifier.py가 잡는지?

### 시나리오 3: planned 항목이 포함된 보고서
- 보고서에 "planned" 상태 항목이 있는데 .done을 생성한 경우
- planned_check가 잡는지?

### 시나리오 4: grep 키워드가 실제 코드에 없는 경우
- 보고서에 "grep 'some_function' OK"라고 적었지만, 실제 코드에 some_function이 없는 경우
- g3의 grep 검증이 잡는지?

### 시나리오 5: 범위 외 파일 수정
- 자기 팀 범위 밖의 파일을 수정한 경우
- scope_check 또는 affected_files 검사가 잡는지?

### 시나리오 6: 테스트 없이 "PASS" 보고
- test_runner를 skip하고도 "전체 PASS"라고 보고서에 적은 경우
- MANDATORY 체크가 이걸 막는지?

### 시나리오 7: 보고서 자체 누락
- 보고서 파일(memory/reports/task-*.md)을 생성하지 않고 .done만 생성
- file_check 또는 다른 verifier가 잡는지?

### 시나리오 8+: 자유롭게 추가 공격
- 위 7개 외에 생각나는 공격 벡터를 자유롭게 추가

## 테스트 방법
1. 임시 task-id (task-test-redteam-N)로 가짜 보고서/이벤트 파일 생성
2. qc_verify.py, g3_independent_verifier.py 등을 수동 실행하여 결과 확인
3. 테스트 후 임시 파일 정리

## 산출물
보고서: `memory/reports/task-1921-redteam-qc-audit.md`
포맷:
```
| 시나리오 | 공격 내용 | QC 탐지 여부 | 탐지한 체커 | 비고 |
```
- 탐지 실패한 시나리오 = "QC 구멍" → 별도 "수정 필요 목록" 섹션에 정리

## 레벨
- normal (조사 작업)