Files

CD 0c3d6cdb6d fix(bridge): step structure discovery + approval watcher + AI text relay

- plannerResponse.response = user-facing text field (confirmed)
- step.runCommand.commandLine = command (not toolCall.argumentsJson)
- Add response watcher: bridge/response/ → ResolveOutstandingSteps RPC
- Fix AI text: use modifiedResponse/response, last-wins, dedup
- Fix flooding: slice(-delta) to skip old steps on reload
- Bot: 404 cache invalidation for deleted Discord channels

2026-03-08 02:29:17 +09:00

1.6 KiB

Raw Blame History

Discord Bridge — Step 구조 파악 및 3대 기능 수정

시간: 2026-03-08 01:45~02:25
Commit: TBD (이 파일과 함께 커밋)

결정 사항

plannerResponse 구조 (확정)

GetCascadeTrajectorySteps RPC가 반환하는 PLANNER_RESPONSE step의 실제 구조:

plannerResponse: {
  response: "사용자 대면 텍스트",       ← 핵심 필드
  modifiedResponse: "수정된 버전",
  thinking: "내부 사고 (SKIP)",
  thinkingSignature: "암호화 해시 (SKIP)",
  messageId: "bot-xxx",
  toolCalls: [{name, argumentsJson}],
  thinkingDuration: "0.9s",
  stopReason: "STOP_REASON_STOP_PATTERN"
}

RUN_COMMAND 구조 (확정)

step.runCommand: {
  commandLine: "echo ...",           ← 핵심 필드
  proposedCommandLine: "echo ...",
  cwd: "c:\\Users\\...",
  waitMsBeforeAsync: "10000",
  blocking: true,
  autoRunDecision: "AUTO_RUN_DECISION_DEFAULT_DENY"
}

step.toolCall은 존재하지 않음 — step.runCommand에 직접 필드

startStepIndex 무시 문제

GetCascadeTrajectorySteps({ startStepIndex }) — API가 파라미터를 무시하고 전체 step 반환. 워크어라운드: allSteps.slice(-e.delta)로 마지막 N개만 처리.

승인 RPC

HandleCascadeUserInteraction → socket hang up (실패)
ResolveOutstandingSteps → 성공 (폴백으로 사용)

미완료

승인 버튼 Discord→Extension→LS 경로: HandleCascadeUserInteraction 파라미터 정확히 확인 필요
AI 텍스트: 긴 응답(4000자+)의 Discord 분할 표시 테스트 안됨
대화형 짧은 응답이 정상 전달되는지 최종 확인 필요

1.6 KiB Raw Blame History