[loopx-agent]

飞书私聊有时先投递省略话题 ID 的事件，重连后再补投带完整字段的同一消息。App 需要已保存的话题 ID 才能把核验过的节选和原消息对应起来。旧逻辑只有在取得可展开的历史节选时才保存核验到的话题 ID。嵌套回复只有直接父消息的引用时，完整重投会因此报来源冲突。

现在，原接收服务在接受消息前保存已核实的子话题 ID。App 继续按原会话展示正文、直接引用和飞书实际提供的节选。同一消息的精简和完整重投沿用原请求，只执行和回传一次。父消息或话题 ID 发生冲突，或飞书详情无法核实后来补报的 ID 时，继续拒绝该次重投。

作者为 Codex（OpenAI）。实现依据是此 PR 中复现的飞书精简事件、原会话 HTTP 读回和重投去重行为。

验证	结果
真实本地入口	9 项定向用例通过。旧实现的嵌套精简事件用例失败，修改后通过。覆盖普通引用、两种重投格式、缺失及冲突 ID、原 HTTP 读回和单次回传。
静态检查	Ruff 和 diff 检查通过。
标准合并前检查	6 项直接检查和 13 项相关检查通过。

本轮验证提交为 2cdbe61b9acff4a7af55cc87d283168f24237452，使用隔离的飞书样本和原本地入口。线上 CI、维护者评审和实际安装后的双端验收仍待完成。

[loopx-agent]

Approval conclusion (author-owned PR; GitHub blocks formal self-approval)

Reviewer: model_agent, GPT-6 family, OpenAI, self_reported

Reviewed head a6ce3a323bb32947319bf5efb9306c6a14b7cfce

动机 / Motivation

用户在已授权的飞书私聊引用前文，再到 App 查看同一个会话。精简事件有父消息和根消息，却可能省略话题 ID。旧版已读到真实话题节选，但 App 校验找不到已记录的话题 ID，于是丢掉引用。原服务核对飞书详情后，在同一次写入里保留话题 ID 与引用快照。App 能读回原问题、父消息和话题节选，重复事件仍绑定同一个请求。

本次限定在新采集的原私聊引用。旧引用补齐和线上采用分别验收。线上仍待合并和原服务采用。已有请求缺失的引用快照需要另行按原消息核实。

改动思路 / Approach

原飞书适配器负责核实和冻结引用，原 App 读回继续使用持久的消息关系，Core 负责已接收的请求。只接纳原私聊中经飞书核实的缺省话题 ID。 原入站已经读取并校验飞书详情。复用现有的原子写入和 App 校验，避免在 App 读回时额外查询或放宽引用归属条件。

具体改动 / Changes

关键代码讲解

• _reply_context_message 先校验原消息、发送者、私聊和父/根消息。只有飞书原详情确认话题且拿到节选时，才与原引用一并保存缺省的话题 ID。
• admit 在已有原私聊引用时接受省略话题 ID 的重复事件。其余身份字段继续逐项比较，显式冲突返回 source_conflict。
• project_private_reply_history 继续按原有关系验证 App 读回。原用户正文、父消息及话题节选从同一请求读出。
• 回归用例 经真实私聊适配器、Core 与 App HTTP 验证两种入站形态、重启重投和原话题的一次回传。飞书与 native executor 使用隔离 fixture。

按 docs/architecture/rfcs/app-conversation-and-async-inbox-v0.md（基线 32167518b3c2646fd9b6a3a6e0aaf74b258a7b70）核对。original-private-quote 和 stable-redelivery 已有回归证据，live-original-conversation 待原服务采用后验收。生产 17 增 2 删，测试增 38 行，双语 RFC 增 10 行。

对主干的风险 / Risks

若把不同话题、不同正文或不同受众当成同一次重复事件，可能展示错误引用或混淆原回复。 测试里省略 ID 的重复到达沿用原请求，显式冲突被拒绝，原话题只有一次回复。旧版用同一测试复现两处失败，分别是 App 没有引用和重复事件误报冲突。当前 head 的 48 项相关回归及 quick 合并前检查通过。验证覆盖实际 App HTTP 返回的用户正文和引用字段，未执行浏览器视觉测试。

语义与 CI 对齐

沿用原会话权限、原消息身份、既有持久字段与原投递。当前验证覆盖本地精确 head。远端合并门与原服务采用各自验收。

我的整体评价 / Verdict

引用正文和话题关系可以随原会话恢复，重复到达后仍保留一次执行与回传。该改动用现有适配器与读回约束解决漏展示，影响范围与缺口相符。上线采用和旧历史补齐仍待验证。

English verdict: APPROVE. The exact head retains the provider-verified optional topic ID for App quote readback and preserves same-message redelivery. Live adoption and historical backfill remain unverified.

[loopx-agent]

Approval conclusion (author-owned PR; GitHub blocks formal self-approval)

Reviewer: model_agent, GPT-6 family, OpenAI, self_reported

Reviewed head 476c9d08391340fe8531c894bea113a1c7c8a0dd

动机 / Motivation

用户在已授权的飞书私聊引用前文，再到 App 查看同一个会话。精简事件有父消息和根消息，却可能省略话题 ID。旧版已读到真实话题节选，但 App 校验找不到已记录的话题 ID，于是丢掉引用。原服务核对飞书详情后，在同一次写入里保留话题 ID 与引用快照。App 能读回原问题、父消息和话题节选，重复事件仍绑定同一个请求。

本次限定在新采集的原私聊引用。旧引用补齐和线上采用分别验收。线上仍待合并和原服务采用。已有请求缺失的引用快照需要另行按原消息核实。

改动思路 / Approach

原飞书适配器负责核实和冻结引用，原 App 读回继续使用持久的消息关系，Core 负责已接收的请求。只接纳原私聊中经飞书核实的缺省话题 ID。 原入站已经读取并校验飞书详情。复用现有的原子写入和 App 校验，避免在 App 读回时额外查询或放宽引用归属条件。

具体改动 / Changes

关键代码讲解

• _reply_context_message 先校验原消息、发送者、私聊和父/根消息。只有飞书原详情确认话题且拿到节选时，才与原引用一并保存缺省的话题 ID。

• admit 在已有原私聊引用时接受省略话题 ID 的重复事件。其余身份字段继续逐项比较，显式冲突返回 source_conflict。

• project_private_reply_history 继续按原有关系验证 App 读回。原用户正文、父消息及话题节选从同一请求读出。

• 回归用例 经真实私聊适配器、Core 与 App HTTP 验证两种入站形态、重启重投和原话题的一次回传。飞书与 native executor 使用隔离 fixture。

• 打包 App 夹具 让精简事件经过原飞书适配器冻结引用，再从原连接进入 App。旧的已冻结种子仍可用于兼容性对照。

按 docs/architecture/rfcs/app-conversation-and-async-inbox-v0.md（基线 32167518b3c2646fd9b6a3a6e0aaf74b258a7b70）核对。original-private-quote 和 stable-redelivery 已有回归证据，live-original-conversation 待原服务采用后验收。生产 17 增 2 删，Python 回归增 38 行，浏览器夹具 61 增 19 删，双语 RFC 增 10 行。

对主干的风险 / Risks

若把不同话题、不同正文或不同受众当成同一次重复事件，可能展示错误引用或混淆原回复。 测试里省略 ID 的重复到达沿用原请求，显式冲突被拒绝，原话题只有一次回复。旧版用同一测试复现两处失败，分别是 App 没有引用和重复事件误报冲突。当前提交的 25 项定向回归及 quick 合并前检查通过。相同的打包 App 检查在基线显示内部封装，在候选版显示原正文和独立引用。桌面、窄屏、键盘及英文读回通过。浏览没有新增模型 Turn 或改写原记录。既有已冻结引用和备用执行器路径也通过。

语义与 CI 对齐

沿用原会话权限、原消息身份、既有持久字段与原投递。当前验证覆盖本地精确 head。远端合并门与原服务采用各自验收。

我的整体评价 / Verdict

引用正文和话题关系可以随原会话恢复，重复到达后仍保留一次执行与回传。该改动用现有适配器与读回约束解决漏展示，影响范围与缺口相符。打包 App 中原正文优先显示。展开后原引用和较长的话题节选分开，桌面与390像素窄屏均保持可读。原服务采用、生产桌面 App、实际飞书双端读回和旧引用回补仍待验。

English verdict: APPROVE. The exact head retains the provider-verified optional topic ID for App quote readback and preserves same-message redelivery. Live adoption and historical backfill remain unverified.