test(bench): allow measured request-history runner variation

.agents/notes/implemented/simplification/2026-09-06-agent-request-freeze-provenance.i18n.yaml

@@ -2,5 +2,5 @@
 # side as of the last confirmed-consistent state. Both languages carry equal authority;
 # after editing either side, bring the other along and re-record with:
 #   pnpm run verify-translation-pairing --write .agents/notes/implemented/simplification/2026-09-06-agent-request-freeze-provenance.md
-2026-09-06-agent-request-freeze-provenance.md: 7a4816df61f6490647aba6f0603719e1b4662a20
-2026-09-06-agent-request-freeze-provenance.zh.md: 239d7e69df1596010ef0f3c8789250f654a75cb1
+2026-09-06-agent-request-freeze-provenance.md: 1235a87ea549c6bbd9c53620017cb1d96f8e7cf7
+2026-09-06-agent-request-freeze-provenance.zh.md: 357b25b0f252a9423c485b2cc119f1226ec16687

.agents/notes/implemented/simplification/2026-09-06-agent-request-freeze-provenance.md

@@ -40,9 +40,21 @@ The standard two-CPU `ubuntu-24.04` lane runs Node 24.20.0. [Run 34033336380, jo
 
 A second hosted run of the same request implementation, [run 34033336246, job 101487216170](https://github.com/deepseek-harness/deepseek-harness/actions/runs/34033336246/job/101487216170), records 145.644577, 144.204300, 143.072572, 145.985903, 146.834474 ms; median 145.644577 ms. It uses the same Ubuntu image and Node version but a different worker in Azure westus3 at merge commit `c366e49`. This faster run does not replace the eastus evidence or establish why the workers differ. The older self-hosted `VM-7-113-ubuntu-ci-9` run with Node 24.18.1 ([run 34021903421, job 101456015028](https://github.com/deepseek-harness/deepseek-harness/actions/runs/34021903421/job/101456015028)) records 110.025154, 119.958978, 108.266860, 107.557950, 108.538902 ms; median 108.538902 ms. Its runner and Node version do not calibrate the standard hosted lane.
 
-The request-history CI expectation is 190 ms, rounded above this observed range. The enforced median budget is `ceil(190 × 1.25) = 238 ms`; the shared 2× reference-machine scale does not apply again to a CI measurement. This matches the direct-CI calibration method of the [63 ms Session-reopen budget](../../../../benchmarks/session-open/session-open.bench.ts), rather than relabeling the M4 reference as hosted evidence. The 238 ms budget remains below the isolated original implementation’s 246.130875 ms M4 median.
+The current request-history median limit is 297 ms. It is the largest integer within a 25% increase from the initial 238 ms limit: `floor(238 × 1.25) = 297`, an increase of 24.79%. This allowance belongs only to `agent-continuation/request-history`; the shared time scale, variance headroom, other time limits, memory limits, sample count, and workload remain unchanged.
 
-Deterministic controls call the same `assertRequestHistoryBudget` assertion as the timed case. They accept the recorded hosted median and maximum (185.042397 ms), reject the recorded original M4 median, and reject a synthetic 250 ms median from 248, 250, 252, 251, 249 ms inputs. The synthetic inputs model a material regression; they are not runtime measurements. Replaying recorded values verifies the assertion, not a new hosted run. The acceptance control fails at 175 ms before calibration; all three controls and the five request-freeze behavior tests pass at 238 ms.
+The standard GitHub Actions `ubuntu-24.04` runner group reports the same image `20260831.293.1` and Node 24.20.0 for the two release measurements below. The workers differ (`1000050430` and `1000050689`), but their hardware and resource conditions are not established by the logs. The request-history runtime and workload are identical between the two heads: 800 historical turns, four tools per historical turn, 40 live requests, and 13,925 final events. The earlier reference run supplies another slow observation.
+
+| Hosted measurement | Request-history raw totals (ms) | Median (ms) |
+|---|---|---:|
+| [Release `f778396b2e`](https://github.com/deepseek-harness/deepseek-harness/actions/runs/34233932940/job/102086694864) | 152.649609, 154.616595, 144.588531, 144.261013, 154.017377 | 152.649609 |
+| [Release `a0a61a8237`](https://github.com/deepseek-harness/deepseek-harness/actions/runs/34235890227/job/102095345914) | 246.876615, 246.881047, 272.370218, 265.796833, 272.507507 | 265.796833 |
+| [Reference `35fcb95275`](https://github.com/deepseek-harness/deepseek-harness/actions/runs/34232504298/job/102084171717) | 279.689489, 297.792849, 263.178391, 252.660292, 251.267361 | 263.178391 |
+
+The first two jobs also differ across tool continuation (483.877/698.657 ms), catalog (612.127/1009.367 ms), and profile continuation (2438.362/3854.950 ms). These observations establish broad hosted execution-time variation; they do not identify a hardware fault or a runtime regression. Among these four continuation scenarios, only request history crosses its limit in the slower release run.
+
+A bounded profile of `a0a61a8237` on Apple M4 Pro / Node 24.19.0 retains five fresh-process totals: 70.198916, 67.432250, 65.151208, 66.473292, 71.049667 ms; median 67.432250 ms. Every sample completes the same 40 requests and 13,925 events. Sampling attributes 38.082 ms inclusive time to adapter dispatch, including 10.878 ms of required file-content traversal; system-node scanning takes 4.127 ms, while the one-time restored-event reversal takes 0.291 ms outside the timed turns. Removing the latter cannot explain the observed turn cost. Caching projected content or system nodes adds immutability or invalidation obligations beyond this bounded allowance. Runtime code is unchanged.
+
+Deterministic controls call the timed case's `assertRequestHistoryBudget`. They accept the recorded 185.042397 ms maximum and the two slower hosted medians, while rejecting a synthetic 310 ms median from 308, 310, 312, 311, 309 ms inputs. The slower-host acceptance control reproduces `265.796833 > 238` before the allowance; the complete owner file passes 11 tests at 297 ms. Replaying recorded values validates the assertion, not a new hosted run. The historical 250 ms synthetic case and the 246.130875 ms original M4 measurement fit this allowance and are no longer rejection controls; original/optimized M4 measurements remain evidence of the freeze implementation's gain.
 
 ## Alternatives considered
 

.agents/notes/implemented/simplification/2026-09-06-agent-request-freeze-provenance.zh.md

@@ -40,9 +40,21 @@ Apple M4 Pro、macOS arm64、Node 24.19.0；worktree 使用独立依赖和构建
 
 相同请求实现的另一次托管运行，[运行 34033336246、任务 101487216170](https://github.com/deepseek-harness/deepseek-harness/actions/runs/34033336246/job/101487216170)，记录了 145.644577, 144.204300, 143.072572, 145.985903, 146.834474 ms；中位数 145.644577 ms。它在合并提交 `c366e49` 上使用相同的 Ubuntu 镜像和 Node 版本，但运行于 Azure westus3 的另一台工作机。较快的运行不能替代 eastus 证据，也不能证明工作机差异的原因。较早的自托管 `VM-7-113-ubuntu-ci-9` 运行使用 Node 24.18.1（[运行 34021903421、任务 101456015028](https://github.com/deepseek-harness/deepseek-harness/actions/runs/34021903421/job/101456015028)），记录了 110.025154, 119.958978, 108.266860, 107.557950, 108.538902 ms；中位数 108.538902 ms。其运行器和 Node 版本不能校准标准托管通道。
 
-请求历史的 CI 期望值为 190 ms，向上取整并高于该观测范围。实际执行的中位数预算为 `ceil(190 × 1.25) = 238 ms`；CI 测量不再应用共享的参考机器 2× 系数。这与 [Session 重开 63 ms 预算](../../../../benchmarks/session-open/session-open.bench.ts)的直接 CI 校准方法一致，而非将 M4 参考值重新标注为托管证据。238 ms 预算仍低于独占原版实现的 M4 中位数 246.130875 ms。
+当前请求历史中位数上限为 297 ms。这是在最初 238 ms 上限基础上增加不超过 25% 的最大整数：`floor(238 × 1.25) = 297`，增加 24.79%。该余量仅属于 `agent-continuation/request-history`；共享时间系数、波动余量、其他时间上限、内存上限、采样次数与工作负载均保持不变。
 
-确定性对照调用与计时场景相同的 `assertRequestHistoryBudget` 断言。它们接受已记录的托管中位数和最大值（185.042397 ms），拒绝已记录的原版 M4 中位数，并拒绝由 248, 250, 252, 251, 249 ms 输入得到的合成 250 ms 中位数。合成输入模拟显著回归，并非运行时测量。回放已记录数值验证的是断言，而非新的托管运行。接受对照在校准前以 175 ms 预算失败；三个对照和五个请求冻结行为测试在 238 ms 预算下均通过。
+下面两次 release 测量都来自标准 GitHub Actions `ubuntu-24.04` 运行器组，记录相同镜像 `20260831.293.1` 与 Node 24.20.0。工作机不同（`1000050430` 与 `1000050689`），但日志没有证明其硬件及资源条件。两个 head 的请求历史运行时代码和工作负载一致：800 个历史轮次、每个历史轮次四个工具、40 个实时请求、最终 13,925 个事件。较早的参考运行提供另一次较慢观测。
+
+| 托管测量 | 请求历史原始总耗时（ms） | 中位数（ms） |
+|---|---|---:|
+| [Release `f778396b2e`](https://github.com/deepseek-harness/deepseek-harness/actions/runs/34233932940/job/102086694864) | 152.649609, 154.616595, 144.588531, 144.261013, 154.017377 | 152.649609 |
+| [Release `a0a61a8237`](https://github.com/deepseek-harness/deepseek-harness/actions/runs/34235890227/job/102095345914) | 246.876615, 246.881047, 272.370218, 265.796833, 272.507507 | 265.796833 |
+| [参考 `35fcb95275`](https://github.com/deepseek-harness/deepseek-harness/actions/runs/34232504298/job/102084171717) | 279.689489, 297.792849, 263.178391, 252.660292, 251.267361 | 263.178391 |
+
+前两次任务的工具续跑（483.877/698.657 ms）、catalog（612.127/1009.367 ms）和 profile 续跑（2438.362/3854.950 ms）也存在差异。这些观测证明托管执行时间存在广泛波动，不能据此断言硬件故障或运行时回归。在上述四个续跑场景中，较慢的 release 运行仅请求历史超过其上限。
+
+对 `a0a61a8237` 在 Apple M4 Pro / Node 24.19.0 上做的有界性能分析保留五次新进程总耗时：70.198916, 67.432250, 65.151208, 66.473292, 71.049667 ms；中位数 67.432250 ms。每个样本均完成相同的 40 个请求和 13,925 个事件。采样将适配器分派的包含后代耗时记为 38.082 ms，其中必需的文件内容遍历占 10.878 ms；system 节点扫描占 4.127 ms，一次性的恢复事件倒序则在计时轮次之外占 0.291 ms。删除后者不能解释观测到的轮次耗时。缓存投影内容或 system 节点会引入超出本次有界余量调整的不可变性或失效管理义务。运行时代码保持不变。
+
+确定性对照调用计时场景使用的 `assertRequestHistoryBudget`。它们接受已记录的 185.042397 ms 最大值和两次较慢托管中位数，同时拒绝由 308, 310, 312, 311, 309 ms 输入得到的合成 310 ms 中位数。较慢运行器接受对照在增加余量前复现 `265.796833 > 238`；完整所属文件在 297 ms 下通过 11 个测试。回放已记录数值验证的是断言，而非新的托管运行。历史合成 250 ms 场景与原版 M4 的 246.130875 ms 测量符合该余量，不再作为拒绝对照；原版／优化版 M4 测量仍保留为冻结实现收益的证据。
 
 ## 考虑过的替代方案
 

.agents/notes/implemented/simplification/2026-09-07-file-content-scan.i18n.yaml

@@ -2,5 +2,5 @@
 # side as of the last confirmed-consistent state. Both languages carry equal authority;
 # after editing either side, bring the other along and re-record with:
 #   pnpm run verify-translation-pairing --write .agents/notes/implemented/simplification/2026-09-07-file-content-scan.md
-2026-09-07-file-content-scan.md: 146f41a26b54e2823b7dfbdab5b6738c7a5041da
-2026-09-07-file-content-scan.zh.md: 07b4a9ecbca5d63eacccb43a9e3a40d0afe2a4cf
+2026-09-07-file-content-scan.md: 5c52a6346fb934a4c10be305dfc6393f87b43f6a
+2026-09-07-file-content-scan.zh.md: 87463ba340f68820e49fd2194d0295a53b93eb3c

.agents/notes/implemented/simplification/2026-09-07-file-content-scan.md

@@ -10,7 +10,7 @@ Every model dispatch checks complete message content for files, including nested
 
 ## Decision
 
-[`contentHasFile`](../../../../packages/llm/llm/src/content.ts) uses direct iteration instead of recursive `Array.some` callbacks. It preserves early exit, nested tool-result traversal, and false results for other block kinds. It stores no identities, validation results, or freeze proofs. Image detection, file projection, request construction, and the 238 ms request-history budget are unchanged.
+[`contentHasFile`](../../../../packages/llm/llm/src/content.ts) uses direct iteration instead of recursive `Array.some` callbacks. It preserves early exit, nested tool-result traversal, and false results for other block kinds. It stores no identities, validation results, or freeze proofs. Image detection, file projection, and request construction keep their existing behavior. The [request-freeze calibration](2026-09-06-agent-request-freeze-provenance.md) owns the request-history budget.
 
 ## Measurement evidence
 

.agents/notes/implemented/simplification/2026-09-07-file-content-scan.zh.md

@@ -10,7 +10,7 @@ Status: implemented
 
 ## Decision
 
-[`contentHasFile`](../../../../packages/llm/llm/src/content.ts) 使用直接迭代，替代递归的 `Array.some` 回调。它保留提前退出、嵌套工具结果遍历，以及其他块类型返回 false 的行为。它不存储身份、校验结果或冻结证明。图片检测、文件投影、请求构建和 238 ms 请求历史预算保持不变。
+[`contentHasFile`](../../../../packages/llm/llm/src/content.ts) 使用直接迭代，替代递归的 `Array.some` 回调。它保留提前退出、嵌套工具结果遍历，以及其他块类型返回 false 的行为。它不存储身份、校验结果或冻结证明。图片检测、文件投影和请求构建保持既有行为。[请求冻结校准](2026-09-06-agent-request-freeze-provenance.zh.md)拥有请求历史预算。
 
 ## Measurement evidence
 

benchmarks/agent-continuation/agent-continuation.bench.ts

@@ -24,9 +24,8 @@ const TOOL_CONTINUATION_BUDGET_MS = Math.ceil(EXPECTED_TOOL_CONTINUATION_CI_MS *
 /** Standard two-CPU hosted CI catalog median is 858.364 ms; 900 ms is the rounded expectation. */
 const EXPECTED_CATALOG_CI_MS = 900
 const CATALOG_BUDGET_MS = Math.ceil(EXPECTED_CATALOG_CI_MS * PERFORMANCE_BUDGET_HEADROOM)
-/** Two-CPU ubuntu-24.04 / Node 24.20 samples span 182.161–185.042 ms; rounded CI expectation. */
-const EXPECTED_REQUEST_HISTORY_CI_MS = 190
-const REQUEST_HISTORY_BUDGET_MS = Math.ceil(EXPECTED_REQUEST_HISTORY_CI_MS * PERFORMANCE_BUDGET_HEADROOM)
+/** Standard two-CPU hosted median limit; observed runner variation is pinned below. */
+const REQUEST_HISTORY_BUDGET_MS = 297
 const EXPECTED_RETAINED_HEAP_MB = 23
 const WORKERS = join(import.meta.dirname, '..', '.dsh-build', 'agent-continuation')
 
@@ -112,18 +111,24 @@ describe('standard hosted request-history calibration', () => {
     expect(recordedMedian).toBeGreaterThan(ciTimeBudget(70))
     assertRequestHistoryBudget(recordedMedian)
     assertRequestHistoryBudget(Math.max(...recorded))
-    expect(REQUEST_HISTORY_BUDGET_MS).toBe(238)
+    expect(REQUEST_HISTORY_BUDGET_MS).toBe(297)
   })
 
   it('rejects a synthetic material request-history regression', () => {
-    const regressionMedian = median([248, 250, 252, 251, 249])
+    const regressionMedian = median([308, 310, 312, 311, 309])
     expect(() => assertRequestHistoryBudget(regressionMedian)).toThrow()
   })
 
-  it('rejects the recorded original implementation on the M4 reference', () => {
-    const originalMedian = median([249.050708, 238.275291, 242.172084, 250.093166, 246.130875])
-    expect(originalMedian).toBe(246.130875)
-    expect(() => assertRequestHistoryBudget(originalMedian)).toThrow()
+  it('accepts the observed slower hosted runners', () => {
+    const recordedMedians = [
+      [246.87661500000002, 246.88104699999997, 272.3702179999999, 265.796833, 272.50750700000003],
+      [279.6894890000001, 297.79284899999993, 263.17839100000003, 252.66029200000003, 251.26736099999994],
+    ].map(median)
+    expect(recordedMedians).toEqual([265.796833, 263.17839100000003])
+    for (const recordedMedian of recordedMedians) {
+      expect(() => expectTotalWithinBudget(recordedMedian, 238)).toThrow()
+      assertRequestHistoryBudget(recordedMedian)
+    }
   })
 })