docs(changelog-v2/house): 房务测试报告(1.docx)整改批次前端对接

43 #4573 配房询房即扣库存+单日确认requirementId+弹窗全态回显currentSelections(前端必改)
44 #4574 日历团数按团期折叠修复+某天下钻详情新端点
45 #4575 待办按订单聚合一行多类型标签+类型字典化(前端必改)
46 #4578 定制师联系房务未读角标unreadMessageCount+站内信标题团号·联系人
47 #4576 转单操作日志显示接收人真名+转单理由(知悉)

changelogs-v2/2026-06/43_4573_房务配房询房即扣库存_单日确认requirementId_弹窗全态回显_前端必改-管理后台.md

@@ -0,0 +1,40 @@
+# 房务配房流程：询房即扣库存 + 单日确认带 requirementId + 配房弹窗全态回显（前端必改）
+
+> 模块：房务管家 · 配房行程（管理后台）
+> 类型：行为变更 + 出参新增字段（PR #4585/#4598/#4600 已合 dev-v3 + 测试服 R1/R2/R3 实测生效）
+> 关联工单：#4573 / #4597 / #4599
+> 日期：2026-06-28
+
+## 1. 【阻塞修复·必改】单日确认改用 itinerary[].requirementId 拼 URL
+
+房务测试反馈「第 1 天确认 OK、第 2 天选另一家酒店点确认报『缺少需求 ID, 暂无法确认』流程卡死」。
+
+- 根因：前端单日确认依赖了上一步流程残留的 requirementId 临时态，切到第 2 天直接点确认时取不到。
+- 后端已在订单详情 `GET /admin/house/orders/{orderId}` 的 `itinerary[]` **每天 VO 新增 `requirementId` 字段**（雪花，String 序列化），对所有天稳定一致。
+- **前端必改**：单日确认 `POST /v3/admin/order/hotel-requirements/{requirementId}/assignments/days/{dayNumber}/confirm` 的 `requirementId` 一律取 `itinerary[该天].requirementId`（不要依赖配房/询房流程的临时变量）。
+
+## 2. 【行为变更·必知】「询房即扣库存」
+
+业务规则调整：**配房进入「询房中」(INQUIRING) 即立即扣减酒店库存**（此前是「单日确认」才扣）。
+
+- `POST /.../assignments`（批量提交配房方案）：提交后该天候选行进入询房中**就已占用库存**；库存不足在**提交时**即拒（返 `808901 房型库存扣减失败:数量不足或日历记录缺失`）。
+- 单日确认 `.../days/{dayNumber}/confirm`：保留的候选**不再重复扣**；落选/未保留的候选软删并**自动还原库存**。
+- 影响前端：①「库存不足」错误现在出现在**提交配房**这一步（不再是确认步）；②取消选中/替换酒店后，被换掉的酒店库存会自动还原，无需前端干预。
+
+## 3. 【出参新增·建议用】配房弹窗全态回显 currentSelections
+
+房务测试反馈「选错酒店点确认后，再点配房不回显已选酒店、无法删除/替换」。
+
+- 订单详情 `itinerary[]` 每天 VO **新增 `currentSelections`**：该天**当前全部 active 配房行**（询房中 INQUIRING ∪ 已确认 CONFIRMED 的并集），每行带 `confirmStatus` 标识。
+- 候选端点 `GET /v3/admin/hotel-candidates` 的 `isCurrentlyAssigned` / `assignedRoomTypeId` 现在在**询房中与已确认两个阶段都会标记**（此前只认已确认）。
+- **前端建议**：再次打开配房弹窗时，用 `currentSelections`（或候选的 `isCurrentlyAssigned`）回显/高亮该天当前已选酒店，支持删除/替换；不要只读旧的 `inquiringAssignments`（确认后会变空）。旧字段 `currentAssignments`(仅 CONFIRMED) / `inquiringAssignments`(仅 INQUIRING) 保留兼容。
+
+## 4. 【入参校验】dayNumber 上界
+
+`POST /.../assignments` 提交的 `dayNumber` 超过该需求应配晚数 → 返 `808102 dayNumber 越界`。前端按行程天数约束，勿提交越界天号。
+
+## 测试服实测（R1/R2/R3）
+- itinerary 每天 requirementId 非空；第 2 天换酒店确认成功无「缺少需求 ID」。
+- 询房即扣：提交配房即 DB stock_used +N；确认保留不重扣；落选/替换/删除自动还原（stock 精确归还、不转负）。
+- 库存不足在提交步即拒 808901（干净中文消息）；填超量被拒后改小量重提同酒店可成功。
+- currentSelections 含询房中+已确认两态行；候选两阶段都标 isCurrentlyAssigned。

changelogs-v2/2026-06/44_4574_房务日历团数按团期折叠修复_某天下钻详情新端点_前端对接-管理后台.md

@@ -0,0 +1,44 @@
+# 房务日历：团数按团期折叠修复 + 新增「某天下钻详情」端点（前端对接）
+
+> 模块：房务管家 · 日历视图（管理后台）
+> 类型：计数修复 + 新增端点（PR #4586 已合 dev-v3 + 测试服实测）
+> 关联工单：#4574
+> 日期：2026-06-28
+
+## 1. 【修复·知悉】日历「共 N 团」不再按子订单膨胀
+
+房务反馈「某天显示『共 32 团』，实际就 3 个团」。
+
+- 根因：原按 `distinct order_id` 计数，但一个团期(productBatchId)会拆成多个子订单(1 单=1 房)，3 个团期约 32 间房被算成 32 团。
+- 已修：`GET /admin/house/calendar` 的 `tourCount` 与各状态点计数改按**团期优先键**折叠（同团期多子订单当天折叠为 1 团；散客无团期则回退订单维度，行为不变）。
+- 前端无需改，数字自动正确。
+
+## 2. 【新增端点·对接】某天团明细下钻
+
+为解决「日历详情信息太少」，新增下钻端点供点开某天时展示团明细。
+
+`GET /admin/house/calendar/day`
+
+| 入参 | 必填 | 说明 |
+|------|------|------|
+| `date` | 是 | 日期 yyyy-MM-dd |
+| `scope` | 否 | `mine`(默认)/`all` |
+| `status` | 否 | 按状态桶过滤(进行中/询房中/待配房/异常) |
+
+返回 `List<DayTourItemVO>`（按团折叠），每项字段：
+
+| 字段 | 说明 |
+|------|------|
+| `productName` | 团期/产品名（标题） |
+| `orderNo` / `orderId` | 团号 / 订单号 |
+| `customerName` / `adultCount` / `roomCount` | 客人 / 人数 / 间数（团维度合计） |
+| `hotelName` | 酒店（快照） |
+| `roomCategory` | 房型（**已翻中文 label**，如「标准间」） |
+| `stayDate` | 入住日 |
+| `status` / `statusLabel` | 状态桶 + 中文标签 |
+| `claimerName` | 房务（仅 scope=all 回填） |
+
+## 测试服实测
+- 某天 2 行配房同属 1 单 → tourCount=1（未膨胀）；多团期分别计 1。
+- 下钻端点字段齐全、房型中文（标准间）；同团期多子订单折叠为 1 项 roomCount 合计。
+- 网关路由已覆盖 `/admin/house/calendar/**`。

changelogs-v2/2026-06/45_4575_房务待办按订单聚合一行多类型标签_类型字典化_前端必改-管理后台.md

@@ -0,0 +1,39 @@
+# 房务待办列表：按订单聚合（一单一行、行内多类型标签）+ 类型字典化（前端必改）
+
+> 模块：房务管家 · 待处理（管理后台）
+> 类型：返回结构调整（PR #4587 已合 dev-v3 + 测试服实测）
+> 关联工单：#4575
+> 日期：2026-06-28
+
+## 背景
+房务反馈「同一订单出现多行（『刚抢单待配房』一行 + 『定制师消息未读』一行）」，要求**一个订单只占一行**，把该订单的多个待办分类标签都显示在这一行。
+
+## 返回结构变更（`GET /v3/admin/order/todos`）
+
+`list[]` 粒度由「(订单 × 待办类型) 一行」改为 **「一个订单一行」**，每行新增类型标签数组：
+
+| 字段 | 类型 | 说明 |
+|------|------|------|
+| `todoTypes` | Array | **本单当前 scope 下全部待办分类标签**（行内渲染多个标签） |
+| `todoTypes[].typeCode` | String | 类型码（SWAP_HOTEL / REFUND / HOTEL_REPLY_TIMEOUT / REQUIREMENT_ADJUSTED / INVENTORY_CHECK_OVERDUE / PENDING_ARRANGE / UNREAD_CHAT …） |
+| `todoTypes[].typeLabel` | String | **类型中文名（取数据字典 `house_todo_type`）**，前端直接展示 |
+| `todoTypes[].urgency` | String | 该标签紧急度 |
+| `todoTypes[].derived` | Boolean | true=派生项(刚抢单待配房/定制师消息未读，无 todoId 不可单独 RESOLVE)；false=持久化项 |
+| `todoTypes[].todoId` | Long | 持久化待办 ID（derived=false 时有，供 RESOLVE/查看） |
+| `todoTypes[].unreadCount` | Integer | UNREAD_CHAT 标签的未读数 |
+
+- 保留 `orderTodoCount` = `todoTypes.size()`（前端原「本单共 N 个待办」可继续用，或直接用 `todoTypes.length`）。
+- 行级 `urgency` = 该订单内各标签的最高紧急度（排序仍按此 + 时间）。
+- **分页/total 口径改为 distinct 订单数**（不再是待办行数）。前端分页器按此对齐。
+- 「核房超期」(INVENTORY_CHECK_OVERDUE，酒店维度无 orderId) 仍独立成行。
+
+## 前端必改
+1. 每行渲染 `todoTypes[]` 多个分类标签（中文 `typeLabel`），不再一订单多行。
+2. 操作入口按 `todoTypes[].derived`/`todoId` 区分：派生标签（刚抢单待配房/消息未读）走对应跳转、不可 RESOLVE；持久化标签带 todoId 可 RESOLVE/查看。
+3. 分页 total 改读新的 distinct 订单口径。
+
+## 顺带（前端自查）
+顶部说明文案「共 N 件待办 · 换酒店/核房超期/退订/询房 · 完成订单前置工作后自动解除」是前端硬编码旧文案，且「共 N 件」此前按旧枚举子集求和导致显示 0。请按新流程更新文案，「共 N 件」改为对聚合后 list/stats 全量统计。
+
+## 测试服实测
+- 同订单「酒店超时未回复 + 刚抢单待配房」聚合为一行、todoTypes 2 个中文标签、orderTodoCount=2、total=distinct 订单数。

changelogs-v2/2026-06/46_4578_定制师联系房务按钮未读角标unreadMessageCount_站内信标题团号联系人_前端对接-管理后台.md

@@ -0,0 +1,30 @@
+# 定制师侧「联系房务」未读角标 unreadMessageCount + 订单类型站内信标题改「团号·联系人」（前端对接）
+
+> 模块：订单详情/行程安排（定制师侧）· 站内信收件箱（管理后台）
+> 类型：出参新增字段 + 标题渲染变更（PR #4590/#4593（修boot）/#4589 已合 dev-v3 + 测试服实测）
+> 关联工单：#4578 / #4577
+> 日期：2026-06-28
+
+## 1. 【出参新增·对接】定制师侧「联系房务」未读消息角标
+
+房务反馈「订单详情 / 行程安排页的『联系房务』按钮，有未读消息时要显示未读数角标」。
+
+- 定制师侧订单详情 `GET /admin/order/orders/{id}` 与 行程安排 `GET /admin/order/orders/{id}/itinerary` **新增出参 `unreadMessageCount`**（Integer）。
+  - = 当前登录定制师在该订单 HOUSE 会话中的未读消息数；无未读返 0。
+  - 软依赖：消息服务临时不可达时降级返 0，不阻断订单详情主流程。
+- **前端对接**：在「联系房务」按钮上按 `unreadMessageCount > 0` 显示未读角标（数字）。
+
+（房务侧订单详情/我的接单列表此前已有 `unreadMessageCount` / `tabCounts.unreadMessageCount`，本次补的是**定制师侧**两个接口。）
+
+## 2. 【标题变更·知悉】订单类型站内信标题改「团号 · 联系人」
+
+房务反馈「订单类型的站内信标题太长，要换成团号+联系人短的」。
+
+- 站内信收件箱 `GET /admin/message/list` 中「订单消息」(kind=CHAT 聊天) 的展示标题由 `【聊天】发件人（角色）` 改为 **`订单号 · 客户姓名`**（如 `HL20260628142754274 · 赵建国`）。
+- 取不到订单摘要（非 HOUSE 会话 / 消息服务降级）时回退原 `【聊天】发件人` 兜底。
+- 「核房记录已更新」等普通消息(NOTIFY) 标题不变。
+- 前端无需改，标题自动变短。
+
+## 测试服实测
+- 定制师订单详情/行程安排返 `unreadMessageCount`（无未读=0；底层 admin_conversation_member.unread_count 增量打通）。
+- 站内信订单消息标题 = 「HL… · 赵建国」/「HL… · 周明远」；普通消息标题不变。

changelogs-v2/2026-06/47_4576_房务转单操作日志显示接收人真名与转单理由_知悉-管理后台.md

@@ -0,0 +1,18 @@
+# 房务转单操作日志：显示接收人真名（企微名优先）+ 转单理由（知悉）
+
+> 模块：房务管家 · 订单详情 · 操作日志（管理后台）
+> 类型：出参补字段（PR #4588 已合 dev-v3 + 测试服实测）· 知悉类，前端可选用
+> 关联工单：#4576
+> 日期：2026-06-28
+
+## 背景
+房务反馈「转单操作日志显示『admin 转单 接收人=2070753530120957954』——接收人显示成 userId，转单理由也没显示」。
+
+## 变更（`GET /v3/admin/house/orders/{orderId}/operation-log`）
+
+- 转单/超管指派的 `summary` 中接收人由 userId 改为**真名**（企业微信名优先，未绑企微回退用户名），如 `admin 转单 接收人=腰苏图`。
+- 操作日志项的 `detail`（OperationDetailVO）**新增 `reason`（转单理由）与 `toUserName`（接收人真名）**两字段；读时从 detail_json 解析，**历史日志也能显示**。
+- 前端可在操作日志详情里展示 `detail.reason` / `detail.toUserName`。
+
+## 测试服实测
+- 转单后操作日志 summary = `admin 转单 接收人=腰苏图`（真名非 userId）；`detail.reason` / `detail.toUserName` 有值。