dsh-fast-mode 1.5.31 → 1.5.32

package/BENCHMARK.md

@@ -2367,6 +2367,31 @@ python3 bench/ablate.py --ci 2000 --anchor def15       # 相对默认配置（
 
 **这张表的两个诚实边界**：不同臂覆盖的任务组合不同（跑一遍命令就能看到 `tasks` 列，`d2` 含 `codeimpl:8`、`map15` 只有 `codebase/debugfix/perfrefactor`），所以行与行之间不能直接排大小；以及每个块只采样一次，`n < 20` 的行只算方向提示。
 
+## 直接跑一次「多个开关一起开」：三开 **0.669×**（22 对，18 对更快），两开 0.742×
+
+上一节那张消融表是**逐个**开关单独叠在默认上测的，从来没有真的跑过「一起开」的臂，所以「多开几个开关不会更快」只是推理。这一轮补上：把默认之上**唯一三个点估计小于 1** 的可选开关同时打开（`d2g` = 明细律第 2 步 + 第 1 步 ≥2 次调用才提前、`workspaceMap`、`openBatch`），和同块的默认臂按 `(任务, pair)` 配对。
+
+```
+python3 bench/suite-run.py --tasks debugfix,migrate --arms def15,combo2 --pairs 12 --tag COMBO2
+python3 bench/suite-run.py --tasks debugfix,migrate --arms def15,combo3 --pairs 6  --tag COMBO3
+```
+
+`combo2` = 默认 + `d2g` + `workspaceMap` + `openBatch`；`combo3` = 默认 + `workspaceMap` + `openBatch`（不含时点类臂，用来分清增益是不是全来自那条提醒时点）。
+
+| 臂 | n | wall 几何比 | CI95（bootstrap 5 000） | 中位 | 更快 | 符号 p | 步数中位 | 输出中位 | 隐藏测试 |
+|---|---|---|---|---|---|---|---|---|---|
+| `combo2`（三开） | 22 | **0.669** | **[0.554, 0.799]** | 0.687 | **18/22** | **0.0022** | 7 → 6.5 | 6 770 → 4 957（−27 %） | 22/22 绿 |
+| `combo3`（两开，无时点臂） | 11 | 0.742 | [0.594, 0.909] | 0.884 | 8/11 | 0.113 | 8 → 7 | 6 223 → 6 497（+4 %） | 11/11 绿 |
+
+分族（`combo2`）：`debugfix` 12 对 **0.766×**（10/12 更快）、`migrate` 10 对 **0.567×**（8/10 更快）。两族方向一致，没有 `d2` 那种「一开就反」的家族。
+
+读法，以及它和上一节的矛盾怎么算：
+
+- **叠加是真的有效，不是推理出来的。** 单个开关各自只有 0.80–0.88 且 CI 跨 1（`map15` 23 对 0.802、`open15` 53 对 0.882、`d2g` 27 对 0.816），三个一起开 22 对 CI 上限 **0.799 < 1**、符号检验 p = 0.0022。单个都测不出显著，合起来能测出，说明增益不在任何一个开关本身，而在它们**减少的是同一类东西的不同份**：少开的文件、少来回的读、少写的散文——每一份单独都不足以顶穿 ±20 % 的单轮噪声。
+- **但别把它读成「把开关都打开就好」。** 表里 `bv15`、`pp16`、`bud8`、`wide15`、`nodisc` 单独叠都是 0.96–1.10，没有理由相信它们进组合会变好；这一轮只验了上面三个。
+- **时点臂仍在 HOLD，不进默认。** `combo2` 比 `combo3` 多出来的那一截（0.669 vs 0.742）指向 `d2g`，但两个臂的样本不是同一批 pair，n = 22 vs 11 也不足以给「多 7 个百分点」定论；`d2g` 在 `codeimpl` 上的负收益（见上一节结论 2）没有被这一轮推翻，默认仍是 `disciplineAfterSteps: 4`。
+- **诚实边界**：各一个块、两个任务族（`debugfix` 短、`migrate` 长），`combo3` 的符号检验 p = 0.113 只算方向提示；锚点臂有 2 格（`migrate` pair 2、11）判 `leak` 被剔除，剔除后仍配对 22 对，`combo2` 24 格全绿、无一格 `leak`。想复现就重跑上面两条命令，`bench/arms/combo2.yml`、`combo3.yml` 在仓库里。
+
 ## 同一配置再跑一遍会差多少：块级差 4 %，任务级差 15–31 %（REP2，10 对）
 
 外部评审提的第一条是稳定性。这一块不新增任何开关，只把 `migrate`+`debugfix` 的同一批格子**用同一套配置再跑一遍**（`REP2`，20 次运行，顺序 ABBA 与之前的块一致），看同配置的两次独立测量互相差多少：

package/CHANGELOG.md

@@ -1,5 +1,15 @@
 # Changelog
 
+## 1.5.32（先回答「多个开关一起开」：三开 **0.669×**、22 对里 18 对更快、隐藏测试 22/22 绿；附带一个内存上限修复）
+
+- **新增两个组合臂并真的跑了一遍**（此前只有逐个开关的消融，从没跑过「一起开」）：`combo2` = 默认 + `d2g` + `workspaceMap` + `openBatch`，`combo3` = 默认 + `workspaceMap` + `openBatch`。同块内与默认臂按 `(任务, pair)` 配对：
+  - `combo2`：22 对，wall 几何 **0.669×**、CI95 **[0.554, 0.799]**、中位 0.687、**18/22 更快**、符号检验 **p = 0.0022**，输出中位 −27 %，步数中位 7 → 6.5，隐藏测试 22/22 绿；
+  - `combo3`（去掉时点臂）：11 对，几何 0.742×、CI95 [0.594, 0.909]、8/11 更快（p = 0.113，方向提示）。
+  - 单开时三个开关各自都测不到显著（0.802 / 0.882 / 0.816，CI 全跨 1），合起来才顶穿噪声——**叠加是真的**，但只验了这三个，其余开关（`batchVerify` / `preferPatch` / 步数预算 / 更宽并行 / 关明细律）单独叠都是 0.96–1.10，没有理由跟着一起开。
+- **默认不变**：`combo2` 比 `combo3` 多出的那一截指向时点臂 `d2g`，但两臂不是同一批 pair、n = 22 vs 11，不足以给「多 7 个百分点」定论；`d2g` 在 `codeimpl` 上的负收益没被推翻，`disciplineAfterSteps` 仍是 4。证据与读法写进 `BENCHMARK.md` 对应新章节。
+- **稳定性修复：`autoBudgets` 加了上限。** 它按会话存自适应超时上限，原来只写不删——长驻宿主进程里每个会话留一格，永不回收。现在与 `compacted` 一样保留最近 200 条（超出丢最旧的）；只有「当前会话下一步」会读它，丢弃旧会话不影响行为。这一条是给长时间运行的宿主用的，不改任何默认值。
+- 只动 `index.js`（8 行）与文档；`src/` 无改动。
+
 ## 1.5.31（`turns.py` 顺手审另一条提醒：压缩后重述规则的那条，会不会无理由地多出来）
 
 - 插件只主动发两条提醒：入场步的「少写散文」（每轮恰好一次）和压缩后的「规则重申」（每次压缩后一次，因为规则可能被裁掉）。`bench/turns.py` 原来只审第一条，第二条只当噪音忽略——如果它的标志位泄漏，就会在每个合格轮里白送一段规则文本。

package/index.js

@@ -97,7 +97,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.31'
+export const VERSION = '1.5.32'
 const GLOBAL_AGENT = '__global__'
 
 /**
@@ -383,7 +383,12 @@ export function apply(ctx, rawConfig) {
   // The scheduler's memory, one entry per conversation: what has been tried, how
   // long calls have been taking, and how many steps went by without a new result.
   const auto = createAutoState()
-  /** Live stall ceilings per conversation, as computed by the scheduler. */
+  /**
+   * Live stall ceilings per conversation, as computed by the scheduler.
+   * Bounded like `compacted`: a long-lived host process sees thousands of
+   * sessions and only the next step of the current one reads a ceiling, so the
+   * oldest entries are dropped instead of kept forever.
+   */
   const autoBudgets = new Map()
   /** @type {Map<string, number>} */
   const startedAt = new Map()
@@ -530,6 +535,7 @@ export function apply(ctx, rawConfig) {
         noteStep(auto, sid)
         notePolicy(auto, sid, cfg)
         const schedule = autoSchedule(auto, sid)
+        if (autoBudgets.size >= 200) autoBudgets.delete(autoBudgets.keys().next().value)
         autoBudgets.set(sid, schedule.stallBudgetMs)
         if (schedule.directive) {
           notices.push(createNoticeMessage(schedule.directive.text, schedule.directive.summary))

package/package.json

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