[loopx-agent]

When /stop finds no active Turn, completed-command discovery currently reads native items separately for every frozen historical Turn. A topic with 23 completed Turns makes 24 item calls including the final cancellation proof before its verified reply.

Read the original native thread's complete paginated item inventory once and intersect command ownership with the frozen candidates. Exact-Turn cancellation and terminal readback remain separate, and newer work remains ineligible. Incomplete pagination or conflicting ownership stays unconfirmed. The paired RFC describes this boundary.

Validation:

• New native inventory and full original-topic journey tests pass, including real child termination, unrelated process preservation, frozen history, one verified reply and idempotent recovery.
• Alternating controlled provider/native-wire runs with 23 Turns and 10ms item RPC delay reduce item calls from 24 to 2 and median verified-journey time from 0.487s to 0.184s. This is synthetic wire evidence, not production latency or the five-second/Web SLA.
• Ruff, configured repository mypy, public-boundary and bilingual diff checks pass. Five optional strict diagnostics in the whole legacy adapter match the exact base.
• 630 broad native/Lark regressions, 71 tests importing the actual installed wheel, and the final 11 native inventory negatives pass. Standard premerge (6 direct + 11 selected checks), normal wheel doctor and packaged HTTP/current/previous/PWA assets pass. Restoring the immutable baseline discovery method makes the new complete original-topic round-trip oracle fail as expected.
• CI is not consulted under the resolved managed policy. Installed production five-second/Web acceptance remains separate.

[loopx-agent]

Reviewer: model_agent · GPT-6 · OpenAI · self_reported (host execution observation unavailable)

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

动机

在群话题中停止已完成回答所遗留后台命令的用户，会等待历史查询完成后才收到停止回执。 同一话题有23个已完成回合时，旧路径逐个读取命令清单；新路径分页读完原线程清单，只筛选已冻结的回合。 受控原话题旅程中，item查询从24次降到2次，原进程退出、其他进程保留且只发送一条核验通过的停止回执。 本PR不改变停止授权、后台任务范围、活跃回合中断、模型输入、持久化格式或服务安装流程。 真实安装态完整5秒时限、网页及时可读与完整社区准出仍需单独验收，本PR没有把历史失败改为通过。

改动思路

保留原生协议IO在现有Codex适配器，复用分页与终端读取；Core继续拥有冻结目标、授权和恢复。 本PR交付完成回合的命令发现往返压缩和原话题真实子进程回执闭环，保留独立的确切取消与终端读回。 我核对了不改、提前结束扫描和缓存归属三种替代方案：前者保留累积往返，后两者可能遗漏后页错误或沿用过期归属。这里直接复用已有 _control_items、终端清单及后续取消，不另建队列、缓存、开关或策略层。下表是准确头 95be7937c8cf71ef40e8c47abfac68eda8e85f13 的源码路径说明，不是执行证据；实际证据来自独立预期的子进程与原话题验收。

触发路径	原实现	当前实现	保留的约束
已完成回答留下后台命令	逐个历史回合读取item	一次分页读完原线程，再筛冻结候选	之后仍做确切取消和终端独立读回
活跃回合停止	确切回合中断	相同路径	无关历史读取不能阻塞它
清单不完整或归属冲突	不能把未知当完成	保留原请求为未确认	不提前发成功回执、不追停后来工作

具体改动

准确审阅头：95be7937c8cf71ef40e8c47abfac68eda8e85f13。五个文件包含一个原生协议IO方法、两份测试与一对中英文RFC；无发布产物、私人状态、持久化迁移或新的共享枚举。原生CLI生成的协议schema明确说明 thread/items/list 的 turnId 可省略，而 threadId 必填；这不是猜测另一个接口。

关键代码讲解

1. background_turn_ids 接收Core冻结的原生回合ID，先读当前终端，再完整读取原线程item分页。它只为原候选保留命令归属，最后按原候选顺序返回；后来的回合即使出现在同一线程中也不进入目标。新发现的归属缺失、跨回合冲突和分页错误会终止发现，而不是被解释为没有活命令。已有确切线程/回合的原生事件归属仅补足本次观察，不持久化本次map。
2. _control_items 保留原有deadline、分页和错误处理。必须读完每页才返回发现结果，不能因为第一页已找到命令就跳过后续坏页。活跃停止仍走原来的 _command_item_ids(selected_turn_id)，没有被迫读取整段历史。
3. completed_background_turns 是未修改但必须核对的上游边界：它根据原Session核对已冻结的canonical回合，将原生观察再映射回原候选。之后原有确切取消和终端读回确认物理状态，现有provider回执路径确认原话题送达；这两个阶段都没有被成功ACK替代。

依据修改前已接受的规范：https://github.com/loopx-project/loopx/blob/110893bcafeb23c166251f9aeec6fe3d829294d1/docs/architecture/rfcs/app-conversation-and-async-inbox-v0.md#selected-group-topics-isolated-ordinary-project-chat；`spec_revision=110893bcafeb23c166251f9aeec6fe3d829294d1`。逐项映射：`frozen-original-scope` 已实现并经后来工作/失败恢复反例验证；fresh-authority-and-unconfirmed-recovery 保留原请求与路由锁内的新鲜授权；active-turn-exact-interrupt 保留不受历史清单故障影响的活跃中断；qualified-stop-reply 在物理停止及完整provider读回后才能成功；installed-web-community-acceptance 保留为分别验收的缺口。两份RFC只增加IO路径解释，没有改写原准出条件来配合实现。

对主干的风险

没有发现阻塞问题。最强风险是完整线程扫描把后来的命令混入停止目标，或前页成功掩盖后页不完整。当前候选map、全部分页验证、Core二次冻结集合交集和确切取消共同约束它；测试覆盖同线程的更新回合、无关活进程、分页/归属冲突、首次清单失败后的active/completed/resume、新会话和legacy未知范围。真实子进程的退出由操作系统读回，无关进程继续存活；provider的完整回执由原有独立读回确认，模拟wire没有直接提供这些物理结论。

原始基线方法重新接入同一个完整原话题验收时，往返计数断言按预期失败；当前安装包的同一旅程通过。630项广回归、71项真实wheel导入测试和最终11项本地原生负例通过。标准预合并6项直接检查及11项选定检查、Ruff、配置内mypy、双语检查、正常wheel doctor及安装态当前/旧资源/PWA HTTP检查均通过。额外对整个遗留适配器开启严格mypy时，五个诊断与准确基线逐条一致，未改这些因果路径。初次六处夹具只接受带Turn ID请求的KeyError已保留记录；修正后夹具同时提供原工作和后来工作，未删原范围断言。当前没有未归因的受影响失败。

语义与 CI 对齐

本改动复用现有协议/语义，开发advisory未发现新词汇载体，标准检查已通过。wait_for_ci=false，未获取、轮询或等待CI。完整线程可能有比稀疏历史更多的item分页，所以受控10ms接口的两组中位数只能说明该fixture的往返改进，不能代表生产p95；已有总deadline和未知状态保留。实际安装态完整5秒/Web及完整社区黄金旅程仍需独立验收。

我的整体评价

APPROVE，结论仅针对 95be7937c8cf71ef40e8c47abfac68eda8e85f13 的完整五文件差异。long_horizon=improved：减少历史增长带来的重复往返，原恢复与完成记录保持。user_experience=improved：用户仍在原话题发同一停止命令，没有新增确认/导航，受控回执闭环实测更快。保留单回合清单取消路径是必要边界；进一步抽象小段解析会增加空值模式和调用理解成本，目前不值得。生产侧只新增短命归属聚合，没有第二套状态、权限、调度或新CLI，改动与问题相称。此审阅不会把COMMENTED自审当作GitHub正式批准，也不把源码/安装包通过当作完整生产与网页准出。

English verdict: APPROVE — head 95be793; one complete native thread inventory replaces repeated completed-Turn discovery while preserving frozen targets, exact cancellation and verified original-topic delivery. Broad source, installed-wheel, negative and standard premerge checks pass. Production five-second/Web acceptance remains separate; CI was not consulted.