claude-mem-lite 3.85.0 → 3.86.0

package/.claude-plugin/marketplace.json

@@ -10,7 +10,7 @@
   "plugins": [
     {
       "name": "claude-mem-lite",
-      "version": "3.85.0",
+      "version": "3.86.0",
       "source": "./",
       "description": "Persistent long-term memory for Claude Code via MCP — captures coding decisions, bugfixes, and context across sessions. Hybrid FTS5 + TF-IDF search with episode batching. Single SQLite DB, no external services. A lighter, lower-cost alternative to claude-mem (episode batching + a smaller model; cost savings are an internal estimate, not a measured benchmark)."
     }

package/.claude-plugin/plugin.json

@@ -1,6 +1,6 @@
 {
   "name": "claude-mem-lite",
-  "version": "3.85.0",
+  "version": "3.86.0",
   "description": "Persistent long-term memory for Claude Code via MCP — captures coding decisions, bugfixes, and context across sessions. Hybrid FTS5 + TF-IDF search with episode batching. Single SQLite DB, no external services. A lighter, lower-cost alternative to claude-mem (episode batching + a smaller model; cost savings are an internal estimate, not a measured benchmark).",
   "author": {
     "name": "sdsrss"

package/hook-context.mjs

@@ -61,6 +61,23 @@ export function computeAdaptiveWindows(db, project) {
   }
 }
 
+// D#192 (filed as D#189, re-scoped after measurement). These two are REACHABILITY bounds, not ranking bounds — the D#172 shape, and
+// the fifth surface it has been found on. Both SELECTs order by pure `created_at_epoch
+// DESC`; the JS below then re-sorts every candidate by `valueDensity`, a composite of
+// typeQuality x impBoost(1.0/1.5/2.0) x lessonBoost(1.0/1.3) / sqrt(cost) whose dynamic
+// range is far wider than the (1,2] that recency contributes. So the key the SQL sorts
+// on barely participates in the final order, and anything past the LIMIT is unreachable
+// however well it scores.
+//
+// Named rather than inline so benchmark/keyctx-pool-replay.mjs can patch a twin and
+// price a change to them. Extracting them changed no value.
+//
+// NOT yet widened: SessionStart injects on every start, so moving these is a
+// user-visible default-behaviour change to a released artifact (L3) and gets its own
+// round. Measured truncation as of 2026-09-01 is in the replay's header.
+export const KEYCTX_POOL_OBS = 50;
+export const KEYCTX_POOL_SESS = 10;
+
 /**
  * Select observations and sessions within a token budget using greedy knapsack.
  * Scores candidates by recency * importance, picks highest value-density first.
@@ -91,7 +108,7 @@ export function selectWithTokenBudget(db, project, budget = 2000) {
         OR (created_at_epoch > ? AND importance >= 3)
       )
     ORDER BY created_at_epoch DESC
-    LIMIT 50
+    LIMIT ${KEYCTX_POOL_OBS}
   `).all(project, tier1Ago, tier2Ago, tier3Ago);
 
   const sessPool = db.prepare(`
@@ -99,7 +116,7 @@ export function selectWithTokenBudget(db, project, budget = 2000) {
     FROM session_summaries
     WHERE project = ? AND created_at_epoch > ?
     ORDER BY created_at_epoch DESC
-    LIMIT 10
+    LIMIT ${KEYCTX_POOL_SESS}
   `).all(project, now_ms - windows.sessWindow);
 
   const selectedObs = [];

package/hook-memory.mjs

@@ -24,23 +24,65 @@ const MEMORY_LOOKBACK_MS = 60 * DAY_MS; // 60 days
  * importance × cross-project × OR × noise × cite). So whatever these numbers are, a row
  * outside the window cannot be picked however high its composite score would have been.
  *
- * The window has to be wide because the composite spread is enormous. Multiplying the
- * extremes of the JS factors (same-project, AND mode): best = 1.5 decision × 1.5 lesson
- * × 1.0 importance × 1.0 noise × 3.0 cite = 6.75; worst = 0.5 change × 1.0 no-lesson
- * × 0.6 importance × 0.2 noise × 0.4 cite = 0.024. That is a **281× spread**, so a row
- * ranked below the window on raw bm25 can outscore the window's contents by a wide
- * margin. (The audit estimated ">10×"; the factor tables say 281×.)
+ * The window has to be wide because the composite spread is wide — 281× by the tables,
+ * 60.0× as realised over the rows this pool can actually return. Multiplying the extremes
+ * of the JS factors
+ * (same-project, AND mode): best = 1.5 decision × 1.5 lesson × 1.0 importance × 1.0 noise
+ * × 3.0 cite = 6.75; worst = 0.5 change × 1.0 no-lesson × 0.6 importance × 0.2 noise ×
+ * 0.4 cite = 0.024, i.e. a **281× DECLARED range**. That is an upper bound off the factor
+ * tables, not a measurement: `citeFactor = 0.4` requires `uncited_streak >= 3`, and
+ * citation-decay resets the streak at 3 after demoting importance, so the steady state is
+ * bounded by [0,2] (scoring-sql.mjs, citeFactorJs docblock). Measured 2026-09-01 over the
+ * 2284 rows that clear `liveObsFilterSql` — the one predicate in the WHERE of BOTH SELECTs
+ * below — 0 are at streak >= 3, and recomputing the factor per row gives a REALISED range
+ * of 0.1125 … 6.750: a **60.0× spread** (81 rows hit the full best case, 0 the full worst).
+ * Each leg then narrows further and the spread survives the narrowing, which is why one
+ * number is quotable: live+`importance >= 1` n=2249 and +`notLowSignalTitleClause` n=2245
+ * both still read 60.00×. The CROSS leg is the exception — its own population
+ * (`type IN ('decision','discovery') AND importance >= 2`) is n=444 at **17.31×**, so if
+ * you are reasoning about `RERANK_POOL_CROSS_PROJECT` specifically, 60× is the wrong figure.
  *
- * HONEST LIMIT OF THIS FIX: because the spread is 281× and bm25 magnitude decays slowly
- * across a top-N window, NO finite pool size proves sufficiency. 30/15 is a 3× widening
- * chosen where cost stays flat (the SELECT carries `narrative`, so the pool is the
- * expensive term, not the sort) — it makes the bound loose, it does not remove it.
+ * COUNT THAT POPULATION WITH THE POOL'S OWN FILTER. Over the raw `observations` table it
+ * reads 0.0780 … 6.750 = 86.5×, and that is the number the first draft of this comment
+ * shipped: 1458 of 3742 rows (39.0%) are compressed or superseded, the row supplying the
+ * 0.0780 minimum (`id 10239`) carries `compressed_into = 10713`, and no such row can enter
+ * the pool, be scored, or be an endpoint of a range describing what the LIMIT cuts. Same
+ * error as v3.82.0's raw `importance = 3` count, overstating by 44% instead of a third.
  *
- * The bound is REMOVABLE, and deliberately was not removed: ordering both SELECTs by the
- * composite instead of raw bm25 is expressible in SQL today (every factor already has a
- * clause — TYPE_QUALITY_CASE / noisePenaltyClause / citeFactorClause — and the two
- * remaining factors, cross-project and OR, are per-QUERY constants that cannot affect
- * within-query order). That would make LIMIT a true ranking bound. It is not done here
+ * Quote whichever population you mean, and say which. Either is wide enough that a row
+ * ranked below the window on raw bm25 can outscore the window's contents by a wide margin.
+ * (The audit estimated ">10×".)
+ *
+ * HONEST LIMIT OF THIS FIX: because the spread is wide and bm25 magnitude decays slowly
+ * across a top-N window, NO finite pool size proves sufficiency. 30/15 makes the bound
+ * loose; it does not remove it. And it is bought, not free — the first draft of this
+ * comment claimed "cost stays flat" in the same breath as a parenthetical saying the pool
+ * is the expensive term, which is its own refutation. Measured instead:
+ * `node benchmark/rerank-pool-replay.mjs --cost` reads **+5% to +16% depending on caliber,
+ * and +6% to +10% with this one**. Whole-corpus runs of `--cost` on this machine: 1.058,
+ * 1.068, 1.078, 1.080, 1.083, 1.102 — same code, same corpus, pure machine variance, and
+ * the absolute ms/prompt moved 3.04 -> 1.80 across the same runs. Other calibers:
+ * 1.054–1.065 with the arm order held fixed, 1.063–1.156 with each arm alone in its own
+ * process (the closest shape to production).
+ *
+ * **Quote the range, re-measure, and never quote the absolute ms** — they vary by 2x with
+ * load while the ratio holds. The first draft of this comment quoted a flat 1.058x and said
+ * it reproduced to three digits; it does not, and every later run came in above it. See
+ * `costCompare`'s docblock for which caliber biases which way. Timing the SELECT alone
+ * reports ~1.00x and misses the JS scoring that the widened pool feeds — a different
+ * question, not a better answer.
+ *
+ * The bound is REMOVABLE, and deliberately was not removed. Ordering both SELECTs by the
+ * composite instead of raw bm25 is close to expressible in SQL, but "every factor already
+ * has a clause" overstated it: of the SEVEN factors, three have named clauses
+ * (TYPE_QUALITY_CASE / noisePenaltyClause / citeFactorClause); two more — the 1.5× lesson
+ * bonus and the `importance >= 2` step — still need one written, because the SQL forms
+ * that exist encode different weights and shapes (`1.0 + 0.3·lesson` and
+ * `0.5 + 0.5·importance` in search-engine.mjs's FULL_SCORE); and the last two,
+ * cross-project and OR, are constant WITHIN EACH SELECT — they differ between the
+ * same-project and cross-project legs, so they are not per-CALL constants, but they never
+ * vary among the rows any one LIMIT cuts, which is the only thing this argument needs.
+ * That would make LIMIT a true ranking bound. It is not done here
  * because `lib/inject-search-core.mjs:23-25` records this surface's "BM25-sort + JS
  * scoring" composition as a deliberate per-surface asymmetry (#8786), and this face is
  * one `benchmark/denoise-ab.mjs` is structurally blind to (its suites drive the
@@ -48,8 +90,13 @@ const MEMORY_LOOKBACK_MS = 60 * DAY_MS; // 60 days
  * project has repeatedly shipped regressions. Widening is monotone and provable;
  * re-ranking needs a ruler that does not exist yet.
  *
- * WHY WIDENING IS SAFE: the old window is a strict PREFIX of the new one (same ORDER BY,
- * larger LIMIT), so the new candidate set is a superset. `scored` sorts by composite and
+ * WHY WIDENING IS SAFE: in practice the old window is a PREFIX of the new one (same plan,
+ * same ORDER BY, larger LIMIT), so the new candidate set is a superset. "Strict" would be
+ * overclaiming — `ORDER BY bm25(...)` carries no tiebreaker, and this release's own
+ * fixture lesson is that a degenerate corpus makes `bm25()` return 0.000 for every row and
+ * ranking fall to rowid. What is measured rather than argued: `rerank-pool-replay.mjs`
+ * reports nonEmptyToEmpty = 0 across the whole corpus, i.e. no prompt loses its injection
+ * to the widening. `scored` sorts by composite and
  * the threshold filter is monotone in that score, so every row returned is at least as
  * good as the row it displaced. The only non-monotone stage is the term-coverage filter,
  * which is exactly why the pool needs slack rather than just `MAX_MEMORY_INJECTIONS`.

package/hook-update.mjs

@@ -21,6 +21,7 @@ import { httpConnectProxyFor, getViaConnectProxy } from './lib/proxy-fetch.mjs';
 import { acquireLock } from './lib/proc-lock.mjs';
 import { atomicWriteFileSync } from './lib/atomic-write.mjs';
 import { verifyReleaseFiles, verifyManifestSignature } from './lib/release-digest.mjs';
+import { detectInstallShape } from './lib/install-shape.mjs';
 
 // ── Configuration ──────────────────────────────────────────
 const GITHUB_REPO = 'sdsrss/claude-mem-lite';
@@ -156,8 +157,47 @@ export function isUpdateCheckDue() {
   } catch { return false; }
 }
 
+// D#187. `CLAUDE_PLUGIN_ROOT` is set in every hook and MCP process Claude Code
+// spawns, so inside those the env var answers "am I a plugin install?" perfectly —
+// which is why v3.84.1's fix, which reads it, was enough THERE. It is not set in a
+// plain terminal, and a plugin-only user typing `claude-mem-lite update` therefore
+// fell off both plugin paths at once: getCurrentVersion() returned '0.0.0' (so every
+// release compares as newer, forever), and isPluginMode() was false, so allowInstall
+// defaulted to true and downloadAndInstall laid a full managed tree into
+// ~/.claude-mem-lite — silently converting a plugin-only install into the hybrid
+// whose two trees D#184 documents drifting apart.
+//
+// Same root cause as PR #17: process ENVIRONMENT was the only install-shape
+// evidence consulted. detectInstallShape() reads the FILESYSTEM instead, so it
+// answers the same in a hook, in a terminal, and in a subprocess.
+//
+// Memoised per process. The reason first written here was wrong and the pre-tag review
+// traced it out: it claimed the memo keeps installExtractedRelease()'s post-install
+// isPluginMode() call stable across the managed-tree write. That call cannot depend on
+// this fallback at all — every path reaching installExtractedRelease is a plugin process
+// (checkForUpdate cannot reach downloadAndInstall while pluginMode is true, and
+// syncDataDirFromCache is only called from scripts/launch.mjs and
+// scripts/hook-launcher.mjs), so CLAUDE_PLUGIN_ROOT is set and isPluginMode()
+// short-circuits before pluginOnlyInstall() is consulted, before AND after the write.
+// What the memo actually buys: one readdirSync per process instead of one per call, and
+// a stable answer inside a long-lived MCP server whose plugin cache may be pruned or
+// re-populated underneath it while it runs.
+let shapeMemo;
+function installShape() {
+  if (shapeMemo === undefined) {
+    try { shapeMemo = detectInstallShape({ installDir: INSTALL_DIR }); } catch { shapeMemo = null; }
+  }
+  return shapeMemo;
+}
+
+/** True when this machine runs the plugin and has NO managed code install to update. */
+function pluginOnlyInstall() {
+  const shape = installShape();
+  return Boolean(shape && !shape.managed && shape.activePluginVersion);
+}
+
 function isPluginMode() {
-  return Boolean(process.env.CLAUDE_PLUGIN_ROOT);
+  return Boolean(process.env.CLAUDE_PLUGIN_ROOT) || pluginOnlyInstall();
 }
 
 // ── Dev Mode Detection ─────────────────────────────────────
@@ -313,6 +353,17 @@ export function getCurrentVersion() {
       if (pkg.version) return pkg.version;
     } catch { /* fall through to the last resort */ }
   }
+  // D#187: no env var in a plain terminal, so ask the filesystem which plugin
+  // version this machine actually runs. Without this a plugin-only user's
+  // `claude-mem-lite update` reads 0.0.0 and every release compares as newer.
+  const active = installShape()?.activePluginVersion;
+  if (active) {
+    try {
+      const pkg = JSON.parse(readFileSync(join(active.root, 'package.json'), 'utf8'));
+      if (pkg.version) return pkg.version;
+    } catch { /* the cache dir name IS the version — use it rather than 0.0.0 */ }
+    if (active.version) return active.version;
+  }
   return '0.0.0';
 }
 

package/lib/citation-tracker.mjs

@@ -115,6 +115,85 @@ export function extractCitationsFromTranscript(transcriptPath, opts = {}) {
   return ids;
 }
 
+/**
+ * D#179 prerequisite measurement: split each cited id into the responses that
+ * ACTED while naming it and the responses that only TALKED about it.
+ *
+ * `applyCitationDecay` promotes on any `#NN` in assistant text, so writing a release
+ * note, an audit, or a review that discusses a memory promotes that memory — including,
+ * self-referentially, a note observing that the memory is about to be evicted. Nothing
+ * downstream distinguishes "changed the code this lesson describes" from "mentioned the
+ * lesson's number". This function supplies the discriminator the deferred item asks for
+ * so the size of the contamination can be counted before anything is redesigned.
+ *
+ * The unit is a RESPONSE, keyed by `requestId` — one model turn, whose entries carry
+ * thinking / text / tool_use blocks under a shared id. That granularity is the point:
+ * a whole user-to-user exchange almost always contains some tool call, so bounding on
+ * user messages would classify nearly everything as "applied" and measure nothing.
+ *
+ * The key falls back `requestId || message.id || uuid`. In practice `message.id` carries
+ * every real Claude Code assistant entry that lacks a requestId, and it is still a
+ * per-response key, so the uuid arm is close to unreachable in production and exists only
+ * so a keyless entry is never merged into a shared bucket. What must NOT happen is any
+ * grouping coarser than one response: one tool call anywhere in a coarser bucket would
+ * mark every id in it as acted on, and the measurement would report no contamination on
+ * any coding session. (The pre-tag review pointed out that the earlier version of this
+ * sentence named only the uuid arm, and that the one test for it constructs a shape
+ * production never emits.)
+ *
+ * Returns a Map keyed by id: `{ withTool, textOnly }` response counts. An id is a pure
+ * MENTION when `withTool === 0`.
+ *
+ * NEITHER SIDE IS A BOUND, and an earlier draft of this comment claimed one. The proxy
+ * errs in both directions: naming an id in a response that also calls a tool is only
+ * co-occurrence, not evidence the lesson was followed (over-counts `withTool`); and an
+ * agent that acts in one response and cites the lesson in a later summary response gets
+ * classified pure-mention despite having applied it (over-counts `textOnly`). Use the
+ * split to size the question, not to settle it.
+ *
+ * @param {string} transcriptPath
+ * @param {object} [opts]
+ * @param {boolean} [opts.mainOnly=true] skip sidechain (subagent) records
+ * @returns {Map<number, {withTool: number, textOnly: number}>}
+ */
+export function classifyCitationContext(transcriptPath, opts = {}) {
+  const { mainOnly = true } = opts;
+  // requestId -> { ids:Set<number>, tool:boolean }
+  const responses = new Map();
+  for (const entry of readTranscriptEntries(transcriptPath)) {
+    if (entry.type !== 'assistant' || !entry.message) continue;
+    if (mainOnly && entry.isSidechain === true) continue;
+    const content = entry.message.content;
+    if (!Array.isArray(content)) continue;
+    const key = entry.requestId || entry.message.id || entry.uuid;
+    if (!key) continue;
+    let r = responses.get(key);
+    if (!r) { r = { ids: new Set(), tool: false }; responses.set(key, r); }
+    for (const block of content) {
+      if (block.type === 'tool_use') { r.tool = true; continue; }
+      // Only `text` blocks count as citing. `thinking` is deliberately excluded:
+      // extractCitationsFromTranscript scores text only, and the whole point is to
+      // classify the same numerator the decay loop acts on, not a wider one.
+      if (block.type !== 'text' || typeof block.text !== 'string') continue;
+      CITATION_RE.lastIndex = 0;
+      let m;
+      while ((m = CITATION_RE.exec(block.text))) {
+        const id = Number(m[1]);
+        if (Number.isInteger(id) && id > 0 && id < 1e7) r.ids.add(id);
+      }
+    }
+  }
+  const out = new Map();
+  for (const { ids, tool } of responses.values()) {
+    for (const id of ids) {
+      let e = out.get(id);
+      if (!e) { e = { withTool: 0, textOnly: 0 }; out.set(id, e); }
+      if (tool) e.withTool++; else e.textOnly++;
+    }
+  }
+  return out;
+}
+
 /**
  * Compute cite-recall stats for one transcript: how many of the `#NN`
  * references that surfaced in non-assistant content (hook injections, system

package/lib/injected-ids.mjs

@@ -28,6 +28,67 @@ export function injectedIdsFileName(project, sessionId) {
   return `${base}-${safe}`;
 }
 
+/**
+ * Namespace prefix for an id written into the shared injected-ids marker.
+ *
+ * D#188. The marker file is a UNION across hooks and across tables, and the
+ * convention for keeping those tables apart already existed — user-prompt-search.js
+ * writes `P<id>` for user_prompts rows and `D<id>` for deferred rows, with the
+ * comment "so obs ids can't collide in the shared injected-ids file". Observations
+ * are the incumbent namespace and stay bare. EVENTS were the one table that never
+ * got a prefix, even though the line three above pre-tool-recall.js's dedup filter
+ * says in as many words that "events share the numeric id space with observations"
+ * — the `src` tag added to carry exactly that distinction was not consulted by the
+ * dedup predicate sitting next to it.
+ *
+ * The consequence, measured on the live store (3747 observations, 91.6% of observation
+ * ids also existing as an event id, 2026-09-01T19:56Z): a UPS-injected observation #42
+ * made event #42 unreachable to the PreToolUse face for the 5-minute window, and vice
+ * versa. Replaying every real session's UPS-injected id set against the injectable
+ * events of the project the SESSION ran in: **14 collisions across 11 of 60 sessions
+ * (18.3%)**, 2026-09-01T20:17Z.
+ *
+ * WHICH PROJECT, precisely, because the draft got this wrong while arguing about
+ * populations. `scripts/pre-tool-recall.js` does `const project = inferProject()` once
+ * and feeds that single value to BOTH `crossHookInjectedFile(project, sessionId)` and
+ * the events `SELECT ... WHERE project = ?`. So the scoping that matters is the
+ * SESSION's project. The draft instead scoped by the injected observation's own
+ * `project` column — a different question, since the `ups`/`fyi` faces do inject
+ * cross-project rows — and reported 9 in 9 (15.5%), understating it. The pre-tag claims
+ * review caught the population, having reconstructed it independently at 12 in 10.
+ *
+ * The predicate, stated here because no harness is committed for it: seen-set per
+ * session = the shipped `extractInjectedBySurface(path).ups`; injectable events =
+ * `importance >= 2 AND superseded_at_epoch IS NULL AND file_paths NOT IN (NULL,'[]')`;
+ * session project recovered by matching each transcript directory against the DB's own
+ * project list (forward map, since flattening `/` and `_` to `-` is not invertible).
+ * Dropping the project condition entirely reports 72 in 41 — a population the
+ * project-filtered query can never reach.
+ *
+ * A SECOND consequence was claimed here before v3.86.0 was tagged and is FALSE, so it
+ * is recorded rather than deleted: bare event ids do flow into hook.mjs's
+ * `pathAInjectedIds`, which is handed to searchRelevantMemories and
+ * rankImperativeCandidates as an OBSERVATION exclude list — but they suppress
+ * NOTHING there, because `mergeCrossHookInjected` writes every id as a STRING and
+ * both consumers test `new Set(excludeIds).has(r.id)` against a NUMBER out of
+ * SQLite. Measured: excluding `1` returns nothing, excluding `'1'` returns the row.
+ * The pre-tag correctness review found this. What it exposes is a real and separate
+ * defect — that exclude list is inert for every id the marker holds as a string,
+ * observations included — which is D#193, not this one.
+ *
+ * Legacy in-flight files (bare ids that were a mix of both tables) keep their old
+ * meaning for at most DEDUP_STALE_MS and then rotate; there is deliberately no
+ * format version, because a 5-minute window of the PRE-EXISTING behaviour is a
+ * smaller cost than a schema every reader has to branch on.
+ *
+ * @param {number|string} id
+ * @param {'obs'|'evt'} [src]
+ * @returns {string}
+ */
+export function injectedIdKey(id, src = 'obs') {
+  return src === 'evt' ? `E${id}` : String(id);
+}
+
 /**
  * Runtime-dir FILE NAME for the SessionStart Key Context marker: the obs ids
  * ACTUALLY rendered into the <claude-mem-context> File Lessons / Key Context

package/lib/stats-quality.mjs

@@ -4,6 +4,7 @@
 // collide with CLI's `out()` stdout-write pattern.
 
 import { buildNotLowSignalSql } from './low-signal-patterns.mjs';
+import { liveObsFilterSql } from './inject-search-core.mjs';
 import { truncate } from '../format-utils.mjs';
 import { COMPRESSED_PENDING_PURGE } from '../utils.mjs';
 
@@ -23,6 +24,26 @@ export function computeNoiseGauge({ liveTotal, lowValCount, lowSignalCount }) {
   };
 }
 
+// D#191: the rule above is a rule about POPULATIONS, and until v3.86.0 it had only
+// been applied to computeNoiseGauge — a pure function that takes `liveTotal` from its
+// caller. Every query below ran on a bare `FROM observations`, so `stats --quality`
+// rendered ratios over all rows (compressed + superseded included) under labels that
+// name no population. Numerator and denominator were paired, so each ratio was
+// internally consistent; what was wrong was the population it described. Measured on
+// the live store 2026-09-01 (3742 rows total, 2284 live): all-time Lesson rate read
+// 59.6% where the live store is 92.9%, and all-time LOW_SIGNAL read 22.9% where the
+// live store is 1.1% — compression retires exactly the low-signal, lesson-less rows,
+// so an all-rows denominator reports a store roughly three decades of quality worse
+// than the one retrieval actually searches.
+//
+// `days` is user-settable (`stats --quality --days N`), so this is NOT confined to the
+// all-time bracket: the wider the window, the more compressed rows it sweeps in. The
+// filter is therefore applied to the window and per-type queries too, not only to the
+// two the review named, and all three now describe one population — the live corpus.
+//
+// Deliberately NOT filtered: `purgeRow`, whose entire subject is compressed rows.
+const LIVE = liveObsFilterSql('');
+
 export function computeQualityStats(db, { project, days }) {
   const projectFilter = project ? 'AND project = ?' : '';
   const baseParams = project ? [project] : [];
@@ -53,7 +74,7 @@ export function computeQualityStats(db, { project, days }) {
       COALESCE(SUM(CASE WHEN type = 'bugfix' THEN 1 ELSE 0 END), 0) as bugfix_total,
       COALESCE(SUM(CASE WHEN type = 'bugfix' AND ${unresolvedNarrativeExpr} THEN 1 ELSE 0 END), 0) as bugfix_unresolved
     FROM observations
-    WHERE created_at_epoch >= ? ${projectFilter}
+    WHERE created_at_epoch >= ? AND ${LIVE} ${projectFilter}
   `).get(cutoff, ...baseParams);
 
   const allTimeRow = db.prepare(`
@@ -62,7 +83,7 @@ export function computeQualityStats(db, { project, days }) {
       COALESCE(SUM(CASE WHEN lesson_learned IS NOT NULL AND lesson_learned != '' THEN 1 ELSE 0 END), 0) as with_lesson,
       COALESCE(SUM(CASE WHEN ${lowSignalIsMatchExpr} THEN 1 ELSE 0 END), 0) as low_signal
     FROM observations
-    WHERE 1=1 ${projectFilter}
+    WHERE ${LIVE} ${projectFilter}
   `).get(...baseParams);
 
   const typeRows = db.prepare(`
@@ -72,7 +93,7 @@ export function computeQualityStats(db, { project, days }) {
       COALESCE(SUM(CASE WHEN COALESCE(access_count, 0) > 0 THEN 1 ELSE 0 END), 0) as accessed,
       COALESCE(SUM(CASE WHEN lesson_learned IS NOT NULL AND lesson_learned != '' THEN 1 ELSE 0 END), 0) as with_lesson
     FROM observations
-    WHERE created_at_epoch >= ? ${projectFilter}
+    WHERE created_at_epoch >= ? AND ${LIVE} ${projectFilter}
     GROUP BY type
     ORDER BY total DESC
   `).all(cutoff, ...baseParams);
@@ -82,7 +103,7 @@ export function computeQualityStats(db, { project, days }) {
     FROM observations
     WHERE lesson_learned IS NOT NULL AND lesson_learned != ''
       AND COALESCE(access_count, 0) > 0
-      AND COALESCE(compressed_into, 0) = 0
+      AND ${LIVE}
       ${projectFilter}
     ORDER BY ac DESC
     LIMIT 5
@@ -109,7 +130,9 @@ export function formatQualityReport(data) {
   const lines = [];
   lines.push(`[mem] Quality snapshot${scope} — window: ${days}d`);
   lines.push('────────────────────────────────────────────────────');
-  lines.push(`  Writes (${days}d):     ${windowRow.total} observations`);
+  // Every ratio below divides live rows by live rows (D#191) — say so once, here,
+  // rather than qualifying each label and still leaving the brackets ambiguous.
+  lines.push(`  Writes (${days}d):     ${windowRow.total} live observations (compressed/superseded excluded throughout)`);
 
   const lessonPct = pct(windowRow.with_lesson, windowRow.total);
   const allLessonPct = pct(allTimeRow.with_lesson, allTimeRow.total);

package/npm-shrinkwrap.json

@@ -1,12 +1,12 @@
 {
   "name": "claude-mem-lite",
-  "version": "3.85.0",
+  "version": "3.86.0",
   "lockfileVersion": 3,
   "requires": true,
   "packages": {
     "": {
       "name": "claude-mem-lite",
-      "version": "3.85.0",
+      "version": "3.86.0",
       "dependencies": {
         "@modelcontextprotocol/sdk": "^1.26.0",
         "better-sqlite3": "^12.6.2",

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "claude-mem-lite",
-  "version": "3.85.0",
+  "version": "3.86.0",
   "description": "Persistent long-term memory for Claude Code via MCP — captures coding decisions, bugfixes, and context across sessions. Hybrid FTS5 + TF-IDF search with episode batching. Single SQLite DB, no external services. A lighter, lower-cost alternative to claude-mem (episode batching + a smaller model; cost savings are an internal estimate, not a measured benchmark).",
   "type": "module",
   "packageManager": "npm@10.9.2",

package/scripts/pre-tool-recall.js

@@ -8,7 +8,7 @@ import { existsSync, readFileSync, mkdirSync } from 'fs';
 import { basename, join } from 'path';
 import { resolveDataDir } from '../lib/resolve-data-dir.mjs';
 import { atomicWriteFileSync } from '../lib/atomic-write.mjs';
-import { injectedIdsFileName } from '../lib/injected-ids.mjs';
+import { injectedIdsFileName, injectedIdKey } from '../lib/injected-ids.mjs';
 import { liveObsFilterSql } from '../lib/inject-search-core.mjs';
 import { buildNotLowSignalSql } from '../lib/low-signal-patterns.mjs';
 import { recordHookError } from '../lib/hook-telemetry.mjs';
@@ -63,10 +63,28 @@ const RUNTIME_DIR = process.env.CLAUDE_MEM_RUNTIME_DIR || join(DATA_DIR, 'runtim
 import { DEDUP_STALE_MS as CROSS_HOOK_DEDUP_MS } from './prompt-search-utils.mjs';
 // Upper bound on the over-fetch the cross-hook dedup buys itself (ALGO-4). The dedup
 // runs in JS after the SELECTs, so each LIMIT is raised by the seen-set size to keep the
-// dedup a re-ranking rather than a truncation. This cap exists because the seen-set is
-// read from a file on disk: it is bounded by UPS's own per-prompt budget in practice
-// (MAX_RESULTS 3), but an unbounded value read off disk must never size a query. 5 is
-// well above that budget and still leaves the worst case at 2+5=7 rows per SELECT.
+// dedup a re-ranking rather than a truncation. This cap exists for one reason only: the
+// seen-set is read from a file on disk, and a number off disk must never size a query.
+//
+// It is NOT a sufficiency argument, and the first version of this comment claimed one —
+// "bounded by UPS's own per-prompt budget in practice (MAX_RESULTS 3)". That premise is
+// false. `crossHookInjectedFile` is a UNION across hooks and calls inside the staleness
+// window: `mergeCrossHookInjected` unions new ids into the old ones, UPS contributes up
+// to MAX_RESULTS per prompt and this script contributes up to `mergeCap` per trigger, so
+// nothing holds it at 3. Measured on this machine's `runtime/.claude-mem-injected-*`
+// markers (2026-09-01): id-count histogram 1x9, 2x1, 3x2, 16x1 over n=13, and 1x11, 2x1,
+// 3x1, 15x1 over n=14 an hour later. Read that as "3 is not a bound", not as a
+// distribution: it is one developer machine, the tail entry is a single long agent session
+// (on the re-measure the top entry was the measuring session itself), and the count is of
+// ids IN THE FILE while `readCrossHookInjected` returns an EMPTY set for a payload whose
+// `ts` is outside DEDUP_STALE_MS — file size and runtime seen-set size are not the same
+// quantity.
+//
+// The residual failure mode that premise was hiding, derived from the arithmetic and NOT
+// observed in the wild: at a seen-set of 16 the slack still caps at 5, so a Read fetches
+// obsLimit = 6, and if all 6 are in the seen-set the face goes silent again — the exact
+// failure ALGO-4 exists to fix. The cap is right (an unbounded LIMIT is worse), the
+// reassurance was wrong.
 const CROSS_HOOK_DEDUP_SLACK_MAX = 5;
 // v2.33.1: cooldown path is session-scoped so same-file-twice within one
 // session never re-injects (was: global file, 5-min window). Cross-session:
@@ -465,8 +483,11 @@ try {
     // On a Read (obsLimit 1 / eventsLimit 1) one dedup hit silenced the whole face.
     // Read the seen-set FIRST and over-fetch by its size so the dedup removes rows
     // from a pool that still has enough left to fill the cap. Capped at
-    // CROSS_HOOK_DEDUP_SLACK_MAX: the seen-set is bounded by UPS's own per-prompt
-    // budget in practice, but it is read off disk and must not size a query.
+    // CROSS_HOOK_DEDUP_SLACK_MAX purely because the seen-set is read off disk and a
+    // number off disk must not size a query — NOT because the seen-set is small. It is
+    // a cross-hook union over the staleness window and was measured at up to 16 ids on
+    // this machine, so with the slack saturated a Read can still fetch fewer rows than
+    // the seen-set holds and go silent. See the constant's docblock.
     const crossHookSeen = readCrossHookInjected(project, sessionId);
     const dedupSlack = Math.min(crossHookSeen.size, CROSS_HOOK_DEDUP_SLACK_MAX);
     const obsLimit = (isRead ? 1 : 2) + dedupSlack;
@@ -571,8 +592,12 @@ try {
       ...rows.map(r => ({ ...r, src: 'obs' })),
       ...eventRows.map(r => ({ ...r, src: 'evt' })),
     ];
+    // D#188: compare on the NAMESPACED key, not the bare number. The `src` tag two
+    // comments up exists precisely because the two tables share an id space; the
+    // predicate that consumed it did not use it, so an observation injected by UPS
+    // silently blocked the same-numbered event and vice versa.
     const dedupedRows = crossHookSeen.size > 0
-      ? sourcedRows.filter(r => !crossHookSeen.has(String(r.id)))
+      ? sourcedRows.filter(r => !crossHookSeen.has(injectedIdKey(r.id, r.src)))
       : sourcedRows;
 
     // Merge: observations first (they carry richer lesson_learned), then events.
@@ -725,7 +750,13 @@ try {
     // file so the next UPS prompt skips them too. Always write, even on
     // empty allRows, so the file's ts stays fresh for the no-op case where
     // we'd otherwise drift outside the dedup window.
-    mergeCrossHookInjected(project, allRows.map(r => r.id), sessionId);
+    // D#188: namespaced on write too — otherwise a bare event id here would keep
+    // blocking the same-numbered observation on the next UPS prompt. (An earlier
+    // version of this comment also claimed it leaked into hook.mjs's
+    // pathAInjectedIds; it reaches there, but suppresses nothing, because this
+    // function stringifies every id and that consumer compares against a numeric
+    // row id. That inertness is a separate live defect — D#193.)
+    mergeCrossHookInjected(project, allRows.map(r => injectedIdKey(r.id, r.src)), sessionId);
   } catch (e) {
     // Silent failure — never block editing, but record for self-observation.
     recordHookError('pre-recall:query', e, RUNTIME_DIR, { filePath });

package/scripts/user-prompt-search.js

@@ -815,6 +815,21 @@ async function main() {
       // tail of the SAME query is the same reach with one fewer FTS scan, and it cannot
       // regress the head — a flat cap of 2 over the merged set could have, by evicting
       // a third head row that ships today.
+      //
+      // "Additive" scopes to THIS SET, not to what finally ships. Downstream the merge
+      // appends `fileRows` after `ftsRows` (dedup by id) and then slices to MAX_RESULTS, and
+      // `deep` rows sort LAST within `ftsRows` (weaker |bm25|, ascending sort) — so a deep
+      // row takes a slot ahead of a file-recall row whenever `|head| < MAX_RESULTS` AND
+      // `|head| + |deep| + |fileRows| > MAX_RESULTS`, with at least one deep row and one
+      // fileRow present. The first condition is not redundant: `mainLimit` is
+      // `intent?.limit || MAX_RESULTS`, so head can already be 3 — and at head=3 the fileRow
+      // never boarded in the first place, so nothing is displaced. At head=2/deep=1/
+      // fileRows=1 the output is [h1, h2, d1] where it was [h1, h2, f1]; at
+      // head=1/deep=1/fileRows=1 nothing is displaced. The trade is one
+      // "filename matched, presumed deliberate" row for one "weak overall bm25, admitted
+      // only on an identifier hit" row. It is a real quality judgement and it is UNMEASURED
+      // — denoise-ab is structurally blind to this face. v3.85.0's release note called the
+      // whole change "strictly additive"; true of the bypass set, false of the output.
       const bypassFloorOk = (r) => typeof r.relevance === 'number' && Math.abs(r.relevance) >= bm25Floor;
       let bypassRows = [];
       if (IDENTIFIER_BYPASS && promptIdentifiers.length > 0) {