crewship seed

Replaces the old prisma/seed.ts script. Creates a demo environment — admin user, workspace, connected crews, agents with system prompts, credentials, integrations, routines, Pages, and executable issues — entirely through the REST API so business logic (validation, encryption, audit logging) is exercised end-to-end. The content is one fictional small business — Harbor Goods — told as four connected business stories, each run by one crew with local sample data and no third-party accounts: Sales (a customer inquiry waiting 26 hours), Finance (an overdue invoice among matched payments), Marketing (a contact-form submission that never arrived) and Shipping (a late parcel inside its claim window). Each story ships a TODO Issue, a Page and three routines — a deterministic check, an optional AI draft and a resolution that waits for a human before it saves anything. Crewship Lab adds real workspace telemetry and a bounded live container monitor. Every story can be run again and checked with crewship seed verify. The legacy external-source demo packs are no longer installed (see the demo packs guide), and synthetic model-regression routines stay out of the product demo (--with-evals).

crewship seed --server <url> [flags]

On a fresh database, seed bootstraps the admin user (demo@crewship.ai) itself. On an existing database, it requires authentication (run crewship login first) and a selected workspace. The server target must be explicit; seed does not infer it from .env.local, the working directory or an active default profile. Export a provider credential or pass a supported Codex login before running a functional demo. Use --offline-demo for an explicit control-plane fixture without model execution. The server may still build crew images automatically when their configuration is created; this option suppresses seed’s explicit provisioning requests and automatic model runs, rather than disabling the server’s image build queue. Bootstrap credentials are stored in a profile for the target server; unrelated default selections are preserved.

Flags

Flag	Default	Purpose
`--offline-demo`	`false`	Create a control-plane fixture without model credentials or execution. Incompatible with execution smoke tests, backup self-tests and Codex login. Supports `--with-memory` through the server API.
`--nuke`	`false`	Delete all workspace contents before seeding. Runs after auth, so a missing/invalid token won’t wipe the wrong workspace. Prompts for confirmation — see below.
`--yes`	`false`	Skip the `--nuke` confirmation prompt (for CI/scripts). Without it, an interactive nuke requires typing the workspace slug; a non-interactive session refuses to nuke unless `--yes` is set.
`--skip-issues`	`false`	Skip the issue/project/label phase. Useful when you only need crews + agents and want a faster seed.
`--with-evals`	`false`	Also install the synthetic model-regression routine catalogue. Intended for eval development, not the normal product demo.
`--password <pw>`	`password123`	Admin password used by bootstrap. The default is the dev convention `password123` — override in any non-local environment.
`--smoke-test`	`false`	After seeding, send a test prompt to each agent to verify end-to-end execution. Implies `--wait-provision`.
`--smoke-timeout <s>`	`60`	Per-agent timeout (seconds) for the smoke test.
`--provision-timeout <s>`	`900`	Per-crew provisioning timeout (seconds).
`--wait-provision`	`false`	Block until all crews finish provisioning. Default is fire-and-forget — seed returns while provisioning runs in the background.
`--test-backup`	`false`	After seeding, run a backup/restore round-trip self-test on one crew. Implies `--wait-provision`.
`--with-memory`	`false`	Initialize all demo memory tiers through the target server’s authenticated API before provisioning. Existing files and operator edits are preserved; a requested initialization failure stops the seed. No server memory is written on the CLI host.
`--with-team-chat`	`false`	Add six fictional colleagues with actual workspace roles, bundled portraits, a shared Chat channel and separately authored DMs. Requires OWNER and current create-only provisioning support; signup is not required.
`--state-dir <path>`	User configuration directory	Private owned-account state outside Git, separated by server/workspace. Passwords are random and never printed.
`--with-users`	`false`	Add four extra users (`ADMIN`, `MANAGER`, `MEMBER`, `VIEWER`) to the workspace for RBAC matrix testing. Uses authenticated member provisioning; public signup may remain disabled. New accounts redeem their setup token against the explicit target. Existing passwords are preserved. An incomplete four-role fixture fails.
`--codex-auth-file <path>`	`$SEED_CODEX_AUTH_FILE`	Absolute path to a private Codex `auth.json` (mode `0600`, outside the repo) holding a ChatGPT subscription login. Switches the demo agents from Claude Code to `CODEX_CLI` — see below. The flag overrides the exported variable; `dev.sh` can supply it from `.env.local`.

Set SEED_CODEX_AUTH_FILE to the absolute path of a Codex auth.json created by codex login. Keep the file outside the checkout with mode 0600. To leave .env.local untouched, pass the path for one CLI invocation — as an env prefix or as the --codex-auth-file flag, which overrides the variable:

SEED_CODEX_AUTH_FILE=/private/path/to/auth.json crewship seed --server http://localhost:8081
crewship seed --codex-auth-file /private/path/to/auth.json --server http://localhost:8081

For repeated ./dev.sh seed runs, put only the path in .env.local, never the JSON or one of its tokens. ./dev.sh seed loads .env.local and passes the path to the CLI:

# .env.local (only this path, never the auth.json contents)
SEED_CODEX_AUTH_FILE=/private/path/to/auth.json

./dev.sh seed

The seed checks the file before changing the workspace. It then creates an encrypted OpenAI PROVIDER_LOGIN in subscription mode, grants it to the nine seeded agents, configures those agents for CODEX_CLI, and uses an OpenAI login requirement and Codex model override in the model-backed routines. Crewship renders a per-agent auth.json with a placeholder refresh token at run time; the original refresh token stays in the server’s credential store. Without SEED_CODEX_AUTH_FILE, the original Anthropic seed behavior applies. An existing routine with the same slug is retained on re-seed, so use a fresh demo workspace when changing its provider. An existing seeded agent is updated to Codex when the path is set. The path must be readable by the user running the seed; it is never sent to Crewship, only the file content is sent through the authenticated credential API.

Examples

Business story issues

The Sales, Finance, Marketing and Shipping projects each hold one prepared Issue, bound to its story’s check routine and starting TODO. The intended loop is check → understand the finding → optionally draft → decide → inspect the receipt: the check publishes real script output to the story’s Page and comments on the Issue; Draft with AI is optional and separately visible; resolving waits for a human, and an approved completion saves a local outbox receipt and moves the Issue to DONE. Keeping a case open leaves it TODO.

Project	The check finds	The decision
Sales	Ava’s quote request, waiting 26 hours	Approve a reply into the local outbox
Finance	Invoice INV-103 for Northstar Studio, 7 days overdue	Approve a reminder; the debt remains unpaid
Marketing	Submission FORM-103, accepted but missing from the delivery log	Repair the local demo delivery
Shipping	Parcel SHIP-105, delivered two days late with the claim window closing	Approve claim evidence into the local outbox

The Crewship Lab project adds Inspect live crew CPU and memory: the collector reads real container CPU and memory per crew through a workspace-scoped sidecar read, and unavailable measurements stay unknown. Its live monitor Page samples real container memory every five seconds for at most 15 minutes and stops on request. No story contacts a real customer, carrier or provider: Finance completion records a reminder, not a payment; Shipping completion records claim evidence, not a paid refund; Marketing simulates local delivery only. The demo’s Inbox items have different sources: a story check completion writes a message to the triggering user, the Sales, Finance and Shipping resolutions park a waitpoint approval, and scripts/demo/run.sh chat-reply-inbox verifies a fourth path: an agent’s saved Chat reply becomes a message under Agent replies when the recipient is not watching that chat live. A missing integration does not currently create a dedicated integration-kind Inbox item; the demo must not present one as real.

First run on a fresh dev DB

crewship seed
# Bootstrapping...
#   Using dev default admin password: password123
#   (override with --password for production)
#   Bootstrapped admin: demo@crewship.ai
#   Workspace: w_abc123
# …
# Provisioning 3 crew(s) in the background.
#   Agents in these crews become runnable once provisioning finishes (~few minutes).
#   Status: crewship crew provision status <slug>   (or re-run `crewship seed --wait-provision`)
#
# ✓ Seed complete: 3 crews, 9 agents
# Login: demo@crewship.ai / password123

The token + workspace are saved to ~/.crewship/cli-config.yaml, so any follow-up command picks up the demo session.

Reset and reseed

crewship seed --nuke
# ⚠️  NUKE permanently deletes ALL contents of workspace "Acme Engineering" (acme)
#     on https://crewship-dev2.example — 4 crew(s), 12 agent(s), plus every
#     issue, project, label, pipeline, schedule, webhook, credential, inbox item,
#     and escalation, and each crew's docker container(s)+volumes (cached images
#     are kept). This cannot be undone.
#
# Type the workspace slug "acme" to confirm the wipe: acme

seed --nuke is an alias for crewship nuke all — the full teardown: DB entities plus inbox items, escalations, and each crew’s docker container(s)+volumes. Cached devcontainer images are preserved, so the reseed reuses them instead of forcing a rebuild. Use the nuke subcommands directly when you want to clear just one thing (e.g. crewship nuke inbox --kind failed_run to drop failed-run spam without touching data). Wipes the active workspace’s contents first, then seeds. Two guards:

Auth before nuke — the auth step runs before --nuke, so a typo in --server or a stale token fails before anything is deleted (it can’t trash a different workspace).
Typed-slug confirmation — --nuke prints a blast-radius summary (workspace, server, crew/agent counts) and requires you to type the workspace slug exactly before it proceeds. This is the guard against an accidental wipe of the intended workspace.

For CI or scripted resets, pass --yes to skip the prompt:

crewship seed --nuke --yes

In a non-interactive session (no TTY), --nuke refuses to run unless --yes is given — it never wipes unattended on a guessed confirmation.

--yes removes the only interactive safety on the most destructive command in the CLI. Reserve it for automation against throwaway/dev instances; never wire it into a script that could point at a real workspace.

CI-friendly run that waits

crewship seed --wait-provision --smoke-test

Blocks until every crew is provisioned, then sends one prompt to each agent. Non-zero exit on any failure — drop straight into pnpm test:e2e after this lands.

Skip the issue phase for a faster crew-only seed

crewship seed --skip-issues --password "$(op read op://Dev/crewship/admin)"

The issue/project/label phase is the slowest because it inserts dozens of rows and creates realistic issue backlogs; --skip-issues halves wall-clock time for crew-development work.

Backup self-test (CI guardrail)

crewship seed --test-backup

Implies --wait-provision. Picks the first crew that successfully started provisioning, runs a backup/restore round-trip via the admin self-test endpoint, and fails the command if the canary doesn’t verify. Use as a CI guard for the backup pipeline.

crewship seed verify

Runs the four local business stories end to end against the live workspace and checks what they produced: delivered files, check routines, Page provenance, Issue assignment and Inbox notifications. No AI credential is needed — the verifier drives the same scripts and the same public API as the Pages. This is the acceptance test for the seed: a story is only worth shipping if it can be run again tomorrow and be shown to be right.

crewship seed verify [flags]

Flag	Default	Purpose
`--complete-demo`	`false`	Also approve the local demo actions and verify completed Issues and outbox artifacts. Changes demo state — use a disposable demo workspace for this mode.
`--pack <slug>`	(none)	Verify the legacy external packs instead of the business demo (repeatable): `ci-watch`, `docs-drift`. The packs are no longer installed by `crewship seed`; this explicit path is for workspaces that still carry them.
`--timeout <duration>`	`30m`	Maximum wait per routine run.
`--strict`	`false`	Treat a skipped check as a failure — for a scheduled run that must not quietly pass.
`--skip-report`	`false`	(legacy packs only) Check files and probes only; do not run the agent report routines (no tokens spent).
`--repo-dir <path>`	current directory if it is a git checkout	(legacy packs only) Local checkout used to fact-check the paths the docs-drift review cites, at the commit the scan read.

For each story the default mode reports one row per step:

Step	What passes
`crew`	The story’s crew exists.
`files`	Every delivered story file (`story.py`, `catalogue.json`, `connector.py`, `live.py`) is byte-identical to the one in the binary. A crew running an older script is a failure, not a warning — the apply path reports success even when a runtime-owned file could not be overwritten.
`check routine`	`demo-<story>-check` runs to completion.
`check outcome`	The run’s authoritative outcome is `SUCCEEDED` with no error — technical completion alone is insufficient, because a missing agent hand-off can leave `completed` next to `FAILED`.
`Page provenance`	The `records` and `finding` panels of the story’s Page carry this run’s id.
`checked records`	The inspect step names its Issue and returns the expected number of sample records.
`Issue assignment and comment`	The Issue belongs to its story crew, is assigned to its agent and already carries the check comment.
`Inbox notification`	The `<Project>: check completed` notification landed after the run started.

With --complete-demo, each story additionally resolves and approves the local demo action, then verifies the resolution outcome, the outcome and resolved-records Page panels, the Issue moving to DONE, and the local evidence: shared/demo/business/outbox/<story>.json must match its story and Issue, carry the proposed text and the local demo only delivery label, and include the source finding it was built from. Exit status is 1 when any check fails; with --strict, when any is skipped too. --format json (or yaml / ndjson, the same object) prints the rows under checks plus the passed / failed / skipped / strict totals for a script to read; the progress lines stay on stderr.

crewship seed verify --timeout 2m
crewship seed verify --complete-demo --timeout 2m   # disposable workspace only
crewship seed verify --pack ci-watch --timeout 20m  # legacy pack
crewship seed verify --format json --strict

The legacy pack path keeps its own contract (probe verdicts against an independent GitHub read, COUNTS: reconciliation, cited-path fact-checks). Its independent read takes the first of SEED_GITHUB_TOKEN, GH_TOKEN, GITHUB_TOKEN set in the verifier’s own environment; only SEED_GITHUB_TOKEN satisfies a pack’s env gate.

Seed phases (in order)

Phase	What it does	Failure mode
1. Bootstrap / auth	Hits `/api/v1/bootstrap` on a fresh DB; falls back to existing CLI token	Fatal
0. Nuke (if `--nuke`)	Wipes workspace contents	Fatal
1b. RBAC users (if `--with-users`)	Adds four extra members (`ADMIN`/`MANAGER`/`MEMBER`/`VIEWER`) before crews land	Fatal if any role is missing; individual failures are reported, existing passwords and roles are preserved
2. Crews + members	Creates three crews — Sales & Shipping, Finance & Marketing, Operations (plus the optional Local AI crew) — and links the admin user	Fatal
2a. Crew connections	All-pairs bidirectional `crew_connections` so missions can hand off	Non-fatal (logs and continues)
2c. Demo story files	Delivers the business-story scripts and fixtures to each crew’s shared volume (`shared/demo/business/…`) plus the Crewship Lab collector (`shared/scripts/…`) — before provisioning, while the host can still write the tree	Fatal; `seed verify` also compares the delivered bytes with the seed
2b. Provision crews	Triggers devcontainer image builds in parallel	Errors deferred to end
3. Agents	Inserts agents with system prompts, then a follow-up `PATCH` for the columns `POST /api/v1/agents` does not model — suggested questions and ask forms (see below)	Fatal
3b. Agent memory (if `--with-memory`)	Initialize every demo tier on the target server before provisioning; existing memory remains unchanged	Fatal on initialization failure
4–5. Skills + assignments	Workspace skills + per-agent skill bindings	Fatal
6–7. Credentials + assignments	Model login for the agents (Codex `auth.json` or the Anthropic key; optional Google, GitHub and Ollama credentials) + per-agent bindings, then the demo vault’s two inert examples (an SMTP relay and a webhook signing secret)	Fatal for the model login; demo vault entries are non-fatal
8–9. Integrations + bindings	One `harbor-goods` MCP server per crew — a local stdio connector (`connector.py` on the crew’s shared volume) exposing the demo records to agents	Fatal
9b. Business routines + Crewship Lab	Twelve story routines (check, optional AI draft and resolve per story), the Lab telemetry collector and the live monitor start/stop controls	Fatal — a failed starter definition aborts the seed instead of leaving broken Page actions
9c. Keeper watchdog	Leaves the sampled-behaviour watchdog OFF unless a working judge endpoint and model are configured	Non-fatal by construction
Schedules	The normal seed creates no cron schedules. Create one explicitly after checking a routine, or use `crewship digest enable` for the workspace digest.	—
10. Issues	One TODO Issue per story plus the Crewship Lab issue, with their projects and labels (unless `--skip-issues`)	Fatal
10c. Pages	Six Pages (one per story, Crewship Lab, live monitor), their story folders and visual identity, demo payloads, then one run of every routine a panel names as producer	Fatal on spec, non-fatal per run
10b. Wait for provisioning	If `--wait-provision`, blocks until images are ready, then refreshes the Crewship Lab telemetry once the Ops sidecar exists	Fatal in sync mode, deferred otherwise
10c. Backup self-test	If `--test-backup`, full round-trip on one crew	Fatal
11. Summary	Prints `Seed complete: N crews, M agents`	—
12. Smoke test	If `--smoke-test`, one prompt per agent	Fatal on any failure

The async-by-default model means a plain crewship seed returns quickly (~seconds for the API mutations) while crew containers warm up in the background. Pair with crewship crew provision status <slug> to check on individual crews.

What the seeded chat surface shows

A fresh workspace is meant to demonstrate the chat features, not ship them switched off, so every one of the nine default agents arrives pre-configured with the same three suggested questions, worded for its role — what the role does in this demo, the sample records and the next action, and what happened in the latest routine run:

Agent	Suggested questions	Ask form
Alex, Sam, Robin, Jordan, Morgan, Riley, Taylor, Jamie	Three role-worded questions each (demo role, sample records and next action, latest routine run)	—
Casey (Marketing Assistant)	The same three, for marketing	Investigate a missing inquiry

Investigate a missing inquiry is the seeded ask form: the submission ID, the expected destination, what happened, and an optional screenshot — four fields across three field types, including the photo upload, on the agent whose story is a contact form that lost a delivery. Preview it without a browser:

crewship agent ask-preview casey check-form \
  --var record=FORM-103 \
  --var destination="Demo sales inbox" \
  --var problem="The form was accepted but the inquiry never arrived." \
  --var screenshot=IMG_4821.heic

Both columns are edited afterwards like any other agent field — crewship agent update <slug> --suggested-prompts/--ask-forms, or the agent’s config tab. The definitions live in cmd/crewship/seeddata/builtin/agents.yaml and cmd/crewship/seeddata/askforms/*.json; the seed’s own tests validate every form against internal/askforms before it can ship, so an invalid one is a red go test rather than a 400 mid-seed.

POST /api/v1/agents does not model suggested_prompts or ask_forms — a create carrying them returns 201 and drops them. The seed therefore issues one follow-up PATCH per agent that has either, which is also how the manifest importer handles it (crewship apply). The PATCH runs on a re-seed too, so an existing demo workspace picks the values up on the next crewship seed.

Common errors

bootstrap request failed (is the server running at http://localhost:8080?) — the server didn’t answer. Start it with crewship start and retry.
**DB already initialized. not logged in — run \crewship login` first** — the database has a user but the CLI has no token. Log in (or use crewship admin reset-password` if you’ve lost UI access).
--test-backup requested, but no crew successfully started provisioning — every crew failed to trigger provisioning. The seed wasn’t going to be useful anyway; the explicit error is so CI doesn’t go green on a broken pipeline.
demo file delivery: … — fatal. The story scripts and fixtures must land on the crews’ shared volumes before provisioning (while the host can still write the tree); a demo without them has only broken buttons.
demo routines: … / demo seed incomplete: N starter routines failed — fatal. A routine definition that cannot be saved leaves broken Page actions behind, so the seed aborts instead of finishing around it.

crewship seed team-chat

Add the same Chat demonstration to an existing workspace without running the full crew/routine seed or changing its owner:

crewship seed team-chat
crewship seed team-chat --state-dir /private/crewship-team-demo
crewship seed --with-team-chat

Thomas (ADMIN), Paul and Anna (MANAGER), Peter and Sofia (MEMBER), and Emma (VIEWER) are explicitly fictional demo accounts. Their email addresses include a stable workspace suffix, so independent demo workspaces do not reuse global accounts. Each user signs in normally, gets a bundled PNG portrait if their avatar is missing, and authors their own example DM and channel message. The shared channel is Team lounge · demo. No agent is invoked and no issue is created. Workspace roles are real: VIEWER has restricted work-management powers, but the current Chat policy allows viewer participation. The server must advertise create_only provisioning in its OpenAPI schema. Account setup uses owner provisioning and its setup token, without signup or email delivery. Existing accounts without locally owned state are rejected; changed roles or passwords are never overwritten. Owner profile and permissions remain unchanged. A rerun preserves personalized demo names/avatars and uses stable message IDs, avoiding duplicate messages or DMs. The private state directory is isolated by server and workspace, with mode 0700 and an atomically written 0600 JSON file. It contains generated passwords; keep it outside Git. JSON output includes only account IDs, roles, room IDs and the protected file path. Concurrent seeds fail on an exclusive state lock. After an interrupted process, inspect the reported lock before removing it. A lost initial provision or channel-creation response fails closed rather than claiming an unrelated account/room. Successfully configured accounts are recovered only by normal login; missing workspace membership can then be restored without a password reset. ./dev.sh seed includes this Chat pack by default. The direct crewship seed command keeps the flag opt-in; legacy --with-users remains the separate four- account RBAC fixture. Fresh account setup and login respect the server’s auth rate limit. On 429, only these auth requests retry, using the server’s Retry-After (up to one minute per wait, at most three attempts). A normal six-person seed can therefore pause for about a minute. Cancellation stops the wait. Other writes are not silently replayed.

Getting started

Sessions & identity

Agents & conversations

Crews, projects & workspaces

Missions & routines

Issues & triage

Skills & integrations

Inbox & notifications

Memory & journal

Observability

Cost & paymaster

Approvals & hooks

Configuration & system

Utilities

Seed

crewship seed

Flags

Examples

Business story issues

First run on a fresh dev DB

Reset and reseed

CI-friendly run that waits

Skip the issue phase for a faster crew-only seed

Backup self-test (CI guardrail)

crewship seed verify

Seed phases (in order)

What the seeded chat surface shows

Common errors

See also

crewship seed team-chat

​crewship seed

​Flags

​Seed Codex agents with a ChatGPT login

​Examples

​Business story issues

​First run on a fresh dev DB

​Reset and reseed

​CI-friendly run that waits

​Skip the issue phase for a faster crew-only seed

​Backup self-test (CI guardrail)

​crewship seed verify

​Seed phases (in order)

​What the seeded chat surface shows

​Common errors

​See also

​crewship seed team-chat

crewship seed

Flags

Seed Codex agents with a ChatGPT login

Examples

Business story issues

First run on a fresh dev DB

Reset and reseed

CI-friendly run that waits

Skip the issue phase for a faster crew-only seed

Backup self-test (CI guardrail)

crewship seed verify

Seed phases (in order)

What the seeded chat surface shows

Common errors

See also

crewship seed team-chat