docs: 通知前端订单调整房务复核闭环

changelogs-v2/2026-07/56_4907_订单调整保留配房与房务驳回定制师待办-管理后台.md

@@ -0,0 +1,88 @@
+# 【行为变更·管理后台】订单调整保留配房与房务驳回定制师待办（#4907）
+
+> 服务：`hl-order-service-v3`
+>
+> 生效分支：`dev-v3`
+>
+> 接口结构：无新增字段、无新增前端接口；沿用订单调整、房务详情、最终确认和房务驳回现有接口
+
+## 1. 订单调整后的房务口径
+
+定制师通过以下接口修改行程天数、出发日期或出行人数：
+
+```http
+POST /v3/admin/order/{orderId}/adjustment/submit
+```
+
+后端现在按最新行程重新对齐住宿需求逐晚结构，但不会自动删除或平移已经配置的酒店：
+
+| 调整项 | 前端应展示的结果 |
+|---|---|
+| 增加行程天数 | 原晚次配房保持；新增夜显示待配房 |
+| 减少行程天数 | 需求夜数减少；多余旧配房继续显示，等待房务人工清空/替换 |
+| 修改出发日期 | 原配房继续显示；旧日期配房阻断最终确认，等待房务人工处理 |
+| 修改出行人数 | 原配房继续显示；完整配房回到待最终确认，不完整则回配房中 |
+
+新增夜允许空候选占位，`roomCount` 未填或为 `0` 均可提交；负数仍会被后端拒绝。前端不要为了绕过校验自行填造假的间数。
+
+## 2. 最终确认
+
+```http
+POST /admin/house/assignments/requirements/{requirementId}/finalize
+```
+
+- 没有任何配房时允许最终确认，用于客人自行解决住宿的场景。
+- 一旦存在任意配房，所有 active 配房必须已确认，并按晚次精确覆盖当前行程住宿日期。
+- 旧日期、缺夜或多余夜返回：
+
+```json
+{
+  "code": 808181,
+  "message": "已有配房与当前行程不一致，请先补配、替换或清空",
+  "data": null
+}
+```
+
+前端收到该错误后保留当前配房数据，提示房务逐日处理；不得清空页面状态或隐藏旧配房。
+
+## 3. 房务驳回后的定制师待办
+
+```http
+POST /v3/admin/order/{orderId}/hotel-requirement/supplier-reject
+Content-Type: application/json
+
+{
+  "returnRemark": "酒店无法满足当前房型，请重新确认需求"
+}
+```
+
+驳回成功后，后端会为原定制师显式创建一条待办：
+
+```json
+{
+  "todoType": "ASSIGN_ROOM",
+  "todoLabel": "房型需求 · 已打回",
+  "status": "PENDING",
+  "assigneeRoleKey": "CUSTOMIZER",
+  "relatedBizType": "HOTEL_REQUIREMENT",
+  "relatedBizId": "2075933198734303233"
+}
+```
+
+该待办与订单当前是否仍处于“补出行人资料”阶段无关。定制师待办页按现有待办接口正常展示并跳转订单调整即可。
+
+## 4. 前端验收
+
+1. 增天后原配房不消失，新增夜可单独配房。
+2. 减天或改期后旧配房仍可见，最终确认被后端阻断，直到人工清空/替换。
+3. 修改人数后已有配房保持，房务重新最终确认。
+4. 零配房订单允许最终确认。
+5. 房务驳回后，原定制师能看到“房型需求 · 已打回”待办。
+6. 历史需求和旧配房均继续展示，不得只渲染当前需求而丢失历史证据。
+
+## 5. 后端验证证据
+
+- PR：`wx/HL#4910`、`wx/HL#4911`
+- 测试环境双实例：`8086/8186` 均 UP
+- 网关全流程：增天、补配、人数变化、改期、减天、人工清空、零配房最终确认、房务驳回待办全部通过
+