# 目标前端

- 端类型：管理后台（Web）
- 目标仓库：`mmg/hl-ui`（`https://git.1814.love:8443/mmg/hl-ui.git`）
- 联调/验收环境：`http://192.168.100.160:9527`
- 小程序、H5 及其他前端：无需处理

# 变更背景

订单改出发日期后，原入住日期已经配置的酒店不能静默平移到新日期。房务需要明确核对并逐条删除旧配房；旧配房未清完时禁止最终确认。

# 详情接口新增字段

`GET /admin/house/orders/{orderId}` 顶层新增：

```json
{
  "pendingRescheduleAssignments": [
    {
      "assignmentId": "99001",
      "originalStayDate": "2026-07-22",
      "hotelId": "8001",
      "hotelName": "示例酒店",
      "roomTypeId": "9001",
      "roomTypeName": "普通标间",
      "roomCategory": "STANDARD",
      "roomCategoryLabel": "标间",
      "roomCount": 2,
      "assignmentStage": "FINAL_CONFIRMED",
      "assignmentStageLabel": "最终确认",
      "deleteEndpoint": "DELETE /v3/admin/order/assignments/99001"
    }
  ]
}
```

`assignmentStage` 枚举：

| 值 | 中文 | 含义 |
| --- | --- | --- |
| `UNCONFIRMED` | 未单日确认 | 改期前仍处于询房/候选阶段 |
| `DAY_CONFIRMED` | 单日确认 | 改期前已完成该日确认，但原需求未最终确认 |
| `FINAL_CONFIRMED` | 最终确认 | 改期前所属住宿需求已经最终确认 |

数组为空表示没有改期旧配房待清理。旧配房不会再出现在当前 `itinerary[].assignments`，也不计入当前配房进度。

# 前端交互要求

1. 在“订单调整提醒”的改期记录下展示 `pendingRescheduleAssignments`，每行至少显示：原日期、酒店、房型、数量、配房步骤。
2. 每行提供“删除旧配房”，调用返回的 `deleteEndpoint`；成功后重新拉取详情。
3. 只要数组非空，不允许用户最终确认，并显示后端 `actions.canFinalize.disabledReason`。
4. 数组清空后再按后端 `actions.canFinalize.enabled` 决定按钮状态，禁止前端自行推断。
5. 删除仍可能因领取归属、房务写权限、并发修改或库存释放链路失败而报错，直接展示后端消息并刷新详情。

# 最终确认写口门禁

`POST /admin/house/assignments/requirements/{requirementId}/finalize`

若仍有旧日期配房，返回业务错误：

- code：`808183`
- message：`改期前旧日期配房尚未清理，请逐条删除后再最终确认`

该门禁由后端强制执行，前端禁用按钮仅用于交互提示。

# 兼容说明

- 字段为 additive；旧页面忽略新增字段不会影响反序列化。
- `roomTypeName` 在资源服务降级时可为空，前端回退 `roomCategoryLabel`。
- `assignmentId`、`hotelId`、`roomTypeId` 按字符串处理，禁止转 JavaScript `number`。