写清前置条件和检查点

以下示例与示意结果由本站编写，用于说明方法，不是模型实测结果。

使用场景

你已准备一个发布候选，但发布前必须确认评审覆盖当前版本。教学记录中候选版本标签是 build-b，批准记录只覆盖 build-a；实际项目应换成真实提交 SHA。这些记录仅用于说明检查，不执行发布。

具体做法

把前置条件和通过依据放在同一个醒目区块。先确定待执行动作与候选标识，再查批准记录的对象、版本和范围；相符才继续。不符、缺失或已失效时交付候选报告，停在该动作之前。已有批准覆盖当前动作时直接引用，不重复索取同一批准。

反例

候选是 build-b，批准记录是 build-a。重要：确保发布前已经评审，然后提交候选。

改进写法

候选为 build-b，已有批准仅覆盖 build-a。
<HARD-GATE>提交发布前核对候选与批准记录的版本和操作范围。只有记录覆盖当前候选及提交动作才继续；批准缺失、版本不匹配或范围不覆盖时，展示候选报告并等待相应决定。当前不执行提交。已有有效批准不重复请求。</HARD-GATE>
在实际项目用真实提交 SHA 替换教学标签，并保留引用的批准记录位置。

为什么这样改

“已经评审”没有指定评审哪一个候选，容易把旧批准借给新版本。显式检查版本与范围能说明为什么可以继续或为什么要停；标签只帮助定位规则，真正的判断依据是匹配记录。

如何验证

对当前教学记录，示意输出应是“build-b 未被 build-a 的批准覆盖，候选已准备，未提交”。把记录替换为覆盖 build-b 和提交动作的有效批准后，应引用它并继续，而非再问一次。

检查执行记录中是否有匹配证据，是否存在版本不匹配仍提交的情况。后者不满足前置条件。

适用边界

醒目标签不形成工具权限或服务端访问控制，关键系统仍需自身的权限机制。不同动作的批准范围可能不同；真实 SHA、记录效期和审批规则以项目约定为准。