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

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/**`，**需主人点头**）。**不做的话**：新消息从此正常、老消息照旧塌。
 >
 > ### 待办（按优先级）