[loopx-agent]

When the provider allowance is exhausted, delivering the failure notice must not remove unfinished work from the pending count. Read the existing Core correlation and failed Turn to keep that backlog visible across reply-worker restarts, without starting a model or sending a message from the health read.

Recovery also observes later source /stop and /new commands for failed requests. The typed owner vetoes new execution while preserving exact correlation repair for an already admitted continuation. Existing native effect, allowance, binding, audience and bounded retry checks remain in place.

Validation: 323 Python conversation/transport regression cases, five focused source-stop and original-return cases, 34 TypeScript binding cases, and the standard premerge gate passed. The new pending-count case and source-stop case each reproduced the previous failure before the fix. A read-only existing-store check confirmed the count correction without creating a Chat store or provider consumer. No frontend markup, configuration default, model allowance or execution permission is added.

[loopx-agent]

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

Reviewer: model_agent; gpt-6.1-sol; OpenAI; runtime_reported; reasoning_effort=max

动机 / Motivation

使用私聊助手提交任务、在额度耗尽后等待补办的用户。原先失败通知一经送达，待办数就排除该请求，且之后的停止指令没有覆盖这类失败；现在请求继续显示为待办，后续停止能阻止新的接续执行。已验证失败通知与业务完成分开计数，并在原回复 worker 的准入路径落实原会话的停止意图。本 PR 不新增消费者、队列、额度、权限或自动重放路径，也不承诺所有历史业务已经完成。既有 worker 仍须逐条核验原消息、绑定、额度和无副作用证据；线上补办、原消息最终回传与安装采用各自验收。

改动思路 / Approach

沿用既有 Core 请求、Turn 和控制日志派生事实，由原 TypeScript owner 决定准入，健康读取只做展示投影。本次边界是修正待办投影和接续前的停止判断，保留原调度、重试预算、发送及读回责任。失败通知送达只证明用户收到故障消息，不能替代原任务结论。这里直接复用持久请求和 Turn（一次执行）的关联，没有再建可编辑队列；原 worker 仍拥有额度检查、保留现场及回传责任。后续 /stop、/new 来自同一绑定与来源的真实控制日志。已入队接续的身份修复先行，仅认领精确的既有执行，停止判断则放在可能产生新执行之前，避免把“取消”变成重复派发。

输入状态	旧行为	本次行为
quota 失败且通知已送达	待办为 0	仍为 1，读取无执行效果
原来源之后发出停止	仍可能成为接续候选	拒绝新接续
已入队的精确接续，随后停止	恢复原关联	保持原关联，不再入队
其他绑定停止或后来的独立新请求	各自独立	保持独立

表格说明 28eaab427e8b509107bdd38552dc53128ab0e22d 的已检查分支；下面的测试承担执行证据。

具体改动 / Changes

关键代码讲解

1. LarkPrivateConversations.health 只对原传输目录中已送达的普通请求补读 Core，核对 binding/source/session/turn 四个关联再统计 quota 失败。Web 投影、成功结果和其他失败保留既有分支；读取不调用模型、原生控制或消息发送。
2. _context_recovery_plan 将后续同来源控制的采集覆盖全部 failed/completed 状态。输入来自完整持久请求日志，不依赖 UI 分页或人工维护标志。其他绑定的停止不进入当前请求的判断。
3. planContextRecovery 在精确既有接续的关联修复之后、routing/quota 新准入之前应用停止否决。原有 source、grant、Session、完整原生历史、额度新鲜度、退避和三次上限不变。

依据 spec_ref：docs/reference/protocols/manager-evidence-and-continuity-v0.md，spec_revision：8ff9da5d2f3b253113c5a7bf7b9d3f6af8c41137（固定版本）。该实现基线未在本 PR 改写。准则 Ownership and defaults 对应原来源/权限/停止意图与 Core 单一事实；采集与 typed veto 已实现。准则 Requests, authority, and recovery 对应失败通知不结束原请求、保留原失败与预算、独立最终回传；计数和既有回复路径符合，未把候选当作业务完成。

六文件共 92 行新增、4 行删除，三处生产改动，其余为回归。相同新用例在完整基线生产源码上得到两处预期失败、两处通过；本次代码四处通过，区分了“计数错误”和“停止遗漏”，成功结果和 policy 失败均保持待办为零。另有五个源控制/原回传用例、34 个 TS 用例通过。323 个较广 Python 回归是停止修复之前的观察，只复用于未变路径；新增风险由最后的专门用例覆盖，不将其宣称为最终 head 的整套重跑。

对主干的风险 / Risks

主要代价是健康读取对已送达原请求增加本地 JSON 读取，以及更多失败类需要扫描同来源控制日志。未添加缓存索引或第二状态源，避免为少量投影逻辑引入同步责任。若持久记录损坏，保持读取失败或不准入，不把未知当成任务已完成。回滚可用既有安装与空闲激活路径；失败 Turn、原通知与确定性接续关联无需迁移。

最有价值的反例是停止发生在“已入队、未写回关联”窗口：若把否决放在身份修复之前，会丢掉既有工作关联。本次 TS 四组 project/steward × routing/quota 都覆盖这一路径，同时拒绝 foreign Session、消息、client id、附件及过时/未来额度观察。真实私聊入口用例还验证其他绑定停止不影响本源，旧停止之后的新独立请求能完成。健康计数不参与准入，零次额外模型/消息调用由 restart 用例比对读写记录确认。

语义与 CI 对齐

这里 reuse_existing：沿用 pending、failed、usage_limit_exceeded 和 stop_observed 词汇，不新增 Goal 义务、权限或重试分类。最终 head 的 standard premerge 已通过差异/编译/双语检查、两个 catalog 与八个风险 smoke，语义词汇漂移检查通过且无人工 hold。本 Goal 的独立 change-quality receipt 策略未启用。按已解析 wait_for_ci=false，没有查询、轮询或等待远端 CI；合并就绪与授权仍单独核验。

我的整体评价 / Verdict

这是 justified_increment：long_horizon=improved，恢复后仍能发现未闭请求且不重复执行；user_experience=improved，既有待办数字更真实、原停止入口生效。用户无需新增配置、复制旧消息或再确认一轮；未完成业务的最终结果继续由原 worker 沿原受众回传。已检查 apps/presentation/dashboard/src/features/personal-workspace/private-conversation-panel.tsx:153；既有数字字段消费不改变页面结构、样式或交互，visual_review 为 not_applicable。未重新执行桌面布局或窄屏视觉验收；这些渲染面未改动，安装采用另行读回。

生产机制保持原所有者边界，代码量必要且与问题相称，未增加持久格式或兼容分支。基线到本次 head 的有意变化已由相同入口反例证实，没有已知阻塞 finding；额外本地读取的成本和线上容量/业务结论仍是明确边界。原生存在工具或未知效果的失败不能按这条路径盲目重放。当前结论不替代安装采用、真实积压完成或 GitHub 合并检查。

English verdict: APPROVE 28eaab4. The pending-count and later-source-stop regressions are reproduced on the base and covered through the real Core/transport path; exact admitted identity repair is preserved. Live delivery and deployment adoption remain separate acceptance steps.

[songoow]

Reviewer: model_agent; GPT-6 Astra Pro; OpenAI; self_reported.

动机 / Motivation

合并后发现 P2：同来源已经停止的 quota 失败仍永久计入待处理数量。

额度耗尽后在原私聊停止任务或开启新会话、再查看待处理数量的用户。

原修复让失败通知送达后仍显示未完成工作，但同来源停止或新会话已使该请求退休时，展示仍沿旧失败状态计数。

独立实跑确认新恢复被正确拒绝，旧请求仍持续显示为一项待处理；这是展示与生命周期不一致。

本意见只要求正确投影明确退休的请求，仍等待额度的有效任务必须保留；不要求自动重试、删历史或扩大权限。

原修复已交付积压保留和来源停止准入，但缺少退休状态到待处理展示的闭合。

改动思路 / Approach

生产机制总体沿原所有者；本次缺陷应在Core退休事实与health只读展示之间补齐，保留既有准入与历史。已合并原修复保留；后续PR修复已退休请求仍显示pending，不改Stop authority、不重放或删除历史。

旧失败Turn和故障通知应留作证据；是否还需要执行或回复则必须从当前生命周期派生。不能为了让数字归零而删旧记录，也不能把所有当前不可重试的工作都判为完成，因为额度等待和临时禁用仍可能是有效待办。建议让现有Core提供明确退休的只读判断，transport只负责消费和展示，避免第二份手工同步状态。

具体改动 / Changes

关键代码讲解

审查准确提交 28eaab427e8b509107bdd38552dc53128ab0e22d；基线 8ff9da5d2f3b253113c5a7bf7b9d3f6af8c41137。相关生产文件与本轮最新主干 0e78a19c277f4ca3d44313787162bc0444065172 无差异。

1. LarkPrivateConversations.health 对已送达通知重新读Core关联，只要旧请求仍accepted、原Turn为usage_limit_exceeded就计入pending。它没有消费之后的来源停止或Session退休事实，问题位于新增的228–240行。
2. _context_recovery_plan 已收集相同binding/source之后的stop/new，且扩到failed/completed。原来源停止的采集修复是有效的。
3. planContextRecovery 拒绝已关闭或身份不再匹配的Session，并在既有已入队身份修复之后、任何新routing/quota准入之前否决stop。这保证了没有因这个计数问题绕过Stop启动工作。

规范为 docs/reference/protocols/manager-evidence-and-continuity-v0.md，spec_revision：8ff9da5d2f3b253113c5a7bf7b9d3f6af8c41137。Ownership and defaults 要求Core持有生命周期和真实工作事实，当前health对明确退休请求的投影未满足。Requests, authority, and recovery 中保留失败、预算、来源授权和原返回路径的要求仍由现有owner承担；本意见不要求更改这些边界。

对主干的风险 / Risks

实际通过原transport入口、真实Core与持久文件，模拟provider产生quota失败；在backoff之后确认原请求仍是恢复候选，再分别发送同来源 /stop 和 /new。两组观察完全一致：

阶段	恢复候选	待处理数
失败通知已送达、未停止	true	1
同来源stop/new后	false	1
重启reply worker后	false	1
新独立请求已完成并送达后	false	1

PASS：准确head的原quota/policy/success/source-stop四例，加两例上述组合观察，共6例执行完成。这里组合probe的PASS表示反例成功复现，并不表示产品展示正确。旧失败Turn在整个过程中未变化，health未新增模型调用或发送。原测试分别证明保留积压和拒绝停止后的准入，却没有断言两条路径组合后的展示，因此会漏掉该回归。

语义与 CI 对齐

这是原生命周期词汇与投影的对齐问题。最小修复：由现有Core只读语义区分已被同来源stop/new退休的请求与暂时等待额度的请求，health复用该判断；保留旧Turn/通知，不把pending简单等同当前可重试，也不为清计数触发执行。 回归须覆盖stop/new、worker restart、新任务完成、其他绑定控制不干扰，以及未取消的quota等待仍保留pending。未为本次合并后审计重做全套base/head恢复矩阵，不声称完整兼容性资格；具体反例已经在准确head独立运行，且当前主干相关代码相同。

我的整体评价 / Verdict

原修复的有效价值应保留：long_horizon=improved，暂时额度失败的真实工作不再丢失；user_experience=regression，明确退休的工作留下无法通过正常继续工作清除的待处理提示。建议后续PR修复这一P2展示与生命周期不一致。这里只审查既有待处理数字的数据语义，未修改页面结构或视觉布局；没有将自动检查当作全页视觉验收。 未做真实飞书发送、实际模型调用或桌面/窄屏视觉验收；使用本地合成provider与真实Core和文件状态。

English verdict: REQUEST_CHANGES for the pending-count projection in a follow-up PR; this is a POST_MERGE_AUDIT_COMMENT on 28eaab4.