docs: changelog for #8166 AC-8/AC-9/AC-10/AC-17 frontend delivery

Co-Authored-By: Claude Haiku 4.5 <noreply@anthropic.com>

changelogs-v2/2026-09/23_8166_消息bizType路由契约交接-前端缺陷-管理后台.md

@@ -0,0 +1,94 @@
+---
+schema: "hl-changelog/v2"
+ticket: "8166"
+title: "通知消息bizType路由与bizId语义契约交接"
+consumer: "admin"
+author: "wx(GIT)"
+change_type: "前端缺陷"
+backend_status: "not_required"
+gateway_status: "not_required"
+frontend_status: "pending"
+frontend_owner: ""
+frontend_ref: ""
+target_release: ""
+verified_at: ""
+status_note: "关联工单#8166（bizType/bizId契约漂移）的前端交接件。后端已就绪，前端按本件调整三处routing逻辑。"
+updated_at: "2026-09-23"
+base: "dev-v3"
+---
+
+# 通知消息 bizType 路由与 bizId 语义契约交接
+
+关联工单：[#8166](https://git.1814.love:8443/wx/HL/issues/8166) bizType/bizId 契约漂移定案
+
+## 一、白名单兜底：未知 bizType 的处理
+
+**问题现状**
+
+当前 `hl-ui/src/views/notification/MyMessages/jumpBiz.js` 的路由逻辑依赖 `else` 分支做兜底，即只要 bizType 不属于已知分支，就默认按 orderId 路由到订单详情页。这意味着：**新增一个 bizType 时，若前端未同步修改路由逻辑，该消息会静默跳转到错误的订单页面**（业务维度错配，用户不可见）。
+
+**前端改动**（共3条，均为必须落地）
+
+1. **显式白名单兜底**：修改 `jumpBiz.js` 的 `else` 分支，改为：仅对已知携带 `orderId` 的 bizType（`ORDER`、`HOUSE`-CHAT、`HOUSE_LEAD`、`GROUP`、`FLEET`）才按 orderId 路由。新增或未定义的 bizType 不入此列。
+
+2. **未知 bizType 不给跳转**：对于白名单外的 bizType，`canJumpToBiz()` 返回 false，**不渲染跳转按钮**，而非跳到错的地方。失败从「隐形」变成「可见」。
+
+3. **团期级 bizType 路由修正**：`GROUP_HOUSE`、`GROUP_FLEET`、`GROUP_BATCH` 这三个 bizType 对应团期维度的会话，其 bizId 是 `groupBatchId` 而非订单 ID。这些类型应路由到**团期详情页**（`hl-ui/src/views/order-v2/batch/detail/`，已存在页面）而非订单详情页。
+
+## 二、AC-9 定案：不补传充字段
+
+**后端定案内容**
+
+`hl-user-service` 的 `AdminMessageRespVO` **不补** `peerRole` / `senderRole` 字段。
+
+**原因分析**
+
+前端当前的 `index.vue:282-287` 有一条路由分支判断 `peer === 'CUSTOMIZER' && (mod === 'HOUSE' || mod === 'HOUSE_LEAD')`，该 `peer` 从 `row.peerRole || row.senderRole || ''` 取值。但：
+
+- `senderRole` 在定制师广播时**恒为 NULL**（定制师作为消息发送人时，系统记录的 sender_role 为空）
+- 后端接口从未返回过这两个字段（`AdminMessageRespVO` 实有15个字段，无此二者）
+- 补了这两个字段等于交付一个在目标场景下永远答不上来的契约
+
+**处置**
+
+mmg 请根据以下情况处理：
+
+1. **删除死代码**：`hl-ui/src/views/notification/MyMessages/index.vue` 的第3层路由分支 `peer === 'CUSTOMIZER' && (mod === 'HOUSE' || mod === 'HOUSE_LEAD')` 目前恒不触发，建议删除。
+2. **确认字段缺席**：`row.peerRole`、`row.senderRole`、`row.bizModule`、`row.requirementId` 这四个字段后端接口**从未返回过**。若业务需要「房务会话行定向跳到房务订单页」的功能，需另行设计接口补充所需数据。
+
+## 三、AC-10 CHAT 通道 bizId 语义契约
+
+**新增书面契约**
+
+后端通过 CHAT 通道（对应 `admin_message.kind = 'CHAT'`）发送的消息，bizId 的语义如下：
+
+| bizType | bizId 实际值 | 含义 |
+|---------|-----------|------|
+| `HOUSE` | orderId | 房务订单ID |
+| `HOUSE_LEAD` | orderId | 房务主单ID |
+| `FLEET` | orderId | 车务订单ID |
+| `GROUP` | orderId | 订单ID（团期订单） |
+| `GROUP_HOUSE` | groupBatchId | 团期房务批次ID |
+| `GROUP_FLEET` | groupBatchId | 团期车务批次ID |
+
+该契约原仅存在于代码注释（`ChatManager.java` / `TeamChatModule.java`），现升级为书面交接件。
+
+## 四、覆盖边界与已知约束
+
+### bizType 清单的完备性
+
+后端 `AdminNotificationController.java` 的 `.eventCode(config.getEventCode())` 是**运行时入参**，可发送 `notification_event_config` 表里**任意一行**对应的事件码。因此：
+
+- **任何静态枚举的 bizType 清单都只是下界**，不是全集
+- 前端的白名单兜底**必须按「未知即不跳」实现**（不能继续假设 else 分支永远指向 orderId）
+- 新增后端 bizType 时，若不在已知白名单内，前端无需修改代码，消息的"跳转按钮"会自动置灰
+
+### 一期 v2 与二期 v3 的产出范围
+
+本契约针对二期（`hl-order-service-v3` / `hl-fleet-service` / 生产尚未上线）的建立。一期 v2 在生产上的行为遵循此前的隐式约定，后续统一时另行协调。
+
+## 五、关联
+
+- Issue：[#8166](https://git.1814.love:8443/wx/HL/issues/8166)
+- 后端对应工单：#8166（bizType/bizId 契约漂移）
+- 后端联系人：@wx