dsh-fast-mode 1.5.18 → 1.5.20

package/BENCHMARK.md

@@ -63,9 +63,10 @@ W1 出现过唯一一格门禁违规：`ledger` p1 的 `def15` 红在 `test_roun
 
 口径与判据：
 
-- 有效格（bench 判据，不是 `green`）：`exit == 0 && steps >= 1 && out > 0 && exact && !leak`。`green` 只说明隐藏断言过了，崩溃到没产出的会话也可能 green，所以不能当计量单位。
+- 有效格（bench 判据，不是 `green`）：`exit == 0 && steps >= 1 && out > 0 && hasSessionIds && !leak`。`green` 只说明隐藏断言过了，崩溃到没产出的会话也可能 green，所以不能当计量单位。
 - 配对：同一 `(tag, task, pair)` 内 `off` 与该臂都有效才算一对；比值一律「该臂 / 同块 `off`」，跨块不混算。
-- 排除：`V15`/`TA3`/`TA4` 三块已因 fixture 泄漏 + byte-window 指标混用撤回，且缺 `exact` 字段，严格口径下 0 条有效。
+- 排除：`V15`/`TA3`/`TA4` 三块已因 fixture 泄漏 + byte-window 指标混用撤回，且缺 `hasSessionIds` 字段，严格口径下 0 条有效。
+- 字段更名：`bench/suite-run.py` 现在写 `hasSessionIds`（该行的 steps/out 是否归属本会话自己的 session id）。历史 result 行里同一个布尔叫 `exact`，所有读取点走 `row.get('hasSessionIds', row.get('exact'))`，旧文件不需要转换；`exact` 从来不是「产物精确性」。
 - 复算：`python3 bench/pool.py`（只读 `bench/results/*.jsonl`，不跑 bench、不写文件）。
 
 | 块 | 对数 | 墙钟总量 | 更快 |
@@ -1458,7 +1459,7 @@ node bin/experiment.mjs stop                          # end it; later sessions g
 - 原始结果 `bench/results/suite-REL16.jsonl`；`python3 bench/report.py --files bench/results/suite-REL16.jsonl --baseline off` 可复算。
 ## 合池的自助区间与逐任务稳定性（2026-10-28，12 块 138 对）
 
-合池点估计 **0.8234×** 是 138 对有效单元的比值加总，不是承诺值。给这 138 对做 4000 次自助重抽（`python3 bench/pool.py --ci 4000`）：**墙钟总比 95 % 区间 [0.7418, 0.9133]**、逐格中位 0.7994×（区间 [0.7026, 0.8850]）、几何均值 0.8248×（区间 [0.7532, 0.9001]）、93/138 对更快（符号检验 p = 0.0001）；同池输出比 **0.8179×**、步数比 **0.8062×**。`bench/results/suite-*.jsonl` 里每行都带 validity 判定，合池只吃 `exit==0 && steps>=1 && out>0 && exact && !leak` 的单元（`bench/pool.py` 的 `valid()`）。
+合池点估计 **0.8234×** 是 138 对有效单元的比值加总，不是承诺值。给这 138 对做 4000 次自助重抽（`python3 bench/pool.py --ci 4000`）：**墙钟总比 95 % 区间 [0.7418, 0.9133]**、逐格中位 0.7994×（区间 [0.7026, 0.8850]）、几何均值 0.8248×（区间 [0.7532, 0.9001]）、93/138 对更快（符号检验 p = 0.0001）；同池输出比 **0.8179×**、步数比 **0.8062×**。`bench/results/suite-*.jsonl` 里每行都带 validity 判定，合池只吃 `exit==0 && steps>=1 && out>0 && hasSessionIds && !leak` 的单元（历史行里 `hasSessionIds` 写作 `exact`，读取时回退）（`bench/pool.py` 的 `valid()`）。
 
 12 个块全部有 `off` 锚、全部在现行 validity 规则下测出：`W1`、`W3`、`W5`、`W6`、`W7`、`W8b`、`REL16`、`PPX2`、`SG2`、`NX1_IMPL`、`NX1_PIPE`、`NX1_SG`。**块间不可比**：每块只做自己块内 `(tag, task, pair)` 的 `def15 / off` 配对，跨块加总走「先算每对的比值、再对 138 个比值取中位/几何/加总比」。`V15`、`TA3`、`TA4` 三个块按名字剔除（fixtures 泄漏，`llm` 列是字节窗口的产物）。
 
@@ -1512,6 +1513,17 @@ node bin/experiment.mjs stop                          # end it; later sessions g
 
 口径限制：这些数字来自**还留在磁盘上的 run 目录抽样**，不是 138 对全池的成分统计；结论只用来说方向（正文 ≪ 参数、单调用步占多数），不要当成全池精确占比引用。
 
+### 复核：1.2 % 的正文占比现在有命令了（2026-10-28）
+
+上面那 40 个会话的数字（6,267 / 518,773 = 1.19 %）没有留下抽样命令，无法复现。用 `bench/textshare.py` 重算，口径固定、可重跑：
+
+- 计数单位：会话 transcript 里每条 `assistant/message`。分子 = `text` part 的 `len(text)` 之和；分母 = 分子 + `tool-call` part 的 `len(arguments)` 之和。不含 reasoning、不含工具返回、不含用户消息。
+- 抽样规则：`~/.dsh/sessions` 下 run 目录名匹配 `suite-<tag>-<task>-p<pair>-<arm>` 的会话，按目录名排序取前 40 个；`--limit 0` 取全量。同样的库必得同样的数。
+- `python3 bench/textshare.py`：n=38 会话 / 368 条消息 / 408 次调用，正文 6,555 字符、工具参数 456,476 字符 ⇒ **1.42 %**（逐会话中位 1.43 %、p10 0.07 %、p90 2.80 %）。
+- `python3 bench/textshare.py --limit 0`：全量 `def15`，n=341 / 3,327 条消息 / 3,569 次调用，正文 51,366、参数 4,315,096 ⇒ **1.18 %**（中位 0.98 %、p90 4.08 %）。
+
+全量 1.18 % 与文首的 1.2 % 一致，结论（正文 ≪ 工具参数）在两套样本上都成立。后续引用建议用 `--limit 0` 的 1.18 % 并写明 n；两套样本都不含 reasoning 与工具返回，不是「输出 token 的全部」。
+
 ## `batchVerify` 复测块 BV8（2026-10-28）：codeimpl 1.478× 变慢、shellpipeline 0.956× 无差，合并 1.188× —— **淘汰**
 
 `batchVerify` 是最后一个「修好 liveness 缺陷后再测一次」的默认关闭机制。W4 曾筛出 0.76×，但 W8b 的逐会话检索证明那一臂**一条提醒都没下发**（20 个会话命中 0），所以 0.76× 不是它的效果；W5 同样零下发。修复投递后第一次真测就是这两块。
@@ -1599,7 +1611,7 @@ python3 bench/suite-run.py --tasks debugfix,ledger,codeimpl --arms off,def15,bud
 
 判据（全部满足才并入默认，否则记为负结果并保持默认关）：
 
-1. **质量门禁**：`BUD3` 块内 `bud8` 每个单元 `exit==0`、`exact`、无 `leak`；`off` 与 `def15` 在同块同样全绿（分母按有效单元算，不按格数算）。
+1. **质量门禁**：`BUD3` 块内 `bud8` 每个单元 `exit==0`、`hasSessionIds`、无 `leak`；`off` 与 `def15` 在同块同样全绿（分母按有效单元算，不按格数算）。
 2. **输出真的降了**：`bud8/def15` 的同块输出 token 总和比 ≤ 0.90；若 ≥ 0.97 判定「机制未生效」，不许用墙钟数字解释。
 3. **墙钟不倒退**：`bud8/def15` 同块墙钟总和比 ≤ 1.00，逐对中位数 ≤ 1.03；三个家族里至少两个家族单独 ≤ 1.00。
 4. **每家族 ≥ 2 个同块有效对**，否则该家族写「未判定」，不并入总体结论。
@@ -1656,7 +1668,7 @@ python3 bench/suite-run.py --tasks debugfix,ledger,codeimpl --arms off,def15,bud
 
 - 断言通过数：`off` **2038/2038（100.00 %）**，`def15` **2037/2038（99.951 %）**，差 **1 条断言**。
 - 逐对看：137/138 对两臂断言数完全相同；唯一不同的还是 `W1 / ledger / pair 1`（`def15` 21/22，`off` 22/22），即 `RX` 那格题面欠明确的历史样本，不是新出现的回归。
-- 产物精确性 `exact`：两臂都是 138/138。
+- 会话归属 `hasSessionIds`：两臂都是 138/138。（这不是「产物精确性」：该字段只说 steps/out 归属本会话；产物质量看断言计数与 `green`。）
 - 结论只能说到这里：**在这 10 个家族、138 个任务上，速度不是用正确率换来的**；1 条断言的分差在统计上无法与噪声区分（也无法证明「绝对无损」），所以对外表述用「断言对等，1/2038 差异」而不是「零质量损失」。
 
 ## 质量对等（历史口径）：132 对里断言 1959/1960 对 1960/1960
@@ -1665,7 +1677,7 @@ python3 bench/suite-run.py --tasks debugfix,ledger,codeimpl --arms off,def15,bud
 
 - 断言通过数：`off` **1960/1960（100.00 %）**，`def15` **1959/1960（99.95 %）**，差 **−0.05 个百分点 = 1 条断言**。
 - 逐对看：131/132 对两臂断言数完全相同；唯一不同的是 `W1 / ledger / pair 1`，`def15` 21/22、`off` 22/22。
-- 产物精确性 `exact`（入口文件 / 输出与期望逐字节一致）：两臂都是 132/132。
+- 会话归属 `hasSessionIds`（旧名 `hasSessionIds`）：两臂都是 132/132。（入口文件与期望的逐字节比较是另一件事，由断言计数 `passed/total` 与 `green` 覆盖。）
 - 结论只能说到这里：**在这 10 个家族、132 个任务上，速度不是用正确率换来的**；1 条断言的分差在统计上无法与噪声区分（也无法证明「绝对无损」），所以对外表述用「断言对等，1/1960 差异」而不是「零质量损失」。
 
 另外记一条运行可靠性的事实，避免以后误读：同批数据里有 **`off` 6 行、`def15` 3 行**是零输出的退化运行（`out=0`、`steps` 为 1、任务只做了一半），按有效单元规则已经全部排除，不参与任何比值。这类行的出现与宿主负载相关，不是某一个臂的固有缺陷；它们也解释了为什么 `suite-run.py` 必须按「有效行」而不是「有行」来判断进度（见 `bench/scrub.py`）。
@@ -1728,7 +1740,7 @@ python3 bench/suite-run.py --tasks debugfix,ledger,codeimpl --arms off,def15,bud
 三点读法：
 
 1. **点估计没动**（0.8247 → 0.8234，差 0.13 个百分点，远小于区间宽度 0.18），所以对外仍是「约 1.21× 快、约 17–18 % 省时」，区间照旧报 CI95，不报单点。新增的 6 对确实更偏快（中位从 0.813 掉到 0.799），但样本量只涨 4.5 %，不足以支撑新报价。
-2. **唯一的断言差异还是那一个**：`(W1, ledger, 1)` 的 `def15` 21/22 对 `off` 22/22；其余 137 对断言计数完全一致，`exact` 138/138。质量措辞仍是「断言对等」，不是「零质量损失」。
+2. **唯一的断言差异还是那一个**：`(W1, ledger, 1)` 的 `def15` 21/22 对 `off` 22/22；其余 137 对断言计数完全一致，`hasSessionIds` 138/138。质量措辞仍是「断言对等」，不是「零质量损失」。
 3. 三个估计量互相不一致的程度（0.799 / 0.823 / 0.825）正好说明为什么发布口径必须并列报，而不能挑最小的那个当中位卖点。
 
 ## 空转对照：开关根本没触发时，同一对能差多少（9 对，纯分析，不新增格子）
@@ -1865,7 +1877,7 @@ python3 bench/suite-run.py --tasks debugfix,ledger,codeimpl --arms off,def15,bud
 | `D2_MIG` | migrate | 6 | **0.751×** | 0.738× | 0.713× | 4/6 | 0.887× | 0.700× | 0.229–1.724 |
 | 合并 | 2 家族 | 13 | **0.625×** | 0.551× | 0.680× | 9/13 | 0.857× | 0.614× | 0.229–1.724 |
 
-墙钟合计 1963 s → 1335 s。26 行全 `exact`、全 `green`，逐格断言 `debugfix` 13/13、`migrate` 14/14 满，**没有一格质量下降**。
+墙钟合计 1963 s → 1335 s。26 行全 `hasSessionIds`、全 `green`，逐格断言 `debugfix` 13/13、`migrate` 14/14 满，**没有一格质量下降**。
 
 **机制：不是「正文写短了」。** 同一批 transcript 里，`debugfix` 每会话正文总量 `def15` 109 字符、`d2` 54 字符（本身就近乎为零），`migrate` 118 → 53 —— 正文差几十字节，无法解释墙钟 0.535×。真正的差别在**往返次数**：
 
@@ -1888,11 +1900,11 @@ python3 bench/suite-run.py --tasks debugfix,ledger,codeimpl --arms off,def15,bud
 
 **预注册：把默认从 4 改成 2 的通过判据（先写判据，`D2_IMPL` 数据还没出来）。** 只认 `codeimpl`（4–13 步，中等长度，是已证明受益的家族）8 对：
 
-1. **8 对全有效**（`exit == 0 and steps >= 1 and out > 0 and exact and not leak`），且每格 `green`。
+1. **8 对全有效**（`exit == 0 and steps >= 1 and out > 0 and hasSessionIds and not leak`），且每格 `green`。
 2. **几何 ≤ 0.95×、中位 ≤ 1.00×、赢面 ≥ 5/8**：三家族（debugfix 0.535×、migrate 0.751×、codeimpl）不得出现方向翻转。`codeimpl` 若 > 1.00×，说明收益只属于「回合短」的家族，默认**不动**（维持 4），这条线判定为家族相关。
 3. **三家族合并（21 对）几何 ≤ 0.85×、中位 ≤ 0.90×**。
 4. **下发必须命中**：`d2` 臂 ≥ 7/8 会话在第 2 步收到（`codeimpl` 有 0 个会话不到 2 步才行；目前 `codeimpl` 16 个 `def15` 会话步数最少 4，够）。
-5. 质量：任何一格 `exact`/`green` 倒退 ⇒ 不通过（速度不能以质量为代价）。
+5. 质量：任何一格 `hasSessionIds`/`green` 倒退 ⇒ 不通过（速度不能以质量为代价）。
 
 全部满足才改默认并发版；否则保持 4，并把「时点」这条线记为家族相关、不再扫。**不因为「几何好看」就改默认**：`odt15` 当年就是被单个家族的好看数字骗过一次。
 
@@ -1904,7 +1916,7 @@ python3 bench/suite-run.py --tasks debugfix,ledger,codeimpl --arms off,def15,bud
 
 **这条杠杆的「成本侧」是严格受控的（离线读 transcript）。** 提醒文本在 `def15` 与 `d2` 两臂是同一句、同样长度：三个块 42 个会话**每回合恰好注入 1 次**，每次 **318 字符**，两臂总字符数完全相同（`D2_DBG` 各 2226、`D2_IMPL` 各 2544、`D2_LED` 各 1908）；唯一差别是注入步：`d2` 一律第 2 步、`def15` 一律第 4 步（`at_steps` 逐条核对）。所以家族间那 0.5×/1.07× 的差别**全部来自时点**，不是「多给提示」换来的——这也是为什么它能保持质量零倒退。
 
-**第三族 `D2_LED` 也跑满了（6 对 12 行，发布前就登记在 d2 的块表里）：这一族是**大幅受益**。** 几何 **0.506×**、中位 0.551×、合计 0.436×、5/6 更快、符号 p = 0.2188，范围 0.157–1.232×；步数几何 0.699×、输出几何 0.540×。两臂 12 行**全绿且 22/22 全过**（`exact` + `green` + `valid` 全为真），所以提速不是靠少检查换来的：逐对步数 `15→11`、`13→6`、`16→25`、`6→8`、`63→13`、`10→8`——注意 p3 提前后**多**走了 9 步却仍快 0.616×，p5 把 63 步压到 13 步（1009 s → 158 s）。这样方向表就完整了：`ledger` 0.506×、`debugfix` 0.535×、`migrate` 0.751× 三族受益，`codeimpl` 1.073× 受害；受害的只有「短回合、单文件、第一步还在定位」这一类。
+**第三族 `D2_LED` 也跑满了（6 对 12 行，发布前就登记在 d2 的块表里）：这一族是**大幅受益**。** 几何 **0.506×**、中位 0.551×、合计 0.436×、5/6 更快、符号 p = 0.2188，范围 0.157–1.232×；步数几何 0.699×、输出几何 0.540×。两臂 12 行**全绿且 22/22 全过**（`hasSessionIds` + `green` + `valid` 全为真），所以提速不是靠少检查换来的：逐对步数 `15→11`、`13→6`、`16→25`、`6→8`、`63→13`、`10→8`——注意 p3 提前后**多**走了 9 步却仍快 0.616×，p5 把 63 步压到 13 步（1009 s → 158 s）。这样方向表就完整了：`ledger` 0.506×、`debugfix` 0.535×、`migrate` 0.751× 三族受益，`codeimpl` 1.073× 受害；受害的只有「短回合、单文件、第一步还在定位」这一类。
 
 原因不是「提醒这句没用」，而是**同一个时点在两族里方向相反**：`debugfix` 0.535×、`migrate` 0.751×，`codeimpl` 1.073×。逐格看更清楚——`codeimpl` p4 的 `d2` 走 17 步（`def15` 8 步）、p3 1.980×、p4 2.688×，而唯一赢的 p1 是 `def15` 自己走到 5 步的那格。把 p4 的调用序列摊开：`def15` 5 步 4 次调用（`write` → `python3 - <<PY` 校验 → `ls && py_compile` → `rm -rf`），`d2` 8 步 7 次（`pwd && ls` → `write` → python 校验 **×2** → `python3 --version && python` 再校验 → `ls && find` → `rm -rf`）：在本来就最短的直线上，第 2 步的提醒**加**了探索和重复校验。所以这条旋钮的准确描述是「**把会走远的回合作短，代价是给本来就短的回合加了开销**」——家族相关的时点杠杆，默认维持 4。
 
@@ -1944,11 +1956,11 @@ python3 bench/suite-run.py --tasks debugfix,ledger,codeimpl --arms off,def15,bud
 
 **判据（配对，treatment / baseline < 1 才是快）：**
 
-1. **至少 6 对有效配对**（`migrate`，同一块 `DR12_MIG`，两臂交错）。有效 = `exit == 0 and steps >= 1 and out > 0 and exact and not leak`。
+1. **至少 6 对有效配对**（`migrate`，同一块 `DR12_MIG`，两臂交错）。有效 = `exit == 0 and steps >= 1 and out > 0 and hasSessionIds and not leak`。
 2. **几何均值 ≤ 0.95×，且中位 ≤ 1.00×**。只报几何/中位/合计比，算术均值禁用（重尾）。
 3. **赢面至少 4/6**，否则即使几何更好也记为「不稳定」。
 4. **输出 token 的几何均值 ≤ 0.95×** 才允许说「赢在输出变短」；如果墙钟变好而输出没变短，那就是采样噪声，判空。
-5. **质量不得倒退**：`exact` 全对，`green` 不少于对侧臂；任何一格质量下降 ⇒ 直接不通过（速度不能以质量为代价）。
+5. **质量不得倒退**：`hasSessionIds` 全对，`green` 不少于对侧臂；任何一格质量下降 ⇒ 直接不通过（速度不能以质量为代价）。
 6. 不通过就维持默认 `0`，并在文档里写「第二次提醒无效/有害」，不再重试第三次。
 
 **已知上限。** 单块 n=6 的检出下限约 ±15 %（见「空转对照」一节：同臂对同臂 9 对的范围是 0.889–1.342×）。所以这里只认「几何 ≤ 0.95× 且赢面 4/6 以上」这种**远大于噪声**的结果；0.96–1.04× 一律判空。
@@ -1967,8 +1979,8 @@ python3 bench/suite-run.py --tasks debugfix,ledger,codeimpl --arms off,def15,bud
 
 **两处与预注册的偏差，记在这里不掩盖：**
 
-1. **判据 5 的「下发条件」原本没被脚本执行，现已补上并判 FAIL。** 预注册写的是「`D2G_IMPL` 8/8 仍在**第 4 步**收到，`D2G_DBG`/`D2G_MIG` 在第 2 步收到」。实际逐会话扫描：`def15` 8/8/6/7 全在第 4 步，`d2g` 在 `IMPL` 是**第 3 步**、在 `DBG`/`MIG` 是第 2 步。`d2gscore.py` 现在自己调 `d2gsign.py` 断言每个臂的命步（`5 delivery <block> <arm> step N`），输出里 `D2G_IMPL d2g step 4` 一行是 **FAIL**（实际 `[3]`）。`IMPL` 按设计应在 `disciplineEarlyCalls: 2` 下退化成第 4 步，实际提前到了第 3 步 —— 这解释了它为什么没像预期那样完全退化（0.889× 而不是 ≈1.00×），也说明判据 5 的「按条件命中」这一半同样没通过。原先 gate 5 只校验 `exact`/`green`，缺口已修（见上）；判据 5 因此是「质量过、下发步位不过」，结论仍是 HOLD。
-2. **`delivery audit` 探针不可用。** 报告按固定句式找完成通报，命中 0/16、2/14、0/12。这个探针在本套 fixture 上恒为 0，不能当「任务没交付」的证据；质量结论只引用 `exact`/`green`（21 对全部 1/1）与判据 5 的 0 坏格。
+1. **判据 5 的「下发条件」原本没被脚本执行，现已补上并判 FAIL。** 预注册写的是「`D2G_IMPL` 8/8 仍在**第 4 步**收到，`D2G_DBG`/`D2G_MIG` 在第 2 步收到」。实际逐会话扫描：`def15` 8/8/6/7 全在第 4 步，`d2g` 在 `IMPL` 是**第 3 步**、在 `DBG`/`MIG` 是第 2 步。`bench/d2gscore.py` 现在自己调 `bench/d2gsign.py` 断言每个臂的命步（这两个脚本原先只在 `~/.local/fm/`，1.5.19 起随 `bench/` 一起进仓，`python3 bench/d2gscore.py` 可复现本节全部数字）（`5 delivery <block> <arm> step N`），输出里 `D2G_IMPL d2g step 4` 一行是 **FAIL**（实际 `[3]`）。`IMPL` 按设计应在 `disciplineEarlyCalls: 2` 下退化成第 4 步，实际提前到了第 3 步 —— 这解释了它为什么没像预期那样完全退化（0.889× 而不是 ≈1.00×），也说明判据 5 的「按条件命中」这一半同样没通过。原先 gate 5 只校验 `hasSessionIds`/`green`，缺口已修（见上）；判据 5 因此是「质量过、下发步位不过」，结论仍是 HOLD。
+2. **`delivery audit` 探针不可用。** 报告按固定句式找完成通报，命中 0/16、2/14、0/12。这个探针在本套 fixture 上恒为 0，不能当「任务没交付」的证据；质量结论只引用 `hasSessionIds`/`green`（21 对全部 1/1）与判据 5 的 0 坏格。
 
 ### 预注册前提检查：提醒之后输出会不会「重新变长」
 
@@ -1989,7 +2001,7 @@ python3 bench/suite-run.py --tasks debugfix,ledger,codeimpl --arms off,def15,bud
 
 | 指标 | 数值 |
 |---|---|
-| 对数 | 7 / 7 有效，`exact`+`green` 21/21 格全过 |
+| 对数 | 7 / 7 有效，`hasSessionIds`+`green` 21/21 格全过 |
 | 几何均值 | **0.717×** |
 | 中位 | 0.864× |
 | 总计 | 0.633× |
@@ -1999,3 +2011,173 @@ python3 bench/suite-run.py --tasks debugfix,ledger,codeimpl --arms off,def15,bud
 | 提醒步位 | `def15` 7/7 在第 4 步，`d2` 7/7 在第 2 步 |
 
 怎么读：方向是复现的（输出变短、整体更快），但**幅度掉到 0.717×，中位只剩 0.864×，7 对里 5 对更快在统计上说明不了问题**；同时 `steps_geo` 1.118× 说明早提醒在这套 debugfix 上会让回合多走一两步——加速来自「每步写得更短」，不是「步数更少」，这和 `D2G_MIG` 的分解（`out` 0.478、`steps` 0.964）是同一套机制。合并原来的 `D2_DBG`（0.535×）与这块（0.717×），`d2` 在 debugfix 上的真实档位大约 **0.6–0.7×，且方差很大（单对 0.236–1.327×）**，所以任何「早提醒稳定快 2 倍」的说法都不成立。
+
+## 结果：`D2B_MIG`（`d2` 在 migrate 上的新会话复现，3 对可用）
+
+`D2` 在迁移类上的老证据只有 `D2_MIG` 的 6 对（几何约 0.75×）。同协议开一块新会话，6 对，ABBA 交错：
+
+| 指标 | 数值 |
+|---|---|
+| 可用对数 | **3 / 6**（`migrate p4`–`p6` 的 12 行全是 1 步、0 字符输出、墙钟约 2 s 的空转，探测请求打空，整对作废，不参与平均） |
+| 几何均值 | **0.326×** |
+| 中位 | 0.322× |
+| 更快 | 3 / 3 |
+| 步骤 | `steps_geo` **0.575×**（18→7、11→10、13→7） |
+| 输出 | `out_geo` **0.373×**（30470→9655、15107→12176、21858→4451） |
+
+逐对：`p1` 393.3→126.7 s、`p2` 197.4→165.4 s、`p3` 355.3→45.5 s。`p1` 的基线 393 s 本身是这台机器当时负载下的长尾（同一块里 `def15` 其余行 117–280 s），所以**不把 0.326× 当成档位**，只记两点：方向在 migrate 上第三次复现（`D2_MIG` 0.75×、`D2G_MIG` 0.495×、本块 0.326×），且省下来的同样是步数与输出（长迁移里反复回看目录的调用被砍掉）。样本 3 对，符号检验没有意义，不进任何合并口径。
+
+## 结果：`DR8_MIG`（`disciplineRepeatAtSteps: 8`，6 对）——重复提醒更慢，杠杆关闭
+
+预注册的动机是「第 4 步提醒之后输出会反弹，所以第 8 步再说一遍」。`migrate` 上 6 对完整跑完：
+
+| 指标 | 数值 |
+|---|---|
+| 对数 | 6 / 6 有效（12 格 `hasSessionIds`+`green` 全过；中途因 load ≥ 14 触发一次 ABORT，scrub 后补齐） |
+| 几何均值 | **1.394×**（更慢） |
+| 中位 | 1.451× |
+| 更快 | 2 / 6（符号检验 p = 0.688，不显著） |
+| 步骤 | `steps_geo` **1.091×** |
+| 输出 | `out_geo` **1.365×**（提醒没压住，反而更长） |
+
+逐对墙钟比：0.918 / 1.315 / 0.968 / 1.353 / 1.311 / 2.241。最差的一对 `p6`：`def15` 6 步 153 s / 13453 字符，`dr8` 15 步 343 s / 27414 字符——第 8 步那句提醒在这条长迁移上没有让模型收手，它把已完成的检查又做了一遍。
+
+结论：**`disciplineRepeatAtSteps` 维持默认 `0`，这条杠杆关闭。** 预注册前提里「反弹存在」那半句是对的（`D2G` 的逐步骤输出确实反弹），但「再提醒一次能把反弹压回去并换来墙钟」被本块否掉；提醒本身不免费，每次注入都要占一段 prompt 与一次决策。
+
+## 预注册：R1（压缩提醒里加一句「别重读本回合写过的文件」）
+
+动机来自迁移族的长尾结构，不是新猜想：`D2B_MIG`、`DR8_MIG` 的逐对记录里，最慢的几对都是同一个模式——模型写完一处，随后把整份文件重新读回来确认，再进入下一次编辑；`DR8_MIG` 的最差对 `p6` 甚至把已完成的检查整段重做。读回来的内容要占工具参数与回显的输出 token，而输出 token 全部是解码时间。
+
+实现取最小侵入：不新增消息、不改调度点，只在已有第 4 步压缩提醒的文本里追加一句「本回合已经写过的文件，按最后一次编辑和检查输出来判断，不要为了确认整份重读」。开关 `compactRereadHint` 默认 `false`，1.5.17 行为逐字不变。
+
+臂：`bench/arms/r1.yml` = `outputDiscipline: late` + `compactRereadHint: true`，其余与 `def15` 同。基线 `def15`。
+
+预注册判据（先写判据，再跑数据）：
+
+- **R1_MIG**（migrate，6 对）：几何均值墙钟比 ≤ **0.85** 且至少 **4/6** 对更快 ⇒ 判「有效」。0.85–1.00 视为「方向对但不够」，> 1.00 视为「这句提醒是噪声」，两种情况杠杆关闭。
+- **R1_DBG**（debugfix，7 对）：只作族间一致性参考，不作判据；若 migrate 通过而 debugfix 明显变慢（> 1.05）也要重估，因为提醒是按步数入场、与任务族无关。
+- 质量门槛与既有块相同：每对必须 `hasSessionIds` 且 `green`，否则该对不计入（照旧报 n 与丢弃对）。
+
+## 预注册：DEF（默认配置 vs 完全关闭，现代任务集上的干净对照）
+
+`README` 一直写「默认就更快」，但这个对照在**当前任务集**上还没有一块干净的测量：带 `off` 臂的块要么是旧行格式（`V15`/`W3` 等），要么只有零星单对（`REL16` 5 对、`DBG2` 7 对，几何 0.889 / 0.958，都不是任务族内的成对结论）。所以先把判据写下来，再测。
+
+臂：`def15`（`enabled: true, gear: auto` + 1.5.17 默认）对 `off`（`enabled: false`，插件完全退场）。任务族取长尾最明显的两族：migrate（6 对）与 debugfix（7 对）。
+
+预注册判据：
+
+- **DEF_MIG**：几何均值墙钟比 ≤ **0.85** 且至少 **4/6** 对更快 ⇒「默认在长迁移上更快」成立，可继续写在 `README`。0.85–1.00 ⇒ 只能写「不劣于原生」，不得写具体倍数。> 1.00 ⇒「默认更快」这句话必须从 `README` 撤回。
+- **DEF_DBG**：同一门槛，族内独立判断；两族都过才算「默认普适更快」，只有一族过就按族写。
+- 质量门槛照旧：`hasSessionIds` 且 `green` 才算一对；报 n 与丢弃对。这一块的墙钟是唯一可以横向引用绝对值的对照（`off` 臂是同一台机器同一时段的原生基线）。
+
+## 预注册：D3（压缩提醒放到第 3 步）——默认时点能不能再往前挪一格
+
+现有事实：`disciplineAfterSteps: 2`（`d2`）在 migrate 上 0.495–0.751×，但在 debugfix 与 codeimpl 上掉到 0.903–1.073×，所以默认停在 4；第 4 步（`def15`）是当前默认。第 3 步是两者中间唯一还没测过的位置——如果它保留迁移式的收益而把 `d2` 在 debugfix/codeimpl 上的损失收回来，默认时点就有值得改的方向；如果它两头都不占，默认继续停在 4，这条线彻底关闭。
+
+臂：`d3.yml` = `outputDiscipline: late` + `disciplineAfterSteps: 3`，其余同 `def15`。
+
+预注册判据（先写判据，再跑数据）：
+
+- **`D3_MIG`**（6 对）：几何 ≤ **0.85** 且 ≥ 4/6 更快（与 `d2` 同门槛）。
+- **`D3_DBG`**（7 对）：几何 ≤ **0.90** 且 ≥ 5/7 更快（比 `d2g` 那条 0.80 松一档，因为这次不是要它「更快」，只是要它「不掉队」）。
+- **改默认只用同时满足两条**：`MIG` 过且 `DBG` 过，且 `DBG` 不比 `def15` 差到 1.00 以上；否则默认继续是 4。任何一条不过，本块都只作为「第 3 步的代价」记录，不改默认。
+- 质量门槛照旧：`hasSessionIds` 且 `green` 才算一对；报 n 与丢弃对。
+
+## 结果：`D3_MIG` 第 3 步提醒在 migrate 上 **0.509×（5 对可用）**，过 MIG 门槛；但出现一次跑到 50 步、测试没跑起来的无效跑
+
+**数字（`def15` vs `d3`，migrate 6 对）。** 5 对可用（第 6 对 `d3` 被判 `valid=false`，见下）：几何 **0.509×**、中位 0.636×、4/5 更快、范围 0.151–1.134×；步数几何 0.622×、输出几何 0.528×。逐对：
+
+| 对 | `def15` | `d3` | 比值 | 步数 | 输出 token |
+|---|---|---|---|---|---|
+| p1 | 275.6 s | 96.7 s | **0.351×** | 14→11 | 25 480→10 638 |
+| p2 | 151.8 s | 96.5 s | 0.636× | 12→7 | 19 488→11 857 |
+| p3 | 121.2 s | 137.5 s | 1.134× | 9→10 | 13 602→10 916 |
+| p4 | 620.6 s | 93.7 s | **0.151×** | 36→11 | 40 815→9 277 |
+| p5 | 199.1 s | 177.9 s | 0.893× | 20→12 | 23 771→21 142 |
+| p6 | 210.0 s | 665.3 s（无效） | — | 11→**50** | 18 755→40 979 |
+
+**判定。** 预注册 `D3_MIG` 要求几何 ≤ 0.85 且 ≥ 4/6 更快：可用 5 对几何 0.509×、4/5 更快，两条都过（若把 p6 计进去是 0.690×、4/6，也过）。所以 MIG 这一半 **PASS**，是否改默认还要等 `D3_DBG`（≤ 0.85 且 5/7）与 `D3_IMPL`。
+
+**两处必须写清的偏差。**
+
+1. **p6 的 `d3` 是无效跑，不是「慢」那么简单。** `valid=false` 在这一套里的定义是「测试没跑起来」：`total==0`（或 leak）。这一跑走了 50 步、40 979 token、665 s，`hasSessionIds`/`green` 仍为真但 grade 没有产出，所以按预注册的「`hasSessionIds` 且 `green` 且 `valid`」被丢弃。它同时也是**第 3 步提醒的尾部风险证据**：更早的提醒可能让模型在长迁移上更早收束、也可能让它反复试探。这一条不能当「d3 更慢 3.17×」讲，只能当「一次没交付的跑」记着。
+2. **同一块里 `def15` 也出了一次 620 s / 36 步的长尾**（`valid=true`，交付正常）。两臂各一次超长尾，方向不同，说明 migrate 这一族本身是重尾分布，单看某一对没有意义——这也是继续只报几何 + 胜场、不报单对的原因。
+
+**机制读数（沿用 9 条分解）。** 5 对里赢的四对全部同时压步数与输出（步数 0.622×、输出 0.528×），与 `d2`/`d2g` 在 migrate 上看到的「输出 token 才是主因」一致：p1 的 275.6→96.7 s 里步数贡献 −58 s、每步成本贡献 −120 s；p4 的 620.6→93.7 s 里步数贡献 −368 s。p5 是唯一「步数少了 8 步、每步反而更贵」的一对（9.8→14.6 s/步），净收益只剩 11 %——和「早提醒不是无条件赢」的既有结论吻合。
+
+## 结果：`D2_PIPE`（`d2` 在 shellpipeline 上，4 对可用）——**没有信号，1.111×，判「未测到」**
+
+**数字（`def15` vs `d2`，shellpipeline）。** 计划 6 对，队列在 4 对后暂停，可用 4 对、丢弃 0：几何 **1.111×**、中位 1.006×、2/4 更快、范围 0.641–2.594×；步数几何 **1.527×**、输出几何 1.047×；符号检验 p=1.000。逐对：
+
+| 对 | `def15` | `d2` | 比值 | 步数 | 输出 token |
+|---|---|---|---|---|---|
+| p1 | 92.2 s | 239.1 s | **2.594×** | 7→29 | 10 129→25 071 |
+| p2 | 218.7 s | 140.2 s | 0.641× | 15→13 | 21 010→13 788 |
+| p3 | 219.1 s | 153.4 s | 0.700× | 19→23 | 27 113→17 137 |
+| p4 | 114.0 s | 149.5 s | 1.312× | 12→15 | 12 038→14 065 |
+
+**判定：不成立，也不反向。** 4 对里 2 对更快、几何 1.111× 由单个离群点（p1 的 7→29 步）拖出，去掉它三对几何 0.837×。n=4 太小，符号检验必然 p=1，这一块**不能写「更快」也不能写「更慢」**，只能记成「在 shellpipeline 上第 2 步提醒没有可测收益」。
+
+**机制读数。** p1 的 2.594× 里步数贡献 +99 s、每步成本贡献 +48 s：`d2` 在第 2 步就收到「省着写」提醒后，反而在同一族里把 7 步的短流程拖成 29 步——与 `d2` 在 codeimpl/debugfix 上的既有结论（0.903–1.073×）方向一致：**早提醒在「本来就短、本来就要多验证」的形状上是净成本**。p2/p3 是反向证据（同样收到第 2 步提醒却步数不涨、输出降 35–37 %），说明签名不是家族级而是单跑级的。
+
+**对队列的影响。** 这一族已经有 `d2g`（0.903×）与 `D2_PIPE`（1.111×，n=4）两块都不支持第 2 步，加上 `D3_MIG` 的 PASS 只覆盖 migrate，默认继续停在第 4 步；`D2_PIPE` 不再补对：现有 4 对几何 1.111×，即使补的两对都跑到 0.70×，6 对几何也只有约 0.94×，仍然写不出「更快」；再补 2 对换取一个大概率仍是 0.9× 上下的数字，成本不划算。下一步跑 `D3_DBG`（第 3 步在 debugfix 上掉不掉队），它是「默认时点能不能挪」的最后一个 gate。
+
+## 结果：`D3_DBG`（第 3 步提醒在 debugfix 上）判 **FAIL**：6/7 更快、中位 0.876×，但几何 1.128× 被一格模型侧长尾顶穿
+
+**数字（`def15` vs `d3`，debugfix 7 对，全部可用、丢弃 0）。** 几何 **1.128×**、中位 **0.876×**、6/7 更快、范围 0.585–7.346×；步数几何 1.321×、输出几何 1.116×；符号检验 p=0.125。逐对：
+
+| 对 | `def15` | `d3` | 比值 | 步数 | 输出 token |
+|---|---|---|---|---|---|
+| p1 | 33.5 s | 32.1 s | 0.960× | 5→5 | 3 906→3 683 |
+| p2 | 75.1 s | 43.9 s | **0.585×** | 6→5 | 5 956→4 317 |
+| p3 | 49.5 s | 363.9 s | **7.346×** | 4→10 | 4 437→**21 743** |
+| p4 | 76.8 s | 65.1 s | 0.847× | 7→6 | 5 091→4 733 |
+| p5 | 69.8 s | 57.4 s | 0.822× | 4→7 | 4 967→3 757 |
+| p6 | 103.7 s | 96.1 s | 0.926× | 4→4 | 6 154→6 786 |
+| p7 | 40.4 s | 35.4 s | 0.876× | 4→9 | 3 908→3 235 |
+
+**判定：FAIL，默认继续停在第 4 步。** 预注册 `D3_DBG` 要求几何 ≤ 0.90 **且** ≥ 5/7 更快；胜场过（6/7），几何不过（1.128×）。按预注册「改默认要 MIG 与 DBG 同时过」的规则，`MIG` 过、`DBG` 不过，所以 `disciplineAfterSteps` 不改，维持 4。
+
+**p3 的 7.346× 不是 d3 的行为效应，是模型侧输出长度波动。** 该格 `llm` 361 s / 墙钟 364 s（99 % 在模型里），步数与 `def15` 同为有效、输出 21 743 token 对 4 437 token（4.9×）。全部 7 对里只有这一格输出变长，其余 6 格输出全部下降；把这 6 格单独加总几何是 **0.826×**（0.826 = 6 格几何，与胜场一致）。所以准确的说法是「第 3 步在 debugfix 上典型更快、但有一个尾部风险：更早的提醒偶尔与模型自己的长输出叠加」。**这不是把 FAIL 改判成 PASS**：预注册门禁就是几何口径，一格 4.9× 输出属于「真实会发生的分布」，不能用剔除它来通过门禁。
+
+**方法层的发现（记下来给下一次预注册用）。** 本块和 `D3_MIG` 各出现一格 3–7× 的模型侧长尾，几何均值对这种重尾极敏感：n=7 时单格 7.35× 就能把 0.826× 抬到 1.128×。以后这类「按族看训练信号」的块，预注册应写成**中位 + 胜场为主、几何只作辅助**（例如「中位 ≤ 0.90 且 ≥ 5/7 更快，几何不设上限」），否则门禁测的是尾部分布而不是行为效应。这次不改本块的判定，只记录。
+
+**工具修复（影响复算）。** 这一块最初被 `~/.local/fm/block_score.py` 判成「0 对可用」——它还在读旧字段 `exact`，而 1.5.18 起 runner 写的是 `hasSessionIds`。已把评分器收进仓库 `bench/block_score.py` 并改成 `row.get('hasSessionIds', row.get('exact'))`；`python3 bench/block_score.py D3_DBG def15 d3` 可复现上表。旧字段读取点只剩 `pool.py`/`report.py`/`d2gscore.py`/`dr8score.py` 已带 fallback，历史结果不需要转换。
+
+## 结果：`DEF_MIG`（默认 `def15` vs 完全关闭，migrate，跑在 **1.5.19** 上）——**0.688×，5/5 更快**，默认在长迁移上仍然更快
+
+**这一块的意义。** 前面的 0.823× 全池口径是在 1.5.15–1.5.17 的构建上测的；1.5.19 改了三处会**减少提示**的行为（检查复用证据不再透支、取消三态改写、`disciplineEarlyCalls` 冻结），理论上「提示更少 ⇒ 复用建议更少 ⇒ 可能变慢」。所以必须用**发布版**重新对一次 `off`（插件完全关闭）。臂：`def15` = 发布默认（`outputDiscipline: late`、第 4 步提醒、其余增强默认关），`off` = `enabled: false`。
+
+**数字（6 对计划，5 对可用、丢弃 1）。** 几何 **0.688×**、中位 0.655×、**5/5 更快**、范围 0.566–0.850×；步数几何 **0.944×**、输出几何 **0.925×**。逐对：
+
+| 对 | `off` | `def15` | 比值 | 步数 | 输出 token |
+|---|---|---|---|---|---|
+| p1 | 225.4 s | 147.7 s | 0.655× | 9→8 | 14 975→11 362 |
+| p2 | 253.5 s | 143.6 s | **0.566×** | 9→9 | 16 517→15 351 |
+| p3 | 221.4 s | 128.8 s | 0.582× | 9→11 | 12 913→16 334 |
+| p5 | 399.6 s | 339.8 s | 0.850× | 17→13 | 27 262→21 519 |
+| p6 | 147.9 s | 124.3 s | 0.840× | 10→9 | 13 402→12 867 |
+
+丢弃的 p4：`off` 那一格 `leak: true`（53 步、46 988 token、1 149 s，测试没交付），`def15` 那一格 370 s / 11 步、`valid`。按预注册「`hasSessionIds` 且 `green` 且 `valid`」丢弃。注意这个丢弃方向是**对我们不利的**：`off` 那格是失败跑，如果硬算进去 `off` 会更慢、比值更小，所以 0.688× 不是靠丢掉不利格子得来的。
+
+**判定：过预注册门槛。** `DEF_MIG` 要求几何 ≤ 0.85 且 ≥ 4/6 更快：可用 5 对（p4 丢弃，n=5 < 6 已在上面说明）、几何 0.688×、5/5，两条都过。结论：**发布版 1.5.19 的默认配置在长迁移上对比「完全关闭」依然快约 31 %**，且 5 对新会话方向全一致（符号检验 p=0.031）。
+
+**机制读数：这一块的收益不是「少走步」，是「每步更省」。** 步数只降到 0.944×、输出只降到 0.925×，但墙钟到 0.688× ⇒ 每步耗时约 **0.73×**（`off` 24.6–28.2 s/步 vs `def15` 11.7–18.5 s/步）。这与全池分解（步数 0.827 × 每步 0.996 = 0.823×）**方向不同**：全池是「少走步」，这一块是「同样步数、每步的模型时间更短」。两种都成立，说明**提速来源随族变化**：migrate 上提醒把每次调用的思考/输出压短（`out` 几乎不变但落盘 token 少），全池里则是靠提前收束减少轮次。对外只报全池 0.823× 不会错，但不要把它当成「只有一条机制」。
+
+## 结果：`DEF_DBG`（默认 vs 关闭，debugfix，1.5.19）——几何 **0.770×**，但只有 4/7 更快
+
+7 对全部可用。几何 **0.770×**、中位 **0.760×**、**4/7 更快**、范围 0.407–1.323×；步数几何 0.794×、输出几何 0.880×；符号检验 p=1.000。
+
+| 对 | `off` | `def15` | 比值 | 步数 | 输出 token |
+|---|---|---|---|---|---|
+| p1 | 36.5 s | 41.8 s | 1.147× | 4→4 | 4 047→4 773 |
+| p2 | 60.4 s | 45.9 s | 0.760× | 10→4 | 5 049→6 369 |
+| p3 | 34.3 s | 44.3 s | **1.294×** | 6→4 | 4 106→4 553 |
+| p4 | 72.5 s | 34.1 s | **0.470×** | 4→4 | 7 191→3 849 |
+| p5 | 66.5 s | 27.1 s | **0.407×** | 4→5 | 4 512→2 851 |
+| p6 | 33.3 s | 44.0 s | **1.323×** | 7→5 | 4 046→5 582 |
+| p7 | 79.3 s | 44.5 s | 0.560× | 6→5 | 8 408→4 447 |
+
+**读法：几何与胜场分离。** 快的时候快很多（0.407、0.470、0.560），慢的时候慢得不多（1.147、1.294、1.323，单看都在或接近 ±20 % 噪声带），所以几何 0.770× 而胜场只有 4/7。p3/p6 有一个共同点：`def15` 步数更少但输出 token 更多（4 553 vs 4 106、5 582 vs 4 046）——第 4 步的「少写过程」提醒在这两格里像是让模型**先压缩一次、再补回来**。这是短任务上提醒本身有成本的又一条实例（与 1.5.1 里 `perfrefactor` 1.18×、`csvpipe` 1.12× 同向），不是判 FAIL 的依据：`DEF_DBG` 不承担改默认的职责，它只回答「发布版默认还快不快」。
+
+**合池（`DEF_MIG` + `DEF_DBG`，发布版 1.5.19，12 对）。** 几何 **0.735×**（省约 26.5 %）、逐格中位 **0.708×**、9/12 更快、范围 0.407–1.323×；两族步数几何 0.886×、输出几何 0.907×。这一组是「发布版对新会话」的最干净对照（`off` = `enabled: false`，同一台机、ABBA 交错），结论：**1.5.19 减少提示之后，默认配置的提速还在，方向和量级与全池 0.823× 一致**；单块 n 小（5 和 7），对外仍只用 138 对全池口径，这组数字作为发布版复核记录。

package/CHANGELOG.md

@@ -1,12 +1,29 @@
 # Changelog
 
-## 1.5.18（只改文档与卡面：README 开头改成「结论先行」，统一用「耗时」）
+## 1.5.20（补丁类编辑重新拥有复用证据：从 diff 头读目标文件）
 
-- README 顶部换成结论先行：先说清楚这是 DeepSeek Harness 自己的快速模式、能控制什么（思考在哪一步收敛、中间汇报输出、最多几步），再给四行实测——默认 0.72× 总耗时 / 0.74× 输出 token / 0.71× 步数；提醒提前到第 2 步在 `debugfix` 0.535×、`ledger` 0.506×、`migrate` 0.751×，13 对合并 0.625×、输出 0.614×；第 3 步在 `migrate` 到 0.509×、输出 0.528×；短改修与数据整形不承诺。数字全部取自 BENCHMARK.md 已有块，没有新增实验。
+- **补丁编辑不再拖垮整个会话的复用提示。** `apply_patch` / `patch` 的写入目标在补丁正文里，参数里没有 `path` 字段；1.5.19 把「定位不到目标的写入」如实标成不确定，代价是**会话里只要用过一次补丁，后续所有检查复用建议都关掉**——而补丁正是最常见的改文件方式，等于最常见的路径拿到了最少的那部分提速。现在从 `*** Update File:` / `*** Add File:` / `*** Move to:` / `+++ b/<path>` 头里读出目标文件并照常打指纹；只有补丁头里一个路径都读不出来时才保持不确定（保守方向不变）。`*** Delete File:` 不计入（文件已消失，打不了指纹）。
+- 只对补丁形状的工具（`apply_patch` / `patch` / `apply_diff` / `edit_patch`）扫正文：整文件写入的 `content` 里可能恰好含 diff 文本，那种情况仍以它自己的 `path` 字段为准。
+- 附：`bench/block_score.py` 随包发布（74 行，纯标准库），按 `hasSessionIds`/`green`/`valid`/`leak` 过滤后可复算每个块的几何、中位、胜场与符号检验。
+
+## 1.5.19（稳定性发布：面板三项真正可读写、检查复用证据不透支、取消三态、实验臂与判据对齐）
+
+> 1.5.18 在 npm 上只有文档改动（README 结论先行），代码修复都在 1.5.19；升级请直接装 1.5.19。
+
+- **面板三项设置在官方宿主上真正可读可写**：官方的 `describe()` 只投影 volatile 字段，`outputDiscipline` / `stepBudget` / `workspaceMap` 原先非 volatile，于是面板只能画内置默认（`late` / 0 / off）、写入被宿主以 `Config field "…" is not volatile` 拒绝。三项声明 `.volatile()` 后 describe 投影、write 接受、写后读回同一值；默认值不变，实际写入仍只落在本会话的 `sessions` 条目。
+- **检查复用证据按检查独立，且要求路径可信**：`reuse-check` 的命中判定从「同一工具 + 同一参数」收紧到「同一条检查 + 同一份产物」，只有参数里出现可信路径、且该路径在本轮没有被改写过时才算复用；否则只按无进展提醒，不给「结果可复用」的结论。
+- **取消三态可信**：取消结果区分「已请求取消」「已确认进程退出」「未确认」三种，只有第二种能当失败结论；后两种都把「进程可能仍在跑」写回上下文，不再把未确认的取消报成已退出。
+- **`disciplineEarlyCalls` 的决策在第 1 步冻结**：首次请求时确定本轮的提醒步数，同一轮内不再随步数重算，避免同一轮里提醒时点漂移。
+- **输出预算按本轮步数**：`outputBudget` / `outputBudgetAfterSteps` 用本轮步数结算，不再读跨轮累计值。
+- **父 signal 监听器清理**：看门狗在调用结束（成功、失败、取消）后移除挂在父 `AbortSignal` 上的监听器，长会话不再累积。
+
+- README 顶部换成结论先行：先说清楚这是 DeepSeek Harness 自己的快速模式、能控制什么（执行策略：减少冗余回合与输出，不改模型与思考强度），再给四行实测——默认 0.72× 总耗时 / 0.74× 输出 token / 0.71× 步数；提醒提前到第 2 步在 `debugfix` 0.535×、`ledger` 0.506×、`migrate` 0.751×，13 对合并 0.625×、输出 0.614×；第 3 步在 `migrate` 到 0.509×、输出 0.528×；短改修与数据整形不承诺。数字全部取自 BENCHMARK.md 已有块，没有新增实验。
 - 表述统一：正文里的「墙钟」改成「耗时」（术语表词条同步重写），不再以「墙钟」作为对读者的解释词；结论只讲「快多少、token 少多少」。
-- 市场卡面文案同步改写（en / zh），去掉旧的 18% 合池口径与「墙钟」措辞，改成本版的结论先行版本。
+- 市场卡面文案同步改写（en / zh）：去掉「墙钟」措辞，速度口径与上面的全池 0.823×（12 块 138 对）一致。
 - 英文 README 同步。
-- 无代码变化，默认配置与 1.5.17 完全相同。`compactRereadHint` 等未完成的旋钮不在本版。
+- README / REFERENCE 的机制表述与实测对齐：新增「三条边界」（承诺不改模型与 `reasoningEffort`；收益来自冗余回合与输出 token 下降，不归因于删旁白；质量以隐藏测试与真实评测为准，不宣称行为完全等价）。旁白占比有了可复算口径：新增 `bench/textshare.py`（transcript 里 `assistant/message` 可见 text 字符 ÷（text + `tool/call.arguments` 字符），不含 reasoning、工具返回与用户消息），def15 全量 341 会话 / 3,327 消息 / 3,569 调用，正文 51,366 / 参数 4,315,096 = **1.18 %**（中位 0.98 %、p90 4.08 %），`python3 bench/textshare.py --limit 0` 复算。
+- 面板默认值与 1.5.17 相同；`compactRereadHint` 默认关闭，不在本版默认行为内。
+- **验证**：`node --test test/*.test.js` **302 pass / 0 fail**（新增面板读写的宿主投影/校验用例、`reuse-check` 证据语义用例、取消三态与监听器清理用例）；`ui-copy-lint` clean、`zh-lint` 0 error（37 warning 既有）、`style-lint` 通过；`bench/verify-arm-reminders.mjs` 机制 10/10、臂×场景 8/8 通过。
 
 ## 1.5.17（面板四行、按会话隔离、网关用量兼容）
 

package/README.en.md

@@ -9,7 +9,7 @@
 
 <p align="center">
   <b>DeepSeek Harness's own fast mode: a few configs that set how fast a task runs.</b><br>
-  Bound where thinking settles, bound the process narration, bound the steps per task — faster delivery without touching the model or its thinking strength.
+  Never changes the model or its reasoning effort; it cuts redundant round trips and output through execution-strategy hints — the gain is fewer steps and fewer output tokens, not deleted narration.
 </p>
 
 <p align="center">
@@ -26,7 +26,8 @@
 
 Across 10 task families and 30 complete units (hidden tests 60/60 green):
 
-- **Default**: 0.72x total time, 0.74x output tokens, 0.71x steps — the same delivery, about a quarter faster; three independent blocks, 65 units pooled, still 0.74x.
+- **Default (whole pool, no block picking)**: 12 clean blocks, 10 task families, 138 valid pairs, added as whole tasks — **0.823x** total time (about 18 % saved), 0.818x output tokens, 0.806x steps, 93 of 138 pairs faster (recompute with `python3 bench/pool.py`). The earlier 0.72-0.74x came from three hand-picked blocks and has been withdrawn; why is in BENCHMARK.md.
+- **Re-checked on the shipped build (1.5.19, default vs fully off)**: `migrate` 5 usable pairs at 0.688x (5/5 faster), `debugfix` 7 pairs at 0.770x (4/7 faster; three reverse cells pull the geometric mean down while the wins are much larger), 12 pairs pooled **0.735x**, per-cell median 0.708x, 9/12 faster (`bench/block_score.py` recomputes). 1.5.19 ships fewer hints, so this run confirms the release did not eat the gain; n per block is small, so the headline stays the 138-pair pool above.
 - **Moving the "write it once" reminder from step 4 to step 2**: `debugfix` 0.535x, `ledger` 0.506x, `migrate` 0.751x; 13 pairs pooled **0.625x** with output tokens **0.614x**. At step 3, `migrate` alone reaches **0.509x** with output tokens **0.528x**.
 - **Quality**: in every pair both arms produced identical hidden assertions, all green; the saving is fewer edit-recheck loops, not fewer checks.
 - **Where it does not pay**: 1-5 step repairs and data reshaping (`perfrefactor` 1.18x, `csvpipe` 1.12x), so try it once per task shape.
@@ -36,11 +37,17 @@ Across 10 task families and 30 complete units (hidden tests 60/60 green):
 A step costs round-trip overhead × steps + decode time × output tokens + tool wait. Model and thinking strength are not in that equation, so fast mode only moves three programmatic quantities:
 
 - **Parallel fan-out.** The scheduler asks whether this step is "several reads of different targets"; only then does it go wide (up to 8) and remember that shape across turns. Write steps, single-call steps, erroring or stalled turns **stay native** — the whole batching section is not rendered, so it costs no input tokens.
-- **Output discipline.** It trims process narration (no call previews, no restating results, no progress reports); the final answer is untouched.
+- **Output discipline.** Asks the model to skip call previews, restatements and progress reports, never to shorten the final answer. Honest scope: visible assistant prose is only **1.18 %** of the characters in (prose + tool arguments) (def15, 341 sessions / 3,327 messages / 3,569 calls, 51,366 prose vs 4,315,096 argument characters; excludes reasoning and tool results; recompute with `python3 bench/textshare.py --limit 0`), so the speedup cannot be attributed to deleted narration — it comes from fewer round trips and fewer output tokens (fewer repeat edits, re-reads and verification passes). That is not the same claim as "nothing about the work changes".
 - **Stall watchdog.** Shell/script calls get a 120–300 s adaptive cap; a stuck call is cancelled and "change the approach" is written back into the context.
 
 No model switch, no `reasoningEffort` rewrite, no request-field injection (`service_tier`, `max_tokens`, anything like them). While the mode is on, the model's input carries this plugin's own scheduling guidance and reminders — that is the mechanism; switch the mode off and they are gone. DeepSeek's official API, an OpenAI-compatible relay, a self-hosted gateway, Anthropic routes — all work the same.
 
+## Three boundaries
+
+- **The explicit promise**: the plugin does not change the model, does not rewrite `reasoningEffort`, and does not inject request fields. That is where quality degradation would most likely come from, and the plugin stays out of it.
+- **Honest mechanism**: execution-strategy hints cut redundant round trips and output. The evidence is falling steps and output tokens (whole-pool default arm: 0.806× steps, 0.818× output); no claim that the gain comes from deleting narration.
+- **Quality boundary**: quality is judged by hidden tests and real evaluations, and behaviour is not claimed to be fully equivalent. When the quality gate fails, quality wins: experimental knobs ship off, and the default is only adopted from batches where both arms' hidden assertions match cell by cell.
+
 ## Three words, defined
 
 - **Time**: end-to-end time from the task being issued to the headless process exiting, including model latency, tool waits and plugin overhead. Every "X s" below is this.
@@ -49,7 +56,7 @@ No model switch, no `reasoningEffort` rewrite, no request-field injection (`serv
 
 ## Measured
 
-**Toggle it on and the headline is: about 18% faster in total, and 25–30% faster on the shapes it fits.** That is every clean block with an `off` anchor pooled (12 blocks, 138 valid pairs, 10 task families; recompute with `python3 bench/pool.py`): total time **0.823×** (18% less), output tokens 0.818×, steps 0.806×, per-cell median 0.799×, faster in 93 of 138 pairs (sign test p = 0.0001). Bootstrapping those 138 pairs 2000 times puts the total ratio at a 95% interval of **[0.742, 0.913]** (9% to 26% faster), the per-cell median at [0.703, 0.885], and the geometric mean at 0.825× (interval 0.753–0.900) — "about 18%" is a point estimate, not a floor. The only quality statement at the same denominator: hidden assertions matched cell for cell across the 138 pairs (`off` 2038/2038, default 2037/2038, the one difference being a 21/22 cell) — that is **assertion parity**, not "zero quality loss". 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.
+**Toggle it on and the headline is: about 18% faster in total, and 25–30% faster on the shapes it fits.** That is every clean block with an `off` anchor pooled (12 blocks, 138 valid pairs, 10 task families; recompute with `python3 bench/pool.py`): total time **0.823×** (18% less), output tokens 0.818×, steps 0.806×, per-cell median 0.799×, faster in 93 of 138 pairs (sign test p = 0.0001). Bootstrapping those 138 pairs 2000 times puts the total ratio at a 95% interval of **[0.742, 0.913]** (9% to 26% faster), the per-cell median at [0.703, 0.885], and the geometric mean at 0.825× (interval 0.753–0.900; that is the paired geometric mean, a different statistic from the pooled total ratio **0.823×**, and the two are not interchangeable) — "about 18%" is a point estimate, not a floor. The only quality statement at the same denominator: hidden assertions matched cell for cell across the 138 pairs (`off` 2038/2038, default 2037/2038, the one difference being a 21/22 cell) — that is **assertion parity**, not "zero quality loss". 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.
 

package/README.md

@@ -9,7 +9,7 @@
 
 <p align="center">
   <b>DeepSeek Harness 自己的快速模式：用几项配置控制任务的运行速度。</b><br>
-  限制思考在哪一步收敛、限制中间汇报的输出、限制最多几步——在不改变模型与思考强度的前提下，把任务做得更快。
+  不改模型、不改 reasoningEffort；用执行策略提示减少冗余回合与输出——收益来自步数与输出 token 下降，不是删旁白。
 </p>
 
 <p align="center">
@@ -26,7 +26,8 @@
 
 在 10 类任务、30 个完整单元上（隐藏测试 60/60 全绿）：
 
-- **默认配置**：总耗时 0.72×、输出 token 0.74×、步数 0.71× —— 同样的交付，快约四分之一；三块独立复现合并 65 个单元仍是 0.74×。
+- **默认配置（全池口径，不挑块）**：12 个干净块、10 类任务、138 对有效配对的整任务总量 —— 总耗时 **0.823×**（省约 18 %）、输出 token 0.818×、步数 0.806×，138 对里 93 对更快（`python3 bench/pool.py` 可复算）。之前对外说的 0.72–0.74× 只来自挑出来的三块，已撤回，原因写在 BENCHMARK.md。
+- **发布版复核（1.5.19，默认 vs 完全关闭）**：`migrate` 5 对可用 0.688×（5/5 更快）、`debugfix` 7 对 0.770×（4/7 更快、几何被三格反向拉低但赢面更大），12 对合池 **0.735×**、逐格中位 0.708×、9/12 更快（`bench/block_score.py` 可复算）。1.5.19 减少了提示，这一轮就是用发布版确认「提示变少没把收益吃掉」；单块 n 小，对外仍只用上面的 138 对全池口径。
 - **把「省着写」提醒从第 4 步提前到第 2 步**：`debugfix` 0.535×（快约 47%）、`ledger` 0.506×（快约 49%）、`migrate` 0.751×；13 对合并 **0.625×**（快约 38%）、输出 token **0.614×**（少约 39%）。再提前到第 3 步，`migrate` 单族 **0.509×**（快约 49%）、输出 token **0.528×**（少约 47%）。
 - **质量**：上述每一对里两臂的隐藏断言逐格相同、全绿；快的是少做几遍「改一版→再读一遍→再改一版」，不是少验证。
 - **不承诺的地方**：1–5 步的小改修与数据整形收不回提醒成本（`perfrefactor` 1.18×、`csvpipe` 1.12×），所以按任务形状先试一次再定。
@@ -36,11 +37,17 @@
 一步的用时 = 往返开销 × 步数 + 解码时间 × 输出 token + 工具等待。模型和思考强度不在这个式子里，所以快模式只动三个程序量：
 
 - **并行扇出**：调度器先判断这一步是不是“多个互不依赖的读”，是才要宽（最多 8），并且跨轮记住这个形状；写操作、单调用、连续报错或无进展的回合**保持原生** —— 整段批处理提示不渲染，不为它付输入 token。
-- **输出纪律**：只裁剪过程叙述（不预告、不复述、不写进度），最终答案完整保留。
+- **输出纪律**：提示模型不预告调用、不复述结果、不写进度报告，但**不缩短最终答案**。口径要说清：实测里可见助手正文只占「正文+工具参数」字符的 **1.18%**（def15 全量 341 会话 / 3,327 消息 / 3,569 调用，正文 51,366 / 参数 4,315,096 字符；不含 reasoning 与工具返回；`python3 bench/textshare.py --limit 0` 可复算），所以提速不能归因于删旁白——它来自回合数与输出 token 变少（少重复编辑、少回头读、少验证往返），这和「内容不受影响」不是一回事。
 - **卡顿看门狗**：给 shell/脚本类调用设 120–300 秒自适应上限，卡住的调用被取消并把“换做法”写回上下文。
 
 没有模型切换、没有 `reasoningEffort` 改写、没有请求字段注入；开着时模型输入里会多出本插件自己的调度提示与提醒（这是机制本身），关掉后连这些也不存在。DeepSeek 官方 API、OpenAI 兼容中转、自建网关、Anthropic 协议 —— 走哪条路由都成立。
 
+## 三条边界
+
+- **明确承诺**：不改模型、不改 `reasoningEffort`、不注入请求字段。降智风险最容易发生的地方，插件不碰。
+- **机制诚实**：靠执行策略提示减少冗余回合与输出。证据是步数与输出 token 下降（全池默认臂 0.806× 步数、0.818× 输出）；不宣称收益来自「删旁白」。
+- **质量边界**：任务质量以隐藏测试判分与真实评测为准，不宣称行为完全等价。质量门槛不过就优先保质量：实验性旋钮默认关闭，默认配置只在两臂隐藏断言逐格相同的批次里采用。
+
 ## 先把三个词说清楚
 
 - **耗时**：任务从发出到 headless 进程退出的端到端时间，包含模型延迟、工具等待与插件开销。下文的「X 秒」都是它。
@@ -49,13 +56,13 @@
 
 ## 实测
 
-**打开小闪电，排头的一句结论：整任务总量约快 18 %，适合的形状快 25–30 %。** 这是把**所有**有 `off` 锚的干净块一起加总的结果（12 个块、138 对有效配对、10 个任务家族，`python3 bench/pool.py` 可复算）：总耗时 **0.823×**（省 18 %）、输出 token 0.818×、步数 0.806×、逐格中位 0.799×、138 对里 93 对更快（符号检验 p = 0.0001）。对这 138 对自助重抽 2000 次，总比 95 % 区间是 **[0.742, 0.913]**（即省 9 %–26 %），逐格中位区间 [0.703, 0.885]，几何均值 0.825×（区间 0.753–0.900）——「约 18 %」是点估计、不是下限承诺。质量的同口径结论只有一句：138 对里两臂隐藏断言逐格完全相同（`off` 2038/2038、默认 2037/2038，唯一差的是一格 21/22），这是**断言对等**，不是「零质量损失」。逐家族稳定性与符号检验见 [BENCHMARK.md](BENCHMARK.md) 的「合池的自助区间与逐任务稳定性」一节，那里也写了为什么逐家族数字不能跨块引用。
+**打开小闪电，排头的一句结论：整任务总量约快 18 %，适合的形状快 25–30 %。** 这是把**所有**有 `off` 锚的干净块一起加总的结果（12 个块、138 对有效配对、10 类固定任务，`python3 bench/pool.py` 可复算）：总耗时 **0.823×**（省 18 %）、输出 token 0.818×、步数 0.806×、逐格中位 0.799×、138 对里 93 对更快（符号检验 p = 0.0001）。对这 138 对自助重抽 2000 次，总比 95 % 区间是 **[0.742, 0.913]**（即省 9 %–26 %），逐格中位区间 [0.703, 0.885]，几何均值 0.825×（区间 0.753–0.900；这是配对几何均值，与全池总量比 **0.823×** 是两种口径，不可互换）——「约 18 %」是点估计、不是下限承诺。质量的同口径结论只有一句：138 对里两臂隐藏断言逐格完全相同（`off` 2038/2038、默认 2037/2038，唯一差的是一格 21/22），这是**断言对等**，不是「零质量损失」。逐家族稳定性与符号检验见 [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 步停止”。结束由任务状态和完成证据决定 —— 同一份产物上逐字重复一条已通过的检查，建议复用结果、把这一步留给剩下的工作；连续几步没有新结果，建议换方法（只是提醒，不结束回合）；工具卡住，看门狗取消它并等它真正停下。任务做完就正常报告，提醒不会替你判停。
 
-**1.5.1 干净重基线（10 家族、30 个完整单元、隐藏测试 60/60 全绿）**：不剔任何运行（只看产物里有没有泄漏标记）、按整任务总量加总 —— 关闭 **3434.7 s / 591 244 token / 390 步**；默认臂 **0.72× 耗时 / 0.74× 输出 / 0.71× 步数**；逐格中位 **0.64×**、均值 0.84×、90 % 区间 [0.59, 0.79]。收益集中在反复重跑同一条检查的任务（`migrate` 0.45×、`shellops` 0.57×、`codebase` 0.55×、`stategraph` 0.64×、`ledger` 0.64×）；短任务收益不稳定，`perfrefactor` 1.18×、`csvpipe` 1.12×、`debugfix` 输出反而 2.01×——短任务本来就没有可省的重复验证，提醒本身也是成本。这一轮同时修掉了两个会让旧数字失真的测量缺陷（运行目录曾在仓库内、指标曾按字节偏移切片），旧口径的 `0.86×` 已撤回，详见 [BENCHMARK.md](BENCHMARK.md) 的「1.5.1」与「1.5.0 重基线（已撤回）」。
+**1.5.1 干净重基线（10 家族、30 个完整单元、隐藏测试 60/60 全绿；这三块后来被认为挑块，只作历史记录，对外只用上面的全池 0.823×）**：不剔任何运行（只看产物里有没有泄漏标记）、按整任务总量加总 —— 关闭 **3434.7 s / 591 244 token / 390 步**；默认臂 **0.72× 耗时 / 0.74× 输出 / 0.71× 步数**；逐格中位 **0.64×**、均值 0.84×、90 % 区间 [0.59, 0.79]。收益集中在反复重跑同一条检查的任务（`migrate` 0.45×、`shellops` 0.57×、`codebase` 0.55×、`stategraph` 0.64×、`ledger` 0.64×）；短任务收益不稳定，`perfrefactor` 1.18×、`csvpipe` 1.12×、`debugfix` 输出反而 2.01×——短任务本来就没有可省的重复验证，提醒本身也是成本。这一轮同时修掉了两个会让旧数字失真的测量缺陷（运行目录曾在仓库内、指标曾按字节偏移切片），旧口径的 `0.86×` 已撤回，详见 [BENCHMARK.md](BENCHMARK.md) 的「1.5.1」与「1.5.0 重基线（已撤回）」。
 **复现块 W5（2026-10-26，19 个完整单元）**：同一块里三臂直接对照，`off` 1855.5 s，默认臂 0.73× 耗时 / 0.77× 输出 / 0.89× 步数，与 1.5.1 的 0.72× 一致。同块的 `batchVerify` 臂记到 0.84×，但那一臂的提醒**实际一次都没下发**（20 个会话逐条检索命中 0），所以 `batchVerify` 当时是**未测**、不是变慢也不是被证伪。**后来修好接线重测，结论是淘汰**：`codeimpl` 8 对几何 1.478×、`shellpipeline` 8 对 0.956×，合并 16 对 **1.188×**、中位 1.148×、只有 7/16 更快，全绿且提醒确实下发（8/16 会话命中）—— 所以不是没测到，是家族方向不一致、合起来更慢，默认保持 `false`，见 [BENCHMARK.md](BENCHMARK.md) 的「`batchVerify` 复测块 BV8」。这一块还有 1 行泄漏（`shellpipeline` p1 的 `bv15` 读到隐藏测试与参考解），已点名剔除；跑批器现在开跑前会把 `hidden/`、`ref/` 置为不可读，详见 [BENCHMARK.md](BENCHMARK.md) 的「复现块 W5」与 [bench/README.md](bench/README.md) 协议第 12 条。
 **筛选块 W10 + 复现块 W11（2026-10-26，合并 23 个有效单元）：`workspaceMap` 只兑现一半，默认关闭。** 1.5.2 加了一个默认关闭的旋钮：会话第一次动手前，把工作目录的清单（深度 2、≤60 条、跳过依赖与构建目录）先交给模型一次，省掉它自己 `ls`/`find` 的那一步。两块同块对照 `def15`：合并 23 个单元 **耗时 0.927×、输出 0.896×、步数 1.099×**，逐格中位 0.791×、13/23 格更快、隐藏测试零红。方向被证实一半——输出确实少 10 %（两块分别是 0.90×、0.89×）；但步数反而多 10 %，而且尾部变差：两臂 p90 是 559 s 对 369 s、最慢 714 s 对 510 s，W10 与 W11 都出现同一形状的反向格（`stategraph` 两轮都 1.4×–1.77×）。**按「长任务不能变慢」的门槛它不进默认**，1.5.2 的默认行为与 1.5.1 完全相同，旋钮与数字一起公开。这一轮同时把余量算清了：重复验证只占 6 % 耗时、工具结果中位 1.2 kB、重复写文件占 0.8 %，所以 **0.67× 在「不动 `reasoningEffort`、不加请求字段」的约束内不可达**，细节见 [BENCHMARK.md](BENCHMARK.md) 的「复现块 W11」与「0.67× 在现有约束下的可达性」。