4 次代码提交

包含重命名

作者	SHA1	备注	提交日期
Mimingguang	0c042ba736	docs(changelog): #7203 verified 回写;#7067 记 U5 已交付	2026-09-07 19:02:13 +08:00
API Changelog Bot和Claude Opus 5	c656b273f0	fix(#7203): 更正二轮复审返工的三个新错误码与核心口径 ... 二轮复审(PR #7275)推翻了旧口径「同步失败=订单侧未收到」的断言。实际上： - 远端已提交成功但回执丢失时，发送端重试耗尽后也会进隔离 - 此时订单侧已是 DONE，直接排车会被 605906 拒 - 故撤销接口需回查订单侧实况后分流三个错误码 本次更新： 1. 补充新增的两个错误码（605923/605924）及其触发条件和前端处置 2. 限定「不必先撤销」仅对 605921 分支成立，605923/605924 必须走运维对账 3. 推翻行 422-425 的核心断言，澄清隔离不等于订单侧未收到 4. 更新 syncStatus 值表 FAILED 的说明文案 5. 注明测试证据表中该行是旧口径的记录 6. 更新 front-matter status_note 记录二轮复审已合并 Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>	2026-09-07 15:31:09 +08:00
Mimingguang	1c2156fbda	chore(changelog): #7203 决策并入 #7067 U5 向导四步化一起做,保持 pending	2026-09-07 14:14:15 +08:00
API Changelog Bot	9f27d9bfb8	changelog(7203): 车务显式声明「整段不用车」——声明/撤销/回显三个新增端点 ... #7067 去槽位化后占位行退役，「车务决定整段不派车」在车管侧就是零派车行， 与「还没开始排车」在库里逐字相同、无法区分，订单侧的用车需求因此永久卡在处理中。 本单新增需求级显式动作承载这个语义（不按零行推断、不放宽常规快照门禁、不复活占位行）。 三个端点各自自包含：入参/出参/请求示例/响应示例/空数据形态/错误响应/业务边界。 另附枚举字典、正确 vs 错误 payload 对照、数据库行为、边界行为与不影响范围。 前端最要紧的三条已写在开头： - syncStatus 不是订单状态，SYNCED 只表示「送到了」，order-v3 可能按自身规则忽略； - declarationStatus=REVOKED 时 syncStatus 为 null，不要展示同步状态； - 撤销按钮只在 syncStatus=SYNCED 时可点，但「只想继续排车」不必先撤销。 实测证据章节为测试服网关真实往返（HEAD 02d7e59be，fleet 双实例）， 逐条核对了订单侧 status / assignment_snapshot_revision / assignment_completion_disposition / assignment_count / assignment_no_vehicle_reason， 不是只看 HTTP 200。	2026-09-07 13:41:46 +08:00