---
task_id: task-1837_5.1
type: context
scope: task
created: 2026-04-16
updated: 2026-04-16
status: in-progress
---

# 맥락 노트: task-1837_5.1

**task**: task-1837_5.1

---

## 결정 근거

### 테스트 구조 설계
- 각 테스트 파일은 대응하는 소스 모듈의 핵심 함수를 실제 import하여 통합 동작 확인
- mock 범위: subprocess(외부 CLI), urllib(Telegram API), 환경변수만 mock
- tmp_path 활용: 파일 I/O 격리로 테스트 간 간섭 방지

### 위임 구조
- 8개 테스트를 2명에게 4개씩 병렬 할당 (독립적이므로 병렬 안전)
- 엔키: dispatch 관련 (overlap, batch, 3docs, gate_instructions)
- 닌기르수: 검증 관련 (sanitize, codex, gemini, g3)

## 3 Step Why

1st Why: "왜 이 설계가 필요한가?"
→ A: 현재 통합 테스트가 2개뿐이어서 시스템 핵심 모듈 간 상호작용 검증이 부족하다. 특히 gate/sanitize/3docs 등 Lv.3 게이트 관련 모듈의 통합 검증이 전무하다.

2nd Why: "왜 A가 최선의 접근인가?"
→ B: 각 모듈별 개별 단위 테스트는 이미 일부 존재하지만, 모듈 간 통합 시 발생하는 데이터 흐름(예: dispatch → 3docs 생성 → QC verify)은 통합 테스트로만 검증 가능하다. 모듈 간 인터페이스 변경 시 회귀를 조기 포착할 수 있다.

3rd Why: "왜 B가 다른 대안보다 나은가?"
→ C: E2E 시스템 테스트(실제 서버 기동) 대비 통합 테스트는 실행 속도가 빠르고 CI에서 안정적으로 실행 가능하다. 단위 테스트만으로는 모듈 간 계약(함수 시그니처, 반환 형식)을 검증할 수 없다. 통합 테스트는 비용 대비 검증 범위가 최적이다.

## 참조 자료

- 기존 테스트 패턴: `/home/jay/workspace/tests/integration/test_phase1_integration.py`
- 소스 모듈: `prompts/gate_instructions.py`, `dispatch.py`, `utils/sanitize_gate.py`, `scripts/codex_gate_check.py`, `scripts/g3_independent_verifier.py`, `cross_model_review.py`, `scripts/worktree_manager.py`, `teams/shared/verifiers/three_docs_check.py`

## 주의사항

- dispatch.py의 WORKSPACE는 Path 객체 → monkeypatch 시 Path(tmp_path) 사용 필수
- codex_gate_check.py의 subprocess.run 호출은 반드시 mock
- three_docs_check.py는 yaml 라이브러리 의존 → 설치 확인 필요