# 房务 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. 最终确认后订单从待办和工作台消失