docs(changelog): #8430 更正 dispatchReadOnly 判据描述——逐日方案全部只读也会整单只读，纯接送机订单改后同样适用

Co-Authored-By: Claude Opus 5.5 (1M context) <noreply@anthropic.com>
2026-09-27 22:14:08 +08:00
@@ -12,7 +12,7 @@ frontend_owner: ""
 frontend_ref: ""
 target_release: ""
 verified_at: ""
-status_note: "PR #8452 已合入 dev-v3（squash 0bae84b59）。TEST 环境 hl-fleet-service 0bae84b59 于 2026-09-27 20:29:52 部署、21:12 复核未变，hl-gateway 71def6dc5；同一张纯接送机订单在部署前（fleet 267ab6906）与部署后各取一次详情做对照，结论见第八节。只改看板详情一个接口，看板列表未改；TRAVEL 与 TRANSFER 并存的订单行为不变。"
+status_note: "PR #8452 已合入 dev-v3（squash 0bae84b59）。TEST 环境 hl-fleet-service 0bae84b59 于 2026-09-27 20:29:52 部署、21:12 与 21:24 两次复核未变，hl-gateway 71def6dc5；同一张纯接送机订单在部署前（fleet 267ab6906）与部署后各取一次详情做对照，结论见第八节。只改看板详情一个接口，看板列表未改；TRAVEL 与 TRANSFER 并存的订单行为不变。"
 updated_at: "2026-09-27"
 base: "dev-v3"
 ---
@@ -87,6 +87,8 @@ base: "dev-v3"
 | suggestedVehicleCount | Integer | **改后**按 TRANSFER 需求计算；改前恒为 0 |
 | actualVehicleCount | Integer | **改后**按 TRANSFER 需求的派车行计算；改前恒为 0 |
 | progressSteps | List | **改后**按 TRANSFER 需求的派车行推进；改前停在第 1 步 |
+| dispatchReadOnly | Boolean | 判据没变：行程已结束，或逐日方案**每一行**都已完结、服务日已过或已关账，满足其一即为 true。**改后**纯接送机订单的逐日方案有了行，第二条也会对它生效；改前它只在行程已结束时为 true |
+| dispatchReadOnlyReason | String | 行程已结束时为「行程已结束」；逐日方案全部只读时为「全部服务日期已过去、完结或关账」；不只读时为 null |

 #### 请求示例

@@ -190,7 +192,7 @@ Authorization: Bearer <车务账号 token>
 - 只改看板**详情**；看板**列表**未改。同一张纯接送机订单在列表与详情里的派车状态、车辆、需求身份已实测一致；列表的 `currentStep` 按 3 步编号、详情的 `progressSteps` 按 4 步编号，两者本来就不同源，不是本单引入的差异。
 - TRAVEL 与 TRANSFER 并存的订单：有效需求就是 TRAVEL，每个字段的取值与改前逐字相同。
 - 打开详情不会改变 TRANSFER 需求的状态（只有 TRAVEL 需求会在打开详情时被置为处理中，这一点没变）。
- `dispatchReadOnly` 的判据没变：仍是「行程已结束」（订单返回日早于今天）才为 true；单行是否只读看 `dailyVehiclePlan[].readOnly`。
+- `dispatchReadOnly` 的判据没变（行程已结束，或逐日方案每一行都已完结、服务日已过或已关账），但纯接送机订单现在有了逐日方案行，所以「全部完结」的纯接送机订单行程未结束也会整单只读，原因「全部服务日期已过去、完结或关账」。单行是否只读看 `dailyVehiclePlan[].readOnly`。
 - 纯接送机订单调需求级确认接口时，`expectedRequirementVersion` / `expectedRequirementSha256` / `expectedPlanGeneration` 取 `requirementIdentities` 中 `kind=TRANSFER` 那一条；`dispatchPlanGeneration` 为 null 时说明该需求还没有唯一的已定稿方案，此时不能按「已定稿方案」确认。

 ---
@@ -229,7 +231,12 @@ const expected = transfer && {

 ### 只读判据

-`dispatchReadOnly` 仍按「行程已结束」判定，与派车行是否全部完结无关；单行只读看 `dailyVehiclePlan[].readOnly`，已完结行为 `true`、原因「派单已完结」。
+`dispatchReadOnly` 的判据没变，有两条，满足其一即为 true：
+
+1. 行程已结束（订单返回日早于今天），原因「行程已结束」；
+2. 逐日方案每一行都已完结、服务日已过或服务日已关账，原因「全部服务日期已过去、完结或关账」。
+
+改前纯接送机订单的逐日方案恒为空，第 2 条对它永不成立；改后它有了逐日方案行，TRANSFER 的派车行全部完结时，即使行程还没结束，整单也会只读。实测订单还有三行在途，所以为 `false`。单行只读看 `dailyVehiclePlan[].readOnly`，已完结行为 `true`、原因「派单已完结」。

 ## 六.6、修改前后对比

@@ -256,7 +263,7 @@ const expected = transfer && {
 | 维度 | 评估 |
 |---|---|
 | 接口结构 | 无变化，不新增、不删除字段 |
-| 纯接送机订单 | 详情字段从空值 / 0 / 订单日期兜底变为按 TRANSFER 需求取值；可能新出现 605311 |
+| 纯接送机订单 | 详情字段从空值 / 0 / 订单日期兜底变为按 TRANSFER 需求取值；可能新出现 605311；派车行全部完结时 `dispatchReadOnly` 会变为 true |
 | TRAVEL 订单、TRAVEL 与 TRANSFER 并存订单 | 无变化 |
 | 看板列表 | 无变化 |
 | 数据库 | 无 DDL、无写入 |
@@ -271,11 +278,11 @@ const expected = transfer && {

 ## 八、测试环境已验证

-**环境**：TEST，hl-fleet-service `0bae84b59`（2026-09-27 20:29:52 部署，21:12 复核未变），hl-gateway `71def6dc5`，测试专用车务账号。
+**环境**：TEST，hl-fleet-service `0bae84b59`（2026-09-27 20:29:52 部署，21:12 与 21:24 两次复核未变），hl-gateway `71def6dc5`，测试专用车务账号。

 1. **同一订单改前改后对照**（第六节）：部署前在 fleet `267ab6906` 上取详情，接机要求日为订单出发日、逐日方案 0 行、车数 0/0；部署后同一订单接机要求日为 TRANSFER 服务日、逐日方案 7 行、车数 1/3，`requirementIdentities[TRANSFER]` 带方案代际。
 2. **接送机配置写口与详情门禁一致**：另建一张只有送机方向的纯接送机订单，接送机配置接口响应里的门禁与随后看板详情返回的门禁逐字段相同（`arrivalRequiredDates=[]`、`departureRequiredDates=["2027-10-19"]`、`satisfied=true`）；只有送机方向时接机要求日为空，不会拿订单出发日硬凑。
-3. **拿详情里的身份做需求级确认**：用同一订单详情里 `requirementIdentities[TRANSFER]` 的需求 ID、版本、指纹、代际调 `POST /admin/fleet/assignments/requirements/{requirementId}/confirm` 成功（`confirmed=true`），确认后再取详情，`progressSteps` 四步均为已完成。
+3. **拿详情里的身份做需求级确认**：用同一订单详情里 `requirementIdentities[TRANSFER]` 的需求 ID、版本、指纹、代际调 `POST /admin/fleet/assignments/requirements/{requirementId}/confirm` 成功（`confirmed=true`、`finalPlanPublished=true`），服务端接受了详情给出的四个值。
 4. **列表与详情一致**：同一订单在看板列表（`GET /admin/fleet/board/orders`）中的派车状态、车辆、需求身份与详情一致。
 5. **单测**：看板详情新增 7 条纯接送机订单用例（含全部已完结、旧版在途行、平移重绑行、同一需求多代 605311、不置处理中、顶层身份为 null），合并后在 dev-v3 上复跑 234/0 通过。