feat(chat): prepare delivery checks in Goal conversations

[loopx-agent]

Goal conversations could display and adopt an acceptance plan, but their native execution tool could not prepare it; preparation required a separate CLI call. Add prepare_check to the existing, explicitly enabled loopx_collaboration tool, using the existing goal.acceptance.check proposal and TypeScript acceptance owner. The host binds Goal, preparing Agent and runtime. Preparation neither changes governance nor runs commands. The existing delivery panel discovers the proposal and retains one Use plan and check action.

• Reject identity/root overrides, invalid plans, inactive/paused/obsolete Turns and revoked configuration. Unchanged requests replay the saved proposal; conflicting retries retain it and return reconciliation context. Document rejection returns repair guidance to the Agent.
• Extend the existing packaged journey to prepare through the admitted conversation callback instead of pre-seeding via CLI, then adopt, check, invalidate changed output, recover failed checks and disable through the actual SQLite/HTTP/CLI owner.
• Frontend composition and CLI behavior are unchanged; Lark is unaffected. prepare_check is local to the existing native tool schema, not a new shared action/state vocabulary. The shared persisted action remains goal.acceptance.check. Python only adapts the native host; it adds no parallel decision owner. The related refactoring pass reuses the existing preparation function rather than duplicating validation or creating another capability.

Validation on integrated head ec55b0b40 (current main 7ed24c6c9; the six proposal paths are unchanged by integration):

• 70 native preparation and conversation tests passed against isolated File/SQLite owners.
• Full Stage2C source recovery suite: 263 passed; two optional benchmark modules skipped at collection because sforge is unavailable. All 55 deliberate mutants had passing controls and assertion failures.
• Packaged native-callback → SQLite/HTTP/CLI delivery-check journey passed, including output invalidation, failed-check recovery, rejected advanced import, disable/default-off, desktop/390px, keyboard and reduced motion. Four packaged team evidence/feedback/use/revalidation recovery journeys also passed.
• Normal bundle build/source verification, Ruff, semantic-vocabulary smoke, public-boundary scan and diff checks passed. The integration consumes existing main fixes for stale browser labels, default-P1 expectations and opaque Todo-ID fixtures; it does not weaken assertions or change the product defaults.

The earlier strict module mypy comparison at e738596e6 was red on both base and then-head (71 errors each, no added messages). A new full configured-mypy pass is not claimed. Hosted CI on this new head and independent exact-head review remain separate gates. No installed App, PostgreSQL refactor or Windows qualification is implied.

This closes the missing advertised caller in the Live Team delivery-check path, not the entire L1 acceptance. Native transport/model interpretation is scripted in these tests; installed App behavior, live-model intent recognition and independent acceptance/adoption are unqualified. An older native thread may not advertise the new action; unfinished threads are preserved rather than replaced to add tools. Existing registered-Agent CLI preparation remains available. Count missing intent or authority from the original task, not just the final button.

[loopx-agent]

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

Approval conclusion (author-owned PR; GitHub blocks formal self-approval). Exact head ec55b0b402147dc3a263195a886a9d5b0260dfca，真实 Git merge-base 7ed24c6c95f9b16f485e57a54d15893ac6079c2f。

动机

在已显式启用 LoopX 的 Goal 会话里，请 Agent 为当前交付准备验收方案的所有者。

原会话工具无法保存交付检查方案，用户需要另外运行技术命令；本 head 可由已获准的会话回调准备同一方案，随后在交付旁一次采用并检查。

准备只保存可审阅方案；所有者采用才配置并执行，版本变化会撤销旧绿色状态，失败后可修复重查。

本切片不自动启用 LoopX，不升级旧原生线程的工具声明，不认证模型理解、已安装 App、独立复核、实际采用或 Goal 完成。

改动思路

原生会话只增加既有验收能力的适配入口；方案、配置、执行和读回继续由现有 Chat action 与 TypeScript owner 决定，避免第二个治理状态源。 本 PR 的边界是既有工具的 prepare_check 动作及真实后端旅程验证；复用已发货的交付面板，无新界面、配置开关、共享状态协议或执行授权。 不改动用户已有的同意边界：Agent 根据已知需求、任务和文件准备方案，人类在交付旁审阅并决定是否更新关联、运行本机命令。已有意图不需要用户重新装配 JSON 或内部 ID；真正缺少的事实与权限仍应澄清，不能为了减少点击而推断同意。

路径	本次核验
原生 prepare_check	当前会话/Turn/配置校验后保存已有 proposal；治理与命令均无变化
所有者一次采用	打包面板发送一个 apply POST，真实 SQLite/HTTP/CLI 读回 accepted/current
产物变化与恢复	只读刷新令旧结果 stale 且 operation不变；显式检查失败，修复后重新检查通过

该表是本次本地入口观察。原生传输与模型意图是脚本化输入；验收 owner、SQLite、HTTP、命令与包内 UI 真实。截图已经查看：同一完整 viewport 内 Goal/责任、当前状态和主动作清楚，390px 无横向溢出，键盘 Enter 可完成采用；不是模型或已安装 App 采用证据。

具体改动

规格为改动前已接受的 docs/reference/goal-acceptance-observations.md，spec_revision 7ed24c6c95f9b16f485e57a54d15893ac6079c2f。agent-prepares implemented：通过已声明的会话工具准备已有方案；owner-effect implemented：准备不执行、交付旁一次所有者采用才执行；recovery-and-readback implemented：原方案/原回执保留，未知结果先对账，历史通过不覆盖新字节；scope-and-off implemented：现有选定任务范围和权限 owner 保持，普通会话默认关闭与注册 Agent CLI 不变。新文档只是说明原生入口与旧线程边界，不将作者新描述当成独立规格。

关键代码讲解

1. TOOL 仅在显式工具集中增加 prepare_check、稳定 operation_id 和 document。公开 schema 不提供 goal_id、agent_id、runtime_root；description 明确准备只产出可审阅方案，不配置、不执行、不伪造 oracle 或授权。原执行 GUIDANCE 增加复用已知需求的准备路径，保留原有成员验收、采用、等待、身份与不宣称 Goal 完成的义务。
2. prepare.dispatch 先在同一 session fence 中重读 enabled/paused/active_turn_id/stopped，并再次检查当前注册/执行配置；随后要求恰好三项参数。Goal、准备 Agent 与 runtime由宿主提供，再调用旧 helper。冲突保留原方案并给出对账指引，文档错误返回修复上下文，不能通过换身份使错误输入通过。
3. prepare_acceptance_check 和 _apply_acceptance_check 均为已有 owner：前者复用 typed normalization/authority preview/ChatActionStore，只保存 proposal；后者沿用 per-proposal lock、provider CAS、配置及 check-started checkpoint。前端不用新增配置面；现有交付面板发现方案，local owner apply才到真正执行。读取、失败、未知或重放不自行获得新的命令执行许可。

新增测试聚焦真实 File/SQLite 原生回调与入口广告隔离；既有打包场景把 CLI预置改为实际 admitted callback，再复用其后端和现有 UI。没有第二个 Python 决策 owner。前瞻整理已落实为共享既有 proposal/helper，额外抽象、新编辑器或旧线程强制迁移均无必要。

对主干的风险

独立98个 native/prepare/CLI 用例全部通过，无跳过，覆盖 File 与 SQLite、注册/范围错误、暂停/disabled/其它Turn/stopped/撤销配置、重复请求、冲突与文档修复。另以同一 fixture 在不可变基线与本 head 调用真实原生 handler：基线拒绝新 action，当前保存 proposal且原 acceptance完整不变、没有运行文件。普通模式完整动态工具 schema 与 objective在两版完全相等；enabled schema只增加声明能力，不自动启用模式或所有者效果。

正常 frontend package build与 verify --source、Ruff、配置要求的19文件 mypy在 base/head、advisory后完整 semantic smoke 均通过。首次误用不存在的 checker脚本只是本地命令错误，未记产品失败；随后运行仓库实际 semantic smoke通过。advisory空结果不覆盖匿名枚举，因此本次仍逐条检查新本地 action 与共享 owner。

Ego 通过实际打包资产和真实 disposable SQLite/HTTP/CLI 完成发现方案、一次键盘采用、当前版本读回、变更产物后只读失效、显式失败/修复重查、非法oracle命令导入拒绝并保留完整旧状态、刷新对账及停用后面板消失/原生enabledFalse。首次页面等待误用了fixture标题、一次snapshot参数不符合Ego API，均只改本地观察方式；未修改产品、放宽断言或重复执行采用。旧绿色失效时原operation_id保持，说明刷新未运行新检查；实际失败后的修复有完整可用结果，不以 blocker receipt代替恢复。浏览器已finish，自有后端关闭。

语义与 CI 对齐

prepare_check 留在工具本地 enum；共享 goal.acceptance.check、scope、proposal/checkpoint与 TypeScript 验收 owner原样复用。普通模式的 schema、提示、输入与效果均保持基线；准备不是执行，检查通过不是独立复核/采用/Goal完成。旧原生线程广告固定且不会为新增工具替换未完成 Goal，CLI仍可用；这项限制已明确披露。未获取或等待 hosted CI；也未把脚本化模型输入、UI截图或本地测试推成已安装 Host与实际模型采用。

我的整体评价

APPROVE。长期推进维度 preserved：沿用原proposal、CAS、check-started与未知结果对账边界，重复/撤销不扩张效果，之后产物变化与失败均能继续到真实修复检查。用户体验维度 improved：从已知请求到可用检查，Agent承担准备工作，所有者仅保留一次有后果的本机执行决定，不需另写技术合同或进入设置；额外澄清只针对实际未知事实/授权。原生会话只增加既有验收能力的适配入口；方案、配置、执行和读回继续由现有 Chat action 与 TypeScript owner 决定，避免第二个治理状态源。 本 PR 的边界是既有工具的 prepare_check 动作及真实后端旅程验证；复用已发货的交付面板，无新界面、配置开关、共享状态协议或执行授权。 这足以关闭所述原生入口缺口，父路线图、模型理解及安装采用仍需各自证据。

English verdict: APPROVE — exact head ec55b0b402147dc3a263195a886a9d5b0260dfca. The explicitly enabled admitted native tool now prepares the existing check proposal without configuring or executing it.98 real File/SQLite tests, paired base/head and exact default-off schema/prompt comparisons, packaged build/freshness, configured mypy/Ruff/semantic checks, and the real SQLite/HTTP/CLI Ego adoption→stale→failure→repair→disable journey pass. Model/tool transport is scripted; installed-App and independent adoption remain unproven. No merge authority is granted.