交付验证依据，而非绿色状态灯

一句话总结

交接不是提供一张成功截图，而是说明使用了哪些代码和输入、验证了什么，以及还有什么问题尚未解决。

为什么需要这些知识

开发人员说“运行正常”，客户却问“昨天的文件重新上传也没问题吗？”双方所说的成功并不是同一回事。开发人员只观察了一次正常请求，客户问的是下一位负责人重复运行时，业务是否仍不会被破坏。良好的验收标准会在编写代码前揭示这种差异，并要求最后按同一标准再次确认。

它是如何运作的

首先分离计划模式和发送模式。默认运行不会发出任何 HTTP 请求，而是把原始文件哈希、发送候选、重复传递和暂缓项记录为 JSON。只有明确指定 --send，才会开始创建和查询预留。这样，“真正产生变更的操作”就成为一项清晰可见的选择。不能因为存在计划文件，就解释成发送已经完成。

发送报告会记录每个准备处理订单的 status、attempts 和 reservation_id。attempts 只统计 POST，不包含查询账本的 GET，也不包含 CSV 中重复传递行的数量。如果存在暂缓行，或无法确认处理结果，程序应返回退出码 2。该代码不表示程序崩溃，而表示处理结果中仍有需要审核的事项。如果监控系统或后续自动化不加区分地重新运行所有非零退出码，暂缓项和故障就会再次混为一谈。

实操评分器不会相信你输出的成功消息，而会启动独立的仓库 API，并将报告与真实 HTTP 请求数量及 SQLite 账本进行核对。它还会修改输入中的部分订单编号、SKU 和数量。如果把提供的 CSV 答案硬编码进程序，更换输入后就会暴露。你要实现公开的 CLI 与 HTTP 契约，而不是直接修改评分材料或账本。

检查项	要确认的问题
plan	是否在不发送数据的情况下对全部输入完成分类？
send	是否只向正常服务器预留候选订单，并查询了结果？
chaos	是否同时处理了保存前的 503 和保存后的响应丢失？
repeat	使用同一账本重启服务器并重新运行后，是否仍无重复？
drift	现有订单内容变化时，是否没有绕过 409？
outage	持续出现 503 时，是否在四次后停止并保留为未确认？

最后一步是制作包含这六项检查结果的交接文档。implementation_sha256 指向经过验证的 sync.py，fixture_sha256 指向交付的样例 CSV。哈希本身不是质量评分，而是区分文件在验证后是否发生变化的标记。即使只修改注释，文件字节也已经改变，因此必须重新生成文档。

verified_cases 记录实际执行的场景，unresolved 则注明不良数量和冲突订单仍需判断。decision 应为 review_only，因为通过教学测试不能代替客户的生产批准。limits 应说明这是合成的单仓库实验，不等同于运营批准。最终评分也不会只检查文档字符串，而会使用当前代码重新运行检查。

在实际工作中会是什么样

对下一位负责人来说，只有失败订单编号可能并不足够。他们还需要知道该订单来自哪个输入的哪一行、是否已经存在确认的预留，以及在哪些情况下停止了重传。但这并不意味着要把整个原始文件和客户邮件复制进日志。本任务只使用经过验证的订单 ID、行号和简短原因。即使材料是合成的，也要练习不传递不必要的个人信息。

这个评分器是在实操容器中运行的正确性检查，并不是用于隔离同等权限恶意程序的独立安全系统。六个场景也无法代表所有故障。分别写清验证已经覆盖的范围，以及真实生产环境仍需补充审核的内容，才是可信的交接。

也要考虑下一位负责人的第一个动作

如果接手的人理解成“先把所有内容全部重跑一遍就行”，说明文档仍不充分。暂缓原因 invalid_quantity 表示要向原始数据负责人确认允许使用的整数数量；conflicting_order 则表示要向业务负责人询问哪一份内容才是已批准订单。工程师不能根据行顺序或较小数量自行猜测这两项判断。收到修正文件后，不应覆盖原始文件，而要把它作为独立输入运行计划模式，确认候选项和暂缓项发生了哪些变化。

如果已预留订单的数量发生变化，就要更加谨慎。本次 API 只提供创建和查询预留，不提供修改或取消流程。不要使用新键强行提交变更后的数量，而应同时展示现有预留和变更请求，与客户约定变更流程。这是一次小型练习，用于区分“验证已经通过”和“有权执行本次变更”。最终文档应继续保持 review_only，不能声称相关判断已经完成。

未确认状态的处理方式也不同。不能修改原始数量，而要使用同一业务标识符查询对方结果，并保留原有键。无需把个人电子邮箱地址扩散到新日志，也能通过订单和输入哈希传递上下文。本课程结束后，如果要向他人说明自己的程序，不仅要讲正常成功时如何运行，还要说明何时必须停止、需要询问什么。

下一次实操要做什么

你将使用 scope.json 固定需求，按计划、正常发送、重试的顺序完成 sync.py。确认重启、内容变化和持续故障后，再创建 handoff.json。预计需要 80 分钟，因此请在默认 60 分钟会话结束前使用“＋时间”延长。最长可延至 180 分钟，会话结束时文件会消失。请在结束前把完成的代码另行保存到个人工作空间。