changelog(#5842): 房务最终确认放开部分配房 + 未配/未确认晚号字段

changelogs-v2/2026-08/11_5842_房务最终确认放开部分配房-修改接口-管理后台.md

@@ -0,0 +1,97 @@
+---
+schema: "hl-changelog/v2"
+ticket: "5842"
+title: "房务最终确认取消「必须每晚配齐」限制：部分配房/未确认行放行 + 新增未配/未确认晚号字段"
+consumer: "admin"
+change_type: "修改接口"
+author: "wx(GIT)"
+backend_status: "deployed"
+gateway_status: "not_required"
+frontend_status: "pending"
+frontend_owner: "mmg"
+frontend_ref: ""
+target_release: ""
+verified_at: "2026-08-11"
+status_note: ""
+updated_at: "2026-08-11"
+base: "dev-v3"
+---
+
+# 房务最终确认：取消「必须每晚配齐」限制（#5842）
+
+> **服务**: hl-order-service-v3
+> **PR**: #5860（已合并 dev-v3 并部署测试服）
+> **日期**: 2026-08-11
+> **背景**: 房务「最终确认」原要求每一晚都配房且全部已确认，否则按钮灰掉并提示「配房与当前行程不一致，请调整后再确认」。现场 26-7666（6 天 5 晚）配了 DAY1/2、DAY3/4/5 待配 → 房务无法收口。wx 要求取消该限制，改为二次确认。
+
+---
+
+## 变更接口
+
+### 1. `GET /admin/house/orders/{orderId}` —— `actions.canFinalize` 放开条件
+
+**旧行为**：只有「每晚都配齐且全部已确认」或「一晚都没配（客人全程自住）」两种情况可最终确认；**部分配房一律禁用**。
+
+**新行为**：**部分配房、存在未确认配房行，均可最终确认**。
+
+| 情况 | 旧 | 新 |
+|---|---|---|
+| 每晚配齐且已确认 | ✅ | ✅ 不变 |
+| 一晚都没配 | ✅ | ✅ 不变 |
+| **部分晚没配房** | ❌ 禁用 | ✅ **放开** |
+| **配了但还没确认** | ❌ 禁用 | ✅ **放开** |
+| 配房日期与当前行程错位 | ❌ 禁用 | ❌ **仍禁用** |
+
+`disabledReason` 在放开后不再出现因部分配房产生的文案；日期错位时文案为「配房日期与当前行程不一致，请调整后再确认」。
+
+> ⚠️ **日期错位仍然硬拦**：这是订单改期后残留的旧配房行，放行会把过期日期的房当成有效配房回传给定制师、直接坏数据（与 `pendingRescheduleAssignments` 互为兜底）。前端不要试图绕过。
+
+### 2. `progress` 新增两个字段（供二次确认弹窗）
+
+```json
+"progress": {
+  "arrangedCount": 1,
+  "totalCount": 5,
+  "unarrangedDayNumbers": [1, 2, 3, 5],    // 【新增】还没配房的晚号
+  "unconfirmedDayNumbers": [4]             // 【新增】配了但还没确认的晚号
+}
+```
+
+| 字段 | 类型 | 说明 |
+|---|---|---|
+| `unarrangedDayNumbers` | `List<Integer>` | 未配房的晚号，升序 |
+| `unconfirmedDayNumbers` | `List<Integer>` | 已配房但 `confirmStatus != CONFIRMED` 的晚号，升序 |
+
+两者**互斥**（同一晚不会同时出现在两个列表里），都为空数组时即配齐且全确认。
+
+**为什么要加这两个字段**：`arrangedCount/totalCount` 只有数量，说不出「缺的是第 3、4、5 晚」，更完全无法表达「配了但酒店还没回复确认」——而这恰恰是本次放开的两类情况，二次确认文案必须分开说，否则房务不知道自己在确认什么。
+
+---
+
+## 前端要做
+
+`canFinalize.enabled` 为 true 且 `unarrangedDayNumbers` 或 `unconfirmedDayNumbers` **非空**时，点「最终确认」先弹二次确认，文案把两类情况分开列，例如：
+
+```
+还有第 1、2、3、5 晚未配房，第 4 晚已配房但酒店尚未确认。
+确认要完成配房吗？
+```
+
+两个列表都为空时（配齐且全确认）保持原有直接确认流程，不弹二次确认。
+
+`disabledReason` 直接透传展示即可，不需要再针对「配房与当前行程不一致」做特殊分支——该文案现在只在真正的日期错位时出现。
+
+---
+
+## 验证证据
+
+2026-08-11 测试服（网关 `https://api.test.1814.love:9443`，房务管理员 token）实测两个真实的部分配房订单：
+
+| 订单 | 进度 | `unarrangedDayNumbers` | `unconfirmedDayNumbers` | `disabledReason` |
+|---|---|---|---|---|
+| 26-3420 | 1/5 | `[1,2,3,5]` | `[4]` | 仅本人持有的订单可最终确认（权限原因，非覆盖度） |
+| 26-3281 | 1/2 | `[2]` | `[1]` | 同上 |
+
+两单的 `disabledReason` 均已不再是「配房与当前行程不一致」，证明覆盖度拦截确已解除；字段互斥升序、数值与实际配房状态一致。
+
+单测：`hl-order-service-v3` 全量 **586 类 / 7512 tests，0 failures 0 errors**，ArchTest 门禁 44 绿。核心逻辑通过**双向变异验证**：退回放开逻辑 → 7 个用例红（覆盖度层 2 / 读口 2 / 写口 3）；误把日期错位也放开 → 4 个用例红（含「未确认 + 旧日期」脏行场景）。