# task-1285.1 미팅 Cycle 6
날짜: 2026-03-31
안건: 전체 10개 항목 파일 충돌 매트릭스 + 동시 진행 그룹 + 순서 의존성 + 팀 배정 초안

## 참석자 발언

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

**1. 파일 충돌 매트릭스 — 기술 분석:**

10개 항목이 수정하는 파일을 전수 조사했습니다.

**dispatch.py 충돌 분석:**

| 항목 | dispatch.py 수정 내용 | 충돌 심각도 |
|---|---|---|
| (1) Progressive Disclosure | build_prompt() 호출부에 prompt_detail 전달 | 중 |
| (2) 읽기/쓰기 격리 | --agent-type 파라미터 추가, worktree 조건부 호출 | **높음** |
| (9) Agent Teams API | cokacdir --cron 호출을 API 호출로 교체 | **높음** |
| (10) Task 파일 표준화 | parse_task_file() 함수 추가 | 중 |

dispatch.py를 건드리는 항목이 4개입니다. 특히 (2)와 (9)는 dispatch.py의 핵심 실행 흐름을 변경하므로, **동시 진행 시 충돌이 확실합니다.** (9)는 P4이므로 당장은 문제없지만, 향후 (9)를 진행할 때 (2)가 완료된 dispatch.py 위에서 작업해야 합니다.

**team_prompts.py 충돌 분석:**

| 항목 | team_prompts.py 수정 내용 | 충돌 심각도 |
|---|---|---|
| (1) Progressive Disclosure | build_prompt()에 prompt_detail 파라미터 추가 | **높음** |
| (2) 읽기/쓰기 격리 | build_prompt()에 agent_type 전달, 프롬프트 텍스트 분기 | **높음** |
| (5) 모델 매핑 테이블 | MODEL_MAP 상수 추가, _build_cowork_section() 수정 | 중 |
| (7) hooks 자동 강제 | 간접 영향 (hooks 에러 시 프롬프트에 경고 삽입) | 낮음 |
| (8) Context Search | 과거 보고서 검색 결과를 프롬프트에 주입하는 새 섹션 | 중 |

team_prompts.py는 **가장 충돌이 심한 파일**입니다. 5개 항목이 동시에 건드립니다. 특히 (1)과 (2)가 build_prompt() 시그니처를 동시에 변경하므로, Cycle 2에서 합의한 대로 **동일 브랜치에서 순차 구현**이 필수입니다.

**DIRECT-WORKFLOW.md 충돌 분석:**

| 항목 | DIRECT-WORKFLOW.md 수정 내용 | 충돌 심각도 |
|---|---|---|
| (2) 읽기/쓰기 격리 | 에이전트 분류 가이드 섹션 추가 | 중 |
| (5) 모델 매핑 테이블 | "모델 선택 가이드" 섹션에 MODEL_MAP 참조 추가 | 낮음 |
| (7) hooks 자동 강제 | hooks 동작 설명 섹션 추가 | 중 |
| (10) Task 파일 표준화 | task 파일 작성 가이드 섹션 추가 | 낮음 |

4개 항목이 DIRECT-WORKFLOW.md를 수정하지만, 각각 **서로 다른 섹션**을 추가하므로 충돌 가능성은 낮습니다. 단, 동시에 여러 PR이 이 파일을 수정하면 merge conflict가 발생할 수 있으므로, 하나의 브랜치에서 순차 수정하거나 섹션 단위로 분리 작업이 필요합니다.

**QC-RULES.md 충돌 분석:**

| 항목 | QC-RULES.md 수정 내용 | 충돌 심각도 |
|---|---|---|
| (4) TRUST 5 구조화 | 본문 구조는 유지, trust_summary 태그 설명 추가 | 낮음 |
| (7) hooks 자동 강제 | "hooks =/= QC 면제" 규칙 추가 | 낮음 |

2개 항목만 QC-RULES.md를 건드리며, Cycle 3 합의에 따라 본문 구조 변경 없이 부분 추가만 하므로 충돌 위험은 낮습니다.

**qc_verify.py 충돌 분석:**

| 항목 | qc_verify.py 수정 내용 | 충돌 심각도 |
|---|---|---|
| (3) haiku 전용화 | 결과 JSON에 model_used 필드 추가 | 낮음 |
| (4) TRUST 5 구조화 | build_result()에 trust_summary 필드 추가 | 중 |

2개 항목이 qc_verify.py의 결과 JSON을 확장합니다. build_result() 함수를 동시에 수정하면 충돌합니다. (3)과 (4)는 같은 P2이므로 순차 구현이 필요합니다.

**settings.json 충돌 분석:**

| 항목 | settings.json 수정 내용 | 충돌 심각도 |
|---|---|---|
| (2) 읽기/쓰기 격리 | permissionMode 설정 (에이전트 타입별) | 중 |
| (7) hooks 자동 강제 | hooks 섹션 추가 (PostToolUse) | 중 |
| (2) git 차단 | permissions.deny 목록 추가 | 중 |

settings.json은 JSON 구조라 서로 다른 키를 추가하면 충돌이 적지만, 동시에 파일을 열고 수정하면 JSON 형식 오류 위험이 있습니다.

---

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

**1. 파일 충돌 매트릭스 종합 — 시각화:**

```
            dispatch  team_prompts  WORKFLOW.md  QC-RULES  qc_verify  settings
(1) Prog.D    O          O*            .           .          .          .
(2) R/W격리   O*         O*            O           .          .          O
(3) haiku     .          .             .           .          O          .
(4) TRUST5    .          .             .           O          O          .
(5) MODEL     .          O             O           .          .          .
(6) @MX       .          .             .           .          .          .
(7) hooks     .          o             O           O          .          O*
(8) CtxSrch   .          O             .           .          .          .
(9) API전환   O*         .             .           .          .          .
(10)Task표준  O          .             O           .          .          .

O* = 핵심 수정 (구조/시그니처 변경)
O  = 일반 수정 (섹션/필드 추가)
o  = 간접 영향
.  = 수정 없음
```

**핫스팟 파일 순위:**
1. **team_prompts.py** -- 5개 항목이 수정 (1, 2, 5, 7, 8)
2. **dispatch.py** -- 4개 항목이 수정 (1, 2, 9, 10)
3. **DIRECT-WORKFLOW.md** -- 4개 항목이 수정 (2, 5, 7, 10)
4. **settings.json** -- 3개 항목이 수정 (2, 2-git, 7)
5. **qc_verify.py** -- 2개 항목이 수정 (3, 4)
6. **QC-RULES.md** -- 2개 항목이 수정 (4, 7)

**2. 동시 진행 가능한 항목 그룹:**

파일 충돌이 없거나 최소인 항목끼리 그룹화:

**그룹 A (team_prompts.py + dispatch.py 중심):**
- (1) Progressive Disclosure + (2) 읽기/쓰기 격리
- 이 두 항목은 team_prompts.py와 dispatch.py를 **동시에** 수정하므로 반드시 **같은 브랜치, 순차 구현**

**그룹 B (QC 중심):**
- (3) haiku 전용화 + (4) TRUST 5 구조화
- 둘 다 qc_verify.py를 수정하지만, 서로 다른 필드를 추가하므로 순차 구현 시 충돌 최소

**그룹 C (설정/문서 중심):**
- (7) hooks 자동 강제
- settings.json과 DIRECT-WORKFLOW.md를 수정. 그룹 A와 WORKFLOW.md에서 겹치지만, 서로 다른 섹션을 추가

**그룹 D (독립 항목):**
- (5) 모델 매핑 테이블 -- team_prompts.py의 MODEL_MAP 상수 추가. 그룹 A 이후 진행
- (10) Task 파일 표준화 -- dispatch.py의 parse_task_file() 추가. 그룹 A 이후 진행

**그룹 E (장기/독립):**
- (6) @MX 태그 -- 코드 주석 수준, 파일 충돌 없음
- (8) Context Search -- 인프라 의존, 독립
- (9) Agent Teams API -- dispatch.py 의존이지만 P4이므로 당장 무관

**3. 동시 진행 가능 판정:**

| 조합 | 동시 진행 | 이유 |
|---|---|---|
| A + B | **가능** | 파일 겹침 없음 (team_prompts vs qc_verify) |
| A + C | **불가** | WORKFLOW.md 동시 수정 위험. C는 A 이후 |
| B + C | **가능** | 파일 겹침 최소 (QC-RULES.md만 낮은 충돌) |
| A + D | **불가** | dispatch.py, team_prompts.py 겹침 |
| B + D | **가능** | 파일 겹침 없음 |

---

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

**1. 파일 충돌의 QC 영향:**

파일 충돌은 코드 품질에 직접적 영향을 줍니다. **merge conflict 해결 과정에서 한쪽 변경이 누락되는 것이 가장 흔한 QC 이슈**입니다.

**QC 관점의 위험 순위:**

| 충돌 지점 | 위험도 | 이유 |
|---|---|---|
| team_prompts.py build_prompt() 시그니처 | **최고** | 시그니처 변경은 모든 호출부에 전파. merge 실수 시 런타임 에러 |
| dispatch.py 실행 흐름 | **높음** | 에이전트 실행의 진입점. 오류 시 전체 시스템 중단 |
| qc_verify.py build_result() | **중간** | JSON 필드 추가는 하위호환적이지만, 중복 키/형식 오류 가능 |
| DIRECT-WORKFLOW.md | **낮음** | 문서 수정은 기능에 영향 없음. 내용 불일치만 주의 |
| settings.json | **중간** | JSON 형식 오류 시 Claude Code 전체 설정이 깨짐 |

**2. 순서 의존성 분석:**

```
(2) 읽기/쓰기 격리
  |
  +---> (7) hooks 자동 강제 (에이전트 타입별 hooks 분기 필요)
  |
  +---> (1) Progressive Disclosure (team_prompts.py 시그니처 동시 설계)
           |
           +---> (5) 모델 매핑 테이블 (build_prompt 안정화 후)
           |
           +---> (8) Context Search (프롬프트 구조 안정화 후)

(4) TRUST 5 구조화
  |
  +---> (3) haiku 전용화 (TRUST 기준으로 haiku 적합성 판단)

(7) hooks 운영 4주
  |
  +---> (6) @MX 태그 (hooks로 태그 위반 감지)

(1)+(2) P1 완료
  |
  +---> (10) Task 파일 표준화 (dispatch.py 안정화 후)
  |
  +---> (9) Agent Teams API (dispatch.py 구조 확정 후)
```

**필수 선행 관계 요약:**

| 선행 항목 | 후행 항목 | 이유 |
|---|---|---|
| (2) R/W 격리 | (7) hooks | 에이전트 타입별 hooks 분기 |
| (1) Prog. Disclosure | (5) MODEL_MAP | build_prompt() 시그니처 안정화 |
| (4) TRUST 5 | (3) haiku | TRUST 기준으로 haiku 적합성 판단 |
| (7) hooks 4주 | (6) @MX 태그 | hooks 인프라 위에 태그 감지 |
| (1)+(2) P1 | (10) Task 표준화 | dispatch.py 안정화 |
| (1)+(2) P1 | (9) API 전환 | dispatch.py 구조 확정 |
| (1) Prog. Disclosure | (8) Context Search | 프롬프트 크기 제어 체계 확립 후 |

**3. 테스트 전략 — 파일 충돌 방지:**

- **team_prompts.py 변경 시**: build_prompt()의 모든 팀유형(direct, marketing, mcp, design, publishing) 회귀 테스트 필수
- **dispatch.py 변경 시**: end-to-end 테스트 (dispatch → build_prompt → worktree → 에이전트 실행) 필수
- **settings.json 변경 시**: JSON 스키마 검증 스크립트 실행. 포맷 에러 방지
- **qc_verify.py 변경 시**: 기존 결과 JSON과 신규 결과 JSON의 하위호환성 테스트

---

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

**1. 파일 충돌 매트릭스에 대한 공격:**

오딘이 깔끔한 매트릭스를 만들었지만, **핵심을 놓치고 있습니다.**

**공격 1: "파일 충돌"이 아니라 "개념 충돌"이 진짜 위험입니다.**

team_prompts.py를 5개 항목이 수정한다고 했는데, 파일 수준의 충돌(merge conflict)은 기술적으로 해결 가능합니다. 진짜 위험은 **"build_prompt()의 설계 의도 충돌"** 입니다.

예를 들어:
- (1) Progressive Disclosure는 프롬프트를 **줄이려** 합니다
- (8) Context Search는 프롬프트에 과거 보고서를 **추가하려** 합니다
- (5) MODEL_MAP은 모델 선택 가이드를 **자동 생성하여 추가**하려 합니다

이 세 개가 동시에 적용되면 build_prompt()는 "줄이면서 동시에 늘리는" 모순적 함수가 됩니다. **파일 충돌은 git이 잡아주지만, 설계 의도 충돌은 아무도 잡아주지 않습니다.**

**공격 2: "동시 진행 가능" 판정이 낙관적입니다.**

오딘이 "A + B 동시 진행 가능"이라고 했는데, 그룹 A(team_prompts.py)와 그룹 B(qc_verify.py)가 파일 수준에서 겹치지 않더라도, **테스트 환경이 겹칩니다.** 그룹 A의 build_prompt() 변경을 테스트하려면 전체 파이프라인(dispatch → prompt → worktree → agent)을 돌려야 합니다. 그룹 B의 qc_verify.py 변경도 전체 파이프라인에서 테스트해야 합니다. **동시에 두 그룹을 변경하면 테스트에서 어떤 변경이 어떤 결과를 냈는지 분리(isolation)가 불가능합니다.**

**공격 3: 순서 의존성이 과도하게 복잡합니다.**

마아트의 의존성 그래프를 보면 거의 모든 항목이 (1)과 (2)에 의존합니다. 이것은 **(1)과 (2)가 실패하면 나머지 8개 항목이 전부 블록**된다는 뜻입니다. 단일 장애점(SPOF)이 2개나 있습니다. **"P1이 가장 중요하니까 먼저"라는 논리가 "P1이 실패하면 전체 프로젝트가 중단"이라는 리스크를 만들었습니다.**

대안: (3) haiku A/B 테스트와 (4) TRUST 구조화는 (1), (2)와 독립적으로 진행 가능합니다. 이것들을 P1과 **병렬**로 먼저 시작하면, P1 지연 시에도 P2 일부가 진행됩니다.

**공격 4: 팀 배정을 논의하기엔 아직 이릅니다.**

P1의 build_prompt() 시그니처도 확정되지 않았고, hooks의 exitCodePolicy 지원 여부도 미확인입니다. **설계가 미확정인 상태에서 팀 배정은 "누가 불확실한 작업을 맡을 것인가?"를 정하는 것입니다.** 설계 확정 후 배정이 순서입니다.

**2. 내 결론:**
- 파일 충돌 매트릭스는 유용하지만, **개념 충돌 매트릭스**를 추가해야 합니다
- 동시 진행은 파일 비겹침만으로 판단하면 안 되고, **테스트 격리 가능 여부**도 고려해야 합니다
- 팀 배정은 P1 설계 확정 후로 미뤄야 합니다. 지금은 **배정 원칙**만 합의합니다

---

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

**1. 파일 충돌 매트릭스 — 전략적 해석:**

헤르메스와 오딘의 기술적 분석을 전략적으로 종합합니다.

**핵심 인사이트: team_prompts.py가 아키텍처의 중심축(hub)입니다.**

5개 항목이 team_prompts.py를 건드린다는 것은, 이 파일이 시스템의 "병목"이라는 뜻입니다. 이 병목을 해소하는 방법은 두 가지입니다:

A) **순차 실행**: 한 번에 하나의 항목만 team_prompts.py를 수정. 안전하지만 느림.
B) **아키텍처 분리**: team_prompts.py를 모듈화하여 각 항목이 독립적인 모듈을 수정. 빠르지만 리팩토링 비용.

현 단계에서는 A(순차 실행)가 현실적입니다. B는 장기 과제로 남깁니다.

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

**"개념 충돌"에 대한 대응:**
로키의 지적이 정확합니다. (1)은 줄이고 (8)은 늘리는 모순을 해소하려면, **"프롬프트 토큰 버짓(budget)" 개념을 도입**합니다.

```
총 프롬프트 토큰 버짓: 3,000 토큰
- 기본 지시: 500 (고정)
- 워크플로우 참조: 200 (고정)
- 팀원/코워크: 300~800 (prompt_detail에 따라 가변)
- 모델 가이드: 100~200 (MODEL_MAP에서 생성)
- 과거 컨텍스트: 0~500 (Context Search, 미래)
- 여유분: 나머지
```

이렇게 하면 각 항목이 build_prompt()에 추가하는 내용이 "버짓 내"인지 확인할 수 있습니다. Progressive Disclosure가 버짓을 확보하고, 나머지 항목이 그 버짓 내에서 추가하는 구조.

**"P1 SPOF"에 대한 대응:**
로키가 맞습니다. (3)과 (4)를 P1과 병렬로 시작하는 것에 동의합니다.

**수정된 실행 타임라인:**

```
Week 1-2: [P1] (1)+(2) 순차 구현 (team_prompts.py, dispatch.py)
           [P2 병렬] (4) TRUST trust_summary 설계 (코드 수정 없이 매핑 테이블 확정)
           [P2 병렬] (3) haiku A/B 테스트 설계 (테스트 케이스 선정, 기준 확정)

Week 3:   [P1] (7) hooks 자동 강제 (settings.json, parse 스크립트)
           [P2] (4) TRUST trust_summary qc_verify.py 구현
           [P2] (5) MODEL_MAP team_prompts.py 추가 (P1의 build_prompt 안정화 후)

Week 4:   [P1] 효과 측정 시작 (기준선 수집은 Week 0에 이미 완료)
           [P2] (3) haiku A/B 테스트 시작 (4주간)

Week 5-8: [P2] haiku A/B 테스트 진행
           [P3] (10) Task 파일 표준화 설계 문서 작성

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

**"팀 배정"에 대한 대응:**
로키의 "설계 확정 후 배정"에 부분 동의합니다. 지금은 **배정 원칙**만 합의합니다.

**팀 배정 원칙:**

| 원칙 | 설명 |
|---|---|
| 파일 소유권 | 각 핵심 파일에 "주 담당 팀"을 지정. 해당 파일을 수정하는 항목은 주 담당 팀이 리드 |
| 순차 잠금 | team_prompts.py를 수정하는 항목은 한 번에 하나만. "잠금 → 수정 → 검증 → 해제" 사이클 |
| QC 독립성 | QC 관련 파일(qc_verify.py, QC-RULES.md)은 마아트 팀이 단독 소유 |

**파일 소유권 초안:**

| 파일 | 주 담당 | 사유 |
|---|---|---|
| dispatch.py | 헤르메스 (dev1) | 백엔드 인프라 핵심 |
| team_prompts.py | 헤르메스 (dev1) | 프롬프트 생성 로직 |
| DIRECT-WORKFLOW.md | 오딘 (dev2) | 워크플로우 문서 |
| QC-RULES.md | 마아트 (QC) | QC 규칙 |
| qc_verify.py | 마아트 (QC) | QC 검증 로직 |
| settings.json | 헤르메스 (dev1) | 인프라 설정 |

**항목별 배정 원칙:**

| 항목 | 리드 팀 | 지원 팀 | 사유 |
|---|---|---|---|
| (1) Progressive Disclosure | 헤르메스 | 오딘 | team_prompts.py + 스킬 파일 |
| (2) 읽기/쓰기 격리 | 헤르메스 | 오딘 | dispatch.py + WORKFLOW |
| (3) haiku A/B 테스트 | 마아트 | 헤르메스 | QC 품질 검증 주도 |
| (4) TRUST 5 구조화 | 마아트 | - | QC 프레임워크 |
| (5) 모델 매핑 테이블 | 헤르메스 | 오딘 | team_prompts.py |
| (7) hooks 자동 강제 | 헤르메스 | 마아트 | settings.json + QC 연동 |
| (10) Task 파일 표준화 | 오딘 | 헤르메스 | 워크플로우 + dispatch.py |
| (6) @MX 태그 | 미정 | - | P4, 착수 미정 |
| (8) Context Search | 미정 | - | P4, 인프라 의존 |
| (9) Agent Teams API | 미정 | - | P4, API 의존 |

로키(DA)와 프로메테우스(전략)는 **모든 항목의 리뷰어** 역할. 코드 수정에는 참여하지 않지만, 설계 리뷰와 위험 분석을 담당합니다.

---

## 3 Whys 검증

### 파일 충돌 관리 전략
**Why 1**: 왜 파일 충돌 매트릭스가 필요한가? -> 10개 항목을 효율적으로 병렬화하려면 충돌 지점을 사전에 파악해야 함
**Why 2**: 파일 수준 충돌만 관리하면 충분한가? -> 아니오. 로키 지적대로 "개념 충돌"도 존재. 프롬프트 토큰 버짓 개념으로 개념 충돌을 관리
**Why 3**: 순차 실행이 비효율적이지 않은가? -> team_prompts.py 등 핵심 파일은 순차 필수. 대신 QC 그룹(B)을 P1과 병렬 진행하여 전체 일정 단축

### 팀 배정 원칙
**Why 1**: 왜 파일 소유권을 지정하나? -> 동일 파일에 여러 팀이 동시 수정하면 merge conflict + 개념 충돌 발생
**Why 2**: 소유권이 병목을 만들지 않나? -> 주 담당이 리드하되, 지원 팀이 PR 리뷰로 참여하므로 지식 공유는 유지
**Why 3**: 소유권이 영구적인가? -> 아니오. P1/P2 기간 한정. P3 이후 재평가

### 실행 타임라인
**Why 1**: 왜 P2를 P1과 병렬로 시작하나? -> P1 SPOF 리스크 완화. P1 지연 시에도 P2 일부 진행 가능
**Why 2**: 병렬 진행이 테스트 격리를 해치지 않나? -> 파일 겹침이 없는 그룹만 병렬. team_prompts.py와 qc_verify.py는 독립적이므로 테스트 격리 가능
**Why 3**: 8주 타임라인이 현실적인가? -> Week 1-4는 P1/P2 구현, Week 5-8은 A/B 테스트 + P3 설계. 코드 작업은 4주, 검증은 4주로 현실적 배분

---

## 합의 사항

### 1. 파일 충돌 매트릭스
- **핫스팟 파일 확정**: (1) team_prompts.py(5개 항목), (2) dispatch.py(4개 항목), (3) DIRECT-WORKFLOW.md(4개 항목)
- **핵심 충돌 쌍**: (1)+(2)의 team_prompts.py build_prompt() 시그니처 변경 -- 반드시 동일 브랜치 순차 구현
- **QC 파일 독립**: qc_verify.py, QC-RULES.md는 다른 항목과 파일 충돌이 적어 병렬 진행 가능
- **개념 충돌 관리**: "프롬프트 토큰 버짓" 개념 도입. 각 항목이 build_prompt()에 추가하는 토큰을 사전 할당

### 2. 동시 진행 가능 그룹
- **그룹 A**: (1) Progressive Disclosure + (2) 읽기/쓰기 격리 -- 순차, 같은 브랜치
- **그룹 B**: (3) haiku A/B + (4) TRUST 5 -- 순차, 같은 QC 브랜치
- **A와 B는 병렬 진행 가능** (파일 겹침 없음, 테스트 격리 가능)
- **그룹 C**: (7) hooks -- 그룹 A 완료 후 착수 (에이전트 타입별 분기 의존)
- **그룹 D**: (5) MODEL_MAP -- 그룹 A의 build_prompt() 안정화 후
- **그룹 E**: (10) Task 표준화 -- P3, 설계만 선행

### 3. 순서 의존성 확정
- **(2) -> (7)**: 읽기/쓰기 격리 완료 후 hooks 적용
- **(1) -> (5)**: Progressive Disclosure 완료 후 MODEL_MAP 적용
- **(4) -> (3)**: TRUST 구조화 후 haiku A/B 판정 기준 활용
- **(7) 4주 운영 -> (6)**: hooks 안정화 후 @MX 태그 검토
- **(1)+(2) -> (10)**: P1 완료 후 Task 표준화 실구현
- **(1)+(2) -> (9)**: P1 완료 후 API 전환 검토

### 4. 팀 배정 원칙
- **파일 소유권 제도 도입**: 핵심 파일별 주 담당 팀 지정 (P1/P2 기간 한정)
  - dispatch.py, team_prompts.py, settings.json -> 헤르메스(dev1)
  - DIRECT-WORKFLOW.md -> 오딘(dev2)
  - qc_verify.py, QC-RULES.md -> 마아트(QC)
- **항목별 리드/지원 배정**: 상기 프로메테우스 제안안 합의
- **리뷰어**: 로키(DA) + 프로메테우스(전략)가 모든 항목의 설계 리뷰 + 위험 분석 담당
- **정식 배정**: P1 설계 확정 후 확정 (로키 의견 반영)

### 5. 실행 타임라인 (수정안)
- **Week 0 (현재)**: 기준선 측정 시작 (4/1~4/14)
- **Week 1-2**: 그룹 A(P1: 1+2) + 그룹 B 설계(P2: 3+4 설계만) 병렬
- **Week 3**: 그룹 C(P1: 7) + 그룹 B 구현(P2: 4 qc_verify.py) + 그룹 D(P2: 5)
- **Week 4**: P1 효과 측정 + P2 haiku A/B 시작
- **Week 5-8**: A/B 테스트 진행 + P3 설계 문서 작성
- **Week 9+**: 전체 평가 -> P3 실구현 / P4 재논의

---

## 미해결 이슈

1. **"프롬프트 토큰 버짓" 상세 설계**: 각 섹션의 토큰 할당량, 초과 시 처리 방법, 측정 도구(tiktoken) 연동 -- 담당: 헤르메스 + 프로메테우스
2. **team_prompts.py 모듈화 장기 계획**: 5개 항목이 하나의 파일을 수정하는 구조적 문제. 장기적으로 모듈 분리(prompt_builder/, model_map.py, context_injector.py 등)가 필요한지 -- 담당: 헤르메스
3. **테스트 격리 방법론**: 그룹 A와 B를 병렬 진행 시, end-to-end 테스트에서 변경 원인을 분리하는 구체적 방법 -- 담당: 마아트
4. **파일 소유권 제도의 운영 규칙**: 소유권자 부재 시 대리 수정 절차, 긴급 수정 시 소유권 우회 규칙 -- 담당: 프로메테우스
5. **P1 실패 시 contingency plan**: (1) 또는 (2)가 실패/지연될 경우, 후속 항목(7, 5, 10)의 대체 진행 경로 -- 담당: 프로메테우스
6. **settings.json 변경 관리**: 여러 항목이 동시에 settings.json을 수정할 때의 merge 전략 (JSON은 merge conflict 해결이 까다로움) -- 담당: 헤르메스
7. **개념 충돌 모니터링**: "줄이면서 늘리는" 모순을 탐지하는 구체적 메커니즘 -- 프롬프트 토큰 버짓으로 해소 예정이나, 버짓 설계가 선행 필요