# 配房流程大改：天级确认（询房中→单日确认→整体确认→可改）+ 删记录式询房

> 变更类型：🔧 流程重构（**房务管家前端需较大迁移**）
> 端类型：管理后台（房务管家·配房/详情/日历/待办）
> 日期：2026-06-27 ｜ 工单：#4469 #4474 ｜ PR：#4470 #4475 ｜ 服务：hl-order-service-v3（双实例已部署测试服，22 项全场景 E2E + DB 地面真相核对通过）

> ⚠️ 本单**取代**早前 `27_4427`（询房候选流程）的「询房候选」部分——询房中候选改由配房行 `confirm_status` 派生，不再有记录式询房消息。`28_4435` 的 `currentAssignments`（一天多家）保留但语义收紧为「仅已确认」。

---

## 一、配房流程改为「天级确认」（核心）

新流程：**抢单 → 单日行程点「配房」选酒店/房型/数量（可多选多家候选）→ 该天「询房中」→ list 每天单独「单日确认」→ 整体确认 → 整体确认后还能改房**。

「询房」= **只复制话术**（记录式发起询房/询房历史已删，见第四节）。

配房行新增确认态 `confirm_status`：
- `INQUIRING`（询房中）= 配房时选的候选，**不占库存**；
- `CONFIRMED`（已确认）= 单日确认保留的，**此刻才扣库存**。

---

## 二、新端点（2 个）

### 1. 单日确认
`POST /v3/admin/order/hotel-requirements/{requirementId}/assignments/days/{dayNumber}/confirm`
- Body（可整体省略）：`{ "keepAssignmentIds": [Long...] }` —— 从该天「询房中」候选里**挑要保留的**（可多家）；**省略/空数组 = 该天全部候选都保留**。
- 行为：保留的行 → `CONFIRMED` + **扣 resource 库存**（库存不足在此拒，code `ROOM_STOCK_INSUFFICIENT`）；落选的行软删。全部天都已确认时需求自动进「待最终确认」。
- 出参 `Result<Void>`；幂等同 `(requirementId, dayNumber)` 3 秒。

### 2. 整体确认后解冻改房（reopen）
`POST /v3/admin/order/hotel-requirements/{requirementId}/reopen`
- 用途：整体确认（已完成）后房务还要改房时调用，把需求从「已完成」退回「配房中」再改。
- 放行条件：订单 `flow_status ≤ 待确认(PENDING_CONFIRM)`（含待支付/待补全信息/资源准备/待确认）；已进下游（待出行及以后）→ 拒 `808122`「订单已确认进入下游，如需改房请由定制师重新调整需求」。
- 幂等：已是「配房中」重复调用安全。

> 配房保存 `POST .../assignments`、改价 `PUT .../assignments/{id}`、删配房 `DELETE .../assignments/{id}` 在「已完成」态仍被拦 `808121`，**必须先 reopen** 才能改。

---

## 三、详情 `GET /admin/house/orders/{orderId}` 字段变更（`itinerary[]` 每天）

| 字段 | 变更 |
|---|---|
| `arrange` / `arrangeLabel` | 三态语义改由 `confirm_status` 派生：`pending`(待配房，无配房行) / `waiting`(询房中，有 INQUIRING 候选无已确认) / `confirmed`(已确认，有 CONFIRMED 行) |
| **`inquiringAssignments`（新增数组）** | 该天「询房中」候选行，结构同 `currentAssignment`（assignmentId/hotelId/roomTypeId/hotelName/roomCategory/roomCount/protoPrice/sellPrice，金额+雪花字符串）。**前端单日确认弹窗读它挑选**，拿 `assignmentId` 作 `keepAssignmentIds` |
| `currentAssignments`（数组） | 语义收紧：**只含已确认（CONFIRMED）行**（之前含全部 active） |
| `currentAssignment`（单数，已废弃） | = `currentAssignments[0]` |
| ~~`inquiries` / `InquiryCandidate`~~ | **删除**（旧记录式询房候选，改用 `inquiringAssignments`） |
| ~~`waitingDesc`~~ | **删除** |

---

## 四、删除 6 个记录式询房端点（询房=只复制话术）

**删**（调用返 body `code:404 接口不存在`）：
- `POST /v3/admin/order/inquiry/send`（发起询房）
- `POST /v3/admin/order/inquiry/{id}/reply`（回填）
- `GET /v3/admin/order/inquiry`（询房历史）
- `GET /v3/admin/order/inquiry/timeouts`
- `POST /v3/admin/order/inquiry/{id}/resend`（重发）
- `POST /v3/admin/order/inquiry/{id}/escalate`（加急）

**保留**：`POST /v3/admin/order/inquiry/preview`（复制话术，房型已翻中文如「标间」）。

前端需：去掉「发起询房」「询房历史」入口，询房按钮接 `/inquiry/preview` 复制话术。

---

## 五、日历 `GET /admin/house/calendar`

- 「询房中」黄点桶现在 = 该天有 `confirm_status=INQUIRING` 的配房行（不再读记录式询房消息）。`summary.inquiry` 同义。
- 4 桶不变（异常/询房中/待配房/进行中），其中「已抢未配」仍归进行中（#4448 不回退）。

---

## 六、待办 `GET /v3/admin/order/todos`

- **`stats` 新增两键**：`REQUIREMENT_ADJUSTED`（异常订单·需求变更，定制师改出发日期/行程天数）、`HOTEL_REPLY_TIMEOUT`（酒店超12h未回复）。
- **删** `stats` 的 `INQUIRY_TIMEOUT` / `INQUIRY_ESCALATED` 键。
- 新 `todoType=HOTEL_REPLY_TIMEOUT`（label「酒店超时未回复」）：某天选了酒店发了话术但 12h 内没单日确认 → 待办提醒（每小时 job 产，房务单日确认/取消/标完成后自动消）。
- 「我的接单」`list[]` 删 `waitingDesc`。

### 6b. 待办列表并入 ①刚抢单 + ④定制师未读消息（派生项，PR #4480）

`GET /v3/admin/order/todos` 的 `list[]` 新增 2 类**派生项**（实时算，非持久化）：
- **`todoType=PENDING_ARRANGE`「刚抢单待配房」**：当前房务 claimer 且 `house_status=CLAIMING` 的需求（一需求一条，带 `requirementId`）。
- **`todoType=UNREAD_CHAT`「定制师消息未读」**：当前房务抢的订单中**有定制师未读消息**（unread>0）的订单（一订单一条，带 `unreadCount`）。**被动展示，不主动推送通知**。

派生项标识 `derived:true`、**无 `id`（不可走待办 RESOLVE 端点）**，源条件消失即自然消失（①配齐确认离开 CLAIMING / ④房务读消息 unread 归 0）。**派生项置顶、仅第 1 页出现、不计入 `total`**。`stats` 再加 `PENDING_ARRANGE`、`UNREAD_CHAT` 两全量计数键。

前端：待办列表渲染 5 类（②③⑤持久化可处理 + ①④派生只展示/点击跳转）；派生项 `derived=true` 不显示「处理/解决」按钮。

---

## 七、测试服实测（22 项全场景 E2E，DB 地面真相核对）

抢单→配2候选(INQUIRING不扣库存)→询房中→单日确认(挑保留→CONFIRMED+落选软删+此刻扣库存)→逐天→整体确认(房控DONE)→已确认改房拦808121→reopen解冻→可改；一天保留多家→多家CONFIRMED各扣库存；取消已配房→异常+退订待办；preview话术翻中文；6询房端点已删；reopen下游拒808122；未付款单reopen放行；酒店12h待办单日确认自动消。全部通过。

> 后端已完成并实测，前端按本单迁移。