Ship

上下游

• 前接：实现完成的改动；用户批准过审查时，review 已收敛。
• 读取：全局规则的 Git 一节，推送和部署前的核对以它为准。
• 分流：部署后出现线上报错，转 ops-triage。
• 写入：项目的部署、迁移、发版步骤 → 持久规则。

口令

用户用短口令下达交付，口令决定执行范围。

• 连写的口令按顺序全部执行，例如「提交推送合并部署」。
• 「先不 X」「X 暂不」：跳过 X，以及只为 X 服务的步骤。
• 口令只覆盖它说到的步骤：「提交推送」不包含部署。
• 每个口令结束时都做一遍盘点。

步骤

1. 提交

从环境里找检查命令（package.json scripts、Makefile、CI 配置），提交前跑格式化、类型检查和测试。按功能分组提交，一个提交只含一个功能的改动。

完成判据：检查全部通过，每个提交能用一句话说清改了什么。

2. 推送与 PR

按全局规则推送。PR 描述写改动、验证方式和遗留项。

3. 部署

1. 读项目的部署说明：持久规则、README、docs/、部署脚本。都没有时问用户部署方式，部署成功后写进持久规则。
2. 列出本次需要的迁移。SQL 先在事务或副本上试跑，核对影响行数后再正式执行。
3. 保持服务不中断：新实例就绪后再切流量，不动正在服务的旧实例。
4. 在本机构建、上传产物，除非项目约定在服务器上构建。

4. 部署后核对

在真实环境确认本次改动生效：

• 运行的版本或提交号等于本次提交；
• 改动点实际可用：请求接口、打开页面截图、走一遍改动的操作；
• 观察日志，直到有请求经过新代码，且没有新增报错。

完成判据：每一项都有证据（命令和输出、截图）。有新增报错时先止血（回滚或关开关），再转 ops-triage。

5. 发版

• 版本号在上一版基础上加一，不跳号。
• 更新日志用中文，只写用户能感知的变化，多个小修复合并成一条。
• 有前后端依赖时，先部署后端和网页，再发客户端。

盘点

每次报完成前逐项检查：

• git status、未推送的提交、本次开的未合并 PR；
• 本次产生的分支、worktree、临时文件、[DEBUG-...] 日志；
• 改动里的 mock、TODO、占位数据、被删掉入口的功能；
• 用户在本会话提过、但还没做的要求：回看用户的消息逐条对照。

完成判据：每一项要么已清理，要么列进汇报并写明原因。

汇报

先给结果：提交号、PR 链接、部署环境和核对证据。再列盘点剩下的项。