chore(changelog): 前端缺陷-确认执行页车辆接续只显示第一段+不发送短信口径澄清（#5776）

changelogs-v2/2026-08/10_frontend_确认执行页车辆接续只显示第一段与不发送短信口径澄清-前端缺陷-管理后台.md

@@ -0,0 +1,65 @@
+---
+schema: "hl-changelog/v2"
+ticket: "frontend-fleet-step4-confirm-continuity-sms"
+title: "确认执行页 2 问题：①车辆接续只显示第一段车/师傅 ②「不发送短信」口径澄清（仅控制确认后行程短信）"
+consumer: "admin"
+author: "wx(GIT)"
+change_type: "前端缺陷"
+backend_status: "not_required"
+gateway_status: "not_required"
+frontend_status: "pending"
+frontend_owner: "mmg"
+frontend_ref: ""
+target_release: ""
+verified_at: ""
+status_note: "工单 #5776（TEST 实测，订单 26-6436，order_id=2086270156475936769）。问题①：Step4Confirm.vue 用单数 vehicle/driver prop（来自活动槽位 picker 选中），只显示第一段（蒙A-E2E01/道尔吉 8/23）；后端派单详情接口的 activeAssignments 已返回全部执行段（每段含 vehiclePlate/vehicleModel/vehicleSeats/driverName/driverPhone），dailyVehiclePlan 返回全部 2 车 2 司机——数据完整，纯前端展示缺陷，确认执行页应遍历全部接续段展示多段车辆+师傅。问题②：前端传值正确（8/10 09:09 最终确认落库 itinerary_sms_decision=0）、后端拦截正确（decision=0 的确认均未创建 ITINERARY_SMS 事件，全订单唯一行程短信来自 8/9 11:01 首次确认 decision=1，12:32 已发王信）；用户『仍收到短信』实为派单通知短信（FLEET_DISPATCH_CREATED，模板 SMS_510265061 与行程短信同模板，派单/改派时必发，不受 sendItinerarySms 控制，8/10 09:09:09 王信/09:22:39 道尔吉均在『不发送』确认前后收到）——建议前端在确认执行页选择「不发送短信」时提示『仅不发送确认后的行程短信，派单通知短信仍会发送』。"
+updated_at: "2026-08-10"
+base: "dev-v3"
+generated: "2026-08-10T10:20:00+08:00"
+---
+
+# 确认执行页 2 问题：车辆接续只显示第一段 + 「不发送短信」口径澄清
+
+> 前端缺陷，后端能力已具备、无需改后端。待前端修复。
+
+## 场景（车辆接续，订单 26-6436 周梦洁，order_id=2086270156475936769）
+
+一个车辆槽位在多天内由不同车辆/司机接续服务：
+- 8/23：蒙A-E2E01 道尔吉（driver_id=2065272150012444674，vehicle_id=2085284111341023234）
+- 8/24~8/25：蒙A-E2E99 王信（driver_id=2067084362829979650，vehicle_id=2085539421276286978）
+
+## 问题①：确认执行页「车·师傅」只显示第一段
+
+**现象**：「车·师傅」只显示 蒙A-E2E01/道尔吉（第一段），没显示王信（第二段）；但「行程短信」行写「全部 2 个执行段·必选」（系统知道有 2 段）。
+
+**定位（前端）**：`Step4Confirm.vue` 的 `vehicle`/`driver` 是**单数 prop**，父组件 `AssignModal.vue` 传入 `selVehicleObj`/`selDriverObj`（`useVehicleDriverPicker` 的当前活动槽位选中快照），模板只用 `vehicle?.plate`/`driver?.name` 渲染 1 组。
+
+**后端数据完整（已核实，无需后端改动）**：
+- `GET /admin/fleet/board/orders/2086270156475936769` 的 `activeAssignments`（List\<CurrentAssignmentVO\>）返回**全部有效派车组**，每组含 vehiclePlate/vehicleModel/vehicleSeats/driverName/driverPhone（BoardOrderDetailVO 字段已核实）；
+- `dailyVehiclePlan` 正确返回全部 2 车 2 司机（8/23 蒙A-E2E01/道尔吉 + 8/24-25 蒙A-E2E99/王信）。
+
+**期望**：确认执行页遍历全部执行段（`confirmationAssignments`/`activeAssignments`）展示多段「车辆+师傅」，车务能核对完整执行信息。
+
+## 问题②：选「不发送短信」确认后司机仍收到短信——口径澄清
+
+**定位（前后端逻辑均正确，非缺陷，建议前端补提示文案）**：
+
+| 事实 | 证据 |
+|------|------|
+| 前端确认时实传 sendItinerarySms | 8/10 09:09 最终确认（王信 8/24-25 转 assigned）落库 `fleet_assignment.itinerary_sms_decision=0`；8/9 15:10 起历次确认均为 0 —— 前端传值正确 |
+| 后端拦截正确 | decision=0 的确认均未创建 ITINERARY_SMS outbox 事件；全订单仅 1 条 ITINERARY_SMS 事件（event_id=2086286779542855682，8/9 11:01:44 创建、12:43 处理成功）对应 8/9 11:01 首次确认（decision=1，当时选择了发送短信） |
+| 用户「仍收到短信」的真实来源 | ① 派单通知短信 `FLEET_DISPATCH_CREATED`（模板 SMS_510265061，**与行程短信同模板**）：由派单/改派 HOLD_NOTIFICATION 触发，派单时必发，不受 sendItinerarySms 控制——8/10 09:09:09 王信、09:22:39 道尔吉均在「不发送短信」确认（09:09:27）前后收到；② 8/9 11:01 首次确认（选择了发送短信）已发出的行程短信（12:32 发送），后取消改派无法撤回 |
+
+**结论**：「不发送短信」只控制**确认后创建的行程短信事件**（FLEET_ITINERARY_READY），**不控制派单通知短信**（FLEET_DISPATCH_CREATED，派单时必发）。验收项「选不发送短信确认后不创建/不发送行程短信事件」在现行代码与 DB 事实下已成立。
+
+**建议前端**：确认执行页选择「不发送短信」时提示「仅不发送确认后的行程短信，派单通知短信仍会发送」，避免车务误解。
+
+## 变更接口
+
+- 无后端接口变化。
+
+## 验证证据
+
+- DB 实证（TEST hl_fleet_service）：`fleet_assignment` 全史 16 行，itinerary_sms_decision 仅首次确认=1，其余全部=0；`fleet_assignment_insurance_outbox` 全史仅 1 条 ITINERARY_SMS（首次确认创建，SUCCESS）。
+- DB 实证（TEST hl_user_service）：`notification_send_log` 仅 1 条 FLEET_ITINERARY_READY（8/9 12:32 发王信 185\*\*\*\*2756，status=0）；8/10 09:09/09:22 两条为 FLEET_DISPATCH_CREATED（派单短信）。
+- 源码核实：`AssignmentService.confirmRequirement`/`confirm` 均 `if (sendItinerarySms)` 才 `writeItinerarySms`；`BoardOrderDetailVO.activeAssignments` 返回全部执行段。