这轮本地审计里，39 项现有离线测试全部通过，但一份合法的 38 条记录文件仍然导入失败。同一文件按物理行读取正常，现有导入器却报错。检查发现，它把文本里的合法 Unicode 分隔符误当成了记录边界。
事实。 Python 3.12 文档把 U+2028 和 U+2029 列为 str.splitlines 的行边界。json.loads 可以解析含 U+2028 的合法 JSON 字符串；splitlines 却会把文本拆开。
最小复现思路
在合法 JSON 字符串里放入 U+2028。解析器认为这仍是一条记录；按行切割的导入器看到两条残片。这说明测试还缺一个真实输入边界。它不能证明哪个 AI 模型好坏，也不代表修复已经完成。
验收一个自动化步骤，可以多交三样东西
- 一个正常输入；
- 一个容易遗漏的边界输入；
- 对应的预期结果。
“测试通过”之外，再用实际文件走一次最终入口。让结果、输入和验收条件对得上。
下一步，而不是已经做完的事
研究 brief R02：修最小 loader，按正常输入、边界输入、坏输入验证，保留前后结果。完成条件是真实 38 条返回正确、合成输入可读、错误输入报告正确物理行。范围是一个函数及其必要验证，不重写采集系统。
判断。 这是 OnBalls 自己的工程案例，用来说明“任务结束了”和“输入被正确理解了”不是同一句话。不把这个 bug 写成 AI 写代码的原罪，也不外推模型质量。
限制
- mock 和本地文件不是供应商宕机。
- 未在本预览中声称源码已修复。
- 不公开内部采集正文。