跳至主要內容

Monorepo 协同升级：共享锁文件、兼容单元与原子更新队列

高谷深陵大约 21 分钟约 6227 字

一个 Monorepo 里，前端应用、Node.js 网关、Java 服务、容器镜像和 Terraform module 共用同一套协议。机器人先合并了 TypeScript 客户端更新，随后单独合并代码生成器，Docker 基础镜像和服务端库还在队列里。每个 PR 单独看都通过了自己的测试，主分支却落在一个从未被任何团队验证过的组合上：客户端开始发送新字段，旧服务忽略它；生成代码要求更新的运行时，某个应用目录仍被共享锁文件解析到旧版本；回退其中一个 PR 又让 lockfile 与 manifest 不一致。

Monorepo 的关键优势是可以把跨目录变更放进一个提交，但更新机器人若仍按“发现一个依赖，创建一个 PR”工作，就可能拆掉业务兼容性。真正需要原子提交的对象不是目录，也不是包管理器，而是兼容单元：一组必须在同一个仓库状态中共同验证、共同合并，也能共同回退的引用。内部包边、生成器与运行时、镜像与 IaC 部署约束会让兼容单元跨越看似独立的文件树；共享 lockfile 则首先形成写冲突和重算约束，只有同时存在业务兼容边时才要求成员进入同一个 PR。

Monorepo多目录共享锁文件内部包跨生态兼容单元原子PR队列和回退海报
Monorepo 依赖协同升级高清原图

目录边界为什么不是升级边界

先看一个常见仓库：

repo/
├─ package.json
├─ pnpm-workspace.yaml
├─ pnpm-lock.yaml
├─ apps/
│  ├─ web/package.json
│  └─ admin/package.json
├─ packages/
│  ├─ protocol/package.json
│  └─ ui/package.json
├─ services/
│  └─ gateway/package.json
├─ images/gateway/Dockerfile
├─ infra/gateway/main.tf
└─ .github/dependabot.yml or renovate.json

三个应用目录各有 manifest，却只有根 pnpm-lock.yaml 保存解析结果。改 apps/web/package.json 时，包管理器可能重写共享 lockfile 中多个 importer 和传递依赖；另一个 PR 同时改 services/gateway/package.json，也会争用同一文件。Git 能合并 YAML 文本，不代表两个解析结果组合后仍是包管理器会生成的合法状态。共享 lockfile 是仓库级状态，不是某个目录的附件。

内部包又增加一层。apps/web 通过 workspace 协议引用 packages/protocol 时，版本号可能只是发布契约；本地构建实际解析到工作区源码。机器人升级外部 @example/protocol-runtime，却不会自动知道内部 packages/protocol 的生成产物、服务端 Java artifact 和镜像标签应同步。manager 负责抽取它认识的引用，datasource 负责查版本；业务兼容关系必须由团队配置或仓库任务图补充。

兼容单元并不意味着“把全仓所有更新塞进一个超级 PR”。先区分两类边：同一 lockfile 的并发写入是冲突边，它要求 PR 在最新主分支上重新生成锁并串行进入队列，但不自动要求无关依赖同组；同一协议版本、生成器与运行时、镜像 digest 与部署约束属于兼容边，成员才应共同更新、验证和回退。同一 source repository 只有在上游确实同步发布时才可能形成发布边。没有兼容边的低风险更新可以保持独立，通过队列解决共享锁冲突；有兼容边的成员才进入同一个原子 PR。

接入前先盘点三个图

示例基线是 Renovate 43.266.0、Dependabot 配置语法 version: 2、pnpm 11.x 与当前 Nx affected 语义。Renovate CLI 是 AGPL-3.0，既可使用 Mend 云托管，也可自托管；dependabot-core 是 MIT，但 GitHub 上的凭据代理、调度和 PR 服务仍是托管能力，配置 self-hosted runner 只改变作业执行网络。版本升级时要重新验证 manager、lockfile 与 Monorepo 工具解析器，不能因为仓库业务代码没变就跳过机器人自身的变更评审。

要让机器人进入大仓，维护者至少需要仓库读权限、创建机器人分支和 PR 的权限，读取必要公共或私有 Registry 的最小凭据；分支保护、CODEOWNERS 和合并队列仍由平台执行。私有源凭据不能写进仓库配置。自托管 Renovate 还需要平台管理员提供运行计划、固定版本和日志空间；Dependabot 由 GitHub 托管，但每个生态和目录都必须在 .github/dependabot.yml 中声明。Dependabot PR 触发的 Actions 默认使用只读 GITHUB_TOKEN 且拿不到普通 Actions secrets，跨生态集成测试若需要私有源，应提供最小范围的 Dependabot secret，不能把发布凭据交给更新分支。

第一张图是发现图：每个 manager 实际发现哪些文件、依赖名、datasource 和当前值。第二张是解析图：哪些 manifest 共同写一个 lockfile、provider lock、Chart lock 或生成产物。第三张是兼容图：哪些依赖虽来自不同生态，却必须同步到一个协议、平台或供应链身份。

不要从目录名猜这三张图。用包管理器命令确认 workspace 与锁文件，用 Monorepo 工具的项目图确认内部边，再用机器人 dry run 日志确认抽取结果。Renovate 支持的 manager 和 datasource 是两个不同集合，官方入口分别见manager modules与datasource modules。Dependabot 的 directory/directories 定位 manifest，支持语义与限制应查选项参考。

在 Node.js workspace 中，先从根运行仓库锁定的包管理器，而不是在每个应用里独立安装。pnpm 默认 sharedWorkspaceLockfile: true，但 peer dependency 默认不会作为硬错误；若仓库把 peer 兼容作为升级门禁，应在 pnpm-workspace.yaml 明确写出政策，而不是依赖开发机历史环境：

packages:
  - "apps/*"
  - "packages/*"
  - "services/*"

sharedWorkspaceLockfile: true
strictPeerDependencies: true
resolvePeersFromWorkspaceRoot: false

resolvePeersFromWorkspaceRoot: false 会迫使各消费者声明自己真正需要的 peer，适合要验证内部包可独立发布的仓库；已有仓库若依赖根级统一 peer，可以保留默认 true，但必须把根依赖视为兼容单元成员。peerDependencyRules.allowedVersions、allowAny 和 ignoreMissing 只应记录经过兼容实验的例外，它们会消除告警，不会让不兼容代码自动兼容。pnpm 对共享锁与 workspace 链接的定义见Workspace 配置，peer 解析开关见pnpm settings。

确认仓库已按 packageManager 字段或受控镜像安装批准的 pnpm 后运行：

pnpm --version
pnpm install --frozen-lockfile
pnpm -r list --depth -1
pnpm -r why @example/protocol-runtime
git status --short

--frozen-lockfile 应在干净主分支上成功且不改文件，这才证明 manifest 与共享锁文件一致；配合 strictPeerDependencies 成功，才额外证明当前解析没有缺失或越界 peer。why 的预期证据是列出每个 workspace 消费者及其解析路径，用来发现同名依赖被不同 peer 上下文拆成多个实例。若 frozen install 失败，先修复基线，不要让机器人在脏状态上生成更多 PR。pnpm 11.x 在 CI 检测到已有 lockfile 时默认冻结，但命令仍显式写出，避免本地与 CI 证据口径不同，具体语义见pnpm install。

用 Renovate 描述兼容单元和更新队列

Renovate 可以按包名、文件、manager、datasource、source URL 与更新类型匹配。groupName 本身没有业务语义；所有得到同一非空组名的更新会进入同一个分支/PR，见groupName 说明。因此组名只是编译结果，真正重要的是 matcher 是否完整覆盖兼容单元。

{
  "$schema": "https://docs.renovatebot.com/renovate-schema.json",
  "extends": ["config:recommended"],
  "dependencyDashboard": true,
  "prConcurrentLimit": 3,
  "branchConcurrentLimit": 3,
  "packageRules": [
    {
      "description": ["协议工具链跨目录、跨生态形成一个兼容单元"],
      "matchPackageNames": [
        "@example/protocol-runtime",
        "@example/protocol-generator",
        "com.example:protocol-runtime",
        "ghcr.io/example/protocol-sidecar"
      ],
      "groupName": "protocol compatibility unit",
      "groupSlug": "protocol-compatibility",
      "addLabels": ["dependencies", "compatibility-unit:protocol"]
    },
    {
      "description": ["同一上游 Monorepo 发布的包保持同组"],
      "matchSourceUrls": ["https://github.com/example/example-framework"],
      "groupName": "example framework packages"
    },
    {
      "description": ["共享锁维护单独排队，不与功能升级混合"],
      "matchUpdateTypes": ["lockFileMaintenance"],
      "groupName": "workspace lock refresh",
      "dependencyDashboardApproval": true
    },
    {
      "description": ["major 更新进入人工审批队列"],
      "matchUpdateTypes": ["major"],
      "dependencyDashboardApproval": true,
      "prPriority": 10,
      "addLabels": ["risk:major"]
    }
  ],
  "lockFileMaintenance": {
    "enabled": true,
    "schedule": ["* 2-4 * * 1"],
    "recreateWhen": "always"
  }
}

协议组同时匹配 npm、Maven 坐标与容器镜像名，目的是让一个 PR 承载同一协议面。真正仓库还可能有 Terraform variable、Helm values 或自定义 YAML；若内置 manager 不识别，需要经过测试的 custom manager 抽取，否则“同组”只覆盖机器人看得见的部分。matchSourceUrls 适合上游仓库确实同步发布的一组包，官方给出了按 source URL 聚合同一 Monorepo 包的用法，见matchSourceUrls 参考。不要因为包来自同一仓库就盲目同组；上游若独立发布，组会扩大失败半径。

lockFileMaintenance 是重建锁文件、刷新允许范围内传递依赖的维护动作，不是某个直接依赖的普通升级。它应有独立窗口和验证，避免与正在变更 manifest 的功能组争用共享锁文件。默认行为和可配置字段见lockFileMaintenance 参考。

prPriority 只影响 Renovate 在有限配额中先创建哪些 PR，不是平台合并顺序。真正的更新队列还需要分支保护或 merge queue：每个 PR 必须基于接近最新的主分支重新验证，队列一次接纳有限兼容单元，合并后让后续项重新计算。若机器人每次主分支变化都 rebase，大组 CI 很重，应控制开放分支数与自动 rebase 频率，而不是无限提高并发。

Dependabot 的多目录和跨生态分组

同一生态的多个目录可以放进一个 update block。GitHub 官方提供 group-by: dependency-name，使同一依赖在多个目录中的更新进入一个 PR，见Monorepo 多目录分组示例。

version: 2

multi-ecosystem-groups:
  protocol-stack:
    schedule:
      interval: "weekly"
    labels:
      - "dependencies"
      - "compatibility-unit:protocol"

updates:
  - package-ecosystem: "npm"
    directories:
      - "/apps/web"
      - "/apps/admin"
      - "/services/gateway"
    patterns:
      - "@example/protocol-runtime"
      - "@example/protocol-generator"
    multi-ecosystem-group: "protocol-stack"

  - package-ecosystem: "docker"
    directory: "/images/gateway"
    patterns:
      - "ghcr.io/example/protocol-sidecar"
    multi-ecosystem-group: "protocol-stack"

  - package-ecosystem: "terraform"
    directory: "/infra/gateway"
    patterns:
      - "example/protocol"
    multi-ecosystem-group: "protocol-stack"

group-by: dependency-name 解决“同一个包散落多个目录”的同步，不自动理解两个不同名字的包必须兼容。multi-ecosystem-groups 才能把支持的不同 package ecosystem 合并进一个 PR；组在顶层定义 schedule，各生态通过同名 multi-ecosystem-group 加入并提供 patterns。配置层与生态层的字段合并方式并非全部相同，某些字段只能放组级，必须按GitHub 多生态更新概念和配置教程核对。

这个示例已经把 npm、Docker 与 Terraform 三个 update block 都加入 protocol-stack，因此匹配 patterns 的候选由组级 schedule 触发并进入一个跨生态 PR。group-by: dependency-name 是另一种机制，只适合同一生态、多个目录中的同名依赖；如果目录间约束不兼容，Dependabot 仍会拆 PR。不要再为相同生态、目标分支和重叠目录复制第二个 update block 来同时追求两种分组，官方要求这些目录边界唯一且不重叠。其余同名依赖若也要降噪，应重新划分不重叠目录，或改用 Renovate 的精确规则。若 GitHub 部署版本尚不支持目标生态的 multi-ecosystem group，就应由 Renovate、自定义编排 PR 或人工变更承载，不能在文档上宣称原子而让工具实际拆开。

正向实验：一个提交保存整个兼容单元

下面的实验只需要 Python 3，使用合成 JSON 文件模拟三个目录、一个共享锁摘要和一个跨生态部署约束。保存为临时目录中的 monorepo_lab.py。

import argparse
import hashlib
import json
from pathlib import Path

FILES = {
    "apps/web.json": {"protocol": "1", "internal": "workspace:packages/protocol"},
    "services/gateway.json": {"protocol": "1", "internal": "workspace:packages/protocol"},
    "packages/protocol.json": {"api": "1", "generated_with": "1"},
    "images/gateway.json": {"sidecar_protocol": "1"},
    "infra/gateway.json": {"accepted_protocol": "1"},
}

def write_tree(root):
    for name, value in FILES.items():
        path = root / name
        path.parent.mkdir(parents=True, exist_ok=True)
        path.write_text(json.dumps(value, indent=2) + "\n", encoding="utf-8")
    refresh_lock(root)

def load(root, name):
    return json.loads((root / name).read_text(encoding="utf-8"))

def save(root, name, value):
    (root / name).write_text(json.dumps(value, indent=2) + "\n", encoding="utf-8")

def refresh_lock(root):
    inputs = []
    for name in sorted(FILES):
        if name == "shared-lock.json":
            continue
        inputs.append((name, load(root, name)))
    digest = hashlib.sha256(json.dumps(inputs, sort_keys=True).encode()).hexdigest()
    save(root, "shared-lock.json", {"input_digest": digest})

def verify(root):
    versions = {
        "web": load(root, "apps/web.json")["protocol"],
        "gateway": load(root, "services/gateway.json")["protocol"],
        "internal_api": load(root, "packages/protocol.json")["api"],
        "generator": load(root, "packages/protocol.json")["generated_with"],
        "sidecar": load(root, "images/gateway.json")["sidecar_protocol"],
        "infra": load(root, "infra/gateway.json")["accepted_protocol"],
    }
    old_lock = load(root, "shared-lock.json")["input_digest"]
    refresh_lock(root)
    new_lock = load(root, "shared-lock.json")["input_digest"]
    lock_ok = old_lock == new_lock
    compatible = len(set(versions.values())) == 1
    return {"versions": versions, "lock_ok": lock_ok,
            "compatible": compatible, "ready": lock_ok and compatible}

def upgrade(root, mode):
    target = "2"
    for name, field in [
        ("apps/web.json", "protocol"),
        ("services/gateway.json", "protocol"),
        ("packages/protocol.json", "api"),
        ("packages/protocol.json", "generated_with"),
        ("images/gateway.json", "sidecar_protocol"),
        ("infra/gateway.json", "accepted_protocol"),
    ]:
        if mode == "split" and name in {"images/gateway.json", "infra/gateway.json"}:
            continue
        data = load(root, name)
        data[field] = target
        save(root, name, data)
    refresh_lock(root)

def main(mode, root):
    write_tree(root)
    upgrade(root, mode)
    result = verify(root)
    print(json.dumps({"mode": mode, **result}, indent=2))
    expected = mode == "atomic"
    if result["ready"] != expected:
        raise SystemExit("COMPATIBILITY_ASSERTION_FAILED")
    print("COMPATIBILITY_ASSERTION_OK")

if __name__ == "__main__":
    parser = argparse.ArgumentParser()
    parser.add_argument("mode", choices=["atomic", "split"])
    parser.add_argument("--workdir", default="monorepo-lab")
    args = parser.parse_args()
    main(args.mode, Path(args.workdir))

运行原子更新：

python monorepo_lab.py atomic --workdir lab-atomic

预期 versions 中六个值均为 2，lock_ok、compatible 和 ready 都为 true，末行是：

COMPATIBILITY_ASSERTION_OK

这里的共享锁只保存所有输入的摘要，用来证明“manifest 改完后重新解析并提交锁状态”这一不变量。真实 pnpm、npm、Yarn、Bundler 或 provider lock 有各自的解析算法、完整性哈希和平台字段，必须由对应包管理器生成，不能手工改 lockfile。

反向实验：错误拆组产生可合并但不可运行的半状态

运行拆组模式：

python monorepo_lab.py split --workdir lab-split

这个模式模拟“应用、内部包和生成器在 PR-A，镜像与 Terraform 在 PR-B”。PR-A 自己刷新了共享锁，所以 lock_ok 仍为 true；但 versions 会显示应用侧为 2，sidecar 与 infra 仍为 1，因此 compatible:false、ready:false。脚本把这个失败视为预期证据，末行仍为 COMPATIBILITY_ASSERTION_OK。

这正是最危险的拆组错误：语法、锁文件甚至目录级单测都可以通过，只有跨生态兼容不变量失败。修复时把镜像与 Terraform 引用纳入同一组，或在仓库根增加一个兼容矩阵检查，要求 PR 中六个观察点一致；重新运行 atomic 模式，直到 ready:true。若业务协议允许 N/N-1 兼容，不要简单要求全相等，而应把允许矩阵写进验证器，例如“新客户端只能与新旧两代服务端通信，但新 sidecar 必须配新 infra capability”，并为每个允许组合保留测试。

规则顺序也会制造拆组。Renovate 中，宽泛的后置规则若把 groupName 改为 null，会覆盖前面协议组；Dependabot 中，宽泛首组会先拿走依赖，使后面的兼容组永远匹配不到。配置审查必须比较最终候选归属，而不是只阅读每条规则的意图。将合成依赖清单喂给策略测试，断言每个兼容单元只产生一个 group key，能在机器人运行前发现这类回归。

原子 PR 也需要可分层的验证

原子表示提交边界一致，不表示一次运行全仓最重测试。CI 可以分层：先验证配置、根安装和 lockfile 无漂移；再根据任务图运行 affected build/test；然后运行兼容单元的协议契约、生成代码 diff、镜像启动和 IaC plan；最后由端到端烟测证明组合可部署。任一层失败，整个 PR 都不能进入队列。

配置/schema
  -> 根目录 frozen install
  -> lockfile / 生成物无未提交差异
  -> affected build + unit tests
  -> 兼容矩阵 / contract tests
  -> 镜像与 IaC 静态验证
  -> 集成烟测
  -> merge queue

内部包尤其要防止“源码可见掩盖发布失败”。workspace 构建可能直接引用源码，发布后的消费者却拿到错误 exports、缺失文件或不匹配 peer dependency。兼容单元 PR 至少要把内部包打成临时制品，在隔离目录安装并运行一个消费者烟测；发布流程再用相同制品身份推进，不能在合并后重新构建出另一份内容。

批量升级也应从根目录、以兼容单元为过滤边界执行。下面命令只演示 pnpm workspace 内两个消费者的同版本更新；运行前先确认过滤器命中的项目，运行后必须提交 manifest 与根 lockfile 的完整差异：

pnpm --filter ./apps/web --filter ./services/gateway update @example/protocol-runtime@2
pnpm install --lockfile-only
pnpm install --frozen-lockfile
git diff -- package.json "apps/*/package.json" "services/*/package.json" pnpm-lock.yaml

预期证据是两个目标 manifest 使用批准范围、根 lockfile 由同一 pnpm 版本重算、随后 frozen install 不再产生变化。--lockfile-only 不是验证，它只生成解析状态；若批量更新漏掉 peer、内部包或生成器，严格 peer 检查、兼容矩阵和制品烟测仍应失败。命令中的 major 2 是实验占位，真实升级必须改成经过评审的目标版本或精确范围。

affected 验证需要明确比较基线。在 Nx CI 中，base 应指向默认分支最近一次成功验证的提交，head 指向当前 PR 提交，而不是含糊依赖本地默认值：

NX_BASE="$LAST_SUCCESSFUL_MAIN_SHA" NX_HEAD="$PR_HEAD_SHA" npx nx affected -t build,test

Nx 遇到 lockfile 变化时默认把所有项目标为 affected，这是保守兜底；只有在验证过解析器与项目图后，才考虑 pluginsConfig.@nx/js.projectsAffectedByDependencyUpdates: "auto"，让 Nx 比较 base/head 两份 lockfile 并映射实际解析变化。affected 只能回答“哪些项目任务要跑”，不能发现 Docker、Terraform、协议矩阵或发布后 peer 消费者，因此兼容单元的 contract、镜像、IaC 与制品烟测仍须固定执行。官方语义见Nx affected。

共享锁文件上的 CI 冲突要由队列串行化最终合并。两个 PR 都基于旧主分支生成 lockfile，即使各自绿色，先合并一个后，另一个必须在新基线重新生成和验证。禁止用 git checkout --theirs pnpm-lock.yaml 解决冲突；正确动作是 rebase、运行仓库锁定的包管理器、审查新 diff，再执行 frozen install。更新队列观测至少包含等待年龄、重算次数、lockfile 冲突率、兼容单元失败率和 Runner 时间；若重算次数持续升高，应降低并发或扩大可独立合并的单元，而不是跳过验证。

配置冲突从哪里出现

大仓常有组织 preset、根配置和目录级历史配置。Renovate 会按配置层级合并可合并字段，但仓库配置文件的发现是“按搜索顺序找到第一份就停止”，不是自动合并所有同名文件，配置文件搜索行为见配置选项开头的文件发现说明。团队若同时保留 .github/renovate.json、renovate.json5 和旧 package.json 配置，维护者可能改了未被读取的那份；把 Renovate 配置放在 package.json 的入口也已被官方标为弃用。

Dependabot 则以默认分支 .github/dependabot.yml 为中心。重复的生态/目录块若边界重叠，会让维护者难以判断哪个 schedule、group 或 registry 生效；target-branch 还会改变 Version Updates 目标，并使该块配置不再按同样方式作用于 Security Updates，见target-branch 说明。配置应该集中生成或集中评审，不能让每个子目录复制一份近似模板。

发现配置冲突时，先保存当前机器人的 dry run/job log 与开放 PR 清单，再建立唯一权威配置。迁移过程中只允许一个机器人创建分支；另一个保持只读或关闭。否则两个工具会为同一共享 lockfile 反复 rebase、关闭和重建 PR，CI 成本与审计噪声都会翻倍。

分批回退不是逐个 revert 随机试

原子 PR 最直接的代码回退是整体 revert 该合并提交，再用仓库锁定的包管理器执行 pnpm install --frozen-lockfile，确认 revert 同时恢复 manifest 与原 lockfile；只有 frozen install 失败时，才在已确认的旧 manifest 上重新生成锁并审查差异，不能无条件重算出一个从未验证的新解析状态。随后重建制品并复跑兼容矩阵，证据应指向一个历史已知绿色提交。若更新已经发布到多个环境，代码 revert 只是第一步：内部包版本可能已经进入 Registry，镜像 tag 可能已移动，Terraform state 可能已记录新资源，数据库或协议数据也可能已向前演进。不可变 digest 与已发布包不应删除覆盖；应发布明确的后续版本或回退引用。

当兼容单元过大、一次回退代价太高，可以在升级前设计分批兼容路径：

先发布服务端兼容层，使旧客户端与新客户端都可工作。再更新生成器、内部包和客户端，但功能开关仍发送旧协议。然后升级 sidecar、镜像和 IaC capability。

验证所有运行实例具备新能力后切换协议。最后删除旧兼容层。

这五批不是五个互相独立的随机 PR，而是有方向的状态机。每批都声明允许的前后组合、进入证据和回退目标。回退时按相反依赖顺序操作：先停用新协议，再回退消费者，再回退交付层，最后决定是否删除服务端兼容层。只要仍有旧消费者，兼容层就不能提前移除。

清理、退出与长期治理

实验目录可以直接删除：

rm -rf lab-atomic lab-split

PowerShell 使用 Remove-Item -Recurse -Force lab-atomic, lab-split，执行前先确认路径确实是实验目录。真实项目若要暂停 Monorepo 协同更新，应先阻止新 PR，处理或关闭机器人分支，保留最近一轮发现图与兼容单元映射，再撤销 App、Token 和 Registry 凭据。不要先删凭据再让机器人清理，否则开放分支可能长期残留且无法解释。

凭据要按生态和主机最小化：读取 npm 私库的 Token 不应同时拥有容器推送或仓库管理权限；机器人日志不能输出内部包全名、认证 URL、Terraform backend 或镜像仓库路径。大型仓库的更新日志和依赖清单可能形成组织技术地图，集中观测时应聚合为生态、兼容单元和状态，限制原始日志访问与保留。

容量成本由三部分组成：发现与查版、分支上的 lockfile/生成物计算、CI 与评审。兼容分组减少 PR 和重复测试，但组越大，失败定位与重跑成本越高。长期要观察“每个兼容单元的成功率和服务时间”，而不是追求最少 PR；当某成员反复让大组失败，应确认它是否真有兼容边，若没有就拆出，若有就补更早的专项验证。

每个兼容单元需要明确 owner、成员匹配规则、验证任务、最大可接受失败半径、回退顺序和删除条件。新目录、新生态或新内部包加入仓库时，合并门禁应要求回答它写哪个锁文件、依赖哪些内部包、属于哪个兼容单元、由哪条机器人规则发现。最终不变量是：主分支上的每个状态都被完整兼容单元验证过；共享锁文件只由对应包管理器生成；队列中的 PR 在最新基线上重新验证；回退恢复的是一个已知兼容状态，而不是又制造一组没人测试过的版本拼图。

跳到正文