docs(changelog): 房务管家操作日志 operator 渲染前端项(#4237) — 渲染 operator.name 而非整串 JSON

changelogs-v2/2026-06/22_4237_房务管家订单详情抢单池_渲染缺口+抢单门控_房务前端.md

@@ -38,6 +38,25 @@ wx 评审房务管家发现多处「前端渲染不全 / 交互缺门控」。**
 - **内部留言计数**：`tabCounts.messageCount` 由恒 0 改为计入定制师需求（=1）。实测 `messageCount=1`。
 - **H 留言空态对齐（前端）**：既然口径是「定制师需求算 1 条留言」(messageCount=1)，内部留言区**别再显「该订单暂无内部留言」**（与 count=1 自相矛盾，且该文案是前端写死，后端不返）。正确：把「定制师需求」当作**第 1 条留言**展示；真正空态只针对**抢单后**房务↔定制师聊天那部分——抢单前聊天关闭，可显「抢单后可与定制师沟通」之类引导而非笼统「暂无内部留言」。
 
+## 6. 操作日志「操作人」别打整串 JSON，渲染 `operator.name`（前端 bug，可立即接）
+
+**现状**（订单详情弹窗 → 操作日志 Tab）：操作人显示成
+`by { "userId": "2037350531801993218", "name": "腰苏图" }`
+—— 把后端返回的**结构化 `operator` 对象**整个 `JSON.stringify` 打了出来。
+
+**后端正确**（实测 `GET /v3/admin/house/orders/{orderId}/operation-log` → `data.records[]`）：每条 `operator` 是结构化对象 `{ userId, name }`，`operator.name` 已是干净姓名「腰苏图」：
+
+```json
+{
+  "opType": "REQUIREMENT_SUBMIT",
+  "opTypeLabel": "定制师提交需求",
+  "summary": "定制师提交房型需求 v1",
+  "operator": { "userId": "2037350531801993218", "name": "腰苏图" }
+}
+```
+
+**前端**：操作人只渲染 `operator.name`（→「腰苏图」/「by 腰苏图」），**别 `JSON.stringify(operator)`、别直接把对象插进模板**。`operator.userId` 仅用于跳详情/排查，不展示。其余照常：`summary` 后端已拼好直接显示、`opTypeLabel` 当中文徽标、`time` 当时间。
+
 ---
 
 ## 说明（非 bug）