[loopx-agent]

当自动补办发现的消息超过现有 worker 的并发容量时，尚未提交的消息也会进入发现阶段的 60 秒退避，导致槽位释放后积压仍不能立即继续。本次复用原 worker 的公平性计数保留未提交项；真正开始核验时刷新退避，继续由 Core 重读原消息、来源和停止门禁。

验证：

• 当前主分支上的同一组新增用例复现 3 处断言失败；最终提交的 11 项关键回归通过，覆盖满池、后台任务占位、后来消息及发现后的停止/来源变化。
• 整合主分支前的相关完整测试为 582 passed；最终提交的标准 premerge 已通过：6 项 direct checks、10 项 selected checks，0 失败，保留 1 项既有非阻塞 advisory。
• Ruff 与 diff 检查通过。生产积压补办和原会话送达作为安装后的独立验收。

The original worker retains discovered but unsubmitted recovery work until capacity is available. Actual recovery attempts keep their retry backoff and revalidate Core authority.

[loopx-agent]

Reviewer: model_agent; model=GPT-6 (Codex); provider=OpenAI; declaration_source=self_reported

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

未发现阻塞性问题。评审对象为 e41b81d68f92020ae2ac0f12705d5fb09691b25a，生产真实消息补齐仍保留为安装后的独立验收。

动机 / Motivation

使用现有Lark个人助手或管家、等待历史请求自动补办的人会遇到这个问题。当四个worker槽位被占满时，旧实现把后续仅被发现的请求推迟60秒；修复后，槽位释放即可继续调度这些请求。受控真实worker回归证明积压和后来请求均在等待窗口内得到尝试，实际失败仍保持退避。这次不改变Core恢复资格、未知效果保护、模型选择或原消息受众。完整生产积压的补执行与原会话回传还需安装后逐条验收。

改动思路 / Approach

发现只是调度提示，恢复资格继续由Core决定；复用既有公平性计数比新增队列或取消退避更小。当前PR只修复现有私聊worker的未尝试项调度和实际尝试退避。原始transport文件和Core请求仍是持久事实，worker的零计数只是已发现、尚未提交的本地提示。槽位被占满时保留这个提示；真正提交后增加原公平计数，并在原reconcile入口刷新退避。这样同时避免了丢失待办提示和反复读取原生事实，不需要第二个队列、消费者或同步协议。单纯取消退避虽然也能让旧请求再次出现，却会把没有变化和失败的探测变成重复成本；只缓存资格又会带来陈旧授权，所以本补丁保留原Core的重新核验。

具体改动 / Changes

关键代码讲解

1. _reconcile_private 复用已有 attempted：扫描得到的路径先以零计数登记；之后把仍未尝试的路径并回候选集合，沿用原公平排序与四线程上限。已有future仍不重复提交，真正 pool.submit 后才增加次数。
2. pending_delivery_paths 仍完整扫描持久请求并保留60秒读探测时钟。它返回的是调度提示，Core的恢复判断没有被缓存为执行授权；新上游的scan-local observer也已整合。
3. reconcile_request 在实际开始核验delivered历史请求时刷新同一时钟。随后继续走原Core和原消息读取；发现后的停止或来源变化不会因旧提示而被绕过。

生产代码新增13行，测试新增137行、删除3行。覆盖0/2个后台槽位、9条积压和满池后新增请求；还验证不合格请求、实际探测失败及发现后的停止/来源变化。没有针对这处临时公平性计数的独立已接受规范，本次没有虚构RFC条目；验收依据是既有持久队列、独立Core资格和复现故障。

对主干的风险 / Risks

主要风险是陈旧发现提示绕过来源/停止，或实际失败的保护窗口被发现阶段提前耗尽。同一完整fixture在不可变基线 d4aaaaefbd37a83a30f10681de839b45d631eeb9 上得到3项预期断言失败和8项既有权限/回传用例通过；在评审head上11项全部通过。负向用例保留原失败Turn字节和事件，不增加Argon业务派发；正向用例完成同一Session接续和回传验证，重复进入原worker不会再次派发。

PASS：标准premerge的6项direct checks与10项selected checks通过，0失败；既有gate保留1项maintainability advisory。初次环境缺少TypeScript依赖，按已有锁文件以 npm ci --ignore-scripts 补齐后，同一head重跑通过。整合前的582项回归及最初fixture接口失败均保留为历史，当前结论由当前base/head对照和源码检查支持，没有删断言或放宽等待窗口。CI按Goal策略未查询。实际PR目标基线已前进至 2087f540bb07dcc96e063911950ba32f3796f0ee；逐路径核对确认本次调度、Core恢复调用方、测试和评审规则未变，因此上述相关证据仍有效。

语义与 CI 对齐

本次属于 local_only 调度修复，复用原Core恢复契约，没有新增状态词汇、协议版本或授权含义。标准语义检查通过。它不改变恢复资格，也没有增加需要用户配置或确认的步骤；原worker仍是生产调用方。模型、provider IO和逻辑时钟在回归中隔离，测试不证明生产端到端耗时或全部积压已送达。

我的整体评价 / Verdict

这是 justified_increment：交付了可独立回滚的积压调度不变量，剩余生产验收边界明确。long_horizon=improved，容量释放后多批积压与后来请求可继续推进；user_experience=improved，复用既有上下文和授权，无额外输入轮次。变更仅涉及已有私聊worker和重试时间戳，未改动任何渲染页面、文案或布局。视觉范围无待验收项；生产送达待安装后验收。发现只是调度提示，恢复资格继续由Core决定；复用既有公平性计数比新增队列或取消退避更小。当前PR只修复现有私聊worker的未尝试项调度和实际尝试退避。代码规模与故障成本相称，已采用复用现有计数这一更小方案；没有新增兼容分支或持久迁移。安装后的真实消息补齐继续由原服务执行并独立读回。

English verdict: APPROVE. Head e41b81d; real-worker regressions and source premerge validation passed, with production delivery retained as post-install acceptance.