基础设施 / CI / 依赖 / 配置变更

归属：docs/guides/sops/ 触发：CI workflow、依赖版本、构建/发布链路、配置、工具链变更关联概念：flow-code、flow-review、flow-release、Release Profile

场景定义

对工程基础设施（而非业务功能）的变更：CI/发布 workflow、依赖升级、构建配置、静态配置、工具链等。这类变更的验收通常就是「CI 自身能否通过 + 关键路径回归」。

目标与不做什么

目标：安全变更基础设施，确保 CI 与发布链路不被破坏，行为（构建/测试/发布）保持一致。
不做：不在基础设施 PR 里夹带业务功能改动；不盲目升级依赖不做兼容验证。

标准方法论（行业通行）

借鉴 IaC（基础设施即代码）与依赖管理的通行做法：

CI 即验收：基础设施变更本身就是代码，由 CI 验证；一份变更 PR 应当能证明「改完 CI 仍绿、构建仍通过」。
变更评审：CI/构建/发布链路变更影响面大，需显式评审（谁改了、为何改、影响哪些 job）。
依赖升级验证：升级前记录当前版本 → 升级 → 兼容性检查（breaking changes）→ 全量回归 → 安全检查（漏洞/许可）。
小步 + 可回退：一次升一类依赖 / 一次改一个链路，便于定位与回退。
发布链路回归：改动 release-publish.yml 等发布链路时，需走一次发布流程验证（或 dry-run）。

本项目落地流程

确认变更范围：CI workflow / 依赖 / 配置 / 构建链路，评估影响面（尤其发布链路）。
小步变更：在独立分支 chore/<slug> 或 ci/<slug> / worktree 内，一次一类变更。
CI 即验收：push 触发 CI（ci.yml）验证；改动发布链路时通过项目 GitHub Actions release workflow dry-run / 试跑验证。
依赖升级专项：记录前版本 → 升级 → 兼容性检查 → 全量回归（npm test）→ 安全检查。
审查与合并：复用 flow-review；审查确认「变更范围清晰、未夹带业务改动、CI/发布链路验证通过」；CI 绿后合并。
文档同步：涉及支持版本 / 配置 / 迁移说明时更新 docs/guides/configuration.md 等。

验证与门禁

[ ] CI workflow 运行通过（变更本身即验收）
[ ] 发布链路变更已通过 release workflow 验证（dry-run / 试跑）
[ ] 依赖升级：兼容性检查 + 全量回归绿 + 无新增漏洞
[ ] 未夹带业务功能改动
[ ] 相关配置/迁移文档已同步

产出物

基础设施变更 PR（chore/<slug> 或 ci/<slug>）
依赖升级验证记录 / 配置迁移说明

复用与新增资产

复用：flow-code（应用变更）、flow-review（审查合并）、flow-release（发布链路验证）、CI workflow。
新增（缺口）：ci/<slug> 分支约定；基础设施变更的轻量入口。

反模式 / 注意事项

在基础设施 PR 里夹带业务功能。
盲目升级依赖不做兼容与全量回归验证。
改发布链路不验证发布流程。
一次变更多个无关链路（CI + 依赖 + 配置混在一起）。
变更后不更新配置/迁移文档。