@modusensus/dsh-mneme 0.9.5 → 0.10.1

package/lib/dream/sleep.js

@@ -27,6 +27,8 @@ import { computeHeat } from "../heat.js";
 // demoteToSummary，phasePatterns 还会 mint 出新行，所以这条契约要在每处各挡一遍
 // （清单与静态锁见 test/share-imported-guard.test.js）。
 import { isImportedRow } from "../memory-source.js";
+// Issue #533：查账本时要拿两侧当前的正文哈希，与 applyDifferentiate 记账时的口径同源。
+import { contentHashOf } from "../content-hash.js";
 
 // Issue #126 review（Copilot）：默认档（sleepActionSet="conflict"）允许的动作 = 全局
 // ACTIONS 去掉 #126 新增的两个。从 ACTIONS 派生而非硬编码，将来再扩动作集时自动跟随。
@@ -40,6 +42,22 @@ const SUMMARY_MAX = 120;
 //   aggressive low-confidence pairs too (0.75) — bloated stores
 const CONFLICT_THRESHOLDS = { gentle: 0.92, normal: 0.85, aggressive: 0.75 };
 
+// Issue #529（C 项的替代实现）：连续失败时最小间隔的封顶。基数默认 8 小时，
+// 2^3 就到 64 小时——不封顶的话模型持续失败会让 sleep 事实上停摆好几天，而
+// 用户完全看不出来。24 小时 = 「最多一天试一次」，与 #292 给 autoDream 的
+// 30 分钟封顶同一意图（封顶值不同是因为两个调度的基数差一个数量级）。
+//
+// 实际封顶取 max(基数, 24h)，不是硬 24h：`sleepMinIntervalHours` 允许 1–168，
+// 用户配 48 小时就是明说"两天跑一次"，退避不该把它压回 24 小时（封顶只能放宽
+// 间隔、不能收紧用户自己设的）。
+const FAILURE_BACKOFF_CAP_MS = 24 * 3600000;
+
+// Issue #529（续排）：一轮内部最多连追多少轮。449 对的池子按每轮 60 对只需 8 轮，
+// 24 留足余量；超过就退回正常最小间隔。防的是"池子在长、每轮都 clean 但永远追不完"
+// ——用户持续写入时池子进得比追得快，光看 clean 会变成永不落地的每五分钟一轮，
+// 而审计上每轮都"有产出"，肉眼很难发现。
+const CATCHUP_STREAK_CAP = 24;
+
 function parseJsonArray(text) {
   if (typeof text !== "string") return undefined;
   const start = text.indexOf("[");
@@ -281,9 +299,83 @@ async function phaseConflicts(ctx, service, config, logger, runId, semantic = nu
   // Dedupe: each memory participates in at most one pair, highest similarity
   // first — overlapping pairs would violate validateDecisions' "one claim".
   pairs.sort((a, b) => b.similarity - a.similarity);
+
+  // Issue #533：已经裁决过「互补、两条都留」的对不再重判。
+  //
+  // 过滤必须发生在 used 去重**之前**：若先占位再丢弃，一条已裁决的记忆会把
+  // 名额占住，而它真正的对手又是自己人，这一轮就白跑——抑制一对不该顺带压掉
+  // 另一对候选。判据与 applyDifferentiate 的幂等同源：账本里有这对、且两侧正文
+  // 的 content_hash 与记账时一致（任一侧改过 = 结论可能不再成立，重判）。
+  // 存量兼容走同一格：旧版本把注记写进正文却没账本行，两侧都还带着注记块也算
+  // 已裁决，免得升级后第一轮把所有老对重判一遍。
+  const alreadyDifferentiated = (p) => {
+    const a = service.getById(p.a.id);
+    const b = service.getById(p.b.id);
+    if (!a || !b) return false;
+    if (typeof service.findDifferentiatedPair === "function") {
+      const record = service.findDifferentiatedPair(a.id, b.id);
+      if (record) {
+        const [ha, hb] = a.id <= b.id
+          ? [contentHashOf(a), contentHashOf(b)]
+          : [contentHashOf(b), contentHashOf(a)];
+        // 账本行没记 hash（存量/异常写入）时不下结论，宁可多判一次。
+        return record.hash_a != null && record.hash_b != null
+          && record.hash_a === ha && record.hash_b === hb;
+      }
+    }
+    return STR.differentiatedNoteRe.test(String(a.content ?? ""))
+      && STR.differentiatedNoteRe.test(String(b.content ?? ""));
+  };
+  const fresh = [];
+  let suppressed = 0;
+  for (const p of pairs) {
+    if (alreadyDifferentiated(p)) {
+      suppressed += 1;
+      continue;
+    }
+    fresh.push(p);
+  }
+  if (fresh.length === 0) {
+    // 与 "no conflicts found" 分开报：一对都没检测到 vs 检测到但全都裁决过，
+    // 是完全不同的两件事，混成一句会让「sleep 是不是没在干活」读不出来。
+    return { status: "noop", reason: "all candidate pairs already differentiated", suppressed };
+  }
+
+  // Issue #529：输入侧预算。此前 samePairs 是**全部**同 scope 相似对，一次拼成一个
+  // prompt——实测单请求 163,054 输入 token（服务端 --ctx-size 163,840），撞墙后按冷却
+  // 重排，下一轮送进去的还是同一份输入，于是 23 轮连续失败。
+  //
+  // 预筛掉「已经判过且两侧都没动过」的对：判 keep 曾经是彻底的 no-op，既不留痕也不
+  // 影响下一轮的候选池，同一对每个冷却周期都被重新送审一遍。台账（conflict_reviewed）
+  // 记的是"这段输入被看过"，两侧任一 updated_at 晚于 judged_at 就重新入池——与
+  // conflict_pending 复核项 4 同一条宽松代理：任何字段更新都算值得再看一眼。
+  //
+  // Issue #536 review（CodeRabbit ①）：预筛必须发生在下面的 used 去重**之前**，理由与
+  // #533 那条一模一样——先占位再去掉，一条已审的记忆会把自己的配对名额占住，而它真正
+  // 的对手（另一条没审过的记忆）因此进不了这一轮。三条边界：
+  //   · 只筛同 scope 对：跨 scope 对本来就要停车进人工队列，不能被台账吞掉；
+  //   · freeze 模式不筛：那一档只停车不送 LLM，台账与它无关（ledgerSkipped 记 0）；
+  //   · ledgerSkipped 在这里一次数清，后面 candidates 直接取 samePairs，不再二次过滤。
+  const isCrossScopePair = (p) =>
+    scopeKeyOf(p.a.agent_scope) !== scopeKeyOf(p.b.agent_scope)
+    || scopeKeyOf(p.a.workspace_scope) !== scopeKeyOf(p.b.workspace_scope);
+  const ledger = typeof service.loadConflictReviewed === "function"
+    ? (service.loadConflictReviewed() ?? new Map())
+    : new Map();
+  const pairKey = (p) => (p.a.id < p.b.id ? `${p.a.id}\u0000${p.b.id}` : `${p.b.id}\u0000${p.a.id}`);
+  const alreadyJudged = (p) => {
+    const rec = ledger.get(pairKey(p));
+    if (!rec?.judged_at) return false;
+    return (p.a.updated_at ?? "") <= rec.judged_at && (p.b.updated_at ?? "") <= rec.judged_at;
+  };
+  const selectionPairs = config.conflictFreezeEnabled === true
+    ? fresh
+    : fresh.filter((p) => isCrossScopePair(p) || !alreadyJudged(p));
+  const ledgerSkipped = fresh.length - selectionPairs.length;
+
   const used = new Set();
   const selected = [];
-  for (const p of pairs) {
+  for (const p of selectionPairs) {
     if (used.has(p.a.id) || used.has(p.b.id)) continue;
     used.add(p.a.id);
     used.add(p.b.id);
@@ -295,9 +387,6 @@ async function phaseConflicts(ctx, service, config, logger, runId, semantic = nu
   // 并存」正是收窄/提升裁决的典型候选）不能自动裁决：归档败者可能销毁该内容在
   // 某个归属下的唯一副本，LLM 也无从替用户决定归属。一律停车到冲突待确认队列
   // （专属 reason），同 scope 对维持既有路径（freeze 停车 / LLM 裁决）。
-  const isCrossScopePair = (p) =>
-    scopeKeyOf(p.a.agent_scope) !== scopeKeyOf(p.b.agent_scope)
-    || scopeKeyOf(p.a.workspace_scope) !== scopeKeyOf(p.b.workspace_scope);
   const crossPairs = selected.filter(isCrossScopePair);
   const samePairs = selected.filter((p) => !isCrossScopePair(p));
   const parkPair = (p, reason) => {
@@ -329,33 +418,42 @@ async function phaseConflicts(ctx, service, config, logger, runId, semantic = nu
     if (parkPair(p, scopeReason(p))) scopeParked++;
   }
   if (samePairs.length === 0) {
-    return { status: scopeParked > 0 ? "ok" : "noop", frozen: 0, scopeCandidates: scopeParked, pairs: selected.length };
+    // 没有可送 LLM 的同 scope 对：可能一对都没检测到，也可能全被台账挡下了
+    // （ledgerSkipped）。两种都要如实报，否则「sleep 怎么什么都不干」读不出来。
+    return {
+      status: scopeParked > 0 ? "ok" : "noop",
+      frozen: 0,
+      scopeCandidates: scopeParked,
+      pairs: selected.length,
+      batches: 0,
+      ledgerSkipped
+    };
   }
 
   // LLM adjudication（仅同 scope 对）。
   const route = resolveSleepRoute(ctx, config, logger);
-  if (!route) return { status: "skipped", reason: "no llm route", scopeCandidates: scopeParked, pairs: selected.length };
-  const snapshot = new Map();
-  for (const p of samePairs) {
-    snapshot.set(p.a.id, p.a);
-    snapshot.set(p.b.id, p.b);
-  }
-  const listText = samePairs.map((p) =>
-    STR.candidateConflicts[language](p)
-  ).join("\n\n");
+  if (!route) return { status: "skipped", reason: "no llm route", scopeCandidates: scopeParked, pairs: selected.length, batches: 0, ledgerSkipped };
+  // 每轮总上限：分批解决的是单请求撞墙，不是"一个 449 对的池子该在一轮里跑完"。
+  // 没进这一轮的对留在下一轮（它们既没被丢弃，也不在台账里）。
+  const perRunCap = config.sleepConflictMaxPairsPerRun ?? 60;
+  const pool = perRunCap > 0 ? samePairs.slice(0, perRunCap) : samePairs;
+  const perRunSkipped = samePairs.length - pool.length;
   const sleepEffort = await resolveDreamEffort(ctx, route, config.sleepReasoningEffort, logger);
   let conflictStreamFailure = "";
   // actionSet 已在候选构造前解析（跨类型候选需要它），这里只按档位选 prompt：
   // 默认档保持只有 conflict/keep 的窄 prompt，"full" 才开放六分支。
   const conflictPrompt = actionSet === "full" ? STR.prompts.conflictFull[language] : STR.prompts.conflict[language];
-  const runConflict = (withEffort, tokens) => {
+  const runConflict = (batch, withEffort, tokens) => {
     conflictStreamFailure = "";
+    const listText = batch.map((p) => STR.candidateConflicts[language](p)).join("\n\n");
     return auditedSleepLlm(ctx, service, config, logger, {
       triggerSource: "sleep",
       operationType: "sleep_conflict",
       modelId: `${route.provider}:${route.model}`,
       // 候选对的双方 id：面板的活动流用 related_memory_ids 解析「沉淀条数」。
-      relatedMemoryIds: samePairs.flatMap((p) => [p.a.id, p.b.id]),
+      // 分批后必须取**这一批**的 id：整轮的 60 对一次写进每一批的审计行，面板会把
+      // 同一个「沉淀条数」重复累加五遍。
+      relatedMemoryIds: batch.flatMap((p) => [p.a.id, p.b.id]),
       streamError: () => conflictStreamFailure,
       // 纯判据：输出里没有 JSON 数组 ⇒ 这轮是失败的调用，审计记 error。**不要**把
       // 解析结果存进闭包给下面的控制流用——审计关闭时 auditedSleepLlm 整段早退、
@@ -377,72 +475,251 @@ async function phaseConflicts(ctx, service, config, logger, runId, semantic = nu
     ]
   }, reportUsage, (reason) => { conflictStreamFailure = describeStreamFailure(reason); }));
   };
-  // Issue #478：睡眠侧同样接 max_tokens 降级——面板 hint 已承诺「超上限同样自动降级」，
-  // 只挂 dream 三个点会让 sleepMaxTokens 的 131072 上限继续原样发。
-  const text = await withMaxTokensFallback(ctx, config.sleepMaxTokens ?? 2048, (tokens) => withEffortFallback(ctx, sleepEffort, () => runConflict(true, tokens), () => runConflict(false, tokens), () => conflictStreamFailure), () => conflictStreamFailure);
-  if (text === undefined) {
-    if (conflictStreamFailure) ctx.logger?.warn?.(`dsh-mneme sleep: conflict stream aborted or errored (${conflictStreamFailure})`);
-    return { status: "failed", error: "llm failed" };
-  }
-  const decisions = parseJsonArray(text);
-  if (!decisions) return { status: "failed", error: "invalid decisions json" };
-  // validateDecisions 要求每个 snapshot id 恰好被 claim 一次。v0.4.4 起它本身
-  // 就会为未覆盖的 id 自动补 keep（dreamImplicitKeep 默认开启），这里保留显式
-  // 预填作为防御性双保险——漏判读作"未裁决冲突"而非"冲突阶段整体失败"。
-  const covered = new Set();
-  for (const d of decisions) {
-    // Issue #126 review（Copilot）：supersede 同样用 winner/loser 定位（没有 ids），
-    // 此前只认 conflict → 它的两个目标都没进 covered → 被补成 implicit keep → 与
-    // supersede 的 claim 冲突：严格模式整单拒绝，宽容模式把合成的 keep 记成 skipped。
-    if (d?.action === "conflict" || d?.action === "supersede") {
-      if (typeof d?.winner === "string") covered.add(d.winner);
-      if (typeof d?.loser === "string") covered.add(d.loser);
-    } else if (Array.isArray(d?.ids)) {
-      for (const id of d.ids) covered.add(id);
+  // 单批的完整往返：送 → 解析 → 校验 → 应用 → 记账。抽成函数是为了让失败只影响
+  // 自己这一批（下面的循环），而不是把整轮判死。
+  const adjudicateBatch = async (batch, updateBudget) => {
+    // Issue #529 review（CodeRabbit ①）：留痕写入失败要能被上层看见。只打 warn 的话，
+    // 这一对既没记账、又被算成"送出去的全落地了"，于是下一轮它原样回到候选池、又被
+    // 算成可续排——每个静默窗口重问一次同一个冲突，直到连击上限才停，而审计上每轮
+    // 都是干净的成功轮。计数随返回值透出，由 phaseConflicts 折进 clean。
+    let ledgerFailed = 0;
+    // Issue #536 review（CodeRabbit ③）：judged_at 是**发送时刻**，不是落地时刻。
+    //
+    // 取 max(墙钟, 本批两侧里最新的 updated_at)：`updated_at` 用的是 store 的
+    // **单调时钟**（src/store.js 的 nowIso：同一毫秒内的连续写入逐次 +1ms），它可能
+    // 比墙钟快几毫秒；直接用墙钟会记出一个早于被测行自身版本的 `judged_at`，于是
+    // 「这一对刚判过」在下一轮的 `alreadyJudged` 里读成「判过之后又被改过」，判 keep
+    // 的死循环原样复活（CI 的 test-host-legacy 腿抓到过一次真 flake）。两列同源才可比。
+    const judgedAt = batch.reduce(
+      (acc, p) => (p.a.updated_at > acc ? p.a.updated_at : (p.b.updated_at > acc ? p.b.updated_at : acc)),
+      new Date().toISOString()
+    );
+    const text = await withMaxTokensFallback(ctx, config.sleepMaxTokens ?? 2048, (tokens) => withEffortFallback(ctx, sleepEffort, () => runConflict(batch, true, tokens), () => runConflict(batch, false, tokens), () => conflictStreamFailure), () => conflictStreamFailure);
+    if (text === undefined) {
+      if (conflictStreamFailure) ctx.logger?.warn?.(`dsh-mneme sleep: conflict stream aborted or errored (${conflictStreamFailure})`);
+      return { status: "failed", error: "llm failed", failure: conflictStreamFailure || undefined };
     }
-  }
-  for (const id of snapshot.keys()) {
-    if (!covered.has(id)) decisions.push({ action: "keep", ids: [id] });
-  }
-  // Issue #126：sleep 是多对批量裁决，严格模式"一票否决"太脆（一对非法就丢掉整轮
-  // 成果）→ 与 dream 对齐透传 skipInvalid：非法的那一对只跳过自己，合法子集照常
-  // 应用，run 记 degraded。update 上限与保护期同样取 dream 的同一组配置，保证两个
-  // 模块对"什么算合法"的判据一致。
-  const { ok, errors, skipped } = validateDecisions(decisions, snapshot, {
-    maxUpdatePerRun: config.reflectionUpdateMaxPerRun,
-    minAgeHours: config.reflectionUpdateMinAgeHours,
-    skipInvalid: config.dreamSkipInvalid !== false,
-    allowCrossTypeMerge: config.allowCrossTypeMerge === true,
-    // issue #339 / E8：guarded 类型 merge 护栏（默认开，dreamMergeGuard），
-    // 与 dream 主链路同一判据。
-    mergeGuard: config.dreamMergeGuard === true,
-    // Issue #126 review（Copilot）：默认档必须真的只放行旧动作集——只换 prompt 挡不住
-    // 模型自发输出 supersede / differentiate，那样"opt-in 零行为变化"就不成立。
-    allowedActions: actionSet === "full" ? null : LEGACY_ACTIONS
-  });
-  if (!ok) return { status: "failed", error: `invalid decisions: ${errors.join("; ")}`, skipped };
-  // 同 phasePatterns——本相位的 create 也落 source=sleep（默认档的
-  // LEGACY_ACTIONS 含 create，理论上可 mint）。
-  const { applied, failures, conflicts } = applyDecisions(
-    decisions, service, logger, snapshot, { ...config, mintSource: "sleep" }
-  );
-  // Issue #126 review（Copilot）：事务内 service.update 会跳过 scheduleEmbed（txDepth>0），
-  // 而 sleep 路径此前没有 dream 那样的 post-apply 索引维护——differentiate 的差异注记与
-  // supersede 的归档都反映不到缓存向量，"注记进 embedding 防再判重复"就是空承诺。
-  if (applied > 0 && semantic?.embedder && semantic?.vectorIndex) {
+    const decisions = parseJsonArray(text);
+    if (!decisions) return { status: "failed", error: "invalid decisions json" };
+    // 本批的 snapshot 只含本批的 id。validateDecisions 要求每个 snapshot id 恰好被
+    // claim 一次，拿整轮的 snapshot 校验单批输出会把其余 48 对判成"未裁决"。
+    const batchSnapshot = new Map();
+    for (const p of batch) {
+      batchSnapshot.set(p.a.id, p.a);
+      batchSnapshot.set(p.b.id, p.b);
+    }
+    // v0.4.4 起 validateDecisions 本身就会为未覆盖的 id 自动补 keep（dreamImplicitKeep
+    // 默认开启），这里保留显式预填作为防御性双保险——漏判读作"未裁决冲突"而非
+    // "冲突阶段整体失败"。
+    const covered = new Set();
+    for (const d of decisions) {
+      // Issue #126 review（Copilot）：supersede 同样用 winner/loser 定位（没有 ids），
+      // 此前只认 conflict → 它的两个目标都没进 covered → 被补成 implicit keep → 与
+      // supersede 的 claim 冲突：严格模式整单拒绝，宽容模式把合成的 keep 记成 skipped。
+      if (d?.action === "conflict" || d?.action === "supersede") {
+        if (typeof d?.winner === "string") covered.add(d.winner);
+        if (typeof d?.loser === "string") covered.add(d.loser);
+      } else if (Array.isArray(d?.ids)) {
+        for (const id of d.ids) covered.add(id);
+      }
+    }
+    for (const id of batchSnapshot.keys()) {
+      if (!covered.has(id)) decisions.push({ action: "keep", ids: [id] });
+    }
+    // Issue #126：sleep 是多对批量裁决，严格模式"一票否决"太脆（一对非法就丢掉整轮
+    // 成果）→ 与 dream 对齐透传 skipInvalid：非法的那一对只跳过自己，合法子集照常
+    // 应用，run 记 degraded。update 上限与保护期同样取 dream 的同一组配置，保证两个
+    // 模块对"什么算合法"的判据一致。
+    const { ok, errors, skipped } = validateDecisions(decisions, batchSnapshot, {
+      // Issue #536 review（CodeRabbit ②）：reflectionUpdateMaxPerRun 是**整轮**上限，
+      // 分批后不能每批都拿整份额度——那样 N 批就是 N 倍上限。这里用的是本轮的剩余额度。
+      maxUpdatePerRun: updateBudget,
+      minAgeHours: config.reflectionUpdateMinAgeHours,
+      skipInvalid: config.dreamSkipInvalid !== false,
+      allowCrossTypeMerge: config.allowCrossTypeMerge === true,
+      // issue #339 / E8：guarded 类型 merge 护栏（默认开，dreamMergeGuard），
+      // 与 dream 主链路同一判据。
+      mergeGuard: config.dreamMergeGuard === true,
+      // Issue #126 review（Copilot）：默认档必须真的只放行旧动作集——只换 prompt 挡不住
+      // 模型自发输出 supersede / differentiate，那样"opt-in 零行为变化"就不成立。
+      allowedActions: actionSet === "full" ? null : LEGACY_ACTIONS
+    });
+    if (!ok) return { status: "failed", error: `invalid decisions: ${errors.join("; ")}`, skipped };
+    // 同 phasePatterns——本相位的 create 也落 source=sleep（默认档的
+    // LEGACY_ACTIONS 含 create，理论上可 mint）。
+    const { applied, failures, conflicts } = applyDecisions(
+      // runId 让 differentiate 的账本行能追到是哪一轮 sleep 判的（issue #533）。
+      decisions, service, logger, batchSnapshot, { ...config, mintSource: "sleep", runId }
+    );
+    // Issue #536 review（CodeRabbit ②）：本轮剩余的 update 额度按本批**通过校验的**
+    // update 数扣减——validateDecisions 已把非法条目从 decisions 就地 splice 掉，
+    // 所以数到的都是真的会落地的那些。落地时被 CAS 挡下的也算：额度宁可少发一次，
+    // 也不能让"多批各扣一次满额"把整轮上限架空。
+    const updateUsed = decisions.filter((d) => d?.action === "update").length;
+    // Issue #126 review（Copilot）：事务内 service.update 会跳过 scheduleEmbed（txDepth>0），
+    // 而 sleep 路径此前没有 dream 那样的 post-apply 索引维护——differentiate 的差异注记与
+    // supersede 的归档都反映不到缓存向量，"注记进 embedding 防再判重复"就是空承诺。
+    if (applied > 0 && semantic?.embedder && semantic?.vectorIndex) {
+      try {
+        await maintainIndexAfterDream(decisions, service, semantic);
+      } catch (error) {
+        logger?.warn?.(`dsh-mneme sleep: index maintenance failed: ${String(error)}`);
+      }
+    }
+    // 台账：本批**全部送审对**都记一行，不只记被判成冲突的那几对。判 keep 的那一对
+    // 正是 #529 里"下一轮原样再送"的元凶，只记有动作的对等于没记。
+    if (typeof service.saveConflictReviewed === "function") {
+      // judged_at 取的是**发送之前**的时刻（见函数开头），不是落地之后：LLM 往返
+      // 期间若一侧被外部改动，它的 updated_at 会晚于 judged_at，下一轮自然重新入池；
+      // 模型看到的本来就是旧快照，按"已审"封盘等于用陈旧结论锁死这一对。
+      const outcomeOf = new Map();
+      for (const d of decisions) {
+        const action = d?.action ?? "keep";
+        if (action === "conflict" || action === "supersede") {
+          if (typeof d?.winner === "string") outcomeOf.set(d.winner, action);
+          if (typeof d?.loser === "string") outcomeOf.set(d.loser, action);
+        } else if (Array.isArray(d?.ids)) {
+          for (const id of d.ids) outcomeOf.set(id, action);
+        }
+      }
+      // Issue #536 review（CodeRabbit ③）：未落地的对不记账。skipped（非法被跳）、
+      // failures（写入失败）、conflicts（CAS 冲突）里出现过的 id，说明那条决策没生效；
+      // 把它记成"已审"会让下一轮的 alreadyJudged 为真，这一对从此不再送审——
+      // 沉默地永久压制一个真实冲突，比多送一轮贵得多。
+      const unsettled = new Set();
+      for (const f of [...(failures ?? []), ...(conflicts ?? []), ...(skipped ?? [])]) {
+        for (const id of f?.ids ?? []) unsettled.add(id);
+      }
+      for (const p of batch) {
+        if (unsettled.has(p.a.id) || unsettled.has(p.b.id)) continue;
+        try {
+          service.saveConflictReviewed({
+            run_id: runId,
+            memory_a: p.a.id,
+            memory_b: p.b.id,
+            // 一对两端的动作可能不同（conflict 的胜/败、merge 的两端），取**非 keep
+            // 的那一侧**：keep/keep 才代表"看过、不冲突"，这正是我们要留痕的结论。
+            outcome: [outcomeOf.get(p.a.id), outcomeOf.get(p.b.id)]
+              .find((x) => x && x !== "keep") ?? "keep",
+            judged_at: judgedAt
+          });
+        } catch (error) {
+          // Issue #529 review（CodeRabbit）：留痕失败必须让这一轮**不 clean**。只 warn 的
+          // 话，这一对既没记账、又被算成"送出去的全落地了"，下一轮它原样回到候选池、
+          // 又被算成可续排——每个静默窗口重问一次同一个冲突，直到连击上限才停，而
+          // 审计上每一轮都是干净的成功轮。
+          ledgerFailed += 1;
+          logger?.warn?.(`dsh-mneme sleep: failed to record reviewed conflict ${p.a.id}/${p.b.id}: ${String(error)}`);
+        }
+      }
+    }
+    // Issue #126 review（Copilot）：有决策被跳过时不能报 ok——与 dream 的 degraded 契约
+    // 对齐（"合法子集已应用"是 degraded 而非 ok），否则消费方分不清整轮与残轮。
+    return { status: applied > 0 ? (skipped.length > 0 ? "degraded" : "ok") : failures.length ? "failed" : "noop", applied, failures, conflicts, skipped, updateUsed, ledgerFailed };
+  };
+  // 分批：每批独立往返，坏批只记 degraded 不中断。此前一次全送，任何一处理由
+  // （撞上下文、输出截断、JSON 坏掉）都是整轮 failed——而整轮 failed 又不带 pairs，
+  // 事后看不出它到底送了什么。
+  const batchSize = config.sleepConflictMaxPairs ?? 12;
+  const batches = batchSize > 0
+    ? Array.from({ length: Math.ceil(pool.length / batchSize) }, (_, i) => pool.slice(i * batchSize, (i + 1) * batchSize))
+    : [pool];
+  let applied = 0;
+  const failures = [];
+  const conflicts = [];
+  const skipped = [];
+  let failedBatches = 0;
+  // Issue #529 review（CodeRabbit ①）：台账写入失败的累计数（逐批由 adjudicateBatch 报回）。
+  let ledgerFailed = 0;
+  // 用户活动打断时**不能**落进下面那条 noop：noop 的语义是「看过，没冲突」，而被打断
+  // 的那几批根本没送出去。用与入口处（signal 一开始就是 aborted）同一个词汇，避免
+  // 同一件事两个状态名。
+  let interrupted = false;
+  // Issue #536 review（CodeRabbit ②）：reflectionUpdateMaxPerRun 是**整轮**上限。
+  // 校验器本身不跨批记忆，每批各拿一份满额就等于 N 倍上限，所以额度由这里持有：
+  // 每批只领剩余额度，校验通过后按**本批通过校验的** update 数扣减。额度用尽的
+  // 那几批若还含 update，会被校验器整单拒绝（记 failed），其余批照常继续——
+  // 与"一批坏掉不判死整轮"的既有契约一致。
+  let updateLeft = config.reflectionUpdateMaxPerRun ?? 2;
+  for (let i = 0; i < batches.length; i++) {
+    if (signal?.aborted) { interrupted = true; break; }
+    // Issue #536 review（CodeRabbit）：单批抛错不能带走整轮。`adjudicateBatch` 里不只有
+    // "把失败变成返回值"的 LLM 通路，还有 `applyDecisions` 与台账写入——它们抛出的异常
+    // 此前会直接跳出循环，后面所有批都不跑、已汇总的 applied/failures 也一起丢掉。
+    // 只放行 AbortError（取消意图绝不能被降级重试吞掉，与 dream.js 的 withEffort 守卫同款），
+    // 其余一律折成这一批的 failed 结果，循环继续。
+    let res;
     try {
-      await maintainIndexAfterDream(decisions, service, semantic);
+      res = await adjudicateBatch(batches[i], updateLeft);
     } catch (error) {
-      logger?.warn?.(`dsh-mneme sleep: index maintenance failed: ${String(error)}`);
+      if (error?.name === "AbortError") { interrupted = true; break; }
+      res = { status: "failed", error: String(error?.message ?? error), failures: [], skipped: [] };
+    }
+    if (res.status === "failed") {
+      failedBatches++;
+      failures.push(...(res.failures ?? []));
+      skipped.push(...(res.skipped ?? []));
+      // 失败批的原始理由（stream 层的 abort/error 原文）要进审计：只写 "llm failed"
+      // 的话，运维分不清是上下文超限、模型拒收还是用户活动打断。
+      logger?.warn?.(`dsh-mneme sleep: conflict batch ${i + 1}/${batches.length} failed: ${res.error}${res.failure ? ` (${res.failure})` : ""}`);
+      continue;
     }
+    applied += res.applied;
+    ledgerFailed += res.ledgerFailed ?? 0;
+    updateLeft = Math.max(0, updateLeft - (res.updateUsed ?? 0));
+    failures.push(...(res.failures ?? []));
+    conflicts.push(...(res.conflicts ?? []));
+    skipped.push(...(res.skipped ?? []));
   }
-  // Issue #126 review（Copilot）：有决策被跳过时不能报 ok——与 dream 的 degraded 契约
-  // 对齐（"合法子集已应用"是 degraded 而非 ok），否则消费方分不清整轮与残轮。
-  const degraded = skipped.length > 0;
+  const degraded = skipped.length > 0 || failedBatches > 0;
+  // 一批都没成功才算整轮失败；只要有一批落地，如实记 degraded——这跟 deriveStatus
+  // 的契约一致（degraded 也算有产出）。
+  const allFailed = failedBatches === batches.length;
+  // 有一批没走通时整轮**绝不能报 noop**：noop 的语义是「看过，没冲突」，而踩了
+  // llm failed 的那批其实没看过。这是 #529 里最误导人的一处——23 轮失败期间
+  // applied 恒为 0，若再叠上 noop，运维只会以为库里没冲突。
+  const status = interrupted
+    ? "aborted"
+    : allFailed
+    ? "failed"
+    : applied > 0
+      ? (degraded ? "degraded" : "ok")
+      : failures.length
+        ? "failed"
+        : failedBatches > 0
+          ? "degraded"
+          : "noop";
+  // Issue #529（续排）：「这一轮有没有产出」和「送出去的每一对是不是都落地了」是两件
+  // 正交的事，status 只回答前者。全判 keep 的轮次 applied 恒为 0 → status 是 noop
+  // （never ok），而它恰恰是 #529 里最该续排的场景；拿 status === "ok" 当判据会在
+  // 这里把续排堵死。所以另给一个布尔，口径与下面台账的 unsettled 完全一致：failure
+  // （写入失败）/ conflicts（CAS 冲突）/ skipped（非法被跳）任一出现过，就说明有对没
+  // 落地，它下一轮还会被重新配出来，不算 clean。
+  // Issue #529 review（CodeRabbit ①）：台账写入失败同样算"没落地"——那一对没被记成
+  // 已审，下一轮会重新入池，与上面 unsettled 是同一个道理。
+  const clean =
+    !interrupted &&
+    failedBatches === 0 &&
+    skipped.length === 0 &&
+    failures.length === 0 &&
+    conflicts.length === 0 &&
+    ledgerFailed === 0;
   return {
-    status: applied > 0 ? (degraded ? "degraded" : "ok") : failures.length ? "failed" : "noop",
+    status,
+    clean,
+    // Issue #529 D：失败轮也要带 pairs/batches——此前只有成功路径带 pairs，85 条
+    // 失败审计行全是"送了个寂寞"，连送了多少对都查不到。
     pairs: selected.length,
+    // #533：这一轮被账本压掉、没送 LLM 的候选对数——不记的话「pairs 变小了」
+    // 分不清是没检测到还是已经裁决过。
+    suppressed,
+    batches: batches.length,
+    ledgerSkipped,
+    perRunSkipped,
     applied,
+    // Issue #529 review（CodeRabbit ①）：留痕失败的对数——clean 为 false 时要能分清是
+    // 哪一类没落地（写入失败 / 非法被跳 / CAS 冲突 / 台账没记上）。
+    ledgerFailed,
     failures,
     conflicts,
     // Issue #126：#104 同向——被跳过的逐对明细要进审计行，否则事后无法判断
@@ -604,8 +881,10 @@ async function phasePatterns(ctx, service, config, logger, runId, signal = null)
   if (!ok) return { status: "failed", error: `invalid decisions: ${errors.join("; ")}` };
   // 本相位的 create 落 source=sleep。来源从管道给而非从决策对象取——见
   // applyDecisions 的 @param config。
+  // #512：runId 也必须给——这是 sleep 唯一的真实铸造路径，漏了它，铸造出来的
+  // pattern 就只能追到「sleep 这条管道」，追不到「哪一轮 sleep」（正是 #512 要补的口子）。
   const { applied, failures, conflicts } = applyDecisions(
-    decisions, service, logger, snapshot, { ...config, mintSource: "sleep" }
+    decisions, service, logger, snapshot, { ...config, mintSource: "sleep", runId }
   );
   return {
     status: applied > 0 ? "ok" : "noop",
@@ -681,10 +960,16 @@ function deriveStatus(phases) {
   // 跳过），它同样算"有产出"——否则整轮会被误判成 noop，把真实变更报成空轮。
   const anyWork = list.some((p) => p.status === "ok" || p.status === "degraded");
   const anyDegraded = list.some((p) => p.status === "degraded");
+  // Issue #529：被打断（用户恢复活动）既不是失败也不是"没活干"。相位层已经用
+  // aborted 区分了这两种，整轮层若回落到 noop，审计行就又把"没跑完"记成"跑过、
+  // 没什么事"——所以这里也给它一个自己的名字。只在没有任何产出时生效：真的落了
+  // 东西就是 ok/degraded，真的报错就是 failed，二者都比 aborted 值得优先播报。
+  const anyAborted = list.some((p) => p.status === "aborted");
   if (anyDegraded) return "degraded";
   if (anyWork && anyError) return "degraded";
   if (anyError) return "failed";
   if (anyWork) return "ok";
+  if (anyAborted) return "aborted";
   return "noop";
 }
 
@@ -755,7 +1040,18 @@ export async function runSleep(ctx, service, config, logger, semantic = null, si
   } catch (error) {
     logger?.warn?.(`dsh-mneme sleep: failed to record audit run: ${String(error)}`);
   }
-  return { ok: status === "ok" || status === "degraded", status, runId, phases, receipt };
+  // Issue #529（续排）：给调度器的续排判据。两个条件缺一不可——
+  //   · 本轮**被预算截断**（conflict 相位报告还有没进这一轮的对）：说明池子没清空；
+  //   · 本轮**clean**：送出去的每一对都落地了，不是为了追一个永远失败的批次空转。
+  // `clean` 缺失时（该相位被 attempt 吞成 failed、或配置让它早退）按"不干净"算，
+  // 宁可少追一轮，也不要在失败状态下把间隔压到静默窗口。
+  const conflictPhase = phases.conflicts;
+  const backlog = Number(conflictPhase?.perRunSkipped ?? 0) > 0;
+  // clean 与 catchup 分开给：前者是"这一轮的活全落地了"，后者是"池子没清空 + 前者"。
+  // 合成一个字段会让"干净但没 backlog"看起来像出过问题，排查时反着读。
+  const clean = conflictPhase?.clean === true;
+  const catchup = backlog && clean;
+  return { ok: status === "ok" || status === "degraded", status, clean, catchup, backlog, runId, phases, receipt };
 }
 
 // ---------------------------------------------------------------- scheduler
@@ -788,6 +1084,36 @@ export function createSleepScheduler({
   let disposed = false;
   let idleTimer = null;
   let sleepAbort = null;
+  // Issue #529（C 项）：同一进程内的连续失败计数。失败（run 报 status="failed"
+  // 或抛错）+1，其余一律清零（ok/degraded/noop——noop 说明 LLM 通路是好的，
+  // 只是没活干，不该被当成失败拖着退避）。纯内存变量、宿主重启归零：跨重启的
+  // 冷却本来就由 lastRunAtSeed（#89/#291）负责，两者不重叠。
+  let consecutiveFailures = 0;
+  // Issue #529（续排）：上一轮报告"还有对没进这一轮、且送出去的全落地了"——池子没清空，
+  // 该接着追而不是等满一个最小间隔。只由 maybeSchedule 按 onRun 的返回置位，跑完一轮就
+  // 重新判：池子追干净或某一轮不 clean 时自动落回 false，不需要额外的复位路径。
+  let catchupWanted = false;
+  // Issue #529（续排）：进程内续排连击数。给"池子在长、每轮都 clean 但永远追不完"这类
+  // 库留一道刹车——用户持续写入时池子进得比追得快，光看 clean 会变成永不落地的每五分钟
+  // 一轮。超过上限就退回正常间隔，等下一个静默窗口重新起算。
+  let catchupStreak = 0;
+
+  // Issue #529：有效最小间隔 = 基数 × 2^连续失败数。关闭或尚无失败时逐字节
+  // 返回基数（默认关 = 行为与现状一致）。封顶取 max(基数, 24h) 而不是硬 24h：
+  // 指数再大也不会把用户自己配的大基数（允许到 168h）压小。
+  function effectiveMinIntervalMs() {
+    // Issue #529（续排）：还有 backlog 时把冷却项按 0 处理，让表落在**静默窗口**而不是
+    // 最小间隔上。不新增配置键：本轮的账本/更新写入会重置 lastWriteAt，下一轮自然至少
+    // 等一个 sleepIdleMinutes，这本身就是节流；再开一个键要连带 settings.js 白名单与
+    // test/api.test.js 的旗标计数锁，不值得为一件事动三个文件。
+    // 与连败互斥（同 issue 的第三条）：连续失败 > 0 时根本不追——两个逻辑抢同一只闹钟
+    // 最容易出"重排的是短的、判定的是长的"这种空转，互斥最省事。
+    if (catchupWanted && consecutiveFailures <= 0) return 0;
+    const base = (config.sleepMinIntervalHours ?? 8) * 3600000;
+    if (config.sleepFailureBackoff !== true || consecutiveFailures <= 0) return base;
+    const cap = Math.max(base, FAILURE_BACKOFF_CAP_MS);
+    return Math.min(base * 2 ** consecutiveFailures, cap);
+  }
 
   function armIdleTimer() {
     if (disposed || idleTimer) return;
@@ -798,8 +1124,10 @@ export function createSleepScheduler({
       idleTimer = null;
       // Issue #187：false = 撞上 CD（或 run 失败）——此前这里直接丢弃，"CD 到期"
       // 成了没有监听者的时刻，要等下一次写入才救回来。改为按剩余窗口重排。
+      // Issue #529（续排）：跑成了也未必收工——池子还有没进这一轮的对时要接着追，
+      // 而此时已经没有待触发的写入了，不在这里补挂就永远等不到下一轮。
       const ran = await maybeSchedule();
-      if (!ran) armNextWindow();
+      if (!ran || catchupWanted) armNextWindow();
     }, delay);
     idleTimer.unref?.();
   }
@@ -813,16 +1141,25 @@ export function createSleepScheduler({
     // lastRunAt === 0 表示从未跑过（此路径不该出现，防御性返回）。
     if (lastRunAt <= 0) return;
     const idleMs = (config.sleepIdleMinutes ?? 5) * 60000;
-    const cdMs = (config.sleepMinIntervalHours ?? 8) * 3600000;
-    const delay = Math.max(
+    // Issue #529：这里必须和 shouldRun 用同一个有效间隔，否则退避期里重排的闹钟
+    // 会在基数到点就响、然后被 shouldRun 否掉再重排——空转一串没有意义的定时器。
+    const cdMs = effectiveMinIntervalMs();
+    let delay = Math.max(
       lastRunAt + cdMs - now(),
       lastWriteAt + idleMs - now(),
       0
     ) + 1000;
+    // Issue #529（续排）：冷却项按 0 处理之后，静默项可能已经是负的（这一轮跑得久、
+    // 期间没有新写入），算出来只剩那 1 秒——追 backlog 不该变成秒级连发。续排下限钉在
+    // 一个静默窗口上：追得动就每轮追一批，但每批之间仍然让库安静下来。
+    // 有写入时静默项会自己变大（账本行落库会重置 lastWriteAt），这里只是保证下限。
+    if (catchupWanted) delay = Math.max(delay, idleMs + 1000);
     idleTimer = setTimeoutFn(async () => {
       idleTimer = null;
       const ran = await maybeSchedule();
-      if (!ran) armNextWindow();
+      // Issue #529（续排）：与 armIdleTimer 的回调同一条理由——追 backlog 的轮次
+      // 跑完必须自己补挂，否则续排在第二张表就断了。
+      if (!ran || catchupWanted) armNextWindow();
     }, delay);
     idleTimer.unref?.();
   }
@@ -833,7 +1170,9 @@ export function createSleepScheduler({
     if (at - lastWriteAt < (config.sleepIdleMinutes ?? 5) * 60000) return false;
     // lastRunAt === 0 means never ran — the min-interval check must not block
     // the very first cycle (a real run stamps a nonzero timestamp).
-    if (lastRunAt > 0 && at - lastRunAt < (config.sleepMinIntervalHours ?? 8) * 3600000) return false;
+    // Issue #529：连败退避开启时改用指数放大的有效间隔——恒定失败的模型不再按
+    // 固定节奏连发（#529 实测连续 23 轮 llm failed），只会越打越稀。
+    if (lastRunAt > 0 && at - lastRunAt < effectiveMinIntervalMs()) return false;
     return true;
   }
 
@@ -869,13 +1208,60 @@ export function createSleepScheduler({
       const result = await service.enqueue(() =>
         onRun ? onRun(abort.signal) : Promise.resolve({ ok: true, skipped: true })
       );
+      // Issue #529：连败计数只在这里加减。判据优先看 result.status——runSleep 的
+      // ok 只在 ok/degraded 时为真，noop（LLM 通路正常、只是没活干）和用户活动
+      // 打断都会给出 ok:false，把它当失败会让退避在自己工作良好的库里越退越长。
+      // 回落到 !result.ok 只是为了兼容注入的 no-op 桩（没有 status 字段）。
+      // result 为空（最小测试替身）＝完成且无失败，不动计数，与 #292 口径一致。
+      if (result) {
+        const failed = typeof result.status === "string" ? result.status === "failed" : !result.ok;
+        consecutiveFailures = failed ? consecutiveFailures + 1 : 0;
+        // Issue #529（续排）：判据只认 runSleep 给的 catchup——它是"池子还有没进这一轮
+        // 的对"且"送出去的每一对都落地了"二者的合取。**不要**在这里拿 status 反推：
+        // 全判 keep 的轮次 applied 恒为 0、status 是 noop，恰好在最该追的场景失效。
+        // 连续失败时不追（与退避互斥，见 effectiveMinIntervalMs），并把连击计数清零——
+        // 失败说明这轮的"追"没有意义，重新从正常节奏起算。
+        // 连击到顶就收手，并把连击清零——不清零的话这个进程从此再也不会追（streak 只增
+        // 不减，之后每一轮都被同一道闸挡下），"等下一个静默窗口重新起算"就成了空话。
+        // 收手必须落在 catchupWanted 这个状态上，不能只写在 effectiveMinIntervalMs 里：
+        // 那里改成"返回基数"之后，armNextWindow 仍会按 catchupWanted 把闹钟钉在静默
+        // 窗口上重排，于是每 5 分钟醒一次、每次都被 shouldRun 否掉再重排——没有 LLM
+        // 调用，但定时器链永远不断。
+        const wantCatchup = result.catchup === true && consecutiveFailures <= 0;
+        if (!wantCatchup || catchupStreak + 1 >= CATCHUP_STREAK_CAP) {
+          catchupStreak = 0;
+          catchupWanted = false;
+        } else {
+          catchupStreak += 1;
+          catchupWanted = true;
+        }
+      }
       return !!(result && result.ok);
     } catch (error) {
       logger?.warn?.(`dsh-mneme sleep: run failed: ${error?.message ?? error}`);
+      consecutiveFailures += 1; // Issue #529：抛错同样计入连败
+      // Issue #529（续排）：抛错也算失败，续排意图一并清掉——否则上一轮置位的状态会跟着
+      // 逃出 try 块，让下一次排表仍按静默窗口的空转节奏走。
+      catchupWanted = false;
+      catchupStreak = 0;
       return false;
     } finally {
       sleepAbort = null;
       running = false;
+      // Issue #529 review（CodeRabbit ②）：运行期间用户写入会走 noteWrite()，它把闹钟
+      // 按**那一次写入**重算了一遍——那可能是静默窗口的尾声。若这一轮结束时报告
+      // catchup=true，那只表可能几秒后就要响，下一批紧接着开跑，于是「让库安静一个
+      // 静默窗口再追」变成「跑完立刻再跑」。这里把已挂着的表撤掉重挂，交给
+      // armNextWindow 从**此刻**算出整整一个静默窗口。
+      // 反过来（不追的轮次）保留 noteWrite 挂的那只表：它是按用户最后一次写入算的，
+      // 正是「用户写完了、安静满一个窗口再说」的意思。
+      if (catchupWanted) {
+        if (idleTimer) {
+          clearTimeoutFn(idleTimer);
+          idleTimer = null;
+        }
+        armNextWindow();
+      }
     }
   }