@modusensus/dsh-mneme 0.10.1 → 0.12.0

package/test/inject-pin-vector-crowd.test.js

@@ -0,0 +1,225 @@
+import test from "node:test";
+import assert from "node:assert/strict";
+import { createStore } from "../src/store.js";
+import { createService } from "../src/service.js";
+import { createVectorIndex } from "../src/vector-index.js";
+
+// 回归（pin 池被向量路封顶饿死）：`injectCandidates` 里 hybrid 分支先把
+// `vectorIndex.search(qv, {limit: poolSize})` 的结果全量 push 进 merged，随后
+// `if (merged.length >= poolSize) break;` 在**pin 筛选之前**就封顶——生产
+// maxItems=5 → poolSize=10，向量路一次正好返回 10 条即 break，规则窗口里那些
+// constraint/preference 一条都进不了 candidates，pin 池只能从这 10 条里筛，
+// 命中几条纯看它们碰巧是什么类型。
+//
+// 代码注释向来自称「pin 不占 maxItems 名额」，实现里却把名额占掉了。实测真库
+// maxItems=5 时 pin shown 只有 2/5，补回后恒 5/5；maxItems=10（poolSize=20）
+// 时前后都是 5/5——所以修法不是多给名额，是把被向量路吃掉的 pin 候选补回来。
+//
+// 修法位置：不在 hybrid 分支之前提前摘（那样会绕过下面 strictScope 与
+// scopeState 两道闸门，而 :1907 的注释明确写着「pin 池 eligible 取自过滤之后的
+// 候选，顺带保证越权行进不了 pin」），而是在合并之后、闸门之前把被甩掉的 pin
+// 类行补回候选池尾部——闸门照旧作用其上。
+//
+// 本文件锁三件事：
+//   ① 向量路把 poolSize 填满时，pin 池照旧拿满预算（缺口本体）
+//   ② 补回的是规则窗口（items）里的 pin，与向量命中集无关——即使查询向量与
+//      pin 条目毫不相干，它们也能进块（这是 pin 的定义：每轮必进）
+//   ③ 预算关时行为逐字节不变
+
+function setup(config = {}) {
+  const store = createStore(":memory:");
+  const service = createService({ store, mirror: null, config });
+  const vectorIndex = createVectorIndex({ store });
+  service.setVectorIndex(vectorIndex);
+  return { store, service, vectorIndex };
+}
+
+// 向量路上与查询完全同向的普通条目：正好填满 poolSize 个名额，且一条都不是 pin 类型。
+function seedVectorCrowd(service, vectorIndex, n) {
+  const ids = [];
+  for (let i = 0; i < n; i++) {
+    const m = service.saveWithDedupe({
+      type: "decision",
+      title: `决定条目${i}`,
+      content: `第 ${i} 条与查询同向的普通决定，不该占掉 pin 的名额`,
+      importance: 5
+    }).memory;
+    vectorIndex.saveEmbedding(m.id, [1, 0, 0]);
+    ids.push(m.id);
+  }
+  return ids;
+}
+
+// 与查询向量正交的 pin 条目：向量路永远检索不到它们，只能靠规则窗口进块。
+function seedPinnedPreferences(service, vectorIndex, n) {
+  const ids = [];
+  for (let i = 0; i < n; i++) {
+    const m = service.saveWithDedupe({
+      type: "preference",
+      title: `硬偏好${i}`,
+      content: `第 ${i} 条约束/偏好，每轮必进，与查询向量正交`,
+      importance: 5
+    }).memory;
+    vectorIndex.saveEmbedding(m.id, [0, 1, 0]);
+    ids.push(m.id);
+  }
+  return ids;
+}
+
+const titlesOf = (list) => list.map((m) => m.title);
+
+test("pin 池不被向量路封顶：poolSize 被填满时仍拿满 pinnedInjectBudget", () => {
+  // maxItems=5 → poolSize=10，与生产默认值一致；预算是 5，满额。
+  const { service, vectorIndex } = setup({
+    maxInjectedItems: 5,
+    pinnedInjectBudget: 5,
+    importanceThreshold: 3
+  });
+  seedVectorCrowd(service, vectorIndex, 10); // 正好 poolSize 条，全是 decision
+  seedPinnedPreferences(service, vectorIndex, 5);
+
+  const pinnedStats = {};
+  const selected = service.injectCandidates({
+    query: "随便问一个与偏好无关的问题",
+    maxItems: 5,
+    queryVector: [1, 0, 0],
+    pinnedStats
+  });
+
+  // 缺口本体的断言：修前这里是 0（向量路 10 条里一条 preference 都没有）。
+  assert.equal(pinnedStats.shown, 5, "pin 池必须拿满预算，不能被向量路的 poolSize 截断");
+  const pinnedTitles = titlesOf(selected).filter((t) => t.startsWith("硬偏好"));
+  assert.equal(pinnedTitles.length, 5, "5 条 pin 必须真的进块（不只是计数对）");
+  // pin 前置在块内：前 5 位必须全是 pin 条目（同 importance/updated_at 的
+  // 同批条目内部次序由 id 决定，不是本用例要锁的东西，故只断言集合）。
+  const head = titlesOf(selected).slice(0, 5);
+  assert.ok(head.every((t) => t.startsWith("硬偏好")), `pin 前置到块内排序之前：${head.join(" / ")}`);
+  assert.deepEqual([...head].sort(), [...pinnedTitles].sort(), "前 5 位就是那 5 条 pin");
+});
+
+test("pin 池取自规则窗口，不取自被封顶的 candidates", () => {
+  // 这条锁的是「怎么修」而不是「修没修」：向量路返回的 10 条与 pin 类型完全
+  // 不相交，若 eligible 仍从 candidates 过滤，pin 恒为 0——无论 poolSize 多大。
+  const { service, vectorIndex } = setup({
+    maxInjectedItems: 2,
+    pinnedInjectBudget: 2,
+    importanceThreshold: 3
+  });
+  seedVectorCrowd(service, vectorIndex, 4); // poolSize = maxItems*2 = 4，正好填满
+  seedPinnedPreferences(service, vectorIndex, 2);
+
+  const pinnedStats = {};
+  const selected = service.injectCandidates({
+    query: "另一个与偏好无关的问题",
+    maxItems: 2,
+    queryVector: [1, 0, 0],
+    pinnedStats
+  });
+
+  assert.equal(pinnedStats.shown, 2, "maxItems=2 时 pin 也要拿满 2 条");
+  const head = titlesOf(selected).slice(0, 2);
+  assert.ok(
+    head.every((t) => t.startsWith("硬偏好")),
+    `pin 从规则窗口取，与向量命中集无关：${head.join(" / ")}`
+  );
+});
+
+test("pin 池关闭时行为不变：pinnedInjectBudget=0 不得凭空引入偏好", () => {
+  // 关闭态必须与改动前逐字节一致——补回的 pin 只在预算 > 0 时发生，
+  // 预算关时 candidates 与改前完全一样。
+  const { service, vectorIndex } = setup({
+    maxInjectedItems: 5,
+    pinnedInjectBudget: 0,
+    importanceThreshold: 3
+  });
+  seedVectorCrowd(service, vectorIndex, 10);
+  seedPinnedPreferences(service, vectorIndex, 5);
+
+  const pinnedStats = {};
+  const selected = service.injectCandidates({
+    query: "又一个与偏好无关的问题",
+    maxItems: 5,
+    queryVector: [1, 0, 0],
+    pinnedStats
+  });
+
+  assert.equal(pinnedStats.shown, 0, "预算 0 → pin 池关闭");
+  assert.equal(selected.length, 5, "槽位数不变");
+  assert.ok(
+    titlesOf(selected).every((t) => t.startsWith("决定条目")),
+    "关闭态下 preference 不得被前置（顺序与改动前一致）"
+  );
+});
+
+// 安全底线：补回 pin 是在 strictScope 与 scopeState 两道闸门**之前**做的，
+// 所以这两道闸必须照旧能拦住被补回来的 pin 行。service.js 里那条位置纪律
+// （「pin 池 eligible 取自过滤之后的候选，顺带保证越权行进不了 pin」）就是靠
+// 这两条用例守住的——不然「补回」会顺带开一个越权口子。
+test("补回的 pin 仍受 strictScope 硬过滤：越权偏好不得因补回而进块", () => {
+  const { store, service, vectorIndex } = setup({
+    maxInjectedItems: 5,
+    pinnedInjectBudget: 5,
+    importanceThreshold: 3,
+    strictScope: true
+  });
+  seedVectorCrowd(service, vectorIndex, 10);
+  // 一条属于 proj-a 的偏好：调用方 scope 是 proj-b 时它必须进不来。
+  const m = service.saveWithDedupe({
+    type: "preference",
+    title: "越权偏好",
+    content: "只属于 proj-a 的偏好，不该泄进 proj-b 的注入块",
+    importance: 5,
+    workspace_scope: "proj-a",
+    workspace_scope_source: "explicit"
+  }).memory;
+  vectorIndex.saveEmbedding(m.id, [0, 1, 0]);
+
+  const pinnedStats = {};
+  const selected = service.injectCandidates({
+    query: "与偏好无关的问题",
+    maxItems: 5,
+    queryVector: [1, 0, 0],
+    scope: { agent_scope: null, workspace_scope: "proj-b" },
+    pinnedStats
+  });
+
+  assert.ok(
+    !titlesOf(selected).includes("越权偏好"),
+    `strictScope 必须挡住被补回的越权 pin：${titlesOf(selected).join(" / ")}`
+  );
+  assert.equal(pinnedStats.shown, 0, "被 scope 挡下的行不能算成已 pin");
+});
+
+test("补回的 pin 仍受 scopeState 拦截档约束：暂停作用域的偏好不得进块", () => {
+  const { service, vectorIndex } = setup({
+    maxInjectedItems: 5,
+    pinnedInjectBudget: 5,
+    importanceThreshold: 3,
+    scopeState: { enabled: true, enforce: true }
+  });
+  seedVectorCrowd(service, vectorIndex, 10);
+  const m = service.saveWithDedupe({
+    type: "preference",
+    title: "暂停域偏好",
+    content: "属于 proj-a 的偏好，而 proj-a 此刻被按下",
+    importance: 5,
+    workspace_scope: "proj-a",
+    workspace_scope_source: "explicit"
+  }).memory;
+  vectorIndex.saveEmbedding(m.id, [0, 1, 0]);
+  service.setScopeState({ dimension: "workspace", scope_value: "proj-a", state: "paused" });
+
+  const pinnedStats = {};
+  const selected = service.injectCandidates({
+    query: "与偏好无关的问题",
+    maxItems: 5,
+    queryVector: [1, 0, 0],
+    pinnedStats
+  });
+
+  assert.ok(
+    !titlesOf(selected).includes("暂停域偏好"),
+    `scopeState 拦截档必须挡住被补回的 pin：${titlesOf(selected).join(" / ")}`
+  );
+  assert.equal(pinnedStats.shown, 0, "被闸门拦下的行不能算成已 pin");
+});

package/test/inject.test.js

@@ -441,3 +441,54 @@ test("throwing surface getter degrades to full-log hot memory instead of a blank
   assert.ok(text.includes("热记忆不该因此整块消失"), "轮次回复应照旧进入");
   assert.equal(getInjectionSnapshot().query, "把投影插件卸了会怎样", "语义查询不受 getter 抛错影响");
 });
+
+// M3 仓库地志（chorography）：注入块折进同一个 memory context（不新开 context），
+// 次序是 时间 → 地志 → 热上下文 → 长期记忆。这三例锁的是「折进来之后仍只有一个块」
+// 与「空串不占位」——后者是宿主契约（空文本 section 被 filter 掉），不是我们自己加的。
+function setupWithChoro(choroText, over = {}) {
+  const store = createStore(":memory:");
+  const service = createService({ store, mirror: null, config: {} });
+  const settings = createSettings(store.db);
+  const contexts = [];
+  const ctx = { systemPrompt: { context(def) { contexts.push(def); return () => {}; } } };
+  const calls = [];
+  const choroInject = {
+    tier: "light",
+    text(cwd) { calls.push(cwd); return typeof choroText === "function" ? choroText(cwd) : choroText; },
+    dispose() {}
+  };
+  const config = { maxInjectedItems: 3, importanceThreshold: 3, ...over };
+  const injector = createInjector(ctx, service, settings, config, null, null, choroInject);
+  return { store, service, contexts, injector, calls, ctx };
+}
+
+test("M3: 地志块折进 memory context，不新开第二个 context", () => {
+  const { contexts } = setupWithChoro("[仓库地志]");
+  assert.equal(contexts.length, 2, "折进来就仍是两块；多开一块会改宿主的装配顺序");
+  assert.equal(contexts[0].name, "memory");
+});
+
+test("M3: 地志块排在热上下文与长期记忆之前，且 cwd 取自 scope.workspace_scope", () => {
+  const { contexts, service, calls } = setupWithChoro("[仓库地志]");
+  service.saveWithDedupe({ type: "preference", title: "语言", content: "用户用中文交流", importance: 5 });
+  const events = [
+    { type: "user/message", data: { source: { kind: "user" }, content: [{ type: "text", text: "这个仓库怎么组织" }] } },
+    { type: "assistant/message", data: { message: { content: [{ type: "text", text: "按模块分组" }] } } }
+  ];
+  // scope.workspace_scope 不是入参，是 scope.js 现场解析出来的（registry 反查，
+  // header.cwd 兜底）；测试只能提供 header.cwd，才能真验「注入器吃的是那一份口径」。
+  const text = contexts[0].text({ agent: { session: { header: { cwd: "/repo" }, snapshotEvents: () => events } } });
+  const iChoro = text.indexOf("[仓库地志]");
+  const iHot = text.indexOf("[短期上下文]");
+  const iMem = text.indexOf("[记忆库]");
+  assert.ok(iChoro >= 0 && iHot > iChoro && iMem > iHot, "次序 地志 → 热上下文 → 长期记忆：" + text);
+  assert.ok(calls.includes("/repo"), "cwd 只能用 scope.workspace_scope 这一份口径（P27），calls=" + JSON.stringify(calls));
+});
+
+test("M3: 地志为空串时不占位，块首尾不留空行；choroChars 记实际体积", () => {
+  const { contexts, service } = setupWithChoro("");
+  service.saveWithDedupe({ type: "preference", title: "语言", content: "用户用中文交流", importance: 5 });
+  const text = contexts[0].text({});
+  assert.equal(text.startsWith("[记忆库]"), true, "空串拼接不许在块首留下空行：" + JSON.stringify(text.slice(0, 8)));
+  assert.equal(getInjectionSnapshot().choroChars, 0);
+});

package/test/llm-audit.test.js

@@ -552,7 +552,7 @@ test("entity extraction writes an llm_audit row with the streamed usage tokens",
   });
   const text = await streamEntityText(
     [{ role: "user", content: [{ type: "text", text: "记忆内容" }] }],
-    {}
+    { memoryId: "mem-ok-1" }
   );
   assert.ok(text.includes("entities"), "the extracted text still reaches the extractor");
 
@@ -565,6 +565,34 @@ test("entity extraction writes an llm_audit row with the streamed usage tokens",
   assert.equal(row.input_tokens, 700, "input tokens come from chunk.usage");
   assert.equal(row.output_tokens, 180, "output tokens come from chunk.usage");
   assert.equal(row.total_tokens, 880);
+  // success 行同样必须可归因。此前这里不传 memoryId、也不断言 id，于是
+  // writeAudit("success", null) 省略第三参的缺陷在绿测试下活了很久——活库
+  // 6256 条 success 行 related_memory_ids 100% 空数组，成功的那些抽取反而
+  // 一条都对不上记忆，#405 只修了 error 半边。
+  assert.deepEqual(row.related_memory_ids, ["mem-ok-1"],
+    "a successful extraction is attributable to the memory it read");
+  store.close();
+});
+
+test("entity extraction success row still leaves the id empty when there is none to attribute", async () => {
+  const store = createStore(":memory:");
+  const service = createService({ store, mirror: null, config: {} });
+  const streamEntityText = createEntityStreamAdapter({
+    llm: {
+      async *stream() {
+        yield { type: "text-delta", index: 0, text: '{"entities":[],"relations":[]}' };
+        yield { type: "finish", reason: { kind: "stop" } };
+      }
+    },
+    agentDefaultModel: { currentSelection: () => ({ provider: "mock", model: "mock-model" }) },
+    logger: { warn: () => {} },
+    service
+  });
+  await streamEntityText([{ role: "user", content: [{ type: "text", text: "记忆内容" }] }], {});
+  const row = service.listLlmAudits({ source: "entityExtract" })[0];
+  assert.equal(row.status, "success");
+  assert.deepEqual(row.related_memory_ids, [],
+    "no memoryId → empty, never a fabricated id");
   store.close();
 });
 

package/test/persona-settings.test.js

@@ -165,3 +165,34 @@ test("personaEnabled is in the feature-flag boolean whitelist", () => {
   assert.throws(() => settings.setFeatureFlags({ notARealFlag: true }), TypeError);
   store.close();
 });
+
+test("strict 寻址：一张身份卡都没建时仍回落 default（#587 的例外）", () => {
+  // 两种处境必须分开：
+  //   A) 建了身份卡、只是没这一张 → strict 下不注入（见上一条用例，行为不变）
+  //   B) 一张身份卡都没建      → default 是用户手里唯一那张卡，strict 不许把它关死
+  // DS Bot 这类宿主里所有 bot 会话共用 agentPreset "standard"，用户按 bot 名字建卡
+  // 永远不命中，于是必然落进 B——此时按 none 处理等于把唯一那张卡静默废掉。
+  const { store, settings } = setup();
+  settings.setPersona({ name: "Amarre", enabled: true });
+  assert.deepEqual(settings.getPersona().byAgent, {}, "前提：byAgent 整体为空");
+  const { card, source } = resolvePersonaCard(settings, "standard", { strict: true });
+  assert.equal(source, "default", "一张卡都没建时严格寻址仍回落 default");
+  assert.equal(card.name, "Amarre");
+  // 建了任意一张身份卡之后，例外立即失效——兜底退回严格语义
+  settings.setPersonaFor("zephyr", { name: "泽菲尔", enabled: true });
+  assert.equal(resolvePersonaCard(settings, "standard", { strict: true }).source, "none");
+  // 而这张卡自己仍然命中
+  assert.equal(resolvePersonaCard(settings, "zephyr", { strict: true }).source, "byAgent");
+  store.close();
+});
+
+test("strict 寻址：身份卡存在但全被关掉，仍算「建过卡」——例外只看有没有键", () => {
+  // 例外判的是 byAgent 的键数，不是「有没有可用的卡」：一张 enabled=false 的卡
+  // 也算「用户已经做过分区」，此时不该再拿 default 去兜。这条锁住判据不会被
+  // 改成「有可用卡才算建过」，否则关掉唯一那张身份卡会重新落回 default。
+  const { store, settings } = setup();
+  settings.setPersona({ name: "Amarre", enabled: true });
+  settings.setPersonaFor("zephyr", { name: "泽菲尔", enabled: false });
+  assert.equal(resolvePersonaCard(settings, "standard", { strict: true }).source, "none");
+  store.close();
+});