superlocalmemory 4.0.10 → 4.1.0

package/.claude-plugin/marketplace.json

@@ -9,7 +9,7 @@
       "author": {
         "name": "Qualixar"
       },
-      "description": "Local-first agent memory + reversible context compression and KV cache, as an MCP server. 21-tool code profile with graph intelligence.",
+      "description": "Local-first agent memory + reversible context compression and KV cache, as an MCP server. 34-tool code profile with graph intelligence.",
       "name": "superlocalmemory",
       "source": "./plugin"
     }

package/CHANGELOG.md

@@ -5,6 +5,176 @@ 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.0] — Every door asks the same question
+
+### Fixed
+- **Nothing was recording which memories a recall actually returned, so nothing
+  could learn from it.** The step that notes "these memories were shown, for this
+  question, in this session" had no caller anywhere — a worker started with the
+  service and waited for events that were never sent. On a real store that left
+  every one of 162 recorded outcomes with no way to trace back to the recall that
+  produced it, every per-memory usefulness score sitting at its untouched
+  starting value, and the ranking model unchanged for eleven weeks. Recalls now
+  leave that record. It costs 1.6 microseconds and is written outside the reply,
+  so recall returns the same answers in the same time — measured across 30 warmed
+  queries, the difference was 3.5 ms in favour of the change, which is to say
+  none. It records only: whether what is learned may reorder your results remains
+  a separate setting that stays off unless you turn it on.
+- **Memories stored since the last graph analysis were ranked as unconnected.**
+  Recall weighs a memory partly by where it sits in your knowledge graph. That
+  position was only recalculated when a consolidation happened to run or you
+  asked for it by hand, so on a real store 1,036 of 4,034 memories had no
+  position recorded — including every memory from the previous four days. They
+  were still found, then ranked as though nothing linked to them. The
+  calculation now runs on a schedule and again shortly after startup, it covers
+  every memory including ones with no links yet, and it no longer ranks memories
+  the store is not allowed to return, which had been diluting the scores of the
+  ones it can.
+- **One small calculation could push a handful of memories above everything
+  else.** A separate routine gave every memory in a group the same score and
+  wrote it where the ranking reads. On a real store that score was more than ten
+  times the highest genuine one, so those memories took the largest ranking
+  bonus available for no reason beyond having shared a subject with a few
+  others. It has been removed; nothing depended on it.
+- **Turning on per-user access did not apply to agent connections.** Company
+  mode is set from the dashboard, and the setting it writes was read by the web
+  interface but not by the connection your AI tools use — so with per-user access
+  on, two users configured, and one of them restricted to read-only, a write
+  arriving over the tool connection was accepted as the machine owner while the
+  same write through the dashboard was refused. Both now read the same setting,
+  and a tool connection that cannot identify who is calling is refused. Personal,
+  single-user use is unchanged and needs no login.
+- **The settings could claim a storage engine that was not there.** A store
+  recorded the fast graph and vector engines as active with neither present on
+  disk and nothing in progress to explain it, so the dashboard reported one thing
+  while retrieval used another, on every restart. The claim is now checked
+  against what is actually on disk when the service starts, and dropped if there
+  is nothing behind it. Nothing is disabled: an engine that is installed is still
+  detected and used.
+- **A note about which schema versions had been applied was stored thousands of
+  times over.** Seven versions were recorded as 3,496 rows on one store and
+  234,348 on another, because the six places that write it all assumed a
+  uniqueness rule the table did not have. The rule is now there, so those writes
+  do what they always intended, and the duplicates are collapsed to one row each
+  keeping the original date.
+- **A second workspace could take over a memory belonging to the first.** Where
+  two workspaces on one store were handed the same identifier for a memory or a
+  fact — an import keyed on an external record id, feeding one source into two
+  workspaces, does exactly this — the later write could claim the first
+  workspace's entry outright: new owner, new content, and the notes attached to
+  it discarded, with nothing raised. Whether it was refused or went through in
+  silence depended on unrelated details of the entry, so neither outcome could
+  be relied on. A write that would move an entry from one workspace to another
+  is now refused, and says which workspace owns it.
+
+- **Restricting someone to read-only did not restrict every way in.** Per-user
+  access was applied where a memory is written, and not where one is deleted or
+  corrected over the network, not on four of the compliance controls, and not on
+  bulk import — which established who was calling and then never asked whether
+  they were allowed to write. Three ways of reading stored memories back asked
+  nothing at all. Every entrance now asks the same question of the same setting.
+- **A workspace that could not answer "what is this person allowed to do?"
+  assumed the most permissive answer.** If that lookup failed — a busy store, a
+  locked file — the caller was treated as able to write. A lookup that fails is
+  not a lookup that said yes; it is now refused outright and says so, and the
+  caller can retry.
+- **Deleting a memory left its connections behind.** The connections were
+  expected to be removed along with it and nothing removed them, so recall kept
+  walking links to memories that no longer existed. Both kinds of connection are
+  now removed with the memory. Erasing a person had the same shape: their entry
+  was removed from the store and left in the copy that search reads, name and
+  all, which is not what an erasure request means.
+- **Housekeeping could remove connections it had no way to announce.** If the
+  copy that search reads could not be told what had gone, the removal was
+  committed anyway and the two drifted apart silently. It is now undone and
+  retried instead. `slm db regraph` rebuilds that copy from the store if they
+  have already drifted.
+- **A request to be told what is held about you left out what had been learned
+  about how you work.** Erasure removed it; the export did not include it. Both
+  now cover the same ground.
+- **Storing a memory waited on a model that was still loading.** A write
+  computes the memory's vector on the spot so it can be found by asking a
+  question rather than only by quoting its own words, and gives that one second
+  before handing the job to the background worker. It started that wait even
+  when the model had not loaded, which it could never win — loading takes about
+  ten seconds. On a copy of a real store the first twelve writes after a fresh
+  start took a median of 1,055 ms and eleven stored no vector; they now take
+  34 ms. Writes against a loaded model are unchanged at about 75 ms. The service
+  now loads the model on startup, in the background, so the wait is not simply
+  moved onto whoever searches first.
+- **The dashboard reported "Healthy" whenever the service answered at all**, and
+  the page never reloaded after an upgrade because the version it looked for was
+  never filled in — so an upgraded install kept showing the previous version's
+  page until someone cleared their cache by hand. Both fixed; the card now
+  reports what the service is actually doing, including how far the search copy
+  is behind.
+- **An unrecognised result was recorded as a mildly positive one.** A client
+  reporting "ok" instead of one of the three accepted words had that counted as
+  partial success and fed to the ranking as though somebody had meant it. It is
+  now refused. An answer can also be reported on by name: recall returns an
+  identifier and a result quoting it is matched to that exact answer rather than
+  guessed at from overlap within a time window.
+- **A hosted model was reported as available before a key was set for it.**
+  Switching to Mode C names a provider and leaves the key empty until you supply
+  one, and every surface said nothing was wrong while each model-backed feature
+  was about to fall back to assembling from your notes. It now says which step
+  is missing.
+- **Repeated failures in a background task looked the same as one hiccup.** A
+  step failing every cycle for days reported exactly what a single transient
+  failure reported. It now says how long it has been failing.
+- **Upgrading a large store could appear to hang.** Collapsing duplicated
+  schema-version records compared every record against every other of the same
+  version; on a store with 234,348 of them that had not finished after 25
+  minutes. It now takes 324 ms, and the whole upgrade of that store takes 40
+  seconds with every memory, fact and connection preserved.
+- **A refusal from the service was reported as a crash.** Commands that were
+  correctly denied printed a stack trace instead of the reason, and one denial
+  told users to run a command that does not exist.
+- **`slm connect claude-code` told you to run a command that does not exist.**
+  It pointed at `slm plugin install`; there is no `slm plugin` subcommand, so
+  the only instruction it gave ended in an error with nothing else offered. It
+  now names the two Claude Code commands that actually install the plugin, and
+  the setup wizard that runs both for you. Reported by @barrygfox (#123).
+- **The bridge install in the IDE guide named a package that is not on npm.**
+  `@modelcontextprotocol/client-cli` has never existed, so the documented
+  install could not produce the `mcp-remote` binary that the config we write
+  points at. All three places now name `mcp-remote`, which does provide it.
+  Reported by @tonydzi (#122).
+- **Two settings did not survive a restart.** The consistency threshold and the
+  per-channel retrieval weights were never written to the config file and never
+  read back, so tuning either one — by hand or by switching mode — lasted until
+  the next restart and then reverted to the default with nothing said. Both are
+  now saved and restored, a pair stays a pair through the file, and a section
+  someone has hand-edited into nonsense falls back to defaults instead of
+  stopping `slm` from running. Reported by @barrygfox (#124).
+- **A migration failure said which, never why.** A migration recorded complete
+  is re-checked by its own verification on every start; when that check stops
+  passing, the log still reads complete while the health endpoint reports a
+  failure, and nothing said the two were answering different questions. The
+  health output now carries the reason for each failure, and `slm db migrate
+  --status` marks any migration whose recorded state and actual end-state
+  disagree instead of only reprinting the log. Reported by @unfall103-debug
+  (#125).
+### Changed
+- **Every table that only grows now has a stated limit, or states why it has
+  none.** Three of them had a cleanup routine, each written and wired
+  separately; the fourth was found by reading a disk-usage report and the fifth
+  by reading the fourth. All 45 are now declared in one place with the reasoning
+  attached, one pass enforces them, and a table added without a decision is
+  something the tests can see. On a real store the first pass removed 7,342 rows
+  in 0.4 s, and 123,918 on a larger one — the biggest single group being 83,623
+  records describing memories that had already been deleted.
+  Nothing that holds your memories, your corrections, an erasure record, or the
+  feedback that improves ranking is touched; each of those says so explicitly.
+  Two tables are recorded as growing faster than the store with no rule decided
+  yet, rather than being quietly given one.
+- **Recall assembles your knowledge graph from the graph store.** On a store with
+  208,000 connections that assembly took 2.5 seconds and now takes 0.4. It runs
+  whenever the graph changes, so it was on the path of a recall. The answers are
+  the same — every probe query returns the same memories with the same scores
+  from either source. Recalls that also span shared or global memories continue
+  to read SQLite, which is the only store that holds them.
+
 ## [4.0.10] — Your memories, not the summarizer's
 
 ### Fixed

package/README.md

@@ -5,7 +5,7 @@
   </picture>
 </p>
 
-<h1 align="center">SuperLocalMemory V4.0.10</h1>
+<h1 align="center">SuperLocalMemory V4.1.0</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.0.10</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.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/>
 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.0.10-Current_Release-2ea44f?style=for-the-badge&logo=checkmarx&logoColor=white" alt="v4.0.10 — Current Release"/></a>
+  <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="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>
@@ -45,7 +45,7 @@ Proxy: <code>slm wrap claude</code> &nbsp;·&nbsp; MCP: add <code>slm_compress</
   <a href="https://superlocalmemory.com"><img src="https://img.shields.io/badge/Web-superlocalmemory.com-ff6b35?style=for-the-badge" alt="Website"/></a>
   <a href="#dual-interface-mcp--cli"><img src="https://img.shields.io/badge/MCP-Native-blue?style=for-the-badge" alt="MCP Native"/></a>
   <a href="#dual-interface-mcp--cli"><img src="https://img.shields.io/badge/CLI-Agent--Native-green?style=for-the-badge" alt="CLI Agent-Native"/></a>
-  <a href="#multilingual-embedding-support"><img src="https://img.shields.io/badge/Multilingual-30%2B_Languages-ff69b4?style=for-the-badge" alt="Multilingual 30+ Languages"/></a>
+  <a href="#multilingual-embedding-support"><img src="https://img.shields.io/badge/Multilingual-via_your_embedding_model-ff69b4?style=for-the-badge" alt="Multilingual via your embedding model"/></a>
 </p>
 
 ---
@@ -310,7 +310,7 @@ can run without a cloud LLM:
 
 1. **Fisher-informed scoring** — dense candidate generation uses cosine similarity; Fisher-derived terms can modify later scoring when their state is available.
 2. **Sheaf Cohomology for Consistency** — algebraic topology detects contradictions via coboundary norms on the knowledge graph.
-3. **Riemannian Langevin Lifecycle** — memory positions evolve on the Poincare ball; neglected memories self-archive, no hardcoded thresholds.
+3. **Riemannian Langevin Lifecycle** — memory positions evolve continuously on the Poincare ball, and where a memory sits decides its lifecycle stage. There is no retention timer counting down against a memory: what moves it outward is being left alone, and what pulls it back is being used. The stage boundaries themselves are fixed radii.
 
 Auto-capture hooks are installed explicitly with `slm hooks install` (Claude
 Code) or `slm hooks install --agent codex` (Codex). Hook latency and capture
@@ -386,7 +386,7 @@ Full docs: [docs/multi-machine.md](docs/multi-machine.md) · [docs/distributed-d
 | **Python CLI + SDK** (primary) | Activate a Python virtual environment, then `python -m pip install superlocalmemory` | Python 3.11+; the `slm` CLI and importable SDK stay inside that environment |
 | **Repository clone — macOS/Linux** | `./scripts/install.sh install` | Research/contributor path; delegates to an existing uv or pipx installation |
 | **Repository clone — Windows** | `.\scripts\install.ps1 -Action Install` | Research/contributor path; delegates to an existing uv or pipx installation |
-| **Claude Code Plugin** | `/plugin marketplace add qualixar/superlocalmemory` then `/plugin install superlocalmemory@qualixar` | Self-bootstraps venv, isolated SLM_DATA_DIR, additive — 16-tool core. Ships the skills/agents/hooks/commands |
+| **Claude Code Plugin** | `/plugin marketplace add qualixar/superlocalmemory` then `/plugin install superlocalmemory@qualixar` | Self-bootstraps venv, isolated SLM_DATA_DIR, additive — 34-tool code profile. Ships the skills/agents/hooks/commands |
 | **Portable / IDE connect** | `slm connect <ide> [--here]` | Wire any IDE without reinstalling; `slm connect claude-code` → plugin pointer |
 
 After any install path: `slm setup` → `slm doctor` → `slm warmup` (optional, pre-downloads ~500MB embedding model).
@@ -477,7 +477,7 @@ then install:
 ```
 
 - Self-bootstraps a Python venv, installs all deps in an isolated `SLM_DATA_DIR`
-- Registers the 16-tool core MCP surface (`core16` profile by default; `core14` remains a compatibility alias)
+- 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

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "superlocalmemory",
-  "version": "4.0.10",
+  "version": "4.1.0",
   "description": "Local-first agent memory with MCP and an agent-native CLI. Documented clients include Claude Code, Cursor, and Windsurf.",
   "keywords": [
     "ai-memory",
@@ -50,7 +50,9 @@
     "check:plugin": "node scripts/build-plugin.mjs --check",
     "build:copilot-plugin": "node scripts/build-copilot-plugin.mjs",
     "check:copilot-plugin": "node scripts/build-copilot-plugin.mjs --check",
-    "prepack": "node scripts/build-plugin.mjs && node scripts/build-copilot-plugin.mjs && node scripts/prepack.js",
+    "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",
     "postinstall": "node scripts/postinstall.js",
     "preuninstall": "node scripts/preuninstall.js",
     "test": "node scripts/run-ui-tests.mjs"

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

@@ -3,7 +3,7 @@
     "name": "Qualixar",
     "url": "https://github.com/qualixar/superlocalmemory"
   },
-  "description": "Local-first agent memory + reversible context compression and KV cache, as an MCP server. 21-tool code profile with graph intelligence.",
+  "description": "Local-first agent memory + reversible context compression and KV cache, as an MCP server. 34-tool code profile with graph intelligence.",
   "displayName": "SuperLocalMemory",
   "keywords": [
     "memory",
@@ -15,5 +15,5 @@
   "mcpServers": "./.mcp.json",
   "name": "superlocalmemory",
   "repository": "https://github.com/qualixar/superlocalmemory",
-  "version": "4.0.10"
+  "version": "4.1.0"
 }

package/plugin/CLAUDE.md

@@ -1,4 +1,4 @@
-<!-- BEGIN SuperLocalMemory v4.0.10 -->
+<!-- BEGIN SuperLocalMemory v4.1.0 -->
 
 ## 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.0.10 -->
+<!-- END SuperLocalMemory v4.1.0 -->
 
-SuperLocalMemory v4.0.10 · Qualixar · AGPL-3.0-or-later
+SuperLocalMemory v4.1.0 · 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.0.10 · Qualixar · AGPL-3.0-or-later
+SuperLocalMemory v4.1.0 · Qualixar · AGPL-3.0-or-later

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

@@ -8,7 +8,7 @@ description: >
   completion with an auditable, resumable ledger persisted in SLM. Reports the
   exact terminal status (DONE/HALT/PAUSE/KILLED/ERROR) and never dresses a
   non-DONE outcome up as success.
-tools: Bash, slm_recall, slm_remember, Read
+tools: Bash, recall, remember, Read
 model: inherit
 ---
 
@@ -57,8 +57,8 @@ bounds, or report the exact non-DONE status.
 
 # Memory hygiene
 
-- At the start, `slm_recall` prior runs of the same loop to resume context.
-- On a substantial outcome, `slm_remember` a one-paragraph summary (what the
+- At the start, `recall` prior runs of the same loop to resume context.
+- On a substantial outcome, `remember` a one-paragraph summary (what the
   gate was, the final status, the run_id) so the next session can find it.
 
 # Anti-rationalization
@@ -68,4 +68,4 @@ assessment. The gate is the authority.
 
 ---
 
-SuperLocalMemory v4.0.10 · Qualixar · AGPL-3.0-or-later
+SuperLocalMemory v4.1.0 · 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.0.10 · Qualixar · AGPL-3.0-or-later
+SuperLocalMemory v4.1.0 · 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.0.10 · Qualixar · AGPL-3.0-or-later
+SuperLocalMemory v4.1.0 · Qualixar · AGPL-3.0-or-later

package/plugin/requirements.txt

@@ -1 +1 @@
-superlocalmemory==4.0.10
+superlocalmemory==4.1.0

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.0.10 · Qualixar · AGPL-3.0-or-later
+SuperLocalMemory v4.1.0 · 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.0.10 · Qualixar · AGPL-3.0-or-later
+SuperLocalMemory v4.1.0 · 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.0.10 · Qualixar · AGPL-3.0-or-later*
+*SuperLocalMemory v4.1.0 · 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.0.10 · Qualixar · AGPL-3.0-or-later
+SuperLocalMemory v4.1.0 · Qualixar · AGPL-3.0-or-later

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

@@ -2,7 +2,7 @@
 name: slm-loop
 description: Run gate-verified bounded loops with SuperLocalMemory as the durable ledger. Use when a task has a checkable acceptance condition (tests, schema, lint, reconciliation) and you must iterate until an INDEPENDENT gate passes — never stopping just because the agent believes it is done. `slm loop demo` runs a keyless convergence demo; `slm loop history` and `slm loop show <run_id>` inspect past runs whose every lap is persisted as queryable SLM memory (tag `loop:<name>`). Terminal statuses are DONE / HALT / PAUSE / KILLED / ERROR — report them exactly, never converting HALT/PAUSE/ERROR into success.
 when_to_use: "run a bounded loop, gate-verified task, iterate until tests pass, verify against an independent gate, don't trust the agent's own done claim, slm loop, convergence loop, loop until green, loop ledger, resume a loop"
-allowed-tools: Bash, slm_recall
+allowed-tools: Bash, recall
 ---
 
 # slm-loop — Bounded, gate-verified agent loops
@@ -96,4 +96,4 @@ paused, name the approval needed; when errored, quote the short detail.
 
 ---
 
-SuperLocalMemory v4.0.10 · Qualixar · AGPL-3.0-or-later
+SuperLocalMemory v4.1.0 · Qualixar · AGPL-3.0-or-later

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

@@ -279,4 +279,4 @@ mesh availability.
 
 ---
 
-*SuperLocalMemory v4.0.10 · Qualixar · AGPL-3.0-or-later*
+*SuperLocalMemory v4.1.0 · Qualixar · AGPL-3.0-or-later*

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

@@ -30,10 +30,10 @@ project, a client engagement, a production vs staging environment.
 
 | Profile | Tools | When to use |
 |---------|-------|-------------|
-| `core` | 14 tools — remember, recall, search, session, optimize | Minimal footprint, no code tools |
-| `code` | 29 tools — core + portable Brain evidence + code graph + profile switching + bounded loops | Default for IDE/coding agents |
-| `full` | 47 tools — code + all memory ops + mesh + bounded loops | Multi-session, team workflows |
-| `power` | 59 tools — full + governance + behavioral tools | Enterprise, admin, audit use cases |
+| `core` | 18 tools — remember, recall, search, session, optimize | Minimal footprint, no code tools |
+| `code` | 34 tools — core + portable Brain evidence + code graph + profile switching + bounded loops | Default for IDE/coding agents |
+| `full` | 50 tools — code + all memory ops + mesh + bounded loops | Multi-session, team workflows |
+| `power` | 62 tools — full + governance + behavioral tools | Enterprise, admin, audit use cases |
 | `mesh` | 8 tools — mesh coordination only | Lightweight cross-session signalling |
 
 The profile is set at MCP server startup via `SLM_MCP_PROFILE` in the MCP config.
@@ -146,4 +146,4 @@ Name them differently in your MCP config (e.g. `superlocalmemory-personal` and
 
 ---
 
-*SuperLocalMemory v4.0.10 · Qualixar · AGPL-3.0-or-later*
+*SuperLocalMemory v4.1.0 · Qualixar · AGPL-3.0-or-later*

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

@@ -50,7 +50,7 @@ recall(
   query="authentication strategy decision",
   limit=20,            # default 20; reduce to 5 for quick pre-task checks
   session_id="<sid>",  # pass the session_id returned by session_init
-  fast=False,          # default False; True enables faster, reduced-channel retrieval
+  fast=None,           # leave unset; see "Fast mode" below for what it controls
 )
 ```
 
@@ -65,12 +65,12 @@ Real response shape (`--json` equivalent):
       "score": 0.87,
       "confidence": 0.91,
       "trust_score": 0.84,
-      "fact_type": "decision",
+      "fact_type": "semantic",
       "channel_scores": {
         "semantic": 0.88,
-        "lexical": 0.61,
+        "bm25": 0.61,
         "temporal": 0.72,
-        "structural": 0.55
+        "hopfield": 0.55
       }
     }
   ],
@@ -78,32 +78,92 @@ Real response shape (`--json` equivalent):
   "query_type": "semantic",
   "channel_weights": {
     "semantic": 0.4,
-    "lexical": 0.2,
+    "bm25": 0.2,
     "temporal": 0.2,
-    "structural": 0.2
+    "hopfield": 0.2
   },
+  "channel_status": {
+    "semantic": "ok",
+    "bm25": "ok",
+    "temporal": "empty",
+    "hopfield": "ok",
+    "spreading_activation": "no_candidates",
+    "entity_graph": "no_embedding",
+    "profile": "disabled"
+  },
+  "incomplete_channels": [],
   "retrieval_time_ms": 134,
   "no_confident_match": false
 }
 ```
 
+**Read `channel_status` before concluding that nothing is stored.** It reports
+what each retrieval channel did on this query. `channel_weights` says how much
+each channel counts; `channel_status` says whether it ran at all.
+
+| status | meaning |
+|---|---|
+| `ok` | the channel ran and contributed candidates |
+| `empty` | it ran and there was genuinely nothing to return |
+| `no_candidates` | it ran but nothing survived fusion |
+| `error` | it raised — **its results are missing from this answer** |
+| `timeout` | it exceeded its guard — **results missing** |
+| `no_embedding` | the query could not be embedded, so it could not run |
+| `disabled` | switched off by configuration |
+| `not_configured` | the backing service is not set up |
+
+`semantic`, `bm25`, `temporal`, `hopfield` and `spreading_activation` each
+search and return their own candidates. `profile` is a shortcut that runs before
+them and can answer directly. `entity_graph` produces nothing of its own — it
+re-scores what the others found, by how well each result connects to the
+entities in your question, which is why it reports `no_candidates` when the
+rest come back empty.
+
+`empty`, `no_candidates`, `disabled` and `not_configured` are normal. `error`,
+`timeout` and `no_embedding` mean the answer is **incomplete, not negative** —
+say so to the user rather than reporting "no memories found". `incomplete_channels`
+carries the same warning as a plain list.
+
 **Refine on low confidence.** `recall` returns confidence signals with every result. If `no_confident_match` is `true` (or `answer_confidence` is low / `abstained` is `true`), do NOT invent a memory — rewrite the query into 1–3 more specific sub-queries (split multi-hop questions; try entity names, synonyms, or broader phrasing) and call `recall` again before concluding nothing was found. A confident match → use it directly. SLM returns fast local results (~1–2s, no server-side LLM round on the hot path) and lets you, the calling model, drive this refinement.
 
 ### 2. Passing session_id
 
-Pass the `session_id` returned by `session_init`. It threads engagement signals
-through to the ranker so each recall contributes to improving retrieval for
-your project over time. Omitting it degrades the learning loop — recall works
-correctly, but feedback is not attributed to the session.
+Pass the `session_id` returned by `session_init`, on **every** recall in that
+session. It does two things.
+
+1. **It carries the conversation forward.** Each recall offers its five
+   best-ranked results to a small per-session working set of seven slots. A
+   memory that keeps coming back is reinforced rather than duplicated, and the
+   least-activated slot is the one evicted, so something referenced across
+   several turns is hard to lose. Later recalls in the same session rank the
+   held memories higher, and turn three is not as cold as turn one. The bias is
+   deliberately small — it nudges the order, it never overrides an exact match.
+2. **It attributes engagement to the session**, so a later `report_outcome`
+   can close the loop on the right recall.
+
+Omitting it costs both: recall still returns correct results, but every turn
+starts cold and no feedback is attributable.
+
+**Use the real id, not a made-up one.** An id beginning `http:`, `mcp:`, `cli:`
+or `probe:` is treated as a synthetic per-request label, not a conversation, and
+is excluded from the working set — inventing one per call would otherwise fill
+the registry and evict genuine conversations.
 
 ### 3. Fast mode
 
-Use `fast=True` for pre-tool-call checks where sub-second response matters.
-This enables a faster, reduced-channel mode. Core semantic and keyword channels
-always run; additional graph and contextual channels are skipped.
+`fast` controls **one** thing: whether the server runs its own internal LLM
+reformulation round. It does **not** disable any retrieval channel — every
+channel and the reranker run either way. There are four always: meaning,
+keyword, entity graph and time. Spreading activation and Hopfield register as a
+fifth and sixth when their prerequisites are present, so a store sees up to six.
+
+Leave it unset. Unset resolves to "skip the internal round", because you are the
+reasoner: you refine the query yourself using the confidence signals above, and
+you do it better than a local model would. Pass `fast=False` only when SLM is
+deployed with no capable client in front of it.
 
 ```
-recall(query="rate limiting approach", limit=5, session_id="<sid>", fast=True)
+recall(query="rate limiting approach", limit=5, session_id="<sid>")
 ```
 
 ### 4. Keyword fallback via search
@@ -138,6 +198,33 @@ once you have the `fact_id` for full content.
 
 ---
 
+### 7. Close the loop — say which memories helped
+
+Retrieval ranks a memory partly on whether it has actually been useful before.
+That evidence only exists if you supply it.
+
+```
+report_outcome(
+  memory_ids="f8a2bc91,c31d0f77",   # the ids you actually used
+  outcome="success",                # "success" | "failure" | "partial"
+  context="used the JWT expiry decision to write the refresh handler",
+)
+```
+
+Call it when a recall visibly changed what you did: you applied the decision,
+followed the convention, or avoided the gotcha. Report `failure` when a
+confidently-returned memory turned out to be wrong or stale — a negative signal
+is worth as much as a positive one, and it is the only way a stale memory stops
+being promoted.
+
+Report only ids you genuinely used. Reporting every returned id marks the
+irrelevant ones useful and trains the ranker toward noise.
+
+`report_feedback(fact_id, feedback, query)` is the finer-grained form for a
+single fact and the query that surfaced it.
+
+---
+
 ## How multi-channel retrieval works
 
 `recall` runs multiple candidate producers in parallel — semantic vector similarity,
@@ -236,4 +323,4 @@ before recalling, then switch back. See `slm-profile` for workspace switching.
 
 ---
 
-*SuperLocalMemory v4.0.10 · Qualixar · AGPL-3.0-or-later*
+*SuperLocalMemory v4.1.0 · Qualixar · AGPL-3.0-or-later*