@jimmy_harika/websitekit

Carrd simplicity × Payload-like power-ups. One shared, block-agnostic, curated-section engine for every Snow Labs app — and the rails for website agents (structured JSON, catalogs, MCP/SDK next).

| Doc | Audience | |-----|----------| | PRODUCT-PUBLIC.md | Agents & integrators — what it is, capabilities, new model, import map | | CHANGELOG.md | What shipped per version | | PRODUCT.md | Internal vision + backlog | | CLAUDE.md | Coding-agent rules for this repo | | PREREQUISITES.md | Host shadcn tokens for editor chrome |

New blocks, catalogs, and verticals land here and upgrade all consumers at once.

Consumers (keep them in sync)

| App | Repo | Job | |---|---|---| | pixbox studio Website tool | convex-pixbox (apps/pixbox) | Multi-page photographer portfolio | | guestcard event websites | convex-pixbox (apps/invite) | Per-event invite / event site | | Future (authors, vendors, …) | other apps | Same engine, own catalog + persistence |

Release path (every shared fix/feature):

1. Land change in this repo (src/) — not in a consumer’s node_modules fork.
2. bun run typecheck → npm version patch|minor|major → npm publish.
3. In each consumer monorepo, bump "@jimmy_harika/websitekit": "^x.y.z" on all apps that depend on it (pixbox + invite together), then bun install.

Local dual-dev (iterate without publishing every minute): from the consumer monorepo root,

bun add @jimmy_harika/websitekit@link:../websitekit --filter <app>

Restore the published ^x.y.z before merge. App-only glue (Convex adapters, plan gates, SEO Manager UI, image upload) stays in the consumer — never pull app UI or Convex into this package.

Why custom (not Puck / GrapesJS)

The engine is the product. Curated sections (not freeform grids) keep sites beautiful-by-default for non-designers, and the same component renders in the editor canvas and in production (an injected edit prop makes fields inline- editable; production omits it for a byte-identical static render) — an RSC + CDN perf moat heavy runtimes can't match.

Layers

| Export | What | |---|---| | @jimmy_harika/websitekit | Core model · registry · theme (RSC-safe) | | @jimmy_harika/websitekit/editor | <PageBuilder> client editor | | @jimmy_harika/websitekit/renderer | PageRenderer / PageFonts (RSC-safe production render) | | @jimmy_harika/websitekit/store | zustand + zundo store | | @jimmy_harika/websitekit/blocks | Design-system-agnostic blocks (--pb-* tokens) | | @jimmy_harika/websitekit/powerups | Founder OS power-up registry (EmailMate, SupportMate, domains, …) | | @jimmy_harika/websitekit/agent | Pure agent ops: brand-fill, patch section, enable power-up | | @jimmy_harika/websitekit/catalogs/author | Author catalog + templates | | @jimmy_harika/websitekit/catalogs/publisher | Publisher catalog + templates | | @jimmy_harika/websitekit/catalogs/generic | SMB shell catalog + Launch/Solid templates |

The app contract

A consuming app supplies only:

1. A catalog (or use a shipped one from ./catalogs/*).
2. A persistence adapter — load → PageDocument or SiteDocument, save, publish.
3. uploadImage(file) => Promise<url>.
4. A data-source resolver — pre-resolve "live" block props (e.g. an author's real books) from the app's own backend before render.
5. Power-up backends (optional) — EmailMate, SupportMate widget, CF domains, form actions. Engine only stores SiteDocument.powerUps[] + registry metadata.

import { PageBuilder } from "@jimmy_harika/websitekit/editor";
import { AUTHOR_CATALOG, AUTHOR_TEMPLATES } from "@jimmy_harika/websitekit/catalogs/author";

<PageBuilder
  catalog={AUTHOR_CATALOG}
  templates={AUTHOR_TEMPLATES}
  initialDocument={doc}
  onChange={autosave}
  onPublish={publish}
  uploadImage={upload}
/>;

// production (RSC)
import { PageRenderer, PageFonts } from "@jimmy_harika/websitekit/renderer";
import { AUTHOR_CATALOG } from "@jimmy_harika/websitekit/catalogs/author";

<>
  <PageFonts doc={doc} />
  <PageRenderer doc={doc} catalog={AUTHOR_CATALOG} />
</>;

Consuming app notes

• The package ships raw TS/TSX — add @jimmy_harika/websitekit to your Next transpilePackages, and ensure a single React copy (dedupe via your bundler's resolve alias).
• zod is a peer (v3 or v4). Catalogs authored here use the repo's zod; apps on a different major only need the obj() cast bridge if they author their own catalog.
• The editor chrome (@jimmy_harika/websitekit/editor) is styled with shadcn/ui semantic utilities and reads the host's shadcn theme. If your app doesn't use shadcn/ui, see PREREQUISITES.md for the required CSS variables. Rendered sites and blocks are portable and do not depend on shadcn.

Roadmap

See PRODUCT.md backlog (P0–P3).

• Catalogs: author · publisher · generic (shipped) → photographer → trucking / cards.
• Power-ups: EmailMate · SupportMate · GrowthMate · BlogMate · domains (host-wired).
• Agent: MCP + SDK over agent.ts pure ops.
• Backend: Convex component + Cloudflare for SaaS domains.
• Dogfood: BookStand landings → public template gallery.