claude-mem-lite 5.5.0 → 5.5.1

package/.claude-plugin/marketplace.json

@@ -10,7 +10,7 @@
   "plugins": [
     {
       "name": "claude-mem-lite",
-      "version": "5.5.0",
+      "version": "5.5.1",
       "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": "5.5.0",
+  "version": "5.5.1",
   "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/deep-search.mjs

@@ -191,12 +191,18 @@ export function resolveDeepMode(explicitDeep, { surface, env = process.env } = {
  * D#3. benchmark/deep-search-holdout.mjs asks the suite's own queries of a corpus with
  * their relevant_ids deleted, so the correct answer is zero rows and every returned row is
  * a false positive by construction. It reads mean FP@10 = 10.00 across 12/12 queries: deep
- * fills every slot, every time. The single-query baseline returns 1-2 rows on the same
- * negatives — the flood is the UNION across paraphrase variants, which is also where deep's
- * recall win comes from, so this is not a bug to be thresholded away. Three gates were
- * tested against both arms and rejected; suppressing OR-fallback on rewrites takes deep
- * R@10 from 0.7383 to 0.3962, because the vocab-mismatch win IS that fallback. rrfFuseN
+ * fills every slot, every time. THE FLOOD IS NOT THE PARAPHRASE UNION, and an earlier
+ * version of this paragraph said it was ("the single-query baseline returns 1-2 rows on the
+ * same negatives"). Measured 2026-09-07, same fixture: the single-variant baseline already
+ * returns mean 9.42 of 10 (min 5, max 10, n=12), so fusion adds about half a slot to a page
+ * that was already full. A counterfactual names the real source — disabling the AND->OR
+ * fallback in search-engine.mjs takes mean FP@10 from 10.00 to 0.08, with 0/12 queries
+ * flooded instead of 12/12. Read that as a MECHANISM PROBE, not a candidate fix: the same
+ * fallback IS the vocab-mismatch recall win, and suppressing it on rewrites takes deep R@10
+ * from 0.7383 to 0.3962. Three gates were tested against both arms and rejected. rrfFuseN
  * fuses by RANK, so no magnitude signal survives the merge for a downstream floor to read.
+ * The same counterfactual explains why auto-escalation never fires here (D#8): with the
+ * fallback off, plain hits drop to min 0 and the escalation reach goes 0/12 -> 12/12.
  *
  * The discrimination is not available at this layer, so the honest move is to hand the
  * caller what the caller cannot otherwise see. Two things were missing:

package/hook-optimize.mjs

@@ -129,7 +129,8 @@ export function findReenrichCandidates(db, limit = 10, { scope = 'narrow', proje
         ${projectClause}
       ORDER BY
         CASE WHEN lesson_learned IS NOT NULL AND lesson_learned != '' THEN 0 ELSE 1 END,
-        created_at_epoch DESC
+        created_at_epoch DESC,
+        id DESC
       LIMIT ?
     `);
     return project ? stmt.all(project, limit) : stmt.all(limit);
@@ -149,7 +150,7 @@ export function findReenrichCandidates(db, limit = 10, { scope = 'narrow', proje
         AND LENGTH(COALESCE(narrative, '')) > 100
         AND ${notLowSignalTitleClause('')}
         ${projectClause}
-      ORDER BY created_at_epoch DESC
+      ORDER BY created_at_epoch DESC, id DESC
       LIMIT ?
     `);
     return project ? stmt.all(project, limit) : stmt.all(limit);
@@ -182,12 +183,15 @@ export function findReenrichCandidates(db, limit = 10, { scope = 'narrow', proje
         AND LENGTH(COALESCE(narrative, '')) > 100
         AND ${notLowSignalTitleClause('')}
         ${projectClause}
-      ORDER BY created_at_epoch DESC
+      ORDER BY created_at_epoch DESC, id DESC
       LIMIT ?
     `);
     return project ? stmt.all(project, limit) : stmt.all(limit);
   }
   if (scope === 'wide') {
+    // This pool's ORDER BY leads with a CASE term and spans lines, which is exactly why the
+    // first pass of the D#9 tiebreaker missed it. The full note lives in the default pool at
+    // the bottom of this function -- read it before touching any ORDER BY here.
     const stmt = db.prepare(`
       SELECT id, title, narrative, type, subtitle, concepts, facts, search_aliases, importance, project
       FROM observations
@@ -200,7 +204,8 @@ export function findReenrichCandidates(db, limit = 10, { scope = 'narrow', proje
         ${projectClause}
       ORDER BY
         CASE type WHEN 'decision' THEN 0 WHEN 'bugfix' THEN 1 WHEN 'refactor' THEN 2 ELSE 3 END,
-        created_at_epoch DESC
+        created_at_epoch DESC,
+        id DESC
       LIMIT ?
     `);
     return project ? stmt.all(project, limit) : stmt.all(limit);
@@ -215,7 +220,36 @@ export function findReenrichCandidates(db, limit = 10, { scope = 'narrow', proje
       AND search_aliases IS NULL
       AND optimized_at IS NULL
       ${projectClause}
-    ORDER BY created_at_epoch DESC
+    -- D#9: the id term is a REACHABILITY guard, not cosmetics. Every pool in this file is
+    -- ORDER BY created_at_epoch DESC LIMIT n feeding JS-side work, so a tie AT THE
+    -- BOUNDARY decides pool MEMBERSHIP. Measured 2026-09-07: two inserts land in the same
+    -- millisecond 272/300 times, and on a tie SQLite returns ASCENDING rowid -- the exact
+    -- opposite of the "newest first" this clause states -- so the newest rows fell out of
+    -- the pool whenever the clock had not ticked. SQLite's tie order is deterministic here
+    -- (8 rows on one epoch, 200 queries, one returned order), so this is not defending
+    -- against a varying plan; it is making the stated order total.
+    --
+    -- TWO DIFFERENT COUNTS, AND AN EARLIER DRAFT OF THIS COMMENT CONFLATED THEM. This
+    -- function, findReenrichCandidates, holds FIVE pools -- five db.prepare blocks:
+    -- 'scopes', 'aliases', 'concepts', 'wide', and this default 'narrow' one. The FILE
+    -- holds SEVEN "ORDER BY ... created_at_epoch DESC" sites: those five plus
+    -- extractUniqueConcepts and findMergeCandidates. All seven now carry the id term.
+    -- DO NOT GREP FOR THE ONE-LINE FORM: two of the seven ('scopes' and 'wide') lead with
+    -- a CASE ... term and span several lines, so grepping the joined
+    -- "created_at_epoch DESC, id DESC" spelling sees only five. That is how the first pass
+    -- read six and shipped 'wide' untiebroken -- the pool the DAILY unattended path passes
+    -- explicitly, on a budget of 6, where a boundary tie decides which rows reach the LLM
+    -- on a given run. Caught later by a test driving scope 'wide'; the original boundary
+    -- case drove only 'narrow', so nothing went red.
+    -- NOT FIXED, AND NAMED SO THE COMPLETENESS CLAIM IS TRUE: findSmartCompressCandidates
+    -- carries an eighth ordering, "ORDER BY project, created_at_epoch" -- ASCENDING, no id
+    -- term, no LIMIT. It is outside the seven by construction and is left alone under Iron
+    -- Law #1: it feeds clusterForCompression, whose vector branch seeds clusters in SQL
+    -- order, so a tie could move cluster membership -- but that branch needs
+    -- CLAUDE_MEM_VECTORS=1 and is off by default, and no failing case has been built.
+    -- Unjudged, not cleared.
+    -- This comment is INSIDE a template literal, so it must never contain a backtick.
+    ORDER BY created_at_epoch DESC, id DESC
     LIMIT ?
   `);
   return project ? stmt.all(project, limit) : stmt.all(limit);
@@ -632,7 +666,7 @@ export function extractUniqueConcepts(db, limit = 500, { project } = {}) {
     WHERE ${liveObsFilterSql('')}
       AND concepts IS NOT NULL AND concepts != ''
       ${projectClause}
-    ORDER BY created_at_epoch DESC
+    ORDER BY created_at_epoch DESC, id DESC -- D#9: total order, see findReenrichCandidates
     LIMIT 2000
   `);
   const rows = project ? stmt.all(project) : stmt.all();
@@ -807,7 +841,10 @@ export function findMergeCandidates(db, maxClusters = 5, { project } = {}) {
       AND title IS NOT NULL AND title != ''
       AND created_at_epoch > ?
       ${projectClause}
-    ORDER BY created_at_epoch DESC
+    -- D#9: this pool's head is what the keeper reduce falls back to on a full tie, so an
+    -- arbitrary tie order decides WHICH DUPLICATE SURVIVES a merge. Same-episode rows are
+    -- exactly that tie (same project, same importance, access_count 0, same millisecond).
+    ORDER BY created_at_epoch DESC, id DESC
     LIMIT 200
   `);
   const rows = project ? stmt.all(cutoff, project) : stmt.all(cutoff);
@@ -876,14 +913,27 @@ Return ONLY valid JSON:
     });
     if (!parsed || !parsed.should_merge) return { merged: false };
 
-    // Keeper = highest importance, then highest access_count. Previously access_count
-    // alone, so a critical (importance=3) but never-accessed observation lost the keeper
-    // role to a trivial (importance=1) accessed one and was compressed away.
+    // Keeper = highest importance, then highest access_count, then highest id. Previously
+    // access_count alone, so a critical (importance=3) but never-accessed observation lost
+    // the keeper role to a trivial (importance=1) accessed one and was compressed away.
+    //
+    // D#9: the third term is the one that makes this TOTAL. Without it a full tie fell
+    // through to `cluster[0]` — the SQL head — and same-episode duplicates are exactly a
+    // full tie: same project, same importance, access_count 0, and a created_at_epoch in
+    // the same millisecond 272 times out of 300 (measured 2026-09-07). On a tie SQLite
+    // returns ASCENDING rowid while an untied pool returns the newest first, so which
+    // duplicate survived flipped on whether two writes straddled a millisecond. Ordering
+    // the pool alone would not have been enough: this reduce is exported to callers that
+    // build their own cluster, so it has to be total on its own. Highest id = written last
+    // = the version whose content the merged summary should be anchored on.
     const keeper = cluster.reduce((best, o) => {
       const oi = o.importance || 1,
         bi = best.importance || 1;
       if (oi !== bi) return oi > bi ? o : best;
-      return (o.access_count || 0) > (best.access_count || 0) ? o : best;
+      const oa = o.access_count || 0,
+        ba = best.access_count || 0;
+      if (oa !== ba) return oa > ba ? o : best;
+      return (o.id || 0) > (best.id || 0) ? o : best;
     }, cluster[0]);
     const others = cluster.filter((o) => o.id !== keeper.id);
     // Floor the merged importance at the cluster max — merging must never silently

package/npm-shrinkwrap.json

@@ -1,12 +1,12 @@
 {
   "name": "claude-mem-lite",
-  "version": "5.5.0",
+  "version": "5.5.1",
   "lockfileVersion": 3,
   "requires": true,
   "packages": {
     "": {
       "name": "claude-mem-lite",
-      "version": "5.5.0",
+      "version": "5.5.1",
       "os": [
         "darwin",
         "linux"

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "claude-mem-lite",
-  "version": "5.5.0",
+  "version": "5.5.1",
   "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",