feat(benchmark): reject replayed segment receipts

[cocolord]

Summary

• add a provider-neutral segment receipt reducer and CLI that fail closed on wrong identity, out-of-window writes, and nonce replay
• expose the contract through benchmark-toolkit while keeping nonce, timestamps, receipt contents, paths, and run identity out of public output
• document runner-owned transient cleanup and per-segment nonce duties in the capability and LoopX benchmark/self-repair playbooks

Why

A multi-segment benchmark adapter can otherwise reuse a fixed-path receipt from an earlier segment after the current process exits before writing fresh evidence. Aggregate completion may then look valid even though the continuation did not run.

Validation

• uv run --extra test pytest -q tests/capabilities/test_benchmark_segment_receipt.py tests/capabilities/test_benchmark_runtime_continuity.py tests/capabilities/test_benchmark_toolkit.py — 130 passed
• uv run --extra test ruff check ... — passed
• loopx check over all 8 changed public paths — public/private boundary clean; two unrelated existing Goal projection warnings only
• loopx canary premerge --from-git-diff --tier standard --format json --no-progress — 4 direct checks plus 18 selected checks passed; no failures or skips

Risk and review

• Changed surfaces: benchmark-toolkit reducer/export, benchmark CLI, focused tests, capability docs, benchmark skill, self-repair pattern catalog.
• No runner launch, scoring, task semantics, submission, permission boundary, credential flow, or private evidence behavior changed.
• Public/private boundary scan found no hits.
• The canary classified the diff as benchmark-sensitive, so this PR intentionally remains open for maintainer review and is not self-merged.
• Future-facing pass: the contract stays in the existing provider-neutral benchmark-toolkit owner; no benchmark-specific builder or second authority was added.

[huangruiteng]

动机

本 PR 想解决 benchmark segment receipt 被错误复用的问题：receipt 必须属于当前 segment、写入时间必须落在该 segment 窗口内、nonce 不能在 prior receipts 中重放，同时公共结果不能泄露 nonce、时间戳、receipt 内容、run identity 或路径。这个失败一旦发生，会污染 segment countability、重试和 closeout，且仅看最终分数很难归因。新增 reducer/CLI 的局部设计确实表达了这些不变量，但我在完整 exact-head 审阅中没有找到任何现有 segment runner 调用它。因此 PR 描述的 stale/replay 修复尚未抵达真实生产 acceptance path；当前实现更像一个未来调用方的 contract，而不是已修复的现有 bug。

改动思路

build_benchmark_segment_receipt 接收 expected/observed nonce、segment start/write/end 和 prior nonce 列表，先做 nonce/时区时间解析，再按“身份不匹配 -> replay -> 窗口外 -> qualified”的顺序分类，返回 compact booleans 与 accept_segment_receipt/discard_and_rerun transition。loopx benchmark segment-receipt 暴露同一 reducer，并通过 --require-qualified 把 false 映射为非零退出；docstring 明确 nonce 生成、文件清理、进程执行、时间采集和 retry 仍由 runner 负责。这个 ownership 划分本身合理，也没有把 benchmark 语义写入通用 quota/todo contract，但它要求一个实际 runner 消费 transition。当前 rg 仅看到新 module、CLI 和测试，没有看到活动 runner 的接线，故 disabled 旧路径仍可直接消费固定路径旧 receipt。

具体改动

生产面新增 segment_receipt.py（119 行）及两个 typed Enum，导出到 benchmark_toolkit/__init__.py；benchmark_boundary.py 增加 parser、结构化 invalid payload、渲染和 --require-qualified exit；catalog_entry.py 只在 required_sequence 增加 qualification 名称。测试新增 120 行，覆盖合法、身份不匹配、窗口外、replay、无效输入、CLI 退出码和 public boundary；README、loopx-benchmark skill 与 self-repair pattern 记录了使用和安全边界。wheel 能打包新 module/skill，未发现 scoring、launch 或权限代码被改动，但 catalog 的 commands projection 没有同步 segment-receipt，导致新命令不可发现。

关键代码讲解

1. BenchmarkSegmentReceiptClassification（loopx/capabilities/benchmark_toolkit/segment_receipt.py:15）把 invalid、qualified、identity mismatch、outside-window、replayed 变成 typed state，分支优先级明确，避免散落布尔判断。
2. build_benchmark_segment_receipt（同文件第 51 行）校验 ended >= started、身份、窗口和 prior 唯一性，并固定 write_performed=false 及 public boundary false；它不读取或清理 receipt，所以无法单独改变旧 runner 的行为。
3. segment_parser 与 CLI 分支（loopx/cli_commands/benchmark_boundary.py:285-613）提供可脚本化入口；语义 invalid 会生成 JSON，--require-qualified 对不合格结果返回 1，但缺少必需 argparse 参数仍是标准 exit 2。
4. agent_usage.required_sequence（loopx/capabilities/benchmark_toolkit/catalog_entry.py:406）声明 qualification 是流程要求，却没有对应 command catalog row，形成发现性漂移。

对主干的风险

有两个 P1 blocking finding，以及一个 P2：

1. P1 — 没有活动 runner 接线。 在第二个 segment 从固定路径读到第一段残留 receipt、或 receipt 身份/窗口错误时，现有 runner 没有调用 reducer，仍可能把旧结果送入 closeout。最小修复是在真实 receipt consumer 接入 reducer，传入 fresh nonce、started/written/ended 和 prior list，并让 false 进入 runner-owned cleanup/retry；如果本 PR 有意只交付未来 contract，则应缩小 PR 的声明与 docs，并记录 owner-accepted coverage-only boundary，同时移除“现有 bug 已修复”的暗示。必须增加两段真实 runner lifecycle 的 end-to-end regression，而不只是 helper 单测。
2. P1 — exact head 的 required checks 未通过。 68d7a7cbc2b8139e9e33332f2757e1bb2444dc6f 当前 27 个检查中 25 个成功，windows-powershell 失败，派生的 merge-gate 也失败。Windows 日志定位到 test_windows_installer_promotes_release_and_runs_doctor 对 quota should-run 的 returncode 断言为 1；这看起来与 segment reducer 无关，但 required check 未绿前不能合并。请先重跑/修复该 baseline，确认同一 exact head 的所有 required checks，再请求复审；任何修复提交都必须按新 head 重新走完整 review。
3. P2 — catalog 漂移。 required_sequence 已要求 qualification，但 commands projection 没有 loopx benchmark segment-receipt 条目。补 command metadata 和 catalog smoke，或在命令真正可公开前撤回过早的 required_sequence。

正向验证充分证明 reducer/CLI 的局部语义：focused suite 11 passed，和相邻 toolkit/runtime continuity 共 130 passed，compileall、diff check、CLI positive/mismatch、wheel build 均通过。它们不能替代真实 runner/cleanup/retry 验证；ruff 在审阅环境不可用，未将其当作通过证据。PR 声称的 opt-in 行为在 disabled 旧 runner 上保持原样，这证明了隔离，却也明确揭示主要修复尚未生效。

我的整体评价

typed classification、public-safe payload 和 CLI exit 设计是可复用的局部基础，命名也没有夸大 agent/peer authority；但 repository_reuse、observable_semantics、scope_fit 和 change_proportionality 的证据都显示：当前 361 行扩展仍缺一个真实 consumer，且 exact head 有 required Windows/merge-gate failure。绿的 helper tests 不能覆盖“旧 receipt 在真实 runner 被接受”这一最强反例。因此本轮对 exact head REQUEST_CHANGES，优先接线或明确收窄 contract-only scope，修复/重跑 Windows required check，再补 catalog discoverability 和真实 lifecycle regression 后复审。

English verdict: REQUEST_CHANGES for exact head 68d7a7cbc2b8139e9e33332f2757e1bb2444dc6f. Blocking findings: the reducer/CLI is not connected to any active segment receipt consumer, so stale fixed-path receipts can still be accepted; windows-powershell and derived merge-gate are failing. Please wire and test the real runner (or narrow the claim), fix/rerun required checks, and align the capability catalog. Local evidence is strong (11 focused and 130 adjacent tests passed, compile/diff/CLI/wheel checks passed) but does not prove production integration.