---
task_id: task-2145
type: context
scope: task
created: 2026-04-24
updated: 2026-04-24
status: completed
---

# 맥락 노트: task-2145

**task**: task-2145

---

## 결정 근거

### 3 Step Why

**1st Why: 왜 이 설계가 필요한가?**
→ 봇이 "확인 불가"로 회피하고 .done 생성하는 실제 사례(task-2140) 발생. 코드 강제 없이 문서 규칙만으로는 봇이 따르지 않음.

**2nd Why: 왜 BLOCK + EXEMPT + 증거 필수 3중 구조가 최선인가?**
→ BLOCK만으로는 백엔드 작업이 과잉 차단됨. EXEMPT만으로는 프론트 작업 회피 불가. 증거 없으면 키워드("성공")만 넣어 통과 가능. 3중 구조가 정밀 제어를 가능하게 함.

**3rd Why: 왜 task 파일 기반 EXEMPT가 대안보다 나은가?**
→ 작업 유형을 task 파일 키워드에서 자동 판별하므로 수동 분류 불필요. 오분류 시에도 증거 체크로 2차 방어. affected_files 확장자 기반 판별은 task 파일이 없는 경우 동작 불가.

### Codex 사전 검증 피드백 반영
- EXEMPT를 `is_frontend` 판별과 "정당한 해당없음 허용"으로 분리 → 반영 완료
- 증거 패턴 정규식 확장 (`200\s*OK`, `\d+\s+passed` 등) → 반영 완료
- 기존 테스트 전면 갱신 → 10개 시나리오로 교체 완료

## 참조 자료

- 미팅 기록: `/home/jay/workspace/memory/meetings/2026-04-24-dispatch-quality-automation.md`
- 기존 코드: 이잠나(dev7) Cycle 1 의견 — "보고서에 '확인 불가' 패턴이 있으면 FAIL 반환"

## 주의사항

- BLOCK_PATTERNS는 보고서 **전체** 내용에서 검색됨 (L1 섹션 뿐 아니라 다른 섹션도 포함)
- `is_frontend` 판별 시 task 파일이 없으면 `False` (백엔드 취급) — 안전한 기본값
- FRONTEND_KEYWORDS의 "UI" 키워드는 대소문자 구분함 ("ui"는 매칭 안됨)