# task-1285.1 미팅 Cycle 2
날짜: 2026-03-31
안건: P1 3건 심층 논의 (Cycle 1 합의 반영: 1.Progressive Disclosure, 2.읽기/쓰기 격리, 7.hooks 자동 강제)

---

## 참석자 발언

### P1-1: Progressive Disclosure 스킬 로딩

---

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

**1. 구체적 구현 방법**

현재 스킬 로딩 경로를 분석하면 두 가지 영역이 있다:

**(A) Claude Code 자체 스킬 (system-reminder로 주입)**
- 이 부분은 Claude Code 하네스가 `~/.claude/settings.json`의 스킬 설정을 읽어 system-reminder에 주입한다.
- 우리가 직접 제어할 수 있는 부분: 각 스킬의 description 필드를 축약하는 것. 현재 각 스킬 설명이 3-5줄인데, 이를 1줄 트리거 조건으로 축약하면 토큰 절감 가능.
- 스킬 파일 자체를 수정: 각 `.md` 스킬 파일의 frontmatter에 `triggers:` 키워드 리스트만 남기고, 본문은 Skill tool 호출 시에만 로드되도록 설계.

**(B) team_prompts.py에서 주입하는 커스텀 컨텍스트**
- `build_prompt()` 함수에서 팀별 프롬프트를 생성할 때, 스킬 관련 컨텍스트를 동적으로 제어 가능.
- 구현: `build_prompt()`에 `skill_level` 파라미터를 추가하여 Level 1(frontmatter only) / Level 2(full) 전환.

**수정 대상 파일:**
- 각 스킬 `.md` 파일의 description 필드 축약 (80+ 파일)
- `prompts/team_prompts.py` — `build_prompt()` 함수에 `skill_level` 파라미터 추가
- `~/.claude/settings.json` — 스킬 등록 방식 검토

**2. 파일 충돌 가능성**
- team_prompts.py는 dispatch.py, chain_manager.py에서 import한다. `build_prompt()` 시그니처 변경 시 호출부 전부 수정 필요.
- 스킬 .md 파일 수정은 독립적이라 충돌 가능성 낮음.
- settings.json 변경은 전체 Claude Code 환경에 영향.

**3. 테스트 방법**
- Before/After 토큰 카운트 비교: 동일 작업을 Level 1과 현재 방식으로 실행하여 system-reminder 토큰 수 측정.
- 스킬 발견율 테스트: 10개 대표 시나리오에서 올바른 스킬이 트리거되는지 확인.
- 회귀 테스트: 기존 워크플로우(dispatch → team → QC)가 정상 동작하는지 end-to-end 확인.

**4. 위험 요소 + 롤백 방법**
- 위험: 스킬 트리거 미스. 축약된 description으로 매칭이 안 되는 경우.
- 롤백: 스킬 .md 파일은 git으로 관리되므로 `git revert`로 즉시 원복. team_prompts.py의 `skill_level` 파라미터에 기본값을 "full"로 설정하면 변경 없이 기존 동작 유지.

---

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

**1. 구체적 구현 방법**

워크플로우 관점에서 3단계 점진적 도입을 제안한다:

**Phase A (즉시):** 스킬 description 축약
- 80+ 스킬의 description을 현재 3-5줄에서 1줄 트리거 조건으로 축약.
- "Use when:" 키워드 리스트만 남기고, 상세 설명은 스킬 본문으로 이동.
- 이것만으로도 system-reminder 토큰을 40-50% 줄일 수 있다.

**Phase B (1주 후):** 카테고리별 그룹핑
- 스킬을 카테고리로 분류: marketing(30+), dev(15+), analysis(10+), etc.
- 에이전트 역할에 따라 관련 카테고리만 로드. 예: dev1-team에는 dev 카테고리만.

**Phase C (2주 후):** 온디맨드 로딩
- Level 1 frontmatter만 기본 로드, Skill tool 호출 시 Level 2 본문 동적 로드.
- 이 단계는 Claude Code 하네스의 동작 방식에 대한 추가 조사가 필요.

**2. 파일 충돌 가능성**
- Phase A는 스킬 파일만 수정하므로 충돌 없음.
- Phase B는 team_prompts.py에 skill_category 로직 추가 필요 — dispatch.py 호출부와 조율 필요.

**3. 테스트 방법**
- Phase A 후: 모든 스킬의 트리거 테스트 (10개 대표 시나리오).
- 스킬 발견율이 95% 이상이면 Phase B로 진행.

**4. 위험 요소 + 롤백 방법**
- Phase별로 독립적이므로 각 Phase에서 롤백 가능. Phase B가 실패해도 Phase A 상태로 유지.

---

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

**QC 관련 스킬 보호 조건:**

다음 스킬은 Progressive Disclosure에서 **항상 Level 2(전체 로드)로 유지해야 한다:**
- `verification-before-completion` — .done 파일 검증
- `tdd-enforcement` — TDD 강제
- `systematic-debugging` — 디버깅 프로토콜

이 3개 스킬이 축약되면 QC 프로세스에 구멍이 생긴다. **"QC 스킬 화이트리스트"를 team_prompts.py에 하드코딩해야 한다.**

테스트 방법으로는 축약 전/후 QC 통과율 비교를 제안한다. 동일 코드에 대해 Level 1과 Level 2에서 각각 QC를 실행하여 발견 이슈 수를 비교.

---

#### 로키 (DA)

**이 항목의 핵심 사각지대를 공격한다.**

**공격 1: "축약"의 정의가 모호하다.**
헤르메스는 "1줄 트리거 조건"이라 했고, 오딘은 "Use when: 키워드 리스트"라 했다. 동일한 것 같지만 다르다. 현재 스킬 description을 보면:
```
- seo-audit: When the user wants to audit... Also use when the user mentions "SEO audit," "technical SEO,"...
```
이 description에서 "Use when" 뒤의 키워드만 남기면 20+ 토큰이다. 80개 스킬이면 여전히 1,600+ 토큰. **절감 효과가 기대보다 작을 수 있다.**

**공격 2: 스킬 트리거의 false negative는 측정 불가능하다.**
오딘이 "스킬 발견율 95% 이상이면 Phase B"라고 했다. **95%는 어떻게 측정하는가?** 에이전트가 스킬을 호출하지 않은 경우, 그것이 "적절히 호출하지 않은 것"인지 "스킬이 불필요해서 호출하지 않은 것"인지 구분할 수 없다. **True negative와 false negative를 구분할 방법이 없다.**

**공격 3: Phase C(온디맨드 로딩)는 사실상 불가능할 수 있다.**
Claude Code의 system-reminder는 대화 시작 시 한 번 주입된다. 대화 중간에 "추가 스킬을 로드"하는 메커니즘이 Claude Code에 존재하는가? Skill tool은 이미 등록된 스킬을 호출하는 것이지, 미등록 스킬을 동적으로 등록하는 것이 아니다. **Phase C는 기술적 실현 가능성을 검증하지 않은 상태에서 로드맵에 넣으면 안 된다.**

**결론: Phase A만 P1으로 진행. Phase B/C는 Phase A의 효과 측정 후 별도 판단.**

---

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

로키의 지적을 수용하여 **구현 범위를 Phase A로 한정하는 것에 동의한다.** Phase A의 성공 기준을 정량적으로 정의한다:

| 지표 | 현재 | 목표 | 측정 방법 |
|------|------|------|-----------|
| system-reminder 스킬 토큰 | 측정 필요 | 50% 감소 | tiktoken으로 before/after 비교 |
| 스킬 트리거 정확도 | 기준선 측정 필요 | 90%+ 유지 | 10개 표준 시나리오 테스트 |
| 작업 완료 시간 | 기준선 측정 필요 | 변화 없음 또는 개선 | 동일 작업 5건 비교 |

Phase A 완료 후 2주간 모니터링하고, 성공 기준을 충족하면 Phase B를 P2로 진행.

---

### P1-2: 읽기/쓰기 에이전트 격리 분리

---

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

**1. 구체적 구현 방법**

**수정 대상 파일: `dispatch.py`**

현재 dispatch.py의 실행 흐름:
1. `--team` 파라미터로 팀 지정
2. `build_prompt()`로 프롬프트 생성
3. worktree_manager.py의 `create` 호출로 worktree 생성
4. `cokacdir --cron`으로 에이전트 세션 시작

변경 사항:
- dispatch.py에 `--agent-type` 파라미터 추가: `read` (리서치) / `write` (코딩) / `auto` (자동 판별)
- `auto` 모드: task 내용을 분석하여 키워드 기반 분류 ("분석", "조사", "리서치", "검토" → read / "구현", "수정", "생성", "추가" → write)
- `read` 타입: worktree 생성 스킵. permissionMode:plan으로 실행.
- `write` 타입: 현재와 동일하게 worktree 생성.

**수정 대상 파일: `scripts/worktree_manager.py`**
- 직접 수정 불필요. dispatch.py에서 조건부 호출만 하면 됨.

**수정 대상 파일: `prompts/team_prompts.py`**
- `build_prompt()`에 `agent_type` 파라미터 추가.
- `read` 타입일 때 프롬프트에 "파일 수정 금지. 분석/보고서 작성만 수행." 지시 추가.

**수정 대상 파일: `prompts/DIRECT-WORKFLOW.md`**
- 읽기/쓰기 에이전트 구분 가이드 섹션 추가.

**2. 파일 충돌 가능성**
- dispatch.py: 가장 빈번하게 수정되는 파일. 다른 작업과 충돌 가능성 **높음**.
- team_prompts.py: build_prompt() 시그니처 변경이 P1-1(Progressive Disclosure)과 겹침. **동시 수정 시 충돌 확실.**
- 해결: P1-1과 P1-2를 **동일 브랜치에서 순차 구현.** team_prompts.py의 build_prompt()를 한 번에 설계.

**3. 테스트 방법**
- 리서치 작업(예: "코드 분석 보고서 작성")을 `--agent-type read`로 실행: worktree가 생성되지 않는지 확인.
- 코딩 작업(예: "버그 수정")을 `--agent-type write`로 실행: worktree가 정상 생성되는지 확인.
- 리서치 에이전트가 파일 쓰기를 시도할 때 차단되는지 확인.
- `auto` 모드의 분류 정확도: 20건의 과거 task를 auto로 분류하여 정확도 확인.

**4. 위험 요소 + 롤백 방법**
- 위험: auto 모드의 오분류. 코딩 작업을 read로 분류하면 worktree 없이 메인 트리에서 작업하게 되어 위험.
- 완화: auto 모드 초기에는 비활성화. 명시적 `--agent-type` 지정만 허용.
- 롤백: `--agent-type` 파라미터의 기본값을 `write`로 설정하면 변경 전과 동일 동작.

---

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

**1. 구체적 구현 방법**

워크플로우 관점에서 에이전트 분류 기준을 명확히 제안한다:

**읽기 에이전트 (permissionMode: plan):**
- 미팅 에이전트 (agent-meeting 스킬)
- 리서치 에이전트 (research-prompt, cross-verified-research)
- 분석 에이전트 (deep-dive-analyzer, adversarial-review)
- 전략 에이전트 (strategy-prompt, swing-mortem)

**쓰기 에이전트 (isolation: worktree):**
- 코딩 에이전트 (백엔드/프론트엔드 구현)
- QC 에이전트 (코드 수정 가능)
- 배포 에이전트 (ship 스킬)

**중간 지대 (판단 필요):**
- 문서 작성 에이전트: memory/ 폴더에 .md 파일을 생성하는 것은 "쓰기"인가? → 제안: memory/ 폴더 쓰기는 worktree 불필요. 코드 디렉토리 쓰기만 worktree 필요.
- 보고서 에이전트: .done 파일 생성은 "쓰기". → worktree 필요.

**2. 파일 충돌 가능성**
- DIRECT-WORKFLOW.md에 에이전트 분류 섹션 추가 시, 다른 워크플로우 업데이트와 충돌 가능.

**3. 테스트 방법**
- 분류 기준 매트릭스를 만들어 팀별로 리뷰.

---

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

**QC 에이전트의 분류에 대한 의견:**

QC 에이전트는 현재 코드를 수정할 수 있으므로 "쓰기"로 분류되어야 한다. 그러나 **QC의 본질은 "검증"이지 "수정"이 아니다.** QC-RULES.md v3.0의 원칙에 따르면, QC 에이전트가 직접 코드를 수정하는 것은 이슈 처리 규칙(1-D)에 해당하는 예외적 경우다.

제안: QC 에이전트를 **"검증 읽기 + 제한적 쓰기"** 모드로 운영. worktree는 생성하되, 수정 범위를 QC-RULES.md에 정의된 범위로 제한.

---

#### 로키 (DA)

**이 항목의 치명적 사각지대를 공격한다.**

**공격 1: "auto 모드"는 시한폭탄이다.**
헤르메스가 "auto 모드 초기에는 비활성화"라고 했지만, **결국 누군가 활성화할 것이다.** 키워드 기반 분류("분석" → read, "수정" → write)는 극히 단순하다. "분석 결과를 바탕으로 코드를 수정하세요"라는 task는 read인가 write인가? "기존 구현을 분석하고 리팩토링하세요"는? **자연어 task의 의도를 키워드로 분류하는 것은 본질적으로 불가능하다.** auto 모드는 아예 구현하지 말고, 항상 명시적 지정을 강제해야 한다.

**공격 2: 읽기 에이전트가 메인 트리에서 실행되는 것의 위험.**
현재 모든 에이전트가 worktree에서 실행되는 이유는 **메인 트리 보호** 때문이다. 읽기 에이전트가 worktree 없이 메인 트리에서 실행되면, permissionMode:plan이 파일 쓰기를 차단하더라도 **git 상태를 오염시킬 수 있는가?** 예를 들어, 에이전트가 `git status`, `git log`를 실행하는 것은 읽기이지만, `git stash`나 `git checkout`은? permissionMode:plan이 모든 부작용을 차단하는지 검증이 필요하다.

**공격 3: 오딘의 "중간 지대" 분류가 복잡성을 키운다.**
"memory/ 폴더 쓰기는 worktree 불필요, 코드 디렉토리 쓰기만 worktree 필요"라고 했다. **디렉토리 기반 권한 분리는 유닉스 파일 시스템에서는 자연스럽지만, Claude Code 에이전트 수준에서 강제할 수 있는가?** 에이전트에게 "memory/에만 쓰세요"라고 프롬프트로 지시하면, 그것은 **권고**이지 **강제**가 아니다. 강제 메커니즘 없는 분류는 장식에 불과하다.

**결론: auto 모드 제거. 읽기/쓰기 2분법을 strict하게 유지. "중간 지대" 개념을 폐기하고, 의심스러우면 write로 분류.**

---

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

로키의 공격을 수용한 수정 전략:

1. **auto 모드를 로드맵에서 제거.** 항상 명시적 `--agent-type read|write` 지정.
2. **3분류가 아닌 2분류 strict 정책:** read 또는 write만. 중간은 없다.
3. **분류 매트릭스를 DIRECT-WORKFLOW.md에 명시:** 어떤 task 유형이 read이고 어떤 것이 write인지 리스트화.
4. **기본값은 write:** 명시하지 않으면 안전한 쪽(worktree 생성)으로 동작.

구현 우선순위: dispatch.py의 `--agent-type` 파라미터 추가가 핵심. 나머지는 문서 작업.

---

### P1-3: Claude Code hooks 자동 강제 (기존 7번)

---

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

**1. 구체적 구현 방법**

**수정 대상 파일: `~/.claude/settings.json` (또는 프로젝트별 `.claude/settings.json`)**

Claude Code hooks 설정 추가:
```json
{
  "hooks": {
    "PostToolUse": [
      {
        "matcher": "Write|Edit",
        "command": "pyright --outputjson {file} 2>/dev/null | python3 scripts/hooks/parse_pyright.py",
        "timeout": 15000
      },
      {
        "matcher": "Write|Edit",
        "command": "ruff check {file} --output-format json 2>/dev/null | python3 scripts/hooks/parse_ruff.py",
        "timeout": 10000
      }
    ]
  }
}
```

**신규 파일 생성: `scripts/hooks/parse_pyright.py`**
- pyright JSON 출력을 파싱하여 에이전트가 이해할 수 있는 간결한 에러 메시지로 변환.
- 에러 심각도별 필터링: error만 보고, warning/info는 무시 (초기 단계).

**신규 파일 생성: `scripts/hooks/parse_ruff.py`**
- ruff JSON 출력을 파싱하여 에이전트 피드백 형식으로 변환.
- auto-fixable 에러는 `ruff check --fix`로 자동 수정 후 결과만 보고.

**수정 대상 파일: `prompts/DIRECT-WORKFLOW.md`**
- hooks 동작 설명 섹션 추가. 에이전트가 훅 에러를 받았을 때의 행동 가이드.

**2. 파일 충돌 가능성**
- settings.json: 다른 설정 변경과 충돌 가능. 하지만 hooks 필드는 새로 추가하는 것이므로 기존 설정과 겹치지 않음.
- scripts/hooks/: 새 디렉토리이므로 충돌 없음.
- DIRECT-WORKFLOW.md: P1-2와 동시 수정 시 충돌 가능. → 같은 브랜치에서 순차 수정.

**3. 테스트 방법**
- 의도적으로 타입 에러가 있는 코드를 Write tool로 작성 → hooks가 에러를 캐치하는지 확인.
- 의도적으로 ruff 위반이 있는 코드를 Edit tool로 수정 → hooks가 경고를 생성하는지 확인.
- hooks 타임아웃 테스트: 대형 파일(1000줄+)에서 pyright가 15초 내에 완료되는지 확인.
- 정상 코드에 대해 hooks가 불필요한 경고를 생성하지 않는지 확인 (false positive 테스트).

**4. 위험 요소 + 롤백 방법**
- 위험: hooks 실행 지연으로 에이전트 응답 속도 저하. pyright가 대형 프로젝트에서 10초+ 걸리는 경우.
- 위험: hooks 에러 시 에이전트 무한 수정 루프. 에러 → 수정 시도 → 새 에러 → 수정 시도 → ...
- 완화: **최대 재시도 3회 제한.** 3회 연속 hooks 에러 시 에이전트에게 "hooks 에러를 무시하고 진행. QC 단계에서 처리" 지시.
- 롤백: settings.json에서 hooks 섹션을 제거하면 즉시 원복.

---

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

**1. 구체적 구현 방법**

워크플로우 관점에서 hooks를 에이전트 타입별로 차등 적용해야 한다:

- **쓰기 에이전트(코딩):** pyright + ruff 전부 적용.
- **읽기 에이전트(리서치):** hooks 불필요 (코드 수정을 안 하므로).
- **QC 에이전트:** 자체 검증 도구가 있으므로 hooks 중복 적용 불필요.

이를 위해 `--agent-type`에 따라 hooks 프로파일을 전환하는 메커니즘이 필요하다. 프로젝트별 `.claude/settings.json`을 에이전트 타입별로 분리하거나, hooks command 내부에서 에이전트 타입을 확인하는 로직을 추가.

**2. 의존성 주의:** P1-2(읽기/쓰기 격리)가 완료되어야 hooks의 타입별 적용이 가능하다. P1-2를 먼저 구현할 것을 제안.

---

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

**hooks가 QC에 미치는 영향 분석:**

긍정적 영향:
- 현재 QC 단계에서 잡는 에러의 60%+(린트/타입)를 코딩 단계에서 미리 잡으면, QC는 **로직 검증에 집중**할 수 있다.
- QC 반복 횟수 감소 → 비용 절감 + 시간 단축.

부정적 영향:
- hooks가 자동 수정(`ruff check --fix`)을 하면, 에이전트가 "수정된 것을 인지하지 못하는" 상황 발생 가능. 에이전트가 자기가 쓴 코드와 hooks가 수정한 코드의 차이를 모르면 혼란.
- 제안: **auto-fix는 초기에 비활성화.** 에러만 보고하고 에이전트가 직접 수정하도록. auto-fix는 2주 후 안정화 확인 후 활성화.

**QC 규칙 업데이트 필요:** QC-RULES.md에 "hooks가 통과한 코드도 QC 대상"임을 명시해야 한다. hooks ≠ QC 면제.

---

#### 로키 (DA)

**이 항목의 숨겨진 위험을 공격한다.**

**공격 1: 무한 수정 루프는 "최대 3회"로 해결되지 않는다.**
헤르메스가 "3회 실패 후 무시하고 진행"이라고 했다. **3회째에 에이전트가 코드를 크게 변경하여 원래 기능이 망가진 상태로 "무시하고 진행"하면?** 문제는 재시도 횟수가 아니라, **각 재시도에서 에이전트가 무엇을 변경하는지에 대한 제어가 없다는 것이다.** 에이전트는 pyright 에러를 없애기 위해 타입 힌트를 `Any`로 바꾸거나, 함수를 통째로 삭제할 수 있다. hooks가 "문법적으로 정확한 나쁜 코드"를 유도하는 역설적 상황.

**공격 2: pyright 타임아웃이 에이전트 경험을 파괴한다.**
pyright가 15초 타임아웃에 걸리면 에이전트는 15초 동안 아무것도 못 한다. 매 Write/Edit마다 15초씩 대기하면, 10회 수정 작업에서 2.5분이 추가된다. **사용자 체감으로는 "느려졌다"가 된다.** 비용은 줄었는데 속도가 느려지면 네트 효과가 마이너스일 수 있다.

**공격 3: hooks의 범위 크립(scope creep).**
오늘은 pyright + ruff. 내일은 "pytest도 추가하자", "보안 스캔도 추가하자", "커버리지 체크도 추가하자". hooks에 검증을 계속 추가하면 **매 코드 수정이 CI/CD 파이프라인을 돌리는 것과 같아진다.** hooks는 가벼운 검증만 해야 한다. 범위 확대 방지 규칙이 필요하다.

**공격 4: ruff auto-fix의 위험.**
마아트가 "auto-fix 초기 비활성화"를 제안했는데, **영원히 비활성화하는 것이 맞다.** 에이전트 모르게 코드가 변경되는 것은 원칙적으로 위험하다. 에이전트는 자기가 작성한 코드의 상태를 정확히 알아야 올바른 판단을 할 수 있다.

**결론:**
1. hooks는 pyright + ruff **보고만** (auto-fix 영구 비활성화)
2. hooks 실패 시 에이전트 행동: 원래 코드를 보존한 채 에러를 보고. 수정 시도 자체를 hooks 단계에서 하지 않음.
3. hooks 범위 확대 방지: pyright + ruff 외에는 별도 승인 필요.
4. 타임아웃을 10초로 축소. 타임아웃 발생 시 "hooks 스킵, QC에서 처리" 로 처리.

---

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

**P1 3건의 구현 순서와 의존성 정리:**

```
P1-2 (읽기/쓰기 격리)
  ↓
P1-3 (hooks 자동 강제)  ← 에이전트 타입별 hooks 분기 필요
  ↓ (병렬 가능)
P1-1 (Progressive Disclosure Phase A)  ← 독립적
```

**권장 구현 순서:**
1. **Week 1:** P1-2 (dispatch.py `--agent-type` 추가) + P1-1 Phase A (스킬 description 축약) 병렬 진행. 단, team_prompts.py는 P1-2 먼저 수정.
2. **Week 2:** P1-3 (hooks 설정 + parse 스크립트). P1-2 완료 후 에이전트 타입별 hooks 분기 적용.
3. **Week 3:** 효과 측정. 토큰 사용량, 작업 완료 시간, QC 반복 횟수 before/after 비교.

**성공 기준:**
| 지표 | 목표 |
|------|------|
| system-reminder 토큰 | 40%+ 감소 |
| 리서치 작업 시작 속도 | 30%+ 단축 (worktree 제거 효과) |
| QC 반복 횟수 | 30%+ 감소 (hooks로 사전 감지) |
| 스킬 트리거 정확도 | 90%+ 유지 |

---

## 3 Whys 검증

### Why 1: "왜 hooks에서 auto-fix를 비활성화해야 하는가?"
- 1차 Why: 에이전트 모르게 코드가 변경되면 혼란을 야기한다.
- 2차 Why: 왜 에이전트가 코드 변경을 인지해야 하는가? → 에이전트는 자기가 작성한 코드의 상태를 기반으로 다음 행동을 결정한다. 코드가 몰래 바뀌면 판단 근거가 틀어진다.
- 3차 Why: 왜 판단 근거가 틀어지면 문제인가? → 에이전트가 "이미 수정된 에러"를 다시 수정하려 하거나, "auto-fix가 변경한 코드"를 자기 코드로 착각하여 잘못된 보고서를 작성한다. 최악의 경우 auto-fix가 의도를 변경한 코드를 "정상"으로 판단하고 QC를 통과시킨다.
- **결론: auto-fix 영구 비활성화 합의.**

### Why 2: "왜 읽기/쓰기 분류에서 auto 모드를 제거해야 하는가?"
- 1차 Why: 자연어 task의 의도를 키워드로 정확히 분류할 수 없다.
- 2차 Why: 왜 분류 오류가 위험한가? → 코딩 작업을 read로 오분류하면 worktree 없이 메인 트리에서 실행되어 코드 오염 가능.
- 3차 Why: 메인 트리 오염은 왜 심각한가? → 다른 에이전트가 동시에 메인 트리를 참조하므로, 한 에이전트의 불완전한 수정이 다른 에이전트의 작업에 전파된다. 멀티봇 환경에서 메인 트리 오염은 연쇄 실패를 유발한다.
- **결론: auto 모드 제거 합의. 명시적 지정만 허용.**

### Why 3: "왜 Progressive Disclosure를 Phase A로 한정하는가?"
- 1차 Why: Phase C(온디맨드 로딩)의 기술적 실현 가능성이 검증되지 않았다.
- 2차 Why: 왜 검증하지 않았는가? → Claude Code의 system-reminder 동적 주입 메커니즘이 문서화되어 있지 않아 내부 동작을 정확히 파악하지 못했다.
- 3차 Why: 왜 내부 동작 파악이 중요한가? → 실현 불가능한 목표를 로드맵에 넣으면 팀 리소스를 낭비하고, 실패 시 전체 Progressive Disclosure 프로젝트에 대한 신뢰가 하락한다.
- **결론: Phase A만 P1. Phase B/C는 Phase A 효과 측정 후 별도 의사결정.**

---

## 합의 사항

### P1-1: Progressive Disclosure
1. **Phase A만 P1으로 진행.** 80+ 스킬의 description을 1줄 트리거 조건으로 축약.
2. **QC 스킬 화이트리스트 적용.** verification-before-completion, tdd-enforcement, systematic-debugging은 항상 Level 2 유지.
3. **효과 측정:** tiktoken으로 before/after 토큰 비교. 목표 40%+ 감소.
4. **Phase B/C는 Phase A 완료 후 2주 모니터링 후 별도 판단.**

### P1-2: 읽기/쓰기 에이전트 격리
1. **dispatch.py에 `--agent-type read|write` 파라미터 추가.** 기본값은 `write`.
2. **auto 모드는 구현하지 않는다.** 명시적 지정만 허용.
3. **2분류 strict 정책.** 중간 지대 없음. 의심스러우면 write.
4. **분류 매트릭스를 DIRECT-WORKFLOW.md에 명시.**

### P1-3: Claude Code hooks 자동 강제
1. **PostToolUse hooks로 pyright + ruff 자동 실행.** Write/Edit tool 사용 후 트리거.
2. **auto-fix 영구 비활성화.** 에러 보고만. 에이전트가 직접 수정.
3. **타임아웃 10초.** 타임아웃 시 hooks 스킵, QC에서 처리.
4. **최대 재시도 3회.** 3회 실패 후 에러 보고 첨부하여 QC 에스컬레이션.
5. **hooks 범위 확대 방지:** pyright + ruff 외 추가는 별도 승인 필요.
6. **ruff auto-fix는 영구 비활성화.** 에이전트 코드 상태 인지 보장.

### 구현 순서
1. Week 1: P1-2 + P1-1(Phase A) 병렬. team_prompts.py는 P1-2 선행.
2. Week 2: P1-3. 에이전트 타입별 hooks 분기 적용.
3. Week 3: 효과 측정 및 모니터링.

---

## 미해결 이슈

1. **team_prompts.py `build_prompt()` 시그니처 설계:** P1-1(`skill_level`)과 P1-2(`agent_type`) 파라미터를 한 번에 설계해야 한다. 담당: 헤르메스. 기한: Week 1 착수 전.
2. **hooks 실패 시 에이전트 행동 상세 프로토콜:** "3회 실패 후 QC 에스컬레이션"의 구체적 메커니즘(에러 로그 어디에 저장? QC 에이전트에 어떻게 전달?). 담당: 마아트 + 헤르메스 협의.
3. **permissionMode:plan의 정확한 제한 범위:** 읽기 에이전트가 메인 트리에서 실행될 때, git 명령(stash, checkout 등)이 차단되는지 기술 검증 필요. 담당: 헤르메스.
4. **스킬 description 축약 표준 템플릿:** 80+ 스킬의 description을 일관되게 축약하려면 템플릿이 필요하다. 담당: 오딘.
5. **효과 측정 기준선(baseline) 수집:** 현재 시스템의 토큰 사용량, 작업 완료 시간, QC 반복 횟수를 측정해야 한다. P1 구현 전에 수집 완료해야 함. 담당: 프로메테우스.
6. **hooks parse 스크립트(parse_pyright.py, parse_ruff.py)의 출력 형식:** 에이전트가 이해하기 쉬운 표준 출력 형식을 정해야 한다. 담당: 헤르메스.