OmniRoute 发布检查清单实战指南从版本号到 npm 产物的一次性正确发布【免费下载链接】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 仓库的发布检查清单docs/i18n/da/docs/ops/RELEASE_CHECKLIST.md及英文完整版 docs/ops/RELEASE_CHECKLIST.md为核心骨架结合仓库内真实脚本源码讲解在打 tag、发布新版本之前必须完成的全部校验动作版本号与 Changelog 同步、OpenAPI 契约核对、Node.js 安全基线、npm 发布产物洁净度以及check:docs-sync自动化同步守卫。读完本文你将掌握 OmniRoute 一整套可执行、可验证的发布前操作流并能对照源码理解每一项检查背后的实现原理。一、这份清单在做什么发布前的最终防线OmniRoute 是一个 MIT 开源的统一 AI 网关项目package.json 描述为 Unified AI router聚合大量 provider 与模型同时对外发布 npm 包、Docker 镜像、Electron 桌面端和文档站。由于发布面广任何一处版本号漂移、文档失同步或残留本地文件泄漏进 npm 包都会直接影响用户升级体验与包体完整性。发布检查清单Release Checklist就是为此设计的最终防线在打 tag 或发布新版本之前逐项核对。丹麦语版本清单将其归纳为四大部分Version and Changelog—— 版本号与变更日志同步API Docs—— OpenAPI 文档版本契约Runtime Docs—— 运行时文档与 Node.js 安全基线、发布产物检查Automated Check—— 自动化同步守卫npm run check:docs-sync。这四部分在仓库中不是孤立的手工清单而是有真实脚本背书的可执行检查项。下文将逐节展开并给出每项检查对应的源码实现位置。二、版本号与 Changelog三处必须一致的版本契约清单原文要求Version and Changelog在 release 分支中提升package.json的版本号x.y.z将CHANGELOG.md中## [Unreleased]下的发布说明移动到一个带日期的版本小节## [x.y.z] — YYYY-MM-DD保持## [Unreleased]作为 Changelog 的第一小节用于承接后续工作确保CHANGELOG.md中最新的 semver 小节与package.json版本号一致。这条规则之所以是硬性要求是因为它在仓库里由npm run check:docs-sync以代码强制校验脚本 scripts/check/check-docs-sync.mjs读取 package.json 的version字段并用 semver 正则校验格式X.Y.Z或X.Y.Z-prerelease.N解析 CHANGELOG.md要求第一小节必须是## [Unreleased]过滤出所有 semver 版本小节要求最新一个小节的版本号与package.json完全相等。一旦CHANGELOG.md最新版本节与package.json不一致脚本即输出[docs-sync] FAIL - Latest changelog release (X.Y.Z) differs from package.json (X.Y.Z)并以非零退出码失败。也就是说版本号不是随便一改就完事它必须同时驱动 changelog 重构。英文完整版清单 docs/ops/RELEASE_CHECKLIST.md 进一步补充了实操方式通过 Claude Code skill/version-bump-cc patch|minor|major一次完成package.json、electron/package.json的版本提升、从最近 tag 以来的 git 提交重新生成CHANGELOG.md、并更新 README 徽章。当前仓库版本为3.8.51见 package.json 与 docs/openapi.yaml。三、API 文档OpenAPI 版本必须与 package.json 严格相等清单API Docs一节要求更新docs/openapi.yaml使其info.version必须等于package.json的版本号如果 API 契约发生变化需要验证端点示例endpoint examples。这里需要留意一个仓库内路径约定清单中写的是docs/reference/openapi.yaml而实际仓库根目录的 OpenAPI 定义位于 docs/openapi.yaml同时 public/openapi.yaml 也有一份用于站点分发check:docs-sync脚本校验的正是根目录docs/openapi.yaml。以实际仓库为准。info.version与package.json版本的一致性不是建议而是check:docs-sync的强制检查项check-docs-sync.mjs 会解析 OpenAPI 文件中的info:块并提取version字段与package.json的version逐字比对不一致即 FAIL。当前两份文件均为3.8.51保持一致。从源码角度看OpenAPI 契约的严肃性还体现在一系列专项检查脚本上见 package.json 的 scripts 区check:openapi-coverage—— 校验路由覆盖check:openapi-routes—— 校验 OpenAPI 中的路由与实际代码路由一致check:openapi-breaking—— 检测 API 破坏性变更check:openapi-security-tiers—— 校验安全分级。也就是说发布前若 API 有改动除了手工更新info.version还需要跑完这一组 OpenAPI 专项检查确保契约、路由、安全分级三者与代码一致。四、运行时文档与 Node.js 安全基线发布环境的版本下限清单Runtime Docs一节要求发布前完成五件事检查 docs/architecture/ARCHITECTURE.md 是否存在存储/运行时漂移storage/runtime drift检查 docs/guides/TROUBLESHOOTING.md 是否存在环境变量与运维层面的漂移验证发布/运行时 Node.js 版本仍满足受支持的安全下限20.20.2 21或22.22.2 23丹麦语清单中的表述并运行npm run check:node-runtime在构建独立包后校验 npm 发布产物npm run build:clinpm run check:pack-artifact确认没有app.__qa_backup、scripts/scratch、package-lock.json等本地残留文件混入包内如果源文档发生重大变更更新本地化文档。4.1 Node.js 安全基线的真实定义丹麦语清单中给出的 Node.js 范围20.20.2 21或22.22.2 23是文档翻译时点的快照仓库当前的实际策略以单一事实源src/shared/utils/nodeRuntimeSupport.ts 为准export const SECURE_NODE_LINES Object.freeze([ Object.freeze({ major: 22, minor: 22, patch: 2 }), Object.freeze({ major: 24, minor: 0, patch: 0 }), Object.freeze({ major: 25, minor: 0, patch: 0 }), Object.freeze({ major: 26, minor: 0, patch: 0 }), ]); export const RECOMMENDED_NODE_VERSION 24.14.1; export const SUPPORTED_NODE_RANGE 22.22.2 23 || 24.0.0 27;该策略同时写入了 package.json 的engines字段node: 22.22.2 23 || 24.0.0 27。从源码看版本判断逻辑为解析当前 Node 主版本 → 在SECURE_NODE_LINES中查找对应主版本的安全下限→ 当前版本低于该下限则判定为below-security-floor不支持并输出警告。也就是说每个受支持的 LTS 主版本线都有自己的补丁安全下限低于下限即被拒绝这正是secure floor安全下限的含义。npm run check:node-runtime对应脚本 scripts/check/check-supported-node-runtime.ts它调用上面的策略模块不兼容时打印警告并以退出码 1 失败兼容时输出类似Node.js v24.x satisfies OmniRoute secure runtime policy的成功信息且额外支持 Bun 运行时判定Bun 1.1也视为满足策略。4.2 npm 发布产物校验不让本地残留泄漏进包里清单要求构建独立包后执行npm run build:cli npm run check:pack-artifactbuild:cli对应 scripts/build/prepublish.ts负责打包发布前所需的 CLI 独立产物check:pack-artifact对应 scripts/build/validate-pack-artifact.ts它通过 scripts/build/pack-artifact-policy.ts 中定义的允许路径白名单PACK_ARTIFACT_ALLOWED_EXACT_PATHS、PACK_ARTIFACT_ALLOWED_PATH_PREFIXES和必需路径清单PACK_ARTIFACT_REQUIRED_PATHS对发布产物做双向检查检查是否存在不应出现的意外路径如app.__qa_backup、scripts/scratch、package-lock.json等本地残留检查必需的产物路径是否齐全。除此之外validate-pack-artifact.ts还会调用buildProvenance.ts校验构建出处build provenance并借助mcpPublishedFilesClosure.ts检查 MCP 文件闭包是否存在泄漏的测试产物findLeakedTestArtifactPaths与缺失的闭包路径。这套机制从白名单 必需清单 出处校验三个维度保证了 npm 包只包含应该发布的内容。英文完整版清单还补充了单项命令npm run build:release组合了rm -rf .build dist清理、next build生成中间产物、assembleStandalone汇总独立产物、写入dist/BUILD_SHA哨兵并强调发布部署不要分别跑npm run build和npm run build:cli而应使用一条build:release完成干净重建 哨兵写入部署前还需确认dist/BUILD_SHA等于git rev-parse --short HEAD。五、自动化同步检查check:docs-sync 与 CI 集成清单Automated Check一节要求在开 PR 前本地运行同步守卫npm run check:docs-sync并且 CI 也会在.github/workflows/ci.yml的 lint job 中运行此检查。这个守卫就是 scripts/check/check-docs-sync.mjs它实际上是一个文档版本同步的总闸门除前文提到的三处版本契约外还承担两类 i18n 镜像校验严格镜像llm.txtdocs/i18n/locale/llm.txt必须与根目录 llm.txt 逐字节一致该文件不做翻译因此要求完全相同翻译镜像CHANGELOG.md各语言 docs/i18n 目录下的CHANGELOG.md允许翻译但必须包含根 CHANGELOG.md 中全部版本小节且顺序一致且正文行数与源文件的偏差不得超过 25%——防止翻译版长期未同步导致内容枯竭。此外脚本还内置了防回归机制禁止已被替代的遗留文档重新出现例如docs/CLI-TOOLS.md一旦重新出现即 FAIL必须以docs/reference/CLI-TOOLS.md为唯一事实源。这也解释了为什么丹麦语清单第 5 步要求如果源文档发生重大变更需要更新本地化文档——因为check:docs-sync会强制所有语言镜像保持同步任何源文档改动如果不同步更新 docs/i18n 下的镜像文件CI 会直接红掉。六、完整发布流程从质量门禁到打 tag 部署丹麦语清单聚焦在版本/文档/运行时三块核心校验上而英文完整版 docs/ops/RELEASE_CHECKLIST.md 给出了整个发布生命周期的全貌两者属于同一清单体系。结合两者一个完整版本发布大致经过以下阶段发布前准备所有目标 PR 合入release/vX.Y.0分支、CI 在该分支全绿、代码中无TODO(release)标记grep -r TODO(release) src/ open-sse/、Docker 基础镜像保持最新版本与 Changelog/version-bump-cc patch|minor|major或手工完成版本提升与 changelog 整理第二节代码质量门禁npm run lint0 错误、npm run typecheck:core、npm run typecheck:noimplicit:core严格模式、npm run check:cycles无循环依赖、npm run check:any-budget:t11、npm run check:route-validation:t06、npm run check:node-runtime第四节测试矩阵npm run test:unit、npm run test:vitestMCP server、autoCombo、cache、npm run test:coverage覆盖率门禁 60/60/60/60即 statements/lines/functions/branches 均不低于 60%、npm run test:integration、npm run test:combo:matrix19 种公开路由策略的确定性选择验证、按需的test:e2e、test:protocols:e2e、test:ecosystemHusky 钩子pre-commit 自动跑lint-stagedcheck-docs-synccheck:any-budget:t11pre-push 跑快速门禁。任何钩子失败都应修复底层问题不得用--no-verify绕过文档与 i18nnpm run check:docs-alldocs-sync docs-counts env-doc-sync deprecated-versions doc-links 的总入口、npm run i18n:check翻译状态与源文档同步、npm run i18n:check-ui-coverage42 个语言环境的 UI 覆盖率不低于 80% 下限、npm run i18n:sync-ui:dry无缺失 key若英文源文档有变需运行npm run i18n:run重新翻译数据库迁移src/lib/db/migrations/新增迁移必须幂等、包在事务中、编号无断层在全新安装与既有安装上分别验证构建与产物校验npm run build:release→npm run check:pack-artifact→ 确认dist/BUILD_SHA与 HEAD 一致、dist/server.js存在打 tag 与发布/generate-release-cc或手工git tag -a vX.Y.Z -m Release vX.Y.Z→git push origin vX.Y.Z→gh release create vX.Y.Z --notes-from-tag并附上 Electron 安装包如已构建部署与冒烟按目标选择/deploy-vps-local-cc、/deploy-vps-akamai-cc或/deploy-vps-both-cc部署后打开/dashboard/health核对版本字符串、对一个已知 provider 发起/v1/chat/completions请求、确认/api/monitoring/health返回CLOSED熔断状态、确认 MCP 传输/mcpHTTP 与/mcp-sseSSE可用发布后/capture-release-evidences-cc采集新功能的 WebP 截图/录屏并附到发布说明更新社区公告为下一版本开启 milestone。回滚预案英文清单定义了发布后发现严重问题的三层回滚策略# 1. 标记为非最新版本 gh release edit vX.Y.Z --prerelease # 2. 仅在尚未被用户采用时删除 tag git tag -d vX.Y.Z git push --delete origin vX.Y.Z # 3. 或者在 release 分支上出 hotfix发补丁版本 vX.Y.(Z1)同时强调Docker 侧永远不要重写版本 tag回滚是把latest重新指向上一个良好 digest。硬规则Hard Rules清单以一组不可协商的硬规则收尾这些规则同时是仓库 CI/钩子强制执行的永不直接向main提交永不对main或release/*分支使用git push --force永不用--no-verify跳过 Husky 钩子永不提交密钥、凭据或.env文件覆盖率必须始终 ≥ 60/60/60/60修改src/、open-sse/、electron/或bin/下生产代码时必须同步包含或更新测试。七、小结清单 脚本 可执行的发布契约OmniRoute 的发布检查清单并非停留在文档层面而是与仓库脚本深度绑定版本契约由 check-docs-sync.mjs 强制校验Node.js 安全基线由 nodeRuntimeSupport.ts 单一事实源定义、由 check-supported-node-runtime.ts 执行发布产物洁净度由 validate-pack-artifact.ts 以白名单 必需清单双向把关。对贡献者而言发布前只需要做到文档跟着代码走、版本跟着 changelog 走、产物跟着白名单走即可让本地npm run check:docs-sync与 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 发布检查清单实战指南：从版本号到 npm 产物的一次性正确发布
OmniRoute 发布检查清单实战指南从版本号到 npm 产物的一次性正确发布【免费下载链接】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 仓库的发布检查清单docs/i18n/da/docs/ops/RELEASE_CHECKLIST.md及英文完整版 docs/ops/RELEASE_CHECKLIST.md为核心骨架结合仓库内真实脚本源码讲解在打 tag、发布新版本之前必须完成的全部校验动作版本号与 Changelog 同步、OpenAPI 契约核对、Node.js 安全基线、npm 发布产物洁净度以及check:docs-sync自动化同步守卫。读完本文你将掌握 OmniRoute 一整套可执行、可验证的发布前操作流并能对照源码理解每一项检查背后的实现原理。一、这份清单在做什么发布前的最终防线OmniRoute 是一个 MIT 开源的统一 AI 网关项目package.json 描述为 Unified AI router聚合大量 provider 与模型同时对外发布 npm 包、Docker 镜像、Electron 桌面端和文档站。由于发布面广任何一处版本号漂移、文档失同步或残留本地文件泄漏进 npm 包都会直接影响用户升级体验与包体完整性。发布检查清单Release Checklist就是为此设计的最终防线在打 tag 或发布新版本之前逐项核对。丹麦语版本清单将其归纳为四大部分Version and Changelog—— 版本号与变更日志同步API Docs—— OpenAPI 文档版本契约Runtime Docs—— 运行时文档与 Node.js 安全基线、发布产物检查Automated Check—— 自动化同步守卫npm run check:docs-sync。这四部分在仓库中不是孤立的手工清单而是有真实脚本背书的可执行检查项。下文将逐节展开并给出每项检查对应的源码实现位置。二、版本号与 Changelog三处必须一致的版本契约清单原文要求Version and Changelog在 release 分支中提升package.json的版本号x.y.z将CHANGELOG.md中## [Unreleased]下的发布说明移动到一个带日期的版本小节## [x.y.z] — YYYY-MM-DD保持## [Unreleased]作为 Changelog 的第一小节用于承接后续工作确保CHANGELOG.md中最新的 semver 小节与package.json版本号一致。这条规则之所以是硬性要求是因为它在仓库里由npm run check:docs-sync以代码强制校验脚本 scripts/check/check-docs-sync.mjs读取 package.json 的version字段并用 semver 正则校验格式X.Y.Z或X.Y.Z-prerelease.N解析 CHANGELOG.md要求第一小节必须是## [Unreleased]过滤出所有 semver 版本小节要求最新一个小节的版本号与package.json完全相等。一旦CHANGELOG.md最新版本节与package.json不一致脚本即输出[docs-sync] FAIL - Latest changelog release (X.Y.Z) differs from package.json (X.Y.Z)并以非零退出码失败。也就是说版本号不是随便一改就完事它必须同时驱动 changelog 重构。英文完整版清单 docs/ops/RELEASE_CHECKLIST.md 进一步补充了实操方式通过 Claude Code skill/version-bump-cc patch|minor|major一次完成package.json、electron/package.json的版本提升、从最近 tag 以来的 git 提交重新生成CHANGELOG.md、并更新 README 徽章。当前仓库版本为3.8.51见 package.json 与 docs/openapi.yaml。三、API 文档OpenAPI 版本必须与 package.json 严格相等清单API Docs一节要求更新docs/openapi.yaml使其info.version必须等于package.json的版本号如果 API 契约发生变化需要验证端点示例endpoint examples。这里需要留意一个仓库内路径约定清单中写的是docs/reference/openapi.yaml而实际仓库根目录的 OpenAPI 定义位于 docs/openapi.yaml同时 public/openapi.yaml 也有一份用于站点分发check:docs-sync脚本校验的正是根目录docs/openapi.yaml。以实际仓库为准。info.version与package.json版本的一致性不是建议而是check:docs-sync的强制检查项check-docs-sync.mjs 会解析 OpenAPI 文件中的info:块并提取version字段与package.json的version逐字比对不一致即 FAIL。当前两份文件均为3.8.51保持一致。从源码角度看OpenAPI 契约的严肃性还体现在一系列专项检查脚本上见 package.json 的 scripts 区check:openapi-coverage—— 校验路由覆盖check:openapi-routes—— 校验 OpenAPI 中的路由与实际代码路由一致check:openapi-breaking—— 检测 API 破坏性变更check:openapi-security-tiers—— 校验安全分级。也就是说发布前若 API 有改动除了手工更新info.version还需要跑完这一组 OpenAPI 专项检查确保契约、路由、安全分级三者与代码一致。四、运行时文档与 Node.js 安全基线发布环境的版本下限清单Runtime Docs一节要求发布前完成五件事检查 docs/architecture/ARCHITECTURE.md 是否存在存储/运行时漂移storage/runtime drift检查 docs/guides/TROUBLESHOOTING.md 是否存在环境变量与运维层面的漂移验证发布/运行时 Node.js 版本仍满足受支持的安全下限20.20.2 21或22.22.2 23丹麦语清单中的表述并运行npm run check:node-runtime在构建独立包后校验 npm 发布产物npm run build:clinpm run check:pack-artifact确认没有app.__qa_backup、scripts/scratch、package-lock.json等本地残留文件混入包内如果源文档发生重大变更更新本地化文档。4.1 Node.js 安全基线的真实定义丹麦语清单中给出的 Node.js 范围20.20.2 21或22.22.2 23是文档翻译时点的快照仓库当前的实际策略以单一事实源src/shared/utils/nodeRuntimeSupport.ts 为准export const SECURE_NODE_LINES Object.freeze([ Object.freeze({ major: 22, minor: 22, patch: 2 }), Object.freeze({ major: 24, minor: 0, patch: 0 }), Object.freeze({ major: 25, minor: 0, patch: 0 }), Object.freeze({ major: 26, minor: 0, patch: 0 }), ]); export const RECOMMENDED_NODE_VERSION 24.14.1; export const SUPPORTED_NODE_RANGE 22.22.2 23 || 24.0.0 27;该策略同时写入了 package.json 的engines字段node: 22.22.2 23 || 24.0.0 27。从源码看版本判断逻辑为解析当前 Node 主版本 → 在SECURE_NODE_LINES中查找对应主版本的安全下限→ 当前版本低于该下限则判定为below-security-floor不支持并输出警告。也就是说每个受支持的 LTS 主版本线都有自己的补丁安全下限低于下限即被拒绝这正是secure floor安全下限的含义。npm run check:node-runtime对应脚本 scripts/check/check-supported-node-runtime.ts它调用上面的策略模块不兼容时打印警告并以退出码 1 失败兼容时输出类似Node.js v24.x satisfies OmniRoute secure runtime policy的成功信息且额外支持 Bun 运行时判定Bun 1.1也视为满足策略。4.2 npm 发布产物校验不让本地残留泄漏进包里清单要求构建独立包后执行npm run build:cli npm run check:pack-artifactbuild:cli对应 scripts/build/prepublish.ts负责打包发布前所需的 CLI 独立产物check:pack-artifact对应 scripts/build/validate-pack-artifact.ts它通过 scripts/build/pack-artifact-policy.ts 中定义的允许路径白名单PACK_ARTIFACT_ALLOWED_EXACT_PATHS、PACK_ARTIFACT_ALLOWED_PATH_PREFIXES和必需路径清单PACK_ARTIFACT_REQUIRED_PATHS对发布产物做双向检查检查是否存在不应出现的意外路径如app.__qa_backup、scripts/scratch、package-lock.json等本地残留检查必需的产物路径是否齐全。除此之外validate-pack-artifact.ts还会调用buildProvenance.ts校验构建出处build provenance并借助mcpPublishedFilesClosure.ts检查 MCP 文件闭包是否存在泄漏的测试产物findLeakedTestArtifactPaths与缺失的闭包路径。这套机制从白名单 必需清单 出处校验三个维度保证了 npm 包只包含应该发布的内容。英文完整版清单还补充了单项命令npm run build:release组合了rm -rf .build dist清理、next build生成中间产物、assembleStandalone汇总独立产物、写入dist/BUILD_SHA哨兵并强调发布部署不要分别跑npm run build和npm run build:cli而应使用一条build:release完成干净重建 哨兵写入部署前还需确认dist/BUILD_SHA等于git rev-parse --short HEAD。五、自动化同步检查check:docs-sync 与 CI 集成清单Automated Check一节要求在开 PR 前本地运行同步守卫npm run check:docs-sync并且 CI 也会在.github/workflows/ci.yml的 lint job 中运行此检查。这个守卫就是 scripts/check/check-docs-sync.mjs它实际上是一个文档版本同步的总闸门除前文提到的三处版本契约外还承担两类 i18n 镜像校验严格镜像llm.txtdocs/i18n/locale/llm.txt必须与根目录 llm.txt 逐字节一致该文件不做翻译因此要求完全相同翻译镜像CHANGELOG.md各语言 docs/i18n 目录下的CHANGELOG.md允许翻译但必须包含根 CHANGELOG.md 中全部版本小节且顺序一致且正文行数与源文件的偏差不得超过 25%——防止翻译版长期未同步导致内容枯竭。此外脚本还内置了防回归机制禁止已被替代的遗留文档重新出现例如docs/CLI-TOOLS.md一旦重新出现即 FAIL必须以docs/reference/CLI-TOOLS.md为唯一事实源。这也解释了为什么丹麦语清单第 5 步要求如果源文档发生重大变更需要更新本地化文档——因为check:docs-sync会强制所有语言镜像保持同步任何源文档改动如果不同步更新 docs/i18n 下的镜像文件CI 会直接红掉。六、完整发布流程从质量门禁到打 tag 部署丹麦语清单聚焦在版本/文档/运行时三块核心校验上而英文完整版 docs/ops/RELEASE_CHECKLIST.md 给出了整个发布生命周期的全貌两者属于同一清单体系。结合两者一个完整版本发布大致经过以下阶段发布前准备所有目标 PR 合入release/vX.Y.0分支、CI 在该分支全绿、代码中无TODO(release)标记grep -r TODO(release) src/ open-sse/、Docker 基础镜像保持最新版本与 Changelog/version-bump-cc patch|minor|major或手工完成版本提升与 changelog 整理第二节代码质量门禁npm run lint0 错误、npm run typecheck:core、npm run typecheck:noimplicit:core严格模式、npm run check:cycles无循环依赖、npm run check:any-budget:t11、npm run check:route-validation:t06、npm run check:node-runtime第四节测试矩阵npm run test:unit、npm run test:vitestMCP server、autoCombo、cache、npm run test:coverage覆盖率门禁 60/60/60/60即 statements/lines/functions/branches 均不低于 60%、npm run test:integration、npm run test:combo:matrix19 种公开路由策略的确定性选择验证、按需的test:e2e、test:protocols:e2e、test:ecosystemHusky 钩子pre-commit 自动跑lint-stagedcheck-docs-synccheck:any-budget:t11pre-push 跑快速门禁。任何钩子失败都应修复底层问题不得用--no-verify绕过文档与 i18nnpm run check:docs-alldocs-sync docs-counts env-doc-sync deprecated-versions doc-links 的总入口、npm run i18n:check翻译状态与源文档同步、npm run i18n:check-ui-coverage42 个语言环境的 UI 覆盖率不低于 80% 下限、npm run i18n:sync-ui:dry无缺失 key若英文源文档有变需运行npm run i18n:run重新翻译数据库迁移src/lib/db/migrations/新增迁移必须幂等、包在事务中、编号无断层在全新安装与既有安装上分别验证构建与产物校验npm run build:release→npm run check:pack-artifact→ 确认dist/BUILD_SHA与 HEAD 一致、dist/server.js存在打 tag 与发布/generate-release-cc或手工git tag -a vX.Y.Z -m Release vX.Y.Z→git push origin vX.Y.Z→gh release create vX.Y.Z --notes-from-tag并附上 Electron 安装包如已构建部署与冒烟按目标选择/deploy-vps-local-cc、/deploy-vps-akamai-cc或/deploy-vps-both-cc部署后打开/dashboard/health核对版本字符串、对一个已知 provider 发起/v1/chat/completions请求、确认/api/monitoring/health返回CLOSED熔断状态、确认 MCP 传输/mcpHTTP 与/mcp-sseSSE可用发布后/capture-release-evidences-cc采集新功能的 WebP 截图/录屏并附到发布说明更新社区公告为下一版本开启 milestone。回滚预案英文清单定义了发布后发现严重问题的三层回滚策略# 1. 标记为非最新版本 gh release edit vX.Y.Z --prerelease # 2. 仅在尚未被用户采用时删除 tag git tag -d vX.Y.Z git push --delete origin vX.Y.Z # 3. 或者在 release 分支上出 hotfix发补丁版本 vX.Y.(Z1)同时强调Docker 侧永远不要重写版本 tag回滚是把latest重新指向上一个良好 digest。硬规则Hard Rules清单以一组不可协商的硬规则收尾这些规则同时是仓库 CI/钩子强制执行的永不直接向main提交永不对main或release/*分支使用git push --force永不用--no-verify跳过 Husky 钩子永不提交密钥、凭据或.env文件覆盖率必须始终 ≥ 60/60/60/60修改src/、open-sse/、electron/或bin/下生产代码时必须同步包含或更新测试。七、小结清单 脚本 可执行的发布契约OmniRoute 的发布检查清单并非停留在文档层面而是与仓库脚本深度绑定版本契约由 check-docs-sync.mjs 强制校验Node.js 安全基线由 nodeRuntimeSupport.ts 单一事实源定义、由 check-supported-node-runtime.ts 执行发布产物洁净度由 validate-pack-artifact.ts 以白名单 必需清单双向把关。对贡献者而言发布前只需要做到文档跟着代码走、版本跟着 changelog 走、产物跟着白名单走即可让本地npm run check:docs-sync与 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），仅供参考