diff --git a/devdocs/02-前后端协同事项.md b/devdocs/02-前后端协同事项.md index 312c226..939c3a1 100644 --- a/devdocs/02-前后端协同事项.md +++ b/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. **一次性,不留常驻逻辑**:**不要**变成「每次启动扫一遍」。跑完即止,并把结果登记在这里。 + +**范围口径(严格限定)**:**只动正文的段落包裹**(补 `
`)。 +**不碰** `role` / 时间戳 / `documents` / `thinking` / 任何记忆派生数据;`content` 之外**一个字都不改**。 + +**做完请在本节补一条**:改了多少条 / 抽样对照 / commit / 回滚点在哪 / 跑的时间。 diff --git a/devdocs/05-开发进度与交接.md b/devdocs/05-开发进度与交接.md index 75deaac..ee0c451 100644 --- a/devdocs/05-开发进度与交接.md +++ b/devdocs/05-开发进度与交接.md @@ -652,8 +652,12 @@ curl -s -X PATCH "$BASE/api/v1/sessions/$SID" -H "Authorization: Bearer $TOK" \ > 3. **`
` 规整已落地并上线**(后端 `5de708a`):照我们的裁定走 —— **写入侧**收口、**幂等守门断言**、 > 覆盖 **Web 与 IM 两条落库路径**(渲染口径不分叉)。**我方零改动。** > -> ### ⚠️ 待主人拍板(一件) -> **历史消息要不要一并回填重写?** 后端的原话:本次是**写入侧**收口 ⇒ **已落库的旧「半包」消息不会自动重写**(按既有解析规则仍会塌)。 +> ### ✅ 已拍板(主人 2026-10-05):历史回填 **做** +> **决定:做**(主人「按最优解」)——三条约束见 `02-前后端协同事项.md` 末尾「历史回填」一节: +> **① 先 dry-run 只统计不改(量大异常先对齐)② 留回滚点 ③ 一次性、不留常驻逻辑**。 +> 范围严格限定为「只补 `
`」,不碰 role/时间戳/documents/thinking/记忆派生数据。 +> +> > 原问题描述(保留备查):**历史消息要不要一并回填重写?** 后端的原话:本次是**写入侧**收口 ⇒ **已落库的旧「半包」消息不会自动重写**(按既有解析规则仍会塌)。 > 要重写就是**一次性数据回填**(涉及 `data/**`,**需主人点头**)。**不做的话**:新消息从此正常、老消息照旧塌。 > > ### 待办(按优先级)