# task-1285.1 미팅 Cycle 10 (최종)
날짜: 2026-03-31
안건: 최종 합의 + 로키 최종 공격 + 만장일치 투표

## 참석자 발언

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

**전체 10개 항목 최종 검토:**

10사이클에 걸쳐 논의한 결과를 기술적 관점에서 정리합니다.

| # | 항목 | 최종 상태 | 기술 요약 |
|---|---|---|---|
| 1 | Progressive Disclosure | P1, Week 1-2 구현 | build_prompt()에 disclosure_phase 3단계. CRITICAL 셋 하드코딩. 비율 검증 |
| 2 | 읽기/쓰기 격리 | P1, Week 1-2 구현 | dispatch.py --agent-type + worktree_manager.py --read-only. 기본값 "write" |
| 3 | haiku 전용화 | P2, Week 4-8 A/B | Fisher's exact test, n>150, FNR<15%. 4주 A/B + 최대 1주 연장 |
| 4 | TRUST 5 태그 | P2, Week 3 구현 | qc_verify.py trust_summary JSON. verifier 9종→TRUST 5차원 매핑 |
| 5 | 모델 매핑 테이블 | P2, Week 3 구현 | team_prompts.py MODEL_MAP 상수. staleness 7일 경고 |
| 6 | @MX 태그 | P4, 장기 | P1/P2 효과 검증 후 재논의 |
| 7 | hooks 자동 강제 | P1, Week 3 구현 | PostToolUse pyright+ruff. 심각도 2단계. circuit breaker(15/30/동일3회) |
| 8 | Context Search | P4, 장기 | ADK 네이티브 기능 대기 |
| 9 | Agent Teams API | P4, 장기 | Google ADK 로드맵 의존 |
| 10 | Task 파일 구조 표준화 | P3(부분)+P4 | P3: 네이밍 규칙. P4: 구조 자동 생성 |

**기술적 리스크 최종 평가:**

- 핫스팟 파일(dispatch.py, team_prompts.py) 충돌: 그룹A→C 순차 실행으로 관리. feature branch 분리
- feature_flags.json 인프라: Week 0에 완성. 모든 항목의 킬 스위치 기반
- 3-Layer 롤백: 각 항목 독립 롤백 가능 확인. 최악 시 git revert 단일 커밋

**내 판단: 기술적으로 실행 가능합니다.** 10사이클의 논의로 엣지 케이스가 충분히 식별되었고, 각 항목에 킬 스위치가 있어 실패 시 즉시 복구 가능합니다.

---

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

**워크플로우/문서 관점 최종 검토:**

| 변경 대상 문서 | 변경 내용 | 리스크 | 상태 |
|---|---|---|---|
| DIRECT-WORKFLOW.md | 섹션 5 "에이전트 분류 가이드" 추가 | 기존 섹션 1-4 무변경 확인 필요 | 설계 완료, 구현 대기 |
| QC-RULES.md | trust_summary 설명 + "hooks=/=QC면제" 규칙 추가 | 기존 QC 규칙과 모순 없음 확인 필요 | 설계 완료, 구현 대기 |
| settings.json | hooks 섹션 추가 (PostToolUse) | 기존 설정과 병합 시 충돌 없음 확인 | 설계 완료, 구현 대기 |
| feature_flags.json | 신규 파일 | 신규이므로 충돌 없음 | 스키마 확정 |

**실행 순서 최종 확인:**

```
Week 0: 기준선 측정 + feature_flags.json 생성
  ↓
Week 1-2: 그룹A (P1-1 + P1-2) 병렬
  ↓ (그룹A PR 머지 후)
Week 3: 그룹C (P1-7) + P2 구현 (TRUST 5, MODEL_MAP)
  ↓ (통합 테스트 통과 후)
Week 4: P1 효과 측정 + haiku A/B 시작
  ↓
Week 5-8: A/B 진행 + P3 사전 설계
```

**의존성 체인이 명확합니다.** 각 단계의 진입 조건(PR 머지, 테스트 통과)이 정의되어 있어 무분별한 병렬 실행 방지.

**내 판단: 워크플로우 관점에서 준비 완료입니다.** Week 0의 기준선 측정이 정확하게 수행되는 것이 전체 프로젝트의 기반입니다.

---

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

**품질 관점 최종 검토:**

10사이클 동안 확립된 품질 게이트:

| 게이트 | 검증 내용 | 판정 기준 | 실패 시 조치 |
|---|---|---|---|
| 단위 테스트 | 각 항목의 핵심 함수 | 전체 통과 | 구현 수정 |
| 통합 테스트 (INT-01~07) | 파이프라인 end-to-end | 전체 통과 | 설계 재검토 |
| 회귀 테스트 | 기존 기능 보존 | 기존 assertion 전부 통과 | 롤백 |
| 비율 검증 | 토큰 비율 (summary/standard/full) | 15-25% / 40-60% / delta<5% | 프롬프트 재설계 |
| FNR 검증 (A/B) | haiku vs sonnet | FNR < 15%, Fisher's p < 0.05 | haiku 기각 |
| 효과 측정 | 기준선 대비 QC 패스율 | 20%p 이상 하락 시 경고 | 원인 분석 + 조건부 롤백 |

**DoD(Definition of Done) 최종 확인:**

- 6개 항목 각각에 체크리스트 형식 DoD 확정 (Cycle 8)
- 모든 DoD에 데드라인 포함 (Cycle 8 로키 제안)
- 데드라인 초과 시 1차/2차 축소안 사전 정의 (Cycle 9)
- Week 0 기준선에 sonnet FNR 추정 추가 (Cycle 9 로키 제안)

**내 판단: 품질 검증 체계가 충분합니다.** 단위/통합/회귀 3계층 테스트 + 효과 측정 비교 + A/B 통계 검정이 구비되어 있습니다.

---

### 로키 (DA) -- [최종 사이클 최강 공격]

**이것이 마지막 기회입니다. 전체 계획에서 가장 약한 고리 3가지를 지적합니다.**

---

**최약 고리 #1: "Week 0 기준선 측정"이 전체 프로젝트의 단일 실패 지점(SPOF)입니다.**

전체 프로젝트가 Week 0 기준선에 의존합니다. 효과 측정, A/B 검정, 롤백 판단 -- 모두 기준선과의 비교에 기반합니다. 그런데:

- 기준선 측정 DRI는 마아트 1명입니다
- 기준선 측정 기간은 2주(4/1~4/14)인데, 이 기간에 이미 feature_flags.json 구현이 시작됩니다
- 기준선 측정 중에 코드가 변경되면, "기준선"이 아니라 "과도기 측정"이 됩니다

**최악 시나리오**: 마아트가 기준선 측정을 4/10에 완료했는데, 4/11에 헤르메스가 feature_flags.json을 머지. 4/12에 기준선을 다시 측정하면 이미 feature_flags 로딩 코드가 들어가 있어서 다른 수치가 나옴. 어떤 수치가 "진짜 기준선"인지 불명확.

**대안**: **기준선 측정은 어떤 코드 변경보다 먼저, 단독으로 완료해야 합니다.** Week 0의 첫 3일(4/1~4/3)을 기준선 전용으로 확보하고, feature_flags.json 구현은 4/4부터 시작. 기준선 완료 = feature_flags 구현의 진입 조건.

---

**최약 고리 #2: 8주 타임라인에 "버퍼"가 전혀 없습니다.**

Week 1-2에 P1-1, P1-2. Week 3에 P1-7, P2-4, P2-5. Week 4에 통합 테스트 + A/B 시작. 모든 주가 빈틈 없이 채워져 있습니다.

실무에서 일어나는 일들:
- 코드 리뷰에서 "설계 변경 필요" 피드백 → 1주 지연
- pyright 설정이 프로젝트별로 달라서 hooks 호환성 문제 → 디버깅 3일
- 헤르메스가 dispatch.py와 team_prompts.py를 동시에 수정하다가 merge conflict → 1일
- QC 패스율 기준선이 예상보다 낮아서 목표 재설정 필요 → 논의 2일

**각 주에 최소 1일의 버퍼가 있어야 합니다.** 현재 계획은 "모든 것이 계획대로 진행될 때"만 성립합니다. 소프트웨어 프로젝트에서 모든 것이 계획대로 진행된 적은 역사상 없습니다.

**대안**: 8주 → 10주로 확장하거나, 8주를 유지하되 Week 3와 Week 5에 "버퍼 데이"를 삽입. 또는 P2-5(MODEL_MAP)를 Week 3에서 Week 4로 이동하여 Week 3의 부하를 줄임.

---

**최약 고리 #3: 이 계획에는 "사람"이 빠져 있습니다.**

10사이클 동안 기술적 설계, 테스트 전략, 롤백 계획, 통계 검정을 논의했습니다. 하지만 **실제로 이 코드를 작성하는 것은 에이전트입니다.** 에이전트가 이 계획을 이해하고 실행할 수 있는가?

- 에이전트에게 "progressive disclosure를 구현하라"는 task를 줄 때, 이 10사이클의 합의 내용(disclosure_phase 3단계, CRITICAL 셋, 비율 검증, feature_flags 통합, 회귀 테스트 필요)을 **어떻게 전달합니까?**
- task 파일에 이 모든 스펙을 넣으면 프롬프트가 거대해집니다. Progressive Disclosure의 목적이 프롬프트를 줄이는 것인데, 그 구현 task의 프롬프트가 비대해지는 아이러니
- DRI가 "헤르메스"라고 했지만, 헤르메스는 에이전트입니다. 에이전트가 "DRI로서 다른 에이전트의 작업 결과를 리뷰"하는 메커니즘이 현재 MoAI에 존재합니까?

**3가지 최악 시나리오 종합:**

| # | 시나리오 | 확률 | 영향 | 대응 |
|---|---|---|---|---|
| 1 | 기준선 측정이 코드 변경과 겹쳐 무효화. 이후 모든 효과 측정이 왜곡된 기준선에 의존 | 중 (40%) | 심각 | 기준선 전용 기간 확보 (4/1~4/3) |
| 2 | 8주 무버퍼 일정에서 Week 2-3 지연 발생. P1 데드라인 초과. contingency 발동하여 scope 축소. 축소 후 남은 것이 "hooks만 적용"이라는 최소한의 결과 | 고 (60%) | 중 | 10주 확장 또는 Week 3/5 버퍼 삽입 |
| 3 | 에이전트가 10사이클 합의를 충분히 이해하지 못한 채 구현 시작. 설계와 다른 구현이 나옴. 리뷰에서 대규모 수정 필요. 사실상 재구현 | 중 (35%) | 심각 | 각 항목의 구현 스펙을 1페이지 문서로 요약. task 파일에 스펙 문서 경로만 참조 |

---

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

**로키 최종 공격에 대한 전략적 대응:**

---

**대응 #1: 기준선 SPOF 해소**

로키 지적이 정확합니다. 기준선 측정과 코드 변경이 겹치면 기준선이 무효화됩니다.

**수정안**: Week 0을 2-Phase로 분리:
- **Phase 0a (4/1~4/3)**: 기준선 측정 전용. 코드 변경 동결(code freeze). 마아트 DRI
- **Phase 0b (4/4~4/6)**: feature_flags.json 구현. 헤르메스 DRI. 기준선 확정 후 시작

이렇게 하면 기준선이 코드 변경 이전의 순수한 상태를 반영합니다.

**추가 안전장치**: 기준선 측정 결과를 `.metrics/baseline/` 에 저장한 후 `git tag baseline-v1`로 태그. 이 태그 시점의 코드 상태가 기준선의 코드 상태.

---

**대응 #2: 버퍼 삽입**

8주→10주 확장은 과도합니다. 대신 **기존 8주 내에서 재배치**합니다.

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

```
Week 0 (3/31~4/6):
  Phase 0a (4/1~4/3): 기준선 측정 전용 [code freeze]
  Phase 0b (4/4~4/6): feature_flags.json 구현

Week 1-2 (4/7~4/20):
  그룹A: P1-1 + P1-2 구현 + 단위/회귀 테스트
  [버퍼: Week 2 금요일(4/17)은 리뷰 + 버그 수정 전용]

Week 3 (4/21~4/27):
  그룹C: P1-7 hooks 구현
  P2-4: TRUST 5 구현
  [P2-5 MODEL_MAP를 Week 4로 이동하여 부하 분산]

Week 4 (4/28~5/4):
  P2-5: MODEL_MAP 구현
  통합 테스트 INT-01~07
  haiku A/B 시작
  P1 효과 측정
  [버퍼: INT 테스트 실패 시 수정 시간 확보]

Week 5-7 (5/5~5/25):
  A/B 진행 (주 1회 sonnet 재검증)
  P3 사전 설계
  격주 효과 보고

Week 8 (5/26~5/31):
  A/B 최종 판정
  전체 평가 보고서
  P3/P4 재논의 트리거 점검
```

**변경점:**
- P2-5 MODEL_MAP를 Week 3→Week 4로 이동 (Week 3 부하 분산)
- Week 2 금요일을 리뷰/버그수정 버퍼로 확보
- Week 0을 Phase 0a/0b로 분리

이것은 8주 타임라인을 유지하면서 현실적인 버퍼를 삽입한 것입니다.

---

**대응 #3: 에이전트 실행 가능성 확보**

로키의 "사람이 빠져있다" 지적은 이 프로젝트의 근본적 질문입니다. 에이전트가 10사이클 합의를 이해하고 실행할 수 있어야 합니다.

**해결책: 항목별 1-page 구현 스펙 문서**

각 P1/P2 항목에 대해 **1페이지 구현 스펙**을 작성합니다:

```
/memory/specs/adk-impl-spec-{항목번호}.md

내용:
1. 목표 (1줄)
2. 수정 파일 목록
3. 핵심 로직 (pseudo-code)
4. feature_flag 이름
5. 단위 테스트 목록
6. DoD 체크리스트
7. 참조: 이 미팅 문서의 해당 섹션 경로
```

task 파일에는 이 스펙 문서 경로만 참조합니다. 에이전트는 스펙 문서를 읽고 구현합니다.

**DRI 리뷰 메커니즘**: DRI 에이전트가 구현 결과를 QC하는 것은 기존 MoAI의 QC 파이프라인으로 처리합니다. "DRI 리뷰"는 코드 리뷰가 아니라 "스펙 대비 구현 일치성 확인"이며, 이것은 qc_verify.py의 검증 항목으로 추가 가능합니다.

**스펙 문서 작성 DRI:**

| 항목 | 스펙 작성 DRI | 작성 시기 |
|---|---|---|
| P1-1 Progressive Disclosure | 헤르메스 | Week 0 Phase 0b |
| P1-2 읽기/쓰기 격리 | 헤르메스 | Week 0 Phase 0b |
| P1-7 hooks | 헤르메스 | Week 1 |
| P2-3 haiku A/B | 마아트 | Week 2 |
| P2-4 TRUST 5 | 마아트 | Week 2 |
| P2-5 MODEL_MAP | 헤르메스 | Week 3 |

---

**만장일치 투표 전 최종 확인:**

| 쟁점 | Cycle 9-10 결론 |
|---|---|
| feature_flags.json | 스키마 확정, atomic write, mtime 캐시, 안전 기본값 False |
| circuit breaker | (tool, error_code, file_path) 3-튜플 |
| A/B 통계 | Fisher's exact, α=0.05, n>150 |
| 기준선 저장 | .metrics/ 디렉토리, JSON, _접두사 메타키 |
| 토큰 버짓 | summary≤600 (15-25%), standard≤1800 (40-60%), CRITICAL ~80토큰 |
| contingency | 독립 실패/롤백, 전부 실패 시 스코프 축소 회의 |
| 기준선 SPOF | Week 0을 Phase 0a(측정)/0b(구현)으로 분리 |
| 버퍼 | P2-5 이동, Week 2 금 리뷰 버퍼 |
| 에이전트 실행성 | 항목별 1-page 구현 스펙 문서 작성 |

---

## 3 Whys 검증

### 로키 최종 공격 대응
**Why 1**: 왜 기준선 측정을 코드 변경과 분리하는가? -> 기준선은 "변경 전 상태"의 스냅샷. 변경 중에 측정하면 과도기 데이터가 되어 비교 기준으로 무효
**Why 2**: 왜 8주를 유지하고 10주로 확장하지 않는가? -> 기간 연장은 집중력 저하와 스코프 크리프 위험. 내부 재배치(P2-5 이동, 버퍼 삽입)로 같은 효과 달성
**Why 3**: 왜 구현 스펙 문서가 필요한가? -> 10사이클 합의 내용이 방대하여 에이전트가 미팅 문서 전체를 처리할 수 없음. 1-page 요약으로 핵심 스펙만 전달

### 최종 계획 검증
**Why 1**: 이 계획이 왜 성공할 수 있는가? -> 6개 항목 모두에 킬 스위치, 독립 롤백, DoD, 데드라인, contingency가 있어 실패해도 복구 가능
**Why 2**: 왜 이 우선순위 순서인가? -> P1은 일상 운영에 즉시 영향(토큰 절감, 안전성), P2는 품질 개선(QC 강화), P3/P4는 장기 구조 개선. 영향 범위 x 긴급도 순
**Why 3**: 왜 전원 합의가 필요한가? -> 각 에이전트가 자기 담당 영역에서 이 계획을 실행해야 하므로, 이해 + 동의가 없으면 실행 단계에서 불일치 발생

---

## 만장일치 투표

### 투표 결과

**헤르메스**: **찬성**
> 기술적으로 실행 가능합니다. feature_flags.json 인프라가 Week 0에 완성되면 모든 항목의 킬 스위치가 확보됩니다. dispatch.py/team_prompts.py 핫스팟 충돌은 그룹 순차 실행으로 관리 가능합니다. 로키의 atomic write 지적, circuit breaker 3-튜플 확장은 구현 품질을 높여줄 합리적 개선입니다.

**오딘**: **찬성**
> 워크플로우 변경이 기존 구조를 파괴하지 않습니다. DIRECT-WORKFLOW.md 섹션 추가는 기존 섹션 무변경을 보장하고, feature_flags로 킬 스위치가 있어 문제 시 즉시 원복 가능합니다. Week 0의 Phase 0a/0b 분리로 기준선 무결성이 확보된 점이 마지막 우려를 해소했습니다.

**마아트**: **찬성**
> 품질 게이트가 충분합니다. 단위/통합/회귀 3계층 테스트, Fisher's exact A/B 검정, 효과 측정 비교 체계가 구비되었습니다. sonnet FNR 기준선 추가(로키 제안)로 A/B 검정의 입력 데이터 신뢰성도 확보했습니다. DoD 체크리스트 + 데드라인 + 축소안이 있어 "영원히 미완" 위험도 관리됩니다.

**로키**: **찬성 (조건부)**
> 3가지 최약 고리를 지적했고, 3가지 모두 대응안이 수용되었습니다. 기준선 Phase 분리, 버퍼 삽입, 구현 스펙 문서 작성이 반영되었으므로 찬성합니다. **단, 조건**: (1) Phase 0a code freeze가 실제로 지켜지지 않으면 기준선이 무효화되므로, code freeze 위반 시 즉시 기준선 재측정을 트리거해야 합니다. (2) 구현 스펙 문서가 "형식적 문서"가 되지 않도록 스펙 대비 구현 차이가 20%를 초과하면 재설계를 강제하는 규칙이 필요합니다. 이 두 조건은 구현 단계에서 확인 가능하므로 현재 합의를 막지 않습니다.

**프로메테우스**: **찬성**
> 10사이클의 논의로 기술적 설계, 테스트 전략, 위험 관리, 롤백 계획, 통계 검정, 팀 배정, contingency가 모두 확정되었습니다. 로키의 최종 공격이 계획의 실질적 보강으로 이어진 것이 이 미팅 프로세스의 가치를 증명합니다. 실행 단계로 이행할 준비가 완료되었습니다.

### 투표 결과: **만장일치 찬성 (5/5)**
- 로키의 조건부 찬성 2가지 조건은 구현 단계에서 적용

---

## 최종 합의문

### 10개 항목별 최종 결정

| # | 항목 | 우선순위 | 담당(DRI) | 구현 방식 | Week |
|---|---|---|---|---|---|
| 1 | Progressive Disclosure | P1 | 헤르메스 | build_prompt() disclosure_phase 3단계(summary/standard/full). CRITICAL 셋 ~80토큰 하드코딩. 비율 검증(15-25%/40-60%/100%) | 1-2 |
| 2 | 읽기/쓰기 격리 | P1 | 헤르메스 | dispatch.py --agent-type(read/write) + worktree_manager.py --read-only. 기본값 "write". WORKFLOW 섹션 5 추가 | 1-2 |
| 3 | haiku 전용화 | P2 | 마아트 | Fisher's exact test A/B, α=0.05, n>150, FNR<15%. 4주+최대1주 연장. 주1회 sonnet 재검증 20% | 4-8 |
| 4 | TRUST 5 태그 | P2 | 마아트 | qc_verify.py trust_summary JSON. verifier 9종→TRUST 5차원 매핑. 매핑 불일치율<3% | 3 |
| 5 | 모델 매핑 테이블 | P2 | 헤르메스 | team_prompts.py MODEL_MAP 상수. _build_cowork_section() 모델 가이드 삽입. staleness 7일 경고 | 4 |
| 6 | @MX 태그 | P4 | 미정 | P1/P2 효과 검증 후 재논의 | 9+ |
| 7 | hooks 자동 강제 | P1 | 헤르메스 | PostToolUse pyright+ruff. 심각도 2단계. circuit breaker(15/30/동일3회). (tool,code,path) 3-튜플 | 3 |
| 8 | Context Search | P4 | 미정 | ADK 네이티브 기능 대기. Google ADK 로드맵 모니터링 | 9+ |
| 9 | Agent Teams API | P4 | 미정 | Google ADK 로드맵 의존. API 안정화 후 재논의 | 9+ |
| 10 | Task 파일 구조 표준화 | P3/P4 | 오딘(P3) | P3: 네이밍 규칙(Week 5-8 설계). P4: 구조 자동 생성(9+) | 5-8/9+ |

### 실행 타임라인 (8주)

```
Week 0 (3/31~4/6):
  Phase 0a (4/1~4/3): 기준선 측정 전용 [CODE FREEZE]
    - DRI: 마아트. 지원: 헤르메스(데이터 추출)
    - 측정: build_prompt 토큰, QC 패스율, QC FNR(30건 재검증),
            QC 실행시간, 세션 Write/Edit 횟수, 토큰 소비량, worktree 성공률
    - 저장: .metrics/baseline/baseline_2026-04-03.json
    - 완료 조건: git tag baseline-v1
  Phase 0b (4/4~4/6): feature_flags.json 구현
    - DRI: 헤르메스
    - 스키마 6플래그, utils/feature_flags.py, atomic write
    - P1-1, P1-2 구현 스펙 문서 작성

Week 1-2 (4/7~4/20):
  그룹A: P1-1 Progressive Disclosure + P1-2 읽기/쓰기 격리
    - DRI: 헤르메스. 지원: 오딘(WORKFLOW)
    - 단위 테스트 + 회귀 테스트 동시 진행
    - P1-7 구현 스펙 문서 작성 (Week 1)
    - P2-3, P2-4 스펙 문서 작성 (Week 2, 마아트)
    - 데드라인: Week 2 (4/14). 초과 시 summary 모드 제거 / --read-only 소프트 제한
    - [버퍼: 4/17(금) 리뷰 + 버그 수정 전용일]

Week 3 (4/21~4/27):
  그룹C: P1-7 hooks 자동 강제
    - DRI: 헤르메스. 지원: 마아트(QC 연동)
  P2-4: TRUST 5 태그
    - DRI: 마아트
  P2-5 구현 스펙 문서 작성 (헤르메스)
  데드라인: Week 3 (4/21). hooks 초과 시 pyright만 먼저 배포

Week 4 (4/28~5/4):
  P2-5: MODEL_MAP 구현
    - DRI: 헤르메스
  통합 테스트 INT-01~07 전체 실행
  P1 효과 측정 (기준선 vs 현재)
  P2-3: haiku A/B 테스트 시작
    - DRI: 마아트. 지원: 헤르메스(분기 구현)
  [버퍼: INT 테스트 실패 시 수정 시간 확보]

Week 5-7 (5/5~5/25):
  A/B 테스트 진행 (주 1회 sonnet 재검증)
  P3(Task 파일 표준화) 사전 설계 문서 작성 (DRI: 오딘)
  격주 효과 보고 (DRI: 마아트)
  feature_flags 잔존 플래그 정리

Week 8 (5/26~5/31):
  A/B 테스트 최종 판정 (Fisher's exact test)
  haiku 전용화 채택/기각 결정
  전체 P1/P2 평가 보고서
  P3 실구현 여부 결정
  P4 재논의 트리거 점검
  프로젝트 회고
```

### 핵심 인프라 합의

| 항목 | 결정 |
|---|---|
| feature_flags.json | 6플래그, mtime 캐시, atomic write, 안전 기본값 False, 환경변수 오버라이드 |
| circuit breaker | (tool, error_code, file_path) 3-튜플. warning=15, critical=30, 동일3회=halt |
| A/B 통계 | Fisher's exact test, α=0.05, power≥0.80, n>150 |
| 기준선 저장 | .metrics/ 디렉토리, JSON, _접두사 메타키, 자동 비교 |
| 토큰 버짓 | summary≤600(15-25%), standard≤1800(40-60%), CRITICAL ~80토큰 하드코딩 |
| 롤백 | 3-Layer: (1)flag off (2)설정 원복 (3)git revert. 항목별 독립 롤백 |
| contingency | P1 독립 실패/롤백. 전부 실패 시 2주 보류 + 스코프 축소 회의 |
| 구현 스펙 | 항목별 1-page 스펙 문서 (/memory/specs/adk-impl-spec-{#}.md) |

### 만장일치 투표 결과

| 참석자 | 투표 | 사유 |
|---|---|---|
| 헤르메스 | 찬성 | 기술적으로 실행 가능. feature_flags 킬 스위치 + 독립 롤백으로 리스크 관리 충분 |
| 오딘 | 찬성 | 워크플로우 변경이 기존 구조 비파괴. Phase 0a/0b 분리로 기준선 무결성 확보 |
| 마아트 | 찬성 | 단위/통합/회귀 3계층 테스트 + Fisher's A/B + 효과 측정 비교 체계 구비. DoD+데드라인+축소안으로 미완 방지 |
| 로키 | 찬성 (조건부) | 3가지 최약 고리 지적에 대한 대응 수용. 조건: (1)code freeze 위반 시 기준선 재측정 (2)스펙 대비 구현 차이 20% 초과 시 재설계 강제 |
| 프로메테우스 | 찬성 | 10사이클 완주. 설계/테스트/위험/롤백/통계/배정/contingency 전부 확정. 실행 단계 이행 준비 완료 |

**최종 결과: 만장일치 찬성 (5/5). MoAI-ADK 도입 계획 확정.**