Repository navigation
fix(goals): keep objective proposals nonblocking and complete CLI workflow - #7088
Conversation
Signed-off-by: LoopX Agent <337587101+loopx-agent@users.noreply.github.com>
Signed-off-by: LoopX Agent <337587101+loopx-agent@users.noreply.github.com>
…cli-nonblocking-20261023 Signed-off-by: LoopX Agent <337587101+loopx-agent@users.noreply.github.com>
loopx-agent
left a comment
There was a problem hiding this comment.
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: 7088@a0fcaa6346d6eabcbf814a812e2d16b81bf74a80;实际基点:f8238e6f26e801a65c8c6a16bc9aea1659bdb690。旧 ee3db08da0df11e9397edd5c2c0e4f5faea3ff1f 的结果保留其原版本归属,未直接继承旧结论。
动机
通过 CLI 长期维护 Goal 的 Agent,以及已经授权调整当前目标的本地 owner。
原 CLI 能准备目标修订提案,却没有按原提案身份查看和应用的入口;操作者还要进入 App 或理解内部 API,而“展示待审提案”可能被误读成必须再次提问或全局停工。
当前帮助和返回命令能完成查看、授权应用、分别采用与读回;待审提案不改变现有目标,独立授权工作可以继续,实际应用仍保留本地 owner 边界。
本 PR 交付 CLI 与指引修复,不扩大根承诺或权限,不自动应用提案,也不认证所有模型、宿主和长期效果。
改动思路
继续复用已有 Goal acceptance/目标修订 TS owner 和 ChatActionStore:CLI 负责发现、参数及返回路由;原 proposal/checkpoint 保存同一个已审请求,原 typed owner 决定修订、CAS 和自身采用。新增查看入口先解析当前来源再加载提案,不以共享 runtime 中碰巧存在的数据替代实际 Goal。
复用现有提案、typed owner 和恢复 checkpoint,再集中同一 transport 的服务构造,足以完成这条任务;不需要新的修订权威或迁移框架。当前 PR 的边界是可发现、可恢复且不制造额外问询的完整 CLI 提案流程。
人已经明确授权同一提案时,新增交互轮次为零。尚缺 consequential intent 或权限时,只等待依赖该决定的动作;待审本身不是新权限、全局停止或 peer adoption。应用之后,各 Agent 检查自己的工作并采用,其它 peer 的状态不能被代签。命令、复制和可选导航的减少是流程改进,不等于模型已学会遵循全部规则。
具体改动
独立规格是实际基点 f8238e6f26e801a65c8c6a16bc9aea1659bdb690 的 docs/architecture/rfcs/goal-outcome-refinement-v0.md,并核对 overall roadmap R4。该规格与最初基点的内容相同。
逐项映射:Current operating objective 的准备无 Goal 效果、owner 应用、各 peer 独立采用为 implemented;Ordinary user messages 的直接用户来源与归因不授权限为 implemented;State, reads and recovery 的原 operation/CAS、来源拒绝和历史回执恢复为 implemented。R4 的一般共享意图修订、真实模型识别、安装后协作和可比长程收益仍超出这个既有 CLI 修复边界,没有用脚本测试关闭它们。
关键代码讲解
register_goal_acceptance_command增加两个原提案动作和完整帮助,区分准备保存、只读查看、应用预览及明确执行;采用文档所需的 revision/digest/work_digest 可直接发现。handle_goal_acceptance_command拒绝给旧 proposal 混入新文档、operation 或 revision,也拒绝带 execute 的查看;以shlex.join返回保留 registry/runtime/Goal/proposal 身份的原路命令。objective_revision_proposal先读取真实当前 Goal,再验证提案种类与双重 Goal 关联;默认只读,带 Agent 身份的应用被拒绝。授权应用委托原 service,历史重放随后读取当前 basis,不能重新安装旧目标。REPLAN_PLANNING_GUIDANCE明确展示不迫使问询,并指向可达 CLI 帮助;root obligations、权限、预算、停止及不因普通进展而修订的条款保持。
完整 PR 仍为7文件 +329/−20,三个产品文件 +101/−9,两份技能说明和两份针对实际调用的测试。新 CLI action choice 是既有命令的本地扩展;没有新增持久 schema、状态集、独立 provider、默认开关或第二个 Python 修订决策 owner。
对主干的风险
未发现当前有阻塞性的功能缺陷;APPROVE 只覆盖本次 CLI/指引修复,不解除独立的合并资格阻塞。
当前 a0fcaa6 上,52项实际 CLI/HTTP 和 Goal 文本测试、完整 control-plane typecheck、标准 premerge 的4项直接检查、编译、10项 catalog 和8项 risk通过。原 ee3db08 的170项验收/重规划回归保留原版本;506项含真实隔离 PostgreSQL17.11 的 store/acceptance/objective/replan 测试也只复用于逐 blob 确认未变的 owner、测试和共享调用文件,零skip,临时数据库容器已删除。没有把这些执行改写成新提交上的全套重跑。
我分别从不可变基线和两个 reviewed revision 的正常 CLI 输入做了独立对照。基线帮助没有按提案查看/应用入口,准备后也没有可执行的后继命令。当前源码与重新构建 wheel 的 File/SQLite 旅程都从 help 和真实返回 argv 开始:保存/精确重试同一提案、查看、默认预览、Agent 越权拒绝、owner 应用、自身采用、App 仅 GET 独立读回,最后在第二次修订后重放原提案仍返回当前 revision2。两种 backend 都保持原 Markdown 字节,以及实际存在的共享 decoy authority;peer A 已采用、B 仍未采用。不是只比较字段名称或 helper 返回码。
失败覆盖包括缺失/错误提案种类、禁止的混合参数、来源缺失/不可读/被移除/未迁移/停用、canonical commit 后响应丢失,以及待审期间新增独立授权工作。默认预览、越权应用和错误来源均不能偷偷完成 Goal 修订。该 owner 的存量旧回执与重放分支保留,退役或删除无效历史版本不属于本次修复。
语义与 CI 对齐
在实际当前 base/head 的18组原生规划输入上,除第一条说明的明确改写外,其余决策、要求和全部其它条款相同。逐条比较了 actor、触发条件、先后顺序、证据来源、权限、继续及停止语义;旧 owner-apply/自身采用次序在完整 CLI help 和技能中仍可达。新说明不强制模型提问,也没有修改机器的 must_attempt、修订 admission 或 root stop 规则。测得 guidance JSON 由2904增至2988字节,保留3000字节门和原其它预算,没有为了变绿删去义务或放宽上限;这不是 Windows 全包大小或模型理解的测量。
作者更新正文保留 native Windows 输出预算、浏览器读回与 CQR 的阻塞及历史失败;这些没有被本次源码/打包 CLI 通过抵消,也不是我独立执行的 Windows 或浏览器结果。本轮按 no-CI 策略未读取、轮询、调度或等待 Actions,仍须按当前合并 readiness/CQR/required checks 完成后续资格,不能把本 COMMENTED 结论当成 GitHub 正式 self-approval 或 merge 权限。
第一次本地 wheel 构建因此前 checkout 的旧生成前端而被正常拒绝;保留该失败后,在忽略的完整精确提交导出中重新构建前端及 wheel,核对当前产品和新调用者模块字节,再完成上述普通 CLI 旅程。没有更改、放宽或绕过构建检查,也没有把旧 wheel 当成当前组合。
我的整体评价
APPROVE,保留当前 CQR/平台/浏览器和合并资格边界。 long_horizon 为 preserved:原提案身份、响应丢失恢复、后续修订和独立 peer 采用没有因新入口分叉;user_experience 为 improved:已知信息和原授权可复用,用户无需为了查看或应用相同提案再进入 App、读源码或回答重复问题。
复用现有提案、typed owner 和恢复 checkpoint,再集中同一 transport 的服务构造,足以完成这条任务;不需要新的修订权威或迁移框架。当前 PR 的边界是可发现、可恢复且不制造额外问询的完整 CLI 提案流程。
已检查现有 App 提案操作、HTTP readback、CLI 和技能装载路径;PR 没有渲染布局变更,视觉评审不适用。本轮未认证 Windows、浏览器完整发布资格、现场安装、所有模型/宿主行为或可比长程净收益。CLI 返回 owner 命令是发现信息,不授予权限;省略 Agent 参数也不能替实际人类授权。后续安装与模型是否实际采用,仍需各自真实证据。
English verdict: APPROVE at a0fcaa6 for the bounded CLI and nonblocking-guidance repair. Fresh source and rebuilt-wheel File/SQLite journeys preserve original proposal identity, preview/owner authority, self-only adoption, source routing and historical-response recovery. Current 52-case integration, typecheck and local standard premerge pass; earlier 170-case and 506-case real-store evidence retain their original revision and explicit reuse basis. Windows/browser/CQR and merge qualification remain separate holds; no installed or model-adherence claim is made.
Goal and delivered outcome
Agents could save a current-objective proposal through CLI, but inspecting or applying that exact proposal still required the App or internal APIs. The workflow wording could also turn “surface for owner review” into an unnecessary question or a stop before otherwise authorized work.
This change makes surfacing a pending proposal nonblocking and completes the existing CLI journey.
goal-acceptance --helpdocuments the objective/adoption JSON; preparation returns route-preservinginspect-proposalandapply-proposalcommands. Apply is preview-only unless--executeis supplied under existing local-owner authorization. It reuses the original proposal, typed Goal owner and lost-response checkpoint. Each Agent still adopts only its own work after an applied revision.A pending proposal creates no new gate or adoption requirement. Continue independent authorized work under the current objective; only an action that actually depends on missing intent or authority waits. The same rule applies to interactive and unattended work. Already answered authorization is reused. No harness-specific exception, permission grant, new state vocabulary or automatic objective application is introduced.
Author declaration and scope
docs/architecture/rfcs/loopx-overall-roadmap-v0.mdat base0161cf683beb81a6af627c67fe8f9538b07fca1a.main. Complete within the CLI/skill repair scope; peer model behavior and broad long-horizon benefit remain unqualified.skills/loopx-project,replan_semantics.ts; quota parity and authorized Todo creation before owner applygoal_acceptance.py; actual returned commands execute on File/SQLite, including from the built wheelChatActionServicecheckpoint; lost-response retry and old-proposal replay cannot reinstall an earlier objectiveBounded refactoring: shared proposal-store route construction within its existing transport owner. No second Python revision/adoption authority or new framework. App proposal handling and presentation remain unchanged; the existing frontend observes the same canonical result.
Validation
Original feature qualification:
ee3db08da0df11e9397edd5c2c0e4f5faea3ff1f. Current integrated head:a0fcaa6346d6eabcbf814a812e2d16b81bf74a80, based onf8238e6f26e801a65c8c6a16bc9aea1659bdb690. Current integration passes 52 native CLI/HTTP and Goal narrative tests, the original local CLI output matrix and configured static checks. Inputs are synthetic/public fixtures; native Windows and browser qualification remain failed.test_goal_objective_revision.pyandtest_goal_acceptance_source_route.py; pending-proposal admission parity, independent work, preview/owner refusal, unavailable/stopped sources, loss recovery and self-only adoptionee3db08)f568944e675fec824747a7c95af4a45e5b7513dd24c264a9a58c1a7e6de5e3d1; receiptcqr_f568944e675fec824747records required Windows/browser failures. Earlier passing qualification is historical, not a current merge clearanceee3db08)Initial author tests exposed invalid Todo-add arguments, a private interpreter path in a synthetic check plan and projection-sensitive text assertions; corrected against existing public contracts. The first wheel build correctly refused stale generated frontend assets; rebuilt the current bundle and retried successfully. An isolated test runner initially missed helper imports; fixed runner paths and explicitly verified wheel provenance. The initial standard premerge also failed the unchanged crowded JSON ceiling (40,040 against 40,000). Matched base/head measurements were retained. One repair pass centralized the detailed procedure in reachable CLI help, keeping explicit nonblocking surfacing in replan. All absolute/growth/line/shape/semantic budgets remain unchanged; 170 differential-policy tests and the original real CLI matrix pass. No runtime or acceptance gate was weakened.
No live model/harness evaluation, new performance claim or installation of this candidate is asserted. Operational private Goal evidence is excluded from this PR. No merge authorization is inferred.
Current integration and CI holds
The latest target main is integrated; the PR still changes only the same seven CLI/owner/skill/test paths. Current integration has 52 passing real CLI/HTTP and Goal narrative tests, plus the unchanged local base/head output matrix, repository CI-scoped Ruff, configured mypy, control-plane TypeScript checks, skill validation and exact-path boundary checks.
Current standard premerge executes 6 direct and 18 selected checks with no command failures; its aggregate remains blocked by CQR. The first local attempt placed a no-Git fixture below a repository and failed its nested catalog check; rerunning with an external owned temporary root passes. That initial failure is retained.
Required CI qualification remains blocked. The original failed run is retained. Matched runs on immutable main
5550e91and the original tested PR merge78a435ashow:research-results.mjs:68goal-masthead.mjs:128goal-vitalsdoes not reappear after Chat navigation; installed-page validation remains failedSources: main CI, tested PR CI, installed-page release check. These observations explain the inherited failures; they do not waive required validation, qualify Windows, or establish merge readiness. Current CQR preserves the failures as blockers. No blind CI retry, timeout increase or unrelated frontend modification is included.
Frontend / visual evidence
UI impact: none. Existing App proposal controls and canonical readback are exercised by integration tests; no viewport or layout changes.
Boundaries