Ship 是 CocoBrew 生命周期中的收尾阶段（6/6），面向已完成编码、测试与评审、准备正式发布的项目，把评审通过的改动固化为可追溯的版本发布记录。
用途与前置条件 使用前需确认目录下已存在 .cocoplus/（否则提示先运行 $pod init），并读取 .cocoplus/lifecycle/meta.json 验证 phases_completed 含 review。仅凭 meta.json 不足以放行，还须确认 spec.md、plan.md、review.md 三个文件真实存在于磁盘，缺失时分别提示运行 $spec、$plan、$review 重新生成。review.md 的 Approval Status 必须为 APPROVED，否则停止并提示先完成评审。
阻断机制 若 review-state.json 中存在 severity 为 BLOCKED 且 resolved 不为 true 的条目，发布将被阻断，并列出每条未解决条目的 ID 与一行摘要，需通过 $review clear-blocked --id <finding-id> --rationale <text> 逐条解决。BLOCKED 与 BLOCKING 同等对待，没有覆盖通道。
版本确定 先检查当前 git 分支是否含语义化版本标记（如 feature/cocoplus-v1.2.0 或 release/1.2.0 均解析为 v1.2.0），有则规范化为 v<major>.<minor>.<patch> 作为发布版本，除非开发者显式覆盖；分支不含版本时不会推断或自动递增，而是询问开发者应使用的语义版本，并校验格式，不符合则再询问一次。已有标签仅作为提示上下文。CHANGELOG.md 更新使用分支推导出的版本：版本已存在则追加发布说明，已有该版本但当前月份不存在时，在同一版本下新建月份小节；分支无版本则先询问版本再编辑。
变更确认与部署记录 执行时展示自最近版本标签（无标签则以首个提交为基准）以来的全部变更统计，并询问是否继续发布，回答 no 即停止。确认后写入 .cocoplus/lifecycle/deployment.md，包含日期、阶段、版本、阶段 ID、变更摘要、Spec ID、Plan ID、评审批准时间，以及提交 SHA 与 PR URL 的预留字段。
提交与打标 将 deployment.md、meta.json、AGENTS.md 加入暂存区，以 release: [version] — [项目目标简述] 为信息提交，并创建附注标签 [version]。标签必须指向包含 deployment.md 的最终提交，不能先打标再提交。
可选 PR 与收尾 询问是否创建 PR；选择是时检查 gh CLI 是否存在，存在则用评审内容作为正文创建 PR，不存在则提示从 https://cli.github.com/ 安装。随后更新 deployment.md 中的提交 SHA 与 PR URL，尽力清理 Build 阶段遗留的 CocoHarvest worktree，并执行 worktree prune。最后更新 meta.json（加入 ship、current_phase 设为 shipped）并向 AGENTS.md 追加不超过 200 行的 SHIPPED 状态记录。
退出标准 deployment.md 含版本、Spec ID、Plan ID 与评审批准字段；存在指向发布提交的 v*.. 标签；meta.json 的 current_phase 为 shipped 且 phases_completed 含 ship；AGENTS.md 含版本与时间戳的 SHIPPED 记录；存在未解决 BLOCKED 项时发布被阻断且无法绕过。