docs(fleet): reuse canonical itinerary print flow

changelogs-v2/2026-07/23_5186_排车中订单恢复派车派人入口-修改接口-管理后台.md

@@ -103,10 +103,23 @@ generated: "2026-07-23T16:10:00+08:00"
 - `confirmHold` 根据后端 `stageCode/driverConfirmedAt` 恢复流程：等待司机回复时进入第 3 步“待确认”，已登记司机确认时进入第 4 步“确认执行”；
 - `availableActionCodes` 包含 `CHANGE_ASSIGNMENT` 时另行显示“改派”，点击进入第 2 步重新选择车辆或司机；
 - 两个按钮不得互相替代：“继续派车”推进当前有效派单，“改派”修改当前有效派单；
-- “发行程单”仍按后端动作码和派单阶段决定是否可用。
+- “打印行程单”是独立只读能力，直接复用订单详情现有打印预览，不参与派单状态流转。
 
 当前 `v2.1@6e6a11bf` 的 `resolveBoardRowActions()` 仍检查已经废弃的 `CONFIRM` 动作码，而后端生命周期实际下发 `RECORD_DRIVER_CONFIRMATION`，因此截图中“继续派车/司机已确认”按钮没有渲染。前端改为消费真实动作码即可，无需后端增加兼容别名。
 
+### 看板复用“打印行程单”
+
+看板不再维护独立的“发行程单”抽屉，也不在前端模拟发送成功。订单详情已经提供完整且权威的打印能力，看板只增加同能力入口：
+
+- 将看板按钮文案由“发行程单”改为“打印行程单”；
+- 直接复用 `src/views/order-v2/detail/modals/PrintItineraryModal.vue`；
+- 继续调用既有 `getPrintItinerary(orderId)`，即 `GET /v3/admin/order/{orderId}/print-itinerary`；
+- `orderId` 使用 `resolveBoardOrderId(order)` 的字符串结果，禁止传团号、订单号或做 `Number()` 转换；
+- 删除/停用看板自己的 `ItinerarySendSheet.vue`、消息模板和本地 `message.success('已发送行程单')` 假流程；
+- 打印内容、彩色/黑白切换、加载失败重试、权限和后端数据源与订单详情完全一致，后续只维护一套。
+
+该打印入口不改变派单状态，也不依赖订单处于待派车、待确认或已派车；是否展示只按订单打印权限和有效订单 ID 判断。
+
 ## 三、不影响范围
 
 - `canRejectRequirement` 仍只在未派阶段可能为 `true`；排车中不得重新开放“驳回用车需求”。
@@ -123,6 +136,8 @@ generated: "2026-07-23T16:10:00+08:00"
 - [ ] 技术状态值仍为 `holding`，改派、司机确认和超时判断不因文案变化而改变。
 - [ ] 待确认订单在 `RECORD_DRIVER_CONFIRMATION` 可用时显示“继续派车”，点击以 `confirmHold` 恢复第 3/4 步。
 - [ ] “继续派车”和“改派”同时存在且职责分离；前端不再检查不存在的 `CONFIRM` 动作码。
+- [ ] 看板显示“打印行程单”，打开内容与订单详情的打印预览完全一致。
+- [ ] 看板不再使用 `ItinerarySendSheet` 或模拟“已发送行程单”，Network 只调用既有打印接口。
 - [ ] 打开排车步骤时，候选请求同时携带字符串 `orderId`、`requirementId` 和当前 `fleetItemIndex`，不再出现“改派候选查询必须携带当前订单ID、用车需求ID和车型项索引”。
 - [ ] 提交时调用既有 `changeAssignment`，不调用创建派单接口。
 - [ ] `assigned`、`completed`、`canceled` 不误显示入口。