perf(lark): overlap completed stop source verification

[loopx-agent]

Completed Lark /stop receipts repeated an App identity request after resolving the current binding, serializing two provider IO phases. For a completed, target-frozen stop on a locally enabled group binding, read its exact source/root messages alongside fresh Core binding/App resolution, join both, then validate provenance and the current binding before delivery. Observations stay within one invocation; ordinary inputs, private conversations, unknown stop scope and explicit selections without an observation keep their existing paths.

Validation covers identity/source failure, changed App/root/ancestry, revocation during reads, original stop scope, replay/recovery, private/group isolation and the native listener. An alternating real-provider, unchanged-source read-only comparison measured ~3.4–4.0 s before and ~1.81–1.83 s after for this verification phase. The original end-to-end stop/web timing requirement remains separate and is not claimed as passed.

The owning bilingual RFC documents this default scheduling change. This adds no consumer, cache, persisted state, setting or permission. The related refactor extracts the existing completed-stop source correlation check into its Lark owner and reuses it for read scheduling and validation.

Six affected runtime modules: 265 passed; the strengthened four-case overlap/authority test also passed. The original implementation fails the overlap case, and removing the post-read grant check fails the revocation case. Configured mypy: 17 files passed; optional strict checking retains the same four baseline errors. Ruff and standard native premerge passed.

The actual reply worker adds two passed cases (normal and revocation during reads). The same worker fixture fails on the original sequential implementation; removing the post-read current-binding check makes it incorrectly send and complete after revocation.

[loopx-agent]

Reviewer: model_agent · gpt-6.1-sol · OpenAI · runtime_reported · reasoning_effort=max

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

APPROVE at 4c688cd060b84787512a000f1b1cfdf3463a0b44. This is an author-side model review; COMMENTED is used because GitHub disallows formal self-approval. It is not a human or independent-person approval.

动机

在群话题发出停止指令、等待原消息回执的用户。

旧路径先核验绑定身份，再并行读取原消息与重复核验身份，形成两段串行网络等待；此版本只对已经完成并固定原目标的停止请求，把原消息读取与当前绑定核验重叠，完成全部校验后才回传。

同一来源、授权和日志不变的真实 provider 交替只读对照，来源校验从约3.4–4.0秒降至1.81–1.83秒；原话题回执的发送和重试仍使用原工作池及去重日志。

本次不改变停止目标、不新增消费者或缓存、不增加设置和确认步骤，也不宣告完整停止时限或社区准出通过。

真实安装后的整条停止和网页时限仍需独立验收；此前完整回执超过既定时限的失败继续保留，完整社区黄金用例和隐私准出也没有由这个源码切口证明。

改动思路

两项只读观测可以在既有绑定的确切原消息范围内重叠，但任何一项的成功都不能代替当前授权；读取结束后的绑定复验阻止并发撤权被旧快照掩盖。

当前PR交付既有Lark停止回执的来源校验优化及真实回复工作池的撤权保护；正常安装、原话题整体验收和完整社区准出继续由现有社区交付任务承担。

直接删掉重复身份调用曾被实际对照否定：原消息读取仍串行，耗时仍约3.5秒。原生历史清单查询也不足以解释秒级等待，因此没有顺便重写原生控制或引入缓存。此版本把已持久固定的两条原消息作为只读预取范围，Core继续独立核验当前App与权限；两个结果全部就绪后再校验来源。身份变化不能变成发送许可，失败也不能被包装成“已停止”。

下表依据准确head 4c688cd060b84787512a000f1b1cfdf3463a0b44 的源码说明时序，属于解释示意，不代替执行证据：

场景	原路径	此版本
已完成且原目标已固定的群停止	身份检查后，再并行读取源消息和重复查身份	只读原消息与当前Core/App检查重叠
读取期间绑定撤回	不能把旧观测当现权限	读完重读绑定，不匹配就拒绝发送
普通输入、本人私聊、未知原范围	既有路径	保持既有路径
任一来源/身份不可用	原请求未确认	同样未确认，使用原恢复owner

具体改动

四个文件共 189+/22-。运行逻辑只在既有Lark provider；两个RFC镜像说明默认时序，既有测试文件补实际回复工作池轨迹，没有新增用户配置、公共协议或持久状态。已有可选观测字段继续由Core生成，不从HTTP或消息文字接入“已核验”声明。

1. _completed_stop_root：把已有Core请求与消息/绑定的对应关系收拢成一个私有读调度谓词。它只选择原两条消息，不能授权发送或改变停止目标。
2. _source_message：仅符合原范围时并行读取；fresh Core resolution、两条provider消息、读后绑定、来源、关联和根提及全部通过才返回可用证据。显式选中但未带观测的内部调用继续重新查身份，没有跨调用缓存。
3. _deliver：维持原Inbox发送/回执owner。新增测试通过 reconcile_request 的实际回复工作池调用它，核对合成provider收到的实际发送调用和持久terminal回执，覆盖成功与撤权失败。

规范依据：docs/architecture/rfcs/app-conversation-and-async-inbox-v0.md，接受的变更前不可变版本 dededb6174c3768fed55b67cb1e4ea3f4fbbce52，原107–141行。以下为无编号原条款的描述标签；新增说明只解释实现时序，没有把新实现改写成自己的验收标准。

criterion_id	本head处置
original-source	implemented：原provider消息/root及当前权限决定可否回传；读取中撤权、不同App和关联错误都拒绝。
frozen-stop-scope	implemented：仍使用原Core target_recorded 与确切source，不改Session/Turn目标，不把后来工作纳入旧stop。
separate-adoption-exits	deferred：真实安装、整条stop/web时限与完整社区包由现有交付owner继续，不由来源阶段计时替代。

对主干的风险

最危险的是并行读期间的撤权被旧快照掩盖。最终工作池用例先让fixture身份观测完成，再持有读结果、撤权并释放，确保不会靠“观察时已经找不到绑定”掩盖竞态。固定实现不发送且terminal未核验；刻意删掉读后复验时，完全相同的回复工作池会错误发送并返回完成，测试1 failed。原实现无法让两个读阶段同时开始，同一正向工作池fixture也1 failed；当前两个工作池用例都通过。

六模块265项通过。最终加强的四项身份/来源/撤权oracle及新增两项真实回复工作池用例另行通过；最后提交只加测试，运行代码blob与首提交一致。标准native premerge准确head的6项直接和11项选中检查通过；Ruff及配置mypy17文件通过。可选strict检查保留与不可变base同身份、同完整详情的4个旧Any-return错误；没有宣称全仓strict通过。按当前策略未获取、轮询或等待远端CI。

交替真实provider只读对照使用同一已完成请求、source/root和授权，三组base约4.04/3.40/3.51秒，head约1.83/1.81/1.82秒，原授权与日志字节不变。这只证明来源核验阶段的改善，不是p95、原生进程停止时间或安装后完整消息/网页时延。合成provider及native协议也不能替代真实安装旅程。所有先前失败、未跑及完整准出缺口继续保留。

我的整体评价

APPROVE，交付判断 justified_increment。两项只读观测可以在既有绑定的确切原消息范围内重叠，但任何一项的成功都不能代替当前授权；读取结束后的绑定复验阻止并发撤权被旧快照掩盖。

当前PR交付既有Lark停止回执的来源校验优化及真实回复工作池的撤权保护；正常安装、原话题整体验收和完整社区准出继续由现有社区交付任务承担。

用户仍只发送原来的停止指令，额外必需的人类语句、确认、复制已知信息和导航均为零。持续执行、回执去重和失败恢复仍由原owner负责；观察到来源核验阶段等待减少，同时没有把“拿到结果”错写成“有权发送”。未来重构检查已落实到一个相关的谓词抽取，避免在预读和校验处复制原范围判断；没有为了追求时延加入另一层缓存、消费者或状态机。整体stop时限仍是后续验收责任，不能用此PR的通过覆盖它。

English verdict: APPROVE this bounded completed-stop source-verification optimization. The actual reply-worker counterfactual catches post-revocation sends; controlled real-provider reads demonstrate a faster verification phase. Existing scope, freshness and Inbox recovery remain, while installed total timing and complete community release acceptance stay separate.