ship

Topics in the source

• ship master orchestrator (v3) — Stage ⑤
• Overview
• Process
• Boundary (important)
• How to invoke

The 5th stage, after Verify. harnessed has the pieces (a release-preflight gate, gstack /ship, publish.yml CI) — this master orchestrates them into one repeatable release path, the way comet (archive), Trellis (finish-work), and Claude-Harness (/harness-release) each close their loop. | order/mode | sub | when fires | | ---------- | --- | ---------- | | 1 (serial) | preflight | always when stage=='ship' — read-only release-readiness gate | After preflight passes, the master delegates PR + deploy to gstack /ship (composition — harnessed does not reimplement it), and the actual npm publish + GitHub release happen in publish.yml CI on tag push. 1. preflight (always) — run harnessed release-preflight. If any check fails (most often an empty ## [Unreleased]), STOP and document the release / clean the tree first. 2. PR / deploy (delegate) — invoke gstack /ship for PR creation + pre-land review. 3. publish (CI) — push the v tag (with explicit user approval) → publish.yml runs npm publish + creates the GitHub release. This stage stops at tag-ready. It never pushes to the remote, never publishes to npm, and never creates a git tag on its own. Those are CI + explicit-approval actions, by des

This is an excerpt. Refer to the complete source and its current requirements.