机制分析
修复改变代码，验证改变可信度
任务约定是返回列表最大值，空列表返回 null，并保留原有功能。初始实现把最大值从0开始计算，对全负数会得到错误结果，空列表也不符合约定。六个固定用例先给出基线报告，再把具体失败交给模型。
第一份补丁把初值改为列表第一项。在它进入编辑台之前，工作区仍是旧代码；写入后才成为 v1。此时旧报告只能说明旧版发生了什么，不能继续代表 v1。重新运行全部用例，才能看见全负数修好了，空列表却仍返回 undefined。
第二份补丁补上空列表判断，工作区成为 v2。再次完整复验，代码与当前版本报告一起通过交付闸门。这里的闭环不是“提出两次建议”，而是每次都经过实际应用、独立执行和反馈更新。
| 状态 | 此时可以作出的判断 |
|---|---|
| 补丁已提出 | 有修改方案，工作区未必改变 |
| 补丁已应用 | 代码已变更，还缺新版本验证 |
| 单项失败消失 | 某个问题改善，仍需检查原有行为 |
| 完整复验通过 | 本例约定与固定用例通过，可绑定当前版本交付 |
测试变绿，也可能只是要求被改了
对照实验保留同一份错误代码，却把空列表的测试预期从 null 改为 undefined。局部测试随即变绿，原任务仍没有完成。修复对象与验收依据必须区分，否则系统可以通过削弱检查获得一个漂亮的成功报告。
工程取舍
让验证足够独立，也控制验证成本
只跑失败项，还是完整复验？
失败项适合快速验证假设，完整复验用于发现对其他行为的破坏。大型项目可以先跑相关测试，再按变更影响补充回归范围；交付时应明确哪些检查真正执行过。把“相关项通过”写成“整个任务通过”，会隐去尚未获得的证据。
测试能不能随代码一起修改？
需求变化或测试本身有错误时，修改测试可能合理。但这需要独立的任务依据，不能只因当前实现失败就调低标准。本例固定验收用例不允许改动，因此改预期明确违反约定；真实项目应记录测试变更原因，并让评审能区分修复实现与改变需求。
报告绑定版本，绑定到多细？
示意中的 v0/v1/v2 足以讲清归属；真实仓库还需辨认实际代码、依赖、测试命令与运行环境。提交号可以提供索引，但若运行时还有未提交修改，只记录提交号仍不完整。保存适当的工作区标识和执行记录，能避免测试完成后代码继续变化，而旧绿灯仍被沿用。
落到实现
把失败反馈写成下一步可以使用的输入
“测试没过”只能提示失败；输入是什么、预期是什么、实际是什么，才能支持下一轮定位与修正。每次修改后，应让验证状态明确回到待验证，再接收本轮的新报告。这样，程序可以主动阻止拿旧证据交付，而不只依赖模型记得提醒自己。
本页模型输出与补丁流采用预设，六个 JavaScript 用例在浏览器内执行。用例全部通过，只能证明本例检查范围内的结果；它不等价于对所有输入的形式化证明，也不能代替真实仓库与目标环境的验收。
补丁说明打算怎样修，执行说明实际改了什么，复验说明哪些行为获得了支持。三份记录对齐，修复才有可以交付的依据。