文档(order/admin): 订单详情「联系房务」面板在线态+房务专员为前端假数据核实(前端BUG)

- 在线绿点=前端写死(后端无在线态来源,HouseStaffQueryReqVO.online注释明写不生效;聊天VO无online字段;SSE连接表不对外)
- 房务专员=抢单人,抢单前claimer为空属占位
- 反向定制师→联系房务真对接缺claimerId(订单详情仅暴露claimerName),需要时后端补

changelogs-v2/2026-06/22_订单详情联系房务面板在线态+房务专员为前端假数据-应去在线态+反向开会话缺claimerId-前端BUG.md

@@ -0,0 +1,72 @@
+# 订单详情「联系房务」聊天面板：在线态 + 房务专员（抢单前）为前端假数据（前端BUG）
+
+> 变更类型：🐞 前端假数据核实 + 对接口径澄清（无需建工单，按约定走 changelog）
+> 端类型：管理后台（订单详情·定制师侧「行程安排 → 住宿安排 → 联系房务」）
+> 日期：2026-06-22
+> 服务：hl-user-service（站内信聊天）、hl-order-service-v3（房务/订单详情）
+> 关联：2026-06-20《房务+定制师提房需求+站内信聊天 — 前端对接总览》模块三
+
+---
+
+## 一、现象（wx 反馈）
+
+订单详情页（`/order-v2/detail/{id}`，状态「配房·待配」、**房务尚未抢单**）点「联系房务」，右侧聊天面板显示：
+
+- 房务专员「**舒心**」
+- 状态「**● 在线**」（绿点）
+
+wx 判断是前端假数据。**经后端核实：判断正确**，下面给铁证 + 正确口径。
+
+---
+
+## 二、诊断结论（后端实证，逐条钉死）
+
+### 1. 「在线 / 离线」状态 = 前端写死的假数据 ✅（最确定）
+
+后端**根本没有「在线态」这个数据源**，且这是设计层面的缺失、不是某接口漏返：
+
+- 聊天三套出参 VO（`ChatOpenRespVO` / `ChatConversationRespVO` / `ChatThreadRespVO`）**没有任何 online / 在线 / presence 字段**。
+- 全 hl-user-service **没有任何「查在线态」的接口**。
+- SSE 服务（`AdminSseService`）的连接注册表**只用于消息推送**，是**单实例内**的、且明确仅供监控/单测（`getConnectionCount` 注释「供监控/单测断言用」），**不对外、不跨实例**——无法回答「某员工是否在线」。
+- 最直接的铁证：后端房务员工查询参数 `HouseStaffQueryReqVO.online` 的注释原文就是 ——
+  > `true=只看在线（当前无在线态来源，不生效）`
+
+  后端自己都标注了「**当前无在线态来源**」。
+
+→ 前端拿不到任何「在线」真值，绿点 100% 是写死的。**请去掉在线/离线指示器**（详见第三节）。
+
+### 2. 「房务专员（舒心）」在抢单前显示 = 不应出现（占位数据）
+
+- 「房务专员」= **抢单人（claimer）**。房务侧详情 `Claim{claimerId, claimerName, claimedAt}`、订单侧 `HotelRequirementBriefVO.claimerName` 都是**抢单后才有值**。
+- **抢单前 claimer 为空**——此时本就没有「房务专员」这个人。所以「配房·待配 / 未抢单」状态下出现具体房务专员姓名（且还带在线），即前端占位/mock。
+- 补充：本地 hl-ui（master 分支）里**没有这个聊天对话面板的代码**（近期是产品/班期/站内信铃铛），说明部署版在更新分支，这块是前端新原型里带进来的占位数据。
+
+---
+
+## 三、正确口径 / 前端应如何改
+
+1. **在线态**：后端无、且短期不会有（无 presence 系统）。**请移除「在线/离线」绿点**；要展示房务专员就只显示姓名/角色，不带在线状态。
+2. **联系房务按钮（抢单前）**：`claimerName` 为空时**按钮置灰 + 提示「等房务接单后可沟通」**；抢单后再显示真实房务专员姓名、按钮可点。
+3. **真聊天接入**：站内信 1:1 聊天后端已就绪（`/admin/message/chat/*` + SSE `im-chat`，见 0620 总览模块三）。**目前已打通并验证的是「房务工作台 → 定制师」方向**（房务从抢单池/我的接单列表卡片用 `consultantId` 开会话，#4101 已把 `consultantId` 补进列表 VO）。
+
+---
+
+## 四、反向「定制师 → 联系房务」要真对接的后端缺口（claimerId）
+
+截图这页是**反方向**：定制师在订单详情找**房务专员**聊。`POST /admin/message/chat/open` 需要 `peerAdminId`（这里=房务专员的 adminId）。但当前：
+
+- 订单详情对前端**只暴露 `claimerName`（姓名），未暴露 `claimerId`（房务专员 adminId）**（`ItineraryVO.HotelRequirementBriefVO` 只有 `claimerName`）。
+- → 前端**拿不到 peerAdminId，无法真正 open 会话**。这也是这个面板只能 mock 的根因之一。
+
+**处置**：若产品确认「定制师在订单详情联系房务」是要做的反向入口，后端需在订单详情补 `claimerId`（数据已有，房务侧 `Claim.claimerId` 即是，仅未透传到订单侧 VO）。**这是个很小的后端改动，需要时告诉我立刻加**（当前站内信/聊天整体在按新原型改造中，故先不预改、不挂跟踪单）。
+
+---
+
+## 五、要点速记
+
+| 元素 | 真相 | 前端动作 |
+|---|---|---|
+| ● 在线（绿点） | 后端无在线态来源（设计缺失，注释明写「不生效」） | **移除** |
+| 房务专员·舒心（抢单前） | 抢单前无 claimer，属占位 | 抢单前不显示，按钮置灰提示「等接单」 |
+| 真聊天（房务→定制师） | 已就绪并验证（consultantId 开会话） | 按 0620 总览模块三接 |
+| 真聊天（定制师→房务） | 订单详情缺 claimerId（peerAdminId） | 需后端补 claimerId（找我加） |