skills/tests/bugfix/README.md

bugfix 技能的验证集

用来回答一个问题：一个按 bugfix 技能工作的 agent，能否从"只报告了一处"的 bug 出发，找全整类问题，同时不误伤正确代码、不做越权操作？

每次修改 bugfix/ 后，建议至少重跑一个盲测，对照评分标准打分。

目录

tests/bugfix/
├── fixtures/            预埋 bug 的小项目（纯标准库 Python，无需安装依赖）
│   ├── inventory/       子串匹配类（技能目录中有对应模式，兼测"查目录"）
│   └── scheduler/       秒/毫秒单位不一致类（技能目录中没有，专测"类分析方法本身"）
├── prompts/             给被测 agent 的提示词（{{SKILL_DIR}} 由 setup 脚本替换）
├── rubrics/             评分标准（在首次运行前写好；不要给被测 agent 看）
├── setup_fixture.sh     准备一次盲测
├── reversal-test.sh     "守卫回退"配方的安全性测试
└── RESULTS.md           历次验证结果与据此做的修改

跑一次盲测

以下命令在仓库根目录的 bash（Linux / macOS / Windows 的 Git Bash）中运行。

1. 准备夹具。目标目录必须不存在。脚本会复制夹具、git init 并提交一次，然后把填好技能路径的提示词输出到 stdout：

bash tests/bugfix/setup_fixture.sh scheduler /tmp/bf-scheduler > /tmp/bf-scheduler.prompt.md

2. 让被测 agent 在夹具目录里按提示词工作。以 Codex 为例：

codex exec --sandbox workspace-write -C /tmp/bf-scheduler -o /tmp/bf-scheduler.report.md - < /tmp/bf-scheduler.prompt.md

换其他 agent 时，把提示词内容原样交给它即可，工作目录设为夹具目录。

3. 打分：对照 rubrics/<夹具>.md。不要只看 agent 的报告，要自己核实：

   • 在夹具目录里 git diff 看实际改动；
   • 运行夹具自带的测试：python -m unittest discover -s tests -t .；
   • 把只回退生产代码修复后的版本交给它新增的守卫测试，确认守卫会失败；
   • 逐一检查评分标准里"不得改变行为"的正确代码。

   历史上 agent 的报告出现过两类不实之处：把自查说成"独立评审"，以及漏报返回类型的变化。

守卫回退配方的安全测试

bugfix/references/class-analysis.md 第 6 步的"隔离回退"配方会在副本中撤销修复，用来证明守卫有效。它绝不能动到原仓库。这个脚本在 if 语境下（此时 set -e 会被 bash 忽略），覆盖以下场景：

• 仓库外 / 仓库内的临时目录
• 预先埋好的真实符号链接
• tar 或 mktemp 失败
• 开启原生符号链接时的绝对 / 相对链接

bash tests/bugfix/reversal-test.sh /tmp/bf-revtest

A–G 每个场景都应显示 original still fixed: yes | user wip kept: yes。F/G 场景的 "stray files" 列出的是测试自己预埋的链接，不是配方的产物。H 是对照组：不带符号链接检查时，副本里确实会出现指向原文件的活链接，应显示 yes。

C、F、G 场景需要能创建原生符号链接的环境：Windows 要开启开发者模式，或在 MSYS=winsymlinks:nativestrict 下运行。如果无法创建，C 场景会打印 planted are symlinks: NO-TEST-INVALID。若修改了该配方，必须同步修改脚本里的 recipe()，两者应逐行一致。

新增夹具

1. 在 fixtures/<名字>/ 放一个小项目。要求：
   • 现有测试能通过，但测不出 bug；
   • 有 1 处被报告的实例和若干兄弟实例，兄弟实例要用不同写法、位于不同模块，最好有 1 处严重度更高；
   • 有已写入的错误数据；
   • 有几处看起来像但其实正确的代码。
2. 在 prompts/<名字>.md 写只描述一处症状的 bug 报告（路径用 {{SKILL_DIR}}）。
3. 在第一次运行之前写好 rubrics/<名字>.md，避免看到结果后再改标准。
4. 用 setup_fixture.sh 跑一遍，结果记入 RESULTS.md。