izittmarvin/buildrail/br-ship

/br-ship — 发布模块

负责将已验证通过的代码变更安全地记录并发布。在整个自动化流水线（bugfix, iterate, full-dev）的最后一步被调用。

运行状态约定

本 skill 启动时按 shared/state-schema.md 的写入契约初始化/更新 .buildrail/state.json：

• 若无活跃 run（state.json 不存在或 run.status !== "running"）→ 视为入口（用户单独 /br-ship），覆盖式初始化：run.command: "br-ship"、run.path: "step"、phase.current: "ship"、phase.label: "发布"
• 若已有活跃 run（被 /br-full-dev / /br-bugfix / /br-iterate / /run 编排调用）→ 不覆盖 run，只推进 phase 到 ship
• 发布前检查 review.verdict：若为 "block" → 禁止发布，提示有 Critical/HIGH 未修
• 发布完成：run.status: "completed"、run.updated_at

职责

1. 向用户汇报本次改动并请求确认（human-in-the-loop，不自动提交）
2. 提交代码（仅当用户明确同意）
3. 推送代码到远程仓库（仅当用户明确同意）

不碰 CHANGELOG。 BuildRail 不假设用户维护变更日志，也不强制创建。用户想记变更，自己用 commit message 或别的工具。BuildRail 只管 commit + push。

第零步：汇报本次改动并请求确认（human-in-the-loop 门控）

核心原则：br-ship 绝不自动提交或推送。 提交（commit）和推送（push）是对外、难撤销的操作，

必须由用户明确确认后才执行。这是 BuildRail 的产品底线——前面开发全自动，最后对外动作前停下来让人拍板。

为什么 commit 也不自动？ 因为用户跑完 br-full-dev 后，可能还想微调（改个文案、调个样式）。

如果 AI 自动 commit 了，用户再改又得重新组织提交，很烦。所以把"何时提交"的决定权留给用户。

汇报内容（排版清晰，让用户看得舒服再决定）

向用户展示本次完成的工作，结构化呈现：

1. 做了什么：本次实现/修复的功能点（X / Y / Z），简明列出。
2. 改了哪些文件：文件列表 + 每个文件的一句话改动概述（如 src/auth.ts — 新增登录校验逻辑）。
3. 审查结果：五轴审查（正确性/可读性/架构/安全/性能）各轴结论，有无遗留问题或技术债。
4. 当前状态：明确告知"以上改动都还在缓存区（工作区），尚未提交"。

请求确认

汇报完后，询问用户："是否需要我帮你提交并推送？"

• 如果用户不确定（尤其新手，可能不懂"提交"是什么意思）：先用大白话解释。
• 解释示例：*"提交（commit）相当于给代码拍一张快照存到本地版本库，推送（push）是把这份快照同步到远程仓库（如 GitHub）。

提交后随时可以撤销或修改。你可以选择现在提交，也可以先自己再看看代码、微调后再提交。"*

• 解释完再问一次，让用户基于理解做决定，不要催。

根据用户回应分流

• 用户说"要 / 提交吧 / 推送吧"等明确同意 → 继续执行第一步起的提交流程。
• 用户说"不要 / 我再看看 / 等等"等拒绝或犹豫 → 立即停止，不提交不推送。

告知用户："好的，改动都保留在工作区，没有提交。你随时可以微调；想提交时运行 `/br-ship` 即可。" 然后 skill 结束，run.status 标记为 completed（开发已完成，只是用户选择暂不发布）。

• 用户提出要先改某些地方 → 建议用 /br-iterate <改动描述> 做微调，改完再用 /br-ship。

第一步：代码提交

(用户在第零步明确同意提交后，才开始以下流程。) 提交本次所有改动（前面 /run 或 /br-iterate 等环节已经把代码写在工作区，但没有 commit，所以这里要把它们一次性提交）。

git add {本次涉及的所有文件}
git commit -m "feat: {本次改动的一句话总结}"

commit message 给用户过目：提交前先把拟用的 commit message 展示给用户，确认无误再提交。

第二步：推送到远程

执行推送命令：

git push origin HEAD

如果推送失败（例如无上游分支、需要 pull 等），向用户报告错误，请用户介入处理，禁止强制推送 (force push)。

结束通知

向用户总结发布状态：

✅ 发布流程结束：代码已提交并推送到远程。

后续维护：发现 bug 用 /br-bugfix <描述>；需要小改动用 /br-iterate <描述>；要再做新功能用 /br-full-dev <需求>（全自动）或 /idea <需求>（分步）。