claude-mem-lite 6.11.0 → 6.12.1

package/.claude-plugin/marketplace.json

@@ -9,7 +9,7 @@
   "plugins": [
     {
       "name": "claude-mem-lite",
-      "version": "6.11.0",
+      "version": "6.12.1",
       "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.11.0",
+  "version": "6.12.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/README.md

@@ -165,7 +165,7 @@ is still outside it gets a message naming both sides of the mismatch instead of
 
 Plugin mode manages its own hooks/runtime. On session start it only **checks and reports** new claude-mem-lite versions; it does **not** self-overwrite plugin files in place. Update plugin-mode installs through Claude's plugin workflow.
 
-> **The plugin install is complete on its own** — hooks, MCP tools, and the bundled slash commands (`/mem`, `/lesson`, `/bug`, `/adopt`) all run from the plugin with no second step. The slash commands invoke the bundled CLI by an absolute path resolved from the plugin directory (`${CLAUDE_PLUGIN_ROOT}/cli.mjs <cmd>`), so they work without anything on your `PATH`. A global `claude-mem-lite` **shell** command (for running queries yourself in a terminal) is **optional** — `npm i -g claude-mem-lite` — and is a *separate* npm install: the plugin's auto-update does **not** refresh it, so re-run `npm i -g claude-mem-lite@latest` if you want that shell command kept in sync. You do **not** need it for the plugin to be fully functional.
+> **The plugin install is complete on its own** — hooks, MCP tools, and the bundled slash commands (`/mem`, `/lesson`, `/bug`, `/adopt`) all run from the plugin with no second step. The slash commands invoke the bundled CLI by an absolute path resolved from the plugin directory (`node "${CLAUDE_PLUGIN_ROOT}/cli.mjs" <cmd>`), so they work without anything on your `PATH`. A global `claude-mem-lite` **shell** command (for running queries yourself in a terminal) is **optional** — `npm i -g claude-mem-lite` — and is a *separate* npm install: the plugin's auto-update does **not** refresh it, so re-run `npm i -g claude-mem-lite@latest` if you want that shell command kept in sync. You do **not** need it for the plugin to be fully functional.
 
 > **Auto-adopt writes into your project, on every SessionStart (v3.13+).** The plugin adds a slug-scoped **managed block** to your project's own **`<cwd>/CLAUDE.md`** — a file that is normally committed to git — plus a `<cwd>/.claude/plugin_claude_mem_lite.md` detail file. The block is a system-authority pointer that boosts Claude's proactive use of `mem_recall` / `mem_save`. Everything outside the block is preserved verbatim, and it coexists with other plugins' blocks in the same file ([details](#invited-memory-v232)). This happens on **every** SessionStart, not just the first: the sync is idempotent and re-applies the block if it is edited away, and refreshes it when the shipped template changes. It applies regardless of install path (npm, npx, `/plugin`, manual), so **no manual `/adopt` is needed**.
 >
@@ -405,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

@@ -129,7 +129,7 @@ v5.1.0 到 v6.1.0 之间，`package.json` 声明的是 `os: ["darwin", "linux"]`
 
 插件模式会管理自己的运行时与钩子。SessionStart 时它现在只会**检查并提示**新版本，不会直接覆盖插件目录中的文件。插件模式请通过 Claude 的插件更新流程完成升级。
 
-> **插件安装本身即完整** —— hooks、MCP 工具、以及捆绑的 slash 命令（`/mem`、`/lesson`、`/bug`、`/adopt`）全部从插件内运行，无需第二步。slash 命令以从插件目录解析出的绝对路径调用捆绑 CLI（`${CLAUDE_PLUGIN_ROOT}/cli.mjs <cmd>`），因此不依赖 `PATH` 上的任何东西。全局 `claude-mem-lite` **shell** 命令（用于你自己在终端里跑查询）是**可选**的 —— `npm i -g claude-mem-lite` —— 且是**独立**的 npm 安装：插件的自动更新**不会**刷新它，想保持同步就重新跑 `npm i -g claude-mem-lite@latest`。插件要完整工作**并不需要**它。
+> **插件安装本身即完整** —— hooks、MCP 工具、以及捆绑的 slash 命令（`/mem`、`/lesson`、`/bug`、`/adopt`）全部从插件内运行，无需第二步。slash 命令以从插件目录解析出的绝对路径调用捆绑 CLI（`node "${CLAUDE_PLUGIN_ROOT}/cli.mjs" <cmd>`），因此不依赖 `PATH` 上的任何东西。全局 `claude-mem-lite` **shell** 命令（用于你自己在终端里跑查询）是**可选**的 —— `npm i -g claude-mem-lite` —— 且是**独立**的 npm 安装：插件的自动更新**不会**刷新它，想保持同步就重新跑 `npm i -g claude-mem-lite@latest`。插件要完整工作**并不需要**它。
 
 ### 方式二：npx（一行命令）
 
@@ -341,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.
@@ -410,6 +417,21 @@ export const KNOWN_CLI_FLAGS = new Set([
   // --has?" suggestion. Locked by tests/cli-flag-allowlist.test.mjs.
 ]);
 
+/**
+ * Flags exactly ONE subcommand reads, mapped to that command. KNOWN_CLI_FLAGS is a union, so
+ * without this `recent --apply` was accepted in silence while `--apply` did nothing there.
+ * Every other command mem-cli dispatches now reports such a flag, and the typo suggester stops
+ * offering it there. Install-family commands (doctor, status, …) route to install.mjs and are
+ * not covered. Only flags with a single reader
+ * belong here; tests/cli-flag-allowlist.test.mjs derives that from the sources.
+ */
+export const COMMAND_SCOPED_FLAGS = new Map([
+  ['apply', 'verify-apply'],
+  ['digest', 'verify-apply'],
+  ['print-project', 'verify-apply'],
+  ['undo', 'verify-apply'],
+]);
+
 /** Levenshtein distance, early-exit past `max` (cheap enough for a handful of flags). */
 function editDistance(a, b, max = 2) {
   const m = a.length,
@@ -437,16 +459,25 @@ function editDistance(a, b, max = 2) {
  * project — a typo produced a wrong result with zero signal. Returns [{flag, suggestion}].
  * Unknown flags with NO close match are omitted: they may be a valid flag we didn't
  * catalog, so silence beats a false alarm. Warning-only by contract — never fails.
+ * A flag in COMMAND_SCOPED_FLAGS given to any other `cmd` is reported too, with `owner` set.
  * @param {object} flags Parsed flags from parseArgs.
- * @returns {Array<{flag: string, suggestion: string}>}
+ * @param {string} [cmd] The subcommand being run; without it scoped flags are not checked.
+ * @returns {Array<{flag: string, suggestion: string|null, owner?: string}>}
  */
-export function suggestUnknownFlags(flags) {
+export function suggestUnknownFlags(flags, cmd) {
   const result = [];
   for (const key of Object.keys(flags)) {
+    const owner = COMMAND_SCOPED_FLAGS.get(key);
+    if (cmd && owner && owner !== cmd) {
+      result.push({ flag: key, suggestion: null, owner });
+      continue;
+    }
     if (!key || KNOWN_CLI_FLAGS.has(key)) continue;
     let best = null,
       bestDist = 3;
     for (const known of KNOWN_CLI_FLAGS) {
+      const knownOwner = COMMAND_SCOPED_FLAGS.get(known);
+      if (cmd && knownOwner && knownOwner !== cmd) continue;
       const d = editDistance(key, known);
       if (d < bestDist) {
         bestDist = d;

package/cli/verify-apply.mjs

@@ -0,0 +1,196 @@
+// 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';
+import { shellWord } from '../cli-path.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.
+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-path.mjs

@@ -22,4 +22,14 @@ import { join, dirname } from 'node:path';
 // module from its unused-export report entirely. Enforced by
 // tests/no-url-module-paths.test.mjs.
 export const CLI_PATH = join(dirname(fileURLToPath(import.meta.url)), 'cli.mjs');
-export const CLI_INVOKE = `node ${CLI_PATH}`;
+/**
+ * A path as one shell word: as-is when it is plain, single-quoted otherwise. Conditional on
+ * purpose — CLI_INVOKE is LLM-visible (MCP instructions, every "Equivalent CLI" hint), so an
+ * ordinary install path must stay byte-identical; only a path with a space or a shell
+ * metacharacter gets quotes, which it needs to survive as ONE argument.
+ * @param {string} s
+ * @returns {string}
+ */
+export const shellWord = (s) => (/^[\w@%+=:,./-]+$/.test(s) ? s : `'${s.replace(/'/g, `'\\''`)}'`);
+
+export const CLI_INVOKE = `node ${shellWord(CLI_PATH)}`;

package/cli.mjs

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

package/commands/adopt.md

@@ -64,4 +64,4 @@ server builds its instructions once at boot, so the MCP-instructions trim
 (or re-attaches the mem-lite MCP server). A `/exit` + fresh session is enough.
 Same caveat applies in reverse for `/unadopt`.
 
-!node ${CLAUDE_PLUGIN_ROOT}/cli.mjs adopt $ARGUMENTS
+!node "${CLAUDE_PLUGIN_ROOT}/cli.mjs" adopt $ARGUMENTS

package/commands/bug.md

@@ -49,7 +49,7 @@ goes in `--lesson` so it lands in the high-weight `lesson_learned` field.
 body in the positional content and trim `--lesson` to the core description if
 longer:
 
-    node ${CLAUDE_PLUGIN_ROOT}/cli.mjs save "<body>" \
+    node "${CLAUDE_PLUGIN_ROOT}/cli.mjs" save "<body>" \
       --type bugfix \
       --title "<first 60 chars of description>" \
       --lesson "<description, ≤500 chars>" \

package/commands/lesson.md

@@ -42,7 +42,7 @@ field. `--lesson` is capped at 500 chars (longer values are rejected), so for a
 long lesson keep the full text in the positional content and trim `--lesson` to
 the core insight:
 
-    node ${CLAUDE_PLUGIN_ROOT}/cli.mjs save "<full text>" \
+    node "${CLAUDE_PLUGIN_ROOT}/cli.mjs" save "<full text>" \
       --type discovery \
       --title "<first 60 chars of text>" \
       --lesson "<core insight, ≤500 chars>" \

package/commands/mem.md

@@ -23,16 +23,16 @@ Search and browse your project memory efficiently.
 
 When the user invokes `/mem`, parse their intent:
 
-- `/mem search <query>` → run `node ${CLAUDE_PLUGIN_ROOT}/cli.mjs search <query>` via Bash
-- `/mem recent` or `/mem recent 20` → run `node ${CLAUDE_PLUGIN_ROOT}/cli.mjs recent [N]` via Bash
-- `/mem recall <file>` → run `node ${CLAUDE_PLUGIN_ROOT}/cli.mjs recall <file>` via Bash
-- `/mem timeline <id>` → run `node ${CLAUDE_PLUGIN_ROOT}/cli.mjs timeline --anchor <id>` via Bash
+- `/mem search <query>` → run `node "${CLAUDE_PLUGIN_ROOT}/cli.mjs" search <query>` via Bash
+- `/mem recent` or `/mem recent 20` → run `node "${CLAUDE_PLUGIN_ROOT}/cli.mjs" recent [N]` via Bash
+- `/mem recall <file>` → run `node "${CLAUDE_PLUGIN_ROOT}/cli.mjs" recall <file>` via Bash
+- `/mem timeline <id>` → run `node "${CLAUDE_PLUGIN_ROOT}/cli.mjs" timeline --anchor <id>` via Bash
 - `/mem save <text>` → call `mem_save` MCP tool with the text as content
-- `/mem stats` → run `node ${CLAUDE_PLUGIN_ROOT}/cli.mjs stats` via Bash
-- `/mem get <ids>` → run `node ${CLAUDE_PLUGIN_ROOT}/cli.mjs get <ids>` via Bash
+- `/mem stats` → run `node "${CLAUDE_PLUGIN_ROOT}/cli.mjs" stats` via Bash
+- `/mem get <ids>` → run `node "${CLAUDE_PLUGIN_ROOT}/cli.mjs" get <ids>` via Bash
 - `/mem cleanup` → run `mem_maintain(action="scan")`, report pending purge count and stale items to user, ask for confirmation, then run `mem_maintain(action="execute", operations=["purge_stale"], confirm=true)` if confirmed. **`confirm=true` is required and is not optional politeness:** without it the call returns a dry-run PREVIEW and deletes nothing, while still succeeding — so you would report a cleanup that never happened.
 - `/mem cleanup Nd` (e.g. `60d`) → same as above but add `retain_days=N` to only purge items older than N days. **`retain_days` must be between 7 and 365**; anything outside that range is rejected by the schema, so `/mem cleanup 3d` cannot be honoured — say so rather than silently substituting the default.
 - `/mem cleanup keep Nd` (e.g. `keep 14d`) → same as above with `retain_days=N`, same 7–365 range.
-- `/mem <query>` (no subcommand) → treat as search, run `node ${CLAUDE_PLUGIN_ROOT}/cli.mjs search <query>` via Bash
+- `/mem <query>` (no subcommand) → treat as search, run `node "${CLAUDE_PLUGIN_ROOT}/cli.mjs" search <query>` via Bash
 
-Use Bash commands first. For detailed data, use `node ${CLAUDE_PLUGIN_ROOT}/cli.mjs get <id>` via Bash.
+Use Bash commands first. For detailed data, use `node "${CLAUDE_PLUGIN_ROOT}/cli.mjs" get <id>` via Bash.

package/commands/unadopt.md

@@ -43,4 +43,4 @@ Once unadopted, the conservative hook layer (SessionStart `File Lessons` /
 `Key Context`, MCP instructions `WHEN TO USE`) returns to verbose mode on the
 next session start.
 
-!node ${CLAUDE_PLUGIN_ROOT}/cli.mjs unadopt $ARGUMENTS
+!node "${CLAUDE_PLUGIN_ROOT}/cli.mjs" unadopt $ARGUMENTS

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.