5.4 KiB
schema, ticket, title, consumer, change_type, author, backend_status, gateway_status, frontend_status, frontend_owner, frontend_ref, target_release, verified_at, status_note, updated_at, base
| schema | ticket | title | consumer | change_type | author | backend_status | gateway_status | frontend_status | frontend_owner | frontend_ref | target_release | verified_at | status_note | updated_at | base |
|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
| hl-changelog/v2 | 5851 | 换版即作废定稿：定制师改需求/人数/天数/出发日期后车务卡片一律回到待派车；行程 day 增删两个 admin 端点下线 | admin | 修改接口 | wx(GIT) | deployed | not_required | not_required | mmg | 2026-08-11 | PR #5856 / #5857 已合并 dev-v3 并部署测试服，26-7944（等量换版）与 26-0682（当代定稿回归）双向实测通过。前端实证 not_required(2026-08-11,mmg)——checklist 1 的 staleFinalizedPlan 卡片标记已由 #5824(aa9c087b)实现(BoardSlotSummary 挂「需求已换版 · 请核对车型与数量」warning 提示),本条仅后端放宽改判口径(去掉车数缺口前置,等量换版也改判),前端消费 assignmentProgress/assignmentStatus 的既有逻辑自动受益;checklist 2 canAssign=true 前端无按钮禁用零改动;checklist 3 下线的 /v3/admin/order/{id}/itinerary/days 端点 grep 实证前端零调用(增减天走 adjustment/submit 的 updates.itinerary.days,已存在),前端命中的 add-day/day/{editId}、product/item、hotel-requirements/assignments/days 均为不同端点不受影响。 | 2026-08-11 | dev-v3 |
车务：换版即作废定稿 + 行程 day 端点下线（#5851 / #5852 / #5853）
服务: hl-fleet-service、hl-order-service-v3 日期: 2026-08-11 无 Flyway · 无新增端点 · 无需改网关路由
背景
#5824 上线后仍有一类场景没修好：需求换版但车辆数不变（如 suv×1 → 商务车×1、或只改人数/天数/出发日期）时，车务看板仍显示「已派车」，而订单侧已是「配车·待配」。
产品口径（wx 2026-08-11）：只要定制师改需求 / 人数 / 天数 / 出发日期，车务就要重新配车流程（行程节点级编辑不算，只有增减天数才算）。
变更接口
GET /admin/fleet/board/orders —— 卡片改判口径放宽
任何用车需求换版（不再要求车辆数变多）都会让该订单卡片改判：
| 字段 | 变化 |
|---|---|
assignmentStatus / assignmentStatusLabel |
陈旧定稿卡片由 assigned/已派车 改判为 unassigned/待派车（出团在即为 unassigned_urgent） |
assignmentProgress.finalizedByFleet |
陈旧定稿时为 false |
assignmentProgress.staleFinalizedPlan |
存在按上一版需求定稿的在途行时为 true（语义不变） |
canAssign |
陈旧定稿时保持 true，改派动作仍在——不会出现「显示待派车却点不动」 |
与 #5824 相比的差异：去掉了「车辆数缺口」这个前置条件。等量换版（只改车型/人数/日期）同样改判。
终态豁免不变：canceled / completed 行携带陈旧定稿不参与判定。
statusCounts、排序权重、分页 total 同源变化，tab 计数与列表条数保持一致。
GET /admin/fleet/board/summary —— 计数随之变化
陈旧定稿卡片计入 pendingArrangeVehicle / 待派车分面，不再计入已派车。
⚠️ 端点下线（order-v3）
| 端点 | 处置 |
|---|---|
POST /v3/admin/order/{orderId}/itinerary/days |
已删除 |
DELETE /v3/admin/order/{orderId}/itinerary/days/{dayId} |
已删除 |
PUT editDay |
保留（只改叙事，不动 dayNumber/dayDate） |
改天数请走 POST /v3/admin/order/{orderId}/adjustment/submit 的 updates.itinerary.days（数组长度表达增减天）。
实测前端零调用：itinerary/days 在 hl-ui 四个远端分支（master/v1/v2/v2.1）grep 全部 0 命中，连 api 包装函数都没写过；UI 上也没有「新增/删除一天」按钮。理论零影响，但仍属 admin 端点移除，故通知。
行为变化（无接口字段变化）
需求处于 PENDING / PENDING_REVIEW 时仅修改出行人数，此前会被幂等判定吞掉（不产新版本、headcount 永久停旧值），导致车务发最终方案被 HEADCOUNT_BASELINE_MISMATCH 永久拦死。现已修复：会正常产生 PENDING_EDIT 换版（version 号不增、requirementId 换新）并通知车务。
验证证据
测试服 2026-08-11 16:33 部署（hl-fleet-service）/ 16:31（hl-order-service-v3）。
| 单 | 场景 | 卡片状态 | finalizedByFleet | staleFinalizedPlan | canAssign | tab 计数 |
|---|---|---|---|---|---|---|
| 26-7944 | 等量换版 suv×1 → 商务车×1 |
待派车 | false | true | true | 待派车 1 条 / 已派车 0 条 |
| 26-0682 | 当代定稿（回归） | 已派车 | true | false | true | 待派车 0 条 / 已派车 1 条 |
存量单靠定稿归属证据直接自愈，无需重新换版。
后端测试：fleet 受影响 5 类 664/664、FleetRedLineArchTest 13/13、spotless 通过；order-v3 253/253、*ArchTest 44/44。
已知取舍
纯人数变更且座位仍够时，订单侧 vehicle_control_status 仍可能到 DONE（与改动前一致、非回归）；车务看板侧不受影响，照常改判待派车。
前端 checklist
- 陈旧定稿卡片会从「已派车」tab 移到「待派车」tab，
staleFinalizedPlan=true建议在卡片上打「需重新核对」标记 - 该类卡片
canAssign=true，改派入口需保持可用 - 确认未使用已下线的
itinerary/days两个端点（实测为零调用）