hl-api-changelog

3,249 提交 29 分支 0 Git 标签

3 次代码提交

包含重命名

作者	SHA1	备注	提交日期
Mimingguang	ac12dabe20	docs(changelog): #7443 C 车务侧+13_7439/18_7443/20_7990 前端已交付 verified(hl-admin v2.1 662310ea/6c091ef24) changelog-filename-gate / validate (push) Failing after 2s 详情 18_7443 挂起期回头补落地(派车弹窗 kind 切换+batch/pickup-dropoff-config 显式 kind); 20_7990 requirementIdentities 已消费;13_7439 硬契约点 A+B 已补(809008/显式 kind/reject 走 query); 20_7443 AC-24 维持 not_required 仅补 C 段实证	2026-09-21 17:52:22 +08:00
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

ac12dabe20

docs(changelog): #7443 C 车务侧+13_7439/18_7443/20_7990 前端已交付 verified(hl-admin v2.1 662310ea/6c091ef24)

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

详情

18_7443 挂起期回头补落地(派车弹窗 kind 切换+batch/pickup-dropoff-config 显式 kind);
20_7990 requirementIdentities 已消费;13_7439 硬契约点 A+B 已补(809008/显式 kind/reject 走 query);
20_7443 AC-24 维持 not_required 仅补 C 段实证

2026-09-21 17:52:22 +08:00

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