[loopx-agent]

A Lark event calls Core several times during admission. Each call was scanning the Effect runtime source tree to resolve the same revision. Lark admission now uses the existing request scope to resolve the revision once per event. Core still checks the current binding and source on admission and redelivery, and the original Turn retains its deduplication identity.

The regression fixture measured 13 revision resolutions before the change and one after it. A redelivery starts a fresh request scope and resolves to the same persisted Turn. Eighteen targeted tests passed, including source revocation, replay, and original-audience delivery.

In an isolated synthetic history with over a thousand completed Turns, eight same-process admissions per variant had medians of 457 and 414 ms. A separate same-event replay comparison measured 32.4 and 30.6 ms across 20 runs per variant, with one retained Turn and reply. Timing varied between processes. Production lock tails still need verification.

The standard pre-merge run passed all six direct checks and ten selected checks.

[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

Lark 入口接收来自原 App 的事件，需要快速建立或读回原 Turn，并在绑定变化时可靠拒绝。 在基线和当前 head 对四个独立事件各做准入与同事件重投，并在另一个事件读来源时撤销绑定。 在同一合成 workload 下，首次准入的实际版本解析从 13 次降到 1 次，后三个新事件从各 6 次降到各 1 次，四次重投从各 2 次降到各 1 次。 在 provider source read 中途撤销原绑定，两边都返回 command_rejected，均无新 Turn 或投递；四次重投仍各只有一条原 Session/Turn 的用户消息。 完整核对 2 个变动文件；代码路径只改 admit，相关准入和原会话行为由本地真实 Core 验证。 本轮为本机隔离验证；真实 Lark provider、生产锁尾延迟与分发后的观测仍待单独验证。

改动思路 / Approach

Lark 入口的现有同步 admit 加入 revision scope；同一调用中的 Core 读/写共享版本。ContextVar 在 finally 关闭并清除，下次独立调用重新解析。源码/权限的持久 owner 不变。 直接复用已经存在的 request scope；它只固定 executable revision 和现有纯投影缓存，不缓存绑定、来源或 canonical write。没有新增 owner 或状态格式。 已有 Lark 路径内部性能修复；不改变 provider 启用、出站验证、宿主选择或 release gate。

具体改动 / Changes

基线为 e2371c476805f67903dd3c338a7e2712f577c9cc。现有迁移 RFC 要求每次逻辑请求固定可执行版本；绑定、provider 与权限仍需实时读取。Lark 来源使用原 request/source fence。 基线规范

• 单次版本解析。 在同一合成 workload 下，首次准入的实际版本解析从 13 次降到 1 次，后三个新事件从各 6 次降到各 1 次，四次重投从各 2 次降到各 1 次。
• 保留来源授权与重投。 在 provider source read 中途撤销原绑定，两边都返回 command_rejected，均无新 Turn 或投递；四次重投仍各只有一条原 Session/Turn 的用户消息。
• 生产观测。 本轮为本机隔离验证；真实 Lark provider、生产锁尾延迟与分发后的观测仍待单独验证。

关键代码讲解

admit复用现有 scope，Core 仍按来源 fence确认原 App 和来源，重投仍沿原 journal。

对主干的风险 / Risks

值得关注的是版本复用会不会跨事件、或者掩盖授权变化。实际 scope 每次退出清空，同事件重投与读中撤销均保持原结果；没有新增持久缓存。

48 项 Lark 相关测试通过。两侧的实际输入、原请求身份和撤销结果一致。 Quick premerge 的 6 项直接检查和 2 项选中检查通过。 当前 base 的合并树可写、DCO 已核对。 小样本本地 warm median 约 409→323 ms，只说明这组 fixture；结论以解析次数与读回为依据。 远端 CI 未取样。

我的整体评价 / Verdict

同意 ce07338b1e7db73a1b3a8c6fa912df60b59564f0：独立对照证明减少重复解析，且原请求、重投和来源拒绝不变。 本轮为本机隔离验证；真实 Lark provider、生产锁尾延迟与分发后的观测仍待单独验证。

English verdict: APPROVE. The request-scoped revision reuse reduces real resolution work and preserves fresh binding checks and original-Turn replay.