ship

Topics in the source

• Ship Workflow
• Steps
• Step 1: Confirm final scope
• Step 2: Confirm objective coverage
• Steps 3–6: Compatibility, tests, observability, deployment
• Step 7: Adversarial reviewer gate
• Step 8: Produce ship output
• Abbreviation

CANARY: ship-loaded-2026-06-15-3b7e91c2d84fa056 Reads status/specification.md to know what should be shipping. Confirms scope coverage, compatibility, tests, observability, and rollback before the merge. Intended vs actual scope. Any drift? Any missing pieces? If drift → decide: acceptable or split into separate PR? If scope grew significantly → does the risk assessment need updating? If the README carries a hero image, does it still match what ships? Load references/readme-hero.md when it might not, or when drawing one. Does the change solve the stated problem? All acceptance criteria satisfied? Every task's Gate is recorded and met — the gate-check skill's rungate.py --input status/plan.md answers it. Exit 1 is No-Go. Exit 0 still leaves each manual (?) gate to a human verdict; one not yet confirmed is No-Go. Exit 2 (no Gate column or usage error): confirm the plan path, then fall back to the acceptance criteria only for a plan that predates gates. Every spec or plan the branch changed has a reader built from its current text (exit 1 is No-Go: regenerate the reader it names, hand the HTML over, and commit it with the document): If partial delivery → is the partial state safe and

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