[loopx-agent]

Problem and result

An original conversation with many delegated requests repeatedly verifies the same provider identity for every historical row. This makes the delegation panel time out even though the shared Core and source store are healthy. Scope verification now occurs before and after the read for every distinct original Session; it grows with sources rather than rows.

The response still checks each row’s current typed source basis, original host/Turn, target grant, Goal lifetime and live receipts. Older Sessions behind a reopened conversation get their own closing check. A binding/provider revocation before return refuses the entire response. No proof is retained across HTTP requests, and unreadable sources stay visible as incomplete coverage.

Validation

• 90 focused checks passed against disposable File/SQLite stores and native Core/provider fixtures. They cover paging, history, search, source damage, original receipt semantics, scope revocation both between reads and immediately before return, and privacy.
• The added baseline regressions fail on the prior implementation: 13 same-source rows cause 15 scope checks; the corrected read uses two, and a new page verifies independently. A reopened source also requires its own closing check.
• Exact-head risk-based premerge, bilingual RFC checks and the five-file public-boundary scan passed.
• Read-only installed-data probes returned in about 29 seconds. One pre-existing historical request lacks matching initial delivery proof and remains incomplete; this patch does not rewrite or replay it. These observations are not production p95, full synchronization or long-run qualification.

No UI layout, activation, persistent schema, sender authority, message consumer or scheduling changes. The existing App/browser panel uses this API; installed Core promotion and actual App readback follow review.

中文

原会话有较多历史委派时，同一来源的飞书身份核验被逐条重复执行，导致委派面板超时。本次将核验限定为每个原 Session 在一次读取前后各一次；逐条权限、原 Turn、Goal 生命周期和回执检查保留。结束前撤销授权会拒绝整份响应，证明不跨请求保存。合成原生 Core 与真实存储回归共 90 项通过，精确版本 premerge 和公开边界检查通过；真实数据只读探针约 29 秒返回。历史初次送达证明缺口继续保留，不通过重写回执或重放来消除。未新增服务、消费者、权限或配置。

[loopx-agent]

Reviewer: model_agent · GPT-6 · OpenAI · self_reported

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

动机

受影响的是在 App 或网页里查看原管家交办记录的用户。

同一个原会话积累多条交办后，旧实现为每条历史记录重新核验同一飞书身份，委派面板因此长期等待或超时；新实现按不同原会话在读取前后核验，已有记录可以返回。

可观察增量是委派读取不再随同一来源的历史行数重复做网络身份核验；13条记录的来源范围核验从15次变为2次，每一页仍重新核验。

本次不新增权限、服务、消息消费者、调度或持久化状态，不替接收者处理业务，也不声称完整媒体同步或历史证明缺口已经解决。

实际安装后的 App 面板读回仍须执行；一条历史记录的初次送达证明不匹配继续作为不完整覆盖保留，完整媒体、回复和游标同步属于既有后续验收。

这不是以测试数量定义完成。原入口必须在历史数据增长后仍能返回；本次只修复已证实的网络核验放大，不以另开空服务、缩小扫描或增加用户确认来规避。

改动思路

来源身份核验在现有 HTTP 适配层按原 Session 合并，结束前重新核验所有来源；共享 typed owner 继续逐条决定原始授权、生命周期和回执语义，不能用跨请求缓存代替。

当前 PR 只交付既有委派读取的有界来源核验和撤权结束检查，保留原接口、完整扫描和失败显示；安装采用与真实 App 验收在合并后沿既有维护流程执行。

最有力的反对意见是短期复用证明可能泄露刚被撤权的来源。决定性检查因此放在返回之前，而非只测“旧请求后下一次会拒绝”：原生 Core 测试先真正读取记录，再撤销 binding 或 provider 身份，要求整份响应拒绝、没有 rows，也不增加模型调用。旧 Session 不能借新调用者的证明，需要自己的结束核验。

场景	原实现	本次结果
同来源13条交办	15次来源范围核验	2次；下一页独立核验
重开会话读取旧来源	旧来源仅开头检查	旧来源与调用者都做结束检查
读取后撤权	调用者原检查	所有已观察来源均拒绝返回
来源损坏或缺初次证明	不完整覆盖	继续保留，不推断完成

没有新增缓存服务、Session authority 或配置。相比保持现状、加大超时、少查历史和跨请求授权缓存，现有 adapter 中的有界观察是更小且可回滚的修复。该表用于解释代码，不冒充执行轨迹。

具体改动

关键符号以精确 head 6437299456be03ba4890c762a082526f22134a4c 为准：

• RequestControlMixin._request_inventory_read：校验原查询，建立请求内来源观察，调用既有共享 reader；结束时逐个重新取得真实范围，任何变化拒绝内容。
• validate_source：同一来源不重复触发网络身份核验，但每条记录都比较当前 typed source basis；新原 Session 独立核验。原宿主、Turn、目标授权、生命周期和回执仍由共享 reader 决定。
• _request_inventory_scope：原 provider/binding resolver 不改，没有身份可用就授权、失效降级到普通管家或自动创建来源的路径。

按合并前 accepted RFC docs/architecture/rfcs/app-conversation-and-async-inbox-v0.md、完整修订 a66d8de30652f2e319465fa2a0939a0fd6b57adb 审阅。original-source-scope 与 fresh-source-and-incomplete-coverage 已通过本切片的存储、原生授权和错误路径验证；这些是审阅映射标签，不冒称原文编号。installed-desktop-qualification 延后到既有维护安装后实际 App 验收，不能由模拟测试或旧服务网页替代。此次 RFC 改文只披露实现，不用它自身证明新行为正确。

90 focused File/SQLite and native Core/provider checks passed in26.13s; source-scope-tests.log。同一新增回归在基线先出现4项失败：同来源13条核验15次而非2次、旧来源只核验1次而非2次；head 通过。保留12/1分页、搜索、损坏/缺失来源、已读/采纳、排队回传、取消与历史语义。读取中的撤权不是 mock 直接返回拒绝，而是改变真实 fixture 的 binding/provider 状态后让原 resolver 拒绝。Exact-head risk-based premerge passed, no failures/holds; paired RFC and five-file public-boundary checks passed.

真实保留数据只读探针约29秒返回，未启动消费者、发消息或重放 Turn。其中一条旧来源仍报 initial_delivery_unproved；原 route 所指 Turn 的初次回执属于另一请求，当前补丁没有修改该事实。首次探针假定覆盖必须完整而失败，后续诊断保留原失败和不完整状态，并不改称该记录通过。实际服务此前45秒仍超时，不能以这两个样本声称 p95 或所有同步已经完成。

对主干的风险

最大风险是把身份观察与业务状态混为一个快照。代码只复用一次读取内的来源证明；每条 grant、Goal 和回执仍实时读取，下次 HTTP 请求重新核验。最终循环包含初始调用者及所有旧来源，减少旧实现仅检查调用者的空隙。当前逐条读取仍是观察，不承诺跨 authority 原子快照，也不声称能撤回已经返回的响应。

API 的 query、view、offset、search、rows、coverage 与错误码保持不变；无版本分支、依赖或持久化迁移。可回滚这个 adapter 改动而保留原数据；代价是恢复原先较慢读取。共享业务决策仍在 typed owner，Python 只拥有 provider IO。真实 provider 延迟、旧证明缺口和安装态尚未验收分别保留，既不靠调高限额通过，也不让不完整来源变成空列表。

本次源码验收不查询、轮询或等待远端 CI。无权限、队列、费用、调度、模型或第二消费者副作用；未扩大到无关 PR。原有独立的服务采用与完整原路回传要求仍然有效。

我的整体评价

没有阻塞性发现。这个切片针对真实累计数据导致的不可用，在既有 owner 内减少重复网络 IO，并增加旧来源的结束检查；改动有正向可感知结果，也能独立回滚。批准当前精确 head 的源码增量，不把整个父级原会话同步目标标记完成。

来源身份核验在现有 HTTP 适配层按原 Session 合并，结束前重新核验所有来源；共享 typed owner 继续逐条决定原始授权、生命周期和回执语义，不能用跨请求缓存代替。

当前 PR 只交付既有委派读取的有界来源核验和撤权结束检查，保留原接口、完整扫描和失败显示；安装采用与真实 App 验收在合并后沿既有维护流程执行。

已检查 conversation-requests 数据读取和现有委派面板调用；没有渲染、布局或密度修改，因此本次无需新的截图。

实际安装 App 的面板读回、生产 p95 和长期表现仍未在本次源码审阅中验收。

English verdict: APPROVE this exact-head source-read increment. It bounds provider scope IO by distinct original Sessions and freshly revalidates all observed sources before return, while keeping per-row grants, lifetime, receipt and incomplete-coverage semantics. The90 focused checks and exact-head risk-based premerge passed; baseline regressions reproduce the prior defects. Installed App adoption, production p95 and complete synchronization remain separately unqualified. No authority, persisted cache or consumer is added.