update-pr

更新 PR

通过集成、相关提交、常规推送和更新元数据，更新已建立的 PR。此请求包括解决常规冲突并运行已声明的 PR 检查门槛；合并由 /deliver 根据交付设置负责。沿用已选定的目标和先前的授权。只有在目标 PR、重大冲突解决方案或此次更新中的其他重大选择仍不明确时才询问。

如果当前 PR 属于原生 GitHub 堆栈，请阅读 ../git-workflow/references/github-stacks.md。 如果 PR 媒体已无法展示当前行为，或更改需要新的媒体内容，请参照 ../create-pr/references/walkthroughs.md刷新受影响的部分；仍能展示当前行为的媒体内容应继续使用。仅媒体工具方面的缺失不会阻碍更新。

1. 应用 git-workflow。按照 git-workflow 的定义，检查当前 PR 及其目标分支、当前分支、相关本地更改、最近提交，以及已获取的远程目标分支。在判断缺失的 CI 是否需要处理之前，先根据第 3 步解决需要更新目标分支的分支。
2. 如果当前位于目标分支上，或不存在开放的 PR，则停止；报告所需的下一步工作流。如果 git-workflow 判定 PR 没有远程目标分支，也同样停止。
3. 仅当 git-workflow 的更新状态规则要求时，才将远程目标分支合并到普通分支。落后于目标分支的分支应保留其当前 HEAD 及其检查结果，即使此次更新会产生新提交也不例外。发生添加式冲突时，保留双方所需的行为；使用项目的工具重新生成生成文件。确定冲突解决方案后，继续验证。对于已验证的原生堆栈，记录远程 HEAD，并使用受保护的 gh stack sync 或范围更窄的官方堆栈操作；绝不使用原始的 rebase 或强制推送命令。
4. 对更改后的行为（包括任何基线集成）应用 /code-review fix-all 和 /test-against-spec fix。仅重用内容、命令、环境和覆盖范围仍然匹配的验证结果；合并基线或编辑会使受影响的检查失效。运行缺失或已失效的检查。通过 /implement 的开发循环修复所有已确认的范围内需求缺口，然后通过已声明的 PR 门禁。若需要预览才能测试尚未发布的修复，可以更新草稿；随后须在该确切修订版本上继续测试，才能宣称已准备就绪。
5. 存在相关更改时，按照 git-workflow 提交：仅暂存这些文件，使用简洁的 Conventional Commit 主题，绝不 amend 或跳过钩子。在每次提交、推送和修改 PR 时运行发布保护检查。
6. 如果分支包含远程尚无的提交，则正常推送普通分支；必要时设置上游分支。已验证的堆栈只能通过受保护的官方堆栈工作流推送。
7. 使 PR 标题和正文与完整的当前差异、范围及关联议题保持一致。推送始终会改变 HEAD，因此推送后必须重新核对正文，即使摘要仍然适用。整个更改的标题都应使用 Conventional Commit 主题；标题会成为 squash merge 提交主题，因此范围扩大时，类型也可能需要调整。遵循PR 描述指南，保留项目模板中的明确要求，并替换过时的摘要、中间开发历史和作者验证部分。将审核备注保留在正文末尾，并按其描述更新。保留 PR 模板的所有标题，原文不变且顺序不变；对于没有内容可写的标题，写一行 None 或说明原因。写入前，对草稿运行 template-check，使用 --kind pr --body FILE；写入后，对实时正文运行该检查，使用 --pr N，并修复它报告的所有标题问题。
8. 报告已更新的 PR、任何新提交、元数据更改、发布保护检查重写的内容，以及观察到的验证结果。适用时，包含堆栈位置和已重写的分支。区分已通过的本地检查与当前 HEAD 上仍待完成的 CI。草稿 PR 在 delivery-wait 确认推送的 HEAD 上所有必需检查均通过之前，必须保持草稿状态；只有届时才可将其标记为可供审核。向当前负责发布或交付的调用方返回确切的当前 HEAD 和下一步转换；该调用方会继续处理 CI 和反馈。若直接启动，则按照交付设置继续；若 entry-points: deliver，推送的 HEAD 将交由 /deliver 处理，由其等待 CI 和审核，并将 PR 推进至配置的终点（若没有 ORCHESTRATION.md，则为 ready-to-merge）。若设置为 stop，则以此报告结束。 报告缺失的演练要求及补救方法。