Starter Ship Blueprint

Starter Ship Blueprint

A ship (one of your projects) is one deployable service plus the crew, knowledge, and automations wrapped around it. There is no ship importer yet, so this listing is download-only: the bundle's four doc pages are the checklist you follow while creating the ship by hand. Here's the same path, condensed:

1. Create the ship

Add a ship in your workspace, give it a short memorable tag (jellies, the AI agents inside a crew, key their work-claims on it), and connect the repository it owns. One service per ship — a ship that owns three services has three ships' worth of ambiguity.

2. Shape the repository

• One deployable service per top-level directory; the Dockerfile lives inside it and COPYs only from it, so change detection stays honest.
• Committed placeholder + CI settings files; real environment settings are injected at deploy, never committed.
• Migrations live WITH the service that owns the schema — sequential, idempotent, applied automatically before serving.
• Tests sit where CI actually runs them (tests/ per service). If CI doesn't run it, it doesn't exist.

3. Wire the crew

Install a crew (a bloom of jellies) — the Fullstack Dev Crew from this marketplace is a good default — and point it at the ship's tag. Each stage produces ONE artifact the next consumes (scope.md → plan.md → the change → the QA report), and rework loops are bounded so a stuck task escalates to a human instead of spinning.

4. Day-2 from day 1

• /health with a live dependency check on every service.
• Structured logs, request-id stamped, secrets redacted before they leave the process.
• A Daily Standup Current and a Deploy Notes Dispatch Pack in the first week — visibility is cheapest on day 2, not day 200.

The bundled pages cover each step in more detail — download the bundle and keep it next to the repo while you set up.