codebase-memory-mcp 本地 CI 场地体系：test-infrastructure 如何让本地测试结果可预测 CI

2026-09-05 12:15:30作者：昌雅子Ethen

High-performance code intelligence MCP server. Indexes codebases into a persistent knowledge graph — average repo in milliseconds. 158 languages, sub-ms queries, 99% fewer tokens. Single static binary, zero dependencies.

项目地址：https://gitcode.com/GitHub_Trending/co/codebase-memory-mcp

本文围绕 codebase-memory-mcp 仓库的 test-infrastructure/ 目录展开，讲解"三操作系统本地 CI 阶梯"的设计与落地：Linux 容器化测试（Colima + Docker Compose）、真 Windows UTM 虚拟机、macOS 原生执行三类"场地（venue）"如何各自接入同一套规范腿脚本（canonical leg scripts），并通过 venue-parity 契约测试、clean-disk 预检、内容校验 ccache 等机制保证本地绿与 CI 绿的一致性。读完后，你将能复现该项目的本地 push 前全平台门禁流程，并理解"场地只准配置机器、只有规范脚本可以驱动产品"这一契约在源码层面是如何被强制执行的。

一、设计信条：场地（venue）只负责"配机器"，规范脚本负责"考产品"

test-infrastructure/ 是三操作系统 CI 阶梯的本地一半。它在 test-infrastructure/README.md 中给出的核心信条（在 scripts/README.md 中被称为"enforced, not advisory"）是：

a venue may provision a machine; only a canonical leg script may exercise the product.

即：本地 CI、PR CI、dry run、release 全部调用同一批 scripts/ 下的规范入口文件（scripts/test.sh、scripts/build.sh、scripts/smoke-local.sh、scripts/soak-legs.sh、scripts/ci/vm-smoke.sh 等），场地之间只在主机规格、架构和输入上不同，绝不各自发明测试逻辑。平台差异（例如 CLANGARM64 的 trap-UBSan 默认开关、Windows 原生行为、Linux 可移植静态二进制）全部内聚在这些规范脚本内部，写一次、处处生效。

test-infrastructure/ 目录本身因此非常"薄"：它只负责容器编排（Dockerfile + docker-compose）和 Windows 虚拟机驱动（vm/ 子目录），不承载任何产品级测试逻辑。这个"薄"不是省略，而是被一个自动化契约强制的——见后文第五节。

二、三类本地场地与入口一览

README 给出的入口表如下（完整继承原文档）：

场地	入口	说明
Linux（arm64 + amd64）+ 交叉编译	`./run.sh <leg>`（`--help` 查看腿列表）	仅支持 Colima（Docker Desktop 在该开发机上不可用）。每条腿启动前都会执行 clean-disk 预检 `scripts/ci/preflight-docker.sh`：GitHub runner 是每 job 全新镜像、磁盘已知 14 GB 空闲，而长寿命的 Colima 虚拟机需要先被"清扫回"runner 形态。
真 Windows（UTM ARM64 VM）	`vm/win.sh <command>`（`win.sh help`）	同款预检思路（`scripts/ci/clean-test-residue.ps1`），外加 CI 的受保护按用户 TEMP 根。Wine（`run.sh windows`）只作编译检查——绝不是 VM 的替代品。
macOS	原生直接跑规范脚本	`scripts/test.sh`、`scripts/build.sh`、`scripts/smoke-local.sh …`

对应的 push 前三步阶梯（the ladder, before any push）：

scripts/test.sh — macOS 原生全量（迭代时可用 --suites … 子集模式）；
./test-infrastructure/run.sh full — Linux arm64 的 test/build/TSan/smoke/portable + mingw 交叉编译（按需追加 amd64、soak-linux）；
vm/win.sh test-par · guards · smoke-install · soak — 真 Windows 各腿。

README 同时强调一条纪律：基础设施不可用 = 需要升级（escalate）的运行阻塞，绝不允许静默绕过。

三、Linux 容器化场地：run.sh 与 docker-compose 深度解析

3.1 run.sh：每条腿都跑 CI 的同一套脚本

test-infrastructure/run.sh 是 Linux（含交叉编译）侧的总入口，其注释头写明了覆盖范围：

Linux arm64：test（ASan+LeakSan）+ build（-O2），原生执行，最快；
Linux amd64：test + build，走 QEMU 模拟，较慢；
Linux portable：Alpine musl 静态构建 + smoke，产出可移植二进制；
Windows：mingw 交叉编译 + Wine 版本检查（快速编译检查；真 Windows 验证必须走 vm/win.sh）；
macOS：不进容器，原生执行。

从源码结构看，run.sh 的 --help 暴露的腿（leg）包括：full（默认：arm64 test + build + TSan + smoke + portable smoke + Windows 交叉编译）、all（再加 amd64 与 Wine 检查）、test|build|smoke|tsan|msan（单腿）、tsan-amd64（需真实 amd64 硬件——TSan 的影子内存与 x86_64-on-ARM 转换不兼容，Apple Silicon 上会 FATAL，这一点在 run.sh 的注释中有明确记载）、portable、glibc-floor、smoke-artifact、soak-linux、soak-windows（委托给 vm/win.sh soak 10）、lint、shell 等。

full 腿的实际执行序列（摘自 run.sh 第 174–192 行）：

full)
    $COMPOSE run --rm -e CBM_SKIP_PERF=1 test          # Linux arm64: test + build
    $COMPOSE run --rm build
    $COMPOSE run --rm test-tsan                          # ThreadSanitizer 数据竞争门禁
    $COMPOSE run --rm smoke                              # smoke 测试
    $COMPOSE run --rm smoke-portable                     # Alpine 静态构建 + smoke
    $COMPOSE run --rm smoke-artifact                     # 工件流 smoke（打包→解包→wrapper）
    $COMPOSE run --rm smoke-glibc-floor                  # glibc 2.35 地板检查
    $COMPOSE run --rm build-windows                      # Windows 交叉编译
    print_real_windows_gate                              # 提示：真 Windows 门禁仍在 vm/win.sh
    ;;

注意末尾的 print_real_windows_gate——容器腿全部通过后仍会打印"Real-Windows gate remains: vm/win.sh sync, test, guards, smoke-install"，从入口层面就把"编译通过 ≠ Windows 验证通过"的边界钉死。

3.2 并发隔离：每次运行独立 build 卷

run.sh 第 60–97 行实现了一个很实用的并发机制：容器名由 compose run --rm 天然隔离，但 build 卷（挂载到 /src/build）默认是共享的——两条腿并发运行时，一条的产物和 suite 日志会覆盖另一条的，导致并行调度器读不到被删掉的日志而崩。修复方式是给每次运行分配独立卷：

RUN_ID="${CBM_CI_RUN_ID:-$$-$(date +%s)}"
CBM_CI_BUILD_VOLUME="cbm-build-${RUN_ID}"   # 默认；CBM_CI_SHARED_BUILD=1 可回到单卷

配套环境变量：CBM_CI_RUN_ID（命名/复用某次运行）、CBM_CI_KEEP=1（成功后也保留卷）、失败运行时保留卷供尸检并打印 docker run --rm -v <vol>:/b alpine ls -R /b 查看命令。ccache 卷与 fixture 缓存卷则有意共享：ccache 并发安全且内容校验，共享正是让隔离运行保持热而非冷的手段。

3.3 docker-compose.yml：与 CI 环境逐字节对齐

test-infrastructure/docker-compose.yml 的注释第一行即写明 "mirrors GitHub Actions CI for ALL platforms"。几个值得展开的实现细节：

测试服务（ASan + UBSan + LeakSanitizer）：test / test-amd64 服务挂载 ..:/src、cbm-build:/src/build、cbm-fixture-cache:/root/.cache/cbm-test-fixtures、cbm-ccache-{arm64,amd64}:/root/.ccache，CCACHE_MAXSIZE=1500M，命令为 CC=gcc CXX=g++ BUILD_DIR=build/linux-arm64——与 CI 的 ubuntu-24.04-arm job 完全同构。

TSan 服务的 seccomp 例外（docker-compose.yml 第 88–97 行注释）：现代 aarch64 内核的高熵 mmap ASLR 会让 TSan 影子内存在测试启动前就 abort（"unexpected memory mapping"）。解法是 setarch -R（ADDR_NO_RANDOMIZE），但它调用的 personality() 系统调用被默认 seccomp profile 拦截，因此该服务声明 security_opt: ["seccomp=unconfined"]——注释明确论证了安全性：容器里只跑自己的测试代码。入口统一走规范入口 setarch -R bash scripts/test.sh --tsan，与 CI 的 tsan job 用同一个文件。

MSan 单独镜像：test-msan 使用 Dockerfile.msan，因为它要求所有链接库（libc++/zlib）都经过 MSan 插桩，无法用普通镜像加 flag 实现。run.sh 对 msan 腿的注释还诚实记录了一个平台限制：MSan 影子映射在 aarch64 上不可靠，grammar 测试套件在 arm64 上会栈溢出（clang 18 与 clang 22 均复现），而 GitHub 上跑 x86-64，所以本地 arm64 出现该形状失败时应先核对 CI 腿再下结论。

glibc 地板腿：smoke-glibc-floor 用 Dockerfile.glibc22（ubuntu-22.04，glibc 2.35）验证两个契约——musl 静态可移植二进制必须在最老受支持 userland 上通过规范 smoke；而动态二进制必须拒绝启动（glibc 2.38+ 地板是设计使然，运行起来反而是"地板契约被破坏"，脚本会 exit 1）。

Wine 腿：smoke-windows 用 Dockerfile.mingw，执行 scripts/build.sh CC=x86_64-w64-mingw32-clang … 交叉编译后，用 wine64 分别以直接调用和 cmd /c 两种方式验证 --version，并检查 payload exe 不存在。这与 README 的定位一致：Wine 只做编译/版本检查。

3.4 Dockerfile：按 digest 钉死基础镜像

test-infrastructure/Dockerfile 精确镜像 Ubuntu CI 环境：

基础镜像是 ubuntu:noble@sha256:4fbb8e…（multi-arch manifest-list digest，2026-07-23 固定）——注释写明"no floating tags，有意识地升版本，绝不用 tag"，这是供应链意义上的钉死；
最小依赖集：gcc g++ make zlib1g-dev pkg-config python3 git curl zsh ccache zip ca-certificates。sqlite3 走 vendored 源码编译（带 ASan 编译）；curl + zsh 是为了与 GitHub runner 镜像对齐（self-update 测试 shell 出 curl，shell 激活测试操作 zsh rc 文件）；zip 支撑 scripts/package-release.sh 的 .mcpb 打包；
ENV CCACHE_COMPILERCHECK=content + 把 /usr/lib/ccache 放在 PATH 最前：编译器走 Debian 的 masquerade 目录"伪装"，ccache 命中键是编译器二进制 + 预处理后输入的内容哈希，因此一次命中在构造上就证明与冷编译字节相同——"缓存只加速，永不改变结果"（这正是 README 保真清单里的一条）。

3.5 Colima 运行环境

run.sh 的头部注释给出 macOS 上 Colima 的标准安装与启动（免费开源，替代 Docker Desktop）：

brew install colima docker docker-compose docker-buildx
ln -sf /opt/homebrew/opt/docker-compose/bin/docker-compose ~/.docker/cli-plugins/docker-compose
ln -sf /opt/homebrew/opt/docker-buildx/bin/docker-buildx  ~/.docker/cli-plugins/docker-buildx
colima start --vm-type vz --vz-rosetta --cpu "$(sysctl -n hw.ncpu)" --memory 32

资源策略值得注意：vCPU 不是预留量（空闲 guest 核零成本，macOS 调度器自由共享），暴露全部核只是去掉小 VM 的人为天花板；内存是唯一"半预留"资源，故给 32 GB；--vz-rosetta 是 amd64 腿快速模拟的必需项（否则走 QEMU）。监测运行中的腿用 docker logs -f <container>，"定期查看而不是盲等"——suite 结果随完成而流式打印，失败会立刻打印 FAIL 位置。

四、真 Windows 场地：UTM ARM64 虚拟机与 win.sh

4.1 为什么必须真 VM

test-infrastructure/vm/README.md 开宗明义：Windows 内核语义无法被容器/Wine 腿复现——对象属主、DACL、token 身份、CI runner 上的 Administrators 默认属主策略，都需要真 Windows。Wine 只编译检查。UTM VM 是强制本地 CI 门禁的一等公民，通过本地 ssh 由可复现脚本驱动，把"盲目的 CI 往返"变成"秒级的本地回路，且 stderr/调试器全可见"。

vm/ 目录各文件职责（继承原文档表格）：

文件	运行位置	用途
`windows-bootstrap.ps1`	VM 内，一次	OpenSSH + host key + CI 属主策略镜像
`provision-windows.sh`	宿主机	从零到完整构建，幂等（磁盘丢失时的唯一恢复命令）
`win.sh`	宿主机	日常驱动（`win.sh help`）：把每个场地级命令路由到规范腿脚本，带 clean-disk 预检
`vm-run-tests.sh`	VM 内	规范 test/soak 入口的 provision 包装（受保护 TEMP 根 + 完成守卫）
`vm-smoke.sh`	VM 内 / CI msys2	规范 Windows smoke（PR CI 与 `_smoke.yml` 原样运行）

4.2 win.sh：日常循环与逐运行隔离

test-infrastructure/vm/win.sh 是日常驱动，所有 venue 级命令（update/sync/build/test/test-par/guards/smoke-install/smoke-artifact/soak）都路由到规范入口（scripts/build.sh、scripts/test.sh、vm-smoke.sh、scripts/soak-legs.sh），wrapper 只负责 provision（ssh、时钟同步、clean-disk 预检、受保护 temp 根）。日常循环（继承 vm/README.md 示例）：

vm/win.sh update            # 同步 VM 仓库到已推送的当前分支 + 重build
vm/win.sh sync              # 镜像未提交的工作树并重建，用于本地门禁前
vm/win.sh test cli daemon_ipc   # 原生跑 suite，秒级
vm/win.sh guards                  # Windows guard 脚本集
vm/win.sh smoke-install           # 托管安装 E2E，stderr 可见
vm/win.sh soak 10                   # 原生 daemon 耐久门禁
vm/win.sh sh "cd /c/cbm && gdb ..."          # 交互式任意命令
vm/win.sh push-file src/cli/cli.c /c/cbm/src/cli/cli.c  # WIP 迭代

源码中一个值得注意的健壮性设计（win.sh 第 92–113 行）：VM 上只有一个工作树 /c/cbm，update/sync 会替换它（git reset --hard + clean -fdx），两个会话并发同步就会在运行中的腿下换掉代码——注释记录了一次真实事故（2026-08-06，main 上的门禁跑挂了另一分支的文件）。解法是设置 CBM_CI_RUN_ID 后为本次运行克隆独立 checkout（/c/cbm-run-<id>），本地克隆硬链接 .git/objects，秒级且省磁盘。环境旋钮还有 CBM_VM_MIN_FREE_GB（预检磁盘地板，默认 14 GB，即 runner 规格）与 CBM_VM_SKIP_PREFLIGHT=1（仅 bootstrap 逃生口）。

ssh 配置刻意放在仓库外（~/.claude/cbm-vm/config，含 CBM_VM_HOST、CBM_VM_USER、CBM_VM_HOST_KEY_SHA256 指纹），key 在 ~/.claude/cbm-vm/id_ed25519，驱动在每次连接前校验指纹。--help 被设计为不依赖已配置 VM 即可打印（"agent 在读取工具时可能什么都还没有"）。

4.3 工具链与诚实的限制

vm/README.md 用"Toolchains & honest limits"一节把能做什么、不能做什么钉得很实：

CLANGARM64（原生，默认）：全核快速；OS 语义类 bug（ACL/属主/路径/锁——整个 Windows 尾部问题族）忠实复现。构建用 SANITIZE=（aarch64-windows 没有 ASan 运行时）；
CLANG64（x86_64 = CI 架构，模拟执行）：架构一致性检查 + 在模拟下可工作的 UBSan（验证过：可构建、可运行、能报告植入的有符号溢出及 file:line）——win.sh ubsan-build + ubsan-test <suites>。UBSan 不需要拦截器，所以能在模拟下存活；
ASan 在该 VM 上两种架构都不存在——已验证，别再重试：aarch64-windows 的 compiler-rt 不附带任何 sanitizer 运行时，x86_64 ASan 运行时在 x64-on-ARM 模拟下进程初始化即 fault。ASan 覆盖保留为 CI 专属腿（历史经验：CI 的 Windows 失败是逻辑失败而非 ASan abort）;
PageHeap（win.sh pageheap on|off）：OS 级页粒度堆越界/UAF 检测，是原生 ARM64 测试运行器上的工具链无关的"部分 ASan 替代品"；
bootstrap 镜像 GitHub runner 的默认属主策略（NoDefaultAdminOwner=0），使"仅 CI 出现"的属主拒绝能在本地复现；
环境形态（runner temp 路径、runneradmin profile）是近似而非完全一致——最终 SHA 上的 CI 才是证明。

"诚实规则"三条：这些腿绝不静默跳过（工具缺失会打印配置指引并以独立退出码退出）；VM 结果补充而非替代最终 SHA 上的 CI 矩阵；整个 VM 回路只走本地 UTM/宿主网络。

4.4 一次性 VM 创建（约 30 分钟交互操作，做一次，然后快照）

vm/README.md 给出了完整步骤：brew install --cask utm → 官方 Windows 11 ARM64 ISO → UTM 新建 Virtualize VM（全部宿主核、12–16 GB 内存、64 GB+ 磁盘）→ 本地账户安装（start ms-cxh:localonly 离线建号）→ 关机并在 UTM 中克隆 VM（"Windows-CLEAN-backup"）——驱动安装可能弄坏启动，克隆把重装变成 10 秒回滚 → 装 SPICE guest tools 网络驱动 → 通过 ISO 手法把 windows-bootstrap.ps1 送进 VM（Windows-ARM guest 上剪贴板/共享文件夹都不工作，SPICE vdagent/webdavd 服务不存在，别追）→ 宿主执行 test-infrastructure/vm/provision-windows.sh（装 msys2 + 两套工具链、克隆仓库、全量构建、smoke 检查；可随时重跑，是磁盘丢失时的一键恢复）。

关于 Defender 姿态与 VM 长寿问题（venue parity 部分）：每次 venue 级命令前，clean-test-residue.ps1 清扫 temp 根/暂存二进制并断言 runner 级空闲磁盘地板，然后 scripts/ci/ensure-defender.ps1 在本 VM 上启用并验证 Defender 实时防护（fail-closed：Defender 漂移关闭就红）。托管 GitHub runner 做不到这一姿态（其镜像上 RTP 被策略锁死为关，2026-07-27 验证过），因此 AV 交互覆盖是有意的本地超集。另由于 utmctl 动词集没有 snapshot 支持，"每运行回滚干净快照"无法脚本化——诚实的兜底就是上述清扫预检；真正从零开始可手动用 qemu-img snapshot 管理 qcow2（破坏性操作，刻意留在自动化回路之外）。

五、venue-parity 契约：把"漂移"本身变成失败

这套体系最核心的工程保证是 tests/test_venue_parity_contract.sh，作为每条测试腿的 Step 0j 运行（即在被它监管的每个场地内部运行）。它源于一次真实教训（脚本头部注释）：2026-07-26 之前 smoke 跑在三套 harness 上——本地 CI 与 PR CI 共享 wrapper，而 _smoke.yml 带着一份手抄的 YAML 再实现（无环境沙箱、无 user-PATH 守卫、固定端口）；soak 序列存在为六对手工同步的 YAML 步骤对；arm64 sanitizer flag 内联在 _test.yml 里本地场地看不到。每处漂移都隐身到某个 release-only 腿变红才暴露。

契约的五层检查（继承 scripts/README.md 与源码注释）：

FORBIDDEN 标记：任何 workflow 中出现即硬失败——内联 fixture server（http.server）、直调 smoke-test.sh/soak-test.sh/run-tests-parallel.sh（必须经 wrapper 到达）、内联 ACL 构造（AddAccessRule 等，必须调 scripts/ci/new-protected-temp-root.ps1）；
白名单走查：逐一检查 9 个 venue workflow（pr.yml、dry-run.yml、release.yml、nightly-soak.yml、_test.yml、_smoke.yml、_soak.yml、_build.yml、_lint.yml、smoke.yml）中每个 run: 步骤的每一行，每行必须分类为"配机器 / 工件管道 / 调用规范腿入口"三者之一——无法分类的行就是红构建，报错中给出文件名、行号与修复建议；
REQUIRED 标记：统一性本身必须保持被引用（例如 _smoke.yml 必须引用 vm-smoke.sh，_build.yml 必须引用 scripts/package-release.sh），且托管 runner 的 workflow 不得用 ensure-defender.ps1 做门禁（其 RTP 被策略锁死，Defender-ON 覆盖归 VM 预检所有）；
本地场地：docker-compose.yml 与 vm/win.sh、vm-run-tests.sh 不得直调内部 harness；同时断言本地 venue 也保有等价腿（compose 中的 smoke-artifact 与 Dockerfile.glibc22、run.sh 暴露的 smoke-artifact/glibc-floor 腿、win.sh 中的 ensure-defender.ps1 与 smoke-artifact.sh）；
接口探针：每个入口必须应答 --help（exit 0 + 打印 Usage: 块），严格入口必须拒绝未知 flag 并返回 exit 2 + 统一的 Please consult --help. 提示——这样 agent 永远能发现一次运行确切会做什么。

脚本还支持传入伪造 repo root 参数来证明契约在违规时确实会失败（不只是通过），第 5 层探针只在真实 repo root 上运行。另有一个 Windows 特有细节：原生 Windows 进程查找先于 PATH 搜索系统位置，裸 bash argv 可能选中 WSL 别名而非 MSYS2 Bash，所以契约文本层面强制所有 shell 承载的 Python 块必须以显式 $BASH 路径启动。

六、保真保证与已知残留：本地为何能预测 CI

README 的 "Fidelity guarantees" 一节是整套体系的验收标准，完整继承如下四条：

同脚本、同顺序、同 flag——平台特性（如 CLANGARM64 的 trap-UBSan 默认）内聚在规范入口内部，处处一致地应用；
同环境形态——受保护 TEMP 根、沙箱化 smoke、内容校验 ccache 的干净构建（命中即与冷编译字节相同；缓存只加速，永不改变结果）；
同起始磁盘——预检清扫残留，并在低于 runner 的 14 GB 地板时 BLOCK（悄悄写满的磁盘会在安装路径内部失败并伪装成产品 bug）；
已知且刻意的残留——runner 物理差异（4 vCPU vs 本地核数、共享租户）、VM 中 Defender 开 vs GitHub runner 关、Windows 任何地方都没有 TSan、原生 ARM64 Windows 没有 ASan 运行时（trap-UBSan + PageHeap 顶替）。

配合 scripts/README.md 的退出码规范（0 = 通过 · 2 = 用法错误 · 90 = 守卫：运行死了但没有完成摘要，绝不算绿 · 其他 = 该腿真实失败）与"CI 红但本地绿时先怀疑环境形态而非代码"的排查顺序，这套残留清单让"本地绿/CI 红"的差异可解释、可归因。

七、进阶：ladder.sh 把三平台腿重叠执行

test-infrastructure/ladder.sh 是完整的本地 push 门禁加速版：macOS 原生、Colima 容器 VM、Windows UTM VM 是三个独立调度域，串行跑会让机器大部分时间闲置。它把 lint + Linux 容器套件 + Windows VM 套件放到后台，macOS 全量套件在前台跑，每个腿流式输出到自己的日志（失败腿可事后检视而不必重跑），最后汇总一个逐腿裁决：

=== ladder verdicts ===
  PASS macOS
  PASS lint
  PASS linux
  FAIL windows (rc=1) — /tmp/cbm-ladder-$$/windows.log

前提（Colima 在跑、VM 已 provision 且可达）缺失时该腿大声失败，绝不静默跳过——与 README 的"infrastructure unavailable = run blocker"纪律一以贯之。

八、实践清单：如何在这个仓库中跑本地门禁

综合 test-infrastructure/README.md、scripts/README.md 与上述源码，标准工作流为：

迭代中：scripts/test.sh --suites <suite>（秒级、增量、与门禁相同的 ASan+UBSan flag）；suite 列表用 build/c/test-runner --list-suites；触碰并发改动尽早加 scripts/test.sh --tsan；
push 前（三 OS 阶梯）：scripts/test.sh（macOS 全量）→ ./test-infrastructure/run.sh full（Linux + TSan + smoke）→ test-infrastructure/vm/win.sh test-par + guards + smoke-install（触及内存/daemon 路径时加 soak）；
release 形态验证：CBM_SMOKE_ARTIFACT_DIR=<解包后的工件> scripts/smoke-local.sh <binary> [ui]，smoke 的正是将要发布的字节；容器侧对应 run.sh smoke-artifact 腿；
CI 红本地绿：先核对环境形态——预检（vm/win.sh 自动执行；容器侧 scripts/ci/preflight-docker.sh，CBM_SKIP_PREFLIGHT=1 可跳过、CBM_PREFLIGHT_ARGS=--deep 加宽）与 README 的残留清单覆盖了一切可知的差异；
soak 时长：CBM_SOAK_MINUTES（默认 10，与 dry run 一致）；soak-linux 腿跑 quick + #581 query-leak 两条（后者永不重建索引，RSS 增长即查询路径泄漏）；CBM_LOCAL_CI_CPUS 仅用于 smoke/soak 的故意资源饥饿检查，常规套件恒全并行。