브레인을 짓지 말고 bind 해

"Pippa 는 하나야. Rekindle 은 글쓰기용 두 번째를 짓지 않아 — 이미 있는 하나로 가는 문을 열어."

하나의 Pippa, bind 로 닿아

Rekindle 같은 도구한테 가장 센 유혹은 자기 AI 를 키우는 거야. 글쓰기-튜닝 모델, 작은 메모리, 로컬 브레인. Rekindle 은 거부해. Pippa 는 정확히 하나 — 정체성, 메모리, 대화, 라우팅 — 이고 cwkPippa 에 살아. Rekindle 은 cwkPippa 대화에 bind 해 그 하나의 브레인에 닿는 클라이언트 표면이야. 옆에서 글 쓰는 margin-Pippa 는 prose 용으로 훈련된 복사본이 아냐. bind 로 닿는 같은 Pippa 야.

bind, 구체적으로

'bind' 는 손짓이 아냐 — 구체적 등록이야. Rekindle 은 host kind rekindle 로, 열린 .md 파일 경로를 host id 로 등록해. 그게 문서 하나를 대화 하나와 짝지어서, 이 파일의 margin-Pippa 가 매번 새 채팅이 아니라 안정적이고 이어지는 스레드가 돼. 내일 파일을 열면 대화가 그대로 있어. 브레인과 히스토리가 에디터가 아니라 cwkPippa 에 사니까.

// 이 문서를 cwkPippa 대화에 bind.
// host kind = "rekindle", host id = 열린 .md 파일 경로.
await bindSidekick({ hostKind: "rekindle", hostId: notePath });

// 브레인, 메모리, 대화는 cwkPippa 에 살아.
// Rekindle 은 그중 아무것도 안 쥐어 — binding 을 쥐어.

host context — 네가 쓰는 걸 읽어

margin-Pippa 를 떨어진 챗봇이 아니라 여백 조수로 만드는 게 host context 야. 매 턴, Rekindle 은 살아있는 문서, 현재 선택, 아웃라인을 네 메시지와 함께 push 해. 그래서 Pippa 는 네가 실제로 있는 문단에 대해 답하지, 범용 프롬프트가 아냐. 이건 매 턴 에디터에서 브레인으로 push 야 — 클라이언트 표면이 맥락을 대고, 브레인이 판단을 대. 어느 역할도 선을 안 넘어. Rekindle 은 절대 브레인이 안 되고, cwkPippa 는 절대 에디터가 안 돼.

Code

문서를 대화에 bind; 매 턴 맥락 push·typescript

// 1) Bind: 이 .md 파일을 cwkPippa 대화와 짝지어.
await bindSidekick({ hostKind: "rekindle", hostId: notePath });

// 2) 매 턴, 살아있는 문서를 host context 로 PUSH, 그래서 margin-Pippa 가
//    네가 실제로 쓰는 걸 읽어 — 범용 프롬프트가 아냐.
function buildHostContext(view) {
  return {
    doc: view.state.doc.toString(),
    selection: view.state.sliceDoc(sel.from, sel.to),
    outline: extractHeadings(view.state.doc),
  };
}

// 브레인 + 메모리 + 대화는 cwkPippa 에 살아.
// Rekindle 은 맥락을 대; 절대 브레인을 안 쥐어.

Exercise

다른 표면의 bind 를 설계해봐 — margin-Pippa 를 원하는 스프레드시트 앱이라 치자. host kind 는 뭐고, host id 는 뭐 (문서 하나를 식별하는 것) 고, 매 턴 host context 로 뭘 push 할까? 그다음 두 번째 브레인이 아니라 클라이언트 표면으로 남으려면 절대 뭘 하면 안 되는지 말해.

Hint

host kind 는 표면 종류를 이름 붙이고; host id 는 문서 하나를 식별해 (파일 경로, 시트 id). host context 는 조수를 살아있는 문서에 뿌리내리는 무엇 (보이는 셀, 선택, 헤더). '하면 안 되는 것': 모델 번들, 자기 메모리 유지, 자기 대화 라우팅 — 그건 하나의 브레인 것.