[loopx-agent]

Delegation inventory reads repeatedly scanned every original source Turn for each request. The existing Chat source observer now builds a locator once per Session within one HTTP read, then rereads each exact Turn before the shared typed grant, lifecycle and receipt checks. The next page constructs a fresh locator; changed identity or missing source remains incomplete coverage. Opening and closing provider checks are unchanged.

This stays in the existing source-observation IO provider. It adds no persisted index, policy owner, consumer, setting or protocol vocabulary. The App and external conversation continue to use the same inventory endpoint. Both RFC mirrors record the bounded checkpoint; complete cross-channel delivery remains separate.

Validation:

• Request inventory/control suites: 20 passed across File and SQLite fixtures. Coverage includes complete pagination, search, older Sessions, audience exclusion, missing source, current Turn contents, changed identity and closing-scope revocation.
• The same 13-request counterexample with the old scan fails on both providers (91 Turn reads against the bounded-read guard); the fixed path passes.
• Read-only original-source samples fell from 28.332–29.061 s to 14.766–15.902 s. Returned rows, totals, next offset, coverage and snapshot digest matched. An existing unreadable source remains explicit. These few samples are not a p95 or end-to-end provider qualification.
• Risk-based premerge gate: all six direct checks and eleven selected checks passed, including bilingual RFC, maintainability, semantic vocabulary and public-boundary checks. No budget was raised; an initial Chat-store ceiling failure was resolved by placing the IO in the existing source observer.
• Adjacent Chat/runtime/steward/delegation suites: 66 passed, one existing interrupt-event failure. The exact isolated test fails identically on the unchanged base and head; this change does not touch that runtime path. CI was not queried under the configured local-validation policy.

No first-screen layout changes. Installed service adoption and full original inventory pagination will be checked after the authorized merge. Rollback is a code revert; there is no store migration or journal rewrite.

[loopx-agent]

Reviewer: model_agent · GPT-6 · OpenAI · self_reported（宿主执行归属观测不可用）

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

动机

管家用户打开原会话的委派列表时，需要及时看到全部未收敛请求。

历史较长时，旧实现为每条委派重新遍历来源会话的全部 Turn；新实现每次读取只定位一次，逐条仍读当前原始 Turn。

只读实际来源的少量样本从约28至29秒降至约15至16秒，返回正文、分页、总数、覆盖和快照摘要一致。

本 PR 不宣称解决 provider 网络延迟、全部跨端同步或历史来源证明缺口。

安装态分页和完整跨端同步仍沿现有 Chat 交付工作继续验收。

改动思路

现有来源观测器负责文件定位，typed Core 继续负责授权和未完成状态；没有新增持久索引或第二决策 owner。本 PR 只消除委派读取中的重复全历史 IO，保留每条来源和返回前的授权核验。最小改动放在既有 source observer，普通队列和重放的单次查找保持原状。把 IO 放回已有来源边界也避免扩大 Chat store 或提高模块预算。定位器只存路径，每条请求仍读取当前文件；下一页重新构建，不复用授权、正文或回执判断。

具体改动

规范依据是 docs/architecture/rfcs/app-conversation-and-async-inbox-v0.md，准确接受版本 ec66345f7ecd826c166c9df45628ca52c3df15a2。本次文档补充按该旧版本的要求审查，没有用新说明反向定义验收。source-read-freshness 已实现：每条仍核验当前来源、Turn、grant、生命周期和回执。per-page-source-proof 已实现：定位器留在当前 HTTP 调用内，下一页重建，结束时继续核验各来源。incomplete-coverage 已实现：文件丢失或身份变化计入不可读，不能伪装成功空列表。

关键代码讲解

• original_turn_reader（source_chat_observation.py:28）建立当前来源的 client 到路径定位，读取时重新取文件并比较 client 身份；不会缓存正文或发布任何消息。
• read_conversation_requests（conversation_inventory.py:35）为每个已核验来源创建一次定位器，随后复用原有 typed Inbox、Goal 和结果读取；排序、搜索、分页和摘要算法不变。
• RequestControlMixin._request_inventory_read（request_control_api.py:79）保持来源开始和结束核验；结束时授权改变，整份响应仍被拒绝。

File/SQLite 的原 API 套件在不可变基线上16项通过，准确候选上20项通过；新反例覆盖当前正文、client 变更、文件消失与结束授权撤销。独立把旧逐条扫描注入同一分页 API，两个 backend 都在91次文件读取处触发有界读取断言，修复版通过。真实只读来源的最终候选读取为15.972秒，与旧路径的正文、总数、分页、覆盖及摘要完全相同；少量样本不能当作 p95。

对主干的风险

最大风险是为提速缓存陈旧内容或放松权限。逐条新读文件、确切身份比较和未改动的结束核验直接限制了这两种风险；已有搜索、重开 Session、其它受众、只读回执与分页案例继续通过。新字典仅保存在一次调用中，没有新 schema、持久索引、开关、消费者或迁移。丢失来源明确保留不可读，恢复后由下一次读取继续。

准确 head 的六项直接检查和十一项风险预合并检查全部通过，包括双语 RFC、编译、模块上限、语义词表和公开边界。初次 Chat-store 上限失败没有通过提额解决，而是移回既有来源 IO owner。相邻套件66项通过，interrupt-event 用例在基线和 head 上都出现同一个额外 turn.interrupt_requested；最终差分未修改该失败的 runtime/store 路径，故按既有无关失败单列保留，不宣称已修复。按当前策略未查询 CI。此结论不授权跨端业务代办，也不关闭来源证明缺口。

我的整体评价

本次是可独立验证、可回滚的有效增量：long_horizon 与 user_experience 都有改进，累计历史不再放大逐条文件扫描，用户原有操作和授权轮次不变。现有来源观测器负责文件定位，typed Core 继续负责授权和未完成状态；没有新增持久索引或第二决策 owner。本 PR 只消除委派读取中的重复全历史 IO，保留每条来源和返回前的授权核验。采用已有合同，无新增共享词表或预算调整。

本差分只修改原委派读取路径，未改动 App 页面结构、内容格式或 CSS；已检查调用该接口的现有对话入口。无新增可视布局；安装态完整跨端旅程仍单独验收。provider 网络等待、历史不可读来源和完整安装态双端交付仍保留真实边界。没有引入需额外确认、手工维护或重新录入信息的流程，批准此准确 head 的增量。

English verdict: APPROVE — 0e86d2b. The read-local locator removes repeated original-Turn scans while preserving fresh content, typed authority and incomplete-source reporting. File/SQLite semantic and negative cases and the risk-based premerge gate passed; the unchanged base interrupt-event failure and full installed cross-channel acceptance remain separate.

[loopx-agent]

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

Post-merge audit — independently reproduced P2 regression

Request changes conclusion (author-owned PR; GitHub blocks formal self-review)

[P2] 新增定位器把无关历史文件的解码错误扩大到整份请求列表。具体见“对主干的风险”，需要后续修复；原审批记录保留。

动机

从原对话查看未完成委派、翻页或搜索请求的用户，以及提供这份列表的已有 Chat 服务。

旧实现为每条请求反复扫描同一 Session 的历史 Turn；新实现一次定位路径、逐请求重读原文件，正常数据下减少重复读取，但一个无关坏文件会让当前提交隐藏本来仍可读取的请求。

同一物理 File/SQLite 夹具中，13条请求的 Turn 读取从91次降为26次，除观测时钟外完整返回和分页摘要相同；服务启动后的坏文件反例却把主干仍可见的6/10条请求都变成0条。

本次评审检查原有列表的 IO、来源与授权语义，不宣称完整安装态跨端同步、原生执行、接收方采用、端到端延迟或长期效率已经资格化。

定位优化仍需补足单文件故障隔离；安装态采用、完整分页和持续 provider 延迟仍由原有会话与异步 inbox 验收负责。

改动思路

路径定位留在现有 Python 来源 IO 适配器，授权、生命周期和回执仍归共享 typed owner；每次 HTTP 的短寿命路径表不应成为整份 Session 内容可读性的额外门。

当前 PR 应只减少既有请求列表的重复 IO，并保持可读请求、覆盖缺口与撤权结果；不新增持久索引、设置、协议或另一套权限，单文件隔离修复即可完成这个边界。

这是已有列表读取的 IO 复用：先按原 Session 找到 client Turn 对应路径，再为每条请求重读内容，之后仍走原有 grant、Goal 生命周期、回执与未完成议程判断。路径表随一次 HTTP 结束，下一页重新构建；不会把打开页面、读过 brief 或存在路径解释成接收方采用、权限或任务完成。保留普通单条 Chat 查询与批量读取各自的调用边界合理，无需持久索引或新缓存服务。

正常场景已经显示实际收益，但每次读取仍要遍历来源 Session 的历史文件；单条早期请求、很长历史、provider 延迟和安装态完整列表没有因此自动资格化。作者少量墙钟样本也不能代替 p95 或端到端验收。

具体改动

评审依据是改动前的 docs/architecture/rfcs/app-conversation-and-async-inbox-v0.md，不可变修订 ec66345f7ecd826c166c9df45628ca52c3df15a2，相关英中合同均已在差异之前阅读。Each row still checks its current source 与 No proof survives the HTTP read 在正常和撤权路径上 implemented；Unreadable sources remain incomplete coverage 与验收矩阵的 Authority 尚未满足，因为新增 IO 路径让无关文件故障吞掉了原本可用的请求。新写入的 RFC 检查点不能作为它自己的独立验收依据。

关键代码讲解

• original_turn_reader 在既有来源观测器建立 client-id→path 表，只保存路径；调用返回的 reader 时重新读原文件并核对 client 身份。位置归属和短寿命设计合适，但第39行在完整目录扫描中直接解码，缺少逐文件错误边界。
• read_conversation_requests 在每个已核验来源 Session 首次遇到请求时建立 reader，并保留每条记录的来源、grant、typed 生命周期与回执核验，排序、分页、搜索和结束 provider 检查也未改。工厂异常时 reader 没被保存，外层每个候选都捕获同一个错误并计为不可读。

全差异为两个既有生产文件32行增加/3行删除、原 HTTP 测试51行补充，以及英中 RFC 14行检查点；没有新 store、schema、开关或协议词汇。生产复用点有真实现有前端与原会话 HTTP 调用。已应用的有界整理是把批量物理定位放回来源 IO owner；剩余修复应在此隔离单文件故障，而不是再增加一个权限 owner。

对主干的风险

[P2] 第39行需要逐文件处理不可解码的历史 Turn。 我用真实服务、真实 Chat 文件和 File/SQLite authority，在同一份物理夹具中分别运行主干与本提交。先启动服务，再把一个由 store 正常创建、已经完成、没有委派请求的历史 Turn 改成非法 UTF-8；另外13条请求及其来源文件、grant 和回执保持有效。主干 File 仍返回6条请求、SQLite 仍返回10条，当前头两种 provider 都返回0条，coverage.unreadable 都变为13。这里没有把主干原有的部分读取失败算成通过；新增代码把可用的6/10条也丢掉，才是此次回归。

原因是 _read_json 的 UTF-8 解码错误会离开整个定位器构建，而外层只在“每条请求”层捕获 ValueError。每个合法请求因此重新撞上那个无关文件，尚未走到自身的来源与 typed 核验。显示覆盖不完整提示不能补回已经消失的待处理工作。

在既有来源观测器中隔离单个 Turn 的解码失败，继续定位其他有效 Turn；实际缺失或坏掉的请求来源仍计为不可读，保留逐请求重读与结束授权核验，并补真实 HTTP 的 File/SQLite 反例。

回归应扩展现有 tests/control_plane/test_chat_request_inventory.py：故障在服务启动后发生，覆盖 File/SQLite，保留可读请求；再验证坏掉的确切请求来源仍不可读，恢复后能继续读取。运行该文件和 test_chat_request_control.py，并保持正常13请求读数、分页、身份变化、缺失恢复和结束撤权反例。

正向证据仍成立：独立的同物理夹具 HTTP 对照在两种 provider 上均为91→26次 Turn 读取，完整 DTO、行顺序、总数、next offset、coverage 和 snapshot digest 除 observed_at 时钟外一致，原回执字节不变。随后新增第14条请求能在下一次 HTTP 看到；目标身份变化或丢失只形成相应缺口，恢复后回到14条；结束核验撤权返回400且不含任何 rows。原生20项请求测试通过，自动 premerge 的双语、编译、维护性、词汇和公共边界检查也通过；这些测试没有覆盖上述无关文件解码反例，本轮新增的两项实际反例均失败，当前精确范围的 change-quality 结果也据此记录为 FAIL。

语义与 CI 对齐

定位器是临时派生 IO 数据，真实 producer 是当前已授权列表读取，不需要人工同步标志。没有新增共享词汇、机器默认值或硬工作义务；但“IO 优化不改变可读覆盖”的现有语义已被当前反例违反。没有查询或等待 CI，也没有放宽预算、吞掉实际坏来源或把失败验证标成通过。

我的整体评价

针对已合并 0e86d2b79c42daa51bf5d0bc1602b81fd7e65823 的补充审计，修复结论 REQUEST_CHANGES，交付判断 not_yet_proven。原审批记录保留，此处发布合并后发现，不重新发起形式审批。正常读取的减少与语义对照有价值，机制规模和归属也合理；阻塞点是完整当前头新增的故障扇出，而非要求本提案完成整个父架构。

long_horizon=regression：有效未完成请求可能从列表消失；user_experience=regression：用户被迫先修复无关历史，才能看到仍然可处理的工作。最小修复是上面的来源文件错误隔离和真实 HTTP 反例。布局、文案和入口未改，因此没有新的视觉设计验收；完整安装态、跨端结果回传、provider 延迟和长期完整成本仍未核验。不要从绿色正常用例或自动 premerge 推导出这些资格，也不据此合并或升级。

English verdict: REQUEST_CHANGES — post-merge audit of 0e86d2b79c42daa51bf5d0bc1602b81fd7e65823; a follow-up fix is required and the prior review remains intact. The normal 13-request read is correctly reduced from 91 to 26 Turn reads with exact same-fixture DTO/digest parity. However, one unrelated completed Turn becoming invalid UTF-8 after startup makes both File/SQLite inventories drop all readable requests: the base retains 6/10 and the head returns 0. Isolate per-file decode failures during locator construction and add the live HTTP regression while preserving authority, coverage and bounded-read checks. No CI or merge authority is implied.