docs(plan): switch decision #1 to selfbot protocol-level stream receive

User rejected browser/screenshot capture: they want to actually receive the
real-time screen-share stream like a real client. Research confirms this needs a
selfbot (user token) via discord.js-selfbot-v13 (werift-rtp) exposing incoming
video RTP (receiverData/hasVideo, VoiceReceiver, StreamConnection); decode via
libsodium decrypt + depayload + ffmpeg. Records ToS/ban risk and that no
turnkey receive->frames library exists. Xvfb browser PoC demoted to fallback.

PLAN.md

@@ -4,12 +4,14 @@
 
 ## 확정된 결정 (2026-08-09)
 
-1. **캡처 방식 (눈)** — 봇 프로토콜 수신/셀프봇 ❌.
-   .9 서버에 **가상 디스플레이(Xvfb) + 진짜 디스코드 클라이언트(웹 Chromium)** 를 띄우고,
-   상대의 공유 스트림 화면을 **프레임으로 캡처**한다.
-   - 근거: Discord 공식 봇은 비디오 송수신을 모두 막음. 셀프봇 수신 라이브러리는 없고(있어도 송출 전용) 유저토큰 필요 → 밴 위험.
-   - 진짜 클라이언트가 스트림을 정상 디코딩/렌더 → 우리는 그 픽셀만 읽음. 무인 서버 실행 가능.
-   - WebRTC 특성상 완전 `--headless` 불가 → Xvfb 가상 X 서버 필요.
+1. **캡처 방식 (눈)** — 사용자 요구: 스크린샷/브라우저 캡처 ❌,
+   **실제 실시간 화면공유 스트림 자체를 진짜 클라이언트처럼 수신**해야 함.
+   → **셀프봇(유저 토큰)으로 프로토콜 레벨에서 비디오 RTP 스트림을 수신·디코딩**한다.
+   - 근거(원문 확인): Discord 공식 봇은 비디오를 완전 차단 → 봇으로는 불가. 반드시 유저 토큰(셀프봇) 필요.
+   - `discord.js-selfbot-v13`(werift-rtp 사용)이 수신 노출: `VoiceReceiver`(수신 스트림 레코딩), `StreamConnection`(스크린셰어), `receiverData` 이벤트(ssrcData: userId, **hasVideo**, RtpPacket). → 남의 화면공유 수신 기술적으로 가능.
+   - 수신 파이프: 셀프봇 join + Go Live "watch stream" 시그널링으로 비디오 SSRC 구독 → 암호화 RTP 비디오 수신 → 복호화(xsalsa20_poly1305/libsodium) → depayload(VP8/H264) → ffmpeg 디코드 → 프레임.
+   - 위험/제약: (a) 유저 토큰 = **Discord ToS 위반, 계정 밴 위험** → 반드시 버리는 계정 사용. (b) 완성형 "수신→프레임" 라이브러리는 없음, 조립 필요. (c) 주력 셀프봇 라이브러리는 2025-10 아카이브(read-only) → 프로토콜 변경 시 깨질 수 있음.
+   - ❌ 폐기: Xvfb + 브라우저 캡처(스크린샷) 방식 — 사용자가 명시적으로 거부. `poc/`는 참고용 폴백으로만 남김.
 2. **대화 방식** — 음성 실시간. STT→LLM→TTS 스트리밍으로 지연 최소화, 사용자 인터럽트 지원.
 3. **두뇌** — Claude **OAuth**로 가장 싸고 빠른 모델(Haiku 계열).
    + .9의 RTX 5050으로 소형 로컬 VLM을 돌려 매 프레임 1차 이해·**화면 변화 감지**를 값싸게 처리,
@@ -18,16 +20,14 @@
 
 ## 단계별 착수 목록
 
-### 1단계 · 눈: 캡처 파이프라인  ← 지금
-- [x] 호스트 도구 확인 (Node/Xvfb/ffmpeg/google-chrome 존재)
-- [ ] **PoC: Xvfb에서 비-헤드리스 Chromium이 재생 화면을 렌더 → 프레임 캡처 검증** (최대 리스크 선제거)
-- [ ] 캡처 주기 + 프레임 변화 감지(동일 화면 반복 전송 방지)
-- [ ] 프레임을 파이프라인에 공급하는 소스 인터페이스
-
-### 2단계 · 디스코드 접속
-- [ ] Xvfb 크롬에서 Discord 웹 로그인 (별도 계정 권장)
-- [ ] 음성 채널 참여 + 상대 스트림 "보기" 클릭 자동화
-- [ ] 스트림 video 영역만 크롭 캡처
+### 1단계 · 눈: 화면공유 스트림 수신  ← 지금
+- [x] 호스트 도구 확인 (Node 22/ffmpeg/libsodium 가능)
+- [x] 수신 방법 조사 확정: 셀프봇 프로토콜 레벨 비디오 RTP 수신
+- [ ] **[블로킹] 버리는 디스코드 유저 계정 + 토큰 확보, ToS/밴 위험 수용 확인**
+- [ ] 셀프봇으로 음성채널 join → 상대 Go Live 스트림 watch/구독 (비디오 SSRC 획득)
+- [ ] 들어오는 비디오 RTP 수신 → 복호화 → depayload(VP8/H264)
+- [ ] ffmpeg로 디코드 → 프레임(JPEG/PNG) 추출 PoC (진짜 공유화면 수신 검증)
+- [ ] 프레임 변화 감지(동일 화면 반복 전송 방지) + 소스 인터페이스
 
 ### 3단계 · 두뇌 (하이브리드 비전)
 - [ ] 로컬 VLM(예: moondream2 / Qwen2-VL-2B) 프레임 1차 이해 + 변화 감지