[loopx-agent]

App inputs accepted into an existing owner-private Lark Session ran through Core but had no Lark outbox, so the original chat never received those inputs or answers. Project the committed canonical text through the existing reply workers and persist each provider attempt; no extra listener, Session, model run or input replay is created.

Each send rechecks the current Core binding/audience and original provider source. Distinct messages and rich-post parts retain distinct idempotency identities even when their text repeats. Recovery verifies known receipts and holds a write whose provider locator was lost. Existing senders keep their receipt digests. Both RFC translations document activation through Settings → Lark → Continue original conversation, revocation, recovery and the primary-source design comparison.

Validation: the private-conversation suite passed 219 tests; after the final label and two additional negative cases, all five App projection journeys passed. The 116 outbound/Markdown/parts/source-authority regressions and risk-based premerge passed. The same real-HTTP/Core journey fails against the pinned pre-change installed source because no projection is delivered. The long-result test reconstructs and compares the full 216 KB text after removing only transport part markers.

Scope: text projection from the exact existing owner-private Session. Default App steward navigation, reply/thread relationship mirroring and attachment transfer remain open in the original sync task. Attachments retain an explicit partial-delivery state. This is source qualification; installed provider adoption/readback will be verified after the authorized merge.

[loopx-agent]

Reviewer: model_agent | GPT-6 | OpenAI | self_reported

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

动机

使用同一私聊的 App 与 Lark 的本人用户。用户在原 Lark 会话的 App 入口发出消息，原先模型已经回答但 Lark 没有对应消息；现在原发送器逐条投递已提交正文，并核对回执。已验证同文不同消息、完整长正文和重启恢复的文本投递，不增加模型执行。不在此 PR 合并默认管家入口、镜像回复关系或传输附件。默认 App 管家入口、回复/话题关系和附件仍由同一同步任务继续，安装态原服务读回另验。不修复会使用户重复发问，甚至重新执行已经做过的业务；这一 PR 的价值是补齐可恢复的文本送达，而不是用一次成功回执宣称整个同步需求完成。

改动思路

复用 Core 的会话、授权和队列，只给不可推导的 provider 写入回执增加本地 outbox；另建消息消费者或模型执行器反而增加重复执行风险。当前 PR 交付已有本人私聊确切 Session 的文本投递与恢复；保留默认入口、关系和附件的原任务验收。App 仍通过原单输入框进入同一 Core 队列。新增扫描只读该会话已提交的消息，原 Lark 请求仅提供地址证据；真正的执行与授权仍由原 owner 决定。每条消息使用自身身份，长内容再派生分段身份，原发送器负责格式和实际 provider 读回。未确认发送停在原记录上，不生成第二条输入。这也比增加 Matrix 服务或只保留“最后目的地”更适合当前已存在的双端会话。

具体改动

独立规范依据为 docs/architecture/rfcs/app-conversation-and-async-inbox-v0.md，spec_revision 69f876f9c95c624cbf7ea95a19bc218202575890，读取的是改动前版本；新增双语检查点用于披露范围，不用于倒推验收。original-owner-continuation 与 one-core-executor 在本提交实现，installed-return-exit 保留安装态验收，随后还需默认入口、关系与附件的原任务工作。

关键代码讲解

_web_projection_paths 从确切已启用本人来源发现 canonical Web 消息，进程内文件观测仅跳过未变文件，重启可重新推导，不能授予发送权限。_reconcile_web_projection 在每次效果前重查 Session、Core 受众及原来源，再复用 _deliver。_deliver_lark_inbox_outbound 只对提供 delivery_id 的调用增加身份维度，既有回执保持旧 digest。_part_identity 为每个富文本分段派生稳定身份，避免相同分段被 provider 幂等键误合并。五条真实 HTTP/Core 加合成宿主/provider 的旅程验证同文不同消息、完整长文、已知与未知回执、重启、撤权及身份替换。

对主干的风险

最强反例是 provider 已写入但丢失响应，或者两条消息正文完全相同。测试让合成 provider 真正按幂等键去重，并模拟实际写入后丢失响应；恢复保留未知发送，不再发一次，也不启动模型。长正文先发现按段计数不能证明完整，最终测试去掉传输序号后逐字符比较原正文，原分段机制无需修改。219 条会话回归、116 条发送/富文本/来源回归、最终五条旅程及标准 premerge 已通过；当前配置不读取或等待 CI。合入的主干增量仅涉及 Pi，相关源码与 fixture 内容未变。仅凭合成 provider 仍不能证明实际 Lark 接收或 UI 显示，安装态门禁继续保留。附件明确标为部分同步，回复和时间线回插不在本次交付中。

语义与 CI 对齐

新增状态是 provider 私有 outbox 与不可推导的远端回执；canonical 会话和 Core 授权没有第二个 owner。可选身份保持既有调用者语义。语义 advisory、双语 RFC 检查、编译、风险 canary 及公开边界检查均通过，没有放宽预算、硬门禁或来源检查。

我的整体评价

long_horizon 与 user_experience 在本次文本范围内改善：恢复不重复业务，用户无需重发或再确认即可沿原会话收到文本。未改前端布局或 renderer；已检查原会话入口、未变 Markdown serializer 和新增发言者文字，实际 Lark 展示仍待安装验收。复用 Core 的会话、授权和队列，只给不可推导的 provider 写入回执增加本地 outbox；另建消息消费者或模型执行器反而增加重复执行风险。当前 PR 交付已有本人私聊确切 Session 的文本投递与恢复；保留默认入口、关系和附件的原任务验收。新增机制属于既有 provider 边界，旧回执的兼容有真实持久恢复义务。结论为 APPROVE 的 author-owned COMMENTED 记录；它不等于 GitHub 自我批准，也不关闭原完整同步任务。

English verdict: APPROVE as a bounded, source-qualified text-delivery increment at 8e47f04a1767205452b1a906d55d842a6d8f4899. The existing Core remains the only executor and authority owner. Unknown effects stay fenced; default navigation, reply/media parity and installed provider acceptance remain explicit gaps.