尧图网站建设 
OmniRoute 测试覆盖率计划COVERAGE_PLAN从 60% 到 90% 的分阶段攀登与棘轮门禁实践【免费下载链接】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, RTKCaveman compression saves 15-95% tokens, MCP/A2A, Desktop/PWA. Built by 550 contributors项目地址: https://gitcode.com/GitHub_Trending/om/OmniRoute本文以 OmniRoute 仓库中的 Test Coverage Plan及其多语言镜像 docs/i18n/pl/docs/ops/COVERAGE_PLAN.md为骨架结合仓库内覆盖率脚本、质量基线配置与真实源码系统讲解 OmniRoute 如何围绕 statements / lines 覆盖率设置单一权威基线、规划 7 个里程碑阶段、定位低覆盖热点文件并通过棘轮ratchet机制让覆盖率只升不降。读完本文你将掌握一套可直接复用的覆盖率分阶段治理方法论以及 OmniRoute 中每条覆盖率命令、每个质量门禁的真实出处与用法。覆盖率数字不止一个为什么规划只能用一条推荐基线COVERAGE_PLAN 开篇就点明一个常见陷阱同一个项目会因为统计口径不同而得到多个覆盖率数字。OmniRoute 将报告分为三种口径只有其中一种对规划有用指标口径范围Statements / LinesBranchesFunctions说明Legacy历史口径旧的npm run test:coverage79.42%75.15%67.94%虚高把测试文件也计入统计且排除了open-sseDiagnostic诊断口径仅源码排除测试与open-sse68.16%63.55%64.06%只用于隔离观察src/**Recommended baseline推荐基线仅源码、排除测试、包含open-sse82.58%75.22%84.23%项目级优化所依据的正式基线这组数字是 2026-05-13 实测的状态。需要特别注意的是文档在棘轮策略一节明确说明最初测得 82.58% 的基线其实虚高——因为旧口径把tests/**也计入了分母同时又排除了产品代码open-sse/**。Quality-Gates 6A.1 阶段对指标做了重基线rebased把口径修正为只数源码、包含 open-sse当前npm run test:coverage强制执行的硬性门槛因此是60 statements / 60 lines / 60 functions / 60 branches。这一修正正好印证了基线口径选择的重要性先定对量什么再谈量到多少。五条覆盖范围规则什么该测、什么不该测覆盖率目标只针对源文件不针对tests/**自身。open-sse/**是产品的一部分必须始终留在统计范围内。新代码不得降低所触及区域的覆盖率。优先测试行为与分支结果而非实现细节。对于src/lib/db/**优先使用临时 SQLite 数据库 小型 fixture而不是大范围 mock。这些规则在 collect-metrics.mjs 中也有呼应覆盖率指标coverage.statements/coverage.lines/coverage.functions/coverage.branches读取 c8 生成的coverage/coverage-summary.json并额外为 8 个关键模块chatCore、combo、accountFallback、auth、routeGuard、error、publicCreds、circuitBreaker提取按模块的行覆盖率下限例如coverage.chatCore.lines、coverage.routeGuard.lines等。这说明分模块设置下限与全局单一口径是并行的两层治理。当前命令集三条命令的职责分工在 package.json 中可找到全部三条命令的真实定义npm run test:coverage—— 单元测试套件的主覆盖门禁生成text-summary、html、json-summary、lcov四种报告。真实参数为 c8 的--merge-async --output-dir coverage --excludetests/** --exclude**/*.test.* --check-coverage --statements 60 --lines 60 --functions 60 --branches 60即四个维度均以 60% 为硬性检查线。npm run coverage:report—— 基于最近一次运行生成逐文件明细报告同样是--excludetests/**、--exclude**/*.test.*输出text与text-summary。npm run test:coverage:legacy—— 仅用于历史对比参数为--excludeopen-sse --lines 50 --functions 50 --branches 50即旧口径的 50/50/50 门槛。此外还有npm run coverage:summary调用 scripts/check/test-report-summary.mjs把coverage/coverage-summary.json渲染为 Markdown 报告coverage/coverage-report.md。该脚本本身就是一个轻量门禁工具对 lines / statements / functions / branches 四项做阈值校验输出 Gate PASS/FAIL、总量表以及按行覆盖率升序排列的最低覆盖文件 Top 15每个文件带 Lines / Branches / Functions / Missing Lines 四列并支持--threshold全局阈值与--lines/--branches/--functions/--statements分项阈值。七个里程碑60% → 90% 的分阶段路线主硬性目标是statements / linesbranches 与 functions 随每个阶段以棘轮方式同步上移但不作为首要攻坚对象。阶段目标statements / lines聚焦方向状态Phase 160%快速取胜项与低风险 utility 覆盖✅ 完成Phase 265%DB 与路由地基✅ 完成Phase 370%Provider 校验与用量分析✅ 完成Phase 475%open-sse翻译器与 helpers✅ 完成Phase 580%open-ssehandlers 与 executor 分支✅ 完成Phase 685%更难的 edge case、分支债务、回归套件⏳ 进行中Phase 790%终盘扫尾、补漏、严格棘轮⏸ 待启动截至文档记录2026-06-28Phase 1–5 已全部完成当前焦点是 Phase 6≥85%与 Phase 7≥90%。优先热点20 个最低覆盖文件 60% 行覆盖以下清单生成自coverage/coverage-summary.json2026-05-13是 Phase 6–7 投资回报率最高的攻坚对象#文件Lines %1open-sse/services/compression/validation.ts7.87%2src/app/api/v1/batches/route.ts9.67%3src/app/docs/components/FeedbackWidget.tsx9.80%4open-sse/services/compression/toolResultCompressor.ts10.00%5src/app/docs/components/DocCodeBlocks.tsx10.63%6open-sse/services/compression/engines/rtk/lineFilter.ts10.96%7open-sse/services/specificityRules.ts11.28%8src/mitm/systemCommands.ts12.19%9open-sse/services/compression/aggressive.ts12.77%10src/app/api/v1/batches/[id]/cancel/route.ts12.98%11open-sse/services/compression/progressiveAging.ts13.26%12open-sse/services/compression/engines/rtk/smartTruncate.ts13.43%13open-sse/services/compression/engines/rtk/deduplicator.ts13.51%14src/lib/cloudAgent/agents/jules.ts13.52%15open-sse/services/compression/lite.ts14.46%16src/app/api/v1/rerank/route.ts14.94%17open-sse/services/compression/preservation.ts15.07%18src/lib/cloudAgent/agents/codex.ts15.54%19open-sse/services/tierResolver.ts16.66%20src/app/docs/components/DocsLazyWrapper.tsx16.66%从这份清单可以提炼出四条攻坚主线也是文档明确归纳的主题open-sse/services/compression/**是密度最高的低覆盖簇占据了剩余缺口的绝对大头。以榜首 validation.ts 为例其核心导出validateCompression(original, compressed)是压缩保真度校验器会逐项核对原文中的 fenced code block、inline code、URL、markdown 链接、frontmatter、标题、表格行、数学块、LaTeX 块、版本号、CONST_CASE 标识是否在压缩结果中完整保留并校验代码块计数不丢失。这种扫描器 正则 边界判断型模块分支极多是典型的低覆盖高风险区——但它已有配套测试 tests/unit/compression/validation.test.ts说明攻坚路径是把已有测试进一步做厚而非从零补测。Batch 与 rerank API 路由src/app/api/v1/batches/**、src/app/api/v1/rerank/route.ts需要 handler 级测试。Cloud agent 适配器src/lib/cloudAgent/agents/jules.ts、codex.ts与open-sse/services/tierResolver.ts需要场景化测试。Docs UI 组件与src/mitm/systemCommands.ts优先级较低但分支覆盖是廉价赢取项。分阶段执行检查清单可以直接照做的补测地图Phase 156.95% → 60%修正覆盖率指标使其反映源码而非测试文件保留 legacy 覆盖率脚本用于对比在仓库中记录基线与热点为低风险 utility 添加定向测试src/shared/utils/upstreamError.ts、src/shared/utils/fetchTimeout.ts、src/lib/api/errorResponse.ts、src/shared/utils/apiAuth.ts、src/lib/display/names.ts添加路由测试src/app/api/settings/require-login/route.ts、src/app/api/providers/[id]/models/route.tsPhase 260% → 65%添加基于 DB 的测试src/lib/db/modelComboMappings.ts、src/lib/db/settings.ts、src/lib/db/registeredKeys.ts覆盖分支行为src/lib/providers/validation.ts、src/app/api/v1/embeddings/route.ts、src/app/api/v1/moderations/route.tsPhase 365% → 70%添加用量分析测试src/lib/usage/usageHistory.ts、src/lib/usage/usageStats.ts、src/lib/usage/costCalculator.ts扩展 proxy 管理与设置分支的路由覆盖Phase 470% → 75%覆盖翻译器 helpers 与核心翻译路径open-sse/translator/index.ts、open-sse/translator/helpers/*、open-sse/translator/request/*、open-sse/translator/response/*Phase 575% → 80%添加 handler 级测试open-sse/handlers/chatCore.ts、open-sse/handlers/responsesHandler.js、open-sse/handlers/imageGeneration.js、open-sse/handlers/embeddings.js添加 executor 分支覆盖provider 专属 auth、重试、endpoint 覆盖Phase 680% → 85%将更多 edge-case 套件并入主覆盖路径提升 DB 模块构造函数 / helper 覆盖薄弱的函数覆盖闭合settings.ts、registeredKeys.ts、validation.ts及翻译器 helpers 中的分支缺口Phase 785% → 90%将剩余低覆盖文件视为 blocker为冲刺 90% 期间修复的每个未被覆盖的生产 bug 添加回归测试只有当本地基线连续两次运行保持稳定后才在 CI 中上调覆盖率门禁棘轮策略让覆盖率只升不降棘轮ratchet是本计划的核心机制其原则是只有项目真正越过下一个里程碑且留出舒适余量后才更新npm run test:coverage的阈值。当前门禁npm run test:coverage强制60 statements / 60 lines / 60 functions / 60 branches如前所述这是 6A.1 重基线后的真实口径test:coverage:legacy保留旧口径 50/50/50 仅供历史比较。临时阈值检查对最新报告做临时性门槛校验使用node scripts/check/test-report-summary.mjs --threshold 75该脚本即 test-report-summary.mjs以--threshold 75为全局默认四项指标分别比较branches 在未传--threshold时默认 70输出 Gate PASS/FAIL 与 Top 15 低覆盖文件。推荐的棘轮序列顺序为statements-lines / branches / functions55/60/5560/62/5865/64/6270/66/6675/70/72 ← 当前门禁位置文档同时注明当前为 75/70/7580/75/7885/80/8490/85/88下一步目标当分支覆盖连续两次运行保持在 78% 以上后将棘轮推进到80/75/78。与质量门禁体系的联动棘轮不止在覆盖率一个维度COVERAGE_PLAN 是 OmniRoute 更庞大的质量门禁体系详见 docs/architecture/QUALITY_GATES.md中的一环。覆盖率数字最终汇入 config/quality/quality-baseline.jsoncoverage.statements/coverage.lines/coverage.functions/coverage.branches均为direction: up的棘轮指标——只许涨、不许跌quality:ratchet门禁由 scripts/quality/check-quality-ratchet.mjs 执行会把实测值与此基线对比任何回落都会让构建失败。8 个关键模块的coverage.module.lines下限同样以direction: up方式冻结在基线中例如coverage.chatCore.lines、coverage.routeGuard.lines。覆盖率收集由npm run quality:collectscripts/quality/collect-metrics.mjs完成它读取coverage/coverage-summary.json输出coverage.statements等全局指标与按模块指标供棘轮引擎消费。需要注意的是该基线文件记录了 2026-08-30 生效的velocity 阶段政策_policy.phase: velocity直至 v4.0 LTS所有数值型基线一次性放宽 20%其中coverage.statements/coverage.lines由 80.8 下调至 67.33coverage.branches由 78.1 下调至 65.08coverage.functions由 86.42 下调至 72.02。这与文档记录的硬性门禁 60/60/60/60 并存基线是现状冻结门禁是允许下限两者服务于不同目的。velocity 阶段结束后会按计划重新收紧。此外tests/**自身也受防护PR 修改src/、open-sse/、electron/或bin/下的产品代码时check:pr-test-policy强制要求改产品代码必须同步补/改测试check:test-masking禁止净减少断言数或添加assert.ok(true)之类的空断言。这些策略与 COVERAGE_PLAN 形成互补覆盖率棘轮保证存量不退化PR 测试策略保证增量必带测试。已知缺口Vitest 覆盖率尚未并入统一报告文档在结尾诚实记录了当前覆盖工具的局限现有覆盖率命令测量的是主 Node 单元测试套件包含从其可达的所有源码包括open-sse但尚未把 VitestMCP server、UI 组件等套件的覆盖率合并进同一个统一报告。合并工作值得后续做但不是启动 60% → 80% 攀登的 blocker——换言之团队选择了先用单一口径把主套件做扎实再扩展口径覆盖其余运行器的务实次序。这一点对于复制该方案的其他项目同样具有参考价值先锁定一个权威数字并让它持续上升比一开始就追求多运行器的全景合并更重要。小结一套可复制的覆盖率治理范式从 OmniRoute 的 COVERAGE_PLAN 可以提炼出四条可迁移到任何项目的实践1只认一条权威基线主动修正会虚高的统计口径避免被漂亮的假数字误导2把大目标切成 60%→90% 的七个阶段每个阶段有明确的文件级攻坚清单3用热点表指导投入先打密度最高、回报最大的低覆盖簇本项目即 compression 服务4用棘轮冻结进步配合quality-baseline.json、check-quality-ratchet.mjs与test-report-summary.mjs让覆盖率只涨不跌、稳健爬升。这套阶段 热点 棘轮的组合正是 OmniRoute 将覆盖率治理从口号变成 CI 中可执行门禁的关键。【免费下载链接】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, RTKCaveman compression saves 15-95% tokens, MCP/A2A, Desktop/PWA. Built by 550 contributors项目地址: https://gitcode.com/GitHub_Trending/om/OmniRoute创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考 OmniRoute 测试覆盖率计划（COVERAGE_PLAN）：从 60% 到 90% 的分阶段攀登与棘轮门禁实践
OmniRoute 测试覆盖率计划COVERAGE_PLAN从 60% 到 90% 的分阶段攀登与棘轮门禁实践【免费下载链接】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, RTKCaveman compression saves 15-95% tokens, MCP/A2A, Desktop/PWA. Built by 550 contributors项目地址: https://gitcode.com/GitHub_Trending/om/OmniRoute本文以 OmniRoute 仓库中的 Test Coverage Plan及其多语言镜像 docs/i18n/pl/docs/ops/COVERAGE_PLAN.md为骨架结合仓库内覆盖率脚本、质量基线配置与真实源码系统讲解 OmniRoute 如何围绕 statements / lines 覆盖率设置单一权威基线、规划 7 个里程碑阶段、定位低覆盖热点文件并通过棘轮ratchet机制让覆盖率只升不降。读完本文你将掌握一套可直接复用的覆盖率分阶段治理方法论以及 OmniRoute 中每条覆盖率命令、每个质量门禁的真实出处与用法。覆盖率数字不止一个为什么规划只能用一条推荐基线COVERAGE_PLAN 开篇就点明一个常见陷阱同一个项目会因为统计口径不同而得到多个覆盖率数字。OmniRoute 将报告分为三种口径只有其中一种对规划有用指标口径范围Statements / LinesBranchesFunctions说明Legacy历史口径旧的npm run test:coverage79.42%75.15%67.94%虚高把测试文件也计入统计且排除了open-sseDiagnostic诊断口径仅源码排除测试与open-sse68.16%63.55%64.06%只用于隔离观察src/**Recommended baseline推荐基线仅源码、排除测试、包含open-sse82.58%75.22%84.23%项目级优化所依据的正式基线这组数字是 2026-05-13 实测的状态。需要特别注意的是文档在棘轮策略一节明确说明最初测得 82.58% 的基线其实虚高——因为旧口径把tests/**也计入了分母同时又排除了产品代码open-sse/**。Quality-Gates 6A.1 阶段对指标做了重基线rebased把口径修正为只数源码、包含 open-sse当前npm run test:coverage强制执行的硬性门槛因此是60 statements / 60 lines / 60 functions / 60 branches。这一修正正好印证了基线口径选择的重要性先定对量什么再谈量到多少。五条覆盖范围规则什么该测、什么不该测覆盖率目标只针对源文件不针对tests/**自身。open-sse/**是产品的一部分必须始终留在统计范围内。新代码不得降低所触及区域的覆盖率。优先测试行为与分支结果而非实现细节。对于src/lib/db/**优先使用临时 SQLite 数据库 小型 fixture而不是大范围 mock。这些规则在 collect-metrics.mjs 中也有呼应覆盖率指标coverage.statements/coverage.lines/coverage.functions/coverage.branches读取 c8 生成的coverage/coverage-summary.json并额外为 8 个关键模块chatCore、combo、accountFallback、auth、routeGuard、error、publicCreds、circuitBreaker提取按模块的行覆盖率下限例如coverage.chatCore.lines、coverage.routeGuard.lines等。这说明分模块设置下限与全局单一口径是并行的两层治理。当前命令集三条命令的职责分工在 package.json 中可找到全部三条命令的真实定义npm run test:coverage—— 单元测试套件的主覆盖门禁生成text-summary、html、json-summary、lcov四种报告。真实参数为 c8 的--merge-async --output-dir coverage --excludetests/** --exclude**/*.test.* --check-coverage --statements 60 --lines 60 --functions 60 --branches 60即四个维度均以 60% 为硬性检查线。npm run coverage:report—— 基于最近一次运行生成逐文件明细报告同样是--excludetests/**、--exclude**/*.test.*输出text与text-summary。npm run test:coverage:legacy—— 仅用于历史对比参数为--excludeopen-sse --lines 50 --functions 50 --branches 50即旧口径的 50/50/50 门槛。此外还有npm run coverage:summary调用 scripts/check/test-report-summary.mjs把coverage/coverage-summary.json渲染为 Markdown 报告coverage/coverage-report.md。该脚本本身就是一个轻量门禁工具对 lines / statements / functions / branches 四项做阈值校验输出 Gate PASS/FAIL、总量表以及按行覆盖率升序排列的最低覆盖文件 Top 15每个文件带 Lines / Branches / Functions / Missing Lines 四列并支持--threshold全局阈值与--lines/--branches/--functions/--statements分项阈值。七个里程碑60% → 90% 的分阶段路线主硬性目标是statements / linesbranches 与 functions 随每个阶段以棘轮方式同步上移但不作为首要攻坚对象。阶段目标statements / lines聚焦方向状态Phase 160%快速取胜项与低风险 utility 覆盖✅ 完成Phase 265%DB 与路由地基✅ 完成Phase 370%Provider 校验与用量分析✅ 完成Phase 475%open-sse翻译器与 helpers✅ 完成Phase 580%open-ssehandlers 与 executor 分支✅ 完成Phase 685%更难的 edge case、分支债务、回归套件⏳ 进行中Phase 790%终盘扫尾、补漏、严格棘轮⏸ 待启动截至文档记录2026-06-28Phase 1–5 已全部完成当前焦点是 Phase 6≥85%与 Phase 7≥90%。优先热点20 个最低覆盖文件 60% 行覆盖以下清单生成自coverage/coverage-summary.json2026-05-13是 Phase 6–7 投资回报率最高的攻坚对象#文件Lines %1open-sse/services/compression/validation.ts7.87%2src/app/api/v1/batches/route.ts9.67%3src/app/docs/components/FeedbackWidget.tsx9.80%4open-sse/services/compression/toolResultCompressor.ts10.00%5src/app/docs/components/DocCodeBlocks.tsx10.63%6open-sse/services/compression/engines/rtk/lineFilter.ts10.96%7open-sse/services/specificityRules.ts11.28%8src/mitm/systemCommands.ts12.19%9open-sse/services/compression/aggressive.ts12.77%10src/app/api/v1/batches/[id]/cancel/route.ts12.98%11open-sse/services/compression/progressiveAging.ts13.26%12open-sse/services/compression/engines/rtk/smartTruncate.ts13.43%13open-sse/services/compression/engines/rtk/deduplicator.ts13.51%14src/lib/cloudAgent/agents/jules.ts13.52%15open-sse/services/compression/lite.ts14.46%16src/app/api/v1/rerank/route.ts14.94%17open-sse/services/compression/preservation.ts15.07%18src/lib/cloudAgent/agents/codex.ts15.54%19open-sse/services/tierResolver.ts16.66%20src/app/docs/components/DocsLazyWrapper.tsx16.66%从这份清单可以提炼出四条攻坚主线也是文档明确归纳的主题open-sse/services/compression/**是密度最高的低覆盖簇占据了剩余缺口的绝对大头。以榜首 validation.ts 为例其核心导出validateCompression(original, compressed)是压缩保真度校验器会逐项核对原文中的 fenced code block、inline code、URL、markdown 链接、frontmatter、标题、表格行、数学块、LaTeX 块、版本号、CONST_CASE 标识是否在压缩结果中完整保留并校验代码块计数不丢失。这种扫描器 正则 边界判断型模块分支极多是典型的低覆盖高风险区——但它已有配套测试 tests/unit/compression/validation.test.ts说明攻坚路径是把已有测试进一步做厚而非从零补测。Batch 与 rerank API 路由src/app/api/v1/batches/**、src/app/api/v1/rerank/route.ts需要 handler 级测试。Cloud agent 适配器src/lib/cloudAgent/agents/jules.ts、codex.ts与open-sse/services/tierResolver.ts需要场景化测试。Docs UI 组件与src/mitm/systemCommands.ts优先级较低但分支覆盖是廉价赢取项。分阶段执行检查清单可以直接照做的补测地图Phase 156.95% → 60%修正覆盖率指标使其反映源码而非测试文件保留 legacy 覆盖率脚本用于对比在仓库中记录基线与热点为低风险 utility 添加定向测试src/shared/utils/upstreamError.ts、src/shared/utils/fetchTimeout.ts、src/lib/api/errorResponse.ts、src/shared/utils/apiAuth.ts、src/lib/display/names.ts添加路由测试src/app/api/settings/require-login/route.ts、src/app/api/providers/[id]/models/route.tsPhase 260% → 65%添加基于 DB 的测试src/lib/db/modelComboMappings.ts、src/lib/db/settings.ts、src/lib/db/registeredKeys.ts覆盖分支行为src/lib/providers/validation.ts、src/app/api/v1/embeddings/route.ts、src/app/api/v1/moderations/route.tsPhase 365% → 70%添加用量分析测试src/lib/usage/usageHistory.ts、src/lib/usage/usageStats.ts、src/lib/usage/costCalculator.ts扩展 proxy 管理与设置分支的路由覆盖Phase 470% → 75%覆盖翻译器 helpers 与核心翻译路径open-sse/translator/index.ts、open-sse/translator/helpers/*、open-sse/translator/request/*、open-sse/translator/response/*Phase 575% → 80%添加 handler 级测试open-sse/handlers/chatCore.ts、open-sse/handlers/responsesHandler.js、open-sse/handlers/imageGeneration.js、open-sse/handlers/embeddings.js添加 executor 分支覆盖provider 专属 auth、重试、endpoint 覆盖Phase 680% → 85%将更多 edge-case 套件并入主覆盖路径提升 DB 模块构造函数 / helper 覆盖薄弱的函数覆盖闭合settings.ts、registeredKeys.ts、validation.ts及翻译器 helpers 中的分支缺口Phase 785% → 90%将剩余低覆盖文件视为 blocker为冲刺 90% 期间修复的每个未被覆盖的生产 bug 添加回归测试只有当本地基线连续两次运行保持稳定后才在 CI 中上调覆盖率门禁棘轮策略让覆盖率只升不降棘轮ratchet是本计划的核心机制其原则是只有项目真正越过下一个里程碑且留出舒适余量后才更新npm run test:coverage的阈值。当前门禁npm run test:coverage强制60 statements / 60 lines / 60 functions / 60 branches如前所述这是 6A.1 重基线后的真实口径test:coverage:legacy保留旧口径 50/50/50 仅供历史比较。临时阈值检查对最新报告做临时性门槛校验使用node scripts/check/test-report-summary.mjs --threshold 75该脚本即 test-report-summary.mjs以--threshold 75为全局默认四项指标分别比较branches 在未传--threshold时默认 70输出 Gate PASS/FAIL 与 Top 15 低覆盖文件。推荐的棘轮序列顺序为statements-lines / branches / functions55/60/5560/62/5865/64/6270/66/6675/70/72 ← 当前门禁位置文档同时注明当前为 75/70/7580/75/7885/80/8490/85/88下一步目标当分支覆盖连续两次运行保持在 78% 以上后将棘轮推进到80/75/78。与质量门禁体系的联动棘轮不止在覆盖率一个维度COVERAGE_PLAN 是 OmniRoute 更庞大的质量门禁体系详见 docs/architecture/QUALITY_GATES.md中的一环。覆盖率数字最终汇入 config/quality/quality-baseline.jsoncoverage.statements/coverage.lines/coverage.functions/coverage.branches均为direction: up的棘轮指标——只许涨、不许跌quality:ratchet门禁由 scripts/quality/check-quality-ratchet.mjs 执行会把实测值与此基线对比任何回落都会让构建失败。8 个关键模块的coverage.module.lines下限同样以direction: up方式冻结在基线中例如coverage.chatCore.lines、coverage.routeGuard.lines。覆盖率收集由npm run quality:collectscripts/quality/collect-metrics.mjs完成它读取coverage/coverage-summary.json输出coverage.statements等全局指标与按模块指标供棘轮引擎消费。需要注意的是该基线文件记录了 2026-08-30 生效的velocity 阶段政策_policy.phase: velocity直至 v4.0 LTS所有数值型基线一次性放宽 20%其中coverage.statements/coverage.lines由 80.8 下调至 67.33coverage.branches由 78.1 下调至 65.08coverage.functions由 86.42 下调至 72.02。这与文档记录的硬性门禁 60/60/60/60 并存基线是现状冻结门禁是允许下限两者服务于不同目的。velocity 阶段结束后会按计划重新收紧。此外tests/**自身也受防护PR 修改src/、open-sse/、electron/或bin/下的产品代码时check:pr-test-policy强制要求改产品代码必须同步补/改测试check:test-masking禁止净减少断言数或添加assert.ok(true)之类的空断言。这些策略与 COVERAGE_PLAN 形成互补覆盖率棘轮保证存量不退化PR 测试策略保证增量必带测试。已知缺口Vitest 覆盖率尚未并入统一报告文档在结尾诚实记录了当前覆盖工具的局限现有覆盖率命令测量的是主 Node 单元测试套件包含从其可达的所有源码包括open-sse但尚未把 VitestMCP server、UI 组件等套件的覆盖率合并进同一个统一报告。合并工作值得后续做但不是启动 60% → 80% 攀登的 blocker——换言之团队选择了先用单一口径把主套件做扎实再扩展口径覆盖其余运行器的务实次序。这一点对于复制该方案的其他项目同样具有参考价值先锁定一个权威数字并让它持续上升比一开始就追求多运行器的全景合并更重要。小结一套可复制的覆盖率治理范式从 OmniRoute 的 COVERAGE_PLAN 可以提炼出四条可迁移到任何项目的实践1只认一条权威基线主动修正会虚高的统计口径避免被漂亮的假数字误导2把大目标切成 60%→90% 的七个阶段每个阶段有明确的文件级攻坚清单3用热点表指导投入先打密度最高、回报最大的低覆盖簇本项目即 compression 服务4用棘轮冻结进步配合quality-baseline.json、check-quality-ratchet.mjs与test-report-summary.mjs让覆盖率只涨不跌、稳健爬升。这套阶段 热点 棘轮的组合正是 OmniRoute 将覆盖率治理从口号变成 CI 中可执行门禁的关键。【免费下载链接】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, RTKCaveman compression saves 15-95% tokens, MCP/A2A, Desktop/PWA. Built by 550 contributors项目地址: https://gitcode.com/GitHub_Trending/om/OmniRoute创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考