fix(benchmark): preserve explicit effort and staged model catalogs

[songoow]

Motivation / 必要性

An explicitly requested reasoning effort must reach the model unchanged. The EdgeBench CLI rejected max, and both its installer and the inherited native command translated max into xhigh. Providers with distinct meanings for those values could therefore execute a different treatment than the recorded configuration.

Official/plain workers also staged an optional model catalog without referencing it in their Codex home. A baseline could consequently use unknown-model tool defaults while the LoopX worker used the supplied catalog. Merely recording equal model names did not establish equal model/tool inputs.

Changes / 修复方式

• Reuse LoopX's existing effort vocabulary and preserve the explicit effort through installation and initial/resume commands. Model/provider support still requires real qualification; accepting a CLI value does not certify support.
• Bind the official worker to the same validated catalog bytes staged by the existing offline installer. Separate the host validation source from its absolute guest destination.
• Retain no-catalog behavior and non-max effort behavior. Native Stop hooks, task semantics, submission rules, grading, quotas and LoopX policy are unchanged.

这是一条适配层修复，不是新的研究策略。必要性在于防止“记录为 max、实际降档”，以及基线与处理臂使用不同模型工具面。既有 Python provider 是本次输入与容器安装边界的 owner；不新增通用控制面状态或另一套推理档位枚举。

Validation / 验证

• Exact PR head: focused adapter/catalog/default-parity checks 21 passed on a remote host.
• The same patch composed with fix: align agent instructions and prompts with current execution contracts #6725: four focused suites 493 passed, covering SForge runtime, shared Codex runtime, feedback and task entry. These are combination-source results, not a claim that every main-branch suite passed.
• Guest destination rejects missing/invalid catalog sources and relative destinations; changing a trial's fixed destination is rejected.
• Explicit max, xhigh and high remain distinct in initial/resume commands and heartbeat inputs. Catalog-off behavior remains covered.
• git diff --check passed. Live provider/container/long-run qualification remains separate and is not certified by these tests.

No credentials, private runtime evidence, model transcripts or machine configuration are included. No merge is requested by experimental launch authorization.

[loopx-agent]

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

动机

运行相同模型对照的操作者，需要记录的推理档位和模型工具目录真正进入每个 worker。

旧路径把明确请求的 max 转成 xhigh，official/plain worker 虽复制了模型目录文件，却没有在自己的配置中引用它；记录相同模型名仍可能使用不同输入。

当前补丁在安装和初始/恢复命令中保留显式档位，并让 official/plain 的配置引用已验证来源对应的容器内目录文件。

本次不证明模型服务支持所有档位、真实工具面完全一致、研究得分或长期收益，也不启动 benchmark 任务、推理或评分。

改动思路

同一个研究输入不能在 adapter 内被静默换档；但接受一个字符串也不等于服务端支持它。这里复用现有 REASONING_EFFORTS，在 Python provider 中传输 caller 的输入，保留实际模型/二进制组合 qualification 的原责任。

配置渲染复用 prepare_codex_home 的既有校验和固定设置身份，安装器只补充已 staging 文件的来源与 guest 路径，不另建模型目录或档位决策 owner。

当前 PR 边界是既有 EdgeBench/共享 Codex provider 的输入保真和已 staging catalog 的配置绑定；不改变 task、Stop hook、分数、续办权限或实验准入。

不修复会让记录与执行不一致；在 host 上手工抄同一份路径会把 host 路径带入容器；新建另一套 catalog renderer 又会复制验证规则。当前 source/destination 分离较小且有用。model_catalog_destination 只决定已经验证文件在 guest 配置中的位置，没有自己触发上传或证明工具能力。以下表只是源码解释，真实安装证据另列。

输入	base	当前 head
明确 max	安装和 native command 降为 xhigh	保留 max
明确 xhigh/high	原样传输	原样传输
有 catalog	guest 文件存在，但 official/plain 配置缺引用	引用固定 guest 路径，字节与 host 来源一致
无 catalog	不引用该字段	保留原形状
相同 trial 更换固定设置	拒绝不一致	也拒绝更换 destination

具体改动

准确 head 647a360fc5762af28108f5fc422865ce1a430174，实际 base f9bdae67596c185cebc81dc555dd6a3e0242e9c5，6路径、+118/-7。先读改动前的 benchmark/runtime/RUNTIME.md（完整 base 同上）及 SETTINGS、EdgeBench说明，再读完整 diff。依据 RUNTIME 的 Configure the native job：caller 明确提供档位；Offline and git-less task images：目录要实际被 trial home 引用、校验 requested model/tool_mode，真正工具面仍需 first-request qualification。SETTINGS 的 Model and effort 要求 pin 两者；EdgeBench 要求各 profile 使用同一显式二进制和模型/档位。没有用本 PR 新增参数作为独立规范。

1. benchmark/edgebench/run.py:115 将 --effort 接受集接到已有 loopx.reasoning_effort.REASONING_EFFORTS；没有新建平行 enum。真实 CLI 对照中，base 在 argparse 阶段拒绝 max/ultra，head 接受后继续到原来的缺凭证拒绝；xhigh 的拒绝路径保持，非法值两侧仍拒绝，全部没有创建 trial。
2. SForgeWorker._install_worker:221 不再把 max 改成 xhigh；official/single 的 CodexOffline.install 真正返回后，把其 staging 来源交给 prepare_codex_home 校验，并使用既有 MODEL_CATALOG_REMOTE 作为目标路径。
3. CodexOffline.install 只在真实 catalog 上传后记录本地来源；guest 文件仍由已有 install 命令复制。prepare_codex_home:113 新可选 destination 需要有效 catalog 和绝对路径；仍由 host 文件校验 requested model 和 tool_mode。不同固定 destination 会被既有 settings identity 拒绝，未清空历史会话来“修复”冲突。
4. SForgeWorker.format_run_cmd:355 沿用 native SForge 的初始/恢复和 Stop hook 行为，仅对显式 max 撤销其已知 xhigh 别名；其余命令由原 native owner 生成。既有 heartbeat/native-goal 继续走同一个共享 runtime。
5. 两个现有测试模块补档位、CLI gate、catalog-on/off、非法来源/相对目标和设置不可变回归，没有新 runner、评分器或额外 protocol。

独立执行493个相关测试，不是借用作者“组合 #6725”的结果。另在 network=none 的自有 Docker 容器走真实 base/head provider 安装、SForgeEnvironment 上传、guest install、权限、配置和原生 Stop hook，共16个对照：official/single × max/xhigh × catalog有/无。base max实际配置/命令为xhigh，head均为max；catalog两侧都复制同一字节，但只有head配置指向可由agent读取的固定guest文件；无catalog/xhigh保持形状，host目录未泄漏进配置。合成 offline executable 只报告版本，未让它模拟模型成功；这是实际安装 IO 证据，不是完整 Codex 推理或工具面证明。

此外独立运行真实 codex-cli 0.162.0-alpha.17.2，通过既有 toolface helper 向本地 HTTP400 stub 发送首个请求后停止，没有模型推理或真实凭证。max与xhigh的请求分别保持max/xhigh；ultra在该客户端内部变成max。因此本次只验证 adapter 保留输入，不能把 CLI 接受 ultra 称为服务端或客户端端到端支持 ultra。这个客户端观察也不能代替 Linux离线二进制/catalog组合的工具面资格；仍需按文档在真实选定组合上执行。

对主干的风险

没有发现当前6路径的阻断项。主要风险是误把“接受参数/配置有路径”当成有效治疗或工具面一致；本次真实安装证明配置消费了 staging 结果，真实首请求只验证了上述特定客户端的档位，不授予其他版本、模型、目录或研究结论。官方/单次 no-catalog、非max，以及共享renderer旧调用未传新可选参数时均保持原路径；当前不需要新前端开关，研究CLI是已有用户入口。

Ruff 在 test_shared_codex_runtime.py 报5项 E702。对完整6路径运行相同命令，在不可变base和head归一化文件/规则/源码行/列后逐项相同，都是既有 native_goal_rounds 测试中的分号，未由本次18行插入引入；不伪称 Ruff全绿，也不放宽规则。493相关测试、完整semantic、公开扫描、DCO/diff和标准premerge的5个直接+10个选中检查通过。premerge总体仍为manual_review_required，原因是benchmark_sensitive维护者hold，不是自动可合并。公开扫描0 error/2隔离registry警告。初次验证曾用不存在的测试文件名，未运行；Docker反例初次漏建合成日志目录，修正夹具后完成16例，故不把启动错误记成产品失败。没有查询、派发或等待CI。

保留公开说明的行为变化：显式max今后不再被adapter降档；catalog存在时official/plain会实际启用这份用户选择的目录，模型消息和工具配置本来就是研究输入的一部分。未选择catalog时不会从安装可用性推断激活。不同目录或不同档位要新trial，不能借修复改写已冻结实验的结果或历史回执。

我的整体评价

APPROVE — 647a360fc5762af28108f5fc422865ce1a430174。本次适用的 Configure the native job 与 Offline and git-less task images 输入传输要求已核验；特定模型、Linux离线客户端的完整工具面和长期净效收益没有据此关闭。基线静态红灯与维护者hold分别保留，不用测试数量代替研究有效性。

相邻未来改动检查已应用：复用已有effort词表、同一个catalog验证/渲染owner和native命令，而没有增加新的通用控制面决策源；Python保留域provider的安装与命令桥接合适。下一次上游native模板改变时应重新验证这一个兼容别名，当前无须新建框架或再拆一条仅serializer的PR。原用户任务仍是准备已知固定输入、启动并读回既有trial，零新增必需确认轮次；缺凭证/冲突依旧明确停止。研究配置不授予模型调用、实验发布、跨角色执行、默认安装更新或合并权限。

English verdict: APPROVE - 647a360. Explicit max survives adapter installation and initial/resume commands;16 real Docker installation comparisons bind staged catalog bytes to the guest config and preserve no-catalog/xhigh behavior.493 tests pass;5 Ruff E702 findings match the immutable baseline. Native premerge retains its benchmark maintainer hold. Live provider/toolface qualification remains separate; this one real local client normalizes ultra to max.

[songoow]

合并资格补充（非重复评审）

准确 head：647a360fc5762af28108f5fc422865ce1a430174；base：f9bdae67596c185cebc81dc555dd6a3e0242e9c5。沿用 当前 head 的独立批准评审，不重复发布同 head 的批准结论。

对照改动前的 RUNTIME：Configure the native job / Offline and git-less task images，补充了真实 Linux codex-cli 0.163.0 的 base/head 首请求验证：两侧均经过实际 SForgeWorker、CodexOffline、SForgeEnvironment 和 DockerBackend 安装与文件上传，使用相同二进制及公开完整 catalog，容器禁用外部网络，本地 HTTP 400 接收首请求后即停止，没有模型推理。base 实际发出 xhigh，head 发出明确请求的 max；head 配置引用固定 guest catalog，上传字节的 SHA256 与来源一致。该组合的首请求工具面也随 catalog 正确启用而改变；这不是所有客户端、模型或目录组合的资格证明。

独立在准确 head 执行 test_sforge_runtime.py、test_shared_codex_runtime.py、test_edgebench_feedback.py、test_task_entry.py：493 passed、无跳过。quick premerge 的 5 项直接检查和 3 项选中检查通过（包括完整 semantic、maintainability、benchmark permission）；总体仍保留 benchmark_sensitive 的维护者人工判断，不称自动可合并。六路径 Ruff 的 5 项 E702 与不可变 base 的规则、源码行和列逐项一致，均在未改动的既有测试代码中；不称 Ruff 全绿，也未放宽规则。

产品判断：这是同一输入在 provider 安装、配置和初始/恢复命令之间的保真修复；复用既有 effort 词表、catalog 校验/渲染和 native 命令 owner，没有增加第二套决策规则。非 max、未选择 catalog 的既有路径保留。原 native 命令模板兼容替换仍受上游版本约束，已用实际首请求核验当前组合；无需为此增加通用框架。它不改变任务评分、Stop hook、预算或研究决策，不证明长期研究收益。

用户已明确授权审查无问题后合并；该授权不代替合并门槛。当前批准 closeout 清晰、无未解决讨论，但 6 个 Python test-shard 尚处于 pending，因此仍 暂缓合并。保持 wait_for_ci=true，不取消其他候选、不修改保护规则、不绕过 CI；仅在准确 head 不变且原生 merge-readiness 返回 ready=true 后执行正常合并。