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

schema, ticket, title, consumer, change_type, author, backend_status, gateway_status, frontend_status, frontend_owner, frontend_ref, target_release, verified_at, status_note, updated_at, base

schema	ticket	title	consumer	change_type	author	backend_status	gateway_status	frontend_status	frontend_owner	frontend_ref	target_release	verified_at	status_note	updated_at	base
hl-changelog/v2	5842	房务最终确认取消「必须每晚配齐」限制：部分配房/未确认行放行 + 新增未配/未确认晚号字段	admin	修改接口	wx(GIT)	deployed	not_required	implemented	mmg	ddb3b823		2026-08-11	前端已实现(2026-08-11,mmg,ddb3b823)：orderDetailAdapter 透传 progress 新增 unarrangedDayNumbers/unconfirmedDayNumbers(互斥升序,缺省/非数组归一 []),新增纯函数 buildFinalizeConfirmContent 分列拼接二次确认文案;OrderDetailModal 最终确认按钮 @click 改 onFinalizeClick,两列表非空先弹 dialog.warning 二次确认(确认完成才 doFinalize)、均空保持直接确认;日期错位仍由后端 808183 硬拦+本地重拉清理入口不动。测试:adapter spec +3 透传 +4 文案纯函数用例,housekeeper 44 全绿,checkpoint 精确文件集全过。	2026-08-11	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 新增两个字段（供二次确认弹窗）

"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 个用例红（含「未确认 + 旧日期」脏行场景）。