# task-1285.1 미팅 Cycle 8
날짜: 2026-03-31
안건: P1/P2 전 항목(6건) 테스트 방법 + 팀 배정 최종 확정 + 완료 기준

## 참석자 발언

### 헤르메스 (백엔드/인프라)

**1. 단위 테스트 설계:**

각 항목이 수정하는 핵심 함수에 대한 단위 테스트를 설계합니다.

**P1-1. Progressive Disclosure:**

| 테스트 대상 | 테스트 내용 | 파일 |
|---|---|---|
| `build_prompt(disclosure_phase="summary")` | 반환값 토큰 수 <= 600. CRITICAL 최소 셋(금지 행위/QC 의무/보고 형식) 포함 확인 | `tests/test_team_prompts.py` |
| `build_prompt(disclosure_phase="standard")` | 반환값 토큰 수 1,200~1,800. 팀원 코워크 섹션 포함 확인 | `tests/test_team_prompts.py` |
| `build_prompt(disclosure_phase="full")` | 기존 테스트와 동일한 출력 (하위호환성). 기존 assertion 전부 통과 | `tests/test_team_prompts.py` |
| `_build_direct_prompt(disclosure_phase=...)` | disclosure_phase별 섹션 포함/제외 정확성 | `tests/test_team_prompts.py` |
| dispatch.py 내 disclosure 결정 로직 | Lv.1 → summary, Lv.2 → standard, Lv.3+ → full 매핑 확인 | `tests/test_dispatch.py` |

**P1-2. 읽기/쓰기 격리:**

| 테스트 대상 | 테스트 내용 | 파일 |
|---|---|---|
| dispatch.py `--agent-type` 파라미터 파싱 | `read`/`write` 값 정상 파싱, 미전달 시 기본값 `"write"` | `tests/test_dispatch.py` |
| `worktree_manager.py --read-only` | read-only 모드에서 파일 생성/수정 시도 → PermissionError 발생 확인 | `tests/test_worktree.py` |
| `worktree_manager.py --read-only` 삭제 | read-only worktree 정상 삭제, 좀비 worktree 미발생 확인 | `tests/test_worktree.py` |
| feature_flags.json 로딩 | `worktree_readonly=false` 시 `--read-only` 플래그 무시 확인 | `tests/test_feature_flags.py` |

**P1-7. hooks 자동 강제:**

| 테스트 대상 | 테스트 내용 | 파일 |
|---|---|---|
| hooks 스크립트 (pyright) | 정상 Python 파일 → exit 0, 타입 에러 파일 → exit 1 | `tests/test_hooks.py` |
| hooks 스크립트 (ruff) | 정상 파일 → exit 0, 스타일 위반 파일 → exit 1 | `tests/test_hooks.py` |
| 심각도 2단계 분류 | critical 에러(import 실패, 구문 오류) → 중단, standard 에러(미사용 변수) → 경고 | `tests/test_hooks.py` |
| `.py` 확장자 필터 | `.md`, `.json` 파일 수정 시 hooks 미실행 확인 | `tests/test_hooks.py` |
| circuit breaker | 15회 초과 → warning 삽입, 30회 초과 → 강제 중단 | `tests/test_hooks.py` |
| 동일 에러 3회 | 동일 pyright 에러 코드 3회 연속 → 즉시 중단 | `tests/test_hooks.py` |

**P2-3. haiku 전용화 A/B:**

| 테스트 대상 | 테스트 내용 | 파일 |
|---|---|---|
| A/B 분기 로직 | 무작위 배정 50:50 확인 (100회 시뮬레이션, 40-60 범위 내) | `tests/test_ab_test.py` |
| MODEL_MAP["qc_verify"] 스위칭 | haiku 그룹 시 `"haiku"` 반환, 대조군 시 `"sonnet"` 반환 | `tests/test_ab_test.py` |
| feature_flag `ab_test_haiku=false` | 플래그 비활성 시 전원 sonnet으로 실행 확인 | `tests/test_ab_test.py` |

**P2-4. TRUST 5 태그:**

| 테스트 대상 | 테스트 내용 | 파일 |
|---|---|---|
| `build_result()` trust_summary 필드 | 5차원(T/R/U/S/T) 키 존재, 각 값이 "PASS"/"FAIL" | `tests/test_qc_verify.py` |
| verifier → TRUST 매핑 로직 | test_runner PASS → Tested PASS, suppression 통과 → Readable PASS 등 9종 매핑 정확도 | `tests/test_qc_verify.py` |
| trust_summary 비활성화 | `trust_summary=false` 플래그 시 trust_summary 키 미생성 확인 | `tests/test_qc_verify.py` |

**P2-5. MODEL_MAP:**

| 테스트 대상 | 테스트 내용 | 파일 |
|---|---|---|
| MODEL_MAP 상수 구조 | 모든 역할 키 존재, 값이 유효 모델명 | `tests/test_team_prompts.py` |
| `_build_cowork_section()` 모델 가이드 삽입 | MODEL_MAP 활성 시 프롬프트에 "모델 가이드" 섹션 포함 | `tests/test_team_prompts.py` |
| `model_map=false` 플래그 | 비활성 시 모델 가이드 섹션 미삽입 확인 | `tests/test_team_prompts.py` |
| staleness 경고 | `_last_updated`가 7일 초과 시 경고 메시지 반환 | `tests/test_team_prompts.py` |

---

**2. 통합 테스트 설계:**

단위 테스트가 개별 함수를 검증한다면, 통합 테스트는 **전체 파이프라인**을 검증합니다.

**통합 테스트 시나리오:**

| 시나리오 ID | 설명 | 검증 항목 | 파일 |
|---|---|---|---|
| INT-01 | Lv.1 작업 end-to-end | dispatch → disclosure=summary → build_prompt → worktree(write) → agent 실행 → hooks 실행 → QC → .done | `tests/integration/test_e2e_lv1.py` |
| INT-02 | Lv.2 작업 read-only 모드 | dispatch(--agent-type=read) → build_prompt → worktree(read-only) → agent 실행(파일 수정 불가 확인) | `tests/integration/test_e2e_read.py` |
| INT-03 | hooks 무한 루프 방지 | 의도적 타입 에러 파일 → hooks 트리거 → circuit breaker 30회 제한 확인 | `tests/integration/test_hooks_circuit.py` |
| INT-04 | haiku A/B 분기 | QC 실행 시 A/B 플래그에 따라 모델 분기 확인 | `tests/integration/test_ab_split.py` |
| INT-05 | TRUST trust_summary + QC 연동 | qc_verify.py 실행 → trust_summary 포함 JSON 출력 → 다운스트림 파싱 성공 | `tests/integration/test_trust_qc.py` |
| INT-06 | feature_flags 킬 스위치 | 모든 플래그 false 설정 → 6개 기능 전부 비활성화 → 기존 동작과 동일 출력 | `tests/integration/test_killswitch.py` |
| INT-07 | 3-Layer 롤백 | Layer 1(flag off) → Layer 2(설정 원복) → Layer 3(git revert) 순차 실행 후 기존 동작 복원 확인 | `tests/integration/test_rollback.py` |

---

### 오딘 (프론트/워크플로우)

**1. 회귀 테스트 설계:**

기존 기능이 깨지지 않음을 확인하는 회귀 테스트입니다.

**회귀 테스트 목록:**

| 항목 | 회귀 대상 | 테스트 방법 | 판정 기준 |
|---|---|---|---|
| (1) Progressive Disclosure | 기존 `build_prompt()` 출력 (disclosure_phase 미전달 시) | 기존 테스트 스위트 전체 실행. disclosure_phase 미전달 = "full" 기본값이므로 기존 출력과 100% 동일해야 함 | 기존 test_team_prompts.py의 모든 assertion 통과 |
| (2) 읽기/쓰기 격리 | 기존 dispatch.py 실행 (--agent-type 미전달 시) | --agent-type 없이 dispatch 실행. 기본값 "write"로 동작하므로 기존과 동일해야 함 | dispatch → build_prompt → worktree 파이프라인 정상 완료 |
| (7) hooks | 기존 에이전트 세션 (hooks 없던 시절) | hooks 비활성화(feature_flag=false) 후 에이전트 실행. 기존과 동일한 결과 | 에이전트 산출물 diff = 0 (hooks 유무에 따른 산출물 차이 없음 확인) |
| (3) haiku A/B | 기존 QC (sonnet만 사용) | A/B 비활성화 후 QC 실행. 기존 sonnet 결과와 동일 | QC JSON 구조 동일, 결과 동일 |
| (4) TRUST 5 | 기존 QC JSON (trust_summary 필드 없음) | trust_summary 비활성화 후 build_result() 출력. 기존 JSON과 동일 구조 | JSON 키 목록 동일 |
| (5) MODEL_MAP | 기존 build_prompt() 출력 (모델 가이드 없음) | model_map=false 후 build_prompt(). 모델 가이드 섹션 미포함 확인 | 기존 프롬프트와 diff = 모델 가이드 섹션 0줄 |

**2. WORKFLOW 문서 검증:**

DIRECT-WORKFLOW.md 변경에 대한 문서 검증:

| 변경 내용 | 검증 방법 |
|---|---|
| 섹션 5 "에이전트 분류 가이드" 추가 | (1) 기존 섹션 1-4 내용 변경 없음 확인 (diff 검증). (2) 새 섹션이 기존 실행 순서에 영향을 주지 않음 확인 (에이전트 테스트 실행) |
| "자동 검증" 언급 문구 추가 | (1) hooks 비활성화 시 해당 문구가 혼란을 주지 않는지 확인. (2) 에이전트가 hooks를 직접 제어하려는 행동이 나타나지 않는지 모니터링 |
| 금지 행위 목록 (CRITICAL 셋) | 기존 금지 행위 목록과 CRITICAL 셋의 내용 일치 확인. CRITICAL 셋이 본문의 부분 집합이어야 함 |

**3. 기준선 측정 체크리스트:**

Week 0(4/1~4/14) 기준선 측정 항목:

```
[ ] build_prompt() 현재 출력 토큰 수 (팀별, 레벨별)
[ ] QC 패스율 현재 수치 (최근 30일)
[ ] QC 실행 시간 현재 수치 (평균, P95)
[ ] 에이전트 세션당 Write/Edit 횟수 (평균, 최대)
[ ] QC 이슈 유형 분포 (코드 결함/보고서 형식/task 해석 오류/기타)
[ ] 에이전트 세션 토큰 소비량 (평균, P95)
[ ] worktree 생성/삭제 성공률
```

이 기준선은 P1/P2 효과 측정의 비교 대상이 됩니다.

---

### 마아트 (품질/검증)

**1. 완료 기준(Definition of Done) 정의:**

각 항목이 "완료"로 판정되기 위한 체크리스트입니다.

**P1-1. Progressive Disclosure -- 완료 기준:**

```
[ ] build_prompt()에 disclosure_phase 파라미터 추가 완료
[ ] summary/standard/full 3단계 동작 확인 (단위 테스트 통과)
[ ] summary 모드에 CRITICAL 최소 셋 포함 확인
[ ] dispatch.py에서 Lv.1→summary, Lv.2→standard 매핑 구현
[ ] disclosure_phase="full" 기본값으로 하위호환성 확인 (회귀 테스트 통과)
[ ] feature_flags.json에 progressive_disclosure 플래그 추가
[ ] 품질 게이트 통과: summary QC 패스율 >= full * 0.85
[ ] 코드 리뷰 완료 (리뷰어: 로키 + 프로메테우스)
```

**P1-2. 읽기/쓰기 격리 -- 완료 기준:**

```
[ ] dispatch.py에 --agent-type 파라미터 추가 완료
[ ] worktree_manager.py에 --read-only 플래그 구현 완료
[ ] read-only 격리 정확도 100건 중 파일변경 0건 확인
[ ] DIRECT-WORKFLOW.md에 섹션 5 "에이전트 분류 가이드" 추가
[ ] --agent-type 미전달 시 기본값 "write" 동작 확인 (회귀 테스트)
[ ] feature_flags.json에 worktree_readonly 플래그 추가
[ ] 좀비 worktree 미발생 확인 (100회 생성/삭제 사이클)
[ ] 코드 리뷰 완료
```

**P1-7. hooks 자동 강제 -- 완료 기준:**

```
[ ] settings.json에 hooks 섹션 추가 (PostToolUse Write/Edit → pyright+ruff)
[ ] .py 확장자 필터 적용 확인
[ ] 심각도 2단계(critical 중단 / standard 경고) 구현
[ ] circuit breaker 구현: warning=15, critical=30, 동일에러3회=즉시중단
[ ] False Positive Rate < 10% (정상 코드 50건 테스트)
[ ] hooks 비Python 파일 미실행 확인
[ ] hooks 스크립트 단독 실행 가능 (독립 테스트)
[ ] feature_flags.json에 hooks_enabled 플래그 추가
[ ] "hooks =/= QC 면제" 규칙 QC-RULES.md에 추가
[ ] 코드 리뷰 완료
```

**P2-3. haiku 전용화 A/B -- 완료 기준:**

```
[ ] A/B 테스트 스크립트 구현 완료
[ ] 무작위 배정 50:50 검증 (시뮬레이션)
[ ] A/B 테스트 4주 실행 완료
[ ] 표본 크기 n > 100 달성
[ ] FNR < 15% 확인 (주 1회 sonnet 재검증 기반)
[ ] haiku 패스율 이상 징후(sonnet 대비 30%+ 높음) 미발생 또는 조기종료
[ ] 비용 절감 효과 정량화 보고서
[ ] feature_flags.json에 ab_test_haiku 플래그 추가
[ ] 코드 리뷰 완료
[ ] 최종 판정: haiku 전용화 채택/기각 결정
```

**P2-4. TRUST 5 태그 -- 완료 기준:**

```
[ ] qc_verify.py의 build_result()에 trust_summary 필드 추가
[ ] 5차원(T/R/U/S/T) 매핑 로직 구현 (verifier 9종 → TRUST 5)
[ ] 매핑 불일치율 < 3% 확인 (기존 QC 결과 100건 역검증)
[ ] trust_summary 비활성화 시 기존 JSON 구조 유지 (회귀 테스트)
[ ] feature_flags.json에 trust_summary 플래그 추가
[ ] QC-RULES.md에 trust_summary 설명 섹션 추가
[ ] 다운스트림(chain_manager.py) 호환성 확인
[ ] 코드 리뷰 완료
```

**P2-5. MODEL_MAP -- 완료 기준:**

```
[ ] team_prompts.py에 MODEL_MAP 상수 추가
[ ] _build_cowork_section()에서 모델 가이드 삽입 구현
[ ] 모델 불일치율 < 5% 확인 (프롬프트 모델 vs 실행 모델)
[ ] _last_updated 필드 추가 + 7일 staleness 경고 구현
[ ] model_map=false 플래그 비활성화 시 모델 가이드 미삽입 확인
[ ] feature_flags.json에 model_map 플래그 추가
[ ] DIRECT-WORKFLOW.md에 "모델 선택 가이드" 참조 추가
[ ] 코드 리뷰 완료
```

---

**2. 테스트 우선순위:**

6개 항목의 테스트를 동시에 수행할 수 없으므로 우선순위를 정합니다.

```
1순위 (P1 착수 전): 기준선 측정 (Week 0, 4/1~4/14)
2순위 (P1 구현 중): 단위 테스트 + 회귀 테스트 (구현과 동시 진행)
3순위 (P1 구현 후): 통합 테스트 INT-01~03 (P1 3항목 통합 검증)
4순위 (P2 구현 후): 통합 테스트 INT-04~05 (P2 QC 관련)
5순위 (전체 완료 후): 통합 테스트 INT-06~07 (킬 스위치 + 롤백)
```

---

### 로키 (DA) -- [반드시 공격적 비평]

**1. 테스트 계획에 대한 공격:**

**공격 1: 단위 테스트의 "토큰 수 검증"은 불안정합니다.**

헤르메스가 `build_prompt(disclosure_phase="summary")` 테스트에서 "반환값 토큰 수 <= 600"을 기준으로 했습니다. **토큰 수는 프롬프트 내용(팀명, 작업 설명 길이)에 따라 변합니다.** "팀원이 10명인 팀"과 "팀원이 3명인 팀"은 summary 모드에서도 토큰 수가 다릅니다. 고정 숫자(600)로 assertion하면 팀 구조가 바뀔 때마다 테스트가 깨집니다.

**대안**: 토큰 수 자체가 아니라 **"full 대비 비율"**로 검증합니다.
- summary: full의 15~25%
- standard: full의 40~60%
- full: 기존과 동일(delta < 5%)

이렇게 하면 팀 구조가 바뀌어도 비율은 안정적입니다.

**공격 2: 통합 테스트 INT-03 "hooks 무한 루프 방지"는 실행 시간이 깁니다.**

"의도적 타입 에러 파일 → hooks 트리거 → circuit breaker 30회 제한 확인" 테스트는 hooks가 30번 실행될 때까지 기다려야 합니다. hooks 1회 실행이 pyright+ruff로 5-10초라면, 30회 = 150-300초 = 2.5-5분. **CI에서 이 테스트가 매번 5분 걸리면 개발 속도가 크게 저하됩니다.**

**대안**: circuit breaker 테스트는 hooks 실행을 **mock**하고, 카운터 로직만 단위 테스트합니다. 실제 hooks 30회 실행은 **주 1회 전체 통합 테스트**에서만 수행합니다.

**공격 3: 회귀 테스트의 "에이전트 산출물 diff = 0"은 비현실적입니다.**

오딘이 hooks 회귀 테스트에서 "hooks 유무에 따른 산출물 차이 없음"을 기준으로 했습니다. 그런데 hooks가 에러를 발견하여 에이전트가 수정하면, **산출물이 더 좋아지는 것이 hooks의 목적**입니다. "diff = 0"이면 hooks가 아무 효과도 없다는 뜻이고, 이것은 hooks 실패입니다.

**수정**: hooks 회귀 테스트의 기준은 "hooks 비활성화 시 기존 동작과 동일"이 아니라, **"hooks 비활성화 시 기존 테스트 스위트 전부 통과"**입니다. 산출물 내용이 아니라 **기능적 정확성**을 검증해야 합니다.

**공격 4: 완료 기준에 "시간 제한"이 없습니다.**

마아트의 DoD에 체크리스트는 있지만, **"이 항목을 언제까지 완료하는가?"가 없습니다.** 완료 기준만으로는 "영원히 완료되지 않는 항목"을 방지할 수 없습니다. 각 항목에 **데드라인**을 추가해야 합니다.

| 항목 | 데드라인 | 초과 시 조치 |
|---|---|---|
| (1) Progressive Disclosure | Week 2 (4/14) | 설계 재검토 또는 범위 축소 |
| (2) 읽기/쓰기 격리 | Week 2 (4/14) | 설계 재검토 또는 범위 축소 |
| (7) hooks 자동 강제 | Week 3 (4/21) | circuit breaker만 먼저 배포, 나머지 이후 |
| (3) haiku A/B | Week 8 (5/26) | n<100이면 기간 연장 1주 (최대 1회) |
| (4) TRUST 5 | Week 3 (4/21) | 매핑 로직 단순화 (5차원 → 3차원) |
| (5) MODEL_MAP | Week 3 (4/21) | 상수만 추가, 프롬프트 삽입은 이후 |

**공격 5: 팀 배정에서 "공동" 항목이 너무 많습니다.**

Cycle 6에서 "기준선 측정, A/B 테스트 설계"가 "공동" 담당으로 되어있습니다. **공동 = 아무도 책임지지 않음**입니다. 모든 항목에 **단독 책임자(DRI, Directly Responsible Individual)**를 지정해야 합니다.

**2. 내 결론:**
- 토큰 수 검증 → full 대비 비율로 변경
- hooks 30회 통합 테스트 → mock 단위 + 주 1회 전체 통합
- hooks 회귀 테스트 기준 수정 → 기능적 정확성
- 각 항목 DoD에 데드라인 추가
- "공동" 배정 폐지, DRI 지정

---

### 프로메테우스 (전략)

**1. 팀 배정 최종 확정:**

Cycle 6의 배정 원칙 + Cycle 7의 위험 분석 + 로키의 DRI 지적을 종합합니다.

**최종 팀 배정표:**

| 항목 | DRI (단독 책임) | 지원 팀 | 리뷰어 | 데드라인 |
|---|---|---|---|---|
| (1) Progressive Disclosure | 헤르메스 | 오딘(WORKFLOW) | 로키, 프로메테우스 | Week 2 (4/14) |
| (2) 읽기/쓰기 격리 | 헤르메스 | 오딘(WORKFLOW) | 로키, 프로메테우스 | Week 2 (4/14) |
| (7) hooks 자동 강제 | 헤르메스 | 마아트(QC 연동) | 로키, 프로메테우스 | Week 3 (4/21) |
| (3) haiku A/B 테스트 | 마아트 | 헤르메스(인프라) | 로키, 프로메테우스 | Week 8 (5/26) |
| (4) TRUST 5 태그 | 마아트 | - | 로키, 프로메테우스 | Week 3 (4/21) |
| (5) MODEL_MAP | 헤르메스 | 오딘(WORKFLOW 참조) | 로키, 프로메테우스 | Week 3 (4/21) |
| 기준선 측정 | **마아트 (DRI)** | 헤르메스(데이터 추출) | - | Week 0 (4/1~4/14) |
| A/B 테스트 설계 | **마아트 (DRI)** | 헤르메스(분기 구현) | 로키(통계 검증) | Week 3 (4/21) |
| feature_flags.json 설계 | **헤르메스 (DRI)** | - | 로키 | Week 1 (4/7) |

**"공동" 배정 전면 폐지. 모든 항목에 DRI 배정 완료.**

**2. 로키 비평에 대한 전략적 대응:**

**토큰 수 → 비율 검증**: 로키 제안 수용. "full 대비 비율"이 더 안정적인 assertion.

**hooks 통합 테스트 mock**: 로키 제안 수용. CI 성능 유지를 위해 mock 단위 테스트 + 주 1회 전체 통합 테스트로 분리.

**hooks 회귀 테스트 기준**: 로키 지적이 정확합니다. "산출물 diff=0"은 잘못된 기준. **"기존 테스트 스위트 전부 통과"**로 수정.

**데드라인**: 로키 제안 수용. 각 항목 DoD에 데드라인 추가. 초과 시 조치도 사전 정의.

**3. 실행 타임라인 최종안 (8주):**

```
Week 0 (3/31~4/6):
  - [DRI: 마아트] 기준선 측정 시작
  - [DRI: 헤르메스] feature_flags.json 스키마 설계 + 구현

Week 1-2 (4/7~4/20):
  - [DRI: 헤르메스] 그룹 A: (1) Progressive Disclosure + (2) 읽기/쓰기 격리 순차 구현
  - [지원: 오딘] DIRECT-WORKFLOW.md 섹션 5 추가
  - [DRI: 마아트] 그룹 B 설계: (4) TRUST 5 매핑 로직 설계 + (3) A/B 테스트 설계
  - [리뷰: 로키, 프로메테우스] 그룹 A 설계 리뷰

Week 3 (4/21~4/27):
  - [DRI: 헤르메스] 그룹 C: (7) hooks 구현 + circuit breaker
  - [DRI: 마아트] (4) TRUST 5 qc_verify.py 구현
  - [DRI: 헤르메스] (5) MODEL_MAP team_prompts.py 추가
  - [지원: 오딘] WORKFLOW.md "자동 검증" 문구 추가

Week 4 (4/28~5/4):
  - [전체] P1 효과 측정 (기준선 vs 현재)
  - [DRI: 마아트] (3) haiku A/B 테스트 시작
  - [전체] 통합 테스트 INT-01~07 전체 실행

Week 5-8 (5/5~5/31):
  - [DRI: 마아트] A/B 테스트 진행 (주 1회 sonnet 재검증)
  - [DRI: 오딘] P3(Task 파일 표준화) 사전 설계 문서 작성
  - [전체] 효과 측정 정기 보고 (격주)
  - Week 8 종료 시: A/B 테스트 최종 판정 + P1/P2 전체 평가

Week 9+:
  - P1/P2 결과 평가 → P3 실구현 여부 결정
  - P4 재논의 트리거 점검
```

**4. 전체 프로젝트 성공 기준:**

| 기준 | 목표 |
|---|---|
| P1 3항목 완료율 | 3/3 (100%) by Week 4 |
| P2 3항목 완료율 | 2/3 by Week 4 (haiku A/B는 진행 중) |
| 전체 QC 패스율 변화 | 기준선 대비 개선 또는 유지 |
| 롤백 실행 횟수 | 2회 이하 (3회 이상이면 설계 재검토) |
| 데드라인 준수율 | 80% 이상 (6개 중 5개 이상 기한 내 완료) |
| 기술 부채 증가 | feature_flags 잔존(활성 상태) 2개 이하 by Week 9 |

---

## 3 Whys 검증

### 단위 테스트 설계
**Why 1**: 왜 단위 테스트가 필요한가? -> 6개 항목이 핵심 함수(build_prompt, build_result, dispatch)를 수정하므로, 수정 직후 즉시 정상 동작을 확인해야 함
**Why 2**: 토큰 수 고정값 대신 비율 검증이 왜 나은가? -> 팀 구조/작업 설명 등 외부 변수에 따라 토큰 수가 변하므로, 고정값은 취약한 테스트. 비율은 상대적으로 안정적
**Why 3**: 단위 테스트만으로 충분한가? -> 아니오. 개별 함수 정상이어도 파이프라인 전체가 실패할 수 있으므로 통합 테스트 필수. 단위 + 통합 + 회귀 3계층 테스트

### 완료 기준(DoD)
**Why 1**: 왜 체크리스트 형식이 필요한가? -> "완료"의 의미가 사람마다 다름. 체크리스트로 객관적 판정 기준을 통일
**Why 2**: 데드라인이 왜 DoD에 포함되어야 하나? -> 체크리스트만으로는 "영원히 미완"을 방지 못함. 시간 제한이 있어야 범위 축소/재설계 결정이 가능
**Why 3**: 데드라인 초과 시 조치가 사전 정의된 이유는? -> 초과 시점에 "어떻게 할지" 논의하면 추가 지연. 사전에 대응책(범위 축소, 부분 배포)을 정해두면 즉시 실행 가능

### DRI 배정
**Why 1**: 왜 "공동" 배정을 폐지하나? -> 공동 = 아무도 최종 책임을 지지 않음. 문제 발생 시 "상대방이 했을 것"으로 미룸
**Why 2**: DRI가 병목이 되지 않나? -> DRI는 "최종 책임자"이지 "유일한 실행자"가 아님. 지원 팀이 실행을 분담하되, 결과 책임은 DRI
**Why 3**: DRI를 어떤 기준으로 선정하나? -> Cycle 6 합의의 "파일 소유권" 기준. 해당 파일의 주 담당이 DRI

---

## 합의 사항

### 1. 테스트 전략 3계층
- **단위 테스트**: 각 항목의 핵심 함수별 테스트. 토큰 검증은 "full 대비 비율"로 (로키 제안 수용)
- **통합 테스트**: 7개 시나리오(INT-01~07). hooks circuit breaker는 mock 단위 + 주 1회 전체 통합 분리 (로키 제안 수용)
- **회귀 테스트**: 6개 항목 각각에 "기존 테스트 스위트 전부 통과" 기준. hooks 회귀는 "기능적 정확성" 검증 (로키 지적 반영)

### 2. 팀 배정 최종
- **"공동" 배정 폐지. 모든 항목에 DRI(단독 책임자) 배정**
- 헤르메스 DRI: (1), (2), (5), (7), feature_flags.json
- 마아트 DRI: (3), (4), 기준선 측정, A/B 설계
- 오딘: WORKFLOW 문서 지원 + P3 사전 설계 리드
- 로키 + 프로메테우스: 전 항목 설계 리뷰 + 위험 분석

### 3. 완료 기준(DoD)
- 6개 항목 각각에 체크리스트 형식 DoD 확정 (상기 마아트 제안안)
- **모든 DoD에 데드라인 포함** (로키 제안 수용)
- 데드라인 초과 시 조치 사전 정의 (범위 축소, 부분 배포, 기간 연장 최대 1회)

### 4. 실행 타임라인 최종 (8주)
- Week 0: 기준선 측정 + feature_flags.json 설계
- Week 1-2: 그룹 A(P1: 1+2) + 그룹 B 설계(P2: 3+4)
- Week 3: 그룹 C(P1: 7) + P2 구현(4, 5)
- Week 4: P1 효과 측정 + haiku A/B 시작 + 전체 통합 테스트
- Week 5-8: A/B 진행 + P3 설계 + 격주 효과 보고
- Week 9+: 전체 평가 + P3/P4 결정

### 5. 프로젝트 성공 기준
- P1 3항목 100% 완료 by Week 4
- P2 2/3 완료 by Week 4 (haiku A/B 진행 중)
- QC 패스율 기준선 대비 유지 또는 개선
- 롤백 2회 이하
- 데드라인 준수율 80%+

### 6. 토큰 검증 방식
- 고정 토큰 수 기준 폐지
- **full 대비 비율**로 검증:
  - summary: full의 15~25%
  - standard: full의 40~60%
  - full: 기존 대비 delta < 5%

### 7. 기준선 측정 항목 (Week 0)
- build_prompt() 출력 토큰 수 (팀별, 레벨별)
- QC 패스율, QC 실행 시간 (평균, P95)
- 세션당 Write/Edit 횟수 (평균, 최대)
- QC 이슈 유형 분포
- 토큰 소비량 (평균, P95)
- worktree 성공률
- **DRI: 마아트. 지원: 헤르메스(데이터 추출)**

---

## 미해결 이슈

1. **tests/ 디렉토리 구조 확정**: 현재 tests/ 하위에 어떤 파일이 있는지, 통합 테스트용 `tests/integration/` 디렉토리 신설 여부 -- 담당: 헤르메스
2. **CI 파이프라인에 hooks 테스트 통합**: hooks mock 단위 테스트를 기존 CI에 추가하는 방법. 주 1회 전체 통합 테스트 스케줄링 -- 담당: 헤르메스
3. **A/B 테스트의 통계적 유의성 검정 방법**: FNR 비교에 어떤 통계 검정(chi-squared, Fisher's exact)을 사용하는가. n=100에서 검정력(power) 충분한가 -- 담당: 마아트 + 로키
4. **"데드라인 초과 시 범위 축소"의 구체적 기준**: 어떤 기능을 먼저 축소하는가. Progressive Disclosure에서 "summary 모드 제거하고 standard/full만 유지"가 축소안인가 -- 담당: 프로메테우스
5. **feature_flags.json 로딩 메커니즘**: dispatch.py가 실행 시 feature_flags.json을 읽는 로직 구현 방법. hot reload(파일 변경 감지)를 지원하는가, 프로세스 재시작이 필요한가 -- 담당: 헤르메스
6. **기준선 측정 데이터 저장소**: 측정 결과를 어디에 저장하는가. `.metrics/` 디렉토리? 별도 JSON? 효과 측정 시 자동 비교 가능한 형식 -- 담당: 마아트 + 헤르메스