docs(changelog): 订正 #8576/#8601/#8577 三份交接件的编造内容与 frontend_status

三份都是既有条目（#8576/#8601 由 da562f3 批次产出，#8577 单独产出），本次逐条对源码与
测试服实测记录核对后订正，不新增条目。

#8576
- frontend_status 由 not_required 改回 pending（ca26be4 批量置位）。依据：hl-ui
  origin/v2.1 确有 src/api/fleet/group-dispatch.js 消费 reconfigure / confirm 两个端点，
  而全仓 specWarnings 命中数为 0 —— 新字段目前无人渲染，车辆规格提醒对车务不可见。
  改判原因已按 FRONTEND_CONSUMPTION_STATUS_GUIDE 要求写进 status_note。
- 两处错误响应示例的 message 是编造的，换成 GroupDispatchAdminErrorCode 的真实模板。
- planVersion 出参类型 Integer/Long 统一为 Long（两张表）。

#8601
- 删掉四处「589535 适用于本端点」的错误断言。实证：RequirementService.java:4749 对
  resourceType=VEHICLE 硬编码 hasActiveAssignments=false，该码在车需求打回上结构性不可达。
- 编造的订单 ID 2099459272533323777 换成实测的 2105173274755534850（dispatch）与
  2105173313083080706（reject）。
- 错误码集合订正为 809000 / 809007（仅 dispatch）/ 582031 / 582083。

#8577
- 订正一处「POST requirement/confirm 零影响」的错误断言：doConfirm 与 confirm-check 共用
  已收窄的 classifyVehicleSubmission，该端点的 809122 触发条件同步收窄。
- 809121 / 809123 的错误响应示例换成测试服实测原文。
- frontend_status 保留 not_required，但把判定依据写进 status_note：三个码一律走拦截器透
  message、生产代码无一处按报文匹配、前端也无纯接送机户的规避需要撤除；同时列出五处现已
  陈旧的前端注释与一处 mock 报文，供 mmg 顺手清理。

门禁：validate-changelog-frontmatter.mjs --files 三个文件一次通过（PASS: 3 files）。

Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>

changelogs-v2/2026-09/30_8576_团期配车提交与确认响应新增车辆规格提醒清单-修改接口-管理后台.md

@@ -7,12 +7,12 @@ author: "wx(GIT)"
 change_type: "修改接口"
 backend_status: "deployed"
 gateway_status: "verified"
-frontend_status: "not_required"
+frontend_status: "pending"
 frontend_owner: ""
 frontend_ref: ""
 target_release: ""
 verified_at: ""
-status_note: "PR #8602 已 squash 合并 dev-v3（cfefe04a83），hl-fleet-service dev-v3 分支已滚测试服。纯新增字段，两个端点的既有字段、错误码、HTTP 形态全部未变。"
+status_note: "PR #8602 已 squash 合并 dev-v3（cfefe04a83），hl-fleet-service dev-v3 分支已滚测试服。纯新增字段，两个端点的既有字段、错误码、HTTP 形态全部未变。【2026-09-30 由 not_required 改回 pending，原因】前端确实消费这两个端点：hl-ui origin/v2.1 有 src/api/fleet/group-dispatch.js（reconfigure / confirm 各一个调用点），而全仓 specWarnings 命中数为 0 —— 即新字段目前无人渲染，提醒对车务不可见，需要前端补渲染后本条才算落地。"
 updated_at: "2026-09-30"
 base: "dev-v3"
 ---
@@ -102,7 +102,7 @@ base: "dev-v3"
 | `groupBatchId` | String | 团期主订单 ID（雪花，字符串） |
 | `requirementId` | String | 正式团级用车需求 ID（雪花，字符串） |
 | `requirementVersion` | Integer | 正式团级用车需求版本 |
-| `planVersion` | Integer/Long | 团期计划版本 |
+| `planVersion` | Long | 团期计划版本 |
 | `addedCount` | Integer | 新增派车记录数 |
 | `removedCount` | Integer | 软删派车记录数 |
 | `keptCount` | Integer | 保留未变派车记录数 |
@@ -264,12 +264,12 @@ base: "dev-v3"
 
 #### 错误响应
 
-既有错误码一条都没变。示例（分组不在本团需求内）：
+既有错误码一条都没变。示例（分组不在本团需求内，消息模板 `乘车分组不存在于本团正式需求: {0}`）：
 
 ```json
 {
   "code": 602001,
-  "message": "分组 VAN 不在本团正式用车需求的分组清单内",
+  "message": "乘车分组不存在于本团正式需求: VAN",
   "success": false,
   "data": null
 }
@@ -317,7 +317,7 @@ base: "dev-v3"
 | `alreadyConfirmedCount` | Integer | 确认前就已是「已确认」的配车行数（重复确认时全部落在这里） |
 | `requirementId` | String | 本次确认所依据的正式团级用车需求 ID（雪花，字符串） |
 | `requirementVersion` | Integer | 本次确认所依据的需求版本 |
-| `planVersion` | Integer/Long | 当前团期计划版本（确认不改计划，故不递增） |
+| `planVersion` | Long | 当前团期计划版本（确认不改计划，故不递增） |
 | `requirementAdvanceIntent` | String | 已登记的需求回写意图方向，恒为 `CONFIRMED_TO_DISPATCHED` |
 | `coverage` | Object | 按乘车分组的覆盖明细（确认前对库里现存配车行重判一次的结果），结构同 reconfigure |
 | `legacyGroupRowCount` | Integer | 本团存活派车行里没有乘车分组键的历史行数；非零时 602008 的缺口很可能正是它们造成的 |
@@ -423,12 +423,12 @@ base: "dev-v3"
 
 #### 错误响应
 
-既有错误码一条都没变。示例（现存配车对当前需求仍不完整）：
+既有错误码一条都没变。示例（现存配车对当前需求仍不完整，消息模板 `配车尚未覆盖完整, 不能确认: {0}`）：
 
 ```json
 {
   "code": 602008,
-  "message": "现存配车对当前需求仍不完整：分组 BUS 缺 2026-09-15",
+  "message": "配车尚未覆盖完整, 不能确认: 乘车分组 BUS 的服务日未排满, 缺失: [2026-09-15]",
   "success": false,
   "data": null
 }

changelogs-v2/2026-09/30_8577_只提交接送机的户不再被判未提交用车需求-修改接口-管理后台.md

@@ -12,7 +12,7 @@ frontend_owner: ""
 frontend_ref: ""
 target_release: ""
 verified_at: ""
-status_note: "PR #8600 已 squash 合并 dev-v3（5b7074e691），hl-order-service-v3 dev-v3 分支已滚测试服。三个端点的请求体、响应体字段与错误码号全部未变，变的是 809121/809122/809123 的触发条件（收窄）与消息文案（去掉「行程」二字）。"
+status_note: "PR #8600 已 squash 合并 dev-v3（5b7074e691），hl-order-service-v3 dev-v3 分支已滚测试服。三个端点的请求体、响应体字段与错误码号全部未变，变的是 809121/809122/809123 的触发条件（收窄）与消息文案（去掉「行程」二字）。【frontend_status 取 not_required 的依据，2026-09-30 对 hl-ui origin/v2.1 逐处查证】三个码的展示一律走拦截器透 message，生产代码无一处按报文字符串匹配；纯接送机户在前端也没有任何规避（按钮禁用/提示）需要撤除，故无强制前端动作。⚠️ 但有注释级陈旧需顺手清：src/api/orderV2GroupBatch.js:921,957,958 与 GroupVehicleRequirementEditModal.vue:377,874 仍写着「TRAVEL / 行程用车需求」，三个码现已按 TRAVEL ∪ TRANSFER 判「已提交」；GroupVehicleRequirementSection.spec.js:1000 的 mock 报文同样陈旧（该用例不断言文案，不会红）。"
 updated_at: "2026-09-30"
 base: "dev-v3"
 ---
@@ -232,12 +232,12 @@ base: "dev-v3"
 
 #### 错误响应
 
-809123（触发条件已收窄、文案已改写；`{0}` 是团期人话标识，`{2}` 按团号列户、无团号回落订单号、都缺时为「某子订单」，顿号分隔）：
+809123（触发条件已收窄、文案已改写；`{0}` 是团期人话标识，`{2}` 按团号列户、无团号回落订单号、都缺时为「某子订单」，顿号分隔；以下为测试服实测原文）：
 
 ```json
 {
   "code": 809123,
-  "message": "团期「第3期 10月8日出发团」有 2 户尚未提交用车需求，暂不能保存正式用车需求：26-0480、26-0481",
+  "message": "团期「第22期 8月喀纳斯湖秋色三日游」有 1 户尚未提交用车需求，暂不能保存正式用车需求：26-6538",
   "success": false,
   "data": null
 }
@@ -363,12 +363,12 @@ GET /v3/admin/order/group-batch/2099459272533000001/vehicle-requirement/aggregat
 
 #### 错误响应
 
-809121（触发条件已收窄、文案已改写；`{0}` 是团期名标识，`{2}` 是「户标识：原因」顿号分隔的清单，原因文案里的 `未提交行程用车需求` 已改为 `未提交用车需求`）：
+809121（触发条件已收窄、文案已改写；`{0}` 是团期名标识，`{2}` 是「户标识：原因」顿号分隔的清单，原因文案里的 `未提交行程用车需求` 已改为 `未提交用车需求`；以下为测试服实测原文）：
 
 ```json
 {
   "code": 809121,
-  "message": "团期 「第3期 10月8日出发团」 有 1 户缺少可汇总的用车需求，暂不能自动汇总：26-0480：未提交用车需求",
+  "message": "团期 「第22期 8月喀纳斯湖秋色三日游」 有 1 户缺少可汇总的用车需求，暂不能自动汇总：26-6538：未提交用车需求",
   "success": false,
   "data": null
 }
@@ -634,6 +634,7 @@ GET /v3/admin/order/group-batch/2099459272533000001/requirement/confirm-check
 | 某户只提交了接送机，团级 PUT 保存 | 809123 整份拒绝，运营无干净出路 | 正常保存 |
 | 某户只提交了接送机，点自动汇总 | 809121 整团出不来草稿 | 正常出草稿（该户不进草稿，也不进缺失清单） |
 | 某户只提交了接送机，进确认预检 | 该户挂 `HOUSEHOLD_REQUIREMENT_NOT_SUBMITTED`，`ready=false` | 不产出该缺失项 |
+| 某户只提交了接送机，点整体确认（`POST .../requirement/confirm`，真实派车/写库） | 809122 抛出，确认失败、零写入 | 正常确认，该户随团一起派车（前提其余条件都满足） |
 | 某户只提交了接送机，是否要求被乘车分组覆盖 | 会走到 809109 | 不要求（它结构上在团级分组之外） |
 | 809121 报文 | `团期 {0} 有 {1} 户缺少可汇总的**行程**用车需求…` | `…缺少可汇总的用车需求…` |
 | 809122 报文 | `该户尚未提交**行程**用车需求，…` | `该户尚未提交用车需求，…` |
@@ -655,9 +656,10 @@ GET /v3/admin/order/group-batch/2099459272533000001/requirement/confirm-check
 ## 七、不影响范围
 
 - **仅影响**: 团期需求管理 Tab 的三个端点里 809121 / 809122 / 809123 的触发条件与报文文案。
+- **⚠️ `POST .../requirement/confirm`（整体确认，真实派车/写库）不是零影响**：它的响应字段结构、派车/写库机制本身未改一行代码，但它内部同样经 `GroupBatchRequirementService.doConfirm`（`GroupBatchRequirementService.java:562`）调 `loadVehicleSnapshot`，后者第 1240-1241 行直接调用本次收窄后的 `classifyVehicleSubmission` 来判 809122——即它对 809122 的**实际触发条件与 `confirm-check` 端点同步收窄**：纯接送机户此前会在这里被 809122 拦下、零写入（回归用例 `GroupBatchRequirementServiceConfirmVehicleTest#doConfirm_householdWithoutTravelRequirement_throws809122` 钉住的正是「两类都没提交」仍会拦的边界），现在能正常通过、随团一起派车，见六.6 行为级对比。前端若曾据「纯接送机户点确认必失败」写过分支或禁用逻辑，需按该行为级对比同步调整。
 - **零影响**:
   - 809109 逐日覆盖判定（仍只认 TRAVEL）
-  - 整体确认端点 `POST .../requirement/confirm` 自身的确认逻辑与响应字段
+  - `POST .../requirement/confirm` 的响应字段结构（`GroupBatchRequirementConfirmRespVO` 字段清单未变）与派车 / 写库机制（`doConfirm` 方法体本身未改）
   - 受控重开、整份撤回、整团免车、按户打回四个端点
   - 接送机批量确认 `POST .../requirement/transfer/batch-confirm`
   - 户级用车需求的提交 / 编辑 / 打回链路

changelogs-v2/2026-09/30_8601_逐户提交车务与打回的kind参数取消默认值-修改接口-管理后台.md

@@ -133,12 +133,12 @@ Content-Type: application/json
 
 #### 错误响应
 
-🆕 809012（本次新增；`{0}` = 订单 ID，`{1}` = 两类名以 ` / ` 连接）：
+🆕 809012（本次新增；`{0}` = 订单 ID，`{1}` = 两类名以 ` / ` 连接）。以下为测试服实测原文（订单 ID 2105173274755534850）：
 
 ```json
 {
   "code": 809012,
-  "message": "订单 2099459272533323777 同时存在 TRAVEL / TRANSFER 两类活跃用车需求，请显式指定要操作的类别（kind=TRAVEL 行程用车 / kind=TRANSFER 接送机）",
+  "message": "订单 2105173274755534850 同时存在 TRAVEL / TRANSFER 两类活跃用车需求，请显式指定要操作的类别（kind=TRAVEL 行程用车 / kind=TRANSFER 接送机）",
   "success": false,
   "data": null
 }
@@ -227,12 +227,12 @@ Content-Type: application/json
 
 #### 错误响应
 
-🆕 809012（本次新增，与 dispatch 端点同码同文案）：
+🆕 809012（本次新增，与 dispatch 端点同码同文案）。以下为测试服实测原文（订单 ID 2105173313083080706）：
 
 ```json
 {
   "code": 809012,
-  "message": "订单 2099459272533323777 同时存在 TRAVEL / TRANSFER 两类活跃用车需求，请显式指定要操作的类别（kind=TRAVEL 行程用车 / kind=TRANSFER 接送机）",
+  "message": "订单 2105173313083080706 同时存在 TRAVEL / TRANSFER 两类活跃用车需求，请显式指定要操作的类别（kind=TRAVEL 行程用车 / kind=TRANSFER 接送机）",
   "success": false,
   "data": null
 }
@@ -245,18 +245,19 @@ Content-Type: application/json
 | 809000 | `用车需求类别非法：{0}` | `kind` 传了非法值 |
 | 582031 | `订单无有效需求行` | 按解析出的类别取不到活跃行 |
 | 582083 | `需求状态不允许此操作，请检查当前状态` | 非团期子订单，或最新需求不在 `PENDING_REVIEW` / `PENDING` |
-| 589535 | `子订单 {0} 已分房，请先由房务调整配房后再打回` | 该户仍有活跃派单/配房占用 |
 | 400 | `打回/驳回备注不能为空` | `returnRemark` 空 |
 
+> `589535`（子订单已分房）**不适用于本端点**：占用探测方法对 `resourceType=VEHICLE` 硬编码返回"无占用"（车侧无配房概念），该码只在 `resourceType=HOTEL` 时可能触发；已派车的拦截由另一套栅栏机制负责，不经过本码。这是既有行为，本次未改。
+
 #### 业务边界
 
 - **鉴权**：权限点 `group-batch:demand:confirm`；未登录由网关拦截返 401。
-- **🔴 解析排在占用探测之前**：`kind` 先解析、再用解析结果去做「有没有活跃占用」的探测——两处必须看同一个类别，否则探测与实写会错位。
+- **kind 解析结果同时用于占用探测与实际取行**：两步必须看同一个类别，避免错位——但车需求侧的占用探测恒不拦截（见上方说明），此为既有行为，本次未改。
 - **只对车需求解析**：同一条服务方法也承接房需求打回（`resourceType=HOTEL`），`kind` 对它无意义、不触发解析，**酒店打回不会被车侧的两类并存误伤**。
 - **副作用是跨聚合的**：除需求行外还会清团级 `requirement_confirmed` 并写团级时间线 `BATCH_REQUIREMENT_REJECT`，与批量打回落同一套副作用。
 - **打回后需求要重提**：定制师重新提交会创建**新的需求行**，不是在原行上改。
 - **🔴 809012 不是可重试错误**：处置是带上 `kind` 重发。
-- **失败零写入**：809012 抛在探测与实写之前。
+- **失败零写入**：809012 抛在取行与实写之前。
 
 ---
 
@@ -315,7 +316,6 @@ Content-Type: application/json
 - 需求状态不在允许的源状态集合 → 582083。
 - 该户按解析出的类别取不到活跃行 → 582031。
 - 解析到 TRANSFER 但服务日未回填 → 809007（dispatch 端点，失败关闭不放行）。
-- 打回时该户仍有活跃占用 → 589535。
 - `kind` 传非法值 → 809000（与改前一致，本次未改变非法值行为）。
 - 老数据兼容：不改表、不迁移；存量订单下次调用时按新解析规则生效。
 
@@ -346,7 +346,7 @@ Content-Type: application/json
 | `DispatchReqVO.dispatchRemark` | 选填 ≤500 | 未变 |
 | `RejectReqVO.returnRemark` | 必填 ≤500 | 未变 |
 | 两个端点的响应 | `Result<Void>` | 未变 |
-| 错误码集合 | 809000 / 809007 / 582031 / 582083 / 589535 | 🆕 **增加 809012** |
+| 错误码集合 | 809000 / 809007（仅 dispatch）/ 582031 / 582083 | 🆕 **增加 809012** |
 
 ### 行为级对比