docs: 补充房务 bug 修复交接清单

changelogs-v2/2026-07/63_房务_bug房务_前端修复清单.md

@@ -0,0 +1,73 @@
+# 房务 bug房务：管理后台修复清单
+
+## 来源
+
+桌面文件：`bug房务.docx`。
+
+## 后端当前状态
+
+`dev-v3` 已包含房务需求版本、改期平移、库存原子迁移、增减晚次、人数变化、作废需求保护、返工待办互斥和最终确认动作契约修复。TEST 回归数据由 Codex 生成，5 条王骁订单已进入 `PENDING / PENDING_CLAIM` 抢单池。
+
+## 管理后台必须修复
+
+### 1. 酒店多房型展示
+
+当定制师选择同一酒店的多个房型时，房务卡片必须按 `hotelId + roomTypeId` 展开，禁止把多个房型合并为一个房型后叠加房间数。展示的房型名称、房间数、价格和晚次必须与需求明细逐项对应。
+
+### 2. 待办标签颜色
+
+按后端 `todoType` 使用统一颜色：待配房、需求变更重配、待最终确认、酒店超时、异常/取消必须视觉可区分；不能只显示文字而丢失优先级。
+
+### 3. 指定酒店但不指定房型
+
+酒店已指定、房型为空时，仍应允许进入房务流程；候选列表限定指定酒店，房型由房务选择。不能把“房型为空”误判为需求无效。
+
+### 4. 最终确认后修改
+
+已最终确认订单进入详情后，仍需显示“修改/替换酒店、调整房型、修改房间数、清空配房”入口。操作前调用重新询房/重开接口，成功后刷新详情；不能在前端用 `m.finalized` 直接隐藏或禁用所有修改入口。
+
+重点文件：`src/views/housekeeper/components/OrderDetailModal.vue` 中 `canClearAssignments`、修改入口和 `ensureRequirementEditable` 的状态判断必须统一。
+
+### 5. 作废需求展示
+
+作废需求必须展示：
+
+- 作废状态和红色视觉标记
+- 准确易懂的作废原因，例如“定制师修改住宿需求，原房务需求已作废”
+- 仅保留“查看”操作
+- 隐藏领取、配房、替换、清空、确认、最终确认等所有写操作
+
+### 6. 改出发日期
+
+改期后页面必须展示新日期；当前有效晚次的配房日期由后端按 `dayNumber` 对齐。原日期库存先恢复，新日期库存全部预占成功后才提交；失败时订单、配房和库存保持原状。页面必须展示“已改期，配房需按新日期重新确认”的说明。
+
+### 7. 增加出行人数
+
+订单调整摘要和房务详情必须显示“增加 X 人”，同时展示调整前人数、调整后人数和新增出行人；既有酒店、房型、房间数和库存字段不得丢失。
+
+### 8. 增加行程天数
+
+必须展示“新增第 N 晚住宿，新增日期待配房”；原日期配房保留，新增晚次为空白候选，未完成新增晚次时禁止最终确认。
+
+## 验收订单
+
+使用以下 5 条 TEST 订单逐项验证：
+
+- `HL20260719092421973`
+- `HL20260719092425403`
+- `HL20260719092428569`
+- `HL20260719092431853`
+- `HL20260719092435001`
+
+每条订单均为定制师“王骁”，已模拟支付、补全出行人并提交住宿需求。
+
+## 验收要求
+
+必须同时提供：
+
+1. 房务首页截图
+2. 待办列表截图
+3. 订单详情截图
+4. 改期/增人/增晚前后对比截图
+5. 浏览器 Network 请求确认只提交 `dayNumber`，不由前端提交 `stayDate`
+6. 最终确认后订单从待办和工作台消失