# Discord Bridge 딥 디버깅 — 시행착오 기록

- **시간**: 2026-03-08 05:30~07:00
- **Vikunja**: #252 → done, #253 진행중, #251 코멘트 추가

## 시행착오 요약 (소거법)

### ❌ 시도 1: Bot 재시작 불필요
- **가설**: Bot이 죽어서 메시지가 안 간다
- **현실**: Bot은 PID 25508로 정상 동작 중이었음
- **배움**: Bot 프로세스 확인은 `Get-Process -Name python | Select PID,StartTime`

### ❌ 시도 2: 수동 테스트 파일 깨짐 (BOM 인코딩)
- **가설**: Bot이 파일을 안 읽는다
- **현실**: `cmd /c echo {...} > file.json`이 BOM(FF FE) 포함 UTF-16 생성
- **배움**: **테스트 파일은 PowerShell Set-Content -Encoding UTF8 사용**
- **증거**: Bot 로그에 `Expecting property name enclosed in double quotes` 반복

### ❌ 시도 3: getDiagnostics 기반 진단 폴링 무의미
- **가설**: getDiagnostics 데이터로 step 변화를 잡을 수 있다
- **현실**: `getDiagnostics.recentTrajectories.lastStepIndex`가 **실시간 업데이트 안 됨**
- **증거**: POLL#1~#2 모두 `steps=1237 known=0` 고정 (실제 step은 1239+)
- **배움**: **getDiagnostics는 세션 메타데이터용, 실시간 step 추적 불가**

### ❌ 시도 4: SDK EventMonitor 의존 불가
- **가설**: SDK monitor.onStepCountChanged가 실시간 감지
- **현실**: EventMonitor._pollTrajectories()가 getDiagnostics 사용 → stale
- **배움**: **SDK EventMonitor는 실시간 step 추적에 부적합**

### ✅ 최종 해결: rawRPC 직접 폴링
- `GetCascadeTrajectorySteps` rawRPC는 **실시간 step 데이터를 정확히 반환**
- 5초 간격 폴링으로 PLANNER_RESPONSE, NOTIFY_USER, TASK_BOUNDARY, WAITING 릴레이
- `getDiagnostics`는 active session ID 확인 용도로만 (최초 + 60초마다)

## 핵심 교훈

| # | 교훈 | 카테고리 |
|---|------|----------|
| 1 | `cmd /c echo`로 JSON 만들지 마라 (BOM) | Windows |
| 2 | `getDiagnostics.lastStepIndex`는 stale | SDK |
| 3 | SDK EventMonitor는 getDiagnostics 의존 | SDK |
| 4 | `rawRPC('GetCascadeTrajectorySteps')`만 실시간 | SDK |
| 5 | Step control은 `vscode.commands` 사용 | SDK |
| 6 | 분석 문서는 brain이 아닌 프로젝트 docs에 저장 | 프로세스 |

## 참조: `docs/discord-bridge-analysis.md`