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 / 回滚点在哪 / 跑的时间。