[loopx-agent]

Goal And Delivered Outcome

原生绑定管家读取委派列表时，读前、读后都分别为会话验证和 Goal 可见范围重复观察同一个 provider。带网络的身份验证因此每个请求执行四次。现在每个检查点复用一次已验证的 Core 选择，合计两次，保留返回内容前的重新验证。

• Outcome basis / optional anchor: 修复既有委派读取的重复 provider IO。
• Observable before → after: 同一来源、同一 HTTP 请求，provider 观察 4 → 2；自定义范围解析器保留原路径，撤销及读取途中改权仍拒绝返回内容。
• Issue/task and intended base: 独立修复，目标 main；现有锁读取优化见 perf(collaboration): batch guarded inventory observations #7630。

Author Declaration

• Written by: model_agent — OpenAI GPT-6 / Codex.
• Specification and revision: loopx/capabilities/manager_context/README.md，9dcdc0bacd455a8cf6f6146f052ffc4df0f5d04a 的 original-conversation inventory 合同。

Criterion	Disposition	Symbol / path	Evidence
读取前、后验证当前绑定与 Goal 范围	implemented	bound_steward_inventory_scope / RequestControlMixin	原生 provider/绑定撤销、读取途中改权与恢复
保留完整计数、分页、来源隔离及只读语义	implemented	既有 inventory / receipt owners	File/SQLite HTTP，43 条长记录、关联工作、完整翻页及搜索
来源与执行器路由保持原边界	implemented	manager_source_scope_resolver	独立 registry/runtime 参数回归；原生 HTTP 使用生产 resolver 工厂

• Self-check: 把默认来源路由移到相邻请求范围模块；聊天服务入口净减少代码，无体积预算上调。既有 Core owner 继续决定授权，没有跨检查点的权限缓存。

Scope And Continuation

完成本次重复身份观察修复及默认来源路由的等价迁移。原生安装态的完整延迟、其它读取成本继续沿既有工作验收；历史回执拒绝沿已有诊断 owner 处理。此提案独立于 #7630 的生命周期锁优化。

Validation

• Tested revision: 61f109d
• Run state: finished
• Input classes: synthetic, public_fixture, authorized_private_read_only

Check kind	Result	Evidence / limitation
integration	passed	104 项；inventory、request control、修订恢复、native ingress、manager tracking
real_backend	passed	隔离 File/SQLite authority；原生绑定的真实 HTTP 完整翻页、来源权限及恢复，模型/provider 为明确的测试替身
regression_parity	passed	同数据 ABBA，历史/待跟进/下一页/搜索/刷新；身份、计数、完整响应和快照一致，来源 JSON 不变；禁用复用路径的敏感性检查按预期以 4≠2 失败
static	passed	Ruff、编译、双语 RFC diff、语义词汇及公开边界检查；词汇 advisory 无支持范围内新增载体
manual	not_run	安装态新旧版本 A/B、真实网络尾延迟尚未资格；不以隔离结果代替这些结果

对照使用 43 条请求、2 个接收者、842 个 Turn（约 50 MB）、32 个 Core Todo、11 条关联。provider 每次读固定模拟 100 ms 延迟；每种查询每模式 2 个样本。以下为各查询的中位数，用于检验重复观察的固定成本：

查询	SQLite 兼容 / 复用 (ms)	File 兼容 / 复用 (ms)
全部记录	664 / 444	949 / 439
待跟进	695 / 451	734 / 434
下一页	695 / 440	764 / 438
搜索	739 / 441	756 / 453
刷新	661 / 444	771 / 1803

File 刷新的复用样本为 453 / 3153 ms，长尾异常保留，尚未归因。 宿主其它负载未隔离，样本不构成尾延迟资格；不把固定 provider 延迟实验解释为安装态性能提升。

Quick 预合并的 6 项直接检查、3 项 canary 和公开边界扫描通过；合并门仍缺 exact-scope change-quality receipt。维护者评审、CI 和合并权限分别确认，本提案不宣告合并就绪。

Frontend / Visual Evidence

• UI impact: none。沿用现有委派入口与响应结构；无布局、控件或首屏变动。
• Before / After / First viewport / viewports / Attention / Craft review: N/A。
• Source data: synthetic。

Type of Change / LoopX Area

• Bug fix
• Refactoring
• Documentation update
• Test update
• Host or runtime integration
• Capability or extension

Technical Direction / Shared-authority RFC fixture impact

既有只读来源合同的 host IO 修复。权威存储实现和切换合同无变动；PostgreSQL 存储资格不在本次范围。无 RFC 成熟度或整体验收晋级声明。

Boundary Checklist

• Diff、正文及附件无私人状态、凭据、原始轨迹、内部链接或本机路径。
• 无 maintainer-owned benchmark 执行；对照是隔离产品读取样本。
• 范围限于来源读取和等价路由迁移。
• 未修改成对 RFC，双语 diff 检查通过。
• UI impact 已标记 none。
• Commit 含 DCO sign-off。

[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)

动机 / Motivation

使用已绑定管家会话查看原始请求清单的用户，会在每次打开和翻页时经过 provider 身份核验。旧路径在同一个授权检查点重复核验同一 provider；新路径在每个检查点只核验一次，并在读取结束前再次检查当前授权。重复外部观察会增加打开清单的等待，但直接缓存权限会让已撤销的授权继续泄露内容。本轮确认完整 HTTP 清单仍能翻页和搜索，读取期间的撤权仍会阻止内容返回，同时单次清单读取的 provider 观察由四次降为两次。本 PR 不增加委派、消息发送、请求接纳或模型执行权限，也不宣称端到端延迟、File 尾延迟或长程任务收益已经达标。

改动思路 / Approach

复用同一次新鲜 Core 选择来校验 Session 与 Goal 可见性，同时保留读取前后两个独立检查点，比缓存授权或移除收尾检查更符合原边界。本次边界是既有请求清单入口的局部读取优化，保留自定义 resolver 和旧 manager 路由的语义，不新增用户配置或独立控制面。只有仍使用创建时那个 manager resolver 的原生绑定路径可以复用已验证选择；resolver 被替换时回到原有路径，空授权列表也不会被当作“没有结果”而回退扩权。这是每个检查点内去重，后一个检查点仍重新读取 provider、binding、Session 和证据范围。

具体改动 / Changes

完整审阅四文件 diff（+218/-20），head 61f109d18e3507e6273205950a4d6be6a22c678e，不可变修改前基线 9dcdc0bacd455a8cf6f6146f052ffc4df0f5d04a。依据修改前的 loopx/capabilities/manager_context/README.md，revision 9dcdc0bacd455a8cf6f6146f052ffc4df0f5d04a，核对原始会话来源、读取前后当前授权以及只读不接纳请求三个要求。原文没有编号，以下是审阅标签：INV-SOURCE、INV-RECHECK、INV-NO-EFFECT；对应要求均已通过实际调用验证，不用本 PR 新增说明反向定义验收。

关键代码讲解

• bound_steward_inventory_scope 先核对 resolver 对象身份，再取得一次新鲜绑定选择，并调用现有 runtime_context 校验管家 Session 的 channel/Goal；返回该选择的 Goal 列表。它没有跨请求缓存，也没有把保存的 Session 文本变成授权。
• _request_inventory_scope 仅在上面的原生路径得到有效列表时复用它；自定义 resolver、私有会话、选定 Goal workspace 和证据范围判断仍保留。_request_inventory_read 的收尾检查继续覆盖每个实际观察到的原始来源。
• manager_source_scope_resolver 从原 Chat server 闭包移出既有路由，继续区分当前来源 registry、协调 runtime 和 executor runtime。原生绑定仍由 conversation bindings 所有，旧 manager 仍调用已有授权函数，没有另建权限规则。

本地验证：七组相关测试 214 PASS，既有清单 caller suite 在 base/head 分别 22 PASS。冻结同一组撤权场景，两边均 12 PASS；捕获完整响应和错误正文，仅归一化生成的身份、digest 与时间后，12 组结果一致。独立次数约束能检出旧重复读取：base 6 FAIL / 3 PASS，head 9 PASS，没有通过放宽撤权条件制造通过。

对主干的风险

没有发现阻塞问题。 最危险的回归是去重时遗漏读取期间撤权，或错误使用另一个 resolver 的结果。已执行读取前/读取中 binding、provider、scope 撤销，覆盖拒绝正文和不返回行；真实 HTTP 的 File/SQLite 场景分别读出 43 个长问题、两名接收者和 Todo 链接，翻页、搜索、撤权后恢复均成立，源 JSON 和模型调用记录不变。

既有 caller 测试另覆盖重开会话、其他 audience 不可见、13 条记录超过 12 条展示页、取消/历史、损坏来源的 partial coverage，以及收尾 scope 改变后整批拒绝。Ruff 与标准 premerge 通过：6 direct、6 catalog、8 risk、1 public-boundary，0 manual hold。没有查询、轮询或等待 CI。作者报告过的 File 尾延迟未在本轮重新定量资格化，不能据此承诺整体延迟改善。

语义与边界

复用现有 Core 会话和 Goal scope 类型，不新增生命周期词汇或依据 prose/substring 分类。README 说明的是新鲜检查的执行方式，没有删去授权、来源隔离或只读义务；固定字段、消息、诊断和副作用保持原契约。该改动不是 default-off 功能；自定义 resolver 回退是兼容路径，已与基线对照，不能把它误说成一个新的功能开关。

我的整体评价

本 head APPROVE，局部成本下降与权限保持都有独立证据，规模和现有 owner 匹配。普通用户继续在同一清单入口查看结果，无需新增设置、确认或重新提供已知信息。检查了 chat_server 和 request_control_api 的实际调用及全部四文件差异，没有渲染层、文案入口或前端布局变化。本轮未渲染无变化的页面；可视化测试不能替代已执行的接口授权和来源隔离验证。本结论只覆盖该精确 head 的读取行为，不代替后续真实延迟测量、安装采用或其他 PR 的验收，也不授权合并。

English verdict: APPROVE at 61f109d: one fresh provider observation per opening/closing checkpoint preserves authorization, full responses, historical-source isolation and read-only behavior; 214 related tests and 22 existing inventory caller tests pass.