# Phase 3: 모듈화 전수조사 — 통합 검증

## 목표
Phase 0~2에서 수행한 전체 모듈화 작업의 통합 검증.
"하나의 오류도, 하나의 실수도 없어야 한다."

## Phase 0~2 작업 요약
- Phase 0 (1팀): config 5파일 생성 (paths/constants/design-system/module-registry/loader.py)
- Phase 1 (5팀 병렬):
  - 8팀: dispatch.py → ConfigManager 참조 (194건 PASS)
  - 3팀: tools/ai-image-gen/ 53파일 → gen_config.py 헬퍼 (154건 PASS)
  - 5팀: dashboard/ JS → /api/design-system + 경로 동적화 (151건 PASS)
  - 6팀: scripts/ + tests/ 54파일 → config/env 참조
  - 4팀: ThreadAuto 47파일 → config.py 단일 소스 (1776건 PASS)
- Phase 1.5 (2팀): image_workflow.py → dq_rules/config 참조 (60건 PASS)
- Phase 2 (1팀, 7팀):
  - 1팀: 린터/훅 + module-registry v2.0 (11소스, verify 통과)
  - 7팀: InsuRo → 3 config + 2 data 파일, 15컴포넌트 (빌드 성공)

## 검증 항목

### 1. 전체 테스트 실행
```bash
# 메인 workspace
cd /home/jay/workspace && python3 -m pytest tests/ -q --tb=short

# ThreadAuto
cd /home/jay/projects/ThreadAuto && python3 -m pytest tests/ -q --tb=short

# InsuRo
cd /home/jay/projects/InsuRo && npm run build && npx tsc --noEmit
```
- 신규 실패 0건 확인 (기존 실패와 구분)
- 회귀 테스트: Phase 전후 실패 목록 비교

### 2. modularity-check.py 전체 스캔
```bash
python3 tools/modularity-check.py scan
python3 tools/modularity-check.py verify
```
- scan: 잔존 하드코딩 0건 (또는 허용된 fallback만)
- verify: registry 11소스 전체 통과

### 3. config 변경 영향 테스트
dq-rules.json의 값을 임시 변경 → 의존 파일에 자동 반영되는지 확인:
- 예: PASS_THRESHOLD 93→95 변경 → image_workflow.py에서 95 사용하는지 확인
- 예: headline.min 84→90 변경 → dq_rules.py에서 90 반환하는지 확인
- 테스트 후 원래 값으로 복원

### 4. 린터/훅 동작 테스트
- 의도적 하드코딩 추가 → pre-commit hook 차단 확인
- 정상 코드 → 통과 확인
- tests/ 내 하드코딩 → WARNING만 (차단 아님) 확인

### 5. 대시보드 기능 검증
```bash
cd /home/jay/workspace && python3 dashboard/server.py &
# 포트 8000에서 아래 확인:
curl http://localhost:8000/api/status
curl http://localhost:8000/api/campaign
curl http://localhost:8000/api/design-system
curl http://localhost:8000/api/org
```
- 모든 API 정상 응답
- 대시보드 UI 렌더링 정상

### 6. dispatch.py 기능 검증
```bash
python3 dispatch.py --help  # 정상 출력
python3 dispatch.py --team dev1-team --task "테스트" --level normal --dry-run 2>&1  # dry-run 정상
```
(dry-run이 없으면 --help만 확인)

### 7. 의존성 그래프 검증
- config → 사용 파일 매핑이 module-registry.json과 일치하는지 확인
- 순환 의존성 없는지 확인

### 8. 3 Step Why 최종 검증
- 1st Why: 왜 모듈화를 했는가? → 하나 바꾸면 전부 바뀌는 원칙
- 2nd Why: 왜 이 방식이 최선인가? → config 단일 소스 + 린터 방어
- 3rd Why: 왜 린터가 필요한가? → 사람의 기억에 의존하면 6개월 후 재발

## 산출물
1. 통합 검증 보고서 (모든 검증 항목 PASS/FAIL)
2. 잔존 이슈 목록 (있으면)
3. 최종 modularity-check.py scan/verify 결과