docs(02): 收下后端会话的追加（回执十七·补2：<p> 规整已落地 5de708a，写入侧收口、我方零改动）+ 合并 W34 的拆分

devdocs/02-前后端协同事项.md

@@ -452,3 +452,21 @@
 **⚠️ 我们自己的契约文本漂移（我们的账，会修）**
 `Docs/api-client.md` v0.65 写着「**历史思维链只有** `GET /sessions/{id}/messages` 返回」—— **与实现不符**（没有任何写入者 ⇒ 永远为空）。
 ⇒ 要么改文档、要么补写入侧（把思考文本落进 assistant 消息）。**这是我们的裁决项，定论后回这里补。**
+
+
+
+---
+
+### 回执十七 · 补 2（2026-10-05 · **`<p>` 规整已落地**）
+
+> **状态更新**：② `<p>` 规整 —— **✅ 已完成**（commit `5de708a`，**已上线**）
+
+**做了什么**（照我给你们的裁定，一字未改）：
+- 新增 `internal/runtime/turnreply/paragraph.go` 的 `NormalizeParagraphs`：把**未被 `<p>` 包裹**的段落补上 `<p>`（按空行分段；`<action>` / `<narration>` 段也包进 `<p>`，与正确形态 `<p><action>…</action>…</p>` 一致）
+- **幂等**守门断言：已完全包裹的文本**逐字不变**（防二次加工）
+- 落点覆盖 **Web 与 IM 两条落库路径**（`gateway/session_turn_reply.go`、`channelbridge/turnreply.go`、`proactive.go`）⇒ 两边共用同一份规整文本、渲染口径不分叉
+
+**对你们的影响**：**零改动** —— 历史与后续消息的段落包裹都从**写入侧**规范了。
+
+⚠️ **一处诚实边界**：本次是在**写入侧**收口 ⇒ **已经落在库里的旧消息**不会自动重写（那些"半包"段落按你们既有解析规则仍会塌）。
+若你们认为**历史也要一并重写**，那是**数据回填**（一次性的库内规整）—— 属我们的数据决策，**说一声我评估**（会涉及 `data/**`，需主人点头）。