C07：一台洗衣机为什么没有变成两台

这是一份合成教学轨迹，不是 OTTO 或任何客户的代码。它只检查需求改变、回执丢失、重试和进程恢复之间的关系。时间是示意，不能用来评价真实性能。此包没有实现库存保留、支付、身份权限、完整幂等存储或崩溃期间的分布式事务；真实项目须另行设计并验证。

先做五个判断

顾客先要求宽度不超过60厘米，发出查询Q1，需求版本为v1；随后改成55厘米，发出Q2，当前需求变成v2。Q2返回宽54厘米的SKU-54，顾客确认加一台。助手把商品编号、数量1、需求v2固定为加入意图A1的内容。

本题约定：服务端按动作号和内容识别同一次意图，编号记录与业务变更须作为不可分割的操作保存。同号同内容可以查询或重试原动作，同号不同内容要报冲突。这是接口约定，不代表某次请求已经完成。

下面各题单独判断。先只用题面中助手能取得的信息作答，不必打开完整轨迹；第5题另给了恢复后的条件，不能拿它倒推第1题当时知道什么。

每题记下判断、依据和下一动作，再看下文。判据是状态与动作是否一致，不以“全程无错误”得分。

没有回音只能记为结果待核实，不能报告失败，也不能另发新动作号。先核对原动作；本题允许带着已保存的A1及相同内容重试。完整轨迹随后揭示：第4步服务端已经写入并保存R1，丢失的是回传。助手超时当时并不知道这个后台结果。
A2会把同一意图标成另一项动作，可能多加一台。修复需要沿用已保存的A1和相同内容，不是删掉重试功能。
同号但数量变化应报冲突，不能当作正常重试。顾客若确实想再增加，需要新的明确确认与新意图号。
迟到的Q1属于v1，59厘米不满足当前55厘米条件，不能直接推荐。可以重新按v2查询，不应自行恢复旧条件。
只有回执而读不到购物车，仍不能完成两者核对。保留不确定并升级排查，不重放写入。若两者可读且相符，本轨迹应核对A1对应R1、购物车版本12及SKU-54数量1，再恢复已确认进度。

现在查看 8步记录和请求与回执，再用空表整理依据与下一动作。CSV包含后台实际发生的事；仅遮住next_action列，仍会看到写入与回执结果，不能当作助手当时的视野。

先核对三件事：当前条件是55厘米，商品宽54厘米，首次加入后数量始终为1。再核对编号：需求v2用来判断查询是否过时，A1识别加入意图，R1记录该意图的处理结果，购物车版本12标识业务状态。它们不能互换。“购物车未重复”也不能证明库存有效或订单安全。