用途：为项目建立确定性的测试覆盖率闸门。构建通过只说明已有测试通过，不能说明是否写了测试；该技能在每个验证环节测量行覆盖率，与提交的基线比较，覆盖率不得下降，只能上升。
为什么用棘轮而非固定目标：绝对阈值（如 80%）在真实代码库中要么第一天就失败而被禁用，要么设得低于现状而毫无约束。棘轮从项目实际水平出发，只收紧。
激活时机：项目有测试目标但从未测量覆盖率；智能体写的功能不断以构建通过但无测试的代码交付；搭建确定性检验流程（配合 testing/fitness-functions/ 与 swift/code-size/）。
设置：把 templates/coverage-gate.sh 复制到项目（如 Scripts/coverage-gate.sh），赋予执行权限，填写配置块（scheme、destination、app target 名称）。初始化基线：Scripts/coverage-gate.sh --init，运行带覆盖率的测试并写入 .coverage-baseline。将脚本与 .coverage-baseline 一并提交。基线文件仅含一个十进制小数（如 0.6231），即 app target 的行覆盖率，忽略行尾空白。
闸门用法：Scripts/coverage-gate.sh，退出码 0 通过、1 表示覆盖率下降。它启用覆盖率运行测试套件，从 xccov JSON 报告提取 app target 行覆盖率；若当前值低于基线减 0.0025 则失败（epsilon 吸收未改动代码的测量抖动）；若当前值高于基线加 0.01 则建议上调，把新数值与产生它的测试放在同一次提交中更新基线。报告结构异常或目标缺失时脚本大声失败——测量损坏绝不能读作通过。上调基线是常规且鼓励的；下调需在提交信息中写明原因。
CRAP 报告（仅供参考）：templates/crap-report.sh 把每函数圈复杂度（SwiftLint JSON 输出）与每函数覆盖率（同一 xccov 报告）合并为 CRAP 分数：CRAP(f) = complexity(f)² × (1 − coverage(f))³ + complexity(f)。复杂且未测试的函数得分急剧升高，简单且已测试的接近其复杂度。报告打印前 20 名，即测试收益最大的函数。仅作参考，永不作为闸门：两个工具的名称连接是启发式的。
限制与注意：不要对既有代码设绝对阈值；不要门禁整个项目覆盖率（测试目标与生成代码会污染数字），应门禁 app target 自身的 lineCoverage；工具失败不能静默通过；不要用无断言的测试刷数字，可配合变异抽查；不要一直不上调，基线会僵化。