From 8dd344fec5c8a4dd4ea95333fadce675ed2f550d Mon Sep 17 00:00:00 2001 From: API Changelog Bot Date: Tue, 18 Aug 2026 11:36:20 +0800 Subject: [PATCH] =?UTF-8?q?docs(changelog):=20=E6=94=B9=E6=9C=9F=E6=8D=A2?= =?UTF-8?q?=E7=89=88=E7=BA=AF=E6=94=B9=E6=9C=9F=E6=AE=8B=E7=95=99=E5=9B=9E?= =?UTF-8?q?=E6=8B=A8=E6=88=90=E5=BE=85=E6=B4=BE=E8=BD=A6=EF=BC=88#6014=20/?= =?UTF-8?q?=20PR=20#6017=EF=BC=89?= MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit --- ...版纯改期残留回拨成待派车-修改接口-管理后台.md | 53 +++++++++++++++++++ 1 file changed, 53 insertions(+) create mode 100644 changelogs-v2/2026-08/18_6014_改期换版纯改期残留回拨成待派车-修改接口-管理后台.md diff --git a/changelogs-v2/2026-08/18_6014_改期换版纯改期残留回拨成待派车-修改接口-管理后台.md b/changelogs-v2/2026-08/18_6014_改期换版纯改期残留回拨成待派车-修改接口-管理后台.md new file mode 100644 index 0000000..77ac430 --- /dev/null +++ b/changelogs-v2/2026-08/18_6014_改期换版纯改期残留回拨成待派车-修改接口-管理后台.md @@ -0,0 +1,53 @@ +--- +schema: "hl-changelog/v2" +ticket: "6014" +title: "改期换版后纯改期残留回拨成待派车，订单/车务两侧状态对齐" +consumer: "admin" +author: "wx" +change_type: "修改接口" +backend_status: "deployed" +gateway_status: "verified" +frontend_status: "pending" +frontend_owner: "" +frontend_ref: "" +target_release: "" +verified_at: "2026-08-18" +status_note: "后端完成：PR #6017 已合并 dev-v3（6233b8554）并部署 TEST（hl-fleet-service 已重启生效）。看板卡片状态由 recordEffectiveStatus 派生，去掉了 #5912 对纯改期残留的覆写豁免；BoardOrderServiceTest 148/0 全绿 + spotless + ArchTest 门禁绿；网关实测改期单 HL20260818092151954 待派车分面 total=1（unassigned_urgent/staleFinalizedPlan=true）/已派车分面 total=0/缺口 unassignedSlots=0 不虚高。" +updated_at: "2026-08-18" +base: "dev-v3" +generated: "2026-08-18T11:35:00+08:00" +--- + +# 改期换版后纯改期残留回拨成待派车，订单/车务两侧状态对齐（#6014） + +## 背景 + +订单改出发日期后走 #5810 换版平移（只 rebind `requirement_id` + 作废定稿、不动 `service_date`），旧实派行停在旧日期、`plan_finalized_requirement_id` 指向旧版，本应按 #5851 陈旧定稿口径把看板卡片覆写成「待派车」；但 #5912 在看板卡片处引入的 `pureRescheduleResidue` 豁免让覆写失效——卡片保留「已派车」，与订单侧「待配」分叉，车务误以为已配好、不会主动重配。 + +## 变更接口 + +| 接口 | 变更 | +| --- | --- | +| `GET /admin/fleet/board/orders`（看板订单列表/各 status 分面） | **行为变更**。纯改期残留的订单卡片 `assignmentStatus` 由「已派车(assigned)」回拨为「待派车(unassigned/unassigned_urgent)」；`assignmentProgress.staleFinalizedPlan=true`、`finalizedByFleet=false` | +| `GET /admin/fleet/board/orders/{orderId}`（详情） | 同上口径 | + +无新增/删除端点，入参出参结构不变，仅卡片状态派生口径变化。 + +## 行为口径 + +- **状态回拨**：去掉看板卡片处 `recordEffectiveStatus` 的 `&& !pureRescheduleResidue` 豁免，纯改期残留（在途行全部越出当前订单窗）也按 #5851 陈旧定稿口径回拨成待派车，与订单侧「待配」对齐。 +- **缺口不虚高**：缺口进度（`buildAssignmentProgressByRequirement`）的纯改期残留分流保留——`unassignedSlots` 仍为 0，残留行**不**计入待派缺口（状态回拨 + 缺口不虚高，两者配套）。 +- **旧派车不自动清除**（铁律）：改期残留行仍在、仍带「改期残留」徽标（`rescheduleResidue`）、仍可**手动取消/改派**（`CANCEL_ASSIGNMENT`/`CHANGE_ASSIGNMENT` 动作保留），由车务手动清理，系统不自动删。 +- **605062 越窗门禁不变**：往越出当前订单窗的日期派车仍被拦截；新订单窗内日期可正常建槽派车，不死卡（`canAssign=true`）。 +- **混合场景零变化**：部分行落在新窗内（非纯改期残留）本就不享受豁免、走常规换版缺口口径，本次无行为变化。 + +## 前端动作 + +- 看板各 status 分面/tab 计数直接消费返回的 `assignmentStatus` 与 `assignmentProgress`，无需前端改逻辑——纯改期残留的订单现在会出现在「待派车」分面而非「已派车」。 +- 残留行的「改期残留」徽标与取消/改派入口照常渲染，引导车务先取消旧行再在新日期重派。 + +## 验证证据 + +- BoardOrderServiceTest **148/0 全绿**（新增 `queryOrders_pureRescheduleResidue_downgradesToUnassignedWithoutInflatedGap`，覆盖验收：卡片回拨 unassigned + staleFinalizedPlan + !finalizedByFleet、缺口 unassignedSlots=0 不虚高、canAssign+ACTION_ASSIGN 不死卡、残留行 ASSIGNED+含 CHANGE/CANCEL 动作可手动清、早筛与记录级口径一致——待派车分面有数、已派车分面空）；spotless + ArchTest 门禁绿。 +- 独立 CR（PASS-WITH-NITS，无阻断；已补 CANCEL_ASSIGNMENT 断言闭环验收）。 +- 网关实测（TEST）：改期单 `HL20260818092151954`（3 行 assigned、service_date 8-25/26/27、plan_finalized_requirement_id≠当前 requirementId）→ 待派车分面 **total=1**（`assignmentStatus=unassigned_urgent`、`staleFinalizedPlan=true`）、已派车分面 **total=0**、`unassignedSlots=0`/`assignedSlots=1`（缺口不虚高）。