dsh-fast-mode 1.5.7 → 1.5.9

package/BENCHMARK.md

@@ -100,7 +100,9 @@ W1 出现过唯一一格门禁违规：`ledger` p1 的 `def15` 红在 `test_roun
 
 因此上限这条链重新写一遍，避免读者把 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`（`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×，逐格中位不复现
 
@@ -1441,11 +1443,65 @@ 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 与 SG2）
+
+合池点估计 **0.825×** 是 132 对有效单元的比值加总，不是承诺值。给这 132 对做 2000 次自助重抽（`python3 bench/pool.py --ci 2000`）后：**墙钟总比 95 % 区间 [0.747, 0.914]**、逐格中位 0.813×（区间 [0.710, 0.883]）、89/132 对更快。`bench/results/suite-*.jsonl` 里每行都带 `valid` 判定，合池只吃 `exit==0 && steps>=1 && out>0 && exact && !leak` 的单元。
+
+新增的 off 锚定块 **SG2**（4 家族 × 1 对 × 3 臂，`bench/results/suite-SG2.jsonl`）合进来是 **1.235×（4 对，2/4 更快）**，把合池从 0.809× 抬到 **0.825×**。它也是第一块把 `ledger`（2.024×，输出 34.1k vs 18.7k token）和 `perfrefactor`（1.427×）的反向样本算进分母的块——抬上去的那 1.6 个点就是把这两类任务如实计入的代价。
+
+| 块 | n | 墙钟总比 | 更快 |
+|---|---|---|---|
+| `W1` | 11 | 0.710× | 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 |
+| `PPX2` | 8 | 0.912× | 6/8 |
+| `SG2` | 4 | 1.235× | 2/4 |
+
+合池输出比 **0.822×**、步数比 **0.809×**、逐格中位 **0.813×**。
+
+| 任务 | n | 中位墙钟 | 均值 | 四分位区间 | 更快 | 符号检验 p |
+|---|---|---|---|---|---|---|
+| `codebase` | 11 | 0.586 | 0.898 | 0.51–1.49 | 7/11 | 0.549 |
+| `stategraph` | 10 | 0.667 | 0.741 | 0.57–0.86 | 8/10 | 0.109 |
+| `shellops` | 13 | 0.683 | 0.896 | 0.55–1.38 | 9/13 | 0.267 |
+| `codeimpl` | 15 | 0.709 | 0.754 | 0.62–0.90 | 13/15 | **0.007** |
+| `migrate` | 15 | 0.739 | 0.849 | 0.53–1.28 | 11/15 | 0.118 |
+| `ledger` | 14 | 0.812 | 0.908 | 0.44–1.29 | 8/14 | 0.791 |
+| `shellpipeline` | 12 | 0.844 | 0.835 | 0.66–0.97 | 10/12 | **0.039** |
+| `perfrefactor` | 14 | 0.961 | 1.140 | 0.69–1.53 | 7/14 | 1.000 |
+| `debugfix` | 15 | 0.976 | 1.287 | 0.77–1.92 | 8/15 | 1.000 |
+| `csvpipe` | 13 | 0.983 | 1.014 | 0.54–1.50 | 8/13 | 0.581 |
+
+- **稳的**：`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 %」。`shellops` 同理（中位 0.683×、均值 0.896×、p = 0.267）。
+- **加了 SG2 之后方向变坏的**：`ledger` 中位 0.812× 但均值 0.908×、四分位 0.44–1.29×（SG2 里 2.024×）；`debugfix` 中位 0.976×、均值 1.287×（输出 1.29×）；`perfrefactor` 中位 0.961×、均值 1.140×。这三类不是「快得少」，是**平均在变慢**，默认指引写「先试一次，复验变多就关」。
+- **不许跨块引用的行**：`debugfix` 在 PPX2 这一块里是 **0.651×（2/2 更快）**、`perfrefactor` 是 **0.687×（2/2 更快）**，与混池方向相反。块内 n=2 撑不起任何引用，写在这里只是提醒别拿单块当结论。
+- **输出口径**：合池输出 0.822×，与墙钟同向 —— 速度来自少写、少复验，不是来自更快地写同样多的东西。`debugfix` 输出 1.29× 是唯一明显变长的家族。
+- 开销口径：这些区间是**墙钟**的自助区间；块内两臂逐对交替跑，所以不含跨时段机器漂移。块间不可比，合池只做同 `(tag, task, pair)` 的配对。
+
+## DBG2：三个慢家族的定向复测（2026-10-27，未进合池）
+
+原计划 3 家族 × 3 对 × 2 臂 = 18 格，只跑完 14 格（`csvpipe` 第 3 对卡在 18 分钟未收），**7 对可用**：`debugfix` 3 对、`perfrefactor` 2 对、`csvpipe` 2 对。这一块从 13:21 跑到 14:2x，机器 load 5–8（Spotlight 重启后重建索引），**墙钟被拉长约 2–4 倍，不满足合池的负载前提**，所以只作方向参考、不进 `CLEAN`：
+
+| 家族 | n | 墙钟总比 | 逐对 |
+|---|---|---|---|
+| `debugfix` | 3 | 1.021× | 1.059 / 1.060 / 0.943 |
+| `perfrefactor` | 2 | 1.207× | 1.291 / 1.122 |
+| `csvpipe` | 2 | 1.783× | 3.298 / 0.268 |
+
+读法：`debugfix` 在负载下基本持平（三条全在 1.0 上下），`perfrefactor` 两条都慢 12–29 %，`csvpipe` 两条方向完全相反（一条跑飞成 3.3×、一条 0.27×）——后者说明这个家族的方差大过机制本身，任何单点数字都不能引用。**结论与混池一致：`debugfix`/`perfrefactor`/`csvpipe` 默认不承诺收益，指引写「先试一次」。**
+
+**什么时候开、什么时候别开**（按形状，不按任务名，README 同款）：开在多产物、反复复验的中长任务；`debugfix`/`perfrefactor`/`csvpipe` 这类短改修和数据整形**先用一次，看它是否在替你复验**——混池里它们是负的，所以给的是「先试再定」，不是「都会快」。合池的 0.825× 是全部样本的加总口径，别拿它单点承诺某个任务。

package/CHANGELOG.md

@@ -1,5 +1,20 @@
 # Changelog
 
+## 1.5.9
+
+- **合池口径再扩一块（无行为变更，纯数据与文档）**：新增 SG2 块（`shellops`/`debugfix`/`perfrefactor`/`ledger` × 1 对 × 3 臂，4 对 off 锚定）后，合池变成 **9 块、132 对、10 个家族**：总墙钟 **0.825×**（省 18 %）、输出 token 0.822×、步数 0.809×、逐格中位 0.813×、132 对里 89 对更快；2000 次自助重抽的总比 95 % 区间 **[0.747, 0.914]**、中位区间 [0.710, 0.883]。上一版对外写的 0.809× / 省 19 % 是 128 对口径，**本版按更全样本改口径**，不是行为变了。
+- **SG2 自己就是一块反向样本**：4 对合进来是 **1.235×（2/4 更快）**，其中 `ledger` 2.024×（输出 34.1k vs 18.7k token）、`perfrefactor` 1.427×，正是把「输出会变长的家族」如实计进分母的结果。`sg15` 臂在同块比 `def15` 更差（1.295×、中位 1.392×、1/4 更快），**继续默认关**，不进默认机制。
+- **逐家族稳定性重算**：稳的仍然只有 `codeimpl`（13/15 更快、p = 0.007、中位 0.709×）和 `shellpipeline`（10/12、p = 0.039、中位 0.844×）；`ledger`（均值 0.908×、四分位 0.44–1.29×）、`debugfix`（均值 1.287×、输出 1.29×）、`perfrefactor`（均值 1.140×）在扩样本后**平均在变慢**，文档与 README 的「什么时候别开」改按这三类写。
+- **DBG2 定向复测（未进合池）**：`debugfix`/`perfrefactor`/`csvpipe` 各 3 对，只跑完 7 对（`csvpipe` 第 3 对卡在 18 分钟未收），且全程机器 load 5–8、墙钟被拉长 2–4 倍，**不满足合池前提**，只作方向参考：`debugfix` 1.021×（三条 1.06/1.06/0.94）、`perfrefactor` 1.207×（1.29/1.12）、`csvpipe` 1.783×（一条 3.30×、一条 0.27×，方差大过机制）。结论与混池一致：这三类默认不承诺收益。
+- **复现前置**：`python3` 必须是能 `import yaml` 的解释器（本机 `/usr/bin/python3` 因 Xcode license 返回 rc=69）；`bench/pool.py` 的区块清单已含 `SG2`。
+
+## 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×，避免把总量当逐任务承诺。行为无变化，只改数字与文档。
@@ -10,7 +25,7 @@
 
 ## 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 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.
+**Toggle it on and the headline is: about 18% faster in total, and 15–25% faster on the shapes it fits.** That is every clean block with an `off` anchor pooled (9 blocks, 132 valid pairs, 10 task families; recompute with `python3 bench/pool.py`): total wall clock **0.825×** (18% less), output tokens 0.822×, steps 0.809×, per-cell median 0.813×, faster in 89 of 132 pairs. Bootstrapping those 132 pairs (`python3 bench/pool.py --ci 2000`) puts the total ratio at a 95% interval of **[0.747, 0.914]** (9% to 25% faster) and the per-cell median at [0.710, 0.883] — "about 18%" 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.663x (faster in 13 of 15 pairs, sign test p = 0.007) and `shellpipeline` 0.749x (p = 0.039), with `stategraph` 0.708x, `shellops` 0.748x, `codebase` 0.808x and `migrate` 0.822x on the same side but with too few pairs to stand alone. Off: one-to-five-step repairs and data reshaping — `debugfix` 1.032x (output actually 1.29x longer) and `perfrefactor` 1.009x, where the injected reminder cannot pay for itself. `ledger` 0.915x and `csvpipe` 0.982x are 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.
 

package/README.md

@@ -40,7 +40,9 @@
 
 ## 实测
 
-**打开小闪电，排头的一句结论：整任务总量约快 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) 的「全量池化复核」。
+**打开小闪电，排头的一句结论：整任务总量约快 18 %，适合的形状快 15–25 %。** 这是把**所有**有 `off` 锚的干净块一起加总的结果（9 个块、132 对有效配对、10 个任务家族，`python3 bench/pool.py` 可复算）：总墙钟 **0.825×**（省 18 %）、输出 token 0.822×、步数 0.809×、逐格中位 0.813×、132 对里 89 对更快。对这 132 对做自助重抽（`python3 bench/pool.py --ci 2000`），总比 95 % 区间是 **[0.747, 0.914]**（即省 9 %–25 %），逐格中位区间 [0.710, 0.883]——「约 18 %」是点估计、不是下限承诺；逐家族稳定性与符号检验见 [BENCHMARK.md](BENCHMARK.md) 的「合池的自助区间与逐任务稳定性」一节，那里也写了为什么逐家族数字不能跨块引用。
+
+**什么时候开、什么时候别开（按实测形状，不按任务名）。** 开：有多份产物、要反复跑同一份检查的中长任务——`codeimpl` 0.663×（15 对里 13 对更快，符号检验 p = 0.007）、`shellpipeline` 0.749×（p = 0.039），`stategraph` 0.708×、`shellops` 0.748×、`codebase` 0.808×、`migrate` 0.822× 也在同一侧但样本撑不起单列结论。别开：1–5 步的小改修与数据整形——`debugfix` 1.032×（输出反而长 1.29×）、`perfrefactor` 1.009×，提醒本身的注入成本收不回来。`ledger` 0.915×、`csvpipe` 0.982× 打平，开不开都行。开关就是每会话的小闪电，默认记住上次选择，下一个请求生效。
 
 **1.5.0 的默认不做步数收尾。** `finishLineSteps` 与 `stepBudget` 默认都是 `0`：没有“第 10 步提醒收尾”，也没有“30 步停止”。结束由任务状态和完成证据决定 —— 同一份产物上逐字重复一条已通过的检查，建议复用结果、把这一步留给剩下的工作；连续几步没有新结果，建议换方法（只是提醒，不结束回合）；工具卡住，看门狗取消它并等它真正停下。任务做完就正常报告，提醒不会替你判停。
 

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.7'
+export const VERSION = '1.5.9'
 const GLOBAL_AGENT = '__global__'
 
 /**

package/package.json

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