docs(05): 补记二十四附——本轮两个决定（P1 主动消息消费我方接、tool_execution 选 a 并要 toolCalls[] 回看面带输出）与推送暂不接的口径

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

@@ -1369,3 +1369,8 @@ curl -s -X PATCH "$BASE/api/v1/sessions/$SID" -H "Authorization: Bearer $TOK" \
 >
 > ### 已派单核实
 > **只读排查**（`agent-8qtm01gd`）就为这两条取证并给出建议：问题一的「帧画的 vs 历史拉的会不会被按 id 合并成一条」（以及最小修法），问题二的「`.start`/`.update`/`.end` 三档各自是否解析 / 是否消费」以及**只发 start/end 时工具卡够不够用**。
+
+> ### 附：本轮回后端的两个**决定**与一个新 P1（补记二十四处）
+> **① P1（我方接）：主动消息实时看不到。** 核实结论：`proactive_message` 帧我们**只解了错的 id**（`messageId`，而落库行是另一个 `id`；`ignoreUnknownKeys` 把新 `id` 静默丢弃），且**整帧零消费**（`ChatViewModel.onEvent` 无该分支）⇒ **「显示两次」不会发生，但「实时看不到她主动说的话」是真缺口**（只能等重连/重开/切会话拉历史）。修法位置已定（`WsEvent.ProactiveData` 补 `id`/`createdAt` + `ChatViewModel` 加分支，**按已落库 assistant 行并入 `mergeMessages`**，**必须自己钉死主会话**——该帧壳**不带 `sessionId`**，否则会窜进每个次级会话）。
+> **② `tool_execution` 口径：选 (a)**（只认 `.start`/`.end` 按 `id` 关联；**不要他们补 `.update`**）。取舍已明确：**没有 `.update` ⇒ 工具卡的结果区是空的**（`ToolCallState.output` 只由 `.update` 的 delta 追加）⇒ **我们真正要的是他们已认领的「持久化 `toolCalls[]` 回看面」**，并请求把输出/摘要一并带上。
+> **③ 移动端推送：暂不接**（等主人自建）。并已告知他们：他们建议的「应用内提示」`message_persisted{proactive:true}` 在我们这边**零实现**（`PersistedData` 只读 `message`；客户端无任何 Notification 代码）⇒ **那条建议目前不产生任何效果**，别当兜底。