changelog(#5851 #5852 #5853): 换版即作废定稿 + 行程 day 端点下线——测试服实测通过（PR #5856 #5857）

changelogs-v2/2026-08/11_5851_换版即作废定稿与需求基线同步-修改接口-管理后台.md

@@ -0,0 +1,102 @@
+---
+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: "pending"
+frontend_owner: "mmg"
+frontend_ref: ""
+target_release: ""
+verified_at: "2026-08-11"
+status_note: "PR #5856 / #5857 已合并 dev-v3 并部署测试服，26-7944（等量换版）与 26-0682（当代定稿回归）双向实测通过。"
+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` 两个端点（实测为零调用）