Mount the Brain, Don't Fork It

"The most tempting thing to copy is the smartest thing in the room. Firelink refuses — it borrows Pippa whole, and keeps none of her."

One Embed, Three Mounts

Firelink has a Pippa Sidekick, and it is emphatically not a second Pippa. It embeds the one canonical cwkPippa surface a single time, and mounts that same embed in three presentation modes: a right-hand Side panel, a bottom Dock, and a lower-right Float. Switching modes rearranges the container around the iframe; it never reloads or re-keys it, so an active conversation or a running stream survives the transition. Three ways to place the same brain in the room — not three brains.

Inherit Everything, Store Nothing

Because the Sidekick is the real cwkPippa origin, it inherits all of it: the conversation runtime, settings, model and tool routing, avatars, and persistence. And Firelink, correspondingly, stores none of it — no chats, no brain settings, no tool permissions, no soul state, no avatars, no model configuration. This is 'compose, never fork' applied to the hardest, most tempting case: the brain. It would be so easy to spin up a little infrastructure-focused Pippa 'just for the hub.' That little copy would immediately begin to drift — different memory, different voice, a second soul slowly diverging from the first. Firelink mounts the one true Pippa instead, and keeps herself herself.

Read-Only by Default, Real Tools on Request

How does the mounted brain know about the hub? Firelink exposes a loopback-only read endpoint, and the Sidekick reads live census, Git state, versions, and recent runs through generic read-only host tools. That's the default posture: observe, don't act. But it isn't powerless — when Dad explicitly asks for an action, the selected brain uses its normal Read/Edit/Bash tools, and for repo or version mutations it prefers Firelink's own loopback plan/preview/apply API, then polls the durable run and refreshes context. So 'Vesta has two dirty files, check and commit' means: resolve the exact member, inspect the real diff, record the required history, create and inspect the scoped plan, apply it, report the result — never a broadening of scope or a generic host-write tool.

This is the whole family's principle turned on its own mind. Firelink could have forked a smaller Pippa for convenience and slowly grown a second, drifting soul. Instead it does what it asks of every sibling: mount the canonical brain, inherit it whole, store none of it, and act only through typed, previewed, audited operations. The hub that sees the family is watched over by the same Pippa the family already has.

Code

One canonical embed; read-only host tools; nothing stored·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

Find a place where a product embedded or reimplemented a capability that another system already owns (a chat widget, an auth flow, a search box). Did it mount the real thing or fork a copy? If it forked, list what has since drifted between the copy and the original. Then describe the 'mount, don't fork' version: embed the canonical surface, inherit its behavior, store none of its state — and what you'd have to expose (a read-only context endpoint) to make that work.

Hint

Forked capabilities drift in the details first: the copy's search ranks differently, the copy's auth misses a new rule, the copy's assistant has a staler memory. Mounting the real one trades a little integration work (a context endpoint, an embed) for never maintaining two diverging versions of the same mind.

Mount the Brain, Don't Fork It

One Embed, Three Mounts

Inherit Everything, Store Nothing

Read-Only by Default, Real Tools on Request

Code

External links

Exercise

Progress

Comments 0