@modusensus/dsh-mneme 0.9.5 → 0.10.0

package/test/client.test.js

@@ -2312,6 +2312,39 @@ test("skipped reasons are visible without expanding the collapsed detail section
   assert.ok(!dreamCards.includes("skippedReasons"),
     "the collapsed card no longer needs its own copy of the skip buckets");
 });
+
+// #495：organize 与巩固共用 dream_runs，一次 agent 主动整理写两行。这张卡的标题是
+// 「最近巩固」，若面板继续拿 lastRun 取数，一次整理就把卡面变成整理回执——正是
+// issue 报的那个现象。锁三件事：① 卡面读 lastConsolidation；② 退回 lastRun 时必须
+// 先排除 organize（旧服务端没有新键，不能拿 organize 行冒充巩固）；③ KPI 带那块
+// 「上一轮跳过什么」同样改读巩固轮，organize 的 skipped 不是巩固决策。
+test("dream status card reads the consolidation run, not whatever ran last (issue #495)", () => {
+  const dreamCards = clientSource.slice(
+    clientSource.indexOf("function DreamStatusCards("),
+    clientSource.indexOf("function InjectStatusCard(")
+  );
+  assert.ok(dreamCards.includes("state.lastConsolidation"),
+    "the card must consume lastConsolidation from /dream-status");
+  assert.ok(dreamCards.includes('state.lastRun.run_type === "organize"'),
+    "falling back to lastRun must still refuse an organize row — an old server may omit the new key");
+  assert.ok(/const run = state\.lastConsolidation\s*\n?\s*\|\| \(state\.lastRun && !organizedOnly/.test(dreamCards)
+    || dreamCards.includes("|| (state.lastRun && !organizedOnly"),
+    "the fallback branch must skip the row it just identified as organize");
+  // 脚注：最近一次后台运行确实是 organize 时点名它，而不是静默把它当巩固。
+  assert.ok(dreamCards.includes("memory.status.dreamOrganizeOnly"),
+    "an organize-only history must be named in a footnote, not shown as a consolidation");
+  // ① 的取数还必须晚于本卡自己那次 fetch，不能只是把键名写进注释里。
+  const fetchIdx = dreamCards.indexOf('apiFetch("/api/dsh-mneme/dream-status")');
+  const useIdx = dreamCards.indexOf("state.lastConsolidation");
+  assert.ok(fetchIdx >= 0 && useIdx > fetchIdx, "the key must be read from the /dream-status payload");
+
+  const tokenFlow = clientSource.slice(
+    clientSource.indexOf("function TokenFlowSection("),
+    clientSource.indexOf("function DreamStatusCards(")
+  );
+  assert.ok(tokenFlow.includes("d.lastConsolidation || d.lastRun"),
+    "the skip-reason KPI belongs to consolidation; organize skipped buckets would read as blocked consolidation");
+});
 // 设置页目录（#518）：用户要的是「左侧一个分类，直接跳到某一节」。这里锁五件事：
 // ① 目录由 tocGroups 一张表生成，五项分组标题全部走 groupHead(key) 渲染——两处各写
 //    一遍清单是这类索引最典型的腐烂方式，而腐烂后的目录会把人领到不存在的锚点；
@@ -2395,4 +2428,186 @@ test("minimal preset notice reaches the settings page, not just the status tab (
   assert.ok(!/minimalWarn\s*=\s*true/.test(clientSource), "the notice must never be hard-wired on");
 });
 
+// --- 移动端适配（mobile-adapt 车道）---
+// 面板在 320–430px 容器里原本是「骨架级失衡」而不是「略挤」：记忆页左栏固定
+// 216px、卡片最小轨道 252+48=300px，要 ≥517px 才排得下；实体页 rail 224px +
+// 属性网格 200+48=248px，要 ≥473px。目标区间上沿只有 430，靠收窄数值永远追
+// 不上，所以适配必须换骨架（row → column）而不是继续动宽度。
+// 下面这组锁防三类回归：
+// ① 有人把新规则写成 @media——面板有两种形态（overlay 弹层与 better-sidebar
+//    工作台 tab），容器宽度与视口宽度并不相等，@media 只在 overlay 形态对，
+//    tab 形态会整块失效；
+// ② 有人在双花括号块里写 color —— contrast.test.js 的规则提取器按单层花括号
+//    匹配，\`@container{...{...}}\` 整串不匹配会被跳过，等于绕过 #178 的 AA 主锁
+//    （静默失效，比写错颜色更糟）；\`background\` 同理，它是合成对比度的基底；
+// ③ 有人删掉 \`min(...,100%)\` 的最小轨道下限——只要容器比轨道窄，网格就会横向
+//    溢出，而外层 .mneme-xcontent 是 overflow:hidden，溢出部分直接被切掉。
+test("mobile: the narrow-container breakpoints reflow the two-column skeletons instead of shrinking numbers", () => {
+  const cssStart = clientSource.indexOf("const css = [");
+  const cssEnd = clientSource.indexOf('].join("\\n");', cssStart);
+  assert.ok(cssStart > 0 && cssEnd > cssStart, "lib/client.js 里找不到 CSS 数组（切片锚点变了？）");
+  const cssBlock = clientSource.slice(cssStart, cssEnd);
+
+  // 断点表只许三档：640（原收窄档，数值不动）、480（本轮主断点）、360（图标/内边距）。
+  for (const max of ["480px", "360px"]) {
+    assert.ok(
+      cssBlock.includes("@container (max-width: " + max + "){"),
+      "@container (max-width: " + max + ") 必须存在——" + max + " 是移动端骨架换向档，删了就等于整套适配没生效"
+    );
+  }
+  // 480 是主断点：记忆页与实体页都要换向，且 rail/xside 满宽、限高、可滚。
+  const c480 = /@container \(max-width: 480px\)\{([\s\S]*?)\}\*?\*?\s*",/.exec(cssBlock);
+  assert.ok(c480, "480 档规则必须是一条完整的 CSS 字符串（单行，便于本测试切片）");
+  const body = c480[1];
+  for (const sel of [".mneme-xmain{flex-direction:column}", ".mneme-ent{flex-direction:column}"]) {
+    assert.ok(body.includes(sel), "480 档必须让 " + sel + " —— 左右分栏在窄容器里只能改上下");
+  }
+  assert.ok(/\.mneme-xside\{[^}]*width:100%/.test(body), "记忆页左栏在窄容器里必须满宽");
+  assert.ok(/\.mneme-xside\{[^}]*max-height:min\(/.test(body),
+    "记忆页左栏必须限高可滚：6 段筛选集群在 320px 下自然高 260–320px，不限高会把主区挤成 0");
+  assert.ok(/\.mneme-entrail\{[^}]*width:100%/.test(body), "实体页 rail 在窄容器里必须满宽");
+  assert.ok(/\.mneme-entrail\{[^}]*max-height:min\(/.test(body), "实体页 rail 必须限高可滚");
+  // 换向之后这两条 rail 是「限高」的，限高必须能真收缩：flex:none 在矮工作区里
+  // 不肯让位——42vh 只是上限、不是需求，可 flex:none 让它按内容撑满，主区被
+  // .mneme-xmain 的 overflow:hidden 直接裁成 0 高（CodeRabbit #542）。改成可收缩
+  // 的 flex:0 1 auto 后，min-height:0 才允许它压到上限以下。
+  for (const sel of [".mneme-xside", ".mneme-entrail"]) {
+    assert.ok(new RegExp("\\" + sel + "\\{[^}]*flex:0 1 auto").test(body),
+      sel + " 在窄容器里必须可收缩（flex:0 1 auto），flex:none 会在矮视口里把主区挤没");
+    assert.ok(new RegExp("\\" + sel + "\\{[^}]*min-height:0").test(body),
+      sel + " 必须带 min-height:0，否则 flex 项的内容高度下限会让收缩失效");
+  }
+  // overscroll-behavior 不继承，只能写在真正的滚动容器上：.mneme-entrail 的 base 规则
+  // 是 overflow:hidden（lib/client.js:2042），滚动的是内层 .mneme-entrailbody
+  // （lib/client.js:2046 的 overflow-y:auto）。写在 rail 上等于没写，触屏滚到底会
+  // 串到外层（Copilot #542）。.mneme-xside 的 base 本身是滚动容器，写在它身上对。
+  assert.ok(/\.mneme-entrailbody\{[^}]*overscroll-behavior:contain/.test(body),
+    "滚动链的 overscroll-behavior 必须写在 .mneme-entrailbody（真滚动容器）上，写在 .mneme-entrail 上无效");
+  assert.ok(!/\.mneme-entrail\{[^}]*overscroll-behavior/.test(body),
+    ".mneme-entrail 是 overflow:hidden 的非滚动容器，overscroll-behavior 写在它身上是死代码");
+  // 抽屉是覆盖层，窄容器里 52% 只剩 166px；满宽不丢关闭入口（✕ 在 .mneme-drawerbar）。
+  assert.ok(body.includes(".mneme-drawer{width:100%}"), "详情抽屉在窄容器里必须满宽");
+  // 网格轨道的 100% 下限不再锚定在本档：它的作用域是「所有宽度」，而 481–519px
+  // （480 主断点之上、两栏又排不下的中间带）恰恰落回基础规则。锁在基础规则上，
+  // 见本用例末尾的 topLevel 那组。本档只保留窄屏特有的 padding 与滚动链。
+  // 固定宽弹层在 320px 会顶边：340px 的分享弹层比视口还宽。
+  assert.ok(/\.mneme-sharedialog\{[^}]*calc\(100cqw - 32px\)/.test(body), "分享弹层宽度必须跟着容器收");
+  assert.ok(/\.mneme-impdialog\{[^}]*calc\(100cqw - 32px\)/.test(body), "导入弹层宽度必须跟着容器收");
+  // 页签的横向滚动必须住在 480 主断点，而不是 360 兜底档：4 个带图标的 tab 约 436px，
+  // 而 480 档给 .mneme-xbar 的可用宽度是容器宽减 62px（左 10 + 右 52 让位给绝对定位
+  // 的 ⋯），480px 时只剩 418px——整段 361–480px 都会把页签顶到 ⋯ 底下。写错档位的
+  // 失败形态最难查：窄屏照样溢出，而只锁「360 档有这条规则」的测试全绿。
+  assert.ok(/\.mneme-vtabs\{[^}]*min-width:0[^}]*overflow-x:auto/.test(body),
+    "页签横向滚动属于 480 档：只在 360 档兜底等于把溢出留在主断点的整个区间");
+  // 三处窄屏宽度都得带 box-sizing:border-box：全文件没有 *{box-sizing} 兜底，声明的
+  // 那个数是内容宽，外宽还要再加 padding+border——impdialog +30px、menu +12px，320px
+  // 视口下比屏幕还宽，会被 overlay 裁掉。CodeRabbit 只点了 sharedialog，另两处同病。
+  for (const sel of ["menu", "impdialog", "sharedialog"]) {
+    assert.ok(new RegExp("\\.mneme-" + sel + "\\{[^}]*box-sizing:border-box").test(body),
+      ".mneme-" + sel + " 的窄屏宽度必须按外宽算（box-sizing:border-box），否则声明值加完 padding+border 就溢出容器");
+  }
+
+  // .mneme-overlay 不在 .mneme-x 之内，容器查询够不到它——它只能走 @media，
+  // 且必须保留基线声明（client.test.js 上有 width:min(1240px,calc(100vw - 88px)) 的锁）。
+  assert.match(cssBlock, /@media \(max-width: 640px\)\{\.mneme-overlay\{/,
+    ".mneme-overlay 是容器查询够不到的祖先，它的移动端外框必须用 @media 覆盖");
+
+  // ② 双花括号块内不得出现颜色声明（见文件头注释的失效机制）。
+  const nested = [...cssBlock.matchAll(/@(?:container|media)[^{]*\{/g)];
+  assert.ok(nested.length >= 4, "移动端适配应当新增 ≥4 条 @container/@media 规则（当前 " + nested.length + "）");
+  for (const m of nested) {
+    const at = m.index + m[0].length;
+    let depth = 1, i = at;
+    while (i < cssBlock.length && depth > 0) {
+      if (cssBlock[i] === "{") depth++;
+      else if (cssBlock[i] === "}") depth--;
+      i++;
+    }
+    const inner = cssBlock.slice(at, i - 1);
+    const hit = /(?:^|[;{])\s*(color|fill|stroke|background(?:-color)?)\s*:/.exec(inner);
+    assert.equal(hit, null,
+      "@container/@media 块内不得写颜色（" + (hit && hit[1]) + "）：contrast.test.js 的单层花括号提取器会整串跳过该块，" +
+      "写进去的色值不会被 AA 主锁审计——这是静默绕过 #178，不是优化");
+  }
+
+  // 触屏没有 hover：设置页删除钮必须常显（#457/#459 两次回滚都是因为连带改了 hover 配色，
+  // 这里只许加 opacity:1，不许在同一条里再动 color）。
+  assert.match(cssBlock, /@media \(hover:none\)\{\.mneme-set-del\{opacity:1/,
+    "触屏设备上 .mneme-set-del 必须常显——它的 base 是 opacity:0，只靠 :hover 恢复，手机上等于永久不可见");
+  // 断点之外还有一段中间带：481–519px 容器宽（480 主断点之上、两栏又排不下）。
+  // 这一段落回基础规则，所以 min(…,100%) 的轨道下限必须写在基础规则上，只在断点里
+  // 写等于给中间带留缺口。本组锁都作用在「剥掉嵌套块之后的顶层规则」上——否则
+  // 480 档里的同名声明会让断言假绿。
+  const topLevel = (() => {
+    let out = "";
+    let i = 0;
+    while (i < cssBlock.length) {
+      const at = cssBlock.indexOf("@", i);
+      out += cssBlock.slice(i, at === -1 ? cssBlock.length : at);
+      if (at === -1) break;
+      const open = cssBlock.indexOf("{", at);
+      if (open === -1) { out += cssBlock.slice(at); break; }
+      let depth = 0, j = open;
+      while (j < cssBlock.length) {
+        if (cssBlock[j] === "{") depth++;
+        else if (cssBlock[j] === "}") { depth--; if (depth === 0) { j++; break; } }
+        j++;
+      }
+      i = j;
+    }
+    return out;
+  })();
+  assert.ok(topLevel.length > 10000, "顶层规则切片异常（" + topLevel.length + " 字符）——切片实现坏了，下面的锁会假绿");
+  assert.match(topLevel, /\.mneme-cards\{[^}]*minmax\(min\(252px,100%\),1fr\)/,
+    "卡片网格的 100% 轨道下限必须写在基础规则上：481–519px 是 480 主断点之外的中间带，" +
+    "只在断点里兜底等于让这一段横向溢出 2–11px（外层 overflow:hidden 直接切掉）");
+  assert.match(topLevel, /\.mneme-attrgrid\{[^}]*minmax\(min\(200px,100%\),1fr\)/,
+    "属性网格同理：481–519px 时实体页 detail 只剩 257–276px，裸 200px 下限会溢出");
+  // 图谱的 touch-action 保持 none（这里是从 pan-y 回退后补的锁）。pan-y 那一版想解决
+  // 「手指在图上竖划时页面滚不动」，但它同时把纵向手势交给浏览器做页面平移，而图谱的
+  // 拖拽只挂了 mousedown/mousemove（全仓 onPointerDown/onTouchStart 命中 0）——触屏上
+  // 纵向拖拽到底走哪条路，浏览器是否派发兼容鼠标事件，没有真机无法定论。宁可保留现状
+  // 也不做无法复验的行为变更；真要两步都能用，得改成 Pointer Events，另开车道。
+  assert.match(topLevel, /\.mneme-graphsvg\{[^}]*touch-action:none/,
+    "图谱的 touch-action 必须写在基础规则上：481–519px 这段中间带落回基础规则，" +
+    "只在断点里声明等于给中间带留缺口");
+  assert.doesNotMatch(topLevel, /\.mneme-graphsvg\{[^}]*touch-action:pan-y/,
+    ".mneme-graphsvg 不得改回 touch-action:pan-y —— 纵向手势会被浏览器拿去滚页面，" +
+    "而图谱的拖拽只有鼠标事件实现，触屏拖拽行为无真机无法验证（见上方注释）");
+});
+
+// Issue #512：面板详情抽屉要能说清「这条记忆是从哪来的」。
+//
+// 归因分两层：窗口级（哪一段原文蒸出来的）与行级（哪一轮铸造的）。这两层
+// 任何一层缺失都必须显示成「没有归因」，而不是让用户看到空白以为自己眼花了。
+test("memory drawer surfaces distillation provenance, both layers (issue #512)", () => {
+  for (const key of [
+    "memory.explorer.detail.provenance",
+    "memory.explorer.detail.provenanceEmpty",
+    "memory.explorer.detail.provenanceMint",
+    "memory.explorer.detail.provenanceWindow",
+    "memory.explorer.detail.provenanceNoRun",
+    "memory.explorer.detail.provenanceRecords"
+  ]) {
+    // 只数字典定义处（"key": 形态）——键在渲染里还会被 t("…") 再引一次，
+    // 数全量出现次数会把两种用法混为一谈。
+    const defined = clientSource.split(`"${key}":`).length - 1;
+    assert.equal(defined, 2, `i18n key ${key} must be defined exactly once in zh and once in en (got ${defined})`);
+  }
 
+  // 必须真的去读那一个端点，且是读不是算——归因的判据只有后端一处。
+  assert.ok(clientSource.includes("/api/dsh-mneme/memory/provenance?id="),
+    "the drawer must fetch the provenance endpoint");
+  // 两层都要渲染：只渲染窗口会让铸造出来的 pattern 永远显示「没有来源」，
+  // 而它们恰恰是归因最该说清的一类（没有会话区间可看）。
+  // 断到 .map( 为止：只写 "provenance.mints" 会被空态判断里的 .length 满足，
+  // 于是「渲染被整段删掉」这种回归照样能过（本用例的变异自证就是从这里翻车的）。
+  assert.ok(clientSource.includes("provenance.mints.map("), "mint-level attribution (which run minted the row) must render");
+  assert.ok(clientSource.includes("provenance.windows.map("), "window-level attribution (which transcript) must render");
+  assert.ok(clientSource.includes("\"memory.explorer.detail.provenanceNoRun\""),
+    "a legacy link without a run id must say so explicitly, not render an empty cell");
+
+  // 读失败要落回「没读到」而不是伪造一份空归因：两者在界面上是不同的话。
+  assert.ok(clientSource.includes("/api/dsh-mneme/memory/provenance?id=") && clientSource.includes("setProvenance(null)"),
+    "a failed read must clear the block instead of pretending there is no attribution");
+});

package/test/config.test.js

@@ -4,6 +4,14 @@ import { readFileSync } from "node:fs";
 import { fileURLToPath } from "node:url";
 import { Config } from "../src/config.js";
 
+test("session incognito is opt-in, with a default-on subordinate selector", () => {
+  const cfg = Config({});
+  assert.equal(cfg.sessionGateEnabled, false);
+  assert.equal(cfg.sessionGateSubagents, true);
+  assert.deepEqual(cfg.sessionGateSessions, []);
+  assert.deepEqual(Config({ sessionGateSessions: ["s1", "s2"] }).sessionGateSessions, ["s1", "s2"]);
+});
+
 // ---------------------------------------------------------------- rerank opt-in (item ⑥)
 
 test("rerank is opt-in: default config does not enable the local reranker", () => {

package/test/conflict-reviewed.test.js

@@ -0,0 +1,79 @@
+import test from "node:test";
+import assert from "node:assert/strict";
+import { createStore } from "../src/store.js";
+
+// Issue #529（B 项）：冲突裁决台账（conflict_reviewed）的存储层契约。
+//
+// 为什么单开一张表而不是复用 conflict_pending：后者是**人工**队列——面板徽标数
+// 就是 countConflictPending()（resolved_at IS NULL 的行数），机器每判一对就写一行
+// 会把那个数字淹掉，人再也看不出"有哪些待我裁决"。台账是机器记账，零用户界面。
+//
+// 这些用例锁三件事，防的回归是：
+//   ① pair 键不归一化 → 同一对（A,B）与（B,A）会记成两行，下一轮照样重送；
+//   ② 重复记账不是幂等 upsert → 同一对判过 N 次就堆 N 行，表无界增长；
+//   ③ 记账误落 conflict_pending → 人工队列被机器行淹没（这是最贵的一种）。
+
+test("issue#529 conflict_reviewed：写入后可读回，键归一化为 (a,b)", () => {
+  const store = createStore(":memory:");
+  store.saveConflictReviewed({
+    run_id: "run-1",
+    memory_a: "b-id",
+    memory_b: "a-id",
+    outcome: "conflict",
+    judged_at: "2026-10-31T00:00:00.000Z"
+  });
+  const all = store.loadConflictReviewed();
+  assert.equal(all.size, 1, "只落一行");
+  const key = [...all.keys()][0];
+  assert.equal(key, "a-id\u0000b-id", "键按字典序归一化——反着传也是同一个键");
+  const row = all.get(key);
+  assert.equal(row.outcome, "conflict");
+  assert.equal(row.run_id, "run-1");
+  assert.equal(row.judged_at, "2026-10-31T00:00:00.000Z");
+  store.close();
+});
+
+test("issue#529 conflict_reviewed：同一对重复记账是 upsert，不堆行", () => {
+  const store = createStore(":memory:");
+  for (let i = 0; i < 3; i++) {
+    store.saveConflictReviewed({
+      run_id: "run-" + i,
+      memory_a: "a-id",
+      memory_b: "b-id",
+      outcome: "keep",
+      judged_at: "2026-10-31T00:00:0" + i + ".000Z"
+    });
+  }
+  const all = store.loadConflictReviewed();
+  assert.equal(all.size, 1, "同一对只留一行");
+  assert.equal(all.get("a-id\u0000b-id").run_id, "run-2", "后写的覆盖先写的");
+  assert.equal(all.get("a-id\u0000b-id").judged_at, "2026-10-31T00:00:02.000Z");
+  store.close();
+});
+
+test("issue#529 conflict_reviewed：记账不进人工待裁决队列", () => {
+  const store = createStore(":memory:");
+  for (let i = 0; i < 5; i++) {
+    store.saveConflictReviewed({
+      run_id: "run-" + i,
+      memory_a: "a-" + i,
+      memory_b: "b-" + i,
+      outcome: "keep",
+      judged_at: "2026-10-31T00:00:00.000Z"
+    });
+  }
+  assert.equal(store.countConflictPending(), 0, "关键：机器记账不涨人工队列的徽标数");
+  assert.deepEqual(store.listConflictPending(), []);
+  assert.equal(store.listConflictReviewed().length, 5, "但台账里确实有 5 行");
+  store.close();
+});
+
+test("issue#529 conflict_reviewed：listConflictReviewed 按判时倒序", () => {
+  const store = createStore(":memory:");
+  store.saveConflictReviewed({ memory_a: "a", memory_b: "b", outcome: "keep", judged_at: "2026-10-30T00:00:00.000Z", run_id: "r1" });
+  store.saveConflictReviewed({ memory_a: "c", memory_b: "d", outcome: "conflict", judged_at: "2026-10-31T00:00:00.000Z", run_id: "r2" });
+  const rows = store.listConflictReviewed();
+  assert.equal(rows[0].judged_at, "2026-10-31T00:00:00.000Z", "最新的在前");
+  assert.equal(rows[1].judged_at, "2026-10-30T00:00:00.000Z");
+  store.close();
+});

package/test/continuity.test.js

@@ -7,6 +7,7 @@ import { createStore } from "../src/store.js";
 import { createService } from "../src/service.js";
 import { createTools } from "../src/tools.js";
 import { Config, applyLightModePreset, injectChildEnabled } from "../src/config.js";
+import { createSessionGate } from "../src/session-gate.js";
 import {
   CONTINUITY_KIND,
   CONTINUITY_NOTICE_PREFIX,
@@ -272,7 +273,7 @@ test("#249 N3：门控不调模型（静态锁）与挂载点的父开关在前"
   // 只剩 Config 里的默认值撑着，接线漏一次没人发现。
   const index = readFileSync(new URL("../src/index.js", import.meta.url), "utf8");
   assert.match(index, /if \(cfg\.autoInject && injectChildEnabled\(cfg, "continuityRescueEnabled"\)\) \{/);
-  assert.match(index, /disposers\.push\(createContinuityRescue\(ctx, store\)\)/);
+  assert.match(index, /disposers\.push\(createContinuityRescue\(ctx, store, sessionGate\)\)/);
 });
 
 test("#249 N3：reject 放行且不消费边缘；缺 session 不抛", async () => {
@@ -295,6 +296,33 @@ test("#249 N3：reject 放行且不消费边缘；缺 session 不抛", async ()
   rescue.dispose();
 });
 
+test("#539：等待 pre-step 期间切到无痕会清除先前边缘，不落提案也不注入", async () => {
+  const store = createStore(":memory:");
+  const ctx = mockCtx();
+  const config = { sessionGateEnabled: false, sessionGateSessions: ["s1"] };
+  const gate = createSessionGate(config);
+  const rescue = createContinuityRescue(ctx, store, gate);
+  const session = fakeSession("s1", [userEvent(1, "私有指令")]);
+
+  ctx.fire("session/event", session, { type: "compaction/end", seq: 7 });
+  const decision = await ctx.fire(
+    "agent/pre-step",
+    { agent: { session } },
+    async () => {
+      config.sessionGateEnabled = true;
+      await Promise.resolve();
+      return { kind: "enter", messages: [] };
+    }
+  );
+  assert.deepEqual(decision.messages, []);
+  assert.equal(store.getContinuityProposal("s1", KIND), null);
+
+  config.sessionGateEnabled = false;
+  const next = await ctx.fire("agent/pre-step", { agent: { session } }, async () => ({ kind: "enter", messages: [] }));
+  assert.deepEqual(next.messages, [], "a stale edge from before the toggle is not consumed later");
+  rescue.dispose();
+});
+
 test("#249 N3：契约——默认关、父关不生效、轻量档压掉、降级规则只在开启时进描述", () => {
   assert.equal(Config({}).continuityRescueEnabled, false, "新增注入表面 → opt-in 默认关");
   assert.equal(applyLightModePreset({ lightMode: true }).continuityRescueEnabled, false, "轻量档压掉（同 injectGuidanceEnabled）");

package/test/dependency-overrides.test.js

@@ -0,0 +1,78 @@
+// 两个 overrides 存在的唯一理由是 osv-scanner 的红灯，而红灯的判据是**已提交的
+// lockfile**——所以这里锁的是 lockfile 的解析结果，不是 node_modules 里装了什么。
+// 2026-10-31 的现场：同一条 lockfile 在 08:36 是绿的，04:42 那次 push 却是红的，
+// 中间没有任何依赖变更——上游在 23:09 发了两条新公告（glob 超时后仍继续遍历、
+// minimatch globparts 放大 DoS）。换句话说，这个文件里的断言会**因为上游多一条公告
+// 而变红**，那是它应该做的事：红在本地，比红在 main 上便宜。
+//
+// 依赖链只有一条，且全部是 devDependency：
+//   c8@12 → test-exclude@8 → glob + minimatch
+// 两个上游包都已经是 npm 上的最新版、其 deps 仍写旧范围，所以只能在本仓库抬 pin。
+// 一旦上游跟上、这条链不再解析到旧版本，下面的 overrides 断言就会失败——那时应当
+// 删掉这两条 overrides，而不是把断言删掉。
+import test from "node:test";
+import assert from "node:assert/strict";
+import { readFileSync } from "node:fs";
+import { dirname, join } from "node:path";
+import { fileURLToPath } from "node:url";
+
+const PKG_ROOT = join(dirname(fileURLToPath(import.meta.url)), "..");
+const pkg = JSON.parse(readFileSync(join(PKG_ROOT, "package.json"), "utf8"));
+const lock = JSON.parse(readFileSync(join(PKG_ROOT, "package-lock.json"), "utf8"));
+
+// 公告给出的修复下限。低于它 = osv-scanner 会在 main 上红，这里先红。
+const FLOORS = {
+  glob: { fixed: [14, 0, 2], cve: "CVE-2026-118773 / GHSA-3g3m-2fjr-6pw4" },
+  minimatch: { fixed: [11, 0, 1], cve: "CVE-2026-118764 / GHSA-g3hv-75wg-m249" },
+};
+
+function parseVersion(v) {
+  return String(v).split(/[.+-]/).slice(0, 3).map((n) => Number.parseInt(n, 10) || 0);
+}
+
+function gte(a, b) {
+  for (let i = 0; i < 3; i++) {
+    if (a[i] !== b[i]) return a[i] > b[i];
+  }
+  return true;
+}
+
+test("glob 与 minimatch 在 lockfile 里都解析到公告的修复下限之上", () => {
+  for (const [name, { fixed, cve }] of Object.entries(FLOORS)) {
+    const entry = lock.packages[`node_modules/${name}`];
+    assert.ok(entry, `lockfile 里应当有 node_modules/${name}`);
+    const actual = parseVersion(entry.version);
+    assert.ok(
+      gte(actual, fixed),
+      `${name} 解析成 ${entry.version}，低于 ${cve} 的修复下限 ${fixed.join(".")}——osv-scanner 会在 main 上红`,
+    );
+  }
+});
+
+// overrides 必须是**精确版本**，不能是 ^ / ~ 范围。
+// 范围等于把选择权交回解析器：下一次上游发版，lockfile 会在某个「只更新 lockfile」
+// 的 PR 里悄悄漂走，而红绿灯本该由人决定。brace-expansion 那次（PR #345）就是精确号。
+test("overrides 是精确版本号，不是范围", () => {
+  for (const name of Object.keys(FLOORS)) {
+    const pin = pkg.overrides?.[name];
+    assert.equal(typeof pin, "string", `package.json overrides 里应当钉住 ${name}`);
+    assert.ok(
+      /^\d+\.\d+\.\d+$/.test(pin),
+      `${name} 的 override 应写精确版本（如 14.0.3），实际是 ${JSON.stringify(pin)}`,
+    );
+  }
+});
+
+// 钉版本是权宜之计，不是永久配置：这条链还在（c8 → test-exclude → glob）就说明
+// 上游仍会解析到旧范围，overrides 必须留着。上游哪天收了，这条会红，提示来删 pin。
+test("devDependency 链仍在：c8 → test-exclude → glob", () => {
+  const c8 = lock.packages["node_modules/c8"];
+  assert.ok(c8, "lockfile 里应当有 c8");
+  assert.ok(c8.dependencies?.["test-exclude"], "c8 仍应依赖 test-exclude");
+  const testExclude = lock.packages["node_modules/test-exclude"];
+  assert.ok(testExclude, "lockfile 里应当有 test-exclude");
+  assert.ok(
+    testExclude.dependencies?.glob,
+    "test-exclude 仍应依赖 glob——它一旦不再依赖，glob/minimatch 两条 overrides 就可以删了",
+  );
+});