perf(ci): cargo 缓存缺失，Windows 每次触发跑两遍全量测试

[2233admin]

症状

.github/workflows/ci.yml 内没有任何 cargo 构建缓存，且同一次 CI 触发在 Windows 上跑两遍全量测试。

只读证据

缓存缺失：ci.yml 全文无 actions/cache，无 Swatinem/rust-cache 之类的 Rust 缓存 action，也无手写的 cargo target 复用。.github/workflows/ 下 5 个工作流均未命中任何缓存配置。

Windows 重复：

位置	内容
ci.yml:14-16	windows-build-test-package 固定 job，runs-on: windows-latest
ci.yml:72	cargo test -p code-intel --locked
ci.yml:355-358	矩阵 os: [windows-latest, macos-latest, ...]
ci.yml:445	cargo test -p code-intel --locked

矩阵含 windows-latest，所以每次触发 Windows 全量测试执行两遍。另有两处重复的 release build：ci.yml:80 与 ci.yml:449。

成本规模（静态计数，2026-09-30 快照）：

• 229 个 .rs，3,298,590 字节
• 69 个集成测试文件；其中 28 个直接用 #[path = "../src/…"] 引入生产模块（121 次直接声明），48 个经 tests/common/mod.rs:7-8 再引入 src/env_contract.rs，合计 169 次生产模块引入实例
• 最密的 tests/decision_record.rs 直接引入 12 个生产模块（:10-33），加 common 后 13 个
• 最深的重入链 4 层：decision_record → run_commit → staged_artifact → stable_artifact
• [profile.release]: opt-level 3 / lto thin / codegen-units 1 / strip；无显式 dev profile 设置
• 仓库无 .cargo/config.toml
• target/ 本地 14,997 文件 / 5,657 MB

未执行任何编译或测试，全部为静态读取。

为何不在现有 issue 下处理

已核对全部 open 与 closed issue，无一条覆盖 CI 基建成本：

• feat(perf): benchmark 驱动的迭代性能优化闭环（对标 weco-skill） #299 feat(perf): benchmark 驱动的迭代性能优化闭环 —— 产品功能面，不是 CI 成本
• feat(perf): 候选安全门禁 + 自动开 PR（复用 #94/#95 护栏） #302 feat(perf): 候选安全门禁 + 自动开 PR —— 认领于 2026-08-21，其分支 issue-302-perf-safety-gate 在本地 heads 与 origin 跟踪 refs 中均不存在，属僵尸认领，应单独清理而非复用
• ci: keep Sentrux gate from hanging on ripgrep bootstrap #295 ci: keep Sentrux gate from hanging on ripgrep bootstrap —— 已关闭，针对 ripgrep bootstrap 挂起，与缓存无关

上游自有的修复与验收

第一步必须先建立基线，不能直接改矩阵。 目前没有任何实测耗时数据（原因见下），无基线时改矩阵是猜测。

1. 在 ci.yml 引入 cargo target 缓存（Swatinem/rust-cache 或 actions/cache + ~/.cargo/registry），保持 --locked 不变，不改动任何测试选择或闸门语义。
2. 在启用缓存的同一次触发上记录 cargo test -p code-intel --locked 与 cargo build -p code-intel --release --locked 的耗时，形成"改前/改后"两个数字。
3. 报告这两个数字，再决定 ci.yml:14-16 固定 Windows job 与矩阵中 windows-latest 的职责如何切分。若两个 job 覆盖的步骤实为重复，应合并或让固定 job 只跑矩阵不覆盖的那部分；若职责确有差异，需在 issue 里写明差异后再动。
4. 缓存不得放宽任何既有断言：cargo test --locked 的选择集、--ignored --nocapture 的 packaged install smoke 步骤（ci.yml:698,707,711）与 orchestration/sentrux-capability-matrix.v1.json 的 closure 校验（ci.yml:771-807）必须原样保留。

阻塞：无法在本机取得耗时基线

本 checkout 所在 Windows 主机被 docs/decisions/DR-0013-affected-host-compilation-isolation.md 隔离（issue #403 未结期间禁止 cargo build / cargo test / cargo check / cargo clippy / cargo run / cargo nextest / cargo clean）。因此基线必须在其他主机或 CI 上取。

DR-0013 的 Why 段落已记录本机 32 逻辑核 / 93.7 GB RAM / 页文件分配 68 GB 峰值 1.4 GB / 四盘 Healthy / 近 7 天零 WHEA 记录——本机不是被资源耗尽压垮的，所以"CI 慢"与"主机崩溃"是两件事，不要混为一谈。

严重度

P1。不是故障：CI 仍能通过且闸门语义完整。但每次 PR 都付双倍 Windows 全量测试代价，在 69 个测试二进制 / 169 次生产模块引入实例的规模下这是可测的持续成本。

[2233admin]

2026-09-30 收敛判决（DR-0014）

Verdict: do — 但第一个交付物是测量，不是改矩阵。

本票在本轮之前是唯一一张既无 claimed 也无任何评论的 open 票（[enhancement, 领域/横向]），票面已记录事实：CI 无 cargo 缓存，Windows 每次触发跑两遍全量测试。

核实到的现状（2026-09-30，只读）

• gh pr list --state open 只有 1 个 fix PR（fix(codenexus): normalize repository and target paths #392，agent/issue-337-codenexus-rust-clean，状态 CLEAN/MERGEABLE）。DR-0005 的上限是 5，本票不触发整合债上限。
• 本 checkout 所在主机被 DR-0013 隔离，无法产出本机的构建计时基线。票面已指出"零实测构建计时或峰值内存"是已知缺口——而这正好意味着本票的基线必须在 CI 或其他主机采集。

因此第一交付物的形态

本票不应以"改 ci.yml 矩阵"开头。票面自己写明"第一个交付物是实测基线，不是矩阵变更"，理由成立：

1. 现在没有任何计时数据。在没有基线的情况下删 job 或改 matrix，等于用猜测换成本，且无法证明没有漏掉某条真实需要的检查。
2. 本机被隔离，本地也拿不到数据。基线只能来自 CI。

建议第一步：一次只采集不改动的 CI 观测——在 ci.yml 相关的 job 上加计时上报（或直接用 GitHub Actions 的 job 时长数据），拿到 Windows 固定 job（ci.yml:72）与 matrix job（ci.yml:445，windows-latest 在 :355-358）各自的实际耗时，再决定矩阵怎么动。

边界

• 加计时上报本身是低风险、可评审的改动，不触碰 AGENTS.md 声明为有意的结构（#[path] 重入、main.rs 的 mod 规模），也不碰 PowerShell 退役线。
• 动矩阵前确认：DR-0013 只隔离本主机，CI 不受该约束影响，CI 上的验证是合法且必要的。

[2233admin]

2026-09-30 首次实测数据（PR #406，cross-platform-smoke Windows 取消）

本票开于 2026-09-29，当时零计时数据。PR #406 的第一次运行提供了第一组实测值。

同一 run 内的横向对照

Job	耗时	结论
cross-platform-smoke (ubuntu-latest)	10 分 34 秒	success
cross-platform-smoke (macos-latest)	13 分 58 秒	success
windows-build-test-package	24 分 23 秒	success
cross-platform-smoke (windows-latest)	30 分 15 秒	cancelled

ci.yml:362 给 cross-platform-smoke 设了 timeout-minutes: 30。Windows 跑满 30 分 15 秒后被 GitHub 取消。

关键：这不是测试失败

Windows 作业在取消前所有步骤都通过了：

• test result: ok. 1117 passed; 0 failed; 1 ignored
• test result: ok. 428 passed; 0 failed（以及 425、427 等多个 target）
• Hardcoded path scan: OK (297 files)
• 失败点是最后一步 Post Setup Python 的 ##[error]The operation was canceled.

也就是说：测试逻辑没红，红的是时间预算。

这印证了本票的原始判断，且比原描述更严重

票面写的是"Windows 每次触发跑两遍全量测试"。实测补充了另一半、也更致命的一面：Windows 不只是贵，它是唯一会撞上 30 分钟上限的那一档。windows-build-test-package 24 分 23 秒通过，距上限只剩 5 分 37 秒余量——任何让测试变慢的改动都会把它推过去。

值得注意的是，windows-build-test-package 与 cross-platform-smoke (windows-latest) 在同一次 run 里并行跑了两遍全量 Windows 测试（一个 release 构建打包，一个跨平台 smoke），这正是票面已记录的结构问题。#404 提出的"先测基线再动矩阵"现在有了第一组数据支撑。

一个反直觉的观察：加 cargo 缓存可能不足以解决

缓存能省掉的是重复编译时间，而 Windows 30 分钟里的大头从日志看是测试执行（1117 + 428 + 425 等多个 target 的 test result 行耗时可观），不是编译。所以"加缓存"与"降低测试时间"是两条不同的路径，值得分别测量。

未解决

本票的第一个交付物是基线，现在有了横向对照，但还缺：

• 单个 target 的耗时分布（哪些测试最贵）
• 有无 cargo 缓存时的对照值
• 这两条在不同机器/不同触发上的稳定性

这些都需要更多 run 才能收敛。本票的判决仍是 do，但下一步应基于"Windows 时间预算"而非笼统的"CI 贵"来排序。

[2233admin]

Claimed (DR-0004). Branch: perf/issue-404-ci-cargo-cache. Approach: measure per-step baseline from recent code-intel-ci runs, add SHA-pinned Swatinem/rust-cache to compiling ci.yml jobs, and skip only the duplicate full cargo test in cross-platform-smoke on Windows (windows-build-test-package keeps it; installed-topology/install_smoke steps keep running); job names unchanged.

[2233admin]

PR #413 has before/cold/warm timings in its body. Windows smoke leg: 25.4 to 13.8 cold and 11.7 warm (min), from skipping the duplicate cargo test. Windows runner-minutes per trigger: 49.4 to 38.7 cold and 35.9 warm. rust-cache gives a small win, 0.2-1.1 min per compile step: it caches only deps, and the workspace crate dominates compile. Wall clock is still about 24 min, set by windows-build-test-package, whose ~9.5 min of test execution is the remaining lever. That is out of scope for PR #413.

[2233admin]

Delivered by #413 (squash-merged to main). Both asks are done: (1) Swatinem/rust-cache pinned by SHA in windows-build-test-package and all three cross-platform-smoke legs; (2) the Windows smoke leg no longer repeats the full cargo test suite, and its unique install-topology checks (DR-0001) still run. Measured, median of 5 before vs warm after: Windows runner minutes per trigger 49.4 -> 35.9, all jobs summed 75.2 -> 58.3. Workflow wall clock is unchanged at ~24 min, bounded by windows-build-test-package (~9.5 min test execution, ~4.5 min thin-LTO release build). Wall-clock reduction would need a separate change to the test/build profile; not in scope here.