Sidekick 계약

"하룻저녁 다섯 번의 필드 라운드가 '챗 패널 embed'를 모든 형제가 베껴야 할 계약으로 바꿨어."

embed는 iframe 한 줄이 아냐

journey Sidekick은 Waystone에 embed된 Pippa야. 작은 일처럼 들려. iframe 넣으면 끝. 현장은 동의 안 했어. 진짜로 써본 하룻저녁이, 통합을 4부 계약으로 단련시킬 만큼 깨짐을 만들었고, 미래 CWK 형제 웹 클라이언트는 그걸 다시 발견하는 대신 베껴야 해. 각 부분이 있는 건 그게 없어서 아빠 손에서 뭔가 깨졌기 때문이야.

네 부분

전용 embed host. Waystone은 cwkPippa 안에 자기 host 라우트랑 host kind를 가져. generic embed 패널은 다른 클라이언트의 사이드 패널 host라 아무한테도 안 맞아. 그리고 host-kind 검증은 뇌 코드에 게이트가 둘이야. 새 kind는 둘 다 통과해야지, 아니면 헷갈리는 데서 실패해.
host context용 pull adapter. cwkPippa가 Waystone 엔진에서 journey record랑 plan 문서랑 breadcrumb 스트림을 읽어서, Pippa의 sidekick tool이 여행 truth를 on-demand로 봐. Waystone의 host state가 텍스트라서 search가 진짜 search하고, 엔진 state가 절대 stale이 아니라서 맞춰둘 cursor가 없어.
Waystone이 소유한 window chrome. side랑 dock이랑 float 모드에 drag-resize, 기기별 persist. 결정적으로, 순수 resize는 iframe을 절대 remount 안 해서 대화가 살아남고, 모드 전환만 reload해.
v0엔 push bridge 없음. consultation은 pull해. live-document push bridge는 plan 공동 편집이 cursor 수준 context를 필요로 할 때 합류해. 잊은 게 아니라 의도적 부재야.

왜 여기선 pull이 push를 이겨

제일 교훈적인 선택이 네 번째야. Waystone state를 Pippa로 계속 push하는 게 더 세련돼 보일 거야. 근데 pull이 더 간단하고 엄격히 더 정직해. Pippa가 필요할 때 엔진한테 묻고, 엔진 답은 언제나 최신이거든. push는 뭘 보낼지, 언제 보낼지, 바뀌면 어떻게 무효화할지 정해야 해. 미묘하게 틀릴 기회가 셋. pull은 그 실패 모드가 하나도 없어. stale될 캐시 사본이 없으니까. 더 싼 설계가 drift할 수 없는 그것이기도 하면, 그걸 택해.

Code

4부 sidekick 계약·text

1. 전용 EMBED HOST          /embed/waystone + 'waystone' host kind
                            (generic 패널은 다른 클라이언트 거)
                            주의: host-kind 검증 게이트가 둘

2. PULL ADAPTER             cwkPippa 가 journey + plan + breadcrumb 을
                            Waystone 엔진에서, on demand 읽음
                            -> host state 가 텍스트라 search 가 진짜 search
                            -> 엔진이 절대 stale 아니라 cursor 없음

3. WAYSTONE 소유 CHROME     side / dock / float + drag-resize, 기기별
                            순수 resize: iframe remount 없음 (챗 살아남음)
                            모드 전환: reload

4. PUSH BRIDGE 없음 (v0)    consultation 은 PULL; live-document push
                            bridge 는 공동 편집이 필요할 때 합류

# pull 은 stale 될 수 없어. push 는 미묘하게 틀릴 방법이 셋.

Exercise

써본 embed 위젯을 생각해봐. 챗, 지도, 결제 폼. host 페이지가 resize하거나 re-render할 때 그 내부 state에 무슨 일이 일어나? 살아남아, 아니면 리셋돼? 이제 거기 AI 대화를 embed한다고 그려봐. 어떤 host 행동이 사용자가 한창인 챗을 조용히 파괴할까?

Hint

embed를 unmount하거나 re-key하는 건 뭐든 그 state를 파괴해. 그래서 '언제 remount하나?'가 디테일이 아니라 load-bearing 설계 질문이야. 대화를 지키는 resize랑 던져버리는 resize의 차이는 host 코드 한 줄이거든.