Repository navigation
fix(benchmark): guide checkpoint research into declared workspace - #6696
Conversation
Signed-off-by: LoopX Agent <337587101+loopx-agent@users.noreply.github.com>
|
CI triage for head
These failures remain open validation limits. Independent review has been requested on this unchanged head; merge readiness has not been established. |
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: 653c053
动机
受影响的是启用研究检查点、之后要接续实验的操作者和 solver。研究报告保存在工作区,而候选程序、拟合参数或负结果放在未声明的临时目录时,报告能恢复,引用文件却可能缺失;操作者必须重新核实甚至重做实验。
本 PR 交付的可观察变化,是让新 native worker 的启动提示和工作区说明明确推荐保存位置,并说明声明是否覆盖工作区;目录捕获与接收端仍独立核验实际文件。
剩余缺口是模型是否采用指引、具体实验的依赖是否完整,以及长期研究效果;本次未验证这些结论,也不能用后来生成的文件修补旧检查点。
这是有价值的保存指引增量。它保留原任务目标与反馈规则,没有新增自动扫描、完整性保证或恢复界面;不以提示词到达 worker 代替科学收益。
改动思路
现有 EdgeBench CLI 先验证显式 checkpoint 声明,再把同一段 native 策略用于启动提示和工作区 AGENTS.md。新增部分仅根据已有声明计算文字提示;TypeScript artifact owner 继续决定实际目录成员、字节见证、捕获和 materialize,SForge 继续决定提交、评分和选择。Python 在这里组合特定 provider 的提示,位置合理,不形成第二套通用恢复 authority。
架构判断是保留这个小边界:一个 40 行 helper 和既有 CLI 的条件组合足以解决当前的提示缺口。新增 provider、目录清单协议或 dependency scanner 都会增加维护成本,却不能证明研究依赖完整。共享策略前缀也使启动提示与新 worker 的说明不易漂移;warm worker 仍保留捕获的说明,不能悄悄更新已有研究的处理条件。
以下是精确 head 上实际执行的比较,表格只总结这些已验证的路径:
| 输入或边界 | 实际观察 |
|---|---|
| 未提供 checkpoint 声明 | base/head 的完整启动提示、工作区策略、原目标和默认 envelope 观察逐项相等 |
| 声明工作区目录 | 新提示说明覆盖;声明后新建的候选与负结果被真实捕获并按字节恢复 |
| 只声明单个文件 | 提示明确不覆盖整个工作区,不推断额外文件成员 |
| 声明外文件、缺失来源或 symlink | 声明外文件不被捕获;两个拒绝案例通过,原捕获边界保留 |
| 重复安装或冲突说明 | 真实 worker 中相同策略重复安装幂等,冲突拒绝并保留原说明 |
具体改动
关键代码讲解
checkpoint_research_instructions用路径组成关系描述声明覆盖,区分整个工作区与单文件。它要求保留候选、输入、拟合参数、报告和负结果;外部依赖须先复制、更新引用并检查,不能删除或替换旧证据。任意私有来源路径不会直接回显到提示。main仅在 native 分支且显式声明存在时追加指引,随后用同一策略前缀重建提示,原始任务仍单独作为 Goal objective。未启用时保留原构造函数与字节内容。- 现有
format_run_cmd和_install_workspace_instructions未修改;新 worker 保留原AGENTS.md、安装并读回策略,warm 路径不改写捕获的说明。独立真实 Docker 用例执行了该安装与冲突路径,在缺少 runtime 安装钩子处停止,没有启动模型。 - 现有
capture_worker及 artifact 验证没有新增决策规则。新增目录用例通过真实 writer、native HTTP controller 和 artifact materialize 验证 later-created 文件;其余三个测试文件补 CLI 到达、关闭路径相等及安装读回。
完整差异为七文件 +205/-0:两个 provider 提示/CLI 文件、四个测试文件、一份公开参考文档。参考文档同时说明新 donor 的显式目录声明、关闭方式、历史点不能追补,以及接收端验证的独立责任。
规范在实现差异之前读取,固定依据为 docs/reference/research-checkpoint.md,修订 fdf03ec,并对照既有 benchmark/README.md:
- Prepare and capture:已实现当前增量。声明决定文件集合,文本引用不增加成员;真实新文件、声明外文件、缺失及 symlink 案例覆盖此边界。提示不证明 filesystem 或依赖闭包。
- Admit a fresh session and adopt context:不在本 PR 新实现;原接收端、当前执行准入和历史证据边界保留。测试中的 materialize 不被描述为自动采用或模型执行。
- Explicit warm worker composition (qualification in progress):当前代码保留 captured instructions 与原预算/反馈逻辑;完整具体研究状态、新 donor 处理条件及模型收益继续由既有 benchmark 操作者在新 attempt 中资格化。
对主干的风险
主要风险是把“建议保存到覆盖目录”误读成“所有依赖已捕获”。当前正文和提示都保留了实际捕获及 receiver verification 的责任;缺少整个目录覆盖时也有明确警告。原目标、提交路径、反馈机会、评分、执行权、TurnEnvelope 默认值均没有被这段文字改变。原外部文件仍需要显式选择与验证,不能为得到表面完整性扩大到整个临时目录。
本轮独立验证:两个完整 prompt/runtime 模块 312 passed;真实 Docker 捕获/安装/拒绝案例 5 passed;相同私有 harness 在不可变 base 和本 head 各经过三个实际 CLI 组合,关闭时全部观察字段相等,开启时原目标和默认 envelope 保留。语义 advisory 在完整语义检查之前执行,完整语义、控制面 typecheck、Ruff、diff、双语检查及唯一提交的 DCO 通过。七路径公开边界扫描通过。
完整标准 premerge 的 5 个直接检查与 19 个选定检查均通过;总体仍退出 1,评审 checkout 的 quality_stale_receipt 和 benchmark manual hold 独立保留,不能称整个合并门禁通过。
另一个独立 TS 检查 tests/control_plane_ts/content_digest_single_owner.test.ts 在 base 与本 head 都是 16 pass / 1 fail,同一失败指向 trajectory_assessment.ts:41 的重复摘要匹配;检查文件和因果源文件逐字节相同,且本 PR 的捕获/提示不经过该逻辑。这是已复现的无关基线失败,未改限额、断言或 allowlist,仍需由原 owner 修复后满足合并门禁。
作者报告过 macOS Docker stream-close 的 ENOTCONN。本轮首次真实五例没有复现,底层 worker/backend 在 base/head 字节相同;这不证明旧传输问题被修复或所有平台稳定。作者另提供的 donor 观察及其他 CI 失败未作为通过证据,本轮按策略没有获取、轮询或等待 CI,也未执行新模型、原生评分或研究任务。
语义与 CI 对齐
本地路径覆盖布尔值只是 provider 提示的派生值,不是新共享状态词表或权限协议。既有 artifact、声明、worker lifecycle 和评分 owner 保留;文本明确是 advisory,未新增机器强制的依赖完整性义务。静态 advisory 的空结果不认证语义;本轮还逐项比较了目标、先后条件、外部证据、关闭路径和失败分支。上面的基线红项与独立合并门禁继续报告。
我的整体评价
APPROVE 这个精确 head 的保存指引增量,未发现本 PR 的阻断性缺陷。长期工作的判断为 accepted tradeoff:已证明指引到达新 worker 且声明目录能保留后来生成的研究材料,尚未证明模型采用、完整依赖或科学效果。用户体验判断为 improved,范围是操作者与 solver 能读到明确的保存位置及覆盖警告;没有把它当作新的恢复 UI 或安装采纳。
面向下一次变更的简化检查已应用:复用已有提示前缀和 artifact owner,保持两处小生产改动,无需新增扫描或目录状态框架。暖恢复、现有 donor 与历史点保持原边界,后续实际实验的材料资格与效果验证由既有 owner 承担。本结论不免除基线失败、CQR、benchmark hold、原生 merge-readiness 或单独合并授权。
历史经验中“走到有用结果”用于检查提示实际安装、文件实际恢复和不能承担的完整性承诺;没有继承历史 verdict,也没有把经验内容送达当作质量收益证据。
English verdict: APPROVE - 653c053 delivers bounded opt-in storage guidance through the actual CLI and new worker instructions. Independent 312-test prompt/runtime coverage, five real Docker cases and paired CLI byte comparisons preserve the original objective, disabled path and authority boundaries. Dependency completeness, model adoption and scientific utility remain unqualified. The identical base/head digest-owner failure, reviewer CQR and benchmark merge hold remain separate; CI was not consulted and no merge is authorized.
Checkpoint-enabled native workers can keep reusable research files in temporary directories outside their explicit capture declaration. A checkpoint can then preserve a report while omitting the files it refers to, preventing reproducible continuation.
This change adds opt-in storage guidance to the initial native prompt and, for new workers, the installed workspace AGENTS.md. It directs reusable candidates, fitted parameters, local inputs and negative results into a workspace subdirectory, and reports whether the declaration covers the whole workspace. Existing recursive directory capture already includes newly created files; no new capture protocol or inferred filesystem scan is introduced. The original task Goal and capture-disabled prompts are preserved.
The owner is the existing EdgeBench benchmark provider. Python only composes provider prompts; the existing TypeScript artifact owner retains capture/verification authority. The bounded refactor reuses one policy prefix across prompt and workspace instructions.
Validation:
This is advisory storage guidance, not an enforced dependency-completeness guarantee. No frozen experiment is updated, no old checkpoint is repaired, and no research-effect improvement or model adoption is claimed. Warm restoration retains captured workspace instructions; adopting a new donor layout requires a new qualified attempt. CLI prompt composition and documentation are the affected entrypoints; there is no new capability or UI operation.