hl-api-changelog

2,934 提交 29 分支 0 Git 标签

2 次代码提交

包含重命名

作者	SHA1	备注	提交日期
Mimingguang	72bb0ff4ad	docs(changelog): #7990/#7964 前端实证 not_required(#7990 TRAVEL 流程逐字正确,TRANSFER 取参口径入 memory;#7964 internal 不可达) changelog-filename-gate / validate (push) Failing after 2s 详情	2026-09-20 18:02:12 +08:00
API Changelog Bot和Claude Opus 5	73e0def125	docs(changelog): #7990 车务看板订单详情按需求各返一组身份三元组，接送机确认参数有来源了 changelog-filename-gate / validate (push) Failing after 2s 详情 GET /admin/fleet/board/orders/{orderId} 新增 requirementIdentities：每条用车需求各一项，含 kind / requirementId / requirementVersion / requirementSha256 / dispatchPlanGeneration。顶层原有的那一组三字段语义不变，仍指行程用车（TRAVEL），前端不改也不炸。为什么前端必须接：POST /admin/fleet/assignments/requirements/{id}/confirm 的三个 expected 入参（version / sha256 / planGeneration，均 @NotNull 或 @NotBlank）唯一公开来源就是本端点，而此前它只给 TRAVEL 那一组 ⇒ 接送机需求在管理后台确认不动。同时修掉一个必 500 的场景：同一订单同时有两条已确认需求时，本端点每一次都抛 IllegalStateException。现改为正常返回；真出现无法判定的代际时抛新业务码 605311（HTTP 200）。行为变化（是修复不是回归）：接送机需求未定稿时，它的待派车行现在会出现在逐日计划里——那些行归它自己的需求，先前隐藏它们才是缺陷。 gateway_status=verified 的依据是真实调用不是推断：经测试网关拿到 requirementIdentities 两项后，原样用于需求级确认返 code=200、 confirmed=true、finalPlanPublished=true ⇒ 该字段不只是返回了，而是真的能驱动接送机确认走通。 Refs #7990 Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>	2026-09-20 17:59:50 +08:00

作者

SHA1

备注

提交日期

Mimingguang

72bb0ff4ad

docs(changelog): #7990/#7964 前端实证 not_required(#7990 TRAVEL 流程逐字正确,TRANSFER 取参口径入 memory;#7964 internal 不可达)

changelog-filename-gate / validate (push) Failing after 2s

详情

2026-09-20 18:02:12 +08:00

API Changelog Bot和Claude Opus 5

73e0def125

docs(changelog): #7990 车务看板订单详情按需求各返一组身份三元组，接送机确认参数有来源了

changelog-filename-gate / validate (push) Failing after 2s

详情

GET /admin/fleet/board/orders/{orderId} 新增 requirementIdentities：
每条用车需求各一项，含 kind / requirementId / requirementVersion /
requirementSha256 / dispatchPlanGeneration。
顶层原有的那一组三字段语义不变，仍指行程用车（TRAVEL），前端不改也不炸。

为什么前端必须接：POST /admin/fleet/assignments/requirements/{id}/confirm
的三个 expected 入参（version / sha256 / planGeneration，均 @NotNull 或 @NotBlank）
唯一公开来源就是本端点，而此前它只给 TRAVEL 那一组
⇒ 接送机需求在管理后台确认不动。

同时修掉一个必 500 的场景：同一订单同时有两条已确认需求时，
本端点每一次都抛 IllegalStateException。现改为正常返回；
真出现无法判定的代际时抛新业务码 605311（HTTP 200）。

行为变化（是修复不是回归）：接送机需求未定稿时，它的待派车行
现在会出现在逐日计划里——那些行归它自己的需求，先前隐藏它们才是缺陷。

gateway_status=verified 的依据是真实调用不是推断：经测试网关拿到
requirementIdentities 两项后，原样用于需求级确认返 code=200、
confirmed=true、finalPlanPublished=true ⇒ 该字段不只是返回了，
而是真的能驱动接送机确认走通。

Refs #7990

Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>

2026-09-20 17:59:50 +08:00