superlocalmemory 4.1.0 → 4.1.3

package/.claude-plugin/marketplace.json

@@ -10,8 +10,36 @@
         "name": "Qualixar"
       },
       "description": "Local-first agent memory + reversible context compression and KV cache, as an MCP server. 34-tool code profile with graph intelligence.",
+      "homepage": "https://github.com/qualixar/superlocalmemory",
+      "keywords": [
+        "memory",
+        "mcp",
+        "agents",
+        "local-first",
+        "context-compression"
+      ],
+      "license": "AGPL-3.0-or-later",
       "name": "superlocalmemory",
-      "source": "./plugin"
+      "source": "./plugin",
+      "version": "4.1.3"
+    },
+    {
+      "author": {
+        "name": "Qualixar"
+      },
+      "description": "Local-first agent memory with auditable hybrid retrieval — the Codex build, with Codex-shaped rules, hooks and launcher.",
+      "homepage": "https://github.com/qualixar/superlocalmemory",
+      "keywords": [
+        "memory",
+        "mcp",
+        "agents",
+        "local-first",
+        "context-compression"
+      ],
+      "license": "AGPL-3.0-or-later",
+      "name": "superlocalmemory-codex",
+      "source": "./codex-plugin",
+      "version": "4.1.3"
     }
   ]
 }

package/CHANGELOG.md

@@ -5,6 +5,113 @@ All notable changes to SuperLocalMemory will be documented in this file.
 The format is based on [Keep a Changelog](https://keepachangelog.com/en/1.0.0/),
 and this project adheres to [Semantic Versioning](https://semver.org/spec/v2.0.0.html).
 
+## [4.1.3] — Your install, your tools, your memories
+
+### Fixed
+- **Installing the plugin could point your editor at a different, empty set of
+  memories.** Its server configuration pinned a data directory of its own, so on
+  a machine already using SLM the editor read somewhere else entirely — measured
+  here, that directory held 28 KB while the real one held 611 MB and 5,370
+  memories. Nothing failed and nothing warned; it simply looked like everything
+  was gone. The plugin no longer says where your memories live.
+- **Installing the plugin could take away tools you had turned on.** Three of the
+  four editor builds forced a narrower tool set — 31 tools, without the eight for
+  coordinating between sessions. If you had deliberately enabled more, installing
+  something removed them. No build states an opinion about this any more.
+- **Installing the plugin could give you a second copy of SuperLocalMemory.** Two
+  launchers preferred a private environment of their own over the one you already
+  had from `pip`, `pipx` or `npm`. So a machine that had ever created one kept
+  using it — including after you upgraded properly — and two copies read the same
+  memories, with whichever started first deciding which one answered. Both now
+  use what you already have, in either install order, and fall back to their own
+  only on a machine with none. When a leftover copy is found beside a real
+  install, it is named, with both version numbers, instead of being used quietly.
+- **The plugin would not start at all outside Claude Code.** The path it built
+  came from a setting only Claude Code provides, so on Codex and Antigravity it
+  pointed nowhere and the server never came up — with no error explaining why.
+- **Codex reported itself as Claude Code.** The catalogue offered one build, the
+  Claude Code one, so Codex installed that and every memory written from Codex was
+  filed under the wrong tool. Codex now has its own entry and its own build,
+  with the Codex-shaped rules, hooks and launcher that were never being delivered.
+
+### Changed
+- **Antigravity is supported.** It had no plugin at all. It now has the same
+  twelve skills, four sub-agents, command and hooks as every other editor.
+
+## [4.1.2] — The monitor that was watching nothing
+
+### Fixed
+- **A killed embedding worker was never brought back, and nothing said so.** The
+  worker is stopped on an idle timeout roughly every hour, by design, and a
+  background monitor exists to revive it. That monitor decided whether anything
+  was wrong by looking at a probe search: results with no meaning-score meant a
+  broken embedder. But it explicitly did not count *no results at all* — and no
+  results is what a dead embedder produces, because the meaning channel returns
+  nothing and the probe phrase appears in nobody's memories. So the one symptom
+  that should have started a repair was read as proof that none was needed, and
+  because a clean verdict is silent, it left no trace. Observed on a machine that
+  sat for over an hour, across two restarts, with searching by meaning switched
+  off, no explanation in the log, and a manual restart the only cure. The monitor
+  now asks the embedder directly, which is a question a search cannot answer.
+- **There was no way to tell a quiet monitor from a dead one.** A check that
+  finds nothing wrong writes nothing, which is right — a monitor that narrates
+  every success is one whose warnings get skimmed past. But it left "is it even
+  running?" unanswerable except by waiting for something to break. The time of
+  the last check is now reported, so it can be looked at instead of inferred.
+- **A failing repair would not say what it was failing.** When a completed
+  upgrade step stops holding, the report named the step and not the condition —
+  and that step checks five separate things. Anyone who hit it had to come back
+  and ask which. It now says which.
+- **One drifted row could make the whole store unreachable.** Any failed upgrade
+  step made every request return "service unavailable". That is right when a
+  table is missing. It is wrong for the checks that guard *data* rather than
+  structure — ordinary use can undo those, a single background pass being
+  enough — and it left people restarting a daemon to fix something a restart
+  could not fix. Structural failures still refuse; a data check that drifted now
+  reports itself and keeps serving while it is repaired. Anything that does not
+  say which kind it is still refuses, so nothing became more permissive by
+  accident.
+
+### Changed
+- **The plugin now installs and lists everywhere it should.** It is the main way
+  to get SLM, and it was only half-delivered:
+  - **Codex could not see it at all.** Codex reads `.codex-plugin/plugin.json` to
+    register a plugin and that file did not exist, so twelve skills, the hooks,
+    the launcher and the server config were all installed and none of it appeared
+    under Plugins. There was nothing to enable.
+  - **Codex was also missing two thirds of the product.** It shipped skills and
+    neither the four sub-agents nor the slash command. Both come from the same
+    single source as the Claude Code copies now, so they cannot drift.
+  - **Antigravity had no plugin at all.** It has one now, with the same skills,
+    agents, commands and hooks as every other surface.
+  - **VS Code was missing the slash command.**
+  - **Every release looked like no release.** The marketplace entry carried no
+    version, so a client had nothing to compare and an installed plugin never
+    appeared out of date. This reverses a rule of our own making; the version is
+    now stated, and one script owns every place that states it.
+- **`slm doctor` now says whether your skills are as new as your install.** The
+  skills, agents and commands are delivered by your editor, not by `pip`, so
+  upgrading the package leaves them untouched — and nothing had ever mentioned
+  that. This release changed 76 files across them. Doctor now reports the plugin
+  version beside the package version and names the command that updates it.
+
+## [4.1.1] — A store older than its own indexes
+
+### Fixed
+- **A store from an early version could not be opened at all, and there was no
+  way out of it.** Starting up creates the indexes, one of which is on a column
+  that arrives with a migration scheduled to run *after* the engine is up. On a
+  store old enough to predate that column, the index could not be created, so
+  startup failed — and the migration that would have added the column could not
+  run, because it runs after a startup that never finished. `slm db migrate` did
+  not help either: it reports nothing failed and skips that class of migration by
+  design. Any store in that state was stuck on the version it was already on.
+  The column is now added before the index that needs it, so those stores open
+  and finish upgrading on their own. Measured on a real 637 MB store: it went
+  from refusing to start to a complete upgrade in 19 seconds, with all 7,707
+  memories, 2,590 records and 848,945 connections unchanged and the integrity
+  check clean.
+
 ## [4.1.0] — Every door asks the same question
 
 ### Fixed

package/README.md

@@ -5,7 +5,7 @@
   </picture>
 </p>
 
-<h1 align="center">SuperLocalMemory V4.1.0</h1>
+<h1 align="center">SuperLocalMemory V4.1.3</h1>
 
 <h2 align="center">Rent the LLM. Own the memory.</h2>
 
@@ -27,12 +27,12 @@ guarantee here is stated as a falsifiable invariant, tested under an adversarial
 negative control, and shipped with the harness that regenerates the evidence:
 <code>python benchmark/run_all.py --trials 200 --output-dir results/</code>. What each experiment
 does <em>not</em> exercise is stated too.</p>
-<p align="center"><code>v4.1.0</code> — one control plane: <strong>SLM-Mesh</strong> peer coordination · multi-scope memory (personal / shared / global) · profiles · Cache · Compress · 7-layer retrieval · code graph · Entity Explorer · skill evolution · Modes A/B/C · GDPR retention &amp; audit chain · bounded loops — across CLI, MCP, dashboard, the <strong>Claude plugin</strong>, the <strong>Codex add-on</strong>, and documented IDE integrations.<br/>
+<p align="center"><code>v4.1.3</code> — one control plane: <strong>SLM-Mesh</strong> peer coordination · multi-scope memory (personal / shared / global) · profiles · Cache · Compress · 7-layer retrieval · code graph · Entity Explorer · skill evolution · Modes A/B/C · GDPR retention &amp; audit chain · bounded loops — across CLI, MCP, dashboard, the <strong>Claude plugin</strong>, the <strong>Codex add-on</strong>, and documented IDE integrations.<br/>
 Proxy: <code>slm wrap claude</code> &nbsp;·&nbsp; MCP: add <code>slm_compress</code> to your config &nbsp;·&nbsp; Skill: zero-config</p>
 <p align="center"><strong>Four public arXiv preprints</strong> · V4: <a href="https://arxiv.org/abs/2608.08253">arXiv:2608.08253</a> · companion archive: <a href="https://zenodo.org/records/21853302">Zenodo 21853302</a> (<a href="https://doi.org/10.5281/zenodo.21853302">DOI 10.5281/zenodo.21853302</a>) · prior preprints: <a href="https://arxiv.org/abs/2603.02240">2603.02240</a> · <a href="https://arxiv.org/abs/2603.14588">2603.14588</a> · <a href="https://arxiv.org/abs/2604.04514">2604.04514</a>.</p>
 
 <p align="center">
-  <a href="CHANGELOG.md"><img src="https://img.shields.io/badge/v4.1.0-Current_Release-2ea44f?style=for-the-badge&logo=checkmarx&logoColor=white" alt="v4.1.0 — Current Release"/></a>
+  <a href="CHANGELOG.md"><img src="https://img.shields.io/badge/v4.1.3-Current_Release-2ea44f?style=for-the-badge&logo=checkmarx&logoColor=white" alt="v4.1.3 — Current Release"/></a>
   <a href="https://arxiv.org/abs/2608.08253"><img src="https://img.shields.io/badge/arXiv-2608.08253-b31b1b?style=for-the-badge&logo=arxiv&logoColor=white" alt="SuperLocalMemory 4.0 paper on arXiv:2608.08253"/></a>
   <a href="https://zenodo.org/records/21853302"><img src="https://img.shields.io/badge/Zenodo-10.5281%2Fzenodo.21853302-1682D4?style=for-the-badge&logo=zenodo&logoColor=white" alt="V4 paper on Zenodo: 10.5281/zenodo.21853302"/></a>
   <a href="https://arxiv.org/abs/2603.14588"><img src="https://img.shields.io/badge/arXiv-2603.14588-b31b1b?style=for-the-badge&logo=arxiv&logoColor=white" alt="arXiv Paper"/></a>
@@ -62,11 +62,7 @@ SuperLocalMemory V4 combines conventional dense and lexical retrieval with graph
 
 **Memory with a sense of time.** SLM does not only store *what* an agent learned — it records *when*. Every fact carries ingestion timing and provenance; recall runs a dedicated temporal candidate channel alongside semantic, lexical, and associative retrieval; scenes and entity timelines reconstruct sequence; and the lifecycle lets neglected memory decay and self-archive instead of growing without bound. Time is a first-class ranking and lifecycle signal rather than a timestamp column an agent never reads — which is what lets a long-lived agent reason about how its context changed, not only what it currently holds.
 
-**What V4.0.7 ships.** Three things that existed but could not be used. `slm summary` gives you a readable layer over your own memories — `day` for what you recorded today, `project` for a directory, `session` for one session — each stating how much of the underlying data it could actually see, with `--json` listing the exact memories it came from. Memories that mention a function, method or file are now linked to that code, with a short description of what they point at and a marker once the code has changed; expanding a memory in the dashboard shows it. Both need no language model, so they work in the fully local mode. The code↔memory bridge behind the second one had never run at all: the setup flag was written and never read, the build discarded it, its settings had no loader, and the method it was written against was an unimplemented placeholder. Linking runs during background maintenance, never when a memory is saved. See [reviewed corrections](docs/reviewed-corrections.md) for the correction lifecycle and [MCP tools](docs/mcp-tools.md) for host-facing commands.
-
-**Fixed in V4.0.7.** Version numbers disagreed across the project — the pip requirement pins, npm lockfile, editor plugin manifest, citation metadata and lockfile all still named the previous release, so installing from `requirements.txt` fetched the wrong version; one script now sets all fifteen. Stale-memory checks reported "nothing is stale" when code linking was simply switched off, and pointed at a setting that did not exist. `slm gdpr` was missing from `slm help`. Consolidation, handed something that was neither a database handle nor a path, created a file named after the object instead of refusing it.
-
-**Carried forward from V4.0.5 and V4.0.6.** A correction is a review-gated lifecycle, not an in-place edit: SLM creates an immutable successor, keeps it out of current recall until an authenticated reviewer applies it, and preserves the predecessor for time-aware history. Every candidate path — cached context, pins, bridge and scene expansion — uses hard current-truth admission and abstains if that truth cannot be read. `slm brain`, MCP, HTTP and the Living Brain share one observation-only BrainTruth snapshot; feedback, external Bounded Loops evidence and receipt claims are shown honestly but never silently alter recall, ranking or model routing. The Living Brain leads with how many questions your memory has answered rather than a raw event count, and says so plainly where nothing has been measured yet. The knowledge graph opens reliably, with a default of 50 nodes and its details panel reachable on narrow screens. The optional adaptive ranker stays off unless an operator sets `SLM_RANKING` (`v1`, `v2`, or `v2-ensemble`) — that gate prevents feedback and observation data from changing ranking without an explicit decision, and does not disable the normal retrieval channels.
+**What changed in this release.** See the [CHANGELOG](CHANGELOG.md) — every release is written up there, in plain language, newest first.
 
 - **[SLM-Mesh](#slm-mesh-cross-session--cross-machine-coordination)** — authenticated cross-session and cross-machine peer coordination (messages, locks, shared state, inbox/outbox, optional discovery). Coordination only — not automatic replicated memory.
 - **Multi-scope memory & profiles** — workspaces (profiles) plus `personal` / `shared` / `global` scopes; cross-profile recall is default-deny.
@@ -300,7 +296,7 @@ retrieved at runtime rather than copied into those files.
 **Score Contract v2:** `relevance_score` is query-relative relevance;
 `ranking_score` is internal ranking utility; `memory_confidence` belongs to the
 stored assertion; and `trust_score` is an evidence-policy signal. Legacy
-`score` and `confidence` remain aliases for one compatibility release. V3.8.0 is
+`score` and `confidence` remain aliases for one compatibility release. It is
 explicitly uncalibrated: `calibration_status` is `uncalibrated` and
 `answer_confidence` is `null`. See
 [the retrieval score contract](docs/retrieval-score-contract.md).
@@ -314,9 +310,9 @@ can run without a cloud LLM:
 
 Auto-capture hooks are installed explicitly with `slm hooks install` (Claude
 Code) or `slm hooks install --agent codex` (Codex). Hook latency and capture
-quality must be evaluated for the target client and workload; V3.8.0 publishes no universal p99 claim.
+quality must be evaluated for the target client and workload; SLM publishes no universal p99 claim.
 
-**Multi-scope memory (v3.6.15, opt-in):** keep memories `personal` (default), `shared` with named profiles, or `global` across the machine. Off by default — recall only ever returns your own facts until you turn sharing on, per call or in config. See **[docs/shared-memory.md](docs/shared-memory.md)**.
+**Multi-scope memory (opt-in):** keep memories `personal` (default), `shared` with named profiles, or `global` across the machine. Off by default — recall only ever returns your own facts until you turn sharing on, per call or in config. See **[docs/shared-memory.md](docs/shared-memory.md)**.
 
 <a id="multilingual-embedding-support"></a>
 
@@ -422,7 +418,7 @@ and the Claude Code plugin update path.
 
 SLM supports two MCP transports:
 
-**HTTP (recommended, v3.6.7+):**
+**HTTP (recommended):**
 ```json
 { "mcpServers": { "superlocalmemory": { "type": "http", "url": "http://127.0.0.1:8765/mcp/" } } }
 ```
@@ -461,77 +457,46 @@ Per-IDE configs available for Claude Code, Cursor, Windsurf, VS Code Copilot, Co
 
 ---
 
-## Claude Code Plugin
+## Editor plugins
 
-Install directly in Claude Code — no system-level npm/pip needed. This is how you
-get the **skills, agents, hooks, commands, and rules** (the MCP server is
-bootstrapped automatically). It is a two-step flow — add the marketplace once,
-then install:
+The plugin is how most people should install SLM. It brings the MCP server, the
+skills, the sub-agents, the slash commands and the hooks in one step, and keeps
+them at the same version as the package.
 
-```bash
-# 1. Add the Qualixar marketplace (one-time — the repo IS the marketplace)
-/plugin marketplace add qualixar/superlocalmemory
-
-# 2. Install the plugin
-/plugin install superlocalmemory@qualixar
-```
+**Four surfaces, one source.** Everything below is generated from `plugin-src/`,
+so no surface can quietly fall behind another:
 
-- Self-bootstraps a Python venv, installs all deps in an isolated `SLM_DATA_DIR`
-- Registers the 34-tool `code` MCP surface — the 18-tool `core` memory surface plus code-graph, portable-evidence, bounded-loop and usefulness-report tools
-- Ships the SLM skills / agents / hooks / commands / rules
-- Additive — does not replace an existing SLM install
-- `slm connect claude-code` detects an existing plugin install and links them
+| Editor | Install | Skills | Agents | Commands | Hooks |
+|---|---|---:|---:|---:|---:|
+| **Claude Code** | `claude plugin marketplace add qualixar/superlocalmemory` then `claude plugin install superlocalmemory@qualixar` | 12 | 4 | 1 | yes |
+| **Codex** | copy `codex-plugin/` into your Codex plugins directory | 12 | 4 | 1 | yes |
+| **VS Code / Copilot** | copy `copilot-plugin/.github/` into your repository | 12 | 4 | as prompts | yes |
+| **Antigravity** | copy `antigravity-plugin/` into your plugins directory | 12 | 4 | 1 | yes |
 
-> **Plugin vs Python/npm:** `python -m pip install superlocalmemory` inside an
-> activated virtual environment, or `npm i -g superlocalmemory`,
-> give you the `slm` CLI + the MCP server (the *tools*). The **skills/agents/hooks/
-> commands** come only through the plugin above. Use the plugin for Claude Code; use
-> pip/npm for the CLI or other IDEs.
+### What you get
 
-To update later: `/plugin marketplace update qualixar` then `/plugin install superlocalmemory@qualixar`.
+- **Skills** — `slm-remember`, `slm-recall`, `slm-session`, `slm-graph`,
+  `slm-mesh`, `slm-scope`, `slm-profile`, `slm-governance`, `slm-cache`,
+  `slm-compress`, `slm-status`, `slm-loop`.
+- **Sub-agents** — a memory advisor, a governance advisor, a context-optimization
+  advisor, and a loop runner, each scoped to the tools it actually needs.
+- **Commands** — `/slm-loop`, to run a task as a gate-verified bounded loop.
+- **Hooks** — session start and end, so context loads and commits without being
+  asked.
 
-## Codex add-on
-
-For Codex, install the SLM-owned skills, two focused subagents, and four
-lifecycle hooks explicitly:
-
-```bash
-slm codex install
-```
+### Keeping it current
 
-This adds only SLM-owned files under `~/.agents/skills`, `~/.codex/agents`, and
-`~/.codex/hooks.json`; it does not replace another agent's hooks or rewrite
-`~/.codex/config.toml`. Codex requires review and trust for new command hooks:
-open `/hooks` after installation. MCP wiring remains a separate explicit step:
+`pipx upgrade superlocalmemory` upgrades the **package**. It does not
+upgrade the plugin — those are separate channels, and the plugin is delivered by
+your editor. `slm doctor` reports both versions side by side and names the
+command that updates the one that is behind.
 
 ```bash
-slm connect codex
+claude plugin marketplace update qualixar
+claude plugin update superlocalmemory@qualixar
 ```
 
-`slm connect codex` semantically merges the `superlocalmemory` MCP server into
-`~/.codex/config.toml`, preserving unrelated configuration keys and writing
-atomically. TOML serializers can normalize whitespace and comments, so it is
-not a byte-preserving operation; use it only when you want the MCP server
-configured. Check the result with `slm codex status`; undo SLM-owned add-ons
-with `slm codex remove`.
-
-## GitHub Copilot integration
-
-The shipped installer configures the SuperLocalMemory MCP server and additive
-agent instructions for VS Code with GitHub Copilot:
-
-```bash
-slm connect vscode-copilot --here
-```
-
-Run it from the project root. It semantically merges the SLM server into
-`.vscode/mcp.json` and adds SLM-owned guidance inside
-`.github/copilot-instructions.md`, preserving unrelated servers and existing
-instructions. The generated `copilot-plugin/` source bundle is maintained for
-parity checks, but v3.8.1 does not claim that `slm connect` installs its prompt,
-agent, or hook files.
-
----
+For the other three, replace the directory from the tag you are on.
 
 ## Privacy controls and operating modes
 

package/ide/configs/codex-mcp.toml

@@ -8,4 +8,6 @@
 [mcp_servers.superlocalmemory]
 command = "slm"
 args = ["mcp"]
-env = { SLM_MCP_PROFILE = "code", SLM_AGENT_ID = "codex" }
+# Agent id only. Pinning a profile here would remove tools you had enabled;
+# unset resolves to the full tool set.
+env = { SLM_AGENT_ID = "codex" }

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "superlocalmemory",
-  "version": "4.1.0",
+  "version": "4.1.3",
   "description": "Local-first agent memory with MCP and an agent-native CLI. Documented clients include Claude Code, Cursor, and Windsurf.",
   "keywords": [
     "ai-memory",
@@ -52,10 +52,11 @@
     "check:copilot-plugin": "node scripts/build-copilot-plugin.mjs --check",
     "build:codex-plugin": "node scripts/build-codex-plugin.mjs",
     "check:codex-plugin": "node scripts/build-codex-plugin.mjs --check",
-    "prepack": "node scripts/build-plugin.mjs && node scripts/build-copilot-plugin.mjs && node scripts/build-codex-plugin.mjs && node scripts/prepack.js",
+    "prepack": "node scripts/build-plugin.mjs && node scripts/build-copilot-plugin.mjs && node scripts/build-codex-plugin.mjs && node scripts/build-antigravity-plugin.mjs && node scripts/prepack.js",
     "postinstall": "node scripts/postinstall.js",
     "preuninstall": "node scripts/preuninstall.js",
-    "test": "node scripts/run-ui-tests.mjs"
+    "test": "node scripts/run-ui-tests.mjs",
+    "build:antigravity-plugin": "node scripts/build-antigravity-plugin.mjs"
   },
   "engines": {
     "node": ">=18.0.0",

package/plugin/.claude-plugin/plugin.json

@@ -15,5 +15,5 @@
   "mcpServers": "./.mcp.json",
   "name": "superlocalmemory",
   "repository": "https://github.com/qualixar/superlocalmemory",
-  "version": "4.1.0"
+  "version": "4.1.3"
 }

package/plugin/.mcp.json

@@ -4,9 +4,7 @@
       "command": "${CLAUDE_PLUGIN_ROOT}/scripts/slm-launch",
       "args": [],
       "env": {
-        "SLM_MCP_PROFILE": "code",
-        "SLM_AGENT_ID": "claude_code",
-        "SLM_DATA_DIR": "${CLAUDE_PLUGIN_DATA}"
+        "SLM_AGENT_ID": "claude_code"
       }
     }
   }

package/plugin/CLAUDE.md

@@ -1,4 +1,4 @@
-<!-- BEGIN SuperLocalMemory v4.1.0 -->
+<!-- BEGIN SuperLocalMemory v4.1.3 -->
 
 ## SuperLocalMemory (SLM) — Agent Rules
 
@@ -39,6 +39,6 @@ slm-recall · slm-remember · slm-session · slm-status · slm-cache · slm-comp
 ### Subagents
 slm-memory-advisor (memory decisions, session hygiene, scope/profile guidance) · slm-optimize-advisor (context compression + KV cache) · slm-governance-advisor (scope/roles/compliance/GDPR)
 
-<!-- END SuperLocalMemory v4.1.0 -->
+<!-- END SuperLocalMemory v4.1.3 -->
 
-SuperLocalMemory v4.1.0 · Qualixar · AGPL-3.0-or-later
+SuperLocalMemory v4.1.3 · Qualixar · AGPL-3.0-or-later

package/plugin/agents/slm-governance-advisor.md

@@ -77,4 +77,4 @@ slm-scope · slm-governance · slm-profile · slm-remember · slm-recall
 # What NOT to do
 Never session_init twice; never forget without dry-run preview; never store secrets; never bypass role checks; never claim an erasure succeeded without verifying via recall.
 
-SuperLocalMemory v4.1.0 · Qualixar · AGPL-3.0-or-later
+SuperLocalMemory v4.1.3 · Qualixar · AGPL-3.0-or-later

package/plugin/agents/slm-loop-runner.md

@@ -68,4 +68,4 @@ assessment. The gate is the authority.
 
 ---
 
-SuperLocalMemory v4.1.0 · Qualixar · AGPL-3.0-or-later
+SuperLocalMemory v4.1.3 · Qualixar · AGPL-3.0-or-later

package/plugin/agents/slm-memory-advisor.md

@@ -46,4 +46,4 @@ slm-recall · slm-remember · slm-session · slm-scope · slm-profile · slm-gov
 # What NOT to do
 Never session_init twice; never forget dry_run=False without reporting preview; never dump a whole file into remember; never invent a memory; never claim "saved" without success:true / clean CLI exit; never bypass scope or governance restrictions.
 
-SuperLocalMemory v4.1.0 · Qualixar · AGPL-3.0-or-later
+SuperLocalMemory v4.1.3 · Qualixar · AGPL-3.0-or-later

package/plugin/agents/slm-optimize-advisor.md

@@ -41,4 +41,4 @@ slm-compress · slm-cache · slm-status · slm-profile
 # What NOT to do
 Never compress code-for-edit/JSON-to-parse/<500 chars; never store secrets/ccr_ids; never let optimize failure block/alter the task; never claim a specific savings %; never carry ccr_ids across profile switches.
 
-SuperLocalMemory v4.1.0 · Qualixar · AGPL-3.0-or-later
+SuperLocalMemory v4.1.3 · Qualixar · AGPL-3.0-or-later

package/plugin/requirements.txt

@@ -1 +1 @@
-superlocalmemory==4.1.0
+superlocalmemory==4.1.3

package/plugin/scripts/slm-launch

@@ -1,62 +1,131 @@
 #!/usr/bin/env bash
-# slm-launch — WP-F SuperLocalMemory MCP launcher (POSIX)
+# slm-launch — SuperLocalMemory MCP launcher (POSIX)
 #
 # Cross-platform counterpart: slm-launch.bat (Windows)
-# Referenced by plugin/.mcp.json as the MCP server command.
+# Referenced by .mcp.json as the MCP server command.
 #
-# Resolves the correct slm binary for POSIX and joins the namespace daemon
-# before opening the MCP stdio transport. This preserves one writer for all
-# parallel Claude sessions that share CLAUDE_PLUGIN_DATA.
+# WHAT THIS RESOLVES, AND WHY THE DEFAULT CHANGED
 #
-# On Windows, Claude Code invokes slm-launch.bat instead (same-stem, .bat extension).
+# It used to default to a venv the plugin owns:
+# "${CLAUDE_PLUGIN_DATA}/venv/bin/slm". So anyone who already had SuperLocalMemory
+# — from pip, pipx or npm — got a SECOND installation the moment they installed
+# the plugin, on its own schedule, upgraded separately, and easy to leave behind
+# a release. Installing a plugin should not fork your installation.
 #
-# Environment:
-#   CLAUDE_PLUGIN_DATA — persistent data dir where the plugin venv lives
-#   SLM_DATA_DIR       — optional; SLM data dir (default: ~/.superlocalmemory)
-#   SLM_LAUNCHER       — optional; which slm binary to use:
-#                          plugin (default) — the plugin venv binary
-#                          system           — the system `slm` on PATH
-#                          <path>           — an explicit slm binary (leading ~ expanded)
+# It was also Claude-Code-only. ${CLAUDE_PLUGIN_DATA} is set by Claude Code and
+# by nothing else, so on Codex or Antigravity the path collapsed to
+# "/venv/bin/slm" and the server simply did not start.
+#
+# The default is now: USE THE SLM THAT IS ALREADY INSTALLED. A plugin-owned venv
+# is the fallback for a machine that has none, not the first choice.
+#
+# Environment (all optional):
+#   SLM_LAUNCHER       auto (default) — prefer an installed slm, else the plugin venv
+#                      system         — require the slm on PATH
+#                      plugin         — require the plugin's own venv
+#                      <path>         — an explicit slm binary (leading ~ expanded)
+#   SLM_DATA_DIR       SLM data dir (default: ~/.superlocalmemory)
+#   CLAUDE_PLUGIN_DATA where a plugin-owned venv lives, when there is one
+#
+# Deliberately NOT set here: the MCP profile. Which tools a host exposes is the
+# user's decision, and a plugin that narrows it takes away tools they configured.
 
 _SLM_DATA="${SLM_DATA_DIR:-$HOME/.superlocalmemory}"
+_PLUGIN_BIN="${CLAUDE_PLUGIN_DATA:+${CLAUDE_PLUGIN_DATA}/venv/bin/slm}"
 
-# If a system daemon is already running (its pidfile points at a live process),
-# there is no need to boot the plugin's own venv daemon — we can open an MCP
-# writer against the daemon that is already up. This skips a redundant, slow
-# venv bootstrap on every session start.
+# Is a daemon already up for this data dir? If so we join it rather than boot a
+# second one — one writer for every session that shares the store.
 _daemon_running=0
 if [ -f "${_SLM_DATA}/daemon.pid" ] \
    && kill -0 "$(cat "${_SLM_DATA}/daemon.pid" 2>/dev/null)" 2>/dev/null; then
     _daemon_running=1
 fi
 
-case "${SLM_LAUNCHER:-plugin}" in
-    plugin)
-        SLM_BIN="${CLAUDE_PLUGIN_DATA}/venv/bin/slm"
-        # Only bootstrap the owned daemon when one is not already running.
-        if [ "${_daemon_running}" -eq 0 ]; then
-            if ! "${SLM_BIN}" serve start >&2; then
+# Expand a leading ~ WITHOUT eval — eval on an environment value is a
+# command-injection foot-gun. Only tilde expansion; pass expanded paths for vars.
+_expand_tilde() {
+    case "$1" in
+        "~"*) printf '%s' "${HOME}${1#\~}" ;;
+        *)    printf '%s' "$1" ;;
+    esac
+}
+
+# Start a daemon with the chosen binary unless one is already serving.
+_ensure_daemon() {
+    [ "${_daemon_running}" -eq 1 ] && return 0
+    "$1" serve start >&2
+}
+
+case "${SLM_LAUNCHER:-auto}" in
+    auto)
+        # 1. An slm already on PATH — the pip, pipx or npm install the user has.
+        #    This is the common case and the one that must not be forked.
+        if command -v slm >/dev/null 2>&1; then
+            # Both orderings end up here, and both must converge on ONE
+            # environment:
+            #   installed first, plugin second -> nothing was ever forked;
+            #   plugin first, installed second -> the plugin venv is now the
+            #     older copy and must stop being used.
+            # They already share one store, because this launcher sets no
+            # SLM_DATA_DIR and both resolve ~/.superlocalmemory. What is left to
+            # go wrong is two DIFFERENT VERSIONS serving that one store: whoever
+            # starts the daemon first decides which code the other one talks to.
+            # So when a leftover plugin venv is found beside a real install, say
+            # so, with both versions named. Silent duplication is how a store
+            # ends up served by a release nobody thinks they are running.
+            if [ -n "${_PLUGIN_BIN}" ] && [ -x "${_PLUGIN_BIN}" ]; then
+                _sys_v="$(slm --version 2>/dev/null | awk '{print $NF}')"
+                _plg_v="$("${_PLUGIN_BIN}" --version 2>/dev/null | awk '{print $NF}')"
+                if [ -n "${_plg_v}" ] && [ "${_sys_v}" != "${_plg_v}" ]; then
+                    echo "SLM plugin: using the installed slm ${_sys_v:-?} and IGNORING a leftover plugin venv at ${_PLUGIN_BIN} (${_plg_v})." >&2
+                    echo "  One store, one version. Remove the venv to stop it drifting:  rm -rf \"${CLAUDE_PLUGIN_DATA}/venv\"" >&2
+                fi
+            fi
+            _ensure_daemon "$(command -v slm)" || \
+                echo "SLM plugin: daemon did not start; continuing as a direct MCP writer." >&2
+            exec slm mcp
+        fi
+        # 2. No system install. Use the plugin's own venv if this host gave us
+        #    somewhere to keep one.
+        if [ -n "${_PLUGIN_BIN}" ] && [ -x "${_PLUGIN_BIN}" ]; then
+            if ! _ensure_daemon "${_PLUGIN_BIN}"; then
                 echo "SLM plugin: unable to start the owned daemon; refusing a direct MCP writer." >&2
                 exit 1
             fi
+            exec "${_PLUGIN_BIN}" mcp
         fi
-        exec "${SLM_BIN}" mcp
+        # 3. Neither. Say which two things were looked for, so the fix is obvious.
+        echo "SLM plugin: no SuperLocalMemory found." >&2
+        echo "  Looked for: 'slm' on PATH, and ${_PLUGIN_BIN:-a plugin venv (this host sets no plugin data dir)}." >&2
+        echo "  Install it with:  pipx install superlocalmemory" >&2
+        exit 1
         ;;
     system)
+        if ! command -v slm >/dev/null 2>&1; then
+            echo "SLM_LAUNCHER=system but no 'slm' on PATH." >&2
+            exit 1
+        fi
+        _ensure_daemon "$(command -v slm)" || true
         exec slm mcp
         ;;
+    plugin)
+        if [ -z "${_PLUGIN_BIN}" ]; then
+            echo "SLM_LAUNCHER=plugin but this host sets no CLAUDE_PLUGIN_DATA." >&2
+            exit 1
+        fi
+        if ! _ensure_daemon "${_PLUGIN_BIN}"; then
+            echo "SLM plugin: unable to start the owned daemon; refusing a direct MCP writer." >&2
+            exit 1
+        fi
+        exec "${_PLUGIN_BIN}" mcp
+        ;;
     *)
-        # Explicit binary path. Expand a leading ~ to $HOME WITHOUT eval — eval
-        # on an environment value is a command-injection foot-gun. Only tilde
-        # expansion is supported here; pass an already-expanded path for $VARs.
-        case "${SLM_LAUNCHER}" in
-            "~"*) _SLM_BIN="${HOME}${SLM_LAUNCHER#\~}" ;;
-            *)    _SLM_BIN="${SLM_LAUNCHER}" ;;
-        esac
+        _SLM_BIN="$(_expand_tilde "${SLM_LAUNCHER}")"
         if [ ! -x "${_SLM_BIN}" ]; then
             echo "SLM_LAUNCHER is not an executable slm binary: ${_SLM_BIN}" >&2
             exit 1
         fi
+        _ensure_daemon "${_SLM_BIN}" || true
         exec "${_SLM_BIN}" mcp
         ;;
 esac

package/plugin/skills/slm-cache/SKILL.md

@@ -145,4 +145,4 @@ These subcommands control daemon-level cache settings. They do not read or write
 
 ---
 
-SuperLocalMemory v4.1.0 · Qualixar · AGPL-3.0-or-later
+SuperLocalMemory v4.1.3 · Qualixar · AGPL-3.0-or-later

package/plugin/skills/slm-compress/SKILL.md

@@ -147,4 +147,4 @@ Content over 1 MB (1 000 000 bytes UTF-8) is processed but `reversible` is force
 
 ---
 
-SuperLocalMemory v4.1.0 · Qualixar · AGPL-3.0-or-later
+SuperLocalMemory v4.1.3 · Qualixar · AGPL-3.0-or-later

package/plugin/skills/slm-governance/SKILL.md

@@ -245,4 +245,4 @@ Before running any destructive operation (`forget`, `compact_memories`):
 
 ---
 
-*SuperLocalMemory v4.1.0 · Qualixar · AGPL-3.0-or-later*
+*SuperLocalMemory v4.1.3 · Qualixar · AGPL-3.0-or-later*

package/plugin/skills/slm-graph/SKILL.md

@@ -312,4 +312,4 @@ profile. See `slm-profile` for the full profile switching workflow.
 
 ---
 
-SuperLocalMemory v4.1.0 · Qualixar · AGPL-3.0-or-later
+SuperLocalMemory v4.1.3 · Qualixar · AGPL-3.0-or-later