dsh-fast-mode 1.5.7 → 1.5.8

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,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,5 +1,12 @@
 # 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×，避免把总量当逐任务承诺。行为无变化，只改数字与文档。
@@ -10,7 +17,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 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.
 

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) 的「全量池化复核」。
+**打开小闪电，排头的一句结论：整任务总量约快 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 步停止”。结束由任务状态和完成证据决定 —— 同一份产物上逐字重复一条已通过的检查，建议复用结果、把这一步留给剩下的工作；连续几步没有新结果，建议换方法（只是提醒，不结束回合）；工具卡住，看门狗取消它并等它真正停下。任务做完就正常报告，提醒不会替你判停。
 

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.8'
 const GLOBAL_AGENT = '__global__'
 
 /**

package/package.json

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