changelog(#5822 #5830): 车务槽位删除放开+逐日计划恒空修复 / 房务订单详情 Tab

changelogs-v2/2026-08/11_5822_车辆槽位无条件可删除与逐日计划恒空修复-修改接口-管理后台.md

@@ -0,0 +1,90 @@
+---
+schema: "hl-changelog/v2"
+ticket: "5822"
+title: "车辆槽位无条件可删除（删除即释放车/司机）+ 行程结束后端拦截 605047 + 逐日计划恒空两处修复"
+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: ""
+updated_at: "2026-08-11"
+base: "dev-v3"
+---
+
+# 车务派单：槽位删除放开 + 逐日计划恒空修复（#5822 / #5821 / #5829 / #5831）
+
+> **服务**: hl-fleet-service
+> **PR**: #5825（#5822+#5821）、#5834（#5829+#5831）—— 均已合并 dev-v3 并部署测试服
+> **日期**: 2026-08-11
+> **含 Flyway**: `20260811.001`（删除意图表唯一键改按稳定槽位 ID）
+
+---
+
+## 变更接口
+
+### 1. `DELETE /admin/fleet/assignments/slots/{slotId}` —— 删除门禁全部撤销
+
+**旧行为**：以下三种情况拒绝删除
+- `605007` 槽位已完成派车或已最终确认（含 completed 行、已最终确认的取消行）
+- `605027` 行程已出发
+
+**新行为**：**任意派车状态均可删除**（已派车 / 待确认 / 已完成 / 已最终确认后取消 / 行程已出发，全部放行）。删除时：
+- 仍占用车辆/司机的行（holding/assigned）联动取消 → **车辆与司机的档期占用被释放，回到空闲可再次被候选查询选中**
+- `canceled` / `completed` 历史行保留不物理删（对账、保险退款关联不丢）
+
+**唯一保留的门禁**：`605047` 行程已结束，派车信息只读，不能修改或改派。
+
+| 错误码 | 状态 |
+|---|---|
+| `605007` | **已下线**，不再由本接口返回（常量已删除） |
+| `605027` | 本接口不再返回（该码在「整组取消派单」路径仍在用，定义保留） |
+| `605047` | **新增于本接口**：行程已结束（今天 **严格大于** 服务结束日）时拒绝；**结束日当天仍可删除** |
+
+**前端要做**：删除按钮的禁用条件只剩「行程已结束」一种；原本针对 605007/605027 的错误提示分支可以删掉，改为透传 605047 的 message。
+
+### 2. `GET /admin/fleet/board/orders/{orderId}` —— `vehicleSlots` 三项变化
+
+| 字段 | 变化 |
+|---|---|
+| `canDelete` | 不再受派车状态影响（已派车/已确认/已完成一律 `true`）；**唯一为 `false` 的情况是行程已结束/已关账**，与接口 605047 同口径 |
+| `deleteBlockReason` | `canDelete=true` 时恒 `null`；为 `false` 时是只读原因文案（如「行程已结束」） |
+| 槽位列表本身 | **已被删除的槽位不再返回**。此前因看板由现存派车行聚合、而历史行永不物理删，删除后槽位仍会显示；现已按删除意图过滤 |
+
+**前端要做**：不要再依赖「`canDelete=false` 就是因为已派车」的旧假设；直接用 `deleteBlockReason` 展示原因即可。
+
+### 3. `dailyVehiclePlan` / `actualVehicleCount` / `vehicleFeeSummaries` 恒空修复
+
+**这是无契约变化的纯 bug 修复，但前端表现差异很大**，两个场景此前会让整单逐日计划、实派车数、车费汇总全部为空：
+
+- **场景 A（#5821）**：方案最终确认过后，那笔派单又被取消 —— 已取消的行仍占住「当前方案」锚点，把活跃行全挡在门外
+- **场景 B（#5831）**：车务点「添加车辆槽位」后方案重新解冻 —— 此时一条已确认的行都没有，代码却仍按「历史代际」逻辑只保留已完成行程的行
+
+场景 B 影响面尤其大：**任何点过「添加车辆槽位」的订单都会立刻中招**，车务看不到逐日计划就无法核对、更无法提交最终方案。
+
+修复后两种场景均正常返回。实测订单 `2086637109266862081`：修复前 `dailyVehiclePlan=[]`、`actualVehicleCount=0`，修复后 **12 条（2 车 × 6 天）、实派 2、车费汇总 2 条**。
+
+**前端要做**：无需改动，接口数据恢复后原有渲染即正常。若前端曾为规避空数据加过兜底/隐藏逻辑，可以撤掉。
+
+---
+
+## 验证证据
+
+2026-08-11 测试服（网关 `https://api.test.1814.love:9443`，车务管理员 token）实测：
+
+| 用例 | 结果 |
+|---|---|
+| 原报 605007 的槽位删除 | `code=200` ✅ |
+| 删除后槽位从详情消失 | ✅（非仅接口成功） |
+| **删除即释放占用** | 蒙A-E2E01 `available=false, 冲突1条` → `available=true, 冲突0条`，联动取消 1 行 ✅ |
+| 已派车槽位 `canDelete` | 全部 `true` ✅ |
+| 行程已结束（2026-07-29）订单删槽位 | `605047 行程已结束，派车信息只读，不能修改或改派` ✅ |
+| 订单 2086637109266862081 逐日计划 | 12 条 / 实派 2 / 车费汇总 2 条 ✅ |
+| 4 个含「已确认+已取消」行的订单 | `dailyVehiclePlan` 均非空 ✅ |
+
+Flyway `20260811.001` 已落库（`success=1`，唯一键已改为 `(requirement_id, assignment_slot_id)`）。单测：fleet 全量 3390 / Failures 0（Errors 均为 Testcontainers 等环境依赖类）；#5831 与 #5822 核心修复均通过**变异验证**（退回旧逻辑后对应用例失败）。

changelogs-v2/2026-08/11_5830_房务订单详情新增订单详情Tab-修改接口-管理后台.md

@@ -0,0 +1,95 @@
+---
+schema: "hl-changelog/v2"
+ticket: "5830"
+title: "房务订单详情新增「订单详情」Tab：景点行程 tripItinerary + 出行人 travelers + 大交通 transport"
+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: ""
+updated_at: "2026-08-11"
+base: "dev-v3"
+---
+
+# 房务订单详情新增「订单详情」Tab（#5830）
+
+> **服务**: hl-order-service-v3
+> **PR**: #5832（已合并 dev-v3 并部署测试服）
+> **日期**: 2026-08-11
+> **背景**: 房务订单详情此前只有 3 个 Tab（配房行程 / 定制师需求 / 操作日志），房务看不到出行人与大交通，行程也只有住宿视角。wx 要求对齐车务派单弹窗 Step1「订单详情」的三块内容。
+
+---
+
+## 变更接口
+
+`GET /admin/house/orders/{orderId}` —— **根级新增 4 个字段**：
+
+| 字段 | 类型 | 可空 | 说明 |
+|---|---|---|---|
+| `tripItinerary` | `List<ItineraryDayForFleetDTO>` | 否（降级时空数组） | **景点/餐食每日安排**（与车务 Step1 同源） |
+| `travelers` | `List<OrderTravelerForFleetDTO>` | 否（降级时空数组） | 出行人，**脱敏版**（`nameMasked` 掩码、无证件/生日明文） |
+| `transport` | `OrderTransportForFleetDTO` | 是 | 大交通（往返方向 / 交通方式 / 时间 / 路线 / 班次 / 关联出行人） |
+| `orderDetailReady` | `Boolean` | 否 | 三块是否取数成功，见下方说明 |
+
+### 🔴 不要和 `itinerary` 搞混
+
+`itinerary` 字段**依旧是「配房行程」Tab 的住宿视角数据**（`ItineraryDay`：`stayDate` / `cityCode` / `arrange` 配房状态…），本次**一字未动**。新的景点行程叫 **`tripItinerary`**，两者结构完全不同，不要互换或复用。
+
+### `tabCounts` 新增 key
+
+```json
+{
+  "itineraryCount": 2,        // 配房行程 Tab（不变）
+  "messageCount": 1,          // 留言（不变）
+  "unreadMessageCount": 0,    // 留言未读红点（不变）
+  "operationLogCount": 4,     // 操作日志（不变）
+  "tripItineraryCount": 3     // 【新增】订单详情 Tab 徽标 = 景点行程天数
+}
+```
+
+### `orderDetailReady` 怎么用
+
+三块数据是**软依赖**：订单核心侧取数异常时各自降级为空集合/null，房务详情接口**不会 500**（房务主职责是配房，不该被订单核心故障拖垮）。
+
+但降级后的空数据与「客人确实没录出行人/没填大交通」**长得一模一样**。`orderDetailReady` 用来区分：
+
+- `true` = 取数成功。此时字段为空就是**真的没有**，正常显示「暂无出行人 / 暂无大交通」
+- `false` = 取数失败。前端应提示「订单信息加载失败，请稍后刷新」，**不要**显示成「该订单没有出行人」
+
+实测印证：某订单 `transport` 各字段全 null（客人确实没录大交通），但 `orderDetailReady=true`，属于第一种情况。
+
+---
+
+## 前端要做
+
+新增第 4 个 Tab「订单详情」，渲染三块，样式对齐车务派单弹窗 Step1：
+
+1. **出行人信息**表：姓名（已脱敏）/ 所属地 / 人员类型 / 性别 / 年龄 / 国籍民族 / 关联班次
+2. **大交通**表：方向（抵达接团 / 返程送站）/ 交通方式 / 时间 / 路线 / 班次 / 出行人
+3. **每日安排**（`tripItinerary`）：按天展示景点、餐食等行程明细
+
+Tab 徽标用 `tabCounts.tripItineraryCount`。只读入口下同样只展示、无操作。
+
+---
+
+## 验证证据
+
+2026-08-11 测试服（网关 9443）实测真实房务订单：
+
+```
+tripItinerary = 3 天
+travelers     = 1 人（nameMasked = "娜***"，脱敏正确）
+transport     = 返回对象（该单客人未录大交通，各字段 null）
+orderDetailReady = true
+itinerary（配房行程）= 2 天  ← 无回归
+tabCounts = {"itineraryCount":2, "messageCount":1, "unreadMessageCount":0,
+             "operationLogCount":4, "tripItineraryCount":3}
+```
+
+单测：`hl-order-service-v3` 全量 **6374 / Failures 0**（3 个 Errors 为 surefire 单 JVM 后期 OOM 的环境性问题，单独重跑绿）；`HouseDetailAggregatorTest` 80/80；专守循环依赖的 `OrderServiceCircularDependencyContextIT` 绿；ArchTest 绿。