# PRD: fireauto 핵심 기능 우리 시스템 통합

> 작성자: 아누 (개발실장)
> 작성일: 2026-04-11
> 레벨: Lv.3 (다중 팀 병렬)
> 상태: Agent Meeting 합의 완료 (2026-04-11) — 제이회장님 승인 대기
> 합의 참가: 시스템 아키텍트, 개발팀장, DevOps, 품질 엔지니어, 프로덕트 매니저, 레드팀

---

## 1. 배경 및 목적

### 현재 문제
1. **작업 기록 공백**: 팀장 봇이 코드를 수정해도 task-timer start/end만 기록. "뭘 고쳤는지, 왜 고쳤는지"는 보고서에만 있고 검색 불가
2. **학습 단절**: 같은 실수를 다른 팀이 반복. 피드백은 아누 메모리에만 있고 팀장 봇에 자동 전달 안 됨
3. **복기 부재**: 세션 끝나면 .done + 보고서만 남음. "이 세션에서 뭘 배웠는지" 체계적 축적 없음
4. **진행률 수동 갱신**: 제이회장님이 매번 "업데이트해"라고 해야 대시보드 갱신
5. **브리핑 한계**: whisper-briefing이 "뭐가 돌고 있는지"만 알려주고 "다음에 뭘 해야 하는지", "최근 뭘 실수했는지" 안 알려줌
6. **CLAUDE.md 비대화**: 팀 프롬프트/규칙이 늘어나면서 관리 어려움
7. **에러 반복 수정**: 팀장 봇이 린트/타입 에러를 수동으로 반복 수정
8. **메모리 검색 한계**: 파일 기반 grep만 가능, 관련 기억 탐색 불가
9. **위임 수동 작성**: 매번 task 파일을 수동 작성 → 시간 소요
10. **수요 조사 수동**: research-prompt는 구조화된 자동 수집/스코어링 없음
11. **루프 반복 한계**: 목표 달성까지 자동 반복하는 기능 미흡

### 목표
fireauto의 검증된 패턴 12개를 우리 멀티봇 시스템에 맞게 통합하여 위 문제를 해결한다.

---

## 1.5. 선행 설계: 멀티봇 Hook 아키텍처

### 문제
fireauto는 1:1(사용자↔AI) 구조라 Hook이 단일 세션에 직접 걸림.
우리는 1:1:8(제이회장님↔아누↔8팀장 봇) 구조라 Hook 적용 대상과 데이터 수집/통합 설계가 필요.

### 설계 결정 (Agent Meeting 합의)

1. **Hook 적용 대상**: 팀장 봇 세션이 주 대상. 아누 세션은 제외.
   - **구현 방식**: settings.json은 전역 1개이므로 봇별 분리 불가.
   - **해결책**: 모든 Hook 스크립트 첫 줄에 `detect-bot.sh` 기반 BOT_ID 가드 삽입.
     ```bash
     source /home/jay/.claude/hooks/lib/detect-bot.sh "$CWD"
     [[ "$BOT_ID" == "anu" || "$BOT_ID" == "unknown" ]] && exit 0
     ```
   - 이미 `stop-qc-reminder.sh`, `post-tool-use.sh`에서 사용 중인 검증된 패턴.

2. **데이터 수집/격리 — 마커 파일 방식**:
   - 기존 `audit-trail.jsonl` 단일 파일에 task_id 필드 의무화 (새 JSONL 파일 생성 않음).
   - UserPromptSubmit Hook에서 프롬프트의 `task_id: task-XXX` 패턴을 regex 추출.
   - 마커 파일 경로: `/home/jay/workspace/memory/sessions/{session_id}.task_id`
   - PostToolUse Hook에서 session_id(stdin JSON에 포함, post-tool-use.sh 17행에서 이미 추출 중)로 마커 파일 참조.
   - 마커 파일 미존재 시: session_id fallback + stderr 경고 (orphan 방지).
   - cleanup: finish-task.sh에서 해당 task 마커 파일 삭제 + 24시간 TTL cron 정리.
   - task_id 필드는 여전히 audit-trail.jsonl에 기록 (schema_version: 2).

3. **8팀 동시 작업 시 격리**:
   - flock 불필요 — POSIX O_APPEND atomic append 보장 (로컬 디스크 전제).
   - 라인 길이 상한: 500바이트 (FILE_PATH truncation 포함).
   - 전제 조건: 로컬 디스크 파일시스템 (NFS/tmpfs 환경에서는 flock 재검토).
   - task_id 필드로 논리적 격리.

4. **Hook 성능**: 
   - 모든 Hook에 `timeout 5 ... || true` 래퍼 적용.
   - PostToolUse Hook은 카운터/기록만 담당 (pyright 등 무거운 연산 직접 실행 금지).
   - async가 불가능한 구조이므로 스크립트 실행 시간 최소화 (50ms 이하 목표).

5. **Hook 배포 전략**:
   - Sprint 0 (0.5일): 템플릿 표준화 + settings.json 백업/롤백 절차 수립.
   - Phase 1: 기능 구현 (Hook 추가 없음).
   - Phase 2: Hook 추가. 1개 팀 시범 → 전 팀 확대.

6. **settings.json 관리 절차**:
   - Sprint 0에서 `settings-deploy.sh` 자동화 스크립트 작성.
   - 순서: JSON 검증(`python3 -m json.tool`) → 타임스탬프 백업(`settings.json.bak.YYYYMMDD_HHMMSS`) → 적용.
   - 디버그 모드: 마커 파일 `/home/jay/.claude/hooks/.debug-enabled` 존재 여부로 제어.
   - 실행 중 세션에는 미반영 (새 세션부터 적용).

---

## 2. 도입 기능 (12개)

### 등급별 분류 (Agent Meeting 재분류)
- ★★★ (F4, F5): CEO 즉시 체감 가치
- ★★★ (F1, F2): 핵심 데이터 수집 인프라
- ★★ (F3, F7, F8, F10): 품질/검색/자동화
- ★ (F6, F9, F11, F12): 고도화/조건부

### Feature 1: audit-trail.jsonl 강화 — 자동 작업 기록

**fireauto 원본:**
- Edit/Write 시 자동으로 Haiku가 분류 → SQLite 저장

**우리 시스템 적용 (합의안):**
```
팀장 봇이 Edit/Write 실행
→ PostToolUse Hook 실행
→ 기존 audit-trail.jsonl에 task_id 필드 포함하여 기록
→ 경로: /home/jay/workspace/memory/logs/audit-trail.jsonl
→ 각 줄: {"timestamp", "tool", "file", "team", "task_id", "session_id", "schema_version": 2}
```

**fireauto와 차이점:**
- fireauto: Haiku API 실시간 요약 (비용 발생)
- **우리: 추가 LLM 호출 없이 파일명+메타데이터만 기록** (API 비용 0, 스크립트 실행 비용만 존재)
- 새 파일 생성 않고 기존 audit-trail.jsonl 확장 (단일 소스 원칙)

**구현 방식:**
- 기존 `post-tool-use.sh`에 task_id 기록 로직 추가 (별도 Hook 스크립트 없음)
- PostToolUse Hook에서 session_id로 `/home/jay/workspace/memory/sessions/{session_id}.task_id` 마커 파일 참조하여 task_id 읽기
- 마커 파일 미존재 시 session_id fallback + stderr 경고
- `scope_check.py`가 audit-trail에서 task_id 필터링하여 수정 파일 목록 자동 생성

**예상 효과:**
- 보고서 없이도 "이 task에서 어떤 파일을 몇 번 수정했는지" 자동 추적
- 기존 QC 파이프라인(scope_check.py)과 즉시 통합

---

### Feature 2: 세션 통계 자동 생성 — 보고서 섹션 통합

**fireauto 원본:**
- Stop Hook → retrospect API → Haiku 세션 분석 → 별도 파일 저장

**우리 시스템 적용 (합의안):**
```
팀장 봇 세션 완료 → finish-task.sh 실행
→ audit-trail.jsonl에서 해당 task_id 레코드 집계
→ reports/{task_id}.md에 "## 세션 통계" 섹션 append:
  - 수정 파일 목록 + 각 파일 Edit/Write 횟수
  - 총 도구 호출 횟수
  - 세션 시작~종료 시간 (task-timers.json 참조)
```

**fireauto와 차이점:**
- fireauto: 별도 retrospective 파일 + Haiku API
- **우리: 보고서 내 섹션으로 통합 + audit-trail 집계 기반** (별도 파일/API 없음)
- 세션 통계는 audit-trail.jsonl로부터 언제든 재생성 가능 (원본 데이터 분리 원칙)

**구현 방식:**
- `finish-task.sh` 말미에 세션 통계 생성 로직 추가
- qc_verify.py PASS 후에만 보고서에 append (불완전 보고서 방지)
- 비정상 종료 시 trap 핸들러로 최소 통계(시작/종료 시각) 기록

**예상 효과:**
- 아누가 보고서 1개 파일에서 작업 내용 + 통계 모두 확인
- .done 판정 주체: qc_verify.py 단일화 (중복 검증 제거)

---

### Feature 3: 파일 접근 빈도 분석 v1 — 반복 패턴 → 학습 리포트

**fireauto 원본:**
- 3회 같은 패턴 반복 → 스킬 자동 생성 + CLAUDE.md 규칙 추가

**우리 시스템 적용 (합의안 — v1):**
```
주간 /retro 자동 스케줄 실행
→ audit-trail.jsonl + reports/*.md 분석
→ 반복 패턴 감지 (v1: 파일 빈도만):
  - 같은 파일이 주간 task 중 N% 이상 AND 절대값 3건 이상 수정 → "핫스팟 파일"
  - 인프라 파일 화이트리스트 제외 (task-timer.py, qc_verify.py 등)
  - import 상위 파일 제외 규칙 (노이즈 필터)
→ /home/jay/workspace/memory/learnings/weekly-{date}.md 저장
→ whisper-briefing에 "미처리 학습 피드백 N건" 자동 표시
→ 각 피드백 레코드에 status 필드: pending / applied / skipped_whitelist / deferred_v2
→ 같은 파일을 수정한 task 목록 표시 (F9 흡수 기능)
```

**actionable_path 스키마:**
```json
{
  "type": "refactor_candidate" | "test_gap" | "config_hotspot",
  "action": "구체적 후속 작업",
  "priority": "high" | "medium" | "low"
}
```

**화이트리스트 갱신:**
- /retro 실행 시 신규 파일 제안 → 아누 승인

**v1 한계 (명시적 고지):**
- 에러 메시지 유사도 분석 미지원 (v2에서 lookup table 방식 도입 예정)
- 팀별 작업 유형 분류 미지원
- 학습 리포트/whisper 출력에 "학습 기능 v1 — 에러 유사도 미지원(v2 예정)" 문구 자동 포함

**fireauto와 차이점:**
- fireauto: 실시간 스킬 자동 생성
- **우리: 주간 배치 학습 리포트 → 아누 판단 후 수동 반영**
- v1은 파일 빈도만. 유사도/자동 생성은 v2 이후.

**구현 방식:**
- `/retro` 스킬 확장: audit-trail + 보고서 분석 로직 추가
- 화이트리스트: `config/learning-whitelist.yaml`로 외부화
- 임계값: `config/learning-thresholds.yaml`로 외부화

**예상 효과:**
- "server.py가 이번 주 12개 task에서 수정됨" 자동 감지
- 아누 부재 시에도 whisper에 미처리 피드백 가시화

---

### Feature 4: 진행률 자동 계산 [★★★ CEO 즉시 체감]

**fireauto 원본:**
- SQLite DB + MCP → 즉시 completed/total 재계산

**우리 시스템 적용:**
```
task-timer.py end {task_id} 실행 시
→ task-timers.json에서 해당 프로젝트의 전체 태스크 집계
→ 가중 진행률 = Σ(완료 task weight) / Σ(전체 task weight)
→ active-projects.json의 progress 필드 자동 갱신
→ 대시보드 프로젝트뷰 API 응답에 실시간 진행률 포함
→ whisper-briefing에 "프로젝트별 진행률" 자동 표시
```

**task weight 필드:**
- 1=소, 2=중, 3=대
- 미입력 시 기본값=1 자동 적용

**project_id 운영:**
- Sprint 0에서 project_id 미입력 WARN 캠페인 + 미입력률 대시보드 노출
- 4주 후 project_id 사용률 재평가

**구현 방식:**
- `task-timer.py`에 `progress` 서브커맨드 추가 + weight 필드
- `active-projects.json`의 progress 필드 자동 갱신 (가중 진행률)
- 대시보드 JS에 5분 자동 새로고침 추가 (SSE 불필요)

**예상 효과:**
- 제이회장님 "업데이트해" 요청 0회
- 세션 시작 시 진행률 자동 파악

---

### Feature 5: whisper-briefing 강화 — 선행적 컨텍스트

**우리 시스템 적용 (합의안):**

**아누 세션 전용 (전체 whisper):**
```
[진행률] InsuWiki 78% | ThreadAuto 92% | MediScan 15%
[미착수 목록] InsuWiki Phase 3 (마지막 수정 3일 전) ← 추천이 아닌 목록
[최근 실수]
- 직접 코딩 금지 위반 (2026-04-09)
- server.py timeout 미반영 서버 재시작 누락 (2026-04-10)
[미처리 학습] 학습 피드백 3건 미확인 (v1)
```

**팀장 봇: UserPromptSubmit Hook에서 1줄만 주입:**
- 포맷: `[{project} {progress}% | {on/off-track} | D-{days}] retry:{remaining}`
- 예: `[InsuWiki 78% | on-track | D-5] retry:3`

**합의 결정:**
- "다음 추천" 기능은 6개월 보류. 잘못된 추천은 신뢰 하락 유발.
- 대신 "미착수 + 마지막 수정 3일 이상 지난 task" 목록 표시 (추천이 아닌 사실 나열).
- 추천은 제이회장님 피드백이 충분히 쌓인 후 도입.

**구현 방식:**
- `whisper-compile.py` 확장 (아누: 전체, 팀장: 1줄)
- F4의 진행률 데이터 활용
- 최근 피드백 메모리에서 실수 3건 추출
- 미착수 태스크 목록 (task-timers.json 기준)

---

### Feature 6: CLAUDE.md 비대화 경고 [★ — 등급 하향]

**합의 결정:**
- 경고만으로는 가치가 낮음 → ★★에서 ★로 하향.
- QC 셀프 체크리스트 항목 10에 "CLAUDE.md 100줄 미만 확인" 추가.
- `qc_verify.py`에 `claude_md_check` verifier (WARN 전용) 추가.
- 자동 트리밍 없음 (team_prompts.py 동적 생성 구조와 충돌).
- 100줄 기준: 팀 고유 규칙 줄 수 기준 (team_prompts.py 공통 섹션 제외).

---

### Feature 7: 에러 감지 + Hook 강제 재시도 [★★]

**합의 결정 — 전면 재설계:**

**에러 판별:**
- PostToolUse stdin에서 에러 패턴 감지 (구체적 필드는 Sprint 0 첫째 날 검증)

**대상 파일:**
- `.py`, `.ts`, `.js`, `.sh`, `.go`, `.json`, `.yaml` (.md 제외)

**차단 방식 (PreToolUse Hook):**
- `{"permissionDecision":"deny","reason":"에러 3회 초과"}` 출력 (Edit|Write 매처)
- 검증 근거: careful-check.sh line 137에서 `permissionDecision` 필드 이미 사용 중

**카운터 관리:**
- 카운터 위치: `/home/jay/workspace/memory/logs/retry-counters/{task_id}.count`
- 카운터 리셋: task 시작 시 UserPromptSubmit Hook에서 초기화
- Hook 카운터(코딩 중)와 qc_verify 카운터(QC 단계) 독립 경로, 상호 참조 없음

**기존 시스템과 공존:**
- 기존 circuit_breaker.py: 봇 레벨(기존) 유지, 태스크 레벨(F7) 추가 — 분리 공존

**점층적 재시도 전략:**
- 1회차: 에러 메시지 직접 수정
- 2회차: 관련 import/타입 힌트 전체 점검
- 3회차: 에스컬레이션 (아누 보고)

**QC 단계 (2단계):**
- 기존 qc_verify.py pyright_check verifier 유지
- FAIL → 수정 → 재검증 (최대 3회)

---

### Feature 8: 메모리 통합 검색 [★★]

**우리 시스템 적용:**
```
기존 파일 기반 메모리 유지 + 검색 스크립트:
→ memory/reports/*.md + memory/research/*.md + memory/learnings/*.md
→ memory-search.py (grep 기반 + 파일명/날짜/팀 필터링)
→ 대시보드 기록 탭에 통합 검색 기능 추가
```

**SQLite 도입 조건 (합의):**
- 파일 수 3,000건 초과 시 SQLite FTS4 도입 재검토
- 검색 응답 시간 500ms 초과 시 트리거
- 현재 파일 수: ~1,600건 → 현 시점에서는 grep으로 충분

---

### Feature 9: 메모리 관계 연결 [★ → Dropped]

**합의 결정:**
- 별도 구현 없음 (concurrent write 문제 + 실사용 불명확)
- F3에 흡수된 기능: "같은 파일을 수정한 task 목록" 표시 기능만 F3에 포함
- 추후 실사용 수요 확인 시 별도 프로젝트로 검토

---

### Feature 10: dispatch.py PRD 자동 분해 [★★ — 등급 상향]

**합의 결정:**
- ★에서 ★★로 상향 (dispatch.py 일상 사용 가치 높음)
- **선행 조건**: PRD 템플릿 표준화 (Sprint 0에서 처리)
  - 구조화된 `## Tasks` 섹션 아래 bullet list 형식 강제
  - 정규식 파싱 우선, LLM 파싱은 폴백으로만 사용 (deterministic 보장)
- dispatch.py에 `--prd` 옵션 추가

---

### Feature 11: 수요 조사 자동 수집 [★ — 조건부 진행]

**합의 결정:**
- Phase 4에서 조건부 진행
- **진입 조건**: Phase 2 종료 시점까지 수동 수요조사 요청이 주 1회 이상 발생
- **결정 데드라인**: Phase 3 완료 후 2일 이내. 미결정 시 기본값 = 미구현(excluded)
- 네이버 API 제한/차단 리스크 사전 평가 필요
- advanced-crawling 스킬(Scrapling) 활용 방안 검토

---

### Feature 12: completion-promise — 루프 반복 고도화 [★]

**합의 결정 — Circuit Breaker 설계:**
- **최대 재위임**: 2회 (hard limit, 상수로 코드에 명시)
- **Circuit Breaker**: 2회 실패 → `escalations/{task_id}_escalation.json` 생성 + 완전 중단
- **완료 조건**: qc_verify.py PASS 필수 (자기 검증/self-certification 금지)
- **구현 방식**: chain_manager.py에 retry phase 삽입 (dispatch.py 새 옵션 아님)
- **재위임 이력**: audit-trail.jsonl에 기록 (모든 재위임 진입점에서 강제)

**qc_verify.py 검증 범위 문서화 (합의):**
- 검증 가능: 정적 타입 체크(pyright), 린트, 파일 존재 확인, SCQA 포맷 준수
- 검증 불가: 동적 import, 멀티프로세스 race, 네트워크 의존 테스트, 비즈니스 로직 정합성
- 인간 검토 샘플링: 월 1회, escalation.json 발생 task 100% + 나머지 10% 랜덤

---

## 2.5. Feature 분류 및 의존성 DAG

### 분류
- Core: F1(audit-trail), F2(세션 통계) — 데이터 인프라
- CEO Value: F4(진행률), F5(whisper) — 즉시 체감
- Automation: F10(PRD 분해) — 위임 자동화
- Quality: F7(에러 감지), F3(빈도 분석), F6(CLAUDE.md 경고), F8(메모리 검색)
- Advanced: F12(completion-promise) — 고도화
- Conditional: F11(수요 조사) — 진입 조건부
- Dropped: F9(관계 그래프) → 폐기, F3에서 "같은 파일 수정 task 목록" 기능으로 최소 커버

### 의존성 DAG
F2→F1, F3→F1, F7 독립(Phase 2 인프라 위), F5→F4
독립 배포 가능: F4, F5, F6, F8, F10, F12

### CEO 보고용 프레이밍
"업무보고 자동화 3종: 진행률(F4) + 브리핑(F5) + 위임분해(F10)"
나머지: "안정성·품질 확보를 위한 백엔드 작업"

---

## 3. 구현 로드맵 (합의안 — 재배치)

### Sprint 0 (0.5일) — 준비
- PRD 템플릿 표준화 (F10 선행)
- settings.json 백업/롤백 절차 수립
- settings-deploy.sh 자동화 스크립트 작성
- 각 Phase Definition of Done 체크리스트 작성
- 성공 지표 기준선(Baseline) 사전 측정
- 기존 텍스트 재시도 규칙 병행 운영 선언 (deprecated가 아닌 병행)
- F7 에러 판별 필드 검증 (PostToolUse stdin 스펙 확인)

### Phase 1 (2일) — CEO 즉시 체감 [F4, F5]
- task-timer.py progress 서브커맨드 + weight 필드
- active-projects.json 자동 갱신 (가중 진행률)
- whisper-compile.py 확장 (아누: 전체, 팀장: 1줄)
- 대시보드 JS 5분 자동 새로고침
- **DoD**: 대시보드에서 가중 진행률 자동 표시, whisper에 실수 3건 포함

### Phase 2 (3일) — Hook 인프라 + 자동 기록 [F1, F2, F10, F6]
- audit-trail.jsonl에 task_id/schema_version 필드 추가 (마커 파일 방식)
- UserPromptSubmit Hook: 마커 파일 생성
- finish-task.sh 세션 통계 섹션 생성 로직
- dispatch.py --prd 옵션 (정규식 파싱 우선, LLM 폴백)
- qc_verify.py claude_md_check verifier (WARN 전용)
- 1개 팀 시범 운영 → 전 팀 확대
- audit-trail.jsonl 하위 호환성 검증
- **DoD**: 1개 팀 세션에서 task_id 포함 기록 + PRD 분해 테스트 + CLAUDE.md 경고 동작

### Phase 3 (2일) — 에러감지 + 학습 + 검색 [F7, F3, F8]
- F7: PreToolUse Hook 에러 차단 + 카운터 관리
- F3: /retro 스킬 확장 (파일 접근 빈도 분석 v1)
- F8: memory-search.py + 대시보드 통합 검색
- **DoD**: 에러 3회 차단 확인, 주간 빈도 리포트 샘플, 대시보드 검색 동작

### Phase 4 (2일) — 고도화 (조건부) [F12, F11]
- chain_manager.py retry phase + circuit breaker
- escalation 파일 생성 + 알림 연동
- F11: 진입 조건 충족 시에만 (미충족 시 Phase 4 = F12만, 1일로 단축)
- F9: F3에 흡수 완료, 별도 구현 없음
- **DoD**: completion-promise 2회 재위임 + 3회차 circuit breaker 동작 확인

**총 소요 업데이트:**
- Phase 1~3: 7일 + Sprint 0 0.5일 = 7.5일 ≈ 2주
- Phase 4 포함: 9.5일 ≈ 2.5~3주
- F11 포함/제외 결정 데드라인: Phase 3 완료 후 2일 이내
- 각 Phase 완료 후 스테이크홀더 체크포인트 (간략 데모/상태 보고) 1회

---

## 3.5. QC 전환 과도기

Sprint 0 ~ Phase 3 완료까지:
- 기존 텍스트 재시도 규칙(DIRECT-WORKFLOW)과 qc_verify.py 병행 운영
- 판정 충돌 시 우선순위: qc_verify.py > 텍스트 규칙
- deprecated 트리거: Phase 3 완료 후 qc_verify.py 통과율 90% 이상 5일 연속

---

## 4. 도입하지 않는 것 (명시적 제외)

| 기능 | 제외 이유 |
|-----|---------|
| SQLite 메모리 DB | 파일 기반으로 충분 (파일 3,000건 초과 시 재검토) |
| Haiku 실시간 요약 | 매 Edit/Write마다 API 호출은 과도. 배치 처리로 대체 |
| 스킬 자동 생성 | 스킬 80개+. 자동 생성 시 중복/충돌 위험. 아누 판단 후 수동 |
| 2-Layer MCP (stdio→HTTP) | CLI 기반 환경에서 불필요 |
| CLAUDE.md 자동 수정 | 아누 규칙이 들어있는 CLAUDE.md 자동 수정은 위험. QC 경고만 |
| SSE 실시간 대시보드 | JS 5분 자동 새로고침으로 충분. SSE 추가는 오버엔지니어링 |
| Reddit API 직접 호출 | 우리는 네이버 도메인. Reddit 대신 네이버 카페/블로그 (F11, 조건부) |
| 별도 observations JSONL | audit-trail.jsonl 통합으로 대체. 데이터 분산 방지 |
| 별도 retrospectives MD | 보고서 세션 통계 섹션으로 대체. 파일 수 증가 방지 |
| 별도 relations.json | F3 학습 리포트에 흡수. concurrent write 위험 회피 |
| 에러 유사도 알고리즘 (v1) | v2에서 lookup table 방식 도입 예정 |
| whisper-briefing 다음 추천 | 6개월 보류. 오추천 시 신뢰 하락 위험 |
| COKACDIR_TASK_ID 환경변수 | cokacdir 클로즈드 바이너리에서 자식 프로세스로 환경변수 전달 불가. 마커 파일 방식으로 대체 |
| audit-trail flock | POSIX O_APPEND atomic append로 충분 (로컬 디스크 전제). flock 도입 시 성능 저하 |

---

## 5. 성공 지표

| 지표 | 현재 | 목표 | Feature | Phase | 측정 방법 |
|-----|------|------|---------|-------|---------|
| 제이회장님 "업데이트해" 횟수 | 세션당 1-2회 | 0회 | F4 | 1 | 주간 아누 세션 로그에서 "업데이트해" 키워드 검색 |
| 브리핑 선행성 | 현황만 | 실수+목록 포함 | F5 | 1 | 주간 아누 세션 로그에서 "업데이트해" 키워드 검색 |
| CLAUDE.md 비대화 감지 | 수동 | QC 자동 경고 | F6 | 2 | audit-trail에서 task_id 포함 레코드 / 전체 레코드 |
| 작업 기록 자동화율 | 0% | 100% (task_id 포함) | F1 | 2 | audit-trail에서 task_id 포함 레코드 / 전체 레코드 |
| 보고서 통계 섹션 | 없음 | 자동 생성 | F2 | 2 | audit-trail에서 task_id 포함 레코드 / 전체 레코드 |
| 에러 재시도 보장 | 텍스트 규칙 | Hook 강제 | F7 | 3 | audit-trail에서 task_id 포함 레코드 / 전체 레코드 |
| 반복 패턴 감지 | 아누 기억 의존 | 주간 자동 리포트 | F3 | 3 | audit-trail에서 task_id 포함 레코드 / 전체 레코드 |
| 메모리 검색 | grep 수동 | 대시보드 통합 | F8 | 3 | audit-trail에서 task_id 포함 레코드 / 전체 레코드 |
| 위임 속도 | task 수동 작성 | PRD 자동 분해 | F10 | 2 | audit-trail에서 task_id 포함 레코드 / 전체 레코드 |
| 루프 안전성 | 제한 없음 | 2회+circuit breaker | F12 | 4 | audit-trail에서 task_id 포함 레코드 / 전체 레코드 |

**측정 주기 및 담당:**
- 주기: 주 1회 (월요일), 담당: 아누
- 기준선: Sprint 0에서 현재 값 사전 측정

---

## 6. 리스크

| 리스크 | 대응 | 합의 출처 |
|-------|------|----------|
| Hook이 세션 속도를 늦춤 | timeout 5초, 스크립트 50ms 이하 목표, 무거운 연산 금지 | 아키텍트+DevOps |
| audit-trail.jsonl 비대화 | 일별 logrotate + copytruncate, 30일 보존 | DevOps |
| Hook 오류로 봇 블로킹 | trap 'exit 0' ERR, timeout 래퍼, detect-bot.sh 가드 | DevOps |
| task_id 누락 기록 | 마커 파일 미존재 시 session_id fallback | 레드팀 |
| 라인 길이 초과 | 라인 길이 상한 500바이트 가이드라인 (FILE_PATH truncation 포함) | 아키텍트+DevOps |
| completion-promise 무한루프 | 최대 2회 + circuit breaker + human-escalation | 레드팀 |
| F10 PRD 형식 불일치 | 정규식 파싱 우선 + LLM 폴백, 템플릿 표준화 선행 | 레드팀 |
| 학습 리포트 노이즈 | 화이트리스트 + 비율+절대값 AND 조건 | QA+레드팀 |
| F7 텍스트 규칙 중복 | 병행 과도기 + qc_verify 우선 후 deprecated | 개발팀장+QA |
| qc_verify.py 자체 한계 | 검증 범위 문서화, 인간 검토 샘플링 향후 검토 | 레드팀 |
| 기존 시스템과 충돌 | Phase 2에서 1팀 시범 후 전체 적용 | 전원 |
| Hook 디버깅 어려움 | 모든 Hook에 debug 로그 추가 (hook-debug.log) | 레드팀 |
| 롤백 불가능성 | 모든 신규 기능에 graceful degradation (파일 없으면 skip) | 레드팀 |