Skip to main content

Documentation Index

Fetch the complete documentation index at: https://docs.crewship.ai/llms.txt

Use this file to discover all available pages before exploring further.

Migrations Catalog

Crewship runs Go-only migrations against SQLite. The full ordered list lives in internal/database/migrate.go (var migrations), and they apply in version order at startup, tracked in the _migrations table for idempotency. This page is a flat reference for the recent set — useful when reading server logs, restoring from a backup that pre-dates a feature, or auditing what shipped between two releases. For older migrations (v1–v49) read migrate.go directly; this catalog focuses on the Crew Journal era and onward.
Never run prisma migrate. Prisma is for TypeScript type generation only (pnpm db:generate). Database schema is exclusively the responsibility of the Go migrations runner.

v50–v53 — Backup & Crew Journal foundations

vNameAddsPR
50add_instance_configPer-instance config row (replaces env-only configuration).
51add_port_exposuresport_exposures table — capability URLs for in-container ports.
52add_crew_journal8 tables: journal_entries, journal_embeddings, agent_status, approvals_queue, checkpoints, hooks_config, cost_ledger, budget_limits.#204
53add_eval_runseval_runs (Quartermaster’s durable replay/regression index with status + metrics columns).#204
After v52, journal_entries is the canonical audit stream. After v53, replay/regression analytics have a durable home.

v54–v55 — Memory uplift

vNameAddsPR
54add_memory_importance_and_gate_rewardsjournal_embeddings.importance_score, reference_count, last_referenced_at. Foundations for nightly decay-and-reinforce.#211
55add_memory_quality_upliftjournal_entries_fts (FTS5 mirror), journal_entries_archived (compaction sink with truncated payloads), memory_relations (A-Mem-style edges), memory_health_snapshots (daily 5-metric scores).#212
These two PRs together delivered the Episodic memory uplift: hybrid retrieval (RRF over dense + BM25), archive layer, relation graph, and the health dashboard. The ?q= parameter on the journal API is backed by the FTS5 table from v55.

v56–v59 — Chat UI overhaul

vNameAddsPR
56add_journal_ws_crew_ts_indexComposite (workspace_id, crew_id, ts) index for the Timeline tab’s crew-filtered queries.#225
57add_chat_extrasFour tables: chat_branches (edit-and-resend branch tree), message_reactions (per-(chat, message, emoji, user) aggregated to counts), chat_attachments (per-chat link row with sha256 + storage path), workspace_files (durable workspace-scoped blob index).#225
58add_user_preferencesuser_preferences (user_id, pref_key, pref_value) — generic per-user JSON-blob KV. First consumer is bottom-panel height in /crews; the schema is intentionally generic so further UI settings land without another migration.#225
59add_chats_originchats.origin (web | cli | webhook | crew) for grouping in the Sessions sidebar. NULL = pre-migration; UI omits the chip rather than guessing.#225
After this batch the chat surface has session history, attachments, reactions, edit-and-resend branches, per-user preferences, and origin tagging. See Chat & Sessions.

v60–v61 — Unified journal / Runs SSOT

vNameAddsPR
60add_journal_ws_trace_indexComposite partial index (workspace_id, trace_id) WHERE trace_id IS NOT NULL. Makes GROUP BY trace_id (run aggregation) cheap.#234
61drop_agent_runsIdempotent backfill from agent_runsjournal_entries, snapshot to agent_runs_archive, then DROP TABLE agent_runs.#234
After v61, journal_entries is the single source of truth for runs. journal.ListRuns reconstructs the row shape via aggregation; the legacy table is gone but its content survived in agent_runs_archive for forensic reads. The five new entry types (run.started, run.completed, run.failed, run.cancelled, run.timeout) shipped with the same PR.

v62 — Paymaster billing modes

vNameAddsPR
62add_paymaster_billing_modes9 columns on cost_ledger: billing_mode, quota_remaining_pct, quota_window, subscription_plan, four rate_*_per_m rate-card snapshot columns, cost_confidence. Plus partial index (workspace_id, billing_mode).#232
PR #232 originally numbered this migration v60. The merge with PR #234 (which had taken v60 + v61 for the unified journal) renumbered it to v62 — see the Renumbered from v60 to v62 comment in migrate.go. Documentation that pre-dates the merge may still mention v60; the canonical number is v62.
After v62, cost_ledger distinguishes metered API-key calls from flat-rate subscription calls and snapshots the rate card per row (Langfuse pattern). See Paymaster.

How to read this in operation

When crewshipd starts, it logs each migration as it applies:
INFO  applying migration  version=62  name=add_paymaster_billing_modes
The _migrations table records the applied set and refuses to apply a version-name pair that disagrees with what the code expects — this catches the classic “two PRs both claimed version N with different SQL” footgun loudly at startup.

Restoring from a backup that pre-dates a column

The backup subsystem (internal/backup/runner.go) records the migrations applied at backup time. On restore, every migration the target has but the source lacked runs its restoreBackfill hook (when defined) against the freshly-inserted rows — so a restore from a v59 bundle into a v62 server populates the new columns sanely instead of leaving them at the SQL DEFAULT. Pure ADD COLUMN migrations that rely on the DB default need no hook; complex ones (e.g. backfilling a JSON column) provide one.