第 12 章：把发布门槛变成可失败的程序
发布门槛不是报告最后一行的装饰。它应该真正影响进程退出状态，使 CI 能阻止不满足合同的候选，同时把失败原因留给维护者。绿色检查还需要对应明确范围，不能借此宣称整个产品已安全可靠。
12.1 先检查证据是否可用
随书 release_gate() 首先检查是否为验收集，以及配对是否完整、候选是否有安全或未知失败、是否仍有待审项。开发集上的漂亮表现会被 not_acceptance_split 拒绝；预算拒绝和超时不能从分母里消失。
这类门槛表达的是证据可用性。假如运行不完整，即使计算得到候选与基线相同的差值，也不应继续把它解释成非劣证据。把检查顺序写清楚，有助于团队先补实验，再争论分数。
12.2 再检查回归与区间
当前教学政策拒绝任何新的任务回归与最低表达回归，并检查项目差值百分位区间的下界不低于 -0.05。这里样本级规则比整体区间更严格；保留两项是为了展示不同层次的决策依据，不应把它们误称为经过统计功效设计的业务检验。
真实项目可能允许某些低风险场景轻微退化，以换取更重要收益。这样的权衡应事先按业务范围规定；不能看到新版本失败以后，再把该样本降级成无关紧要。
12.3 让命令真的返回失败
python3 -m lab.pipeline --candidate retrieval_v2 \
--output /tmp/quality-blocked.json --require-pass该命令实际以状态码 2 结束。报告包括 new_task_regression、new_answer_quality_regression 和 paired_interval_below_noninferiority_margin。省略 --require-pass 时，程序仍生成失败报告，但命令本身仅承担分析任务，退出为 0；两种使用方式需要区分。
CI 的实验测试包含对失败退出码的检查，避免未来重构只打印 FAIL 却继续成功。完整 demo 则期望一个修复候选通过、两个缺陷候选失败；它自身成功表示这些预期行为被验证，并不表示三个候选都适合发布。
12.4 审计记录足以重建决定
至少保留输入和答案指纹、候选及评分代码版本、完整配对结果、配置、预算状态、人工决定、门槛版本与原因。对含私有数据的业务报告，证据应分级存储，公开报告可以只保留定位符和汇总。
本实验完整响应可公开，是因为数据全部是合成的；报告本身没有实现访问控制、签名、不可篡改日志或审批身份系统。哈希便于发现字节变化，但不证明谁有权签署该版本。
12.5 回退也需要版本证据
发布记录应关联实际部署配置、回退目标和监测窗口。评测通过后部署了另一个提示或索引版本，先前报告便不能直接覆盖它。回退后也要确认旧资源仍然可用，权限与数据合同没有被迁移破坏。
练习。 去掉 --require-pass 运行缺陷候选，观察报告与退出码的区别。然后为自己的 CI 写下“哪些步骤允许只产出分析、哪些步骤必须阻止发布”，避免把一份失败报告误当作一个失败的工作流。