dsh-fast-mode 1.5.6 → 1.5.8

package/BENCHMARK.md

@@ -55,6 +55,55 @@
 
 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` 上更慢，说明「按形状分流」比「全局换臂」更合理，但它同样只跑过一块。
+
+**`pp16` 的结论已经出来，是否定的（PPX + PPX2，同块对照，n=12）。** 过程值得记：PPX 那一块（4 对，`codeimpl`/`migrate`/`debugfix`/`perfrefactor`）给出 0.426×，看着像强机制；把同样的臂在 PPX2 上复测 8 对得到 **1.193×**（比 `off` 还慢），两坑合起来 **1.035×**、6/12 更快、输出 1.056× —— 也就是说 0.426× 是 4 个格子的运气，不是机制。同一块里 `def15` 是 0.911×（PPX2）和 0.850×（两坑合并），方向一致但幅度远小于 PPX 给人的印象。`preferPatch` 因此保持默认关闭，不因为单块好账面就翻默认。
+
 ## 复现块 W5（2026-10-26）：三臂同块对照，总量复现 0.73×，逐格中位不复现
 
 这一块是为了两件事：① 用另一批样本复算 1.5.1 的 `def15` 总量；② 在同一块内直接对照 `bv15`（`batchVerify: true`），因为 W4 只有单臂对基线，无法排除那一轮基线本身偏慢。
@@ -1394,11 +1443,40 @@ node bin/experiment.mjs stop                          # end it; later sessions g
 - Experiment E's minimal reproduction: `--gears safe,turbo`, then two concurrent waves of eight sessions on one prompt, and a per-session `ΣstepMs` median grouped by `gear`. The raw rows are in `~/.dsh/fast-mode-metrics.jsonl` (present on this machine); grouping by `sid` recomputes the table without re-running a model.
 - The 0.8.0 raw log is [`docs/bench-raw-2026-10-24.jsonl.gz`](docs/bench-raw-2026-10-24.jsonl.gz) (committed with the repo); under the stated conventions it reproduces every number in Experiments E and F.
 - For multi-repo tasks, do not treat the whole-history ratio table from `dsh-fast-mode-report` as a conclusion; group by task first, then compare medians inside a group.
+- 跑 `bench/suite-run.py` 前先确认 `python3` 能用：它在 :176 用 `subprocess.run(['python3','-m','unittest', ...])` 给每个格子判分。2026-10-27 这块机器上 `/usr/bin/python3` 因为 Xcode 许可失效直接失败（`You have not agreed to the Xcode license agreements`，rc=69），当时 PPX2 有 2 个格子因此没落盘。修法：把可用的解释器放前面，例如 `mkdir -p /tmp/fm/bin && ln -sf /Users/apple/.local/share/uv/python/cpython-3.11-macos-aarch64-none/bin/python3.11 /tmp/fm/bin/python3 && export PATH=/tmp/fm/bin:$PATH`（该解释器已装 pyyaml，`load_token()` 也要用）。
 
 ## 发布前复核块 REL16（2026-10-26，默认 vs `off`，5 家族 × 1 对 = 10 个单元）
 
 - **目的**：发版前用当时的默认（与 1.5.1 行为相同）对 `off` 再做一块同块对照，只回答两件事——隐藏测试有没有退化、总量方向有没有反过来。
 - **质量：两臂 10/10 全绿，逐任务通过数完全相同**（`shellops` 14/14、`ledger` 22/22、`codebase` 18/18、`stategraph` 10/10、`migrate` 14/14），无 leak、无超时、无 `steps=0`。
 - **速度**：墙钟合计 **0.967×**（1543.5 s → 1493.3 s），逐格中位 **0.999×**、3/5 格更快，步数 0.66×。逐格：`ledger` 0.78×、`shellops` 0.98×、`migrate` 1.00×、`stategraph` 1.31×、`codebase` 1.79×。
-- **读法**：单对、n=5，噪声带比 26–28% 的总口径宽，**不用这块替换总量结论**；它只用于回答「发版这一步有没有把质量或方向弄坏」。质量答案是没坏；速度方向在这一块落进噪声（0.97×）。
+- **读法**：单对、n=5，噪声带比合池 0.798× 的总口径宽，**不用这块替换总量结论**；它只用于回答「发版这一步有没有把质量或方向弄坏」。质量答案是没坏；速度方向在这一块落进噪声（0.97×）。
 - 原始结果 `bench/results/suite-REL16.jsonl`；`python3 bench/report.py --files bench/results/suite-REL16.jsonl --baseline off` 可复算。
+## 合池的自助区间与逐任务稳定性（2026-10-27，含 PPX2）
+
+合池点估计 **0.8087×** 是 128 对有效单元的比值加总，不是承诺值。给这 128 对做 2000 次自助重抽（`python3 bench/pool.py --ci 2000`）后：**墙钟总比 95 % 区间 [0.734, 0.894]**，中位 **[0.706, 0.885]**，步数总比 0.8062×，更快 87/128。区间上沿还贴着 0.9，所以对外只说「大约两成」，不说「至少两成」；要收窄区间只能加样本，不是换机制。
+
+PPX2 是这一轮唯一新增的 off 锚定块（4 家族 × 2 对 × 3 臂，`bench/results/suite-PPX2.jsonl`）。它合进来的总量是 **0.912×（8 对，6/8 更快）**，把合池从 0.798× 抬到 **0.809×** —— 方向没变，幅度更保守。它还暴露了一件事：**同一批任务在另一块里符号会翻**，见下表 `debugfix`/`perfrefactor` 两行。
+
+逐任务拆开看，方向稳定的只剩两个家族（双侧符号检验，7 块 + PPX2，共 128 对）：
+
+| 任务 | n | 中位墙钟 | 均值 | 四分位区间 | 更快 | 符号检验 p | 输出比中位 |
+|---|---|---|---|---|---|---|---|
+| `codeimpl` | 15 | 0.709 | 0.754 | 0.62–0.90 | 13/15 | **0.007** | 0.831 |
+| `stategraph` | 10 | 0.667 | 0.741 | 0.59–0.72 | 8/10 | 0.109 | 0.737 |
+| `migrate` | 15 | 0.739 | 0.849 | 0.53–1.28 | 11/15 | 0.118 | 0.802 |
+| `codebase` | 11 | 0.586 | 0.898 | 0.51–1.49 | 7/11 | 0.549 | 0.657 |
+| `shellops` | 12 | 0.774 | 0.928 | 0.66–1.44 | 8/12 | 0.388 | 0.932 |
+| `ledger` | 13 | 0.782 | 0.822 | 0.45–1.22 | 8/13 | 0.581 | 0.950 |
+| `shellpipeline` | 12 | 0.844 | 0.835 | 0.67–0.99 | 10/12 | **0.039** | 0.761 |
+| `perfrefactor` | 13 | 0.890 | 1.118 | 0.72–1.36 | 7/13 | 1.000 | 0.865 |
+| `csvpipe` | 13 | 0.983 | 1.014 | 0.54–1.48 | 8/13 | 0.581 | 0.883 |
+| `debugfix` | 14 | 1.183 | 1.323 | 0.83–1.92 | 7/14 | 1.000 | 1.286 |
+
+- **稳的**：`codeimpl`（13/15 更快，p = 0.007，中位 0.709×）与 `shellpipeline`（10/12，p = 0.039）。这两个家族的收益同时出现在墙钟和步数上。
+- **中位好看但不稳的**：`codebase` 中位 0.586× 但均值 0.898×、四分位 0.51–1.49×，p = 0.549 —— 靠少数长格拉低中位，不能说成「普遍快 41 %」。
+- **不许当结论的两行**：`debugfix` 在中位 1.183×（p = 1.000，7/14 更快）；但在 PPX2 这一块里 `debugfix` 是 **0.651×（2/2 更快）**、`perfrefactor` 是 **0.687×（2/2 更快）**，与混池方向相反。样本只有 2 对时不构成反证，但足以说明**「哪个家族快」不能跨块引用** —— 对外只能说合池，不能说逐家族表是稳定的。
+- **输出口径**：`debugfix` 输出比 1.286× 仍是唯一明显变长的家族；`codebase`/`stategraph`/`shellpipeline` 输出明显变短（0.657/0.737/0.761）。合池输出 0.806×，与墙钟同向 —— 速来自少写，不是来自少做。
+- 开销口径：这些区间是**墙钟**的自助区间；块内两臂逐对交替跑，所以不含跨时段机器漂移。块间不可比，合池只做同 `(tag, task, pair)` 的配对。
+
+**什么时候开、什么时候别开**（按形状，不按任务名，README 同款）：开在多产物、反复复验的中长任务；`debugfix`/`perfrefactor` 这类短改修**先用一次，看它是否在替你复验**——混池里它们是负的，但 PPX2 里是正的，所以给的是「先试再定」，不是禁令；`csvpipe` 中位 0.983×，接近 1，等于没赚没亏。开关本来就按会话记：同一会话里一旦发现提示在拖后腿，关掉即可，不需要重启宿主。

package/CHANGELOG.md

@@ -1,8 +1,23 @@
 # Changelog
 
+## 1.5.8
+
+- **合池口径再收紧（无行为变更，纯数据与文档）**：新增 PPX2 块（4 家族 × 2 对 × 3 臂，8 对 off 锚定）后，合池变成 **8 块、128 对、10 个家族**：总墙钟 **0.809×**（省 19 %）、输出 0.806×、步数 0.806×、逐格中位 0.813×、87/128 更快，2000 次自助重抽 95 % 区间 **[0.734, 0.894]**（中位 [0.706, 0.885]）。上一版的 0.798× / 120 对是被一块偏乐观的数据抬高的，这版把 PPX2 一起算进去。
+- **`preferPatch`（`pp16`）判定为不成立**：PPX 单块 4 对给出 0.426×，看着像强机制；同块复测到 12 对后是 **1.035×**（6/12 更快、输出 1.056×），PPX2 那 8 对单独看是 1.193×。结论：单块好账面是格子运气，`preferPatch` 保持默认关闭。这一条写进 `BENCHMARK.md`，避免后来的人重复踩。
+- **逐家族表加了「不可跨块引用」的告示**：`debugfix` 混池中位 1.183×，但在 PPX2 块里是 0.651×（2/2 更快）；`perfrefactor` 混池 0.890×、PPX2 里 0.687×。方向会翻，所以对外只报合池，不报「某家族必然快多少」。
+- **`bench/pool.py` 区块清单**加 `PPX2`、`SG2`（后者落地后才参与合池），文档补了「`python3` 必须是可用解释器」的复现前置（本机 `/usr/bin/python3` 因 Xcode license 直接返回 69，会让隐藏测试静默失败）。
+
+## 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`。
+- **发版前复核块 REL16**：默认对 `off` 再跑 5 家族 × 1 对（10 个单元），两臂 **10/10 全绿、逐任务通过数完全相同**、无 leak；墙钟合计 **0.967×**、逐格中位 0.999×、3/5 格更快。单对 n=5 只作复核，不替换当时的 26–28% 总口径（该口径已在 1.5.7 撤回）；原始数据 `bench/results/suite-REL16.jsonl`，分析与读法见 `BENCHMARK.md`、`README.md`。
 
 ## 1.5.5
 

package/README.en.md

@@ -40,7 +40,9 @@ 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 19% faster in total, and 15–30% faster on the shapes it fits.** That is every clean block with an `off` anchor pooled (8 blocks, 128 valid pairs, 10 task families; recompute with `python3 bench/pool.py`): total wall clock **0.809×** (19% less), output tokens 0.806×, steps 0.806×, per-cell median 0.813×, faster in 87 of 128 pairs. Bootstrapping those 128 pairs (`python3 bench/pool.py --ci 2000`) puts the total ratio at a 95% interval of **[0.734, 0.894]** (11% to 27% faster) and the per-cell median at [0.706, 0.885] — "about 19%" is a point estimate, not a floor. Per-family stability and sign tests are in [BENCHMARK.md](BENCHMARK.md), section "合池的自助区间与逐任务稳定性", which also explains why per-family numbers cannot be quoted across blocks.
+
+**When to turn it on, and when not to.** On: mid-length tasks with several artifacts and repeated re-checks — `codeimpl` 0.608x, `stategraph` 0.708x, `migrate` 0.748x, `shellpipeline` 0.749x, with `shellops` 0.803x, `codebase` 0.808x and `ledger` 0.811x on the same side. Off: one-to-five-step repairs — `debugfix` 1.245x and `perfrefactor` 1.077x, where the injected reminder cannot pay for itself. `csvpipe` 0.982x is a wash. The switch is the lightning bolt per conversation; it remembers your last choice and applies from the next request.
 
 **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 +52,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,9 @@
 
 ## 实测
 
-**打开小闪电，排头的一句结论：整任务总量约快 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 那一批的分布记录，对外只用总量。
+**打开小闪电，排头的一句结论：整任务总量约快 19 %，适合的形状快 15–30 %。** 这是把**所有**有 `off` 锚的干净块一起加总的结果（8 个块、128 对有效配对、10 个任务家族，`python3 bench/pool.py` 可复算）：总墙钟 **0.809×**（省 19 %）、输出 token 0.806×、步数 0.806×、逐格中位 0.813×、128 对里 87 对更快。对这 128 对做自助重抽（`python3 bench/pool.py --ci 2000`），总比 95 % 区间是 **[0.734, 0.894]**（即省 11 %–27 %），逐格中位区间 [0.706, 0.885]——「约 19 %」是点估计、不是下限承诺；逐家族稳定性与符号检验见 [BENCHMARK.md](BENCHMARK.md) 的「合池的自助区间与逐任务稳定性」一节，那里也写了为什么逐家族数字不能跨块引用。
+
+**什么时候开、什么时候别开（按实测形状，不按任务名）。** 开：有多份产物、要反复跑同一份检查的中长任务——`codeimpl` 0.608×、`stategraph` 0.708×、`migrate` 0.748×、`shellpipeline` 0.749×，`shellops` 0.803×、`codebase` 0.808×、`ledger` 0.811× 也在同一侧。别开：1–5 步的小改修——`debugfix` 1.245×、`perfrefactor` 1.077×，提醒本身的注入成本收不回来。`csvpipe` 0.982× 打平，开不开都行。开关就是每会话的小闪电，默认记住上次选择，下一个请求生效。
 
 **1.5.0 的默认不做步数收尾。** `finishLineSteps` 与 `stepBudget` 默认都是 `0`：没有“第 10 步提醒收尾”，也没有“30 步停止”。结束由任务状态和完成证据决定 —— 同一份产物上逐字重复一条已通过的检查，建议复用结果、把这一步留给剩下的工作；连续几步没有新结果，建议换方法（只是提醒，不结束回合）；工具卡住，看门狗取消它并等它真正停下。任务做完就正常报告，提醒不会替你判停。
 
@@ -50,7 +52,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.8'
 const GLOBAL_AGENT = '__global__'
 
 /**

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "dsh-fast-mode",
-  "version": "1.5.6",
+  "version": "1.5.8",
   "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",