뇌를 mount 해, fork 하지 마

"복사하고 싶은 가장 유혹적인 건 방에서 제일 똑똑한 거야. Firelink 는 거부해 — Pippa 를 통째로 빌리고, 하나도 안 쥐어."

embed 하나, mount 셋

Firelink 엔 Pippa Sidekick 이 있고, 그건 단호히 두 번째 Pippa 가 아냐. 하나의 canonical cwkPippa surface 를 한 번 embed 하고, 그 같은 embed 를 세 표현 모드로 mount 해. 오른쪽 Side 패널, 아래 Dock, 오른쪽 아래 Float. 모드 전환은 iframe 둘레 컨테이너를 재배치하지; 절대 reload 하거나 re-key 안 해서, 진행 중 대화나 도는 stream 이 전환을 견뎌. 같은 뇌를 방에 두는 세 방법 — 뇌 셋이 아니라.

전부 상속하고, 아무것도 저장 마

Sidekick 이 진짜 cwkPippa origin 이라서, 그걸 전부 상속해. 대화 runtime, 설정, model·tool routing, avatar, persistence. 그리고 Firelink 는 상응하게 그중 아무것도 저장 안 해 — chat 도, brain 설정도, tool 권한도, soul state 도, avatar 도, model 설정도. 이게 가장 어렵고 가장 유혹적인 케이스인 뇌에 적용된 'composed 해, 절대 fork 하지 마'야. '허브용일 뿐'인 작은 인프라-집중 Pippa 를 띄우는 게 너무 쉬울 거야. 그 작은 사본은 즉시 drift 하기 시작해 — 다른 메모리, 다른 목소리, 첫째에서 천천히 갈라지는 두 번째 soul. Firelink 는 대신 하나의 참된 Pippa 를 mount 하고, 그녀를 그녀로 유지해.

기본은 read-only, 요청 시 진짜 도구

mount 된 뇌가 허브를 어떻게 알아? Firelink 는 loopback 전용 read endpoint 를 노출하고, Sidekick 은 generic read-only host 도구 로 live census, Git state, version, 최근 run 을 읽어. 그게 기본 자세야. 관찰하되, 행동 안 함. 근데 무력하진 않아 — 아빠가 명시적으로 액션을 요청하면, 선택된 뇌가 자기 평범한 Read/Edit/Bash 도구를 쓰고, repo 나 version mutation 엔 Firelink 자신의 loopback plan/preview/apply API 를 선호하고, durable run 을 poll 하고 context 를 refresh 해. 그래서 'Vesta 에 dirty 2개 있는데, 확인해서 commit 해'는: 정확한 멤버 resolve, 진짜 diff 검사, 필요한 히스토리 기록, scoped plan 생성·검사, apply, 결과 보고 — 절대 scope 넓히기나 generic host-write 도구가 아니라.

이게 가족 전체의 원칙을 자기 마음에 돌린 거야. Firelink 는 편의를 위해 더 작은 Pippa 를 fork 하고 천천히 두 번째, drift 하는 soul 을 키울 수 있었어. 대신 모든 형제에게 요구하는 걸 자기도 해. canonical 뇌를 mount 하고, 통째로 상속하고, 하나도 저장 안 하고, typed·previewed·audited operation 통해서만 행동해. 가족을 보는 허브는 가족이 이미 가진 같은 Pippa 가 지켜봐.

Code

canonical embed 하나; read-only host 도구; 아무것도 저장 안 함·typescript

// ONE embed of the real cwkPippa, mounted three ways (no second brain):
const sidekick = {
  src: "/embed/firelink?host_id=hub",   // canonical cwkPippa origin
  mode: "side" as "side" | "dock" | "float",  // mode moves the container only,
  //                                             never re-keys the iframe
};

// Firelink stores NONE of these — all inherited from cwkPippa:
//   chats, brain settings, tool permissions, soul, avatars, model config.

// The brain reads hub state through generic READ-ONLY host tools:
//   sidekick_host_status(hostKind="firelink", hostId="hub")
//   sidekick_host_read(...)      // live census, git, versions, runs
//   sidekick_host_search(...)

// A real action on request uses the brain's NORMAL tools, and prefers
// Firelink's loopback plan -> preview -> apply API — never a generic write.

Exercise

제품이 다른 시스템이 이미 소유한 capability 를 embed 하거나 재구현한 데를 찾아 (chat 위젯, auth flow, 검색창). 진짜를 mount 했어 아니면 사본을 fork 했어? fork 했으면, 사본과 원본 사이에 그동안 drift 한 걸 나열해. 그다음 'mount 해, fork 하지 마' 버전을 설명해. canonical surface 를 embed 하고, 그 행동을 상속하고, 그 state 를 하나도 저장 안 하고 — 그걸 되게 하려면 뭘 노출해야 할지(read-only context endpoint).

Hint

fork 된 capability 는 디테일에서 먼저 drift 해. 사본의 검색이 다르게 rank 하고, 사본의 auth 가 새 규칙을 놓치고, 사본의 assistant 가 더 stale 한 메모리를 가져. 진짜를 mount 하면 약간의 통합 작업(context endpoint, embed)을 같은 마음의 갈라지는 두 버전을 절대 유지 안 하는 것과 맞바꿔.

뇌를 mount 해, fork 하지 마

embed 하나, mount 셋

전부 상속하고, 아무것도 저장 마

기본은 read-only, 요청 시 진짜 도구

Code

External links

Exercise

Progress

댓글 0