[loopx-agent]

Goal And Delivered Outcome

The mid-wake checkpoint controller test starts with File authority, then tries to select SQLite after the first wake has installed the writer fence. The provider rejects that change before the test reaches checkpoint capture. Initialize the controller fixture with SQLite and use the existing fixture helper to advance the same store when the test introduces a later review.

• Intended base: main.

Author Declaration

• Written by: model_agent, OpenAI Codex.
• Implemented against the controller capture and continuation behavior in the benchmark qualification guide at the base revision.
• Criterion implemented: the controller smoke reaches native capture and continues after a duplicate guard using a single canonical store. The real controller regression below exercises both.

Scope And Continuation

Complete within the test fixture. The other test variants keep File authority and use the same existing helper for the later fixture update. Runtime code, checkpoint policy, and provider selection are outside this change.

Validation

• Tested revision: ebbc461cadf813bc122a19e9719c711a5b841f98.
• Run state: finished.
• Input classes: synthetic.

Check kind	Result	Public-safe evidence / limitation
real_entrypoint	passed	test_actual_worker_handles_midwake_replan_and_duplicate_without_guard_replay[True-controller] on Linux amd64 with Codex CLI 0.162.1, the Docker writer barrier and the native context delivery path. The test checks one capture and continuation after a duplicate guard.
real_backend	passed	Canonical SQLite on the same isolated Linux fixture. Model inference and evaluator values were synthetic.
regression_parity	passed	The unfixed controller fixture on the integration checkout stopped at provider selection after the writer fence. At the tested main-targeted revision, the same smoke reaches capture and checks native continuation.
static	passed	git diff --check and DCO trailer.

• Coverage and gaps: The targeted controller variant covers the SQLite initialization change. The full native fixture matrix was not run for this PR.

Frontend / Visual Evidence

• UI impact: none.

Type of Change

• Test update

LoopX Area

• Benchmark boundary (adapters, runners, verifiers, scoring, evidence)

Shared-authority RFC fixture impact

N/A. The change uses the existing fixture API and leaves the authority contract unchanged.

Boundary Checklist

• Public-safe test fixture and validation summary only.
• Scoped to the reproduced regression.
• No paired RFC or UI change.
• DCO sign-off on the commit.

[loopx-agent]

Reviewer: model_agent · gpt-6.1-sol · OpenAI · runtime_reported · max

Approval conclusion (author-owned PR; GitHub blocks formal self-approval)

没有阻塞性发现。 最大剩余验证是独立复跑完整的 Linux external controller 与 Docker writer barrier。

动机 / Motivation

维护者在运行 checkpoint controller smoke 时，需要确认 worker 能在 replan 后捕获一次，并继续原会话。

基线先在 File 建立防止旧写者修改的 writer fence，后来才尝试切换到 SQLite，因而卡在真正的 checkpoint 流程之前。候选从一开始就使用同一 SQLite。

独立复现看到 SQLite 文件和存储身份保持，版本推进后两次 replan guard 仍只有一份回执。原 File 捕获和关闭捕获两个变体继续通过。 本轮只评审测试夹具。完整 Linux controller 测试由作者提供；研究点资格、真实推理和完整 benchmark 验收各有自己的边界。

改动思路 / Approach

原 guard 完成后，fixture 模拟同一 wake 中出现一个新的 replan。候选在创建第一个 fence 前选择 SQLite，后来沿用原 store 的版本执行 CAS。File 变体按原设置选 provider。只把初始 provider 换成 SQLite 仍会走旧的中途重新初始化。两个位置一起改，才会保留首个 fence 和回执。

provider 选择和 writer fence 是 fixture 的前置条件。后来改写测试场景时应走已经选定的 canonical store。 把修改限制在一个 native checkpoint fixture，沿用现有 provider、CAS helper、controller 验证和 writer barrier。

具体改动 / Changes

评审提交为 ebbc461cadf813bc122a19e9719c711a5b841f98。以 main 的 71190b6b4ef4e146f3bf4a10d31ce61ac42fd021 固定比较基线，本地与远端 1 个路径的改动一致。采用基线的 benchmark/README.md。 基线规范

• controller-existing-store 已验证首个 fence 和后续 CAS 使用同一真实 SQLite。
• original-guard-once 已验证原 preflight 结算保留，两个后续 guard 只留下一个 replan 回执。
• capture-off-parity 已验证原 native File 及关闭捕获变体。
• qualified-research-point 属于独立验收，当前 fixture 仍以合成场景验证。

关键代码讲解

• 初始化只为显式 controller 变体在首个 writer fence 前选 SQLite。源码
• mid-wake response 把后续场景写入当前 provider。旧 File 变体继续用 soft_claim，controller 的合成 replan 用 hard_lease。源码
• advance_canonical_fixture_authority 打开已有 store，读出版本并执行 CAS。现有 callback 同时保留原 preflight 的 index 行。源码

对主干的风险 / Risks

基线在实际 File writer fence 后选择 SQLite，provider 拒绝并保留原 File store 与 preflight 回执。 同一 SQLite store identity 和文件 inode，原生 CAS 更新版本并读回 hard_lease，原 preflight 1 份回执与 1 条 spend，后续重复 guard 1 份 replan 回执。 对照运行了精确 checkout 的初始化和 mid-wake callback 语句，后端与 quota CLI 为真实实现。真实 macOS Codex CLI 0.167.0-alpha.3.2，True-files / True-off 基线与候选各两例通过；合成模型响应。

作者在同一 head 报告 Linux amd64 Codex CLI 0.162.1 的完整 True-controller，包括 Docker writer barrier 和一次捕获后继续。我本地的独立覆盖为上述 SQLite 与 native File 两条路径。快速预合并 5 项直接检查、3 项所选检查零失败，手工评审门保留。CI 未查询。

语义与 CI 对齐

hard_lease、soft_claim 与 fixture CAS 都复用既有 vocabulary。对照检查的是 authority 身份、原结算和重复请求结果，测试可持续保留。

我的整体评价 / Verdict

复现恢复了 checkpoint smoke 原本要观察的连续性。这个测试变化消除了 fixture 自己制造的换库故障，便于后续观察真实 controller 的行为。 对维护者而言，仍用原命令即可抵达原 checkpoint 验证条件，无需手动迁移 fixture。完整 Linux amd64 True-controller、Docker barrier 和受控 native interruption 为作者测试；我未独立执行整条 Linux 组合路径。未执行全矩阵或真实模型。

English verdict: APPROVE at ebbc461. The controller fixture advances its existing SQLite authority and preserves duplicate-guard behavior.

[huangruiteng]

Reviewer: model_agent, GPT-5, OpenAI, self_reported

Independent approval

动机 / Motivation

维护 checkpoint controller / benchmark qualification 的开发者，以及依赖该 smoke 判断 native capture 是否发生的验证流程。fixture 先用 File authority 初始化，随后在 runner 中尝试切 SQLite；provider selection 被已存在的 writer fence 拒绝，测试在 checkpoint capture 之前停止。同一 controller 变体在 base 上于 provider selection 处停止；head 在首个 fence 前使用 SQLite，随后通过 CAS helper 推进原 store，并继续检查 capture、duplicate guard 和 continuation。

本地 provider-fence/CAS helper 与 File 变体通过；native controller 10 个参数组合因缺少 LOOPX_NATIVE_CHECKPOINT_BIN 被跳过，作者提供的 Linux real-entrypoint 证据不冒充本地通过。

本 PR 不扩展 checkpoint artifact、research-point qualification、provider 默认值或真实模型能力；它只修复 benchmark fixture 的前置条件。

改动思路 / Approach

入口仍是 benchmark checkpoint controller fixture。_initialize_fixture_authority 在首次 writer fence 前选择 SQLite，advance_canonical_fixture_authority 打开已有 store、读取当前 provider revision 并执行 CAS。File/native/full/off 变体保留原来的 File 与 soft_claim 行为。

这个安排将 provider 选择放在 disposable fixture 的初始化所有者中，把 later synthetic projection 交给 canonical fixture helper。它删除了原先手工拼接 Node provider script 和 controller 中途重新初始化的路径，没有修改 runtime checkpoint code、provider 默认值或持久 authority 契约。This is a test-only authority setup correction using the existing canonical CAS owner, with no production policy or persistent-state change. Deliver the fixture fix and its local provider/File evidence; retain the author's Linux external-controller observation as an explicitly separate environment qualification.

场景	base	当前 head
controller 首个 fence	File 已建立 fence 后请求 SQLite，provider 拒绝	SQLite 在 fence 前选定
后续 synthetic replan	手工 provider script 可能重建/切换 store	通过现有 CAS helper 推进同一 store
File/native/off	File + 原 soft_claim 分支	保持原行为
无 native controller binary	跳过	继续显式跳过，不伪造通过

具体改动 / Changes

本次核对 ed8137c45b6bdba783332502806181669f4ded36 相对 99fdb8c6fc523651d3667085d042d0566afb03ac 的 1 个文件，+10/−22。规范依据是 Inert checkpoint capture revision 71190b6b4ef4e146f3bf4a10d31ce61ac42fd021。

• single-authority-before-capture：controller fixture 在首次 writer fence 前选定 SQLite，later synthetic projection 通过当前 store 的 CAS 更新。
• preserve-existing-capture-variants：File、native、off 分支继续使用 File provider 与原有 soft_claim 行为。
• preserve-settlement-and-duplicate-guard：原有 preflight rows 被保留；重复 guard 走已有 continuation 分支而不是再次 capture。

关键代码讲解

• controller provider initialization 让 controller 在 _initialize_fixture_authority 之前选定 SQLite，其他变体继续选择 File；这是避免 first-fence provider conflict 的关键顺序。
• midwake canonical update 把 synthetic replan 投影交给 advance_canonical_fixture_authority，并使用 hard_lease 只用于 controller 分支。
• advance_canonical_fixture_authority 读取现有 store head 并通过 expected provider revision 提交，拒绝回到 Markdown 或创建第二个 authority。

测试还保留原 preflight index rows，因此 synthetic fixture 更新不会抹去已完成 Host Turn 的证据；重复 guard 分支没有被改成第二次 capture。

对主干的风险 / Risks

没有新的 blocking finding。最强反例是 later synthetic replan 重新初始化 SQLite 或重新导入 Markdown，导致 smoke 在另一个 authority 上通过；当前 fixture 在首个 fence 前选定 provider，later update 只走现有 CAS helper，所以 provider identity 与 revision 保持在同一个 store。第二风险是只改初始化而保留中途 provider script，仍可能重演切换；这次同时删除了该脚本。

本地 exact-head 验证为 provider-fence/CAS 与 benchmark fixture 共 23 passed, 27 skipped；Ruff、py_compile 和 diff check 通过。native controller 的 10 个参数组合因 LOOPX_NATIVE_CHECKPOINT_BIN 未设置而跳过，作者报告的 Linux amd64 controller/real entrypoint 结果只能作为外部环境证据，不能写成独立本地 passed。远端 CI 作为独立 merge-readiness 观察保留；视觉审查不适用，因为这是 test-only fixture。

语义与 CI 对齐

candidate decision 是 reuse_existing：复用 canonical authority fixture 与 checkpoint vocabulary，没有新增 provider、持久状态或用户协议。CI 不是本 PR 的 changed-invariant oracle；native controller 环境缺口与 local provider-fence 证据分开记录，未把 skip 或 CI 状态伪装成通过。

我的整体评价 / Verdict

这个修复让 checkpoint smoke 不再由 fixture 自身制造 provider 冲突，维护者仍使用原 benchmark 命令就能到达 capture 和 continuation 断言。它对长程能力本身保持中性，对 benchmark fixture 的 truthful coverage 是改善；用户界面没有变化。实现复用了现有 canonical CAS helper，并删除了重复的 manual provider path，残余风险主要是外部 controller/Docker/native CLI 环境不在本机可用。

English verdict: APPROVE for ed8137c. The controller fixture now selects SQLite before the first writer fence and advances that existing store through the shared canonical CAS helper; local provider-fence tests pass, while unavailable native-controller runs are explicitly retained as environment-gated evidence gaps.