交付改动

1. 读懂 ticket

通过已连接的 Jira MCP 或已认证的 acli 读取 [Jira 编号或链接]，包括描述、验收标准和评论。
访问不了的话，让我把详情贴给你。读仓库说明，梳理受影响的流程。
提出最小的改动方案，以及能证明它正确的检查。业务规则、权限或数据上不清楚的地方，列成问题。
先不要改代码。

• 带上上手项目时整理的项目背景，以及已经确定的分支计划。
• 简单的改动，给个简短方案就够了。涉及业务规则、权限或数据的改动，先和需求负责人讨论。
• 一个 PR 只做一件事。拆分能让验证、上线或恢复更容易时，就拆；光看行数，判断不了好不好评审。

acli jira workitem view ENG-123 --fields '*all' --json

2. 实现改动

在 [ticket 分支] 上为 [Jira 编号] 实现已确定的改动，每条验收标准都要有测试。
这次改动让哪些文档和 agent 说明变得不对，就一起更新。计划和笔记不要放进仓库。
告诉我改了哪些文件、加了哪些测试，以及已确定的行为或风险有没有变化。
先不要 push 或开 PR。

• 文档和它描述的行为在同一个 PR 里修改，这样发布收尾只是核对，不用重写。
• 后端改动保持向后兼容。现有客户端照常工作，包括所有仍允许运行的已安装 App 版本。可以新增字段和接口；等没有受支持的客户端依赖它们之后，才能修改或删除。

  注意已安装的移动端版本收不回来，用户更新也慢。哪些版本仍受支持，由强制更新设置决定。

• 检查每条验收标准都有测试，diff 只改了这个 ticket 相关的文件。
• 让 agent 只用合成数据，并待在它的权限范围内：生产环境操作和破坏性操作要等你同意。
• 无关的缺陷单独建 ticket 跟进，不要在这次改动里顺手修。
• 如果中途发现的情况改变了已确定的行为或风险，先和需求负责人达成一致。
• 新增文档要在文档索引里登记。
• 按改动涉及的内容，对照相应的防护页面：访问与数据、数据库变更、资金与奖励、后台任务与外部调用，或短信与付费接口。

3. 验证结果

很好，测试都过了。开 PR 吧。

用合成数据，对照 ticket 的验收标准验证这次改动。
运行相关检查，实际走一遍受影响的流程。如果是修 bug，展示回归测试在修复前失败、修复后通过。
逐条给出每个验收标准的证据、运行的命令、测试的 commit，以及验证缺口。检查失败就修根因，不要削弱防护。
先不要 push 或开 PR。

• 对照 ticket 检查证据；AI agent 验证不了的部分，自己去看。
• 改动防护措施，要写明理由，并得到评审人同意。

ENG-123 要让 AI agent 验证这些：

4. 开一个可评审的 PR

检查 [Jira 编号] 的最终 diff，看有没有缺陷、无关改动和意外的文件。发现了就停下来告诉我。
diff 干净的话，push [ticket 分支]，向 [目标分支] 开 PR。描述里写清楚为什么要做这个改动，链接 ticket 和验收标准，给出每条标准的证据、检查结果和测试的 commit、哪些没有验证，以及怎么撤销这个改动。
不要合并。

• 被评审的改动要在 CI 里跑测试和 lint。本地通过，证明不了共享的构建环境也没问题。
• 说明改动的原因。链接 ticket 和验收标准，让评审人能判断结果对不对。
• 写明哪些没有验证，以及原因。批准人要知道缺口在哪，才能做判断。

PR 描述示例

ENG-123：导出筛选后的订单

为什么：商户管理员需要把正在查看的订单导出为 CSV。
证据：用两个商户的合成用户，检查了字段、筛选、空结果、重试、商户隔离和管理员权限。
检查：[CI 运行] · [命令和结果] · commit [SHA]。
缺口：生产数据量下的性能未验证。
跟进：[Jira 链接]，负责人 [姓名]；发布前解决。
恢复：暂停导出队列，然后重新部署上一个版本；新增的 exports 表保留。