# task-1285.1 미팅 Cycle 4
날짜: 2026-03-31
안건: P1 구현 세부 확정 + Cycle 1-2 미해결 이슈 해소 (build_prompt 시그니처, permissionMode:plan git 차단, hooks 실패 에스컬레이션, 효과 측정 기준선)

## 참석자 발언

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

**1. build_prompt() 시그니처 통합:**

현재 build_prompt() 시그니처:
```python
def build_prompt(
    team_id: str, task_id: str, task_desc: str,
    level: str = "normal", project_id: Optional[str] = None,
    chain_id: Optional[str] = None, task_type: str = "coding",
) -> str:
```

Progressive Disclosure Phase A를 위해 필요한 변경:

```python
def build_prompt(
    team_id: str, task_id: str, task_desc: str,
    level: str = "normal", project_id: Optional[str] = None,
    chain_id: Optional[str] = None, task_type: str = "coding",
    disclosure_phase: str = "full",  # NEW: "summary" | "standard" | "full"
) -> str:
```

`disclosure_phase` 파라미터의 동작:
- `"summary"`: 작업 지시 + 워크플로우 경로 + 한 줄 TRUST 요약만 전달 (토큰 ~500). Phase A의 기본값.
- `"standard"`: summary + 팀원 코워크 섹션 + 모델 가이드 (토큰 ~1,500). 대부분의 작업.
- `"full"`: 현재와 동일, 모든 섹션 포함 (토큰 ~3,000+). 하위호환 보장.

구현 방법: 기존 `_build_direct_prompt()`, `_build_cowork_section()` 등 내부 함수에 disclosure_phase를 전달하고, 각 함수 내부에서 조건부로 섹션을 생략합니다.

```python
def _build_direct_prompt(team, team_id, task_id, ..., disclosure_phase="full"):
    base = (
        f"당신은 {team['leader']}, {team['role']}입니다.\n\n"
        f"## 작업 지시\n"
        f"- 작업 ID: {task_id}\n"
        f"- 작업 상세는 {task_file_path}를 읽고 파악하세요.\n\n"
    )
    if disclosure_phase == "summary":
        base += f"## 워크플로우\n{WORKSPACE_ROOT}/prompts/DIRECT-WORKFLOW.md 참조.\n"
        return base
    # standard 이상이면 기존 섹션 포함
    base += f"{project_map_section}"
    base += f"## 팀원 구성\n{team['members']}\n\n"
    # ... full이면 추가 상세
    return base
```

**호출부 변경점:** dispatch.py에서 build_prompt() 호출 시 disclosure_phase를 전달해야 합니다. dispatch.py에서 작업 레벨에 따라 자동 결정하는 로직 추가:

```python
# dispatch.py (예시)
disclosure = "summary" if task_level == "Lv.1" else "standard"
prompt = build_prompt(team_id, task_id, task_desc, disclosure_phase=disclosure)
```

**하위호환:** `disclosure_phase="full"`이 기본값이므로 기존 호출부는 변경 불필요.

**테스트:** 기존 `tests/test_team_prompts.py`에 disclosure_phase별 프롬프트 길이 비교 테스트 추가.

**2. permissionMode:plan git 차단 범위:**

`.claude/settings.json`의 `permissionMode: "plan"` 모드에서 차단해야 하는 git 명령:

**차단 (Deny) 목록:**
| 명령 | 사유 |
|---|---|
| `git push` | 원격 저장소 변경 |
| `git push --force` | 원격 저장소 파괴적 변경 |
| `git merge` | 브랜치 통합 (아누 승인 필요) |
| `git rebase` | 커밋 히스토리 변경 |
| `git reset --hard` | 작업 내용 파괴 |
| `git checkout -- .` | 변경사항 전체 취소 |
| `git clean -fd` | 추적 안 되는 파일 삭제 |
| `git branch -D` | 브랜치 강제 삭제 |
| `git stash drop` | stash 항목 삭제 |
| `git tag -d` | 태그 삭제 |

**허용 (Allow) 목록:**
| 명령 | 사유 |
|---|---|
| `git status` | 읽기 전용 |
| `git diff` | 읽기 전용 |
| `git log` | 읽기 전용 |
| `git add` | 스테이징 (되돌릴 수 있음) |
| `git commit` | 로컬 커밋 (push 없이는 안전) |
| `git branch` (생성) | 브랜치 생성 (비파괴적) |
| `git checkout -b` | 새 브랜치 생성 + 전환 |
| `git stash` | 임시 저장 (비파괴적) |
| `git stash pop` | 임시 저장 복원 |
| `git worktree add` | 워크트리 생성 (비파괴적) |

**settings.json 구성 예시:**
```json
{
  "permissions": {
    "deny": [
      "Bash(git push*)",
      "Bash(git merge*)",
      "Bash(git rebase*)",
      "Bash(git reset --hard*)",
      "Bash(git checkout -- *)",
      "Bash(git clean*)",
      "Bash(git branch -D*)",
      "Bash(git stash drop*)",
      "Bash(git tag -d*)"
    ]
  }
}
```

**3. hooks 실패 에스컬레이션:**

PostToolUse 훅 실패 시 작업 흐름 제안:

```
PostToolUse hook 실행
  |
  +-- PASS --> 정상 계속
  |
  +-- FAIL --> 재시도 (최대 2회)
       |
       +-- 재시도 PASS --> 정상 계속
       |
       +-- 재시도 FAIL (2회 소진)
            |
            +-- hooks.log에 FAIL 기록
            +-- 팀장에게 경고 메시지 출력
            +-- 작업 계속 (hook 비활성 상태)
            +-- 보고서에 "hook FAIL" 섹션 추가 의무
            +-- .done 파일에 hook_failures 필드 추가
```

구현: `.claude/settings.json`의 hooks 설정에 `onFailure` 속성 추가.
```json
{
  "hooks": {
    "PostToolUse": [
      {
        "command": "python3 /home/jay/workspace/scripts/post-tool-hook.py",
        "onFailure": "warn-and-continue",
        "maxRetries": 2,
        "logPath": "/home/jay/workspace/memory/logs/hooks.log"
      }
    ]
  }
}
```

주의: hooks의 `onFailure` 속성은 Claude Code ADK 스펙에서 지원 여부 확인 필요. 미지원 시 hook 스크립트 내부에서 try/except로 처리하고 exit code 0을 반환하되, 별도 로그 파일에 기록하는 방식으로 대체.

---

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

**1. build_prompt() 시그니처 -- 프론트 팀 관점:**

disclosure_phase가 마케팅/디자인/출판 팀에도 적용되어야 합니다. 현재 team_prompts.py에는 `_build_marketing_prompt()`, `_build_design_prompt()`, `_build_publishing_prompt()` 등 팀 유형별 함수가 있고, 각각 자체적으로 팀원/스킬/워크플로우 섹션을 포함합니다.

모든 _build_*_prompt() 함수에 disclosure_phase를 전달하면 인터페이스가 복잡해집니다. 대안: build_prompt() 내부에서 disclosure_phase에 따라 **후처리로 섹션 제거**.

```python
def build_prompt(..., disclosure_phase="full"):
    # 기존 로직으로 full 프롬프트 생성
    prompt = _build_xxx_prompt(...)

    if disclosure_phase == "summary":
        # "## 작업 지시" 섹션만 추출
        prompt = _extract_section(prompt, "작업 지시") + "\n워크플로우: 해당 WORKFLOW.md 참조.\n"
    elif disclosure_phase == "standard":
        # "## 사용 가능 스킬" 등 상세 섹션 제거
        prompt = _remove_sections(prompt, ["사용 가능 스킬", "횡단조직", "소환 규칙"])

    return prompt
```

이 방식이 각 _build_*_prompt()를 개별 수정하는 것보다 유지보수가 용이합니다.

**2. permissionMode:plan 워크플로우 영향:**

git push 차단 시 DIRECT-WORKFLOW.md의 Step 4.5(Worktree 정리)에서 "체이닝 중간 Phase 자동 머지"가 차단됩니다. `git merge`가 deny 목록에 있기 때문입니다.

해결 방안:
- 체이닝 중간 Phase 머지는 worktree_manager.py가 수행합니다
- worktree_manager.py의 merge 명령을 hooks의 allow-list에 추가하거나
- permissionMode:plan에서 worktree_manager.py 경유 merge만 예외 허용

구체적으로:
```json
{
  "permissions": {
    "deny": ["Bash(git merge*)"],
    "allow": ["Bash(python3 */worktree_manager.py finish * --action merge)"]
  }
}
```

Claude Code의 permission 매칭이 deny보다 allow를 우선하는지 확인 필요.

**3. hooks 실패 시 UI 표시:**

hooks 실패가 발생하면 팀장에게 명확하게 보여야 합니다. 현재 hooks는 stderr로 출력하는데, Claude Code가 이를 팀장에게 전달하는지 불확실합니다.

안전한 방법: hook 스크립트가 실패 시 특정 파일(`/tmp/hook-failure-{task_id}.flag`)을 생성하고, build_prompt()에서 이 파일 존재 여부를 체크하여 프롬프트에 경고 삽입.

단, 이 방식은 프롬프트 생성 시점과 hook 실패 시점의 타이밍 문제가 있습니다. 실시간 반영은 어렵고, 다음 태스크 프롬프트에 "이전 태스크에서 hook 실패 발생" 경고를 넣는 형태가 현실적입니다.

**4. 효과 측정 기준선 -- 대시보드 관점:**

측정 지표를 어디서 수집하고 어디에 저장할지:

| 지표 | 수집 소스 | 저장 위치 |
|---|---|---|
| 토큰 사용량 (모델별) | Claude API 응답 usage 필드 | task-timers.json에 token_usage 필드 추가 |
| QC PASS/FAIL 비율 | qc_verify.py 결과 JSON | memory/logs/qc-results.jsonl |
| 태스크 완료 시간 | task-timer.py start/end | task-timers.json (기존) |
| hook 실패 빈도 | hooks.log | memory/logs/hooks.log |
| TRUST 차원별 FAIL 빈도 | qc_verify.py trust_summary | memory/logs/qc-results.jsonl |
| haiku vs sonnet 비용 비교 | A/B 테스트 로그 | memory/logs/ab-test-haiku-qc.jsonl |

기준선 측정 기간: P1 적용 전 2주 + P1 적용 후 2주 비교.

---

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

**1. build_prompt() 시그니처 변경의 테스트 전략:**

현재 tests/test_team_prompts.py가 존재합니다. disclosure_phase 추가 시 테스트 매트릭스:

| 팀 유형 | disclosure_phase | 검증 항목 |
|---|---|---|
| direct (dev1) | summary | 작업 지시 섹션 존재, 팀원 섹션 부재 |
| direct (dev1) | standard | 작업 지시 + 팀원 존재, 상세 스킬 부재 |
| direct (dev1) | full | 모든 섹션 존재 (하위호환) |
| marketing | summary | 작업 지시만 |
| marketing | full | 기존과 동일 |
| mcp (dev8) | summary | 작업 지시 + MCP tool 참조만 |
| mcp (dev8) | full | 기존과 동일 |

최소 테스트 케이스: 5 팀유형 x 3 phase = 15건.

**2. permissionMode:plan 검증 방법:**

git 차단 규칙의 검증은 **드라이런 테스트**로 수행합니다:

```bash
# 테스트 스크립트 (검증용, 실제 실행 안 함)
for cmd in "git push" "git merge main" "git rebase main" "git reset --hard" "git checkout -- ."; do
    echo "Testing: $cmd"
    # Claude Code permission check 시뮬레이션
    # deny 목록에 매칭되는지 확인
done
```

실제 검증은 별도 sandbox 환경(테스트 git repo)에서 수행. 프로덕션 repo에서 직접 테스트 금지.

**엣지 케이스 검증:**
- `git push origin --delete branch-name` -- push 차단에 포함되는가?
- `git checkout -f` -- `git checkout -- .`과 다른 패턴이지만 파괴적
- `git restore --staged .` -- 스테이징 해제는 허용해야 하지만 패턴 매칭 주의
- piped 명령: `echo "yes" | git merge --no-edit` -- 파이프 사용 시 매칭 우회 가능성

추가 차단 필요:
- `git checkout -f` (강제 checkout)
- `git restore --worktree .` (작업 디렉토리 전체 복원 = 파괴적)

**3. hooks 실패 에스컬레이션 검증:**

hooks onFailure 동작을 검증하려면:
1. 의도적으로 실패하는 테스트 hook 스크립트 작성
2. PostToolUse에 등록
3. 실패 시 로그 기록, 재시도 횟수, 최종 동작(warn-and-continue) 확인

검증 체크리스트:
- [ ] hook 1회 실패 + 재시도 PASS -> 정상 계속, 로그에 "retry success" 기록
- [ ] hook 3회 연속 실패 -> 경고 출력, 작업 계속, 로그에 "max retries exceeded" 기록
- [ ] .done 파일에 hook_failures 필드 포함 확인
- [ ] 보고서에 "hook FAIL" 섹션 자동 포함 확인

**4. 효과 측정 기준선 수립:**

기준선 측정 항목과 현재 기대치:

| 지표 | 현재 추정치 (기준선) | P1 적용 후 목표 |
|---|---|---|
| 평균 프롬프트 토큰 수 | ~3,000 토큰/태스크 | ~1,500 토큰 (-50%) |
| QC PASS 비율 | ~75% (1차 시도) | >80% |
| 태스크 평균 완료 시간 | 측정 필요 (task-timers.json 분석) | -15% |
| hook 실패율 | N/A (신규) | <5% |
| git 사고율 (push/merge 실수) | 분기별 2-3건 (체감) | 0건 |

기준선 측정 기간: 2026-04-01 ~ 2026-04-14 (P1 적용 전 2주)
비교 측정 기간: P1 적용 후 2주

---

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

**1. build_prompt() 시그니처에 대한 공격:**

`disclosure_phase="full"` 기본값이라서 하위호환이라고? **거짓말입니다.**

문제 1: 오딘이 제안한 "후처리로 섹션 제거" 방식은 **프롬프트를 먼저 full로 만들고 나서 잘라내는** 것입니다. full 프롬프트 생성에 들어가는 파일 I/O, 문자열 연산, 조건 분기를 다 실행한 뒤에 결과물의 절반을 버립니다. 이것은 "Progressive Disclosure로 토큰 절감"이 아니라 **"생성 후 폐기"** 입니다. 실제 토큰 절감은 되지만 서버 측 연산 비용은 그대로입니다.

해결: 헤르메스 방식(각 _build_*_prompt에 disclosure_phase 전달 + 조건부 생성)이 정직합니다. 오딘 방식의 "후처리 제거"는 우아해 보이지만 비효율적입니다. 다만, 헤르메스 방식은 모든 _build_*_prompt 함수를 수정해야 하므로 변경 범위가 큽니다. 이 트레이드오프를 인지하고 결정해야 합니다.

문제 2: `disclosure_phase`라는 파라미터 이름이 사용자(아누, 디스패처)에게 비직관적입니다. "summary"가 뭘 요약하는 건지, "standard"가 왜 기본이 아닌지 혼란스럽습니다. 차라리 `prompt_detail: Literal["brief", "normal", "verbose"]`가 낫습니다.

**2. permissionMode:plan git 차단에 대한 공격:**

1. **패턴 매칭 우회 취약점**: `Bash(git push*)` 패턴은 `git  push` (스페이스 2개), `GIT_DIR=. git push`, `env git push`로 우회 가능합니다. Claude Code의 permission 매칭 엔진이 정규식인지 glob인지, 환경변수 치환 전인지 후인지에 따라 보안 수준이 달라집니다.

2. **allow vs deny 우선순위 미확인**: 오딘이 제안한 "deny git merge + allow worktree_manager.py 경유 merge" 구성에서, allow가 deny를 오버라이드하는지 확인되지 않았습니다. 만약 deny가 우선이면 worktree_manager.py도 차단되어 체이닝이 깨집니다. 만약 allow가 우선이면 `python3 -c "import os; os.system('git merge')"` 같은 우회가 가능할 수 있습니다.

3. **git restore 누락**: 마아트가 지적한 `git restore --worktree .`뿐 아니라, `git checkout HEAD -- file.py` (특정 파일 복원)도 파괴적일 수 있습니다. 화이트리스트 방식(허용 명령만 지정)이 블랙리스트 방식(차단 명령 지정)보다 안전합니다.

4. **현실적 질문: 누가 이 규칙을 관리하나?** git 명령은 계속 추가됩니다 (git switch, git worktree remove 등). 새 명령이 나올 때마다 deny 목록을 업데이트해야 합니다. **화이트리스트(allow-only) 방식으로 전환**하면 새 명령은 자동 차단됩니다.

**3. hooks 실패 에스컬레이션에 대한 공격:**

1. **"warn-and-continue"는 hooks를 무의미하게 만든다**: hooks의 존재 이유가 "자동 강제"입니다. 실패해도 계속 진행하면 hooks가 아니라 "제안"입니다. Cycle 1-2에서 "hooks 자동 강제를 P1으로 올린" 이유가 강제성 때문이었는데, 실패 시 무시하면 강제가 아닙니다.

2. **재시도 2회의 근거는?** 왜 2회인가요? 1회로 충분할 수도 있고, 3회가 필요할 수도 있습니다. 재시도 횟수를 정할 데이터가 없습니다. hooks가 아직 운영된 적이 없으므로 실패율 자체가 미지수입니다.

3. **"hook 스크립트 내부에서 try/except + exit 0" 대체안은 더 위험**: hook이 내부적으로 실패를 삼키고 exit 0을 반환하면, Claude Code는 hook이 성공했다고 판단합니다. 로그에만 기록된 실패는 아무도 보지 않습니다. **사일런트 페일**의 전형.

**대안 제시**: hooks 실패 시 **작업을 중단하고 에스컬레이션**. 즉 `onFailure: "stop-and-escalate"`. 팀장이 보고서에 hook 실패 사유를 분석한 후 수동으로 재개. 이래야 hooks의 "자동 강제" 의미가 살아납니다.

**4. 효과 측정 기준선에 대한 공격:**

1. **"현재 추정치"는 추정치가 아니라 추측**: "평균 프롬프트 토큰 ~3,000"은 어떤 데이터에서 나왔나요? 측정한 적 없으면 기준선이 아니라 희망사항입니다. P1 적용 전에 **실제 측정**을 먼저 하세요.

2. **"git 사고율 분기별 2-3건"은 체감**: 로그가 없으면 기준선이 아닙니다. git reflog를 파싱하여 실제 reset --hard, force push 횟수를 측정해야 합니다.

3. **비교 기간 2주는 너무 짧음**: 학습 효과(처음엔 어색하지만 적응하면 개선)와 피로 효과(처음엔 좋지만 시간이 지나면 우회)를 모두 포착하려면 최소 4주가 필요합니다.

---

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

**1. build_prompt() 시그니처 -- 전략적 결정:**

두 구현 방식의 트레이드오프:

| | 헤르메스 방식 (조건부 생성) | 오딘 방식 (후처리 제거) |
|---|---|---|
| 효율성 | 높음 (필요한 것만 생성) | 낮음 (생성 후 폐기) |
| 변경 범위 | 큼 (7개 _build_* 함수 수정) | 작음 (build_prompt 1곳) |
| 유지보수 | 각 함수에 분기 추가 | 섹션 제거 로직 집중 관리 |
| 버그 위험 | 함수별 분기 누락 가능 | 섹션 파싱 오류 가능 |

**결정: 2단계 접근**
1. **1차 구현**: 오딘 방식 (후처리 제거). 빠르게 동작 검증.
2. **2차 최적화**: 효과가 입증되면 헤르메스 방식으로 전환. 각 _build_* 함수를 점진적으로 수정.

파라미터 이름: 로키 지적을 수용하여 `prompt_detail: Literal["brief", "normal", "verbose"]`로 변경. "brief"=summary, "normal"=standard, "verbose"=full.

**2. permissionMode:plan -- 화이트리스트 vs 블랙리스트:**

로키의 "화이트리스트 방식" 제안에 동의합니다. 블랙리스트는 새 명령 추가 시 누락 위험이 있습니다.

**화이트리스트 구성:**
```json
{
  "permissions": {
    "allow": [
      "Bash(git status*)",
      "Bash(git diff*)",
      "Bash(git log*)",
      "Bash(git add*)",
      "Bash(git commit*)",
      "Bash(git branch *)",
      "Bash(git checkout -b *)",
      "Bash(git stash)",
      "Bash(git stash pop)",
      "Bash(git worktree add*)",
      "Bash(python3 */worktree_manager.py*)"
    ],
    "deny": [
      "Bash(git *)"
    ]
  }
}
```

이렇게 하면 allow에 없는 모든 git 명령이 deny됩니다. 새 명령(git switch 등)도 자동 차단.

**단, Claude Code의 permission 매칭이 allow-then-deny 순서인지 확인 필요.** 확인 전까지는 블랙리스트로 시작하되, 화이트리스트 전환을 로드맵에 포함합니다.

**3. hooks 실패 에스컬레이션 -- 전략적 타협:**

로키의 "stop-and-escalate"와 헤르메스의 "warn-and-continue" 사이의 타협:

**hooks 실패 심각도에 따른 분기:**
- **Critical hooks** (읽기/쓰기 격리 위반 감지): `onFailure: "stop"` -- 즉시 중단
- **Standard hooks** (스타일 체크, 토큰 경고): `onFailure: "warn-and-log"` -- 경고 후 계속

이를 위해 hook 스크립트의 exit code를 활용:
- exit 0: PASS
- exit 1: FAIL (standard, warn-and-log)
- exit 2: CRITICAL FAIL (stop-and-escalate)

```json
{
  "hooks": {
    "PostToolUse": [
      {
        "command": "python3 /home/jay/workspace/scripts/post-tool-hook.py",
        "exitCodePolicy": {
          "0": "continue",
          "1": "warn-and-log",
          "2": "stop-and-escalate"
        }
      }
    ]
  }
}
```

주의: 이 `exitCodePolicy` 구조는 Claude Code ADK에서 지원하지 않을 수 있습니다. 미지원 시:
- hook 스크립트 내부에서 심각도 판단
- critical이면 STOP 파일(`/tmp/hook-critical-stop.flag`) 생성 + exit 1
- standard이면 로그만 기록 + exit 0
- 팀장 프롬프트에 "STOP 파일 존재 시 즉시 작업 중단 후 보고" 규칙 추가

**4. 효과 측정 기준선 -- 구체적 실행 계획:**

로키 지적을 수용하여, **P1 적용 전 실측 기간** 확보:

**Phase 0: 기준선 실측 (4/1 ~ 4/14, 2주)**
1. task-timers.json에서 최근 2주 데이터 추출: 태스크별 소요 시간
2. qc_verify.py 결과 로그에서 PASS/FAIL 비율 계산
3. git reflog 파싱으로 reset --hard, force push 횟수 실측
4. Claude API 사용량 대시보드에서 모델별 토큰 소비량 추출 (가능한 경우)
5. 결과를 `/home/jay/workspace/memory/metrics/baseline-2026-04.json`에 저장

**Phase 1: P1 적용 (4/15 ~)**
- Progressive Disclosure, 읽기/쓰기 격리, hooks 자동 강제 적용

**Phase 2: 효과 측정 (적용 후 4주, ~5/12)**
- 동일 지표 재측정
- Phase 0 기준선 대비 delta 계산
- 결과를 `/home/jay/workspace/memory/metrics/post-p1-2026-05.json`에 저장

**측정 자동화:** 주간 단위로 `retro` 스킬 실행 시 자동 수집되도록 retro 스킬에 metric 수집 모듈 연동.

---

## 3 Whys 검증

### build_prompt() 시그니처 통합
**Why 1**: Progressive Disclosure를 왜 build_prompt()에 넣나? → 프롬프트 생성이 토큰 사용의 시작점이므로 여기서 제어해야 효과적
**Why 2**: disclosure_phase 파라미터가 최선인가? → 대안(환경변수, 설정 파일)보다 명시적이고 테스트 가능
**Why 3**: 후처리 방식과 조건부 생성 중 어느 것이 맞나? → 1차는 후처리(빠른 검증), 2차에서 조건부(최적화). 단계적 접근이 위험 감소

### permissionMode:plan git 차단
**Why 1**: 왜 git 명령을 차단하나? → 서브에이전트가 실수로 push/merge하여 프로덕션 영향을 주는 사고 방지
**Why 2**: 블랙리스트 vs 화이트리스트? → 화이트리스트가 더 안전하지만, Claude Code permission 매칭 동작 확인이 선행 조건
**Why 3**: 화이트리스트 우회 가능성은? → `python3 -c "os.system('git push')"` 같은 간접 호출은 패턴 매칭으로 차단 불가. 별도 auditing 필요

### hooks 실패 에스컬레이션
**Why 1**: hooks가 실패하면 어떻게 해야 하나? → 심각도에 따라 다르게 처리 (critical=중단, standard=경고)
**Why 2**: 심각도 분류 기준은? → 데이터 무결성/보안 위반=critical, 스타일/규약=standard
**Why 3**: Claude Code ADK가 exitCodePolicy를 지원하나? → 미확인. 미지원 시 hook 스크립트 내부에서 분기 + STOP 파일 방식으로 대체

### 효과 측정 기준선
**Why 1**: 왜 기준선을 먼저 측정하나? → 개선 효과를 정량적으로 입증하려면 비교 대상 필요
**Why 2**: 어떤 지표를 측정하나? → 토큰 비용, QC 품질, 완료 시간, 사고 빈도 -- 비용 절감과 품질 유지 양립 확인
**Why 3**: 측정 기간은 충분한가? → 기준선 2주 + 적용 후 4주 = 총 6주. 학습효과와 피로효과를 모두 포착 가능

---

## 합의 사항

### 1. build_prompt() 시그니처 통합
- **합의**: `prompt_detail: Literal["brief", "normal", "verbose"] = "verbose"` 파라미터 추가
- **파일**: `/home/jay/workspace/prompts/team_prompts.py` -- build_prompt() 함수
- **1차 구현**: 후처리 방식 (build_prompt 내부에서 full 생성 후 섹션 제거)
- **2차 최적화**: 효과 입증 시 각 _build_*_prompt()에 조건부 생성으로 전환
- **호출부**: dispatch.py에서 task_level에 따라 자동 결정 (Lv.1=brief, Lv.2=normal, Lv.3+=verbose)
- **테스트**: 5 팀유형 x 3 detail = 15 테스트 케이스 추가

### 2. permissionMode:plan git 차단 범위
- **합의**: 1차 블랙리스트 방식으로 시작, 화이트리스트 전환 로드맵 포함
- **블랙리스트 (1차)**: git push, git merge, git rebase, git reset --hard, git checkout -- ., git clean, git branch -D, git stash drop, git tag -d, git checkout -f, git restore --worktree .
- **화이트리스트 전환 조건**: Claude Code permission 매칭 동작 확인 후 (allow > deny 우선순위 확인)
- **worktree_manager.py 머지 예외**: 별도 확인 후 결정 (permission 매칭 엔진 동작 의존)
- **파일**: `.claude/settings.json` (프로젝트별) 또는 `.claude/settings.local.json`
- **검증**: sandbox 환경에서 드라이런 테스트, 엣지케이스(이중 스페이스, 환경변수 치환, piped 명령) 포함

### 3. hooks 실패 에스컬레이션
- **합의**: 심각도 기반 2단계 에스컬레이션
  - Critical (격리 위반, 보안): exit code 2 -> 작업 중단 + STOP 파일 생성 + 보고서 에스컬레이션
  - Standard (스타일, 토큰 경고): exit code 1 -> 로그 기록 + 경고 출력 + 작업 계속
- **Claude Code ADK 지원 여부 확인**: exitCodePolicy 미지원 시 hook 스크립트 내부 분기 + STOP 파일 방식
- **파일**: `/home/jay/workspace/scripts/post-tool-hook.py` (신규 또는 수정)
- **로그**: `/home/jay/workspace/memory/logs/hooks.log`
- **재시도**: hooks 자체 재시도 없음 (hook 스크립트 내부에서 필요 시 자체 재시도, Claude Code 레벨 재시도 불가)
- **보고서 의무**: hook 실패 발생 시 보고서에 "Hook 실패" 섹션 필수 기재

### 4. 효과 측정 기준선
- **합의**: P1 적용 전 실측 2주 (4/1~4/14) 필수
- **측정 지표 확정**: (1) 평균 프롬프트 토큰 수, (2) QC PASS 비율, (3) 태스크 완료 시간, (4) git 사고 횟수, (5) hook 실패율
- **기준선 저장**: `/home/jay/workspace/memory/metrics/baseline-2026-04.json`
- **비교 측정**: P1 적용 후 4주 (4/15~5/12)
- **결과 저장**: `/home/jay/workspace/memory/metrics/post-p1-2026-05.json`
- **자동화**: retro 스킬에 metric 수집 모듈 연동 (주간 자동 수집)
- **git 사고 실측 방법**: git reflog 파싱으로 reset --hard, force push 횟수 추출

---

## 미해결 이슈

1. **Claude Code permission 매칭 엔진 동작 확인**: allow vs deny 우선순위, glob vs regex, 환경변수 치환 시점 -- ADK 문서 확인 또는 실험 필요
2. **exitCodePolicy 지원 여부**: Claude Code ADK hooks 스펙에서 exit code별 분기 처리 지원 여부 확인 필요
3. **dispatch.py의 task_level 접근 방법**: build_prompt()에 prompt_detail을 전달하려면 dispatch.py가 task_level을 알아야 함. 현재 dispatch.py에서 task_level을 어떻게 결정하는지 확인 필요
4. **간접 git 호출 차단**: `python3 -c "os.system('git push')"` 같은 간접 호출은 permission 매칭으로 차단 불가. 별도 auditing 메커니즘 필요 여부 결정
5. **retro 스킬 metric 수집 모듈 구현**: retro 스킬에 자동 metric 수집 기능을 추가하는 별도 태스크 필요
6. **STOP 파일 정리 메커니즘**: critical hook 실패로 STOP 파일이 생성된 후, 문제 해결 후 파일 삭제 주체 및 절차 미정
7. **후처리 방식의 섹션 파싱 안정성**: `_extract_section()`, `_remove_sections()` 유틸리티의 마크다운 파싱이 모든 프롬프트 형식에서 안정적인지 검증 필요