[loopx-agent]

Goal and delivered outcome

Repair two browser acceptance scenarios for Goal creation. The stored workspace scenario regenerates a proposal without adding an execution request, then confirms the existing Goal creation. The real workspace selection scenario confirms a Goal with an explicit original Task request and reads back the committed Task and Session for the selected workspace. These are the failures in the Dashboard and packaged browser jobs on #8266. Stored proposal failure · Real workspace selection failure

The stored proposal wait now matches the Goal confirmation for its saved parameters. The synthetic runtime supplies the registry, store and queue boundary used by the real creation handler. The workspace selection scenario checks the HTTP confirmation, original Task and Session IDs, read-only permission and empty write scope. This targets main.

Author declaration

Written by Codex, OpenAI. The existing confirmed Goal creation contract in #8805 is the acceptance source. Goal creation and the original Task

Validation

Tested file contents at fa5f8acdf1018cadc8a599b699f81dfab9d2f4ef with synthetic fixtures and isolated local state.

Check	Result	Evidence
Baseline reproduction	Failed as expected	The two Main scenarios reproduced the CI timeouts. The workspace selection apply returned HTTP 424 with an incomplete fake controller interface.
Development browser	Passed	typed-actions and goal-workspace-selection through examples/personal-workspace-browser-smoke.mjs.
Packaged browser	Passed	Rebuilt the Chat bundle and ran both scenarios with LOOPX_PERSONAL_WORKSPACE_PACKAGED=1. Workspace selection used the real HTTP and registry path with synthetic dispatch.
Typed-action service	Passed	uv run --extra test python examples/loopx-chat-actions-smoke.py.

Scope and continuation

This repairs the existing smoke fixtures and assertions. UI impact is none. Hosted browser and Windows status remain separate checks for #8266 after it synchronizes with main.

• Test 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)

动机 / Motivation

维护 Goal 创建流程的人运行浏览器回归时，需要验证历史提案的确认权限和新建 Goal 的明确启动请求。 旧测试在恢复仅创建的提案后一直等启动按钮。实际工作目录场景也因测试后端缺少确认所需的接口而超时。候选可完成两类确认，并能直接报告 HTTP 或权威回执错误。

两条打包浏览器场景通过。额外读回核对了确认后的原 Task 检查点、Session 工作目录和仍开放的 Todo。把回执权限改成可写时，浏览器断言失败。 打包浏览器调用真实 HTTP、确认服务和本地状态，模型派发由 fixture 提供。实际安装、模型执行及原 Task 完成仍需各自证据。

改动思路 / Approach

这次变化集中于现有浏览器 fixture、动作 smoke 和验收断言。 历史提案重新选择目录后，继续使用已保存的启动意图。明确启动时，测试 backend 通过既有确认服务和本地状态提交 Goal。合成 runtime 在队列边界核对已保存的 Session 与工作目录。这样既保留原界面的权限区分，也能在确认失败时显示实际错误。现行创建合同 · 已交付约定

具体改动 / Changes

关键内容讲解

• stored-create-only-intent 已实现。历史提案在选择目录后比较原 start_execution，确认之前检查零写，点确认后读回一次写。测试其它位置的中英文显式开始控件保持自己的条件。历史提案与重新确认
• saved-original-workspace-task 已实现。真实 POST 返回成功后核对 Task ID、Session ID、只读权限和空写范围，再从 registry 验证 Goal 实际落到选定目录。独立的本地读回验证已保存的原任务检查点、Session 和 canonical Todo。确认检查 · fixture 的真实持久化边界
• preview-refusal-and-recovery 已实现。预览 503 或目录不可用时保留选择和目标，registry 未新增 Goal。目录恢复后完成该次确认。按 docs/architecture/rfcs/monorepo-distribution-split-v0.md 和用户指南的目录与原任务操作核对。预览失败与恢复用例 · 工作目录用户指南

对主干的风险 / Risks

历史提案在精确启动按钮处 30 秒超时。工作目录确认收到 HTTP 424，随后在进入 Goal 的等待处超时。 同一打包入口的候选两条场景通过。工作目录确认返回 202。独立把回执的权限改成可写，新增断言按预期失败。原 action smoke、21 条工作目录测试和 diff 检查通过。

另跑了四个 Core 文件，两个版本各有 25 项通过，52 项失败。失败节点及归一后的异常完全一致，其中一类是在独立原 Task fixture 未生成预期验收提案。该现象的根因未查明。此次浏览器修复的必要行为由上述本地打包、真实写入和独立读回覆盖。更广的两个原 Task 测试套件有 52 个匹配的基线失败。输出现有原 Task 启动/准入路径的最后验证范围尚不能由这个 fixture 推出。

我的整体评价 / Verdict

保留用户看到的两种确认权限，并使当前浏览器验收能分别验证。原 Task 的持续运行仍由已存在的准入和队列所有者处理。测试复用原场景，已关闭的 #8815 指向这份联合修复。检查了 Goal 对话、浏览器断言和相同构建产物的路径。此提交没有改变渲染代码。 真实用户安装、现场模型和原 Task 完成超出本次浏览器 fixture 范围。 在 fa5f8acdf101 给出通过结论。#8815 的后续指向

English verdict: APPROVE at fa5f8ac. Both packaged browser scenarios pass, genuine workspace confirmation retains the read-only original Task and Session, and the mutation test rejects broadened receipt permissions. The broader Core failures reproduce on the base.