docs(02): 把「标签包裹」从观察升级为明确请求——主人要求问「能不能修」，附三条可选路径与必须的裁定

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

@@ -2003,3 +2003,30 @@ document extracted           kind=text  chars=10
 **请你们确认**：这是**模型输出的 `<p>` 包裹不完整**吗？（即：本该每段都包 `<p>`，这次只包了最后一段。）
 若是 ⇒ 请在**产出侧**（persona 的分段约定 / 输出后处理）收口；我们这边**一个字节都不改**。
 若不是 ⇒ 请告诉我们应该按什么规则渲染，我们照办（但要**同时**对齐 Web 端，别让两个客户端渲染不一致）。
+
+### 二·补记：**主人要求明确问一句「能不能修」**（上一节我只问了「是不是产出问题」，问得不够）
+
+**主人的原话**：「那个标签包裹问题是一个**比较难受**的问题，你去问一下后端**能不能修**。」
+
+**所以这里是明确的请求，不是一个观察**：
+
+> **能不能在产出侧把 `<p>` 包裹收口，让每一段都带上 `<p>`？**
+
+**为什么值得修（不是洁癖，是实打实影响可读性）**：
+
+- 我方的解析规则（**与 Web 端对齐的既有口径**）是：**只要存在完整 `<p>` 块，就不再按空行回退切分**。
+  ⇒ 模型**漏包任意一段**，整条消息就会**塌成一段**（而不是按空行拆开）。
+- 而**「半包」恰好是最坏的形态**：如果他**全都不包**（纯裸文本），我们反而会按空行**正常拆成多段**。
+  ⇒ 现在的产出是「**一部分包、一部分不包**」，正好落在唯一会塌的那一侧。
+- 主人这两天报的「有一条消息没有拆分成多个气泡」就是它的表现，**而且这种半包在历史里不止一条**。
+
+**请你们给一个明确回答：能修 / 不能修**（不要只说"这是模型行为"就结束）：
+
+1. **能修** ⇒ 走哪条路？我们看到的可能方向（供参考，**由你们定**）：
+   - (a) **persona 的分段约定**里把「每段必须包 `<p>`」写死，并在产出后抽样校验；
+   - (b) **落库前做一次规整**：把 `<p>` 之外的裸文本段落**补上 `<p>`**（这会让历史也一次性变好，因为是在写入侧收口）；
+   - (c) 如果你们认为 `<p>` 本身就不该出现 ⇒ **反过来全去掉**，让客户端统一按空行拆 —— 但**必须两个客户端一起改**（我们与 Web 的渲染口径不能分叉）。
+2. **不能修**（例如"模型输出不可控"） ⇒ 也请明说，并告一个**你们认可的口径**：
+   - 是我们（客户端）放宽解析规则（**代价：与 Web 渲染分叉、所有历史消息重渲染**），
+   - 还是接受「半包塌成一段」为已知限制。
+   **我们要的是一个裁定，不是一个解释** —— 主人已经把它列为「比较难受」的问题，我们不能让它悬着。