{"slug":"starter-ship-blueprint","name":"Starter Ship Blueprint","kind":"ship","version":1,"format_version":1,"checksum":"053414988ff69d784b0bfb9b296d41e5a0520dae0e243ac9f07167ec43d1850c","bundle":{"docs":[{"body":"# How to use this blueprint\n\nThere is no ship importer yet (v1 is download-only), so treat these pages as the checklist while you create the ship by hand:\n\n1. Create the ship in your workspace and give it a memorable tag.\n2. Wire a bloom to it — the Fullstack Dev Crew from this marketplace is a good default.\n3. Walk the remaining pages top to bottom; each one is a self-contained setup step.\n","title":"How to use this blueprint"},{"body":"# Repository layout\n\n- One deployable service per top-level directory; the Dockerfile lives inside it and COPYs only from it (repo-root build context drives change detection in CI).\n- Committed placeholder settings + a committed CI settings file; real environment settings are injected, never committed.\n- Migrations live WITH the service that owns the schema, sequential and idempotent, applied automatically before serving.\n- Tests sit next to the suite runner CI invokes (`tests/` per service) — if CI doesn't run it, it doesn't exist.\n","title":"Repository layout"},{"body":"# Pipeline stages and handoffs\n\nThe default flow is scoping → architecture → development → qa.\n\n- Each stage produces ONE artifact the next stage consumes (scope.md → plan.md → the change → the QA report).\n- Handoffs are explicit: a stage that needs a missing decision routes a question UP, it does not improvise silently.\n- Rework loops are bounded (max_rework) — when the bound trips, a human gets a summary instead of an infinite loop.\n","title":"Pipeline stages and handoffs"},{"body":"# Day-2 operations\n\n- Health: every service exposes /health with a live dependency check; the frontend surfaces degradation.\n- Logs: structured, request-id stamped, shipped centrally with secrets redacted on the way out.\n- Deploys: CI builds on merge, migrations self-apply, and a failed migration blocks the new revision from serving.\n- Currents: schedule a standup digest and a deploy-notes dispatch early — visibility is cheapest on day 2, not day 200.\n","title":"Day-2 operations"}],"kind":"ship","ship":{"name":"Starter Ship","emoji":"⛵","description":"A reference blueprint for standing up a new ship (service) the Bloom way: repository layout, pipeline wiring, and day-2 operations."},"exported_at":"2026-07-17T00:00:00Z","format_version":1}}