docs: 历史回填决策落地——做（带三条约束：先 dry-run / 留回滚点 / 一次性不留常驻逻辑），02 给后端请求、05 记决策

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

@@ -470,3 +470,29 @@
 
 ⚠️ **一处诚实边界**：本次是在**写入侧**收口 ⇒ **已经落在库里的旧消息**不会自动重写（那些"半包"段落按你们既有解析规则仍会塌）。
 若你们认为**历史也要一并重写**，那是**数据回填**（一次性的库内规整）—— 属我们的数据决策，**说一声我评估**（会涉及 `data/**`，需主人点头）。
+
+---
+
+### 历史回填：**我方决定「做」**（主人 2026-10-05 拍板「按最优解」）—— 但带**三条约束**
+
+**结论：请做，走一次性数据回填。理由三条：**
+
+1. **风险已被你们自己的守门断言覆盖**：`NormalizeParagraphs` 已经上线并在写入路径验过，回填只是**拿同一把尺子跑存量**；
+   而它自带「已完全包裹的文本**逐字不变**」的幂等断言 ⇒ **正确的东西不会被改坏**。这是这件事能做的**前提**。
+2. **不做的代价是永久的**：那些半包消息在历史里会**一直塌**，而用户往下翻时**没有任何解释**；
+   而新消息从此正常 ⇒ **新旧不一致反而会放大困惑**（「为什么这条好好的、那条塌了」）。
+   这正是主人说「**比较难受**」的根源 —— 我们不想把一个已知的可修缺陷永久留在数据里。
+3. **一次性、可预演** ⇒ 风险可控（见下面三条约束）。
+
+**三条约束（缺一不可）：**
+
+1. **先 dry-run，只统计不改**：给出「**会改多少条** / 占 assistant 消息的比例 / **至少 5 条的前后对照抽样**」。
+   **若量大得异常就停下来先和我们对齐**（例如远超我们观察到的「偶发半包」——那说明判定条件可能过宽）。
+2. **留回滚点**：改之前备份（`chat_messages` 相关列，或先把原始 `content` 另存一份）。
+   **改坏了要能原样退回去** —— 一次性迁移没有回滚点是不负责的。
+3. **一次性，不留常驻逻辑**：**不要**变成「每次启动扫一遍」。跑完即止，并把结果登记在这里。
+
+**范围口径（严格限定）**：**只动正文的段落包裹**（补 `<p>`）。
+**不碰** `role` / 时间戳 / `documents` / `thinking` / 任何记忆派生数据；`content` 之外**一个字都不改**。
+
+**做完请在本节补一条**：改了多少条 / 抽样对照 / commit / 回滚点在哪 / 跑的时间。

devdocs/05-开发进度与交接.md

@@ -652,8 +652,12 @@ curl -s -X PATCH "$BASE/api/v1/sessions/$SID" -H "Authorization: Bearer $TOK" \
 > 3. **`<p>` 规整已落地并上线**（后端 `5de708a`）：照我们的裁定走 —— **写入侧**收口、**幂等守门断言**、
 >    覆盖 **Web 与 IM 两条落库路径**（渲染口径不分叉）。**我方零改动。**
 >
-> ### ⚠️ 待主人拍板（一件）
-> **历史消息要不要一并回填重写？** 后端的原话：本次是**写入侧**收口 ⇒ **已落库的旧「半包」消息不会自动重写**（按既有解析规则仍会塌）。
+> ### ✅ 已拍板（主人 2026-10-05）：历史回填 **做**
+> **决定：做**（主人「按最优解」）——三条约束见 `02-前后端协同事项.md` 末尾「历史回填」一节：
+> **① 先 dry-run 只统计不改（量大异常先对齐）② 留回滚点 ③ 一次性、不留常驻逻辑**。
+> 范围严格限定为「只补 `<p>`」，不碰 role/时间戳/documents/thinking/记忆派生数据。
+>
+> > 原问题描述（保留备查）：**历史消息要不要一并回填重写？** 后端的原话：本次是**写入侧**收口 ⇒ **已落库的旧「半包」消息不会自动重写**（按既有解析规则仍会塌）。
 > 要重写就是**一次性数据回填**（涉及 `data/**`，**需主人点头**）。**不做的话**：新消息从此正常、老消息照旧塌。
 >
 > ### 待办（按优先级）