docs(changelog): #8578 接送机派车行按航班日自动置接送标志（修复，契约不变）

Co-Authored-By: Claude Opus 5.5 (1M context) <noreply@anthropic.com>
2026-10-03 10:41:51 +08:00
@@ -0,0 +1,92 @@
+---
+schema: "hl-changelog/v2"
+ticket: "8578"
+title: "接送机用车需求派车时按航班日自动置接送标志，主路径派齐后最终方案可发布；接口契约不变"
+consumer: "admin"
+author: "wx(GIT)"
+change_type: "修复"
+backend_status: "deployed"
+gateway_status: "verified"
+frontend_status: "not_required"
+frontend_owner: ""
+frontend_ref: ""
+target_release: ""
+verified_at: ""
+status_note: "接口路径、入参、出参、错误码均不变；变化的是接送机（TRANSFER）用车需求经派车接口建派单行时，接机日、送机日的派单行由后端自动标为接机车、送机车，主路径派齐后接送机门禁可以满足、最终方案可以发布。"
+updated_at: "2026-10-03"
+base: "dev-v3"
+---
+
+# 车务派车：接送机派车行按航班日自动置接送标志
+
+> **服务**: hl-fleet-service
+> **关联 Issue**: #8578
+> **关联 PR**: #8595（合并提交 0f19f383fa）
+> **部署状态**: 测试环境已部署并经网关实测，见「五、实测验证」
+> **影响范围**: 管理后台车务派车（单派 `POST /admin/fleet/assignments`、批派 `POST /admin/fleet/assignments/batch`）之后的接送机门禁与最终方案发布结果——不改任何请求或响应字段
+
+---
+
+## ⚠️ 关键变化
+
+- **以前**：派车接口建派单行时，接送标志（接机车 / 送机车）一律写 0。接送机订单只走「派车 → 确认」主路径时，接送机门禁结构性无法满足，批派响应恒为 `finalPlanPublished=false`、`finalPlanNotPublishedReason=GATE_UNSATISFIED`，只能再去第③步「接送机配置」手工勾选才放行。
+- **现在**：接送机（TRANSFER）用车需求的派单行，服务日是大交通声明的接机日则自动标为接机车，是送机日则自动标为送机车。接机日、送机日都派了车，门禁即满足，最终方案在派车这一步就能发布。
+- **前端无需改代码**：请求体、响应结构、错误码都没变。
+
+---
+
+## 一、背景
+
+接送机门禁要求大交通声明的每个接机日都有接机车、每个送机日都有送机车。门禁读的是派单行上的接送标志，而派车接口建行时从不置这两个标志，所以门禁在主路径上永远不满足，最终方案永远不发布。
+
+---
+
+## 二、后端改动
+
+- 建派单行的入口 `AssignmentService#doCreateInLock` 在逐日建行时，按该行服务日置接送标志。单派与批派都经过这个入口。
+- 接机日、送机日两个日期集直接取自门禁判定用的 `PickupDropoffGateResolver`，建行口径与门禁口径同源，不会出现「建行认为是接机车、门禁不认」的分叉。
+- 只对 TRANSFER 用车需求自动置位。TRAVEL（旅游）用车需求的某个行程日不一定是航班日，系统不做推断，派单行仍写 0，与改前一致。
+
+---
+
+## 三、对前端的影响
+
+### 可观察到的行为变化
+
+- 接送机订单在派车向导里把接机日、送机日都派上车后，批派响应 `finalPlanPublished=true`，`pickupDropoffGate.satisfied=true`，不需要再进第③步手工勾选。
+- 只派了接机日、没派送机日时，门禁按设计仍不满足：`finalPlanPublished=false`、`finalPlanNotPublishedReason=GATE_UNSATISFIED`，缺的日期列在 `pickupDropoffGate.missingDropoffDates`（或 `missingPickupDates`）里。补派缺的那一天即可。
+- 订单「确认核对清单」的用车项（`VEHICLE_DONE`）随门禁满足变为通过。
+
+### 字段口径（均未变化）
+
+批派响应的 `finalPlanPublished`、`finalPlanNotPublishedReason`、`pickupDropoffGate`（`arrivalRequiredDates`、`departureRequiredDates`、`missingPickupDates`、`missingDropoffDates`、`declared`、`satisfied`）都是既有字段，含义不变。
+
+---
+
+## 四、覆盖范围与边界
+
+- **只影响修复部署后新建的派单行**。已经存在的派单行，接送标志保持原值。需要改的，仍在第③步用 `PUT /admin/fleet/assignments/pickup-dropoff-config` 调整。该接口行为不变：在门禁已满足的订单上按相同取值再提交一次，返回成功，`finalPlanPublished=true`，`requirementReopened=false`。
+- **TRAVEL 订单零变化**：无接送机声明时 `pickupDropoffGate.declared=false`、`satisfied=true`，最终方案照常发布。
+- **派车弹窗两种进入方式提交的日期范围不同**：按日格进入只提交该日，按车辆槽位统一选择提交整段日期（hl-ui `v2.1` 分支 `AssignModal.vue`）。只按日格派了接机日时，门禁显示缺送机日属于正常结果，不是前端提交形状的缺陷。
+
+---
+
+## 五、实测验证（测试环境）
+
+2026-10-03，测试服 hl-fleet-service 部署提交 `89c87fd21`（已包含修复提交 `0f19f383fa`），经网关实测：
+
+| 场景 | 结果 |
+|------|------|
+| 接送机订单（接机日 2027-05-10、送机日 2027-05-15），只走「派车 → 确认」主路径，不调接送机配置 | 批派响应 `finalPlanPublished=true`，`pickupDropoffGate.satisfied=true`，`missingPickupDates`、`missingDropoffDates` 均为空 |
+| 同一订单 `GET /v3/admin/order/{orderId}/confirm-checklist` | `VEHICLE_DONE` 为 `passed=true` |
+| 阴性对照：只派接机日（2027-06-10），没派送机日（2027-06-16） | `finalPlanPublished=false`，`finalPlanNotPublishedReason=GATE_UNSATISFIED`，`missingDropoffDates=["2027-06-16"]` |
+| 门禁已满足后，按相同取值再调 `PUT /admin/fleet/assignments/pickup-dropoff-config` | `finalPlanPublished=true`，`requirementReopened=false` |
+| TRAVEL 订单同批次对照 | `pickupDropoffGate.declared=false`、`satisfied=true`，`finalPlanPublished=true` |
+
+---
+
+## 关联
+
+- Issue: [wx/HL#8578](https://git.1814.love/wx/HL/issues/8578)
+- PR: [wx/HL#8595](https://git.1814.love/wx/HL/pulls/8595)
+- 后端：@wx