[loopx-agent]

普通 Goal 创建表单已经确认了完成标准，创建服务却只保存目标文字和首批 Todo；首项完成后，持续要求 owner 看不到这份标准。本改动在首个会话启动前，将明确的 completion_criteria 接入已有 outcome owner。首批工作完成但要求未满足时，继续走既有 frontier/replan；不增加开关、计时器、控制器或 benchmark 特判。

创建中断沿用原 operation、provider revision 和声明重试。写入响应丢失不会先启动 Host；首轮响应丢失后恢复同一会话和 Turn。已知 CAS 冲突保持未确认，不自动重基。没有完成标准时不从自由文本猜要求；标准需要已选择的执行 Agent。已启动过会话的历史创建记录不自动迁移，旧检查、Stop、权限、预算和原生 Goal 自然结束语义不改。

TypeScript 负责从已审请求构建声明及校验恢复阶段；Python 保留现有 IO 效果适配。两个新增 checkpoint 阶段属于既有创建操作的局部恢复词汇，不是新的执行状态机。单项要求描述从 512 对齐到 2000 UTF-16 单元，以完整保留表单已经支持的 1000 Unicode 码点；两个 131072-byte 聚合上限保持，超过单项和聚合上限都原子拒绝。同一合成输入在原 owner 被拒绝，在新 owner 完整保留。

验证：

• 默认传输下新增 20 项真实 File/SQLite、HTTP、CLI、managed controller 和 external worker 用例通过，无跳过。普通非 benchmark Goal 首项完成后触发重规划、执行实际报告修复、保留原内容，并在有据复核和 Vision 收尾后停止。受控 Host 使用本地确定性程序，不代表真实模型采用。
• managed 恢复穿过实际 ChatRuntimeController 与协议进程，声明响应丢失及首轮响应丢失均只有一个会话、一次 turn/start。
• 旧 outcome 语义回归在机器 JSON 传输下 41 passed；默认渐进传输扩大回归 144 passed / 14 failed。14 个失败均为旧测试直接读取完整 JSON 的 KeyError，已在原始 base 的相同两个文件复现同一组失败（27 passed / 14 failed），没有改写这些失败为通过。
• TypeScript action/capacity：25 passed / 2 PostgreSQL tests skipped；其他 Goal acceptance/replan：172 passed / 23 skipped。此轮没有 PostgreSQL 正向集成资格声明。
• control-plane typecheck、Dashboard/Chat production build、9 文件公开边界扫描、双语 RFC diff 和 whitespace 检查通过。没有前端布局变更；App 的现有创建入口使用实际 HTTP 服务验证，已安装 App 的完整视觉旅程及真实模型效果仍未验证。

这是普通 Goal 创建入口的漏接修复。既有默认持续要求 owner 不依赖可执行检查、检查 scope 或领域反馈；领域适配器只提供自己的证据。更早的自由文本 Goal 不会被猜测式迁移。本 PR 不声明实验补时、运行采用、独立验收或 main 合并。

[loopx-agent]

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

Request changes conclusion (author-owned PR; GitHub blocks formal self-review)

动机 / Motivation

在 Chat 中创建 Goal 并填写完成标准的用户，会遇到起步任务做完、原始交付要求却没有进入后续判断的问题。

例如用户要求完整报告及附录，却只把“写引言”列为初始任务：旧路径只创建任务，后续可能认为已无工作；新路径在启动前把原始标准登记为可读回的支撑成果，让现有闭环继续发现缺口。

独立 HTTP 对照确认，明确填写的标准在 File 和 SQLite 中完整保存，空任务列表及后续无关提醒均不使它丢失；未填写标准时不会从目的文字推测出一套要求。

本次不新增继续执行控制器、模型调用、独立验收权或根 Goal 完成权，也不把旧的已派发创建记录自动迁移。

当前提交仍新增一处必需 Ruff 检查失败，修复后需重新评审；实际模型遵循、已安装 App 采用和完整成本净收益没有获得本次验证。

改动思路 / Approach

创建适配只把已批准的用户意图送入现有成果 owner；原始 CAS 的恢复日志守住启动顺序，没有另设调度或验收权威。当前边界是创建、原始写入重放及既有页面读回；后续工作发现仍由原有成果闭环负责。用户完成标准属于不可推导的明确意图，适配器只把已批准字段及实际创建的任务引用转成既有声明。prepared/recorded 是恢复写入身份的日志，不是第二个完成判断器。必要写入失败要阻止首次派发；显示页面和观测者不能替它放行。

场景	原路径	当前路径
明确标准、无初始任务	标准没有进入成果契约	原样登记后才允许启动
未填写标准	无声明	仍无声明，不猜目的文字
写入成功但响应丢失	无这次声明步骤	重放原操作和原 CAS
准备后他人已更新契约	无这次声明步骤	明确冲突并保留，不能自动重基

表格依据本次源码和独立 HTTP 对照；它不代表模型已遵循标准。继续使用现有工作发现、预算和停止规则，比另设一个“永远继续”的控制器更小，也更容易回滚。

具体改动 / Changes

完整审查 8178@297c168d39befa3e1141b2230e04e261d5aaf717，实际 merge base 62e234c，9 个文件 +500/-1。生产改动集中在创建入口、22 行 TS 适配及恢复检查；345 行新 Python 测试覆盖真实边界，文档和 TS 测试没有混入生成产物。

关键代码讲解

• goalCreationOutcome（creation_outcome.ts:12）只接收明确标准、选定 Agent 和已创建任务；稳定操作身份把来源及重放关联起来，不从自然语言推断工作或验收。
• _apply_goal_create（chat_actions.py:640，新增路径约 810 行）在初始任务之后、首次 Session/Turn 之前调用原生 refine_goal_outcome，先记录原始 provider revision，再写入和记录成功；恢复不会重新取一个 revision 覆盖并发修改。
• goalCreationProgress（action_review_plan.ts:112）核对 prepared/recorded 的 Goal、操作身份及顺序。已有已派发记录保留旧恢复路径；新步骤不能伪装成已记录后提前启动。

规范依据 docs/reference/goal-acceptance-observations.md#default-supporting-outcomes，固定于 62e234c。以原文行号标识现有条款：L78-L82 — implemented，标准、关联工作和来源进入 canonical 读回，未知写入保留原操作；L84-L89 — implemented，默认维护不等于独立验收或根 Goal 完成，预算和停止仍优先。新增文档解释这次创建路径，并非拿本 PR 自己的新文字替代原验收。共享单条描述上限由 512 扩至 2000 UTF-16 单元以容纳表单原有 1000 codepoints；两项 131072 字节总预算未放宽，越界拒绝测试保留。

对主干的风险 / Risks

[P2] 必需 Ruff 新增失败：tests/control_plane/test_goal_create_completion.py:184。 lose_response 把 original(*args, **kwargs) 的返回值存到从未读取的 result。完整命令 uv run --extra test python -m ruff check tests loopx/canary loopx/control_plane loopx/domain_packs loopx/presentation 在当前头产生 F841；同一命令在固定 base 仅有三个旧 F811，当前头则是这三个加新 F841。最小修复是去掉赋值、保留 original 调用和随后的 TimeoutError 注入，再跑完整 Ruff 及创建恢复测试。不能把旧 F811 当作新增 F841 的豁免。

独立执行的完整创建与存储集 PASS：88 项；另一个空任务/长标准/无关提醒探针在 base 的两个明确标准场景失败、两个无标准对照通过，head 四项全过。TS 测试 PASS：25 项，两个 PostgreSQL 用例跳过；typecheck、17 个 strict mypy 文件通过。源码构建页面连真实隔离 SQLite，完整标准逐字读回；断网刷新明确失败，恢复后健康。初始缺依赖及无效探针夹具的失败保留，装齐声明依赖、改成合法用户任务后才得到上述结果，没有删除断言。

原生 premerge 的 6 项直接检查和 14 项选定执行通过，首次总门因缺质量收据失败；随后记录的当前收据明确为 FAIL，验证为 invalid_receipt，原因就是新增必需 Ruff 失败。未把这些执行称为总门通过。实际模型、安装版采用和 PostgreSQL 正向集成没有验证；所有 GitHub CI 均未拉取、轮询或等待。

语义与 CI 对齐

局部创建检查点复用既有 typed journal，原生语义词汇检查通过，没有新增通用状态分类或关键词启停规则。明确标准且缺 Agent 现在在创建前拒绝，这是已披露并覆盖的输入变化。无标准的两种 provider 对照保留原行为；重放与冲突不新增权限。修复 lint 后仍需按新头重新核对完整差异，而不是继承本次功能结果为批准。

我的整体评价 / Verdict

当前功能是 justified_increment：长程路径在确定性用例中 improved，能够保留起点意图并让原生闭环继续；user_experience improved，创建字段可完整读回，未核验和自查并未变成验收通过。已检查真实源码构建页面的默认视图、完整展开和下部区域：目的与当前工作可辨，五项成果的重复内容通过折叠组织，长标准可展开阅读全文；恢复后仍保留内容和未核验标记。页面没有响应式布局修改，另检查了既有 390px 展开和下部阅读。这些观察来自隔离 SQLite 后端及合成内容，不证明已安装 App、真实模型遵循或真实用户理解。

创建适配只把已批准的用户意图送入现有成果 owner；原始 CAS 的恢复日志守住启动顺序，没有另设调度或验收权威。当前边界是创建、原始写入重放及既有页面读回；后续工作发现仍由原有成果闭环负责。大部分行数保护实际边界，保留原始 CAS 的兼容分支有已存创建记录支撑；可立即删除的冗余是这一个未使用变量，评审没有修改作者提交。没有发现第二个可验证阻塞，但新 F841 使当前结论为 REQUEST_CHANGES。模型采用、完整成本和净收益仍未证；本结论不授予合并或安装权。

English verdict: REQUEST_CHANGES at 297c168d39befa3e1141b2230e04e261d5aaf717. Remove the newly introduced F841 and rerun required validation; functional creation/recovery evidence passes, while installed/model adoption remains unverified.

[loopx-agent]

[P2] 保留故障注入调用，去掉未使用的 result 赋值

完整必需 Ruff roots 在此精确 head 新增 F841；固定 base 只有 tests/test_chat_codex_history.py 的三个旧 F811，当前头是这三个加这一处。因此旧 lint 失败不能豁免新增失败。这里不读取返回值，直接调用 original(*args, **kwargs)，保留随后的 TimeoutError，便可保持原来的响应丢失故障注入。修复后重跑完整 Ruff roots 及创建/恢复测试；88 项功能回归通过不替代此必需静态检查。