ship

ship

Deploy one verified increment to the test environment, obtain the human verdict, then merge.

Load

• ${CLAUDE_PLUGIN_ROOT}/shared/core-contract.md
• ${CLAUDE_PLUGIN_ROOT}/shared/packs/release-ops.md
• ${CLAUDE_PLUGIN_ROOT}/shared/packs/evidence.md
• ${CLAUDE_PLUGIN_ROOT}/shared/packs/feedback-routing.md
• ${CLAUDE_PLUGIN_ROOT}/shared/packs/branch-worktree.md
• For the touchpoint: ${CLAUDE_PLUGIN_ROOT}/shared/formats/report-style.md

Stages

When the project has a release ledger, resume after the latest fresh release entry with result: ok. Refresh evidence and recollect any applicable manifest whenever the content tree changes.

1. Precheck and classify evidence:
   • Build: run opc_increment.py check --require real-service-core-journey, check_gate_chain.py docs/features/<slug>, and opc_ledger.py audit --require-increment-complete. Require the plan, receipt, approved demo/PRD/testcase artifacts, reviews, resolved rework, and test-env runbook.
   • Lite: confirm no exact Build trigger applies; run focused regressions, matching risk checks, the smallest relevant real-entry check, and the project's complete predeploy/release gate. Record commit/diff, commands, exits, and evidence through the project's native mechanism. Do not create Build feature artifacts, approvals, reviews, or receipts solely for release. Both routes require the real test-env runbook. Release intent does not change the route.
2. manifest: inspect the actual diff per release-ops.md. Build writes its feature release manifest. Lite uses the project's native release artifact or a concise release ledger/handoff record only when operational changes exist; do not create a feature directory for an ordinary code-only Lite release. Every DDL item has rollback; secret values never enter artifacts; provider/dashboard changes have an owner.
3. env-test + deploy-test: apply manifest items to test in order, back up shared data before DDL, and deploy per runbook.
4. regression-test:
   • Build: execute the same approved Core-Case and regression suite through the project testcase runner against test and attach runner-generated evidence.
   • Lite: rerun the focused regression and matching real-entry check against test; use a matching project testcase when one exists, without requiring a new testcase catalog. In both routes attach honest build/origin/session/object/trace/state facts where available. Do not rerun a real provider to diagnose a harness failure.
5. acceptance-test: present the real test entry, scoped change or Build result card, applicable manifest, safety checks, and highest supported completion claim. Route the verdict:
   • approved: Build runs opc_increment.py accept --actor <role>; Lite records the human verdict through the project release evidence/ledger, then continue;
   • implementation defect: re-enter the originating Lite change or Build slice, invalidate stale evidence, fix, and resume at test deploy;
   • wrong journey/object/plan: reject the candidate, revise the result card or earliest explicit artifact, and invalidate downstream evidence;
   • taste change: create a new increment; the human decides whether this one still ships.
6. merge: merge to the project trunk, push, and clean worktrees. Fold into a living spec only when the project uses one and the increment changes durable behavior.