feat: 添加write-stable-tests 的 Skill 来限制 AI 编写测试代码，增加测试报告和性能分析

[xiaoyumuxi]

Summary

• add the write-stable-tests skill with deterministic test rules for macOS, Windows, and Rust
• add bounded per-test timing, static blocking-pattern checks, JUnit XML, and self-contained HTML reports
• keep macOS on Swift/zsh/Node.js only; isolate Bun to Windows Frontend tests
• upload test stability artifacts from macOS, Windows, database, and plugin CI lanes

Validation

• macOS full lane: 630 tests passed
• Shared Rust lane: 243 tests passed
• stability verifier, classifier tests, Windows boundary checks, YAML parsing, and skill validation passed
• focused macOS stability run passed without invoking Bun

Windows runtime execution was not available in the current environment; Windows scripts and boundary checks were validated locally.

[xiaoyumuxi]

@1lck 这个 windows 端我也改动了，但是我没有虚拟机进行测试，如果方便的话能不能帮忙测试一下

[xiaoyumuxi]

这个改动的核心目的就是因为原来 CI 流程中 MacOS 的构建经常出现超时的问题，而且往往都是随机性的，后来经过日志分析发现大多数情况都是因为 codex 在写单元测试的时候，有的时候是偷懒直接使用阻塞同步的方式去进行书写和构建的，因此我添加了这个 skill 从而强制AI 单元测试需要考虑同步耗时，如果耗时有异常的话需要提醒 AI。此外对于性能测试等内容，我对所有的方法都实现了一个性能报告的东西，会提醒某些超时异常的内容

如下:

[xiaoyumuxi]

@lithe review

[github-actions]

Lithe Review

结论： ⚠️ 建议修改
依据： 无关联 Issue · 228dacf ← e9d9b6b · head: e9d9b6b

变更理解

本 PR 新增跨平台测试稳定性规则、静态阻塞模式检查和逐测试计时报告，并将 Swift、Windows 前端及 Windows/共享 Rust 测试切换到新的 CI harness。

发现

1. [P2] Rust 的 SuiteTimeoutSeconds 只限制编译，没有限制整个测试套件
   .agents/skills/write-stable-tests/scripts/test-stability-windows.ps1:46

   PowerShell harness 将 SuiteTimeoutSeconds 仅转换为 --build-timeout-ms；随后 run-rust-tests-with-timing.mjs 会逐个运行全部测试，但没有覆盖“编译 + 枚举 + 所有测试”的总 deadline。CI 虽传入 1080 秒，却在 20 分钟处直接终止步骤。可构造的失败场景是 Windows 编译耗时接近 18 分钟，之后数百个测试各自都低于 15 秒硬预算、但累计超过剩余 2 分钟；此时首先终止流程的是 GitHub step timeout，而且 runner 尚未执行到写入 JSON/JUnit/HTML 的位置。缓存失败触发一次干净重试时，这个风险更明显。应为整个 Rust runner 增加单一的 suite deadline，并让编译、枚举、逐测试执行和缓存重试共同消费该预算，且在超时前落盘当前记录。

2. [P2] 新增的 Swift 阻塞门禁允许显式无限等待通过
   .agents/skills/write-stable-tests/scripts/verify-test-stability.mjs:15

   swift-unbounded-wait 只匹配没有参数的 .wait()。因此新测试写成 semaphore.wait(timeout: .distantFuture) 或 group.wait(timeout: .distantFuture) 时，新增行不会产生违规，但它们仍然没有本地 deadline，能够复现本 PR 要阻止的 CI 卡死路径，并直接违反同一 skill 中“Every wait has an explicit local deadline”的约束。现有 verifier 自测也只覆盖裸 .wait()。应至少拒绝 .distantFuture 等无限 timeout 表达式，并为该绕过路径增加门禁测试。

验证

• 实际检查了 24 个变更文件的确定性清单与聚焦 diff，并沿 macOS/Windows/database/plugin CI、Swift/Bun/Rust timing runner、进程终止、报告生成、静态 verifier、自测和 change classifier 调用链检查。
• 已提供的 CI：Plugin CI gate、Database CI gate、Swift tests、Rust Core and Swift bridge tests、Plugin tests、Rust database tests、Swift database tests及 Classify changes 成功；Windows implementation 与 release package verification 仍在进行中。
• 本次审查未运行测试。

[xiaoyumuxi]

@lithe review

[github-actions]

Lithe Review

结论： ⚠️ 建议修改
依据： 无关联 Issue · 228dacf ← 0b16ecc · head: 0b16ecc

变更理解

本 PR 新增跨平台测试稳定性门禁、逐测试超时与报告生成，并将 macOS、Windows、数据库及插件 CI 接入这些 harness。当前 head 已修复上一轮指出的 Rust suite deadline 和 Swift .distantFuture 单行检测问题。

发现

1. [P2] Rust 编译失败会丢失 rustc 诊断和结构化报告
   .agents/skills/write-stable-tests/scripts/run-rust-tests-with-timing.mjs:149

   Cargo 使用 --message-format=json，因此编译诊断位于 stdout；但构建调用没有启用 streamStdout，日志也只追加 build.stderr。当 Windows PR 引入 Rust 编译错误时，此处分支只抛出退出码，随后通用 catch 又不会调用 writeReport()，CI 中最终只能看到“compilation exited with code …”，既没有 rustc 错误正文，也没有该 lane 的 JSON/JUnit/HTML。应把 Cargo JSON 中的 rendered diagnostic 输出并写入日志，同时在所有编译/枚举失败分支落盘 failure 记录后再退出。

2. [P2] Bun suite 超时在生成任何稳定性报告前直接退出
   .agents/skills/write-stable-tests/scripts/run-bun-tests-with-timing.mjs:60

   runProcess 检测到 suite timeout 后立即抛错，后面的 JUnit 解析、JSON 写入和 HTML 生成均不会执行。可构造的失败场景是 Windows 前端测试卡死至 660 秒：恰恰在最需要定位挂起测试时，上传目录中没有规范化的 timeout 记录和 dashboard；若 Bun 没有在被终止前完整刷新 JUnit，后续聚合步骤也会因没有 JSON 报告而失败。应在超时分支先保存已完成用例及明确的 suite timeout/incomplete 记录，再生成 JSON/JUnit/HTML 并返回失败。

3. [P2] 阻塞门禁可通过换行书写无限等待绕过
   .agents/skills/write-stable-tests/scripts/verify-test-stability.mjs:195

   所有规则都逐行匹配，因而合法 Swift 写法 gate.wait(\n)，以及 gate.wait(\n timeout: .distantFuture\n)，每一行都不会命中第 15 行的正则。这样的新增测试可以通过 PR 门禁，却仍会阻塞测试进程，直到 timing harness 强制终止整套 Swift 测试；现有 verifier 自测也只覆盖单行形式。应对去除注释/字符串后的完整源码或跨行调用片段匹配，并加入上述多行 fixture。

验证

• 实际检查了 24 个变更文件的确定性清单和聚焦 diff，并沿 macOS/Windows/database/plugin CI、Swift/Bun/Rust runner、进程终止、报告生成、静态门禁、自测及 change classifier 调用链核查；按规则读取了 macOS、Windows/Rust 和报告规范。
• 已提供的 CI：macOS、Windows、Plugin、Database gate，以及 Swift、Rust Core/bridge、Windows implementation、release/package、数据库和 classifier checks 均成功。
• 本次审查未运行测试。