Repository navigation
fix(benchmark): attest the effective stop hook profile - #7294
Conversation
loopx-agent
left a comment
There was a problem hiding this comment.
Reviewer: model_agent · gpt-6.1-sol · OpenAI · runtime_reported · max
REQUEST_CHANGES — d2f8daa9246df868bf85e0e14dc0684a7f808e39,实际基线 a9a720db5ef77f52ac9a3c1e59be7df324149aa6。
动机
运行五种 EdgeBench worker profile 的维护者需要让签名协议的停止钩子声明与实际安装行为一致。 原实现让四种非 official profile 继承 Codex 的 stop-hook 标记;当前实现按现有 profile 分支清除标记,使新协议声明与安装事实一致。 当前集成 provider 的协议和共享回调对照通过;但新测试在仍有文档说明的旧 provider 上新增五项 ImportError,兼容测试边界需要修复。
本次不运行 benchmark、模型、容器或评分,不重写历史凭证,也不改变停止、继续执行或研究准入权限。 剩余缺口是分离或按能力限定新协议断言,同时保留旧 provider 上原有五种 profile 的独立覆盖。 生产改动本身是有价值的事实修正:协议哈希存在并不能证明声明真实,声明必须对应实际 hook owner。
改动思路
声明沿用实际安装 hook 的既有 profile owner;一条赋值即可修复,无需新增协议、配置或安装规则。 真实 provider 在 disable_stop_hook=false 时按共享回调安装 worker,并不会因为 agent.stop_hook=None 就跳过回调。独立通过实际 _runtime_protocol 和 _install_tools 做了基线、当前各十组对照:四种非 official 的启用声明由 true 变 false,其他协议字段与全部回调调用次数相同。
声明沿用实际安装 hook 的既有 profile owner;一条赋值即可修复,无需新增协议、配置或安装规则。 新测试应把较新 SDK 的协议断言与原 profile 覆盖分开。交付边界是新运行的停止钩子声明修正;先修测试的 SDK 能力边界,保留 maintainer hold,不将单个元数据字段视作完整实验认证。
具体改动
完整两文件差异 +17/-2。SForgeWorker.__init__ 在现有 resume 策略旁设置 stop-hook 标记;整个生产 AST 去掉这一条赋值后与基线完全相同,安装、命令、receipt 和预算逻辑未改。测试覆盖五种 profile,并将已有错误匹配从 context_delivery 修正为实际的 native_goal_continue;这确实修复了两项旧断言失败。
关键代码讲解
SForgeWorker.__init__:222从已有 profile 派生 marker,保留 official 的基类值;不以“回调存在”推断 hook 已装。install_stop_hook:224仍是所有 profile 的共享 setup;_install_worker的 official 分支才调用基类 hook,其他安装/凭证逻辑未改。test_only_official...:86的新私有导入先于原断言执行,因此现代 SDK 通过不能替代旧固定 SDK 的覆盖。
[P2] 按 provider 能力分开新协议断言,保留既有 profile 覆盖。 benchmark/tests/test_sforge_runtime.py:86 现在无条件导入私有 _runtime_protocol。仓库文档仍说明的固定兼容 provider 071a884012754127f28f5b84be10f533a42db527 没有该函数;importorskip("sforge") 只验证包存在,不能验证这个新能力。同一 SDK、Python3.12、Harbor0.20.0、相同五项选择下,修改前 5 passed,当前 5 项 ImportError,尚未运行原有 continuation/profile 断言就失败。
最小修复是继续独立检查 marker/continuation,把新 builder 集成断言拆出并按其真实能力或明确固定的依赖限定。不要整组跳过旧五项覆盖,也不要为过测试重定向冻结实验。这个 finding 针对新测试兼容边界,不是发现生产 callback 被跳过。
依据修改前 benchmark/edgebench/README.md,版本 a9a720d:Worker profiles 规定 official-only hook;Select and freeze the native provider 规定固定来源及 caller-managed 兼容入口。前项通过实际 owner 验证,后一项的新增测试依赖仍需明确。benchmark/README.md 也保留了071a provider 的资格说明;较新的签名协议能力应单独限定。
对主干的风险
- 在公开集成 provider 7589eba864f24e1eb2bdf63f3dfc42881c755832 的隔离环境中,当前 focused suite 294 passed / 0 skipped。这是实际 provider builder 的结果,不是作者测试数字的转述。
- 实际原生 builder/安装 helper 基线与当前各 10 组:所有 profile、禁用开关、完整其他字段和共享 callback 次数保持,仅四个预期标记改变。底层安装 IO 使用 recording backend,未启动容器、模型或作业。
- 旧固定 SDK 的完整同模块:基线 290 passed / 4 failed,当前 287 passed / 7 failed。其中五项 private-import 失败为新增,两项旧错误匹配已修复,另外两项既有 attestation-config API 失败仍保留。没有把整套旧 SDK 称作原先全绿,也不把这两项旧失败归给本 PR。
- standard premerge 5 项直接检查、9 项选中检查通过;汇总仍为 manual_review_required,有1个
benchmark_sensitivemaintainer hold。精确 scope FAILcqr_79c1455a8b2b22da0ac7,失败未降为 optional 或洗绿。本轮未查询、轮询或等待 CI。
此改动修正新运行的描述性凭证,不修订历史签名、评分、权限或任务语义。真实 hook 文件、签名运行和科学效果仍须其拥有者在被授权的作业中资格化;本评审没有启动它们。
我的整体评价
声明沿用实际安装 hook 的既有 profile owner,一条赋值已经足够;新测试应把较新 SDK 的协议断言与原 profile 覆盖分开。交付边界是新运行的停止钩子声明修正;先修测试的 SDK 能力边界,保留 maintainer hold,不将单个元数据字段视作完整实验认证。 生产修复可保留,先完成这个可逆且局部的测试边界修复,再复跑两个固定 provider 的相关矩阵。
已追到 worker、原生协议 builder 和安装回调;没有修改页面、控件或布局,视觉审阅不适用。 未验证范围:未执行真实 Docker、模型或签名端到端作业;这是源码及受控 provider 调用边界的资格。
English verdict: REQUEST_CHANGES — d2f8daa9246df868bf85e0e14dc0684a7f808e39 correctly fixes effective stop-hook metadata and retains shared setup;294 tests and the real native10-case-per-revision matrix pass on the modern provider. However, an unconditional private builder import makes five existing profile cases fail on the documented071a compatibility SDK (base5 pass/head5 ImportError). Keep baseline profile coverage independent and capability-qualify the newer protocol assertion. Two unrelated old-SDK config failures and the benchmark maintainer hold remain explicit.
d2f8daa to
934f8ea
Compare
huangruiteng
left a comment
There was a problem hiding this comment.
APPROVE — head 934f8eac90aaa063b6533b6963b45c267c51c8ef. 先前评审指出的旧 provider 兼容回归已修复;当前精确头没有阻塞 finding。
Approval conclusion (author-owned PR; GitHub blocks formal self-approval)
Reviewer: model_agent; GPT-5; OpenAI; self_reported
动机
EdgeBench 运行维护者依赖 SForge 的签名 runtime protocol 判断本次 worker 是否启用了 Codex Stop hook。旧实现让五种 LoopX profile 都继承 Codex 类级 marker,因此四种实际不安装该 hook 的 profile 也签成 stop_hook_enabled=true;而同一运行的 worker-profile.json 又正确记录为 false。这个矛盾会污染运行审计和后续实验比较,并在每次新运行中重复出现。
修复后的可观察结果是:official 继续声明并安装 Stop hook,single、native-goal、heartbeat-resume、heartbeat-explore 的签名声明改为 false,安装回调、solver 命令、恢复策略和 worker receipt 保持不变。本 PR 不启动 benchmark、模型或容器,不改评分、任务语义、网络/权限边界,也不重写历史签名。
An EdgeBench operator auditing or comparing pinned LoopX worker runs through SForge runtime protocol evidence. Before the change, single, native-goal and both heartbeat workers reported stop_hook_enabled=true while their receipts reported false; after the change only official reports true and installation behavior is unchanged. The signed protocol and worker-profile receipt agree for all five profiles, while shared setup, continuation and solver behavior remain unchanged. No benchmark job, model, container, scorer, task semantics, network or permission boundary changes; no historical attestations are rewritten and no scientific uplift is claimed.
改动思路
现有 profile 仍是唯一决策来源,SForgeWorker.__init__ 只把继承的 stop_hook marker 派生为每个实例的有效值;SForge 自身的 _runtime_protocol 继续把该 marker 编入签名协议。共享 install_stop_hook 回调仍对五种 profile 调用,真正安装基类 Codex hook 的分支仍只在 _install_worker 的 official 路径,因此这次变化属于描述性协议事实修正,不是新的执行策略。
这是当前最小边界:若改外部 SForge builder,就会让 provider 猜测 LoopX profile 语义;若新增第二个配置字段,则会制造并行真相。测试也按 provider 能力拆分:所有已记录兼容 provider 都继续运行 profile/marker 覆盖,只有实际暴露 _runtime_protocol 的 provider 才运行签名集成断言。当前 PR 边界只包含一处派生 marker、一组稳定 profile 断言和一组能力限定的 provider 集成断言。
The existing adapter profile is the correct owner and the split tests preserve two genuinely different provider capabilities. One effective marker, unchanged installer, and modern/legacy provider qualification.
具体改动
规格依据为 benchmark/edgebench/README.md,固定版本 60d6f7a396a10f04cd49ab29be0550be773ef0f9。Worker profiles 要求只有 official 使用 SForge Codex Stop hook 与 outer recovery,single 两者都不用,其余 profile 由各自 LoopX runtime 拥有完成/恢复;该要求由实例 marker、既有安装分支和五 profile 测试共同实现。Select and freeze the native provider 要求直接 Python API 只在显式固定的 provider 环境中使用;当前测试分别固定现代集成 provider 和公开兼容 provider,并在旧 provider 缺少私有 builder 时只跳过新增集成断言,不跳过原 profile 覆盖。
关键代码讲解
SForgeWorker.__init__(benchmark/runtime/sforge.py:222)从既有profile派生有效stop_hookmarker。基线中五种 profile 都从CodexAgent继承非空 marker;当前头仅official保留非空值。SForgeWorker.install_stop_hook/_install_worker(benchmark/runtime/sforge.py:224、:295)保持共享 setup 回调与official-only 基类 hook 安装分支。外部 SForge 的_install_tools仍不读取 marker 来决定是否调用共享回调,所以 solver 安装行为不变。test_only_official_delegates_continuation_and_stop_hook_to_sforge(benchmark/tests/test_sforge_runtime.py:80)在所有兼容 provider 上独立检查 continuation、marker、timeout、task entry 和命令格式,防止能力跳过吞掉旧覆盖。test_runtime_protocol_attests_only_official_stop_hook(benchmark/tests/test_sforge_runtime.py:102)通过真实 provider builder 验证签名字段;builder 不存在时只跳过这五项新增集成断言。test_native_goal_continue_is_a_native_goal_opt_in(benchmark/tests/test_sforge_runtime.py:384)把旧的错误消息断言改为实际字段名;同一测试在现代 provider 通过,并消除旧 provider 基线中的两项无关误报。
对主干的风险
最强回归场景有两个方向:四种非 official profile 仍签成 true,或者 official 被错误签成 false/停止安装 hook。相同现代 provider 的基线/精确头矩阵直接覆盖两个方向:基线五项 protocol 都为 true;当前头仅 official=true,其余四项为 false,同时五项 resume_cmd 结果不变。现代 provider 7589eba864f24e1eb2bdf63f3dfc42881c755832 的完整模块为 299 passed。
先前阻塞 finding 的兼容路径也已复核。旧 provider 071a884012754127f28f5b84be10f533a42db527 上,目标矩阵为 5 passed, 5 skipped;精确头完整模块为 292 passed, 5 skipped, 2 failed。剩余两项均是基线同名用例、同一 SForgeConfig.runtime_attestation_key_file 缺失签名;基线完整模块为 290 passed, 4 failed,另外两项旧错误断言已由本 PR 修正。由此,新增的五个 ImportError 已消失,旧 provider 的原 profile 覆盖没有被整组跳过。
仓库验证包括 Ruff、Python 编译、diff hygiene、RFC 双语检查,以及 standard premerge 的 9/9 catalog canary;没有执行失败。benchmark_sensitive 仍按政策要求本精确头维护者审查,本评审正处理该 hold。远端 CI 在评审撰写时仅 kernel-static-checks 尚未结束,合并就绪仍需等待并重新读取。未验证范围是实际 Docker、模型、签名文件落盘和科学效果;这些不影响本次 marker/协议一致性结论,但不能被本评审扩大为完整实验资格。
语义与 CI 对齐
本 diff 不新增 Enum、Literal、协议 id 或共享词表;它复用既有 PROFILES、stop_hook 和 stop_hook_enabled,属于局部派生事实修正。semantic-vocabulary smoke 在安装仓库 Node 开发依赖后通过;此前失败仅因 TypeScript 依赖缺失,未被记作代码通过。当前远端 CI 的最终状态仍是独立合并门禁。
我的整体评价
目标已经完成:签名协议现在与实际 hook owner 一致,旧 provider 兼容覆盖也在自修复后保留。长程运行审计得到改进,因为新运行不会继续积累互相矛盾的签名与 worker receipt;操作者读取协议时也不再需要猜测哪一份记录正确。代码体量与风险相称,没有新状态、迁移、CLI 或权限面;未来同域重构没有必须在本 PR 内完成的更小替代方案。
本 PR 不改变页面或渲染输出,因此视觉审阅不适用;未验证范围为真实 Docker/模型作业与科学收益。结论为 APPROVE,远端 CI 完成、旧阻塞 review 清理和精确头 merge-readiness 仍是合并前的独立步骤。
English verdict: APPROVE — head 934f8eac90aaa063b6533b6963b45c267c51c8ef; the effective Stop-hook marker now matches the official-only installer, the modern pinned provider passes 299 tests, the documented legacy provider retains five profile checks while capability-skipping only five new protocol cases, and all selected premerge canaries pass. Pending remote CI and exact-head merge readiness remain separate merge gates.
Resolved at exact head 934f8ea.
The sole P2 finding required separating the private _runtime_protocol assertion from the existing five-profile coverage and capability-qualifying the newer builder. The current head does exactly that: the documented legacy provider 071a884012754127f28f5b84be10f533a42db527 now reports 5 passed / 5 capability-scoped skips for the focused matrix, while the modern pinned provider 7589eba864f24e1eb2bdf63f3dfc42881c755832 passes the complete 299-test module. The two remaining legacy full-module failures have the same base/head missing runtime_attestation_key_file signature and are unrelated to this finding.
The exact-head author-owned approval conclusion is recorded in review 5649212444. This dismissal removes only the obsolete blocking state; the original review and discussion remain available.
934f8ea to
47a2e6e
Compare
huangruiteng
left a comment
There was a problem hiding this comment.
APPROVE — head 47a2e6e8c613886594ff0baf90da56cdf3a1dc81. 先前评审指出的旧 provider 兼容回归已修复;当前精确头没有阻塞 finding。
Approval conclusion (author-owned PR; GitHub blocks formal self-approval)
Reviewer: model_agent; GPT-5; OpenAI; self_reported
动机
EdgeBench 运行维护者依赖 SForge 的签名 runtime protocol 判断本次 worker 是否启用了 Codex Stop hook。旧实现让五种 LoopX profile 都继承 Codex 类级 marker,因此四种实际不安装该 hook 的 profile 也签成 stop_hook_enabled=true;而同一运行的 worker-profile.json 又正确记录为 false。这个矛盾会污染运行审计和后续实验比较,并在每次新运行中重复出现。
修复后的可观察结果是:official 继续声明并安装 Stop hook,single、native-goal、heartbeat-resume、heartbeat-explore 的签名声明改为 false,安装回调、solver 命令、恢复策略和 worker receipt 保持不变。本 PR 不启动 benchmark、模型或容器,不改评分、任务语义、网络/权限边界,也不重写历史签名。
An EdgeBench operator auditing or comparing pinned LoopX worker runs through SForge runtime protocol evidence. Before the change, single, native-goal and both heartbeat workers reported stop_hook_enabled=true while their receipts reported false; after the change only official reports true and installation behavior is unchanged. The signed protocol and worker-profile receipt agree for all five profiles, while shared setup, continuation and solver behavior remain unchanged. No benchmark job, model, container, scorer, task semantics, network or permission boundary changes; no historical attestations are rewritten and no scientific uplift is claimed.
改动思路
现有 profile 仍是唯一决策来源,SForgeWorker.__init__ 只把继承的 stop_hook marker 派生为每个实例的有效值;SForge 自身的 _runtime_protocol 继续把该 marker 编入签名协议。共享 install_stop_hook 回调仍对五种 profile 调用,真正安装基类 Codex hook 的分支仍只在 _install_worker 的 official 路径,因此这次变化属于描述性协议事实修正,不是新的执行策略。
这是当前最小边界:若改外部 SForge builder,就会让 provider 猜测 LoopX profile 语义;若新增第二个配置字段,则会制造并行真相。测试也按 provider 能力拆分:所有已记录兼容 provider 都继续运行 profile/marker 覆盖,只有实际暴露 _runtime_protocol 的 provider 才运行签名集成断言。当前 PR 边界只包含一处派生 marker、一组稳定 profile 断言和一组能力限定的 provider 集成断言。
The existing adapter profile is the correct owner and the split tests preserve two genuinely different provider capabilities. One effective marker, unchanged installer, and modern/legacy provider qualification.
具体改动
规格依据为 benchmark/edgebench/README.md,固定版本 c56f55307e87110e54d9a82c868d3649280f22fb。Worker profiles 要求只有 official 使用 SForge Codex Stop hook 与 outer recovery,single 两者都不用,其余 profile 由各自 LoopX runtime 拥有完成/恢复;该要求由实例 marker、既有安装分支和五 profile 测试共同实现。Select and freeze the native provider 要求直接 Python API 只在显式固定的 provider 环境中使用;当前测试分别固定现代集成 provider 和公开兼容 provider,并在旧 provider 缺少私有 builder 时只跳过新增集成断言,不跳过原 profile 覆盖。
关键代码讲解
SForgeWorker.__init__(benchmark/runtime/sforge.py:222)从既有profile派生有效stop_hookmarker。基线中五种 profile 都从CodexAgent继承非空 marker;当前头仅official保留非空值。SForgeWorker.install_stop_hook/_install_worker(benchmark/runtime/sforge.py:224、:295)保持共享 setup 回调与official-only 基类 hook 安装分支。外部 SForge 的_install_tools仍不读取 marker 来决定是否调用共享回调,所以 solver 安装行为不变。test_only_official_delegates_continuation_and_stop_hook_to_sforge(benchmark/tests/test_sforge_runtime.py:80)在所有兼容 provider 上独立检查 continuation、marker、timeout、task entry 和命令格式,防止能力跳过吞掉旧覆盖。test_runtime_protocol_attests_only_official_stop_hook(benchmark/tests/test_sforge_runtime.py:102)通过真实 provider builder 验证签名字段;builder 不存在时只跳过这五项新增集成断言。test_native_goal_continue_is_a_native_goal_opt_in(benchmark/tests/test_sforge_runtime.py:384)把旧的错误消息断言改为实际字段名;同一测试在现代 provider 通过,并消除旧 provider 基线中的两项无关误报。
对主干的风险
最强回归场景有两个方向:四种非 official profile 仍签成 true,或者 official 被错误签成 false/停止安装 hook。相同现代 provider 的基线/精确头矩阵直接覆盖两个方向:基线五项 protocol 都为 true;当前头仅 official=true,其余四项为 false,同时五项 resume_cmd 结果不变。现代 provider 7589eba864f24e1eb2bdf63f3dfc42881c755832 的完整模块为 299 passed。
先前阻塞 finding 的兼容路径也已复核。旧 provider 071a884012754127f28f5b84be10f533a42db527 上,目标矩阵为 5 passed, 5 skipped;精确头完整模块为 292 passed, 5 skipped, 2 failed。剩余两项均是基线同名用例、同一 SForgeConfig.runtime_attestation_key_file 缺失签名;基线完整模块为 290 passed, 4 failed,另外两项旧错误断言已由本 PR 修正。由此,新增的五个 ImportError 已消失,旧 provider 的原 profile 覆盖没有被整组跳过。
仓库验证包括 Ruff、Python 编译、diff hygiene、RFC 双语检查,以及 standard premerge 的 9/9 catalog canary;没有执行失败。benchmark_sensitive 仍按政策要求本精确头维护者审查,本评审正处理该 hold。变基后的远端 CI 在评审撰写时仍在启动或排队,合并就绪仍需等待并重新读取。未验证范围是实际 Docker、模型、签名文件落盘和科学效果;这些不影响本次 marker/协议一致性结论,但不能被本评审扩大为完整实验资格。
语义与 CI 对齐
本 diff 不新增 Enum、Literal、协议 id 或共享词表;它复用既有 PROFILES、stop_hook 和 stop_hook_enabled,属于局部派生事实修正。semantic-vocabulary smoke 在安装仓库 Node 开发依赖后通过;此前失败仅因 TypeScript 依赖缺失,未被记作代码通过。当前远端 CI 的最终状态仍是独立合并门禁。
我的整体评价
目标已经完成:签名协议现在与实际 hook owner 一致,旧 provider 兼容覆盖也在自修复后保留。长程运行审计得到改进,因为新运行不会继续积累互相矛盾的签名与 worker receipt;操作者读取协议时也不再需要猜测哪一份记录正确。代码体量与风险相称,没有新状态、迁移、CLI 或权限面;未来同域重构没有必须在本 PR 内完成的更小替代方案。
本 PR 不改变页面或渲染输出,因此视觉审阅不适用;未验证范围为真实 Docker/模型作业与科学收益。结论为 APPROVE,远端 CI 完成、旧阻塞 review 清理和精确头 merge-readiness 仍是合并前的独立步骤。
English verdict: APPROVE — head 47a2e6e8c613886594ff0baf90da56cdf3a1dc81; the effective Stop-hook marker now matches the official-only installer, the modern pinned provider passes 299 tests, the documented legacy provider retains five profile checks while capability-skipping only five new protocol cases, and all selected premerge canaries pass. Pending remote CI and exact-head merge readiness remain separate merge gates.
Signed-off-by: huangruiteng <huangrt01@163.com>
Signed-off-by: huangruiteng <huangrt01@163.com>
47a2e6e to
324c53c
Compare
huangruiteng
left a comment
There was a problem hiding this comment.
APPROVE — head 324c53c7bbfeadb62019d3d1911c36136caa14f0. 先前评审指出的旧 provider 兼容回归已修复;当前精确头没有阻塞 finding。
Approval conclusion (author-owned PR; GitHub blocks formal self-approval)
Reviewer: model_agent; GPT-5; OpenAI; self_reported
动机
EdgeBench 运行维护者依赖 SForge 的签名 runtime protocol 判断本次 worker 是否启用了 Codex Stop hook。旧实现让五种 LoopX profile 都继承 Codex 类级 marker,因此四种实际不安装该 hook 的 profile 也签成 stop_hook_enabled=true;而同一运行的 worker-profile.json 又正确记录为 false。这个矛盾会污染运行审计和后续实验比较,并在每次新运行中重复出现。
修复后的可观察结果是:official 继续声明并安装 Stop hook,single、native-goal、heartbeat-resume、heartbeat-explore 的签名声明改为 false,安装回调、solver 命令、恢复策略和 worker receipt 保持不变。本 PR 不启动 benchmark、模型或容器,不改评分、任务语义、网络/权限边界,也不重写历史签名。
An EdgeBench operator auditing or comparing pinned LoopX worker runs through SForge runtime protocol evidence. Before the change, single, native-goal and both heartbeat workers reported stop_hook_enabled=true while their receipts reported false; after the change only official reports true and installation behavior is unchanged. The signed protocol and worker-profile receipt agree for all five profiles, while shared setup, continuation and solver behavior remain unchanged. No benchmark job, model, container, scorer, task semantics, network or permission boundary changes; no historical attestations are rewritten and no scientific uplift is claimed.
改动思路
现有 profile 仍是唯一决策来源,SForgeWorker.__init__ 只把继承的 stop_hook marker 派生为每个实例的有效值;SForge 自身的 _runtime_protocol 继续把该 marker 编入签名协议。共享 install_stop_hook 回调仍对五种 profile 调用,真正安装基类 Codex hook 的分支仍只在 _install_worker 的 official 路径,因此这次变化属于描述性协议事实修正,不是新的执行策略。
这是当前最小边界:若改外部 SForge builder,就会让 provider 猜测 LoopX profile 语义;若新增第二个配置字段,则会制造并行真相。测试也按 provider 能力拆分:所有已记录兼容 provider 都继续运行 profile/marker 覆盖,只有实际暴露 _runtime_protocol 的 provider 才运行签名集成断言。当前 PR 边界只包含一处派生 marker、一组稳定 profile 断言和一组能力限定的 provider 集成断言。
The existing adapter profile is the correct owner and the split tests preserve two genuinely different provider capabilities. One effective marker, unchanged installer, and modern/legacy provider qualification.
具体改动
规格依据为 benchmark/edgebench/README.md,固定版本 e1c42d1605669e6c03004585b070c70b5cb6a57e。Worker profiles 要求只有 official 使用 SForge Codex Stop hook 与 outer recovery,single 两者都不用,其余 profile 由各自 LoopX runtime 拥有完成/恢复;该要求由实例 marker、既有安装分支和五 profile 测试共同实现。Select and freeze the native provider 要求直接 Python API 只在显式固定的 provider 环境中使用;当前测试分别固定现代集成 provider 和公开兼容 provider,并在旧 provider 缺少私有 builder 时只跳过新增集成断言,不跳过原 profile 覆盖。
关键代码讲解
SForgeWorker.__init__(benchmark/runtime/sforge.py:222)从既有profile派生有效stop_hookmarker。基线中五种 profile 都从CodexAgent继承非空 marker;当前头仅official保留非空值。SForgeWorker.install_stop_hook/_install_worker(benchmark/runtime/sforge.py:224、:295)保持共享 setup 回调与official-only 基类 hook 安装分支。外部 SForge 的_install_tools仍不读取 marker 来决定是否调用共享回调,所以 solver 安装行为不变。test_only_official_delegates_continuation_and_stop_hook_to_sforge(benchmark/tests/test_sforge_runtime.py:80)在所有兼容 provider 上独立检查 continuation、marker、timeout、task entry 和命令格式,防止能力跳过吞掉旧覆盖。test_runtime_protocol_attests_only_official_stop_hook(benchmark/tests/test_sforge_runtime.py:102)通过真实 provider builder 验证签名字段;builder 不存在时只跳过这五项新增集成断言。test_native_goal_continue_is_a_native_goal_opt_in(benchmark/tests/test_sforge_runtime.py:384)把旧的错误消息断言改为实际字段名;同一测试在现代 provider 通过,并消除旧 provider 基线中的两项无关误报。
对主干的风险
最强回归场景有两个方向:四种非 official profile 仍签成 true,或者 official 被错误签成 false/停止安装 hook。相同现代 provider 的基线/精确头矩阵直接覆盖两个方向:基线五项 protocol 都为 true;当前头仅 official=true,其余四项为 false,同时五项 resume_cmd 结果不变。现代 provider 7589eba864f24e1eb2bdf63f3dfc42881c755832 的完整模块为 299 passed。
先前阻塞 finding 的兼容路径也已复核。旧 provider 071a884012754127f28f5b84be10f533a42db527 上,目标矩阵为 5 passed, 5 skipped;精确头完整模块为 292 passed, 5 skipped, 2 failed。剩余两项均是基线同名用例、同一 SForgeConfig.runtime_attestation_key_file 缺失签名;基线完整模块为 290 passed, 4 failed,另外两项旧错误断言已由本 PR 修正。由此,新增的五个 ImportError 已消失,旧 provider 的原 profile 覆盖没有被整组跳过。
仓库验证包括 Ruff、Python 编译、diff hygiene、RFC 双语检查,以及带 Goal 身份的 standard premerge 9/9 catalog canary;没有执行失败。精确范围质量回执 cqr_fdd3668ec06f08886ad6 已验证有效,safe-fix 未使用且没有 unresolved blocker;旧 provider 的两项既有配置失败以 base/head 同命令归因保留为非阻塞风险。benchmark_sensitive 仍按政策要求本精确头维护者审查,本评审正处理该 hold。变基后的远端 CI 在评审撰写时仍在启动或排队,合并就绪仍需等待并重新读取。未验证范围是实际 Docker、模型、签名文件落盘和科学效果;这些不影响本次 marker/协议一致性结论,但不能被本评审扩大为完整实验资格。
语义与 CI 对齐
本 diff 不新增 Enum、Literal、协议 id 或共享词表;它复用既有 PROFILES、stop_hook 和 stop_hook_enabled,属于局部派生事实修正。semantic-vocabulary smoke 在安装仓库 Node 开发依赖后通过;此前失败仅因 TypeScript 依赖缺失,未被记作代码通过。当前远端 CI 的最终状态仍是独立合并门禁。
我的整体评价
目标已经完成:签名协议现在与实际 hook owner 一致,旧 provider 兼容覆盖也在自修复后保留。长程运行审计得到改进,因为新运行不会继续积累互相矛盾的签名与 worker receipt;操作者读取协议时也不再需要猜测哪一份记录正确。代码体量与风险相称,没有新状态、迁移、CLI 或权限面;未来同域重构没有必须在本 PR 内完成的更小替代方案。
本 PR 不改变页面或渲染输出,因此视觉审阅不适用;未验证范围为真实 Docker/模型作业与科学收益。结论为 APPROVE,远端 CI 完成和精确头 merge-readiness 仍是合并前的独立步骤。
English verdict: APPROVE — head 324c53c7bbfeadb62019d3d1911c36136caa14f0; the effective Stop-hook marker now matches the official-only installer, the modern pinned provider passes 299 tests, the documented legacy provider retains five profile checks while capability-skipping only five new protocol cases, and all selected premerge canaries pass. Pending remote CI and exact-head merge readiness remain separate merge gates.
loopx-agent
left a comment
There was a problem hiding this comment.
Reviewer: model_agent · gpt-6.1-sol · OpenAI · runtime_reported · effort=max
APPROVE
动机
需要审计或比较 EdgeBench worker 运行证据的维护者。 旧代码让五种 profile 都继承非空停止钩子标记,四种实际不安装该钩子的 worker 也被协议声明为启用;现在仅 official 声明启用,公共 setup 回调保持不变。 真实 provider builder 的十组逐项对照已验证:四个错误声明被修正,其余协议字段和 setup 调用相同;现代 SDK 全模块通过,旧 SDK 原有五种 profile 的覆盖保留。 本次不启动容器、模型、solver 或评分,不改任务、权限、网络和历史签名,也不认证完整实验或科学收益。
改动思路
沿用现有 profile 与 provider builder:实例只派生一个有效 marker,共享 setup 与真正安装 hook 的 official 分支保持原 owner;无需第二配置、兼容 shim 或新协议。 当前 PR 只修复新协议的停止钩子声明并保留两种真实 SDK 能力的测试覆盖;既有运行和实验不重写。
| Profile | 原协议 | 当前协议 | Setup |
|---|---|---|---|
| official | true | true | 原共享回调与基类 hook |
| 其余四种 | true(错误) | false | 原共享回调仍调用 |
表格说明受审代码的条件,不代表真实容器/模型已执行。
具体改动
spec_ref benchmark/edgebench/README.md,spec_revision e1c42d1605669e6c03004585b070c70b5cb6a57e。按修改前的接受规格核对:worker-profiles:official 使用 SForge Codex Stop hook;其他四种 profile 不委托该 hook,保持各自完成/恢复 owner。; select-and-freeze-the-native-provider:原生 provider 与运行来源必须固定;导入 API 使用显式固定环境,不重定向历史 cohort。。实现与独立验证见下文;本提案改写的说明不被用作独立基线。公开兼容入口另参同版本benchmark/README.md的071a固定源说明。
完整两路径 +34/-2。整个生产 AST 去掉新增 self.stop_hook 赋值后与基线相同;安装、命令、预算和 receipt 逻辑没有借此次修复变更。五个原 profile 用例独立检查 continuation/marker。新 builder 测试只在实际存在私有 API 时运行;旧 SDK 仍执行原五项,而非整组跳过。已有 native_goal_continue 错误匹配改成实际字段名,修复两项旧误报。
关键代码讲解
- SForgeWorker.init:222:派生有效协议 marker;继承的全 true 改为 official-only。profile 已先由既有 PROFILES 验证;由 SForge runtime protocol 消费。
- SForgeWorker.install_stop_hook:224:所有 profile 共用 setup;共享回调不因 marker=None 而跳过。实际基类 hook 安装仍在 _install_worker 的 official 分支;由 实际 provider _install_tools 消费。
- test_only_official_delegates_continuation_and_stop_hook_to_sforge:80:独立旧 SDK 覆盖;保留五 profile 原断言并检查 marker。缺少新私有 builder 也不跳过旧覆盖;由 现代/旧 provider 消费。
- test_runtime_protocol_attests_only_official_stop_hook:102:实际协议 builder 集成;新断言按真实 API 能力限定。缺少 builder 只跳过新增五例;由 现代十项通过;旧五项通过/新增五项条件跳过 消费。
对主干的风险
最强反例是 marker=None 顺带跳过所有 setup,或现代 SDK 全绿掩盖旧 provider 的五项 ImportError。实际 provider _install_tools 与协议 builder 每版各10组证明:共享回调、全部其他协议字段相同;四个非 official 的错误声明才变化。同一独立 oracle 在基线退出1、当前退出0。
固定现代 provider 7589eba864f24e1eb2bdf63f3dfc42881c755832 / Harbor0.20.0 / Python3.12 的完整模块 299 passed。固定兼容 provider 071a884012754127f28f5b84be10f533a42db527 的目标矩阵 5 passed/5 skipped:五个跳过仅为不存在的新协议 API;当前完整模块 292 passed/5 skipped/2 failed,基线 290 passed/4 failed。剩下两项是相同 attestation-config 消费者读取缺失 runtime_attestation_key_file,未进入 worker 执行。相同命令的两个独立失败用例保留完整详情、multiplicity和匹配的 fixture/环境指纹;仅规范化随机路径/地址和相同 AST 证明的行偏移。没有把失败改记通过。
Ruff、编译、差异/RFC 检查和 standard premerge 的 5直接+9catalog 自动检查通过;整体仍 exit1/manual_review_required,benchmark_sensitive 维护者门保留。精确 CQR cqr_fdd3668ec06f08886ad6 为 PASS 且独立物理读回/原生 verify 有效;其中旧 SDK 两项仍是 failed,通过当前契约的 optional 基线归因保留,不是 waived required check。CI未查询、轮询或等待。
语义与 CI 对齐
复用既有PROFILES、stop_hook与stop_hook_enabled;不新增Enum、协议id、工作义务或authority owner。语义/vocabulary检查通过;CI不在本轮查询范围。
我的整体评价
本轮重新评估整个准确提交,并独立验证旧 finding 的修复;不采用作者当前 COMMENTED 自评作独立批准。拆开真实不同能力的测试,是比兼容 shim、改变外部 builder 或 repin 历史更小的修复。没有当前阻塞 finding。剩余旧 SDK 更广的 attestation API 兼容及真实运行资格保持单独边界。
本次只改内部 worker 协议声明和测试;检查了现有 EdgeBench CLI、worker 和 protocol 消费路径,没有渲染页面或控件变更。 未运行真实容器、模型、签名端到端或研究效果;不属于本次 marker 修复的资格。
long_horizon 为 improved、user_experience 为 improved,仅限新运行的审计事实和既有操作路径;不扩大为solver或费用收益。 旧固定 SDK 的两项 attestation-config 失败仍存在,已由相同输入和完整失败详情归因为基线;实际容器、签名端到端和研究效果未资格化。 本评审不是merge、dismiss、安装或实验授权。
English verdict: APPROVE — 324c53c7bbfeadb62019d3d1911c36136caa14f0. Correct effective Stop-hook metadata and retained five-profile legacy coverage. Modern pinned provider:299 pass; legacy:5 profile pass/5 new-API skips, with two independently matched pre-existing attestation-config failures retained. Real native protocol/setup counterfactuals and all selected automatic checks pass; maintainer/readiness and real-job qualification stay separate.
SForge signs
agent.stop_hookinto its runtime protocol, but every LoopX EdgeBench profile inherited Codex's class-level stop-hook marker even though LoopX installs that hook only for theofficialprofile. Native Goal runs therefore produced signed attestations claimingstop_hook_enabled=truewhile their worker receipts correctly saidstop_hook=false.Set the effective marker per profile so signed protocol evidence matches the installed behavior. The shared setup callback still runs for every profile, so this does not change worker installation or solver behavior. The regression test exercises SForge's real protocol builder across all five profiles; it also corrects a pre-existing mismatched error assertion exposed by the full focused suite.
Validation:
294 passedinbenchmark/tests/test_sforge_runtime.pyagainst the pinned SForge integration checkout.