3.2 KiB
房务 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 订单逐项验证：
HL20260719092421973HL20260719092425403HL20260719092428569HL20260719092431853HL20260719092435001
每条订单均为定制师“王骁”，已模拟支付、补全出行人并提交住宿需求。
验收要求
必须同时提供：
- 房务首页截图
- 待办列表截图
- 订单详情截图
- 改期/增人/增晚前后对比截图
- 浏览器 Network 请求确认只提交
dayNumber，不由前端提交stayDate - 最终确认后订单从待办和工作台消失