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

变更类型：🔧 流程重构（房务管家前端需较大迁移）端类型：管理后台（房务管家·配房/详情/日历/待办）日期：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待办单日确认自动消。全部通过。

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

6.8 KiB 原始文件 永久链接 Blame 文件历史 Unescape Escape