Codex 编码修复实测：0007 变成 7 后，怎样确认补丁修好了

先写清导入器应该保留什么

这个项目和缺陷都由本站当前 Codex 代理专门构造。它用于展示怎样复现一次改动，并非从真实客户仓库中抽取的未知挑战。任务约定编号是字符串，0007 与 7 可以同时存在，AG-001 也应被接受；前后空白可以去掉，标题内部的空格继续保留。

acceptance_cases.json 在补丁前写好八组输入与预期结果。测试还要求拒绝空编号，真正重复的编号也必须继续报错。冻结文件记录了测试与原版程序的 SHA-256；复做脚本会核对这些值，不能改完程序后再悄悄放宽原来的判断。

旧版把两个合法编号合成了一个

旧版读取每行 CSV 后，把 task_id 字段交给 int。这样会把 0007 变成整数 7，随后读到原本就是 7 的编号时，重复检查会报错。下载包中的 sample-tasks.csv 只有下面两条记录，标题带逗号的那一项使用标准 CSV 引号，不需要自行拆分字符串。

实际运行旧版命令行后，它以非零退出码结束，错误为 duplicate task_id: 7。函数测试也有六项失败，另外两项通过。通过的是原本就能拒绝真正重复编号与缺失表头的检查；它们要在修复后继续成立，不能为了接收新样本而删除。

task_id,title
0007,"Task, 中文"
7,Second task

补丁只改编号转换并补空值检查

修复把整数转换改为字符串 strip，再单独拒绝空编号。CSV 读取和标题处理没有重写，原有重复检查也保留。Python 的 CSV 文档说明，读取字段通常返回字符串；这次丢零来自项目自己追加的 int 转换，不能归咎于 CSV 文件里少了引号。

下面是保存下来的真实差异。它替换一行转换代码，再增加两行空值检查。这个规则只适用于本项目约定的编号格式；如果另一个系统把编号两端空格也视为有效内容，就需要另写预期，不能直接复制 strip。

-        task_id = int(row['task_id'])
+        task_id = row['task_id'].strip()
+        if not task_id:
+            raise ValueError('task_id must not be empty')

相同测试通过后再走一次命令行

修复后再次执行同一份测试，八项全部通过，错误数为零。小项目也实际从命令行读取同一个 CSV，输出里同时保留字符串 0007 与字符串 7，带逗号的中文标题没有被拆开。记录中的 expected 与 actual 都可以下载查看，而不是只给一个完成提示。

每条命令的退出码与测试输出分别保存。为避免公开本机目录，日志只把执行目录前缀改成相对路径，失败信息没有改写。复做脚本还会重新计算冻结文件的校验值；测试本身发生变化时，它会停止，而不是把新的测试通过冒充原结果。

怎样把这个样例换成自己的项目

解压完整资料包后，在 coding-agent-acceptance 目录执行下面的命令。脚本先运行保留缺陷的 before 版本，再运行 after 版本；前者失败是预期步骤，后者没有通过才会让整次检查报错。逐项 CSV 方便比较，JSON 则保存了输入合同与实际观察。

这里只完成一个自建问题，没有测大型仓库，也没有比较多个模型。真实项目还要按自己的数据格式补充样本，再执行已有回归测试。代理提交了补丁之后，应继续检查实际输入能否得到正确输出；这份资料包提供的是可以重复执行的做法，不是对其他修复任务的成功率承诺。

python3 run_repair_checks.py