diff --git a/changelogs-v2/2026-06/62_站内信订单消息按会话归并一条_跳转改去配房详情_详情页红点接unreadMessageCount_前端处理-管理后台.md b/changelogs-v2/2026-06/62_站内信订单消息按会话归并一条_跳转改去配房详情_详情页红点接unreadMessageCount_前端处理-管理后台.md
new file mode 100644
index 0000000..feeb37d
--- /dev/null
+++ b/changelogs-v2/2026-06/62_站内信订单消息按会话归并一条_跳转改去配房详情_详情页红点接unreadMessageCount_前端处理-管理后台.md
@@ -0,0 +1,32 @@
+# 站内信：订单消息按「会话」归并成一条 + 跳转去配房详情(非 order-v2) + 详情页红点接 unreadMessageCount
+
+> 模块：管理后台 · 站内信「订单消息」+ 房务订单详情红点
+> 类型：**前端处理**（后端数据已具备，无后端改动）
+> 日期：2026-06-30 · 反馈来源：wx 手动测试
+> 说明：**本文 D1 部分修正 57_「订单消息 tab 用 list?messageType=ORDER」** —— 订单消息改为按会话归并（一个订单一条）。
+
+## D1：一个订单的聊天要归并成一条（不要一条消息一行）
+现象：「订单消息」tab 把同一个订单的多条聊天消息（如 4444112、77721）显示成**多行**。要求：**一个订单的会话只显示一条**（最新一条 + 未读数），像聊天 App 的会话列表。
+
+【前端处理】**「订单消息」tab 改用会话列表接口** `GET /admin/message/chat/conversations?pageNo=1&pageSize=20`（一行=一个会话/订单，自带 `lastMessagePreview`/`lastMessageAt`/`unreadCount`/`orderNo`/`customerName`），**不要**再用 `list?messageType=ORDER`（那是一条消息一行）。
+- 「普通消息」tab 仍用 `list?messageType=NORMAL`（系统通知，一条一行，正确）。
+- 「全部」tab：系统通知（NOTIFY）一条一行 + 订单聊天按会话归并一行（CHAT 会话），二者混排。
+
+## D2：订单消息「跳转」目标错（房务进了 order-v2 订单详情，应进配房详情）
+现象：房务（admin/房务管理员）点订单消息的「跳转」，进了 `order-v2/detail/{orderId}`（定制师侧订单详情页），**应进「配房详情」**（房务自己的工作页）。
+
+【前端处理】订单消息（CHAT 会话）的点击/跳转**按角色去对应工作页**：
+- **房务** → 打开**配房详情**弹窗（房务订单详情，接口 `GET /admin/house/orders/{orderId}`，orderId 取会话的 bizId / conversationKey `HOUSE:{orderId}` 解析），**不要**跳 `order-v2/detail`；
+- 或点击订单消息直接**打开该会话的聊天面板**（changelog 59 的 `open-house`）也可，按产品取一种；总之房务侧不应落到 order-v2 定制师订单详情页。
+
+> ⚠️ 关联后端待核（已记录）：房务能打开 `order-v2/detail` 且未报越权——order-v2（一期）订单详情接口对房务角色是否应拦，需产品确认（房务是否禁看定制师订单详情）。本条前端先把跳转目标改对，越权另行核。
+
+## C：定制师发消息后，房务订单详情「联系定制师」没红点
+现象：定制师给房务发消息，房务订单详情页「联系定制师」按钮**没红点**。后端已查实数据正确（截图当时该消息确为未读）。
+
+后端已提供：`GET /admin/house/orders/{orderId}` → `data.tabCounts.unreadMessageCount`（该订单聊天未读数，经 Feign 取当前登录房务在该会话的未读，纯读不误清）。
+
+【前端处理】
+1. 房务订单详情渲染时，`tabCounts.unreadMessageCount > 0` 即在「联系定制师」按钮上显示红点（数字角标可选）。
+2. 实时：房务停留在详情页时若定制师发来消息（CHAT SSE，conversationKey=`HOUSE:{orderId}`），前端据 SSE 点亮该红点（或重拉 unreadMessageCount），不必等重开页面。
+3. 房务打开聊天会话（open-house 标记已读）后，红点随 unreadMessageCount 归 0。
diff --git a/changelogs-v2/2026-06/63_房务订单详情弹窗去掉复制内部外部链接两按钮_前端处理-管理后台.md b/changelogs-v2/2026-06/63_房务订单详情弹窗去掉复制内部外部链接两按钮_前端处理-管理后台.md
new file mode 100644
index 0000000..46a8466
--- /dev/null
+++ b/changelogs-v2/2026-06/63_房务订单详情弹窗去掉复制内部外部链接两按钮_前端处理-管理后台.md
@@ -0,0 +1,11 @@
+# 房务订单详情弹窗：去掉「复制内部链接 / 复制外部链接」两个按钮
+
+> 模块：管理后台 · 房务订单详情弹窗（底部操作栏）
+> 类型：**前端处理**（纯前端去按钮，无后端改动）
+> 日期：2026-06-30 · 反馈来源：wx 手动测试
+
+## 现象 / 要求
+房务订单详情弹窗底部操作栏里有「**复制内部链接**」「**复制外部链接**」两个按钮，wx 要求**去掉这两个按钮**。
+
+## 【前端处理】
+房务订单详情弹窗底部去掉「复制内部链接」「复制外部链接」两个按钮（保留「转单」「提交配房方案」「最终确认」等其它按钮）。纯前端移除，无后端依赖。
diff --git a/changelogs-v2/2026-06/64_房务待处理页改显所有未完成订单含异常_改用我的订单接口过滤_前端处理-管理后台.md b/changelogs-v2/2026-06/64_房务待处理页改显所有未完成订单含异常_改用我的订单接口过滤_前端处理-管理后台.md
new file mode 100644
index 0000000..d0f7ad4
--- /dev/null
+++ b/changelogs-v2/2026-06/64_房务待处理页改显所有未完成订单含异常_改用我的订单接口过滤_前端处理-管理后台.md
@@ -0,0 +1,20 @@
+# 房务「待处理」页：改为显示所有未完成订单（含异常），而非只显示 todo 待办
+
+> 模块：管理后台 · 房务管家 · 待处理
+> 类型：**前端处理**（改数据源；后端订单列表接口已具备，无后端改动）
+> 日期：2026-06-30 · 反馈来源：wx 手动测试
+
+## 现象 / 要求
+房务「待处理」页显示「没有待处理事项 / 共 0 个待办订单」，但订单列表里明明有未完成订单（如 HL20260630103610215「待最终确认·已配3/共3晚」）。
+
+根因：「待处理」页现在调的是 `GET /v3/admin/order/todos`（**todo 待办驱动**——只有异常/超时/换店等动作类事件才生成 todo；「待最终确认」是正常流转态、不产 todo），所以为 0。
+
+wx 要求：**「待处理」应显示所有「未完成」订单，异常也算未完成。**
+
+## 【前端处理】
+「待处理」页**改用「我的订单」列表接口**（房务订单列表同源，`GET /v3/admin/order/grab-pool/my-claims/hotel`），**按未完成状态过滤**：
+- 「未完成」= 房务流程未到「已完成」的全部，含 **配房中（CLAIMING）+ 待最终确认（PENDING_FINALIZE）+ 异常（EXCEPTION）**；排除「已完成（CONFIRMED）」。
+- 即等价于订单列表去掉「已完成」tab 的并集（配房中 ∪ 待确认 ∪ 异常），用列表项的 `houseStatus/houseStatusLabel` 过滤。
+- 不要再用 `todos` 接口作「待处理」唯一数据源（todo 只覆盖异常/动作类，漏掉正常未完成态）。
+
+> 备注：与「工作台首页待办摘要」(dashboard-summary) 是两个概念——首页摘要是 todo/桶视图（wx 早前确认按桶稀疏呈现不动）；本「待处理」页是房务的「待办订单」工作队列，按未完成订单口径展示。后端订单列表接口已能按状态过滤，前端改数据源即可。