---
schema: "hl-changelog/v2"
ticket: "5851"
title: "换版即作废定稿：定制师改需求/人数/天数/出发日期后车务卡片一律回到待派车；行程 day 增删两个 admin 端点下线"
consumer: "admin"
change_type: "修改接口"
author: "wx(GIT)"
backend_status: "deployed"
gateway_status: "not_required"
frontend_status: "not_required"
frontend_owner: "mmg"
frontend_ref: ""
target_release: ""
verified_at: "2026-08-11"
status_note: "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 均为不同端点不受影响。"
updated_at: "2026-08-11"
base: "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` 两个端点（实测为零调用）