dsh-fast-mode 1.5.6 → 1.5.7

package/BENCHMARK.md

@@ -55,6 +55,53 @@
 
 W1 出现过唯一一格门禁违规：`ledger` p1 的 `def15` 红在 `test_round_half_up`。逐条重跑该格的隐藏测试后确认：测试用 `offset: "0.005"`（三位小数）要求 `Decimal` 精确参与四舍五入，而 `PROMPT.txt` 只写了「四舍五入到分」并让 `parse_amount` 对非法输入抛 `ValueError`——「把规则里的 `0.005` 先按分解析」也是一种合理读法，两个实现都能自证。参考实现 22 条断言全绿，说明是**题面欠明确**，不是快速模式降质。已把题面补成「`multiplier`/`offset` 是任意位小数的金额字符串，按 Decimal 原样解析，只有最终结果取两位小数」，fixture 摘要从 `2699cd64…` 变为 `2d7546f8…`；W3 的 ledger 三格用的是旧题面（两臂看到的是同一份，且都没红），W4 起全部用新题面。
 
+## 全量池化复核（2026-10-27）：7 个干净块合池 120 对，总量 **0.80×**，「26–28 %」撤回
+
+之前对外说的是「1.5.1 那一块 0.72×、W5 0.73×、W7 0.73×，三块合并 65 个有效单元 0.74×」。那三块是**挑出来的**：它们都恰好是默认臂表现好的块。样本扩大以后，把**所有**有 `off` 锚的干净块一起加总——不再挑块、不再排除任何任务——数字变差，所以 26–28 % 撤回，改成约 **20 %**。
+
+口径与判据：
+
+- 有效格（bench 判据，不是 `green`）：`exit == 0 && steps >= 1 && out > 0 && exact && !leak`。`green` 只说明隐藏断言过了，崩溃到没产出的会话也可能 green，所以不能当计量单位。
+- 配对：同一 `(tag, task, pair)` 内 `off` 与该臂都有效才算一对；比值一律「该臂 / 同块 `off`」，跨块不混算。
+- 排除：`V15`/`TA3`/`TA4` 三块已因 fixture 泄漏 + byte-window 指标混用撤回，且缺 `exact` 字段，严格口径下 0 条有效。
+- 复算：`python3 bench/pool.py`（只读 `bench/results/*.jsonl`，不跑 bench、不写文件）。
+
+| 块 | 对数 | 墙钟总量 | 更快 |
+|---|---:|---:|---|
+| W1 | 11 | 0.711× | 7/11 |
+| W3 | 29 | 0.721× | 23/29 |
+| W5 | 20 | 0.793× | 11/20 |
+| W6 | 19 | 0.931× | 11/19 |
+| W7 | 17 | 0.734× | 13/17 |
+| W8b | 19 | 0.819× | 13/19 |
+| REL16 | 5 | 0.967× | 3/5 |
+| **合池** | **120** | **0.798×** | **81/120** |
+
+合池另外两个量：输出 token 总量 **0.806×**、步数总量 **0.800×**、逐格墙钟中位 **0.829×**。也就是整任务总墙钟省 **20 %**，逐格中位省 17 %：**总量口径对外说 20 %，不再说 26–28 %**。
+
+按任务拆开，收益集中在有多份产物/多轮复验的中长任务，短任务打平或更慢——这不是噪声，方向和单格结论一致：
+
+| task | 对数 | 墙钟总量 | 更快 | 读法 |
+|---|---:|---:|---|---|
+| codeimpl | 13 | **0.608×** | 12/13 | 省 39 %，全表最稳（13 对里 12 对更快） |
+| stategraph | 10 | 0.708× | 8/10 | 省 29 % |
+| migrate | 13 | 0.748× | 10/13 | 省 25 % |
+| shellpipeline | 12 | 0.749× | 10/12 | 省 25 % |
+| shellops | 12 | 0.803× | 8/12 | 省 20 % |
+| codebase | 11 | 0.808× | 7/11 | 省 19 %，但块间 0.40–1.80，方差大 |
+| ledger | 13 | 0.811× | 8/13 | 省 19 % |
+| csvpipe | 13 | 0.982× | 8/13 | 打平，收益在噪声内 |
+| perfrefactor | 11 | 1.077× | 5/11 | **更慢 8 %** |
+| debugfix | 12 | 1.245× | 5/12 | **更慢 25 %**（6 块里 5 块中位 >1） |
+
+两个更慢的任务都是 1–5 步、输出 5k token 以内的小改修：没有可省的重复复验，提醒本身按「注入一次 ≈0.66–0.92 s」计价，小任务上这笔钱收不回来。它们不进「适合场景」的说法，默认不做按任务名的特殊处理（判据是请求形状，不是任务名），文档里点名是为了不让读者在短任务上期待收益。
+
+成本模型（`W8b` 的 `off` 臂，n=19）同步重算，结论没变：`wall = a + b·out + c·steps`，OLS `a=-8.8 s`、`b=13.48 s/1k tok`、`c=1.621 s/step`、R²=0.922；NNLS（`a=0`）`b=13.59`、`c=0.739`、R²=0.921。**输出项占墙钟 ~97–98 %，步数项 ~3 %**。跨 task 外推会高估 1.5–2.1×（各 task 自己的每 1k token 价格是 6.75–9.60 s，W8b 是 13.89 s），所以只能读结构比例，不能拿系数给别的任务定价。
+
+因此上限这条链重新写一遍，避免读者把 40 % 当待办：要省 40 % 墙钟就得省约 40 % 输出 token（输出占 97 %）；现在合池实测输出 0.806×，已经兑现了「省输出 → 省墙钟」的大部分可用余量；剩下能动的（重复复验 6 %、重复写文件 0.8 %）即使全压掉也只值 2–6 %。**0.67× 在「不动 `reasoningEffort`、不加请求字段」的约束内不可达**，这一条没有变，见下一节「0.67× 在现有约束下的可达性」。
+
+另有两处副产品值得记：`pp16`（`preferPatch`）在 `W8b` 上账面最好（19 对总量 0.70×、中位 0.66×、13/19 更快），但只跑过一块，样本面太窄；`open15` 在 `codebase`/`csvpipe`/`debugfix` 上明显强于 `def15`（中位 0.46/0.47/0.48）却在 `shellops`/`shellpipeline` 上更慢，说明「按形状分流」比「全局换臂」更合理。两者都还没到能进默认的证据量。
+
 ## 复现块 W5（2026-10-26）：三臂同块对照，总量复现 0.73×，逐格中位不复现
 
 这一块是为了两件事：① 用另一批样本复算 1.5.1 的 `def15` 总量；② 在同一块内直接对照 `bv15`（`batchVerify: true`），因为 W4 只有单臂对基线，无法排除那一轮基线本身偏慢。

package/CHANGELOG.md

@@ -1,5 +1,13 @@
 # Changelog
 
+## 1.5.7
+
+- **对外口径修正（撤回 26–28%）**：把**所有**有 `off` 锚的干净块合池重算——7 个块、120 对有效配对、10 个任务家族：总墙钟 **0.798×**（省 20%）、输出 token 0.806×、步数 0.800×、逐格中位 0.829×、81/120 对更快。之前公开的 26–28% 来自三个被挑出来的块（1.5.1 0.72×、W5 0.73×、W7 0.73×，65 个有效单元合池 0.74×），样本扩大后不再成立，**撤回**；对外只说约 20%，并同时给逐格中位 0.83×，避免把总量当逐任务承诺。行为无变化，只改数字与文档。
+- **分场景读法写进文档**：`codeimpl` 0.608×（省 39%，13 对 12 对更快）、`stategraph` 0.708×、`migrate` 0.748×、`shellpipeline` 0.749×、`shellops` 0.803×、`codebase` 0.808×、`ledger` 0.811×、`csvpipe` 0.982×（打平）、`perfrefactor` 1.077×、`debugfix` 1.245×（更慢）。后两者是 1–5 步、5k token 以内的小改修，没有可省的重复复验，一次通知的注入成本（≈0.66–0.92 s）收不回来；默认仍按请求形状调度，不按任务名做特殊处理。
+- **成本模型复算进仓库**：`wall = a + b·out + c·steps`，OLS（W8b 的 `off` 臂，n=19）`a=-8.8 s`、`b=13.48 s/1k`、`c=1.621 s/step`、R²=0.922；NNLS（`a=0`）`b=13.59`、`c=0.739`、R²=0.921 ⇒ **输出项占墙钟 ~97–98%**，步数项 ~3%。跨 task 外推会高估 1.5–2.1×，只能读结构比例。
+- **新增 `bench/pool.py`**：一条命令复算上面这些合池数字（只读 `bench/results/*.jsonl`，不跑 bench、不写文件），并把「有效格」判据固定成 `exit == 0 && steps >= 1 && out > 0 && exact && !leak`（`green` 不算计量单位）。
+- **上限结论不变**：省 40% 墙钟需要省约 40% 输出（输出占 97%），现有约束内 0.67× 不可达，见 `BENCHMARK.md`。
+
 ## 1.5.6
 
 - **发版前复核块 REL16**：默认对 `off` 再跑 5 家族 × 1 对（10 个单元），两臂 **10/10 全绿、逐任务通过数完全相同**、无 leak；墙钟合计 **0.967×**、逐格中位 0.999×、3/5 格更快。单对 n=5 只作复核，不替换 26–28% 的总口径；原始数据 `bench/results/suite-REL16.jsonl`，分析与读法见 `BENCHMARK.md`、`README.md`。

package/README.en.md

@@ -40,7 +40,7 @@ No model switch, no `reasoningEffort` rewrite, no request-field injection (`serv
 
 ## Measured
 
-**Toggle it on and the headline is: about 26–28% faster in total (0.72×, 0.73× and 0.73× across three independent blocks; a fourth block landed at 0.93× and is an outlier).** Ten task families, around 30 units per block; the 1.5.1 block ran 60 sessions with hidden tests **29/29 green among valid units** (one more unit was voided by a session-startup crash, not a red): total wall clock **0.72×** (off 3434.7 s → on 2472.5 s), output tokens 0.74×, steps 0.71×; per-cell wall median **0.64×**, faster in 24 of 30 cells, 90% interval [0.59, 0.79]. That is the speed available without giving up completion or re-verification; going further means skipping checks, which this version does not do. Single tasks vary widely (`migrate` 0.45×, `shellops` 0.57× on one side, `perfrefactor` 1.18× and `csvpipe` 1.12× on the other): the slow cells come from the model writing more reasoning tokens in that session, not from a scheduler behaviour, so "28%" is the total and is not a per-task promise. **The "about 36% on a typical cell" claim is retracted**: in a 19-unit replication block (10 families × 2 pairs × 3 arms) the per-cell median was 0.84× and the mean crossed 1 — the gain sits in a few long cells while short cells are often a wash or slower. The median stays as a distribution record for the 1.5.1 batch only; the public number is the total.
+**Toggle it on and the headline is: about 20% faster in total, and 25–39% faster on the shapes it fits.** That is every clean block with an `off` anchor pooled (7 blocks, 120 valid pairs, 10 task families; recompute with `python3 bench/pool.py`): total wall clock **0.798×** (20% less), output tokens 0.806×, steps 0.800×, per-cell median 0.829×, faster in 81 of 120 pairs. Per task the gain concentrates in medium/long tasks with several deliverables and repeated re-verification: `codeimpl` **0.608×** (39% less, 12 of 13 pairs faster), `stategraph` 0.708×, `migrate` 0.748×, `shellpipeline` 0.749×; `csvpipe` is a wash at 0.982×; `perfrefactor` 1.077× and `debugfix` 1.245× are **slower** — both are 1–5 step repairs under 5k output tokens, where there is no repeated verification to save and a single injected notice (~0.7 s) never pays for itself. **The "about 26–28% faster in total" claim is retracted**: it came from three selected blocks (1.5.1 at 0.72×, W5 at 0.73×, W7 at 0.73×, 65 valid units pooled to 0.74×); with the wider sample the pooled figure is 0.798×, so the public number is 20%, not 26–28%. **The "about 36% on a typical cell" claim stays retracted** as well (per-cell median 0.83×; the gain sits in a few long cells). The 1.5.1 block is still true in itself: 60 sessions, hidden tests **29/29 green among valid units** (one more unit voided by a session-startup crash, not a red), single-block wall clock 0.72× (3434.7 s → 2472.5 s), per-cell median 0.64× — it is the record of *one* block, not a promise for the pool. That is the speed available without giving up completion or re-verification; going further means skipping checks, which this version does not do. Per-block and per-task tables, plus the ceiling derivation, are in [BENCHMARK.md](BENCHMARK.md) under the pooled re-check section.
 
 **1.5.0 ships no step-based finish line by default.** `finishLineSteps` and `stepBudget` both default to `0`: there is no "remind me at step 10" and no "stop at step 30". When to finish is decided by task state and completion evidence — repeating an already-passing check verbatim against the same artifact suggests reusing the result and spending the step on what is left; several steps with no new result suggests changing the method (a reminder only, it never ends the turn); a stuck tool is cancelled by the watchdog and awaited until it really stops. A finished task is reported normally; a reminder never votes to stop for you.
 
@@ -50,7 +50,7 @@ No model switch, no `reasoningEffort` rewrite, no request-field injection (`serv
 
 **Screen W10 + replication W11 (2026-10-26, 23 valid units combined): `workspaceMap` only half delivered, stays off by default.** 1.5.2 adds one knob, off by default: before the first action the harness hands the model a one-shot inventory of the working tree (depth 2, ≤60 entries, dependency and build directories skipped) so it does not have to spend a step listing files itself. Both blocks compare it with `def15` inside the same block: across 23 valid units **wall 0.927×, output 0.896×, steps 1.099×**, per-cell median 0.791×, 13/23 faster, zero gate reds. Half of the mechanism is confirmed: output really is 10 % lower (0.90× and 0.89× in the two blocks). But steps rise 10 % and the tail gets worse — p90 559 s versus 369 s and max 714 s versus 510 s, with the same reverse cells in both blocks (`stategraph` at 1.4×–1.77× in each). **Because a long task must not get slower, it is not promoted**: the 1.5.2 default behaves exactly like 1.5.1, and the knob ships with its numbers. The same round accounted for the remaining headroom: repeated verification is only 6 % of wall, tool results have a 1.2 kB median, rewriting an already written file is 0.8 % — so **0.67× is not reachable inside the "do not touch `reasoningEffort`, add no request fields" constraints**. See "复现块 W11" and "0.67× 在现有约束下的可达性" in [BENCHMARK.md](BENCHMARK.md).
 
-**Pre-release re-check (REL16, 10 units)**: the then-current default was run against `off` once more, purely to ask whether shipping had damaged quality. Both arms came back **10/10 green with identical per-task pass counts** (14/14, 22/22, 18/18, 10/10, 14/14) and no leaks; wall summed to **0.967×**, per-cell median 0.999×, faster in 3/5 cells. That is one pair at n=5, a wider noise band than the pooled total, so it is reported as a re-check and does not replace the 26–28 % headline — see [BENCHMARK.md](BENCHMARK.md).
+**Pre-release re-check (REL16, 10 units)**: the then-current default was run against `off` once more, purely to ask whether shipping had damaged quality. Both arms came back **10/10 green with identical per-task pass counts** (14/14, 22/22, 18/18, 10/10, 14/14) and no leaks; wall summed to **0.967×**, per-cell median 0.999×, faster in 3/5 cells. That is one pair at n=5, a wider noise band than the pooled total, so it is reported as a re-check and does not replace the pooled 0.798× figure — see [BENCHMARK.md](BENCHMARK.md).
 
 **Faster configurations that failed the gate stay ablation arms only.** `fl10` (a step-10 finish reminder) is the fastest configuration measured, but it suppresses re-verification after the tests pass and once went red on a cell where both the baseline and the default were green, so it stays an ablation arm (those numbers came from a retracted batch and are kept only as a decision record). `openBatch` (one opening reminder to put independent calls in one block) beat the default 0.77× vs 0.93× in the W6 screen, but an independent W7 rerun brought it back to 0.91× and 1.136× head-to-head — **not replicated, so dropped**. `batchVerify` was 0.84× against the default inside W5 and is likewise not promoted. **The defaults therefore stay as they are**: no step-based finish line, `stepBudget: 0`, and all three mechanisms off. Per-cell data and gate results are in the `H2`/`H3` sections of BENCHMARK.
 

package/README.md

@@ -40,7 +40,7 @@
 
 ## 实测
 
-**打开小闪电，排头的一句结论：整任务总量约快 26–28%（三块独立批次 0.72×、0.73×、0.73×；第四块 0.93× 是离群）。** 10 个任务家族、每块 30 个单元左右；1.5.1 那一块 60 次运行、隐藏测试**有效单元 29/29 全绿**（另 1 个单元因会话启动崩溃作废，不是红灯）：整任务总墙钟 **0.72×**（关掉 3434.7 s → 打开 2472.5 s），输出 token 0.74×，步数 0.71×；逐格墙钟中位 **0.64×**、30 格里 24 格更快、90 % 区间 [0.59, 0.79]。这是「不牺牲完成度和复验」换来的速度，再往下压就要开始省检查，本版不做。单任务快慢波动很大（`migrate` 0.45×、`shellops` 0.57×，反过来 `perfrefactor` 1.18×、`csvpipe` 1.12×）：那几格变慢是模型在同一会话里多写了推理 token，不是调度器行为，所以「28 %」是总量口径，别当成每个任务的承诺。**「典型一格约快 36%」已撤回**：另一个 19 单元的复现块（10 家族 × 2 对 × 3 臂）里逐格中位是 0.84×、均值跨过 1，收益集中在少数长格，短格常常打平或更慢；中位只作 1.5.1 那一批的分布记录，对外只用总量。
+**打开小闪电，排头的一句结论：整任务总量约快 20 %，适合的场景快 25–39 %。** 这是把**所有**有 `off` 锚的干净块一起加总的结果（7 个块、120 对有效配对、10 个任务家族，`python3 bench/pool.py` 可复算）：总墙钟 **0.798×**（省 20 %）、输出 token 0.806×、步数 0.800×、逐格中位 0.829×、120 对里 81 对更快。分任务看，收益集中在有多份产物、需要多轮复验的中长任务：`codeimpl` **0.608×**（省 39 %，13 对 12 对更快）、`stategraph` 0.708×、`migrate` 0.748×、`shellpipeline` 0.749×；`csvpipe` 0.982× 打平；`perfrefactor` 1.077×、`debugfix` 1.245× **更慢**——这两个都是 1–5 步、5k token 以内的小改修，没有可省的重复复验，提醒本身按「注入一次 ≈0.7 s」计价就收不回来。**「整任务约快 26–28 %」已撤回**：那个数字来自三个被挑出来的块（1.5.1 0.72×、W5 0.73×、W7 0.73×，合并 65 个有效单元 0.74×），样本扩大后合池回到 0.798×，所以对外只说 20 %，不再说 26–28 %。**「典型一格约快 36 %」也已撤回**（逐格中位 0.83×，收益集中在少数长格）。1.5.1 那一块自身仍是真实的：60 次运行、隐藏测试**有效单元 29/29 全绿**（另 1 个单元因会话启动崩溃作废，不是红灯）、单块总墙钟 0.72×（3434.7 s → 2472.5 s）、逐格中位 0.64×——它只是**一块**的记录，不是全池承诺。这是「不牺牲完成度和复验」换来的速度，再往下压就要开始省检查，本版不做。逐块、逐任务表与上限推导见 [BENCHMARK.md](BENCHMARK.md) 的「全量池化复核」。
 
 **1.5.0 的默认不做步数收尾。** `finishLineSteps` 与 `stepBudget` 默认都是 `0`：没有“第 10 步提醒收尾”，也没有“30 步停止”。结束由任务状态和完成证据决定 —— 同一份产物上逐字重复一条已通过的检查，建议复用结果、把这一步留给剩下的工作；连续几步没有新结果，建议换方法（只是提醒，不结束回合）；工具卡住，看门狗取消它并等它真正停下。任务做完就正常报告，提醒不会替你判停。
 
@@ -50,7 +50,7 @@
 
 **复现块 W7（2026-10-26，17 个有效单元）**：默认臂 **0.73×** 墙钟 / 0.75× 输出 / 0.59× 步数（最长一格 36 步 → 17 步），与 1.5.1 的 0.72×、W5 的 0.73× 一致：三块合并 65 个有效单元 **0.74×**。同块的 `openBatch` 是 0.91×，对默认头对头 1.136×，W6 的 0.77× 没有复现，**淘汰**。这一块还有 7 行运行崩溃（会话启动阶段 `exit=1`、1 步、0 输出），3 个单元因此作废并点名；从这一块起判据要求 `exit == 0 && 步数 ≥ 1 && 输出 > 0 && 判分完成 && 未泄漏` 才计数，所以「全绿」一律指有效单元全绿（1.5.1 29/29、W5 19/19、W7 17/17）。详见 [BENCHMARK.md](BENCHMARK.md) 的「复现块 W7」。
 
-**发版前复核（REL16，10 个单元）**：用当时的默认再对 `off` 跑一块，只查「质量有没有被发版弄坏」。结果两臂 **10/10 全绿、逐任务通过数完全相同**（14/14、22/22、18/18、10/10、14/14），无 leak；墙钟合计 **0.967×**、逐格中位 0.999×、3/5 格更快。单对 n=5，噪声带比总量宽，所以这条只作复核，不替换 26–28% 的总口径，详见 [BENCHMARK.md](BENCHMARK.md)。
+**发版前复核（REL16，10 个单元）**：用当时的默认再对 `off` 跑一块，只查「质量有没有被发版弄坏」。结果两臂 **10/10 全绿、逐任务通过数完全相同**（14/14、22/22、18/18、10/10、14/14），无 leak；墙钟合计 **0.967×**、逐格中位 0.999×、3/5 格更快。单对 n=5，噪声带比总量宽，所以这条只作复核，不替换合池 0.798× 的总口径，详见 [BENCHMARK.md](BENCHMARK.md)。
 
 **更快但没过门禁的配置只作消融臂。** `fl10`（第 10 步提醒收尾）是实测最快的配置，但它会压掉「测试通过后又改了代码」的必要复验，且出现过基线与默认都绿而它红的一格，所以只是消融臂（这些数字出自已撤回的批次，只保留决策记录）。`openBatch`（开局发一次「把独立调用并进同一块」）在 W6 筛查里以 0.77× 快过默认的 0.93×，但 W7 独立复测回到 0.91×、头对头 1.136×，**没有复现即淘汰**。`batchVerify`（改完一批文件再跑一次覆盖检查）在 W5 同块对照里记到 0.84×，但那一臂的提醒实际零下发，测到的不是机制本身，所以它算**未测**，默认保持关闭。**所以默认不变**：不按步数收尾、`stepBudget: 0`、上述机制全关。单元级数据与门禁逐条见 BENCHMARK 的 `H2`/`H3`。
 

package/index.js

@@ -95,7 +95,7 @@ const TAG = '[fast-mode]'
  * Shipped identity of this build. Traced into the debug log so a stale install is
  * visible at a glance, and pinned by a test against `package.json`.
  */
-export const VERSION = '1.5.6'
+export const VERSION = '1.5.7'
 const GLOBAL_AGENT = '__global__'
 
 /**

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "dsh-fast-mode",
-  "version": "1.5.6",
+  "version": "1.5.7",
   "description": "DeepSeek Harness fast mode: same thinking effort, fewer round trips. An adaptive parallel tool fan-out, output discipline that never trims the answer, and a cancellable stall guard. Never changes reasoning effort, the model, or the request body. Provider-agnostic, one dependency (@deepseek-ai/schemastery).",
   "repository": {
     "type": "git",