deploylisted

# crew Deploy & Release `/crew:ship` carries a verified change from the repo to a release (and optionally a deployment). Behavior is config-driven via `config.workflow.ship`; **all git mechanics defer to `config.git`** — the single git authority. There is no deploy-specific push axis. `/crew:ship` is also the **Ship step** of the `/crew:finish` strand (see `crew-config` → `config.workflow.finish`): there it runs only when `config.workflow.ship.run ≠ off` **and** `config.workflow.ship.enabled` — finish adds no new push/release axis, it calls this same command. ## `config.workflow.ship` | field | what it does | |---|---| | `enabled` *(default `true`)* | Is `/crew:ship` available here? `false` → explain how to enable, then stop. | | `runDeploy` *(default `off`)* | The only knob `config.git` doesn't cover: run an **imperative** deploy command after the git steps? `off` = push-triggered CI (the push *is* the deploy — nothing extra to run). `ask`/`auto` = imperative world (Vercel/Fly), command from `reference/deploy.md`. | | `provider` | `gh-actions` (`gh`) or `gitlab-ci` (`glab`). | | `tagPattern` | Release tag shape, e.g. `v{version}`. | | `environments` | Optional named environments. | | `releaseTool` *(default `auto`)* | How the version is decided (see **Release mechanics** below). `auto` detects from the repo. Replaces the old hardcoded Changesets check. | | `finishRelease` *(default `off`)* | Bot-PR tools only: merge an open version/release-PR (phase 2)? `off`/`ask`/`auto