OmniRoute 质量门体系深度解析：Ratchet 基线引擎、12 类检查点目录与跨项目复刻 Playbook-迪斯科星球

OmniRoute 质量门体系深度解析：Ratchet 基线引擎、12 类检查点目录与跨项目复刻 Playbook

【免费下载链接】OmniRouteNever stop coding. Free MIT AI gateway: one endpoint, 352 providers (150+ free), 1200+ models Kimi, Claude, GPT, Gemini, GLM, DeepSeek, MiniMax. Works with Claude Code, Codex, Cursor, OpenCode, Cline & Copilot. Quota-aware auto-fallback, RTK+Caveman compression saves 15-95% tokens, MCP/A2A, Desktop/PWA. Built by 550+ contributors项目地址: https://gitcode.com/GitHub_Trending/om/OmniRoute

本文基于 OmniRoute 仓库中的《质量门 Playbook》（docs/ops/QUALITY_GATE_PLAYBOOK.md，波兰语镜像见 docs/i18n/pl/docs/ops/QUALITY_GATE_PLAYBOOK.md）展开：先讲清这套"ratchet（棘轮）质量门"体系的成熟度定位与自我批判，再完整继承其 12 类检查点目录与分阶段复刻计划，并结合 config/quality/quality-baseline.json、scripts/quality/check-quality-ratchet.mjs 等真实源码，把文档中的每个模式落到可验证的实现证据上。读完你可以完整掌握：如何在任意项目中复刻一套"只进不退"、防 Goodhart、缺基础设施自动降级的质量门系统。

一、文档定位与评估基准

Playbook 开篇明确声明了自己的性质：一份对 OmniRoute 质量门系统的批判性评估（对标行业最佳实践）+ 全部质量检查点的完整目录 + 一个与工具无关的复刻计划，且强调"基于仓库真实状态生成，而非凭记忆"（生成日期 2026-06-16）。其对标基准包括：OWASP DSOMM、OpenSSF Scorecard、SLSA、SonarQube "Clean as You Code"、Quality-Ratchet 模式、DORA 2024 报告、OWASP LLM Top 10（2025）以及 mutation testing 最佳实践。

文档给出的总评级是A− / "Advanced"（自评为项目分布的前 5–10% 区间），其论据不是"我们抄了清单"，而是"系统独立收敛到了行业明确命名的几种模式上"——这是最强的对齐信号。需要说明的是，该评级是文档的自我评估口径；下文所有结论均可通过仓库内文件复核。

二、成熟度分类：八个参考框架逐项打分

参考框架	现状定位	评级
OWASP DSOMM（5 级 × 5 维度）	稳固的 Level 3，在 Test Intensity 与 Static Depth 两维触及 Level 4；多数组织停留在 1–2 级	L3→L4
OpenSSF Scorecard（18 项检查）	通过 CI-Tests、Code-Review、Dependency-Update-Tool、Fuzzing、SAST、Signed-Releases（provenance）、Token-Permissions、Vulnerabilities、Dangerous-Workflow；缺口：`main`分支保护关闭、部分 actions 未按 SHA 固定	约 7–8/10
SLSA（4 级）	`npm publish --provenance`+`id-token: write`+ GitHub 托管构建 = L2，接近 L3；缺 L3+ 所需的加固/可复现构建器	L2→L3
SonarQube "Clean as You Code"	哲学完全一致：ratchet 门的是"不回归"而非绝对值；分歧点是 Sonar 建议条件要少，而本项目约 46 道门（疲劳风险）	对齐，但有保留
Quality-Ratchet 模式	参考级实现：ratchet +`dedicatedGate`+`tightenSlack`+`--require-tighten`+ graceful-skip，比大多数公开示例更精细	典范
DORA 2024	stability 轴很强；风险是重门侵蚀 lead time，用 fast-gates 拆分缓解但仍有覆盖缺口	强（stability）
OWASP LLM Top 10 (2025)	风险 #1（prompt-injection）由 runtime guard + promptfoo（eval）+ garak（red-team）三层覆盖	已覆盖
Mutation testing	Stryker nightly，阈值 70/50，关键模块 nightly 变异测试；超越行业共识基线；缺口是 score 尚未成为 ratchet（后已补齐，见下文源码证据）	接近完成

三、七大优势：超出平均水平的部分

3.1 多指标 ratchet 引擎（系统的心脏）

文档称基线文件 config/quality/quality-baseline.json 承载"24 个指标、4 个专用基线，每个指标带方向（up/down）、容差（eps）、收紧余量（tightenSlack）与dedicatedGate标志"。从当前仓库看，这套引擎已经长大：基线现含 50+ 个指标（含 8 个 per-module 覆盖率地板、28 条 per-modulemutationScore条目、bundle size、CodeQL alerts、zizmor findings 等），且每个指标下都挂着一大段_rebaseline_*审计注释——记录每次重定基线的日期、PR 号、测量方式与理由。这正是文档所说的"修好的东西保持修好"的代码库熵逆手段，也是"trust-but-verify"文化的直接物证。

引擎本体是 scripts/quality/check-quality-ratchet.mjs，约 165 行，核心语义与文档完全一致：

逐指标比较metrics.json与quality-baseline.json，方向语义为down（不许变大）/up（不许变小）；
每个指标可自带eps（防抖容差，全局回退值 0.01），--require-tighten时若指标改善幅度超过tightenSlack却没收紧基线，同样 exit 1——"锁住收益"；
--update把改善写回基线；--allow-missing允许本地跑（coverage 只在 CI 有）；
检测到"孤儿指标"（在 metrics 里出现但基线没登记）时打印警告；
基线中的_policy块（当前为 velocity 阶段：到 v4.0.0 前所有基线统一放宽 20%、requireTighten置 false）会让--require-tighten自动降级为 advisory——这是文档"advisory→blocking 生命周期"原则在引擎层的落地。

3.2 供应链纵深防御

文档列出的完整栈：SAST（CodeQL/Sonar）+ secrets（gitleaks 且useDefault）+ SCA（osv/npm-audit/Trivy/Dependabot）+ licenses + lockfile + SBOM + SLSA provenance + Scorecard + workflow 加固（zizmor）。仓库中可逐一验证：scripts/check/check-secrets.mjs 用 gitleaks 扫描src/open-sse/bin/electron/scripts五个源目录（刻意不做全树扫描，注释里说明了 gitleaks 无遍历排除项、全树会超时）；.github/workflows/quality.yml 中"Install security scanners"步骤把审计器版本全部钉死（gitleaks v8.30.1、osv-scanner v2.3.8、zizmor 1.25.2、oasdiff v1.19.1），注释明确写道："ratchet 比较的是跨运行的扫描器计数，审计器必须全部钉版本——规则集更新必须是一次显式的重测量 PR，而不是某天早晨 latest 恰好给了个红或绿"。

3.3 对 Goodhart 定律的解药

"当度量成为目标，它就不再是好度量"——文档把 coverage-as-target 列为经典反模式，并给出四重配重：

mutation testing：测的是"测试能不能抓住 bug"，而不是"行有没有被执行"；配置见 stryker.conf.json（thresholds.high=70 / low=50，nightly 专用，注释明确"不要在每个 PR 上跑"），对应 check-mutation-ratchet.mjs；
check-test-masking（scripts/check/check-test-masking.mjs）：阻止为通过而弱化断言；
per-module coverage floors：8 个高危模块（chatCore/combo/accountFallback/auth/routeGuard/error/publicCreds/circuitBreaker）各有独立地板，逼着团队测难的代码而不是容易的部分；
check-pr-evidence：PR 声称"完成"必须附证据块（Hard Rule #18）。

3.4 反幻觉 / 一致性门（罕见而高价值）

check-known-symbols、check-fetch-targets、check-openapi-routes、check-docs-symbols保证文档、spec 与字符串分发（string dispatch）都指向"活着的符号"，抓住 lint/test 看不见的"腐烂"。这些脚本（如 scripts/check/check-known-symbols.ts、scripts/check/check-fetch-targets.mjs）全部列在 package.json 的check:*scripts 中，并实际编排进 fast-gates 的聚合步骤。

3.5 advisory→blocking 生命周期

新门先以 advisory 进场（不阻塞 merge，边成熟边观察），周期末尾转 blocking。仓库中的大量_flip_blocking_*审计注释（如 codeql、vulnCount、Trivy CRITICAL 门禁从 advisory 转 blocking 的记录）就是这条流水线的运行日志。

3.6 缺基础设施时优雅跳过

扫描器加--ratchet后仍是"只在测到的真实回归时 exit 1"：二进制缺失、网络失败、无授权一律 exit 0。check-secrets.mjs 头部注释把这条规则写成契约："缺基础设施永远不阻塞合法 PR，只有实测回归才阻塞。"这是文档所称"成熟的工程"。

3.7 文化即代码

Hard Rules + trust-but-verify + stale-allowlist（每条抑制都要理由+issue，过期抑制会被抓住）+ evidence-gate，把纪律变成自动化校验。

四、七项诚实的弱点：真实缺口

🔴fast-gates 拆分留下结构性洞：quality.yml（PR→release/**）跑 typecheck、快速确定性测试与 advisory production build，但不跑ci.yml的完整 release-PR 面（coverage ratchets、package artifact、integration、E2E、SonarQube）。动机（速度）合理，但"门应该站在 merge 发生的地方"（shift-left）。这是文档认定的最大待办结构修复——下文第六部分用真实事故佐证。
🟠门膨胀/疲劳风险：约 46 道门 + 25 个 job。Sonar 自己警告条件过多会引发"gate fatigue"，DORA 警告重门侵蚀 lead time。已用 advisory 分层与"非绝对值" ratchet 缓解，但缺按门的周期性 ROI 审查（部分 doc-sync 微门可以合并）。
🟠mutation score 尚未成为 ratchet（撰写时状态）：对 coverage-gaming 最强的解药还是 advisory。它是"价值最高的待办（且已完成约 90%）"。
🟡本应阻塞的 advisory：osv（vulnCount）与oasdiff在基线冻结后仍为 advisory。osv 有中间解（只阻塞 CRITICAL+fixable，像 Trivy 那样两步走）；oasdiff advisory 意味着破坏契约的变更可能溜过。
🟡runtime 安全只在 nightly：schemathesis/garak/promptfoo/chaos/k6 夜间跑（合理：慢、需要活服务），但一个 PR 引入的 injection-guard 回归要等第二天夜里才被抓到。
🟡main分支保护关闭：BRANCH_LOCK_TOKEN锁的是 release 分支，main本身无保护，Scorecard/DSOMM 扣分项，需要仓库 owner 操作。
🟡CodeQL 用 default-setup，semgrep 未入库：default-setup 有效（0 alert），但提交一个codeql.yml可控性更强；semgrep 走外部云平台，未版本化。

五、12 类质量检查点目录（可移植）

以下是文档第三部分的完整目录：每一类给出"保护什么"、OmniRoute 的实际工具、以及任意技术栈可复刻的通用等价物。

1. 风格与格式化（确定性、快速）

OmniRoute：Prettier + ESLint 经 lint-staged（pre-commit），2 空格/双引号/100 列。
通用：一个可自动修复的 formatter + 一个 linter，pre-commit 只对 staged 文件跑。

2. 类型

OmniRoute：typecheck:core（blocking）+typecheck:noimplicit:core（advisory）+type-coverageratchet + per-file any 预算（check:any-budget:t11）。
通用：CI 严格 typecheck + ratcheted type-coverage 指标 + per-fileany/逃生舱预算。

3. 测试（强度）

OmniRoute：两个不重叠的 runner（Node native + vitest）、8 分片、全局覆盖率地板 60/60/60/60 + 覆盖率 ratchet + 8 个关键模块 per-module 地板 + nightly 性质测试 + nightly mutation testing。
通用：test runner +绝对覆盖率地板（防归零）+ 覆盖率ratchet（防回归）+ 高危模块per-module 地板（防 Goodhart）+ 纯逻辑的 property-based 测试 + nightly mutation testing 作为测试质量的真度量。

4. 测试策略（防作弊）

OmniRoute：pr-test-policy（生产代码必须有测试）、check-test-masking（拦截被弱化的断言）、pr-evidence（成功声明必须附证据块）、test-discovery（每个测试都被 runner 收编，无孤儿）。
通用："新代码⇒新测试"门 + 断言删除/恒真检测器 + 证据要求（TDD 或 living test）+ 保证没有测试游离在 glob 之外。

5. 复杂度与代码健康（ratchets）

OmniRoute：ESLint warnings、jscpd 重复率、圈复杂度+max-lines、sonarjs 认知复杂度、knip 死代码、per-file 文件大小（冻结、只缩不涨）、循环依赖（自定义 Tarjan，blocking）。
通用：把每个健康指标都 ratchet 化（warnings、重复率、圈复杂度和认知复杂度、死代码、文件体积、import 环），方向永远是"不许倒退"。

6. 静态安全（SAST + secrets）

OmniRoute：CodeQL（alert ratchet）、gitleaks（[extend] useDefault=true是关键——自定义配置若覆盖默认规则集等于致盲）、SonarQube、项目专属安全规则（public-creds、error-helper、route-guard-membership、route-validation）。
通用：SAST + alert ratchet + 带继承默认规则集的 secrets 扫描器 + 项目级 Hard Rule 安全门。

7. 供应链（依赖）

OmniRoute：osv-scanner + npm-audit + Trivy + Dependabot（SCA）、license-checker（SPDX 白名单）、lockfile-lint（HTTPS+sha512+registry）、check-deps防 slopsquatting（白名单 + 包龄 ≥72h）。
通用：多源 SCA + license 白名单 + lockfile 完整性检查 + 带包龄/typosquatting 检查的依赖白名单 + 分组更新机器人。

8. 供应链（构建与发布）

OmniRoute：SBOM（CycloneDX + syft）、SLSA provenance（--provenance）、OpenSSF Scorecard（每周）、workflow 加固（zizmor：artipacked→persist-credentials:false、cache-poisoning、token-permissions）。
通用：publish 时生成 SBOM + 签名 provenance（SLSA L2+）+ 定时 Scorecard + 全部 workflow 加固（最小权限 token、非 pusher 的 checkout 不保留凭据、actions 按 SHA 固定）。

9. 契约与 API

OmniRoute：oasdiff（OpenAPI breaking-change）、schemathesis（nightly 契约 fuzz）、openapi-coverage（已文档化路由占比，ratchet）、openapi-security-tiers（spec vs route-guard 对齐）。
通用：breaking-change 契约 diff（oasdiff/buf）+ 基于 spec 的 property fuzz + ratcheted 文档覆盖率 + spec↔code 一致性。

10. 文档与 i18n（防腐烂）

OmniRoute：docs-sync（镜像版本）、docs-counts-sync（文档里的数字 vs 代码）、env-doc-sync、doc-links、fabricated-docs、cli-i18n、i18n-ui-coverage（--threshold=65+ ratchet）。
通用：文档与代码间同步版本/计数/环境变量（靠门不靠信任）+ 内部链接校验 + ratcheted i18n 覆盖率。

11. 反幻觉 / 一致性（罕见类别）

OmniRoute：known-symbols（字符串分发⇒活符号）、provider-consistency、fetch-targets（客户端 fetch⇒真实路由）、docs-symbols、db-rules（Hard Rules #2/#5）、migration-numbering。
通用：对每个"重复的事实来源"（注册表、字符串分发、跨层引用）设一道门证明两边一致。抓的是 typecheck/test 看不见的结构腐烂。

12. 韧性与领域（产品专属）

OmniRoute：chaos（故障注入）、heap-growth（泄漏）、k6（浸泡）、promptfoo+garak（LLM 红队，对齐 OWASP LLM Top 10）、韧性三定律（circuit-breaker/cooldown/lockout）。
通用：识别你自己领域的失效模式，每个配一道门（哪怕 nightly）。AI 应用：injection 红队；分布式系统：chaos + 泄漏 + 浸泡。

六、v3.8.27 发布事故：fast-gates 洞的真实代价

文档第六部分记录了一次真实事故，它是第二、三部分抽象警告的具体化。

发生了什么：v3.8.27 的/generate-release生成 release PR（release/v3.8.27→main），这是整合周期内第一次执行完整ci.yml矩阵，结果一次性爆出 12 个失败——其中3 个是确定性测试，其余约 9 个是 flake/环境问题。三者全都不是活的产品回归，但都"隐形"了很久，因为周期 PR 经 fast-gates（quality.yml）进release/**，而该路径不跑完整 unit suite、不跑pr-test-policy（test-masking）、不跑完整 integration suite、不跑 schema parity 检查。

三个确定性失败分别是：

UI 变更让测试过时：permissions modal switch buttons declare button type—— #4034 加了第 4 个 switch（保留 a11ytype="button"），测试里=== 3的计数随之失效。静态分析本应在 #4034 那个 PR 就抓到。
打包变更让测试过时：findMissingArtifactPaths ... root runtime files——dist/http-method-guard.cjs成为合法必需产物，测试的期望列表过期。
有损模块化分歧（最严重）：settings schemas accept ... unprefixed toggle—— 模块化后的updateSettingsSchema（#3988 新建）与规范版settingsSchemas.ts分叉：45 字段 vs 85——丢了 40 个、6 个 divergent（qdrant*）。当时是 dead-code（运行时用规范版），无活影响，但只有手写的 parity 测试抓到了它；#4030 恢复了 #3988/#3993 的 16 个同类 drop，这个却溜了过去。

文档提出的三道新门（Phase 9）：

G1 — 真正堵住 fast-gates 洞（扩展 P0 #2）：在quality.yml（PR→release/**）除 typecheck + impacted tests 外，补跑pr-test-policy（test-masking）+完整确定性 unit suite（或至少静态/parity 文件——快且非 flaky），让过时测试与断言删除在引入它们的 PR 就被抓，而不是发布日。integration/e2e 仍留在外面（慢/flaky），但确定性层绝不能只留在 PR→main。
G2 — 模块化 parity 门（新，现无覆盖）：对每个被模块化 barrel 再导出的符号，比较其 shape（z.objectkeys、registry 条目）与规范来源，dropped/extra field 即失败。它本可以在 #3988 的 PR 内当场抓住 40 字段丢失；本质是把"手写 parity 测试"（只存在于有人记得写它的地方）一般化——实现成本极低：import 两边，diffObject.keys(shape)。
G3 — 确定性 flake 分诊（支撑）：LiveWS-startup 与 integration-combo/breaker 测试因 CI 环境（server 超时/级联）失败，标记为known-flaky（带 issue 隔离），让 release-PR 的红色只剩真实信号，而不是用噪音掩盖中间的确定性回归。

原则回扣：门必须跑在 merge 发生的地方。v3.8.27 证明这条原则适用于确定性测试层，不止 lint/typecheck——否则"过时测试债务 + 有损模块化"会积压到 PR→main，在最坏时刻批量爆发。

七、任意项目的复刻计划（Part 4 完整继承）

7.1 可复用核心："ratchet 门"的三文件解剖

整个系统围绕这个三文件模式转，先抄它：

baseline.json—— 冻结的指标值 +direction（up/down）+eps（防抖）+tightenSlack+dedicatedGate。OmniRoute 实例：config/quality/quality-baseline.json。
collect-metrics.<ext>—— 跑工具、抽数字、写metrics.json。OmniRoute 实例：scripts/quality/collect-metrics.mjs（npm run quality:collect）。
check-ratchet.<ext>—— 比较metrics.json与baseline.json：只有回归超出eps才exit 1；工具/基础设施缺失则exit 0（graceful skip）；加--require-tighten时，指标改善了却未更新基线也exit 1（锁住收益）。OmniRoute 实例：scripts/quality/check-quality-ratchet.mjs（npm run quality:ratchet）。

三件套就位后，任何新指标（coverage、复杂度、warnings、SAST alerts、bundle size、mutation score……）都只是基线里的一行。

7.2 分阶段推进（每阶段独立交付价值）

分阶段构建，不要一次上 12 类——那恰好制造第二部分警告的 gate fatigue。每道新门以advisory进场，稳定后转blocking。

阶段	时间	内容	交付结果
Phase 0 基础	第 1 周	CI 就位；formatter + linter + typecheck + 1 个 test runner +绝对覆盖率地板（如 60%）；pre-commit 跑快速可自动修复检查	没有 PR 能破坏基础
Phase 1 ratchet 引擎	第 2 周（一切的地基）	实现上述 3 文件；为 warnings、coverage、复杂度、重复率、死代码、文件体积冻结基线	从此代码库只能变好
Phase 2 静态深度	第 3 周	SAST（CodeQL/Sonar/semgrep）+ alert ratchet；secrets 扫描器（继承默认规则集）；SCA（osv/Dependabot）+ license 白名单 + lockfile-lint	已知漏洞与泄露 secret 过不了
Phase 3 构建供应链	第 4 周	publish 时 SBOM + 签名 provenance（SLSA L2）+ 定时 Scorecard + workflow 加固（zizmor：最小 token、无持久凭据、actions 钉死）	发布可追溯、抗篡改
Phase 4 测试强度	第 5–6 周	有必要时第 2 个 runner；关键模块 per-module 覆盖率地板（反 Goodhart）；纯逻辑 property-based；nightly mutation testing——第一个 score 到达时就把`mutationScore`做成 ratchet	coverage 不再是 vanity metric；测试被证明能抓 bug
Phase 5 契约与动态	第 7 周	有公开 API 则 oasdiff（breaking-change，blocking）+ schemathesis（nightly fuzz）；按领域 nightly DAST/红队	契约不再静默破裂
Phase 6 反幻觉与领域	第 8 周	每个"重复事实来源"一道 consistency 门；领域专属失效模式门（AI：injection 红队）	结构腐烂与领域失效都有安全网
Phase 7 治理（持续）	持续	每道新门走 advisory→blocking 周期；`stale-allowlist`（每条抑制有理由+issue，过期抑制被抓）；`evidence-gate`（PR 成功声明必须有测试/living test 为证）；每季度按门 ROI 审查（不赚钱的门砍掉/撤资——对抗疲劳）；把项目 Hard Rules 提升为可执行门	治理本身被自动化

7.3 横切原则（不可妥协）

Ratchet，而非绝对值：门"不回归"，不门固定数字（防归零地板除外）。
绝对地板 + ratchet 并用：地板防崩塌，ratchet 防缓慢侵蚀。
反 Goodhart 是设计出来的：每个目标指标都要配重（coverage ⇒ mutation + anti-masking；per-module 地板逼着测难代码）。
Graceful skip：缺基础设施永不阻塞；只有真实回归才阻塞。
昂贵指标用dedicatedGate：需要外部二进制的指标给独立脚本（带 skip），放在同步中央 ratchet 之外。
门站在 merge 发生的地方：不要在快速门与真实 merge 之间留洞（fast-gates 拆分的教训）。
少而精的 blocking 门：Sonar/DORA 都警告条件过多=疲劳。优先 advisory + ratchet，而非 blocking 高墙。

八、推荐改进清单（P0/P1/P2，与现状兼容）

P0 — 最高 ROI，几乎就绪

Mutation score ratchet（等第一个 nightly Stryker 产出数值后）。coverage-Goodhart 的关键解药，撰写时已完成约 90%。从仓库现状看这条已落地：check-mutation-ratchet.mjs 已实现 covered score（detected/(detected+survived)，NoCoverage 剔除出分母）与 1.0 点的 anti-flake eps，config/quality/quality-baseline.json 中已有 28 条mutationScore.*条目（direction: up+dedicatedGate: true），并由 nightly-mutation.yml 聚合触发——与文档"最高价值待办"的预期走向一致。
堵住 fast-gates 剩余洞——production build 经其 advisory 观察周后在quality.yml转正式，并继续把"仅 release-PR 跑"的确定性检查前移到 PR→release 路径。
main分支保护（owner 设置）——提 Scorecard 分，补上 DSOMM 缺口。

P1 — 有价值

osv/oasdiff 转 blocking（范围正确）：osv 只阻塞 CRITICAL+fixable（像 Trivy 那样两步走）；oasdiff 阻塞 breaking-change。
require-tighten转 blocking（周期末尾）——锁住指标收益。当前ci.yml的 quality-gate job 中该步骤已是 blocking（"Require-tighten (blocking)"，.github/workflows/ci.yml）。
按门 ROI/耗时审查（ci-summary）——找到并剪除慢/低价值的门。

P2 — 收益递减

SLSA L3：如需从 L2 上探，配 hermetic/可复现构建器。
提交 CodeQL 配置 + 版本化 semgrep——更多控制与可复现性。
Per-PR DAST smoke：schemathesis/promptfoo 的高风险端点子集（不只 nightly）。
Flakiness 看板 + DORA 指标——确保门没有侵蚀速度。

九、在仓库中验证本体系的入口

关注点	入口文件
指标基线与审计注释	config/quality/quality-baseline.json
通用 ratchet 引擎（eps/tighten/require-tighten/孤儿指标）	scripts/quality/check-quality-ratchet.mjs
指标采集器	scripts/quality/collect-metrics.mjs
PR→release fast-gates（含钉版本扫描器、TIA impacted tests、4 分片 unit）	.github/workflows/quality.yml
release-PR 全矩阵（quality-gate / quality-extended）	.github/workflows/ci.yml
Mutation testing 配置（tap-runner、阈值 70/50、nightly）	stryker.conf.json
Mutation ratchet 检查器	scripts/check/check-mutation-ratchet.mjs
Secrets ratchet（gitleaks、graceful skip）	scripts/check/check-secrets.mjs
测试作弊防护	scripts/check/check-test-masking.mjs
全部`check:`/`quality:`脚本清单	package.json
逐门权威参考（每道门验证什么、CI job、ratchet vs policy、blocking vs advisory）	docs/architecture/QUALITY_GATES.md

最后值得注意的一个"活的证据"：当前基线中的_policy块记录了 2026-08-30 的 owner 决策——进入 velocity 阶段（到 v4.0.0 前所有数值基线统一放宽 20%，requireTighten暂停，headroom 由 nightly 监控，v4.0 收口时重测、收紧、删除该块）。这说明该体系的"治理"不是静态文档，而是会随发布节奏显式松绑、显式收回的动态过程——正是复刻计划 Phase 7 所倡导的形态。

创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考

企业官网建设流程全解析