docs: 更新订单改期配房平移与库存契约

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

@@ -14,17 +14,35 @@
 POST /v3/admin/order/{orderId}/adjustment/submit
 ```
 
-后端现在按最新行程重新对齐住宿需求逐晚结构，但不会自动删除或平移已经配置的酒店：
+后端现在按最新行程重新对齐住宿需求逐晚结构。既有配房不会被自动删除；真正改出发日期时，仍在新行程晚数范围内的配房会按 `dayNumber` 自动平移入住日期：
 
 | 调整项 | 前端应展示的结果 |
 |---|---|
 | 增加行程天数 | 原晚次配房保持；新增夜显示待配房 |
 | 减少行程天数 | 需求夜数减少；多余旧配房继续显示，等待房务人工清空/替换 |
-| 修改出发日期 | 原配房继续显示；旧日期配房阻断最终确认，等待房务人工处理 |
+| 修改出发日期 | `stayDate = 新出发日期 + dayNumber - 1`；酒店、房型、房间数、价格、扣库存选择和备注原样保留；配房退回询房中重新确认 |
+| 同时改日期和天数 | 新行程范围内的配房自动平移；新增夜为空待配；超出新晚数的旧配房不自动删除 |
 | 修改出行人数 | 原配房继续显示；完整配房回到待最终确认，不完整则回配房中 |
 
 新增夜允许空候选占位，`roomCount` 未填或为 `0` 均可提交；负数仍会被后端拒绝。前端不要为了绕过校验自行填造假的间数。
 
+### 改期库存原子性
+
+- `deductInventory=false`：只平移订单配房快照，不操作资源库存。
+- `deductInventory=true`：后端先逐晚预占新日期库存；全部成功后才修改订单、行程、需求和配房日期，并释放旧日期库存。
+- 任意新日期库存不足或日历缺失：整次订单调整返回 `808901`；订单日期、需求版本、配房和旧库存全部保持原样，已临时预占的新日期库存自动补偿。
+- 前端收到 `808901` 时只提示库存不足，不得将本地表单当作已保存。
+
+### 房务人工修改配房
+
+房务仍通过现有配房提交接口按晚次替换：
+
+```http
+POST /v3/admin/order/hotel-requirements/{requirementId}/assignments
+```
+
+同一 `dayNumber` 可重新选择 `hotelId`、`roomTypeId`、`roomCount`。入住日期由后端按当前行程与 `dayNumber` 计算，不能沿用前端缓存的旧日期；替换后重新进入询房/确认流程。
+
 ## 2. 最终确认
 
 ```http
@@ -33,7 +51,7 @@ POST /admin/house/assignments/requirements/{requirementId}/finalize
 
 - 没有任何配房时允许最终确认，用于客人自行解决住宿的场景。
 - 一旦存在任意配房，所有 active 配房必须已确认，并按晚次精确覆盖当前行程住宿日期。
-- 旧日期、缺夜或多余夜返回：
+- 缺夜、多余夜、日期不匹配或存在未确认配房返回：
 
 ```json
 {
@@ -43,7 +61,7 @@ POST /admin/house/assignments/requirements/{requirementId}/finalize
 }
 ```
 
-前端收到该错误后保留当前配房数据，提示房务逐日处理；不得清空页面状态或隐藏旧配房。
+前端收到该错误后保留当前配房数据，提示房务逐日处理；不得清空页面状态或隐藏超出新行程的旧配房。
 
 ## 3. 房务驳回后的定制师待办
 
@@ -73,16 +91,22 @@ Content-Type: application/json
 
 ## 4. 前端验收
 
-1. 增天后原配房不消失，新增夜可单独配房。
-2. 减天或改期后旧配房仍可见，最终确认被后端阻断，直到人工清空/替换。
-3. 修改人数后已有配房保持，房务重新最终确认。
-4. 零配房订单允许最终确认。
-5. 房务驳回后，原定制师能看到“房型需求 · 已打回”待办。
-6. 历史需求和旧配房均继续展示，不得只渲染当前需求而丢失历史证据。
+1. 增天后原配房不消失，新增夜可单独配房；不再出现 `roomCount 必须 > 0`。
+2. 改期后原配房按晚次自动平移日期，酒店、房型、房间数和价格快照不变，状态退回询房中。
+3. 改期同时增减天数时，新范围内配房平移、新增夜为空、超范围旧配房保留。
+4. 房务可按晚次替换日期对应的酒店、房型和房间数。
+5. 扣库存配房改期成功时旧库存释放、新库存扣减；任一晚不足时整单不变。
+6. 减天后的多余旧配房继续显示，最终确认被后端阻断，直到人工清空/替换。
+7. 修改人数后已有配房保持，房务重新最终确认。
+8. 零配房订单允许最终确认。
+9. 房务驳回后，原定制师能看到“房型需求 · 已打回”待办。
+10. 历史需求和旧配房均继续展示，不得只渲染当前需求而丢失历史证据。
 
 ## 5. 后端验证证据
 
-- PR：`wx/HL#4910`、`wx/HL#4911`
-- 测试环境双实例：`8086/8186` 均 UP
-- 网关全流程：增天、补配、人数变化、改期、减天、人工清空、零配房最终确认、房务驳回待办全部通过
+- PR：`wx/HL#4910`、`wx/HL#4911`、`wx/HL#4913`
+- 测试环境部署任务：`440ed4d1`，`8086/8186` 双实例均 UP
+- 模块全量：5499 项；与 clean baseline 相同的既有 5 项失败，无新增回归
+- 网关全流程报告：`D:/work2/HL-v3/.tmp/house-adjustment-flow-probe-20260712-024715.json`
+- 实测通过：增晚、减晚、人数变化、改期+增晚同次提交、酒店/房型/房间数替换、入住日期对齐、人工清空、零配房最终确认、房务驳回待办、库存成功迁移、库存不足整单回滚