# 작업: 위스퍼 .done 프로토콜 버그 수정 + WebFetch 429 에러 대응

## 두 가지 작업을 순서대로 처리

---

## 작업 A: 위스퍼 .done 프로토콜 버그 수정 (우선)

### 문제
`auto_merge.py`가 `.done` → `.done.clear` 변환(try_claim)을 실행하면서, 아누가 제이회장님께 완료 보고하기 전에 `.done` 파일이 사라짐.
- `.done` = 미처리 완료 작업 (아누가 보고 해야 함)
- `.done.clear` = 아누가 보고 완료 후 마킹
- 하지만 `auto_merge.py`가 `.done.clear`를 먼저 생성 → 아누가 감지 못함 → 영구 누락

### 원인
`/home/jay/workspace/scripts/auto_merge.py` line 115-137 `try_claim()` 메서드가 `.done.clear` 파일을 생성하여 처리 선점하는데, 이 네이밍이 아누의 `.done` 프로토콜과 충돌.

### 수정 방안

#### A-1. auto_merge.py — claim 파일명 분리
- `try_claim()`: `.done.clear` 대신 **`.done.merging`** 파일 생성으로 변경
- `scan_done_files()`: `.done.merging`이 있는 것도 이미 처리 중으로 판단 (line 103-108)
- `.done` 파일은 **삭제하지 않음** — 아누가 보고 후 `.done.clear`로 변환해야 함
- 머지 완료 후 `.done` 삭제하는 코드(line 661, 689, 714) 제거 — `.done` 유지

#### 변경 요약:
```python
# try_claim: .done.clear → .done.merging
def try_claim(self, done_file: Path) -> bool:
    merging_file = done_file.with_suffix(".done.merging")  # 변경
    ...

# scan_done_files: .done.merging도 이미 처리 중으로 판단
def scan_done_files(self) -> list[Path]:
    for done_file in sorted(self.events_dir.glob("*.done")):
        clear_file = done_file.with_suffix(".done.clear")
        merging_file = done_file.with_suffix(".done.merging")  # 추가
        if not clear_file.exists() and not merging_file.exists():  # 변경
            done_files.append(done_file)

# .done 파일 삭제 코드 제거 (line 661, 689, 714, 730)
# done_file.unlink(missing_ok=True) → 삭제하지 않음
```

#### A-2. user-prompt-submit.sh — 안전망 강화 (선택)
현재 5분 안전망이 너무 짧음. 하지만 A-1 수정으로 `.done`이 유지되므로 이 문제는 자연 해결됨.
별도 수정 불필요.

#### A-3. _finalize_done_file도 수정
```python
def _finalize_done_file(self, done_file: Path, task_id: str, action: str, reason: str) -> None:
    """처리 완료 후 로그만 기록. .done 파일은 삭제하지 않음 (아누가 처리)."""
    self.log_result(task_id, {...})
    # done_file.unlink(missing_ok=True)  # 삭제 금지
```

### 수정 대상 파일
- `/home/jay/workspace/scripts/auto_merge.py`

### 테스트 방법
1. 테스트용 `.done` 파일 생성: `echo '{"task_id":"task-test"}' > /home/jay/workspace/memory/events/task-test.done`
2. `python3 /home/jay/workspace/scripts/auto_merge.py --dry-run` 실행
3. `.done` 파일이 삭제되지 않고 유지되는지 확인
4. `.done.merging` 파일이 merge_needed=True 케이스에서만 생성되는지 확인
5. 테스트 후 정리: `rm /home/jay/workspace/memory/events/task-test.*`

---

## 작업 B: WebFetch HTTP 429 에러 대응

### 문제
2팀(오딘)이 superpowers 리포 분석(task-605.1) 중 GitHub에 병렬 WebFetch 호출 → HTTP 429 (Too Many Requests) + "Sibling tool call errored" 발생.

### 원인
Claude Code의 WebFetch 도구가 같은 도메인(github.com)에 여러 개 동시 요청을 보낼 때 GitHub 서버가 rate limit 적용.

### 수정 방안
이 문제는 Claude Code의 WebFetch 자체를 수정할 수 없으므로, **위임 프롬프트에 가이드라인 추가**로 대응.

#### B-1. 팀 워크플로우에 WebFetch 가이드 추가
`/home/jay/workspace/prompts/DIRECT-WORKFLOW.md` 파일에 다음 규칙 추가:

```markdown
## WebFetch 사용 규칙
- 같은 도메인에 대한 WebFetch 호출은 **동시에 최대 2개까지**만 병렬 실행
- GitHub 등 rate limit이 있는 사이트: 순차 호출 권장
- HTTP 429 에러 발생 시: 해당 도메인에 대한 요청을 줄이고, WebSearch 또는 gh CLI로 대체
- GitHub 리포 분석 시: `gh` CLI 명령어 우선 사용 (예: `gh api repos/owner/repo`, `gh repo view`)
```

#### B-2. GitHub 전용 대안: gh CLI 활용 지침
DIRECT-WORKFLOW.md에 추가:
```markdown
## GitHub 리포 분석 가이드
GitHub 리포지토리 분석 시 WebFetch 대신 다음 도구를 우선 사용:
1. `gh repo clone <repo>` → 로컬 클론 후 Read/Grep/Glob으로 분석
2. `gh api repos/<owner>/<repo>/contents/<path>` → API로 파일 내용 조회
3. WebSearch로 리포 관련 블로그/문서 검색
4. WebFetch는 최후 수단으로, 순차적으로만 사용
```

### 수정 대상 파일
- `/home/jay/workspace/prompts/DIRECT-WORKFLOW.md`

### 테스트
- 수정 후 새로운 위임 작업에서 WebFetch 429 에러가 줄어드는지 모니터링

---

## 산출물
- 보고서: `/home/jay/workspace/memory/reports/task-606.1.md`