# Discord Bridge 디버깅 분석 로그

> 날짜: 2026-03-08
> 세션: e7b46728-6c7d-4220-b45a-d79e5a8c2318

## 1. Step Type 전체 매핑 (775 steps)

`GetCascadeTrajectorySteps` RPC로 현재 세션의 775개 step을 덤프한 결과:

| Step Type | 횟수 | Statuses | Data Key | Discord 전달 여부 |
|-----------|------|----------|----------|------------------|
| PLANNER_RESPONSE | 218 | DONE | plannerResponse | ✅ AI 응답 (핵심) |
| EPHEMERAL_MESSAGE | 186 | DONE | ephemeralMessage | ❌ 내부 시스템 알림 |
| RUN_COMMAND | 81 | DONE, CANCELED | runCommand | ✅ 명령 실행 (WAITING 시) |
| TASK_BOUNDARY | 71 | DONE | taskBoundary | 🟡 작업 진행 상태 |
| USER_INPUT | 38 | DONE | userInput | 🟡 사용자 입력 |
| VIEW_FILE | 38 | DONE | viewFile, permissions | ❌ 파일 읽기 |
| CODE_ACTION | 36 | DONE, ERROR | codeAction, error | ✅ 파일 수정/생성 (WAITING 시) |
| ERROR_MESSAGE | 33 | DONE | errorMessage | ❌ 에러 |
| GREP_SEARCH | 18 | DONE | grepSearch | ❌ 검색 |
| NOTIFY_USER | 18 | DONE | notifyUser | ✅ 사용자 알림 |
| VIEW_CODE_ITEM | 9 | DONE | viewCodeItem | ❌ 코드 조회 |
| CONVERSATION_HISTORY | 7 | DONE | conversationHistory | ❌ 대화 이력 주입 |
| KNOWLEDGE_ARTIFACTS | 7 | DONE | knowledgeArtifacts | ❌ KI 주입 |
| CHECKPOINT | 7 | DONE | checkpoint | ❌ 세션 체크포인트 |
| LIST_DIRECTORY | 4 | DONE | listDirectory, permissions | ❌ 디렉토리 조회 |
| VIEW_FILE_OUTLINE | 2 | DONE | viewFileOutline | ❌ 파일 아웃라인 |
| FIND | 2 | DONE | find | ❌ 파일 검색 |

### PLANNER_RESPONSE 구조
```json
{
  "thinking": "내부 사고 과정 (SKIP)",
  "response": "사용자 대면 텍스트",
  "modifiedResponse": "정리된 버전 (있으면 우선 사용)",
  "toolCalls": [{"name": "...", "argumentsJson": "..."}],
  "thinkingDuration": "0.9s",
  "stopReason": "STOP_REASON_STOP_PATTERN"
}
```

### WAITING 상태 미관측
775 steps 중 `WAITING` 상태가 **0개**. 이유:
1. `SafeToAutoRun=true` → WAITING 없이 바로 실행
2. 이미 승인/거부된 step → DONE/CANCELED로 변환
3. `GetCascadeTrajectorySteps`는 완료된 step만 반환하는 것으로 보임

---

## 2. SDK 아키텍처 분석 (antigravity-sdk v1.6.0)

### 전체 구조
```
AntigravitySDK
├── commands: CommandBridge          ← vscode.commands.executeCommand 래퍼
├── state: StateBridge               ← state.vscdb (USS) 직접 읽기
├── cascade: CascadeManager          ← 대화 관리 + step control
├── monitor: EventMonitor            ← 상태 변화 감지 (polling)
├── ls: LSBridge                     ← Language Server RPC (rawRPC)
└── integration: IntegrationManager  ← Agent View UI 커스터마이즈
```

### EventMonitor (transport/event-monitor.ts)
- **USS 폴링**: `state.vscdb` 키 크기 변화 감지 (setInterval)
- **Trajectory 폴링**: `antigravity.getDiagnostics` → `recentTrajectories[].lastStepIndex` 비교
- 데이터 소스: `vscode.commands.executeCommand('antigravity.getDiagnostics')`
- `recentTrajectories`는 최근 10개 대화만 포함

### Step Control (cascade/cascade-manager.ts)

| 메서드 | VS Code 명령어 | 용도 |
|--------|----------------|------|
| `acceptStep()` | `antigravity.agent.acceptAgentStep` | 코드 수정 승인 |
| `rejectStep()` | `antigravity.agent.rejectAgentStep` | 코드 수정 거부 |
| `acceptTerminalCommand()` | `antigravity.terminalCommand.accept` | 터미널 명령 승인 |
| `rejectTerminalCommand()` | `antigravity.terminalCommand.reject` | 터미널 명령 거부 |
| `acceptCommand()` | `antigravity.command.accept` | 비터미널 액션 승인 |
| `rejectCommand()` | `antigravity.command.reject` | 비터미널 액션 거부 |

> **핵심**: Step control은 **vscode.commands**, rawRPC가 아님!

---

## 3. 파이프라인 테스트 (소거법)

### 파이프라인 구조
```
Extension step event → 텍스트 추출 → chat_snapshots/*.json 쓰기
→ Bot scanner (5초) → Discord 전송
```

### 테스트 결과

| Stage | 테스트 | 결과 |
|-------|--------|------|
| 1. Step 감지 | onStepCountChanged | ✅ step 1239 (+2) |
| 1. 등록 | register 파일 | ✅ e7b46728→gravity_control |
| 2. 텍스트 추출 | PLANNER_RESPONSE | ✅ 24 chars |
| 3. 파일 쓰기 | chat_snapshots/*.json | ✅ 파일 생성됨 |
| 4. Bot 스캔 | chat_snapshot_scanner | ✅ 정상 동작 (정상 JSON) |
| 5. Discord 전송 | 채널 전송 | ✅ 수동 테스트 파일 도착 |

### 핵심 문제 발견

**`getDiagnostics.recentTrajectories.lastStepIndex`가 실시간 업데이트되지 않는다.**

Console POLL 데이터:
```
[POLL#1] e7b46728 steps=1237 known=0 "Debugging Discord Bridge"
[POLL#2] e7b46728 steps=1237 known=0 "Debugging Discord Bridge"
```

- `steps=1237` — getDiagnostics에서 반환하는 lastStepIndex
- 실제로는 1239+ steps가 존재 (step event는 1239 감지)
- 이후 대화 턴에서 step이 계속 추가되지만 `lastStepIndex`는 1237에서 변하지 않음
- 결과: SDK EventMonitor가 변화를 감지 못함 → `onStepCountChanged` 미발생

### `known=0` 문제
- POLL에서 `known=0` = `lastSeenStep` 맵이 비어있음
- step event에서 `lastSeenStep.set()`이 실행되어야 하지만, 
  one-time full dump의 async 대기 중에 POLL이 먼저 실행될 수 있음
- MISSED STEPS 복구 조건이 `known > 0`이라 초기 상태에서 작동 안 함

---

## 4. 남은 문제 & 다음 단계

### 근본 원인
`getDiagnostics`의 `lastStepIndex`가 실시간 반영되지 않아
SDK EventMonitor의 trajectory polling이 새 step을 감지하지 못함.

### 적용된 해결책 (2026-03-08 06:55)

**PRIMARY RELAY 완전 재작성**: `getDiagnostics` 의존 제거, 직접 `rawRPC` 폴링

```
setInterval (5초마다):
  1. getDiagnostics로 active session ID 확보 (초회 + 60초마다 갱신)
  2. rawRPC('GetCascadeTrajectorySteps', {cascadeId, startStepIndex}) 직접 호출
  3. step count 변화 감지 → 새 step 추출
  4. PLANNER_RESPONSE → chat_snapshots (AI 응답)
  5. NOTIFY_USER → chat_snapshots (알림)
  6. TASK_BOUNDARY → chat_snapshots (작업 상태)
  7. WAITING → pending approval (승인 대기)
```

이 방식은 `getDiagnostics.lastStepIndex`의 stale 문제를 완전히 우회함.

### 추가 발견 (2026-03-08 07:10)

**rawRPC `GetCascadeTrajectorySteps` 775-step 한계**

- RPC는 항상 **최대 775 steps** 반환 (0-774)
- `startStepIndex` 파라미터가 **무시됨** — 항상 처음부터 775개
- 현재 대화가 1275+ steps이면, steps 775-1274는 접근 불가
- 마지막 PLANNER_RESPONSE (24 chars)가 step 774의 오래된 텍스트

**수정**: getDiagnostics로 step count 변화 감지 (3초 폴링) + rawRPC는 content 조회용으로만 사용.
`currentMax` 계산 버그 제거 — getDiagnostics.lastStepIndex를 직접 비교.