---
schema: "hl-changelog/v2"
ticket: "5681"
title: "多槽位确认执行页逐日车费覆盖全程+HOLD 整组确认快照代际修复"
consumer: "admin"
change_type: "修改接口"
author: "wx(GIT)"
backend_status: "deployed"
gateway_status: "verified"
frontend_status: "not_required"
frontend_owner: ""
frontend_ref: ""
target_release: ""
verified_at: ""
status_note: "后端完成：PR #5690 已合并 dev-v3 并部署 TEST（12:52 滚动 DONE）。网关双探针 ALL PASS：自建 2 车需求订单 HOLD 派车→行级冻结代际→详情整组快照代际非空→两组逐日车费各覆盖全部出行日→司机确认→需求级整组确认 200 confirmed=true。前端无需配合（字段与守卫均沿用既有契约，此前是后端数据缺失）。"
updated_at: "2026-08-08"
base: "dev-v3"
generated: "2026-08-08T13:00:00+08:00"
---

# 多槽位确认执行页逐日车费覆盖全程+HOLD 整组确认快照代际修复

> **服务**: hl-fleet-service
> **PR**: [#5690](https://git.1814.love:8443/wx/HL/pulls/5690)
> **Issue**: [#5681](https://git.1814.love:8443/wx/HL/issues/5681)
> **日期**: 2026-08-08
> **影响**: 🟢 **缺陷修复**，无契约结构变更（既有字段数据口径修复）。前端无需改代码。

## 背景

#5681（P1）wx 实测：订单 26-0703（4 人 2 车 2 司机，8/11-8/14）确认执行页：
1. 逐日车费只显示 1 车 1 天（8/11）——应列出每个车每个出行日车费；
2. 报「详情缺少整组确认快照，请刷新后重试」——多槽位无法确认执行。

**根因（双缺陷）**：
- 全程单行（service_date NULL）派车组聚合视图的 `dailyVehicleFees`/`chargeableServiceDates`/`freeServiceDates` 由物理行 1:1 生成，`serviceDateOf` 对全程行只取 startDate，逐日车费只产出 1 天；
- #5400 重构时 dailyPlan 模式 HOLD 创建只退休旧代际标记、不再冻结新方案代际（items 模式两种模式都会冻结），导致 HOLD 单 `dispatchPlanGeneration` 恒为 NULL，需求级整组确认的代际栅栏与前端整组快照守卫永远拿不到代际。

## 修复内容（内部，无接口/字段结构变化）

- `completeDailyPlanCreation`：HOLD 逐日方案创建同样冻结方案代际（finalized=1 + generation，与 items 模式一致）；DAILY_V3 最终快照事件仍只在 DIRECT 创建时发布，HOLD 待最终确认后发布（#5400 意图不变）。
- `aggregateGroupRows`：全程行聚合视图逐日费用/收费日/免费日按 startDate..endDate 逐日展开。
- 兼容：#5675 行程短链哨兵路径只服务存量无代际 HOLD 行，有代际行走真实代际校验，双向兼容；单车/逐日切片行为不变（回归测试钉住）。

## 变更接口

| 方法 | 路径 | 变更 |
|---|---|---|
| GET | /admin/fleet/board/orders/:orderId | activeAssignments[].dailyVehicleFees 全程行覆盖全部出行日；driverConfirmationSummary.dispatchPlanGeneration 对 HOLD 单正常返回 |
| POST | /admin/fleet/assignments/requirements/:requirementId/confirm | 多槽位 HOLD 整组确认可正常携带代际提交（修复前永远拿不到代际） |

## 验证证据

- 全量 `mvn -pl hl-fleet-service -am verify`：3283 Tests 0 失败；新增 4 回归（HOLD 冻结代际不发快照事件/DIRECT 对照发事件/全程行逐日车费展开 4 天/逐日切片不变）；spotless 通过。ReleaseEMixedBinaryHarnessTest（进程时序）与两个 Testcontainers 类（3306 端口并行争用）全量内环境性失败，单独重跑 23/23、2/2、10/10 全绿，与本改动无关。
- 部署 TEST：12:52 滚动 DONE。
- 网关端到端（自建 2 车需求订单 2085938395749515266，蒙C01E01+孟和/蒙A-S6666+苏和巴特，8/22-8/24）：HOLD 派车 → 行级 finalized=1+代际一致 → 详情整组快照代际非空 → 两组逐日车费各 3 天 → 两组司机确认 → 需求级整组确认 **200 confirmed=true** → DB 双行 assigned。单车对照（26-6179）逐日车费 3 天正常。

## 前端配合

无需配合。确认执行页的槽位切换、整组快照守卫（requirementId/version/sha/代际/groups）均为既有契约，此前是后端数据缺失导致守卫不通过；修复后原链路自然恢复。

## 前端实证确认（2026-08-08 mmg，hl-admin）

逐行核实确认 not_required 属实，零代码改动：整组快照守卫在 `src/views/fleet/board/composables/useAssignFlow.js:166-169` 与 `:518-531`，前端直读 `driverConfirmationSummary.dispatchPlanGeneration`、空则抛「详情缺少整组确认快照，请刷新后重试」——正是本单后端修复的守卫，前端是正确消费方，此前因 HOLD 单代际恒 NULL 不通过，后端补冻结代际后原链路自然恢复；逐日车费前端仅逐日渲染 `activeAssignments[].dailyVehicleFees`，后端全程行按 startDate..endDate 展开后自动正确。前端无任何针对该缺陷的特判或 workaround 需拆除。