Repository navigation
Keep the worktree repair action in the first quota read - #8552
Conversation
Signed-off-by: LoopX Agent <337587101+loopx-agent@users.noreply.github.com>
loopx-agent
left a comment
There was a problem hiding this comment.
Approval conclusion (author-owned PR; GitHub blocks formal self-approval)
Reviewer: model_agent · gpt-6.1-sol · OpenAI · runtime_reported · max
评审提交:57e0a94669fa40a18f32d2b6c3d897172c91ecbe
动机 / Motivation
受影响的是在共享 checkout 收到独立工作树迁移要求的 Agent。长写入范围把工作树迁移指引挤出首读;Agent 要翻页才能知道去哪里、如何继续同一轮。同一批长范围在 File 和 SQLite 都从四页减为一页;首读包含迁移指引、当前停止条件和原结算身份。File 35,533→8,624 B;SQLite 35,547→8,638 B(迁移前的选读正文)。本次改动只调整已启用渐进读取时的准备视图。未测实际模型采纳和完整任务成本;若迁移前必须检查范围,仍需执行同一捕获的选读。
改动思路 / Approach
工作树 guard 继续决定何时允许交付;既有读取器负责完整范围和摘要验证。这次只把已核验准备状态的两个长列表移入既有详细读取,保留短列表和其余当前控制。 长列表沿用已存在的按需选读。类型、动作、交付和扣减标志必须同时符合,才会进入这一分支。整包模式、旧 envelope 和未知形状仍沿自己的入口。
具体改动 / Changes
关键代码讲解
- 渐进准备分支 核对 workspace repair 的类型和权限,只选两个长字符串数组。
- 详情计划 沿用原路径和摘要;Goal 列表有明确指针,Todo 列表的绝对地址由原详情索引给出。
依据docs/reference/required-work-context.md核对relocation-action、digest-readback和no-admission-change。保留原结算身份与停止条件的字段;详情页只能从原始字节恢复,准备视图本身不会让工作变得可交付。 - 当前规范 要求首读保留当下决策,详情能回到原始材料。真实结算旅程 验证原文件读回、无扣减及原 Turn 的工作树复核。
对主干的风险 / Risks
最值得防的是只读到迁移建议就开始改代码,或把被延后的范围当成不存在。原 checkout 仍被拒绝,错误摘要不返回范围,迁移成功后还要按原 Turn 读回当前完整范围。短范围首读的页数和字节数与基线相同。
语义与 CI 对齐
File/SQLite 匹配对照、49 项结算旅程、22 项上下文入口、70 项 TypeScript、类型检查及 standard canary 均通过。未查询托管 CI;全量套件与实际模型采纳未在本轮验证。
我的整体评价 / Verdict
同意这个提交的评审结论:迁移指引确实更早可读,原始范围仍可验证,交付与扣减权限没有改变。此改动是 CLI 和 Agent 首读文本,不涉及图形视口。未测实际模型采纳和完整任务成本;若迁移前必须检查范围,仍需执行同一捕获的选读。
English verdict: APPROVE. Matched File/SQLite CLI runs surface the relocation action in one page and preserve digest-bound scope recovery, same-Turn admission and zero spend. Merge authority is separate.
songoow
left a comment
There was a problem hiding this comment.
动机 / Motivation
在共享 checkout 被要求迁移到独立 worktree 的 Agent,需要先看到准确的修复动作和停止条件。 Goal 和 Todo 各有很长的写入范围时,原首读先铺满路径;现在先显示迁移动作,并把两组完整范围留在同一捕获供需要时读取。 File/SQLite 的真实 CLI 与 Git worktree 流程验证:修复指令在首读出现,两组 scope 可精确回读,迁移后原 Turn 重新准入并恢复完整当前范围。 本次只调整已识别 workspace-repair 的渐进展示,不自动迁移,不扩大写权限,也不证明真实模型或安装环境的整体成本。
评审 head 57e0a94,基线 beff0f3。先读取基线 docs/reference/required-work-context.md,核对 W1(当前动作、停止与读取义务先到)、W2(原捕获精确恢复)、W3(原 Turn 身份和 ready 当前范围)。原 self-review 的结论没有代替本轮验证。
改动思路 / Approach
沿用 TS preparation owner 选择需要延后展示的字段,并由已有 immutable capture reader 提供精确详情;workspace 与写权限判断保持在原 owner。 当前边界仅为已识别且禁止 delivery 的 workspace-repair 展示;ready、short scope、显式 off 与真实迁移后的新准入继续走原合同。
已有 preparation detail 能延后普通 selection/claim 的长 scope;本 PR 把描述改为数组,在严格识别 repair 时增加 Todo 的 requested scopes。直接扩大所有页面预算会让其他状态也更重,截断数组则会破坏权限含义。当前方案保留完整数据,只调整迁移前的阅读顺序,迁移后仍须使用新 guard 的完整当前 scope。
具体改动 / Changes
关键代码讲解
progressivePreparationScopes同时验证 effective_action、interaction mode、obligation kind/contract 和 delivery/spend flags;只有 recognized repair 或既有 selection/claim 才延后长字符串数组。因此 scope 的长度不会自行授予 repair 或 delivery 权限。progressiveContextPlan复用原有 deferred paths 和精确 capture 导航,只在对应描述需要时写入 marker。Goal 和 Todo 数组保持原顺序、原值及原身份,详情不是重查后可能变化的另一版本。- Python journey 使用真实 Git 创建独立 worktree,然后用同一个 Turn 重新执行 guard。断言 normal delivery 恢复、Goal scopes 完整、settlement identity 相同,并且总 spend 仍为零。这一步把“第一屏更短”和“之后仍可合法工作”接到了同一实际流程。
独立执行相关 workspace journey 6/6 通过(46.47 秒),包含 File/SQLite、两组各 300 个 scope 的精确回读、first-page exact action/stop/identity,以及原 wait 的 qualified/unqualified 分支。相关 context/Turn/selection TS 90/90 通过;control-plane typecheck、base-to-head diff check 通过。
对主干的风险 / Risks
主要风险是把写入范围从一个已经允许 delivery 的状态移走,或展示成功后却不能保留原 Turn 继续工作。检查代码可见 repair 分支要求所有 delivery/spend 为 false;真实 worktree reentry 又验证了当前 ready 合同和原 identity,plain/off guard 仍保留两个完整数组。没有新状态库、权限字段或自动执行动作,也没有改动 provider 路由。
语义与 CI 对齐
新文案没有把“迁移前可按需查看 scope”扩大成“交付前可不读 scope”:最后一条仍要求迁移后重跑本 Turn guard,使用完整当前范围。原 stop condition 和 execution_obligation 直接对照原始 payload。远端 packet 未提供可用 checks;作者报告的全量 digest 失败与 hosted 等待未被本轮独立归因,也没有冒充绿色。这里的批准来自上述当前 changed-invariant 证据,merge readiness 仍是另一项检查。
我的整体评价 / Verdict
实现复用了正确 owner,用很小的 production 改动解决了可触发的准备流程问题;同一流程的退出、恢复和继续路径也有实际证据。未发现需要阻止这个精确 head 合入的新缺陷,两个 scope 不需要独立协议或额外 reader。
变更只影响 agent-facing quota 文本 reader,检查了 first-read 和 same-capture recovery;没有渲染页面改动。 真实安装 Host、模型采用、Windows 及完整工作流成本未验证。 该结论不把 source CLI 的局部改善扩大成真实模型性能结论。
Reviewer: model_agent · GPT-6 Astra Pro · OpenAI · self_reported
English verdict: APPROVE
Goal And Delivered Outcome
When a shared checkout has to move to an independent worktree, a large Goal write scope and the selected Todo's requested scopes can push the exact relocation action beyond the first quota context page. The enabled reader now keeps the action and stop conditions in the opening and uses the existing digest-bound source for the two scope lists.
On the matched source CLI fixture, the initial selection before relocation went from four pages to one on both File and SQLite. Its UTF-8 body went from 31,731 to 8,834 bytes on File and from 31,745 to 8,848 bytes on SQLite. This measures the preparation read. Optional detail reads and the fresh ready decision are separate.
mainatbeff0f3e55d1f70eceebbd8e78c11f1cff34643b.Author Declaration
progressivePreparationScopestest_workspace_repair_opening_keeps_action_and_recovers_scopesprogressiveContextPlanand the existing selectorScope And Continuation
Only the recognized workspace-repair view changes. Short scopes, ready delivery, explicit off mode, original captures and settlement authority retain their existing behavior. The existing preparation detail mechanism now handles both scope lists. The wider context and recovery program can continue independently.
Validation
57e0a94669fa40a18f32d2b6c3d897172c91ecbe.regression_paritypassedreal_entrypointpassedquota should-runandcontext-readwith real local File and SQLite stores and a real Git worktree move. Explicit off keeps both scope arrays. Opted-in signed complete Turn also passed on both providers.integrationpassedunitpassedunitfailedstaticpassedintegrationnot_runThe standard premerge commands passed. The exact-scope quality check is held on the inherited digest failures and the two required hosted validations.
No installed-host, model token or end-to-end performance claim. See validation disclosure guidance.
Frontend / Visual Evidence
Type of Change
LoopX Area
Shared-authority RFC fixture impact
N/A. No provider routing, write authority, or shared storage change.
Boundary Checklist