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 이 아니라서 sync 유지할 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 코드 한 줄이야.