claude-mem-lite 6.10.3 → 6.12.0

package/.claude-plugin/marketplace.json

@@ -9,7 +9,7 @@
   "plugins": [
     {
       "name": "claude-mem-lite",
-      "version": "6.10.3",
+      "version": "6.12.0",
       "source": "./",
       "homepage": "https://github.com/sdsrss/claude-mem-lite",
       "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": "6.10.3",
+  "version": "6.12.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/README.md

@@ -237,6 +237,25 @@ rm -rf ~/claude-mem-lite/   # pre-v0.5 unhidden (if not auto-moved)
     repos/               # Shallow-cloned source repos
 ```
 
+## Upgrading to 6.11.0
+
+**One default changes: re-enrich stops leaving part of its budget idle.** It reserves half of
+each run's budget for two backfill passes and gives its main scope the rest. When the main
+scope had fewer rows to enrich than its share, the remainder went unspent; it now goes to the
+backfills. The daily unattended pass runs once per machine per day, over all projects
+together, so with an empty main pool it now makes up to 6 of these LLM calls a day where it
+made 3. The ceiling of 6 is unchanged — it was always the declared budget — and a separately
+budgeted scope-classification pass, also unchanged, can add up to 6 more short calls. A manual
+`claude-mem-lite optimize --run` or `mem_optimize` behaves the same way. No schema change and
+no migration: an older build still opens the database, so reverting is pinning
+`claude-mem-lite@6.10.3`.
+
+**One security fix does not reach data you already have.** In some combinations of two
+labelled credentials on one line — `token: <v> secret: <v>` is one, when the first value ends
+in a letter — earlier versions redacted the first and stored the second as typed. Values on
+separate lines were never affected. This release fixes the write path; nothing already in
+your database is rewritten.
+
 <!-- normalize-per-project-note:start -->
 ## Upgrading to 6.8.0
 
@@ -386,6 +405,7 @@ surface — reach them through the CLI column in the second table.
 /mem <query>               # Shorthand for search
 /lesson <text>             # Save a non-obvious lesson to the events table (v2.31.0)
 /bug <text>                # Log a known bug + repro steps to the events table (v2.31.0)
+/verify                    # Check memories against the current code; correct stale ones after you approve
 ```
 
 ### Efficient Search Workflow

package/README.zh-CN.md

@@ -199,6 +199,20 @@ rm -rf ~/claude-mem-lite/   # v0.5 前的非隐藏目录（如未自动迁移）
     repos/               # 浅克隆的源代码仓库
 ```
 
+## 升级到 6.11.0
+
+**只有一个默认行为变化：re-enrich 不再让一部分预算空着。** 它为两个回填任务预留每次运行一半的
+预算，其余给主范围。以前主范围待处理的行数少于它那一份时，剩下的额度就空着不用；现在转给回填
+任务。每日后台任务是**每台机器每天一次、对所有项目合并运行**，所以主池为空时，它现在每天最多
+做 6 次这类 LLM 调用，而以前是 3 次。上限 6 没变——这一直是声明的预算；另有一个单独计预算的
+「范围分类」任务，本版未改动，最多还会再加 6 次简短调用。手动运行 `claude-mem-lite optimize --run`
+或 `mem_optimize` 行为相同。没有 schema 变更、没有迁移：旧版本仍能打开数据库，回退就是固定到
+`claude-mem-lite@6.10.3`。
+
+**有一个安全修复不会作用于你已有的数据。** 同一行里两个带标签的凭据，在某些组合下——例如
+`token: <v> secret: <v>`，且第一个值以字母结尾——以前的版本会脱敏第一个、把第二个按原样存下来。
+分行写的值从未受影响。本版本修的是写入路径；数据库里已有的内容不会被改写。
+
 <!-- normalize-per-project-note:start -->
 ## 升级到 6.8.0
 
@@ -327,6 +341,7 @@ README 和 `docs/ARCHITECTURE.md` 都钉在它上面。）
 /mem <query>               # search 的简写
 /lesson <text>             # 保存非显而易见的经验到 events 表（v2.31.0）
 /bug <text>                # 记录已知 bug + 复现步骤到 events 表（v2.31.0）
+/verify                    # 对照当前代码核查记忆；你确认后才改正过期的记忆
 ```
 
 ### 高效搜索工作流

package/cli/common.mjs

@@ -399,6 +399,13 @@ export const KNOWN_CLI_FLAGS = new Set([
   // warn-on-every-unknown-flag flip turned the omission into a false warning on a
   // documented, working command.
   'prompts-limit',
+  // `verify-apply --apply --digest <d>` / `--undo <backup>` — read as flags.apply / .digest / .undo in
+  // cli/verify-apply.mjs. Missing here, a working apply printed "Unknown flag --apply — ignored,
+  // it had no effect" beside its own read-back. Pinned by tests/verify-apply-cli.test.mjs.
+  'apply',
+  'digest',
+  'print-project',
+  'undo',
   // Entries here MUST be read by a `claude-mem-lite` subcommand. A flag that no
   // command reads is worse than an absent one: it converts the "ignored, it had no
   // effect" warning into silence, so the user's dropped flag reads as accepted.

package/cli/verify-apply.mjs

@@ -0,0 +1,197 @@
+// cli/verify-apply.mjs — `claude-mem-lite verify-apply <proposals.json> [--project P]`
+// (dry run), `... --apply --digest <d>`, and `claude-mem-lite verify-apply --undo <backup.json>`.
+//
+// The write step of /verify (commands/verify.md). The agent proposes; this command is the only
+// thing that writes. It defaults to a dry run that prints the new text itself and a digest, and
+// --apply refuses unless it is handed that digest back: what the user approved is what lands,
+// and a proposals file or a row that changed in between is refused rather than applied. All
+// policy lives in lib/verify-apply-core.mjs; this file is I/O, formatting and exit codes.
+
+import { readFileSync } from 'fs';
+import { join } from 'path';
+import { DB_DIR } from '../lib/data-paths.mjs';
+import { atomicWriteFileSync } from '../lib/atomic-write.mjs';
+import { inferProject } from '../utils.mjs';
+import { resolveProject } from '../project-utils.mjs';
+import {
+  parseProposals,
+  planVerifyApply,
+  planDigest,
+  priorVerifyApplies,
+  runVerifyApply,
+  undoVerifyBackup,
+  markUndone,
+} from '../lib/verify-apply-core.mjs';
+import { parseArgs, out, fail, rejectBareStringFlags } from './common.mjs';
+
+const USAGE =
+  '[mem] Usage: claude-mem-lite verify-apply <proposals.json> [--project P]          (dry run)\n' +
+  '       claude-mem-lite verify-apply <proposals.json> [--project P] --apply --digest <d>\n' +
+  '       claude-mem-lite verify-apply --undo <backup.json>';
+
+const SNIPPET_CONTEXT = 60;
+const BACKUP_DIR = join(DB_DIR, 'backups');
+// The commands this prints must run as printed. `claude-mem-lite` is on PATH only after an
+// optional global npm install (which may also be a different, stale code home), so name the
+// node binary and THIS cli.mjs — the one that produced the plan.
+/** A path as one shell word: as-is when it is plain, single-quoted otherwise. */
+const shellWord = (s) => (/^[\w@%+=:,./-]+$/.test(s) ? s : `'${s.replace(/'/g, `'\\''`)}'`);
+const SELF = process.argv[1] ? `node ${shellWord(process.argv[1])}` : 'claude-mem-lite';
+
+function readJson(path, what) {
+  try {
+    return { value: JSON.parse(readFileSync(path, 'utf8')) };
+  } catch (e) {
+    return { error: `[mem] Cannot read ${what} ${path}: ${e.message}` };
+  }
+}
+
+/**
+ * The changed region of a field, with context. The changed part is printed IN FULL, never
+ * clipped: the digest covers the whole text, so any cap here would let the user approve text
+ * they were never shown (re-review of dcc8f72, P2-2). Only unchanged context is elided.
+ */
+function snippet(before, after) {
+  const a = before === null || before === undefined ? '' : String(before);
+  const b = String(after);
+  if (a === b) return ['    (unchanged)'];
+  let start = 0;
+  while (start < a.length && start < b.length && a[start] === b[start]) start++;
+  let endA = a.length;
+  let endB = b.length;
+  while (endA > start && endB > start && a[endA - 1] === b[endB - 1]) {
+    endA--;
+    endB--;
+  }
+  const from = Math.max(0, start - SNIPPET_CONTEXT);
+  const lead = from > 0 ? '…' : '';
+  const tail = (s, end) => (end + SNIPPET_CONTEXT < s.length ? '…' : '');
+  return [
+    `    - ${lead}${a.slice(from, Math.min(a.length, endA + SNIPPET_CONTEXT))}${tail(a, endA)}`,
+    `    + ${lead}${b.slice(from, Math.min(b.length, endB + SNIPPET_CONTEXT))}${tail(b, endB)}`,
+  ];
+}
+
+function describe(p) {
+  const head = `  #${p.id} [${p.verdict}] ${p.action} — evidence: ${p.evidence}`;
+  if (p.action === 'retire') return [head, '    retired with no replacement (kept as history)'];
+  const fields =
+    p.action === 'edit'
+      ? Object.entries(p.set)
+      : ['title', 'narrative', 'lesson_learned', 'importance', 'facts', 'concepts']
+          .filter((k) => p[k] !== undefined)
+          .map((k) => [k, p[k]]);
+  const lines = [head];
+  if (p.action === 'replace') lines.push('    new memory supersedes this one; unlisted fields are copied');
+  for (const [k, v] of fields) lines.push(`   ${k}:`, ...snippet(p.before[k], v));
+  return lines;
+}
+
+function undo(db, path) {
+  const { value, error } = readJson(path, 'backup');
+  if (error) return fail(error);
+  const { errors, restored } = undoVerifyBackup(db, value);
+  if (restored.length === 0 && errors.length)
+    return fail(`[mem] Undo refused, nothing written:\n  ${errors.join('\n  ')}`);
+  for (const r of restored) {
+    out(
+      `  #${r.id} restored${r.replacementRetired ? ` (replacement #${r.replacementRetired} retired)` : ''}`,
+    );
+  }
+  if (errors.length) return fail(`[mem] Undo read-back found problems:\n  ${errors.join('\n  ')}`);
+  out(`[mem] Undo complete: ${restored.length} row(s) restored.`);
+  // The restore is committed; marking the file only stops a second run early. If the mark
+  // cannot be written, a second undo is still refused (the rows no longer match the apply's
+  // record), so this is a warning, not a failure of the undo that already happened.
+  try {
+    atomicWriteFileSync(path, JSON.stringify(markUndone(value), null, 1));
+  } catch (e) {
+    process.stderr.write(
+      `[mem] Warning: undo is done, but ${path} could not be marked as undone: ${e.message}\n`,
+    );
+  }
+}
+
+export function cmdVerifyApply(db, args) {
+  const { positional, flags } = parseArgs(args);
+  if (rejectBareStringFlags(flags, ['project', 'undo', 'digest'])) return;
+  // The project verify-apply targets when --project is omitted, printed so /verify can export
+  // exactly that project (export's --project matching is fuzzy; this is not).
+  if (flags['print-project'] === true) return out(inferProject());
+  // Boolean means boolean: `--apply=false` / `--apply no` must not apply.
+  if (flags.apply !== undefined && flags.apply !== true)
+    return fail(`[mem] --apply takes no value.\n${USAGE}`);
+
+  if (flags.undo !== undefined) {
+    if (positional.length || flags.apply || flags.digest) return fail(USAGE);
+    return undo(db, flags.undo);
+  }
+
+  const file = positional[0];
+  if (!file || positional.length > 1) return fail(USAGE);
+  const { value, error } = readJson(file, 'proposals');
+  if (error) return fail(error);
+
+  const parsed = parseProposals(value);
+  if (parsed.errors.length)
+    return fail(`[mem] Invalid proposals, nothing written:\n  ${parsed.errors.join('\n  ')}`);
+
+  const project = flags.project ? resolveProject(db, flags.project, { mode: 'write' }) : inferProject();
+  const { plan, errors } = planVerifyApply(db, parsed.entries, { project });
+  if (errors.length) return fail(`[mem] Refused, nothing written:\n  ${errors.join('\n  ')}`);
+  const digest = planDigest(
+    plan,
+    project,
+    priorVerifyApplies(
+      BACKUP_DIR,
+      plan.map((p) => p.id),
+    ),
+  );
+
+  if (!flags.apply) {
+    out(`[mem] verify-apply plan — project ${project}, ${plan.length} change(s):`);
+    for (const p of plan) for (const line of describe(p)) out(line);
+    out(`[mem] Plan digest: ${digest}`);
+    out('[mem] Dry run — nothing written. After the user approves exactly this plan, run:');
+    out(
+      `  ${SELF} verify-apply ${shellWord(file)} --project ${shellWord(project)} --apply --digest ${digest}`,
+    );
+    return;
+  }
+
+  if (!flags.digest) {
+    return fail('[mem] --apply requires --digest <d> from the dry run the user approved. Nothing written.');
+  }
+  if (flags.digest !== digest) {
+    return fail(
+      '[mem] Plan digest mismatch: the proposals file or the memories changed since the dry run. ' +
+        'Nothing written — re-run the dry run and get the new plan approved.',
+    );
+  }
+
+  let run;
+  try {
+    run = runVerifyApply(db, plan, { backupDir: BACKUP_DIR });
+  } catch (e) {
+    // One failure happens AFTER the commit: the undo record could not be written. The changes
+    // are in the database then, and saying "nothing written" would be false.
+    if (e.message.startsWith('applied, but')) {
+      return fail(
+        `[mem] APPLIED — the changes are in the database, but ${e.message.slice('applied, but '.length)}`,
+      );
+    }
+    return fail(`[mem] ${e.message}`);
+  }
+  for (const c of run.checks) {
+    out(
+      `  #${c.id} ${c.action}${c.newId ? ` → #${c.newId}` : ''}: ${c.ok ? 'ok' : `MISMATCH (${c.problems.join('; ')})`}`,
+    );
+  }
+  out(`[mem] Backup: ${run.backupPath}`);
+  out(
+    `[mem] To undo (only while these rows are untouched): ${SELF} verify-apply --undo ${shellWord(run.backupPath)}`,
+  );
+  if (run.checks.some((c) => !c.ok)) {
+    fail('[mem] Applied, but read-back found mismatches — show the MISMATCH lines above to the user.');
+  }
+}

package/cli.mjs

@@ -14,6 +14,7 @@ const CLI_COMMANDS = new Set([
   'update',
   'export',
   'restore',
+  'verify-apply',
   'compress',
   'maintain',
   'optimize',

package/commands/verify.md

@@ -0,0 +1,156 @@
+---
+name: verify
+description: "Use when: the user explicitly asks to verify, audit or correct their stored memories against the current code (e.g. \"check my memories for stale ones\", /verify). You check each memory with read-only repo tools and propose corrections; nothing is written until the user approves the exact plan. Not for routine recall or saving."
+---
+
+# /verify — check memories against the code, then correct the stale ones
+
+Memories go stale: a bug recorded as open gets fixed, a measurement gets retracted, a
+mechanism is replaced. Measured on 118 live memories across 7 repos, ~10% were STALE and
+~14% PARTIAL, and most went stale within a day of being saved. No automatic pass catches
+this — cheap single-shot models misjudged it (precision 0.36) and model-written corrections
+were false in 28 of 72 cases. What works is YOU reading the code: you propose, the user
+approves the exact plan, and `verify-apply` is the only thing that writes.
+
+(If another plugin also defines `/verify`, this one is `/claude-mem-lite:verify`.)
+
+## Arguments
+
+- `--from <YYYY-MM-DD>`: only memories saved on or after this date (default: all live).
+- `--ids 12,34`: only these memories.
+- `--project <name>`: a project other than the current one.
+
+## Step 1 — Select
+
+Get the exact project name first. For the current project (the usual case), run from the
+project's directory:
+
+```bash
+node "${CLAUDE_PLUGIN_ROOT}/cli.mjs" verify-apply --print-project
+```
+
+It prints the canonical name (e.g. `dev--my-app`) that verify-apply itself will target. For
+another project, use the name the user gave only if it already has the `parent--name` shape;
+otherwise ask. Always pass that exact name — `export --project` matches loosely and can pick a
+neighbouring project from a short name.
+
+```bash
+node "${CLAUDE_PLUGIN_ROOT}/cli.mjs" export --project <project> [--from <date>] > <scratch>/memories.json
+```
+
+Every row carries `id`, `project`, `type`, `title`, `narrative`, `facts`, `lesson_learned`,
+`files_modified`, `created_at`. Check that every row's `project` is the name you passed. With
+`--ids`, filter the file to those ids. The repository to check them against is the current
+directory for the current project; for another project, ask the user where it lives.
+`files_modified` holds both absolute and repo-relative paths. Tell the user how many memories
+you are about to check.
+
+## Step 2 — Verify (read-only)
+
+For EACH memory, answer: *if this memory were shown to an agent working in this repo today,
+would anything it asserts mislead that agent?*
+
+1. List its concrete, checkable claims: identifiers, file paths, `file:line` references,
+   constants, counts, behaviours, "X is still broken", "Y was measured at Z".
+2. Check each against the current tree (Grep, Read) and, where useful, the history since
+   `created_at` (`git log --since=<created_at> -- <files>`, `git log -S<token>`, `git show`).
+3. Pick one verdict:
+   - **VALID** — every checkable claim still holds.
+   - **STALE** — at least one specific claim is contradicted by the tree or history: a
+     renamed/removed symbol, a changed value or default, a changed behaviour, a bug presented
+     as open that has since been fixed, a count that moved, a measurement later retracted.
+   - **PARTIAL** — the main point holds; a secondary detail (a line number, a count, a minor
+     mechanism) is out of date.
+   - **UNVERIFIABLE** / **NO_CODE_CLAIM** — leave these alone.
+
+Rules that the measurement showed matter:
+- A file having changed is NOT a contradiction. You need a line, a diff hunk, a commit, or a
+  command's output that contradicts a specific claim.
+- Output you did not see is not a contradiction. A grep that printed nothing, or output cut
+  off by `head` or a size limit, proves nothing — re-run it untruncated before calling a claim
+  stale.
+- A number only a test run could confirm (a test count, a coverage figure) is a dated
+  measurement: stale only if a later commit or document reports a different value, not
+  because you cannot re-run it here.
+- A record of what happened (what was measured then, what a review found) stays true as
+  history. It is stale only if it would mislead about the PRESENT.
+- A note that already records its own fix is not stale because the fix commit landed later.
+- Do not write, stash, check out or run tests while verifying.
+
+More than ~25 memories: split them into batches and give each batch to a read-only subagent
+with the rubric above; have each subagent write its results to a file with a bash heredoc and
+reply with only the path. Treat a subagent's verdict as a lead: before proposing anything,
+re-open every cited `file:line`, commit or command yourself.
+
+## Step 3 — Draft proposals (STALE and PARTIAL only)
+
+If every memory is VALID (or UNVERIFIABLE / NO_CODE_CLAIM), stop here: report the counts to
+the user and say nothing needs changing. Do not run Step 4 with an empty proposals file.
+
+Write `<scratch>/proposals.json` — a JSON array, one entry per memory to change:
+
+```json
+[
+  { "id": 52, "action": "replace", "verdict": "STALE",
+    "title": "...", "narrative": "...", "lesson_learned": "...",
+    "evidence": "7bc8ba9; hook-optimize.mjs:1371-1383" },
+  { "id": 64, "action": "edit", "verdict": "PARTIAL",
+    "set": { "narrative": "..." }, "evidence": "hook-llm.mjs:1359-1361" },
+  { "id": 201, "action": "retire", "verdict": "STALE", "evidence": "600c744" }
+]
+```
+
+- **edit** — the stale part is one detail in `title`, `narrative`, `lesson_learned`,
+  `importance` or `concepts`. Copy the original text into `set` and change only the stale words.
+- **replace** — the memory's claim is wrong but its lesson is still worth keeping, OR the
+  stale detail sits in `facts` (edit cannot change `facts`). Write the corrected memory; give
+  `facts` (an empty string drops them) or `concepts` when those are what is stale. Omitted
+  fields are copied from the original, which stays as history.
+- **retire** — nothing in it is worth keeping (e.g. a mid-debug note about a failure fixed
+  minutes later).
+- `evidence` is required: the commit, the `file:line`, or the command and its output (for
+  something outside the repo, e.g. a tool version) that shows the memory is out of date.
+- `lesson_learned` is at most 500 characters. Keep the memory's language.
+
+## Step 4 — Show the plan and get approval
+
+```bash
+node "${CLAUDE_PLUGIN_ROOT}/cli.mjs" verify-apply <scratch>/proposals.json --project <project>
+```
+
+This is a dry run: it validates every entry against the database, writes nothing, prints each
+change as `-` old / `+` new text (the changed text in full), and ends with a **plan digest**
+and the exact apply command.
+Show the user that output as it is (do not summarise the changes away), plus your counts of
+VALID / STALE / PARTIAL, and ask for approval. If the dry run refuses an entry, fix the
+proposal — never work around it with `update`, `save` or `delete`. If you change the proposals
+after the user saw them, run the dry run again and show the new plan: the digest changes, and
+the old one will be refused.
+
+## Step 5 — Apply, only after the user approves that plan
+
+Run exactly the command the dry run printed:
+
+```bash
+node "${CLAUDE_PLUGIN_ROOT}/cli.mjs" verify-apply <scratch>/proposals.json --project <project> --apply --digest <digest>
+```
+
+It refuses if the proposals or the memories changed since the dry run. Otherwise it backs up
+every target row, applies all entries in one transaction (all or nothing), reads each row back
+and prints `ok` or `MISMATCH`, then prints the backup path and the undo command. Report the
+result and the undo command to the user. Reading the exit status:
+- exit 0 — applied, every row read back `ok`.
+- exit 1 with `MISMATCH` lines — applied, but a row did not read back as planned. Show those
+  lines; do not re-run the apply.
+- exit 1 with a message starting `APPLIED` — the changes are in the database, but no undo
+  record could be written. Say exactly that.
+- any other exit 1 — nothing was written. Say why.
+
+Undo (`verify-apply --undo <backup>`) only works while the changed rows' content and state are
+as the apply left them (usage counters such as access counts do not count): it refuses once any
+of them changes again — an edit, a supersede, or a routine background pass (importance decay,
+alias or concept backfill) — and it runs at most once. It then prints `Undo complete`; a `Warning: … could not be marked as undone` line means
+the undo still happened. After an undo, the earlier apply command is refused: applying the
+same changes again needs a new dry run and the user's approval of its new digest. That refusal
+rests on the backup file: once it is deleted, the earlier command would match again, so never
+re-run an apply command from an earlier approval.