The Seed Workspace exists so the reference application, tests, and screenshots all start from the same realistic state. It is not demo data — it is committed source the rest of the starter depends on.
What it contains
- One workspace (
starter-lab) with three members in three Workspace Roles (one owner, one admin, one member) - Seeded API Tokens, Webhook Endpoints, and Notifications for the workspace
- An Onboarding Checklist that reads three of four steps done: members, an API Token, and a Webhook Endpoint exist, while the demo owner's account has no two-factor yet (the plan step only appears when billing is configured)
- One finished Workspace Export (
exp_seed_ready), downloadable through the API worker's signed route, so the settings page and the export flow have something to show without R2 (in-memory Seed layer only — the D1 seed writes no export row, since there is no artifact for it in a bucket)
When it runs
bun run db:seed invokes scripts/seed.ts. The script collects the fixture from the seed capability layer and writes it to D1 with INSERT OR REPLACE, so re-running resets the workspace to a known shape without duplicating rows.
Why it matters
Wide-event observability, the REST + MCP surfaces, and the home-page architecture showcase all assume a Seed Workspace exists. Skipping the seed makes the starter render empty states everywhere and obscures what the starter actually ships.