fix(acceptance): recover reviewed check plans across progress

[loopx-agent]

An Agent-prepared delivery check could be rejected after an ordinary progress update or a lost preparation reply, forcing the same plan to be prepared again. Keep the reviewed work context stable across unrelated progress and recover the original prepared request, so the owner retains the same Use plan and check decision.

The TypeScript acceptance owner binds the reviewed configuration, covered work and Goal lifecycle. Actual writes still compare the current provider revision; native receipts retain the original operation identity. The existing preparation adapter now recovers an unchanged Goal/preparer/document request before creating another preview, including a competing commit. It reads current canonical availability and returns the original state without refreshing its fingerprint. Different intent or preparer still conflicts; cancelled, stale and applied plans stay in their original states. No check is automatically rerun.

Basis and scope

Written by: model_agent, OpenAI GPT-6 family; exact serving variant is not verified here.

Implemented against the existing owner-authorized acceptance contract, revision fdf03ec6112aedf497b7ab1d6e5bc4db19c2ae5f.

Accepted requirement	Disposition	Owning implementation and evidence
Agent prepares; one local-owner decision adopts and checks	Implemented for this recovery slice	Existing preparation/action journal; real packaged SQLite/HTTP/CLI journey after a lost tool reply and canonical note update
Original operation recovery, no duplicate effects, current version checks	Implemented	TS review context/CAS and immutable receipts; File/SQLite retry, race, changed-work/configuration and source-unavailable regressions
Full live-model correction, independent semantic acceptance and requester adoption	Outside this bounded defect repair; remains open	The original L1 qualification retains its full acceptance

This completes preparation/application recovery within the existing delivery-check interaction. Native Goal Chat prepare_check, registered-Agent CLI preparation and the existing workbench owner action share the same plan. No Lark action, new editor, model call, automatic execution or authority is added. Python retains transport/journal recovery; acceptance decisions stay in the existing TS owner. The small companion refactor centralizes saved-intent lookup rather than adding a tool or another configuration path. Historical revision-only plans retain strict admission.

Validation

Tested head: 564ebba32e7ece93a07174df0bbe774d88a9090b; base: fdf03ec6112aedf497b7ab1d6e5bc4db19c2ae5f. Run state: finished. Inputs: synthetic and public fixtures.

Check	Result	Evidence and limits
Regression parity	Passed	Six recovery cases failed before the fix across actual File/SQLite; the same cases pass after it. Cross-preparer refusal passes both versions.
Python integration	Passed	140 tests: full prepared-action, acceptance CLI, oracle and Chat LoopX mode modules. Includes real File/SQLite, native admission, lost replies, concurrent commit, terminal state preservation, stale work/configuration and unavailable authority.
TS / real backend	Passed	109 acceptance authority/oracle/runtime tests, zero skips, on File/SQLite and a disposable real PostgreSQL 16.15 server. The isolated server was removed afterward.
Packaged frontend / real entrypoint	Passed	Fresh build and source verification; the original plan survives lost preparation response plus progress, then one keyboard owner action adopts and checks. Exact native readback, changed-output withdrawal, failure/recovery, rejected import, disable, 390px and reduced motion pass. Model and tool transport are scripted; this does not qualify a live model or installed App.
Static and boundary	Passed	Control-plane typecheck, configured mypy (17 modules), changed Python Ruff, advisory before full semantic smoke, all-seven-path native public-boundary scan, DCO and bilingual/diff checks.
Native premerge	Passed	Standard tier: 6 direct checks plus 14 selected checks executed, zero failures or warnings. Exact-scope change-quality receipt is valid for this head and base.

Remote CI and independent review of this updated head are separate. This PR does not change storage-provider routing or promote an authority; File/SQLite/PostgreSQL conformance above covers the existing owner boundary. No active Goal is used as a mutable test fixture.

Frontend impact

Presentation: none. No first viewport, navigation, CTA, stylesheet or frontend source changes. The existing approved workbench interaction is exercised against its actual disposable backend; JSON import stays optional. The new browser backend scenario makes lost-response recovery part of that ordinary journey. No merge, release or installation is performed by this update.

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

Exact head: 12fb840

动机

负责人拿到 Agent 准备的交付检查方案后，若 Agent 先补一条进展备注，原方案就可能在点击“采用并检查”时过期。
旧实现把整个 Goal 的存储版本当作方案依据，即使只改备注或选定范围外的任务，也要求重新准备。修复后，这些无关进展保留原方案；已覆盖的工作要求、所有者配置或 Goal 实例变化仍阻止旧方案执行。
实际隔离 File/SQLite 调用证明，无关进展后仍能采用并检查一次，重复申请不再执行第二次；配置回执丢失后的备注变化也能恢复。
本次修复方案新鲜度与恢复判断，不授予 Agent 配置权限，不自动执行检查，也不证明远程身份、真实模型采用或整个 Goal 已完成。

改动思路

方案语义由既有 TypeScript owner 从规范事实派生，Python 只携带摘要并消费原生回执；实际写入仍保留当前 CAS，没有增加独立状态 owner。
当前范围是既有准备、采用、恢复链路的依据修复，沿用现有概览交互和本机所有者边界。

这里区分“负责人审阅的内容是否变化”和“这次存储写入是否发生竞争”。前者使用已有的工作语义摘要、规范配置和精确 Goal 生命周期，排除检查结果等观察；后者仍对刚读取的存储 head 做 CAS，也就是只有版本仍一致才能提交。摘要匹配不是新的授权令牌，Agent 配置、旧实例、冲突操作身份仍被原有规则拒绝。

独立同环境对照的结果如下，每种情况都经过真实 File 和 SQLite owner：

准备后的变化	不可变基线	当前 head
无变化	检查一次，重复申请不重跑	保持相同
已选任务加备注；新增范围外任务	原方案过期，零检查	可采用，检查一次
已覆盖工作要求改变；另一个所有者配置	拒绝，零检查	保持拒绝，规范 head 不变
配置回执丢失后加备注	恢复遇到依据冲突	恢复原回执，检查一次
配置回执丢失后被重新配置	拒绝恢复执行	保持拒绝、零检查
历史纯版本方案加备注	继续严格拒绝	保持严格拒绝

只比较文档或删除全局版本检查都会漏掉重要约束。这里复用既有 scope、工作摘要和原生操作日志，不增加第二个验收配置库或要求用户手工同步摘要。

具体改动

关键代码讲解

• reviewContext：从当前 Goal、生命周期、规范化方案、现有验收配置和覆盖工作派生摘要。排除 verification 观察，不排除配置修订、工作要求或 Goal 实例；范围复用已有 goalAcceptanceWorkDigest。
• configureGoalAcceptance / commit：先核对不可变操作回执。新方案可用匹配的审阅摘要通过无关进展，但真正提交仍比较刚读到的 provider 版本；回执身份绑定原请求，返回原配置上下文，不能借后来配置替换原依据。
• _apply_acceptance_check：Python 携带而不重新判断摘要，复用已有锁、检查点和原生 configure/verify。新旧持久化方案分支有实际兼容需要：旧方案没有可恢复的语义依据，继续严格版本检查；已开始而缺少对应原生结果的检查继续保持不确定，不自动重跑。

另一个 Python 文件只转发可选字段；公开投影仍隐藏可执行声明和内部审阅摘要。两份现有测试补充范围隔离、竞争提交、历史方案和丢失响应；文档以中英文明确行为变化。全提案六文件 +225/-12，没有新能力、设置页、CLI 参数、provider 实现或自动启用行为。

依据为修改前已接受的 docs/reference/goal-acceptance-observations.md，固定修订 dededb6：

• Owner-authorized contract (v0)：已实现；Agent 准备不配置、不执行；本机所有者一次“采用并检查”，回执与不确定启动边界保持。真实打包页面发现方案、一次 Enter 采用、经原生 owner 读回当前版本；额外场景在准备与采用之间真实提交备注后，同一旅程仍通过。
• selected_work：已实现；选定工作与独立工作按原有范围处理。覆盖要求、配置、生命周期变化仍拒绝；竞争提交仍精确 CAS，不能修改工作来逃逸 owner 绑定。
• Owner-pinned oracle and exact versions：保持；真实来源/输入/输出版本变化会清除当前通过状态，修复后需明确检查。历史通过、截图、方案或摘要都不等于实际采用或 Goal 完成。

本次先按上述既有合同判断，再审查新增文档；没有用新文档反向定义正确答案。实际分叉基线是 dededb6；移动中的 PR 目标主干为 04b929a，两者差异只有四个无关 Lark 路径，验收规范的旧 blob 相同。

对主干的风险

未发现阻断项。最大风险是“容忍无关变化”同时放过真正的工作、配置或实例变化，或丢失响应时把后来状态冒充原操作依据。独立 16 例/版本的真实 CLI 与服务对照保留上述相反方向，拒绝后检查器零执行、规范状态逐项相同；另在三个真实存储 provider 执行竞争写入、操作身份冲突、工作范围逃逸和生命周期测试。准备和重复 apply 没有增加执行次数，缺失已启动检查结果不会自动重跑。

独立验证：三个完整 Python 模块 106 项通过；三个完整 TypeScript 模块 109 项通过、零跳过，包含专用隔离 PostgreSQL 16.15、File 和合格 SQLite。正常打包构建、现有完整 oracle 浏览器场景，以及仅插入真实备注更新的同场景均通过；后者使用私有派生测试副本，保留原断言与真实 SQLite/HTTP/CLI，未修改产品文件。模型与原生工具传输仍是脚本化输入，不能称安装后的应用或真实模型采用已验证。

已查看打包桌面待采用首屏和 390px 当前结果：目标、覆盖范围、命令影响和一个采用动作在工作列表之前；技术细节收起，未知统计仍未知，没有新增设置或填写要求。改变产物清除绿色状态、检查失败与修复、非法高级导入的 409 及状态保持、停用、键盘和减少动态效果路径也通过。

语义与 CI 对齐

扩展既有原生请求/回执中的可选上下文字段及本地冲突原因，不新增共享状态 owner。先跑 advisory，再跑完整语义检查；扫描无候选不等于没有语义变化。原生 premerge 的 6 个直接检查和 14 个选定检查通过，零维护者确认项，Ruff 与控制面类型检查通过。首次构建命令定位到不存在的旧目录，退出 254；改用现有 Dashboard 包的正常 build:chat 后通过，没有源代码修改或门槛调整。依策略未查询 CI。

我的整体评价

APPROVE。长期工作与用户体验均改善：日常进展不再强迫重新准备，恢复能继续消费原意图；真实要求变化和写入竞争仍保留明确拒绝。已知上下文由 Agent 准备，用户仍只作原本需要的本机命令授权决定，没有新增确认轮次；若原始意图或权限缺失，依旧不能省略该决定。

面向后续变更的简化检查采用现有 typed owner、工作摘要和日志，避免重复 Python 决策与新编辑器。历史分支服务真实持久化提案，暂时保留比猜测旧批准内容安全；回退旧运行时可能要求重新准备新格式方案，但会安全拒绝，不增加执行权限。前端沿用现有完整交互，Lark 无新动作。历史经验只用于当前有用结果判断，不继承旧结论或认证记忆收益；本次完成这个修复，不认证整个 Goal、部署或合并授权。

English verdict: APPROVE - 12fb840 keeps reviewed plans usable across unrelated progress while preserving owner authority, semantic invalidation, exact write CAS and immutable retry identity. Independent paired native counterfactuals, 106 Python and 109 TS tests including real PostgreSQL, and packaged real-owner adoption/recovery paths passed. CI was not consulted; live model adoption and installed App behavior remain outside this review.