Castbook

Castbook is the registry for the reference characters I reuse across generative work — the clay-rendered version of me, a storybook character, a mascot — so that I define an identity once and reuse it everywhere instead of re-coaxing it out of a fresh prompt each time. It started life over-engineered, as a professional provenance-and-consent system with origins, canonical assets, transformation recipes, and generation-request lineage. The course-correction was to build what I actually wanted: a polished, consumer-friendly shelf. A character is a card, a version is an image, one version is marked current, and the thing you copy-paste is the reference prompt attached to it.

The clean cut was a single migration that dropped five lineage tables and their join tables and folded a reference_prompt text field and a current_asset_id pointer onto representations, backfilling both from the old structure so the existing characters survived the surgery. The MCP slimmed from eight tools to five read-only ones, because curation belongs in the UI and retrieval belongs in the tool surface. The web admin got rebuilt in a cerulean-and-gold editorial dark theme with a gallery, a character detail view, and a new-character flow that includes a prompt helper.

Architecturally it matches the rest of my MCP fleet exactly — three repos: a domain service that owns Postgres and object storage and the web UI, a thin TypeScript MCP server that’s an HTTP client to that API, and a Cloudflare Worker that puts an OAuth 2.1 gate in front so a remote agent on claude.ai or ChatGPT can reach it without touching the tailnet. The lesson Castbook keeps reinforcing is the one about altitude: the layered Identity → Representation → Asset model still exists under the hood, but the UI only ever shows characters and versions, because the right abstraction for the builder is not always the right one for the person using it.