@xdarkicex/openclaw-memory-libravdb 1.6.22 → 1.6.25

package/README.md

@@ -14,7 +14,7 @@
 `@xdarkicex/openclaw-memory-libravdb` is a local-first OpenClaw memory plugin
 backed by the `libravdbd` vector service. It replaces the lightweight default memory
 path with scoped session, user, and global memory; continuity-aware prompt
-assembly; durable recall; and sidecar-owned compaction.
+assembly; durable recall; and daemon-owned compaction.
 
 [Install](./docs/install.md) · [Full installation reference](./docs/installation.md) · [Architecture](./docs/architecture.md) · [Security](./docs/security.md) · [Performance and tuning](./docs/performance-and-tuning.md) · [Contributing](./docs/contributing.md)
 
@@ -109,7 +109,7 @@ Runtime requirements:
 
 Compatibility note:
 
-- this plugin is currently verified against OpenClaw `2026.4.23`
+- this plugin is currently verified against OpenClaw `2026.5.22`
 
 Default endpoints:
 
@@ -139,7 +139,7 @@ If your service runs elsewhere, set `sidecarPath`:
 - **Memory capability ownership** - owns the OpenClaw `memory` slot and
   registers the context engine capability at runtime.
 - **Memory runtime bridge** - routes built-in `memory_search` calls to the same
-  libraVDB-backed sidecar on hosts that expose the runtime API.
+  libraVDB-backed daemon on hosts that expose the runtime API.
 - **Three memory scopes** - keeps active session, durable user, and global memory
   separate.
 - **Hybrid retrieval** - blends semantic similarity, scope, recency, and summary

package/dist/context-engine.js

@@ -445,6 +445,7 @@ function rankExactRecallCandidate(result, token) {
 }
 /**
  * Extracts the exact recall fact text starting at the token marker.
+ * Tool-call patterns are sanitized to prevent loop-priming.
  */
 function extractExactRecallFactText(text, token) {
     const markerStart = text.indexOf(token);
@@ -452,7 +453,8 @@ function extractExactRecallFactText(text, token) {
         return text.trim();
     const tail = text.slice(markerStart).trim();
     const factSentence = tail.match(/^[\s\S]*?\bmeans\b[\s\S]*?[.!?](?:\s|$)/i)?.[0]?.trim();
-    return factSentence ?? tail.split("\n")[0]?.trim() ?? tail;
+    const extracted = factSentence ?? tail.split("\n")[0]?.trim() ?? tail;
+    return sanitizeToolCallPatterns(extracted);
 }
 /**
  * Escapes special characters in memory fact text for safe rendering.
@@ -468,6 +470,38 @@ function escapeMemoryFactText(text) {
         .replaceAll("\n", "
")
         .replaceAll("\t", "	");
 }
+// Tool-call pattern detection for sanitization
+const TOOL_CALL_BRACKET_RE = /\[tool:([^\]]+)\]/gi;
+const TOOL_CALL_JSON_RE = /\{\s*"name"\s*:\s*"([^"]+)"[^}]*\}/g;
+const TOOL_RESULT_ANNOTATION_RE = /\[tool:[^\]]+\](?:\s*[^{\[]*)?/g;
+/**
+ * Sanitizes text that may contain tool-call syntax to prevent loop-priming.
+ * Replaces executable-looking patterns with neutral summaries rather than
+ * replaying them verbatim, so the model cannot pattern-match and repeat them.
+ */
+function sanitizeToolCallPatterns(text) {
+    let sanitized = text;
+    // Replace [tool:name] patterns with a neutral summary
+    sanitized = sanitized.replace(TOOL_CALL_BRACKET_RE, (_match, toolName) => {
+        return `[historical tool call: ${toolName}]`;
+    });
+    // Replace JSON tool-call objects with a neutral summary
+    sanitized = sanitized.replace(TOOL_CALL_JSON_RE, (_match, toolName) => {
+        return `[historical tool call: ${toolName}]`;
+    });
+    // Replace remaining tool-result annotations
+    sanitized = sanitized.replace(TOOL_RESULT_ANNOTATION_RE, "[historical tool call]");
+    // Detect and summarize repeated tool calls (loop indicator)
+    const toolCallCount = (sanitized.match(/\[historical tool call:\s*([^\]]+)\]/gi) || []).length;
+    if (toolCallCount > 2) {
+        const uniqueTools = new Set([...sanitized.matchAll(/\[historical tool call:\s*([^\]]+)\]/gi)].map((m) => m[1]));
+        if (uniqueTools.size === 1) {
+            // Single tool repeated multiple times — likely a loop, summarize aggressively
+            sanitized = `[Historical tool activity: repeated ${[...uniqueTools][0]} call ${toolCallCount} times. Do not repeat this pattern.]`;
+        }
+    }
+    return sanitized;
+}
 const TRUNCATION_MARKER = "...[truncated]";
 /**
  * Attempts to truncate an item to fit within token budget.
@@ -671,8 +705,9 @@ export function normalizeAssembleResult(result, sourceMessages) {
             }
             else {
                 if (content.trim().length > 0) {
+                    const sanitizedContent = sanitizeToolCallPatterns(content);
                     const roleAttr = message.role ? ` role="${escapeMemoryFactText(message.role)}"` : "";
-                    extractedMemoryItems.push(`<memory_item source="recalled"${roleAttr} provenance="durable_memory">${escapeMemoryFactText(content)}</memory_item>`);
+                    extractedMemoryItems.push(`<memory_item source="recalled"${roleAttr} provenance="durable_memory">${escapeMemoryFactText(sanitizedContent)}</memory_item>`);
                 }
             }
         }

package/dist/index.js

@@ -26891,11 +26891,35 @@ function extractExactRecallFactText(text, token) {
   if (markerStart < 0) return text.trim();
   const tail = text.slice(markerStart).trim();
   const factSentence = tail.match(/^[\s\S]*?\bmeans\b[\s\S]*?[.!?](?:\s|$)/i)?.[0]?.trim();
-  return factSentence ?? tail.split("\n")[0]?.trim() ?? tail;
+  const extracted = factSentence ?? tail.split("\n")[0]?.trim() ?? tail;
+  return sanitizeToolCallPatterns(extracted);
 }
 function escapeMemoryFactText(text) {
   return text.replaceAll("&", "&amp;").replaceAll("<", "&lt;").replaceAll(">", "&gt;").replaceAll('"', "&quot;").replaceAll("'", "&#39;").replaceAll("\r", "&#13;").replaceAll("\n", "&#10;").replaceAll("	", "&#9;");
 }
+var TOOL_CALL_BRACKET_RE = /\[tool:([^\]]+)\]/gi;
+var TOOL_CALL_JSON_RE = /\{\s*"name"\s*:\s*"([^"]+)"[^}]*\}/g;
+var TOOL_RESULT_ANNOTATION_RE = /\[tool:[^\]]+\](?:\s*[^{\[]*)?/g;
+function sanitizeToolCallPatterns(text) {
+  let sanitized = text;
+  sanitized = sanitized.replace(TOOL_CALL_BRACKET_RE, (_match, toolName) => {
+    return `[historical tool call: ${toolName}]`;
+  });
+  sanitized = sanitized.replace(TOOL_CALL_JSON_RE, (_match, toolName) => {
+    return `[historical tool call: ${toolName}]`;
+  });
+  sanitized = sanitized.replace(TOOL_RESULT_ANNOTATION_RE, "[historical tool call]");
+  const toolCallCount = (sanitized.match(/\[historical tool call:\s*([^\]]+)\]/gi) || []).length;
+  if (toolCallCount > 2) {
+    const uniqueTools = new Set(
+      [...sanitized.matchAll(/\[historical tool call:\s*([^\]]+)\]/gi)].map((m) => m[1])
+    );
+    if (uniqueTools.size === 1) {
+      sanitized = `[Historical tool activity: repeated ${[...uniqueTools][0]} call ${toolCallCount} times. Do not repeat this pattern.]`;
+    }
+  }
+  return sanitized;
+}
 var TRUNCATION_MARKER = "...[truncated]";
 function tryTruncateItem(rawText, tag, attributes, maxTokenBudget) {
   const tagOpen = attributes ? `<${tag}${attributes}>` : `<${tag}>`;
@@ -27075,8 +27099,9 @@ function normalizeAssembleResult(result, sourceMessages) {
         });
       } else {
         if (content.trim().length > 0) {
+          const sanitizedContent = sanitizeToolCallPatterns(content);
           const roleAttr = message.role ? ` role="${escapeMemoryFactText(message.role)}"` : "";
-          extractedMemoryItems.push(`<memory_item source="recalled"${roleAttr} provenance="durable_memory">${escapeMemoryFactText(content)}</memory_item>`);
+          extractedMemoryItems.push(`<memory_item source="recalled"${roleAttr} provenance="durable_memory">${escapeMemoryFactText(sanitizedContent)}</memory_item>`);
         }
       }
     }
@@ -33072,6 +33097,13 @@ var DirectoryMarkdownSourceAdapter = class {
     if (!this.started || this.stopping) {
       return;
     }
+    for (const state of this.states.values()) {
+      if (state.scanState.timer) {
+        clearTimeout(state.scanState.timer);
+        state.scanState.timer = null;
+      }
+      state.scanState.dirty = false;
+    }
     for (const root of this.roots) {
       await this.scanRoot(root);
     }
@@ -33213,11 +33245,11 @@ var DirectoryMarkdownSourceAdapter = class {
         continue;
       }
       stats.filesIncluded++;
-      currentFiles.add(child);
       const stat = await this.safeStatWithCtime(child);
       if (!stat) {
         continue;
       }
+      currentFiles.add(child);
       candidates.push({ path: child, size: stat.size, mtimeMs: stat.mtimeMs, ctimeMs: stat.ctimeMs, ordinal: candidates.length });
     }
   }
@@ -33232,6 +33264,8 @@ var DirectoryMarkdownSourceAdapter = class {
         this.lastRetryAfterMs = 0;
       } else {
         rootState.scanState.resumeFromPath = null;
+        this.lastAcceptMore = true;
+        this.lastRetryAfterMs = 0;
       }
     }
     for (const candidate of sorted) {

package/dist/markdown-ingest.js

@@ -147,6 +147,14 @@ class DirectoryMarkdownSourceAdapter {
         if (!this.started || this.stopping) {
             return;
         }
+        // Cancel any pending scheduled scans so they don't race with this refresh
+        for (const state of this.states.values()) {
+            if (state.scanState.timer) {
+                clearTimeout(state.scanState.timer);
+                state.scanState.timer = null;
+            }
+            state.scanState.dirty = false;
+        }
         for (const root of this.roots) {
             await this.scanRoot(root);
         }
@@ -291,11 +299,11 @@ class DirectoryMarkdownSourceAdapter {
                 continue;
             }
             stats.filesIncluded++;
-            currentFiles.add(child);
             const stat = await this.safeStatWithCtime(child);
             if (!stat) {
                 continue;
             }
+            currentFiles.add(child);
             candidates.push({ path: child, size: stat.size, mtimeMs: stat.mtimeMs, ctimeMs: stat.ctimeMs, ordinal: candidates.length });
         }
     }
@@ -310,7 +318,10 @@ class DirectoryMarkdownSourceAdapter {
                 this.lastRetryAfterMs = 0;
             }
             else {
+                // Resume cursor target was deleted — clear it and resume normal processing
                 rootState.scanState.resumeFromPath = null;
+                this.lastAcceptMore = true;
+                this.lastRetryAfterMs = 0;
             }
         }
         for (const candidate of sorted) {
@@ -439,6 +450,8 @@ class DirectoryMarkdownSourceAdapter {
     async syncMarkdownFile(rootState, filePath, initialStat) {
         const sourceDoc = filePath;
         const relativePath = toPosixPath(path.relative(rootState.root, filePath));
+        // Re-check existence when initialStat is provided — the file may have been
+        // deleted between the scan pass and the sync pass.
         const stat = initialStat ?? (await this.safeStatWithCtime(filePath));
         if (!stat) {
             await this.deleteSourceDocument(sourceDoc);

package/docs/README.md

@@ -6,14 +6,14 @@ deeper by goal.
 
 ## Start Here
 
-- [Install](./install.md) - shortest supported install and daemon lifecycle path.
+- [Install](./install.md) - shortest supported install and vector service lifecycle path.
 - [Installation reference](./installation.md) - requirements, activation, verification, and troubleshooting.
-- [Uninstall](./uninstall.md) - safe disable, daemon shutdown, package removal, and optional data cleanup.
+- [Uninstall](./uninstall.md) - safe disable, vector service shutdown, package removal, and optional data cleanup.
 
 ## Understand The System
 
 - [Problem](./problem.md) - why this plugin replaces the stock memory lifecycle.
-- [Architecture](./architecture.md) - plugin, sidecar, storage, retrieval, and compaction overview.
+- [Architecture](./architecture.md) - plugin, vector service, storage, retrieval, and compaction overview.
 - [Dependency rationale](./dependencies.md) - why LibraVDB and slab-style storage fit this workload.
 - [Architecture decisions](./architecture-decisions/README.md) - accepted ADRs.
 
@@ -27,5 +27,5 @@ deeper by goal.
 ## Advanced And Source Docs
 
 - [Performance and tuning](./performance-and-tuning.md) - resource expectations and tuning knobs.
-- [Development](./development.md) - source setup, local daemon builds, generated IPC files, and validation commands.
+- [Development](./development.md) - source setup, local vector service builds, generated IPC files, and validation commands.
 - [Contributing](./contributing.md) - contributor workflow and repository expectations.

package/docs/TLS_configuration.md

@@ -1,6 +1,6 @@
 # TLS Configuration
 
-The plugin selects the right credentials automatically based on which address it connects to. Unix sockets and loopback addresses (localhost, 127.0.0.1, ::1) always use plaintext. All other addresses use TLS. In most deployments no TLS configuration is needed at all. The only time manual configuration is required is when the daemon serves TLS on a loopback address, when the daemon uses a self-signed or private-CA certificate, or when infrastructure such as a service mesh handles TLS outside the plugin.
+The plugin selects the right credentials automatically based on which address it connects to. Unix sockets and loopback addresses (localhost, 127.0.0.1, ::1) always use plaintext. All other addresses use TLS. In most deployments no TLS configuration is needed at all. The only time manual configuration is required is when the vector service serves TLS on a loopback address, when the vector service uses a self-signed or private-CA certificate, or when infrastructure such as a service mesh handles TLS outside the plugin.
 
 ## Default behavior
 
@@ -18,21 +18,21 @@ Because these rules are automatic, most users do not set any TLS-related fields.
 
 | Field | Type | Default | When to use |
 |---|---|---|---|
-| `grpcEndpoint` | string | — | The daemon address. Set to a unix socket path, a loopback address, or a remote host. |
-| `grpcEndpointTlsCa` | string | — | Path to a CA certificate PEM file. Required only when the daemon certificate is self-signed or signed by a private CA not in the system certificate store. |
+| `grpcEndpoint` | string | — | The vector service address. Set to a unix socket path, a loopback address, or a remote host. |
+| `grpcEndpointTlsCa` | string | — | Path to a CA certificate PEM file. Required only when the vector service certificate is self-signed or signed by a private CA not in the system certificate store. |
 | `grpcEndpointTlsMode` | `"auto"` \| `"tls"` \| `"insecure"` | `"auto"` | Override the automatic selection. `"auto"` applies the default rules above. `"tls"` forces TLS regardless of address. `"insecure"` forces plaintext regardless of address. |
 
 `grpcEndpointTlsMode` values explained:
 
 - **`"auto"`** (default) — apply the automatic rules. Unix sockets and loopback use plaintext; all other addresses use TLS.
-- **`"tls"`** — always use TLS, even for loopback addresses. Use this when the daemon has TLS enabled on a loopback address.
+- **`"tls"`** — always use TLS, even for loopback addresses. Use this when the vector service has TLS enabled on a loopback address.
 - **`"insecure"`** — always use plaintext, even for remote addresses. Use this only when a service mesh or TLS-terminating tunnel handles encryption externally.
 
 ## Deployment scenarios
 
-### Local daemon (default)
+### Local vector service (default)
 
-The daemon runs on the same machine, listening on a unix socket or a loopback address.
+The vector service runs on the same machine, listening on a unix socket or a loopback address.
 
 ```json
 {
@@ -50,9 +50,9 @@ or:
 
 The plugin automatically uses plaintext. No TLS fields are needed.
 
-### Remote daemon with a trusted certificate
+### Remote vector service with a trusted certificate
 
-The daemon runs on a remote host and presents a certificate issued by a public CA such as Let's Encrypt or cert-manager.
+The vector service runs on a remote host and presents a certificate issued by a public CA such as Let's Encrypt or cert-manager.
 
 ```json
 {
@@ -60,11 +60,11 @@ The daemon runs on a remote host and presents a certificate issued by a public C
 }
 ```
 
-TLS is automatic. The plugin uses the system certificate store to verify the daemon's certificate, so no additional configuration is needed.
+TLS is automatic. The plugin uses the system certificate store to verify the vector service's certificate, so no additional configuration is needed.
 
-### Remote daemon with a self-signed or private CA certificate
+### Remote vector service with a self-signed or private CA certificate
 
-The daemon runs on a remote host and uses a self-signed certificate or a certificate signed by a private/internal CA not in the system certificate store.
+The vector service runs on a remote host and uses a self-signed certificate or a certificate signed by a private/internal CA not in the system certificate store.
 
 ```json
 {
@@ -73,11 +73,11 @@ The daemon runs on a remote host and uses a self-signed certificate or a certifi
 }
 ```
 
-The CA certificate must be the certificate of the CA that signed the daemon's server certificate — not the server certificate itself. The plugin uses this CA to verify the daemon's certificate during the TLS handshake. Without it, the plugin will reject the daemon's certificate as untrusted.
+The CA certificate must be the certificate of the CA that signed the vector service's server certificate — not the server certificate itself. The plugin uses this CA to verify the vector service's certificate during the TLS handshake. Without it, the plugin will reject the vector service's certificate as untrusted.
 
 ### TLS on a loopback address
 
-The daemon has TLS enabled on a loopback address. This is uncommon. The automatic rules would select plaintext for a loopback address, so an explicit override is required.
+The vector service has TLS enabled on a loopback address. This is uncommon. The automatic rules would select plaintext for a loopback address, so an explicit override is required.
 
 ```json
 {
@@ -86,11 +86,11 @@ The daemon has TLS enabled on a loopback address. This is uncommon. The automati
 }
 ```
 
-Set `grpcEndpointTlsMode` to `"tls"` to force the plugin to use TLS even on the loopback address. The plugin will use the system certificate store for verification. If the daemon uses a self-signed certificate, add `grpcEndpointTlsCa` as well.
+Set `grpcEndpointTlsMode` to `"tls"` to force the plugin to use TLS even on the loopback address. The plugin will use the system certificate store for verification. If the vector service uses a self-signed certificate, add `grpcEndpointTlsCa` as well.
 
 ## Service mesh and tunnels
 
-When the daemon runs behind Istio, Envoy, or any other infrastructure that terminates TLS at the mesh or tunnel layer, the plugin should not attempt its own TLS. Set `grpcEndpointTlsMode` to `"insecure"` so the plugin uses plaintext and lets the mesh handle encryption:
+When the vector service runs behind Istio, Envoy, or any other infrastructure that terminates TLS at the mesh or tunnel layer, the plugin should not attempt its own TLS. Set `grpcEndpointTlsMode` to `"insecure"` so the plugin uses plaintext and lets the mesh handle encryption:
 
 ```json
 {
@@ -105,8 +105,8 @@ This applies even for remote addresses. The mesh terminates TLS at the boundary,
 
 | Error | Likely cause | Fix |
 |---|---|---|
-| `UNAVAILABLE / connection closed / TLS handshake failed` when connecting to a loopback address | The daemon has TLS enabled on a loopback address but the plugin is using plaintext (the default for loopback). | Add `"grpcEndpointTlsMode": "tls"` to the plugin config. |
-| `x509: certificate signed by unknown authority` | The daemon uses a self-signed certificate or a certificate from a private CA not trusted by the system. | Set `grpcEndpointTlsCa` to the path of the CA certificate PEM file that signed the daemon's server certificate. |
+| `UNAVAILABLE / connection closed / TLS handshake failed` when connecting to a loopback address | The vector service has TLS enabled on a loopback address but the plugin is using plaintext (the default for loopback). | Add `"grpcEndpointTlsMode": "tls"` to the plugin config. |
+| `x509: certificate signed by unknown authority` | The vector service uses a self-signed certificate or a certificate from a private CA not trusted by the system. | Set `grpcEndpointTlsCa` to the path of the CA certificate PEM file that signed the vector service's server certificate. |
 | `failed to load TLS CA certificate from "...": ENOENT: no such file or directory` | The file path given in `grpcEndpointTlsCa` does not exist on the machine. | Verify the file path is correct and the CA certificate file exists. |
 | `LibraVDB: invalid grpcEndpointTlsMode "..."` | The value set in `grpcEndpointTlsMode` is not one of the accepted values. | Change the value to `"auto"`, `"tls"`, or `"insecure"`. |
 | `LIBRAVDB: grpcEndpointTlsCa is set but grpcEndpointTlsMode is "insecure"` (warning) | Both `grpcEndpointTlsCa` and `grpcEndpointTlsMode: "insecure"` are set. The CA file will not be used. | Remove `grpcEndpointTlsCa` if plaintext is intended, or change `grpcEndpointTlsMode` to `"auto"` or `"tls"` to use the CA file. |

package/docs/architecture-decisions/adr-004-sidecar-over-native-ts.md

@@ -6,7 +6,7 @@ The plugin requires local vector storage, ONNX inference, transport isolation, a
 
 ## Decision
 
-Implement the memory engine as a Go daemon with a narrow JSON-RPC transport boundary.
+Implement the memory engine as a Go vector service with a narrow gRPC transport boundary.
 
 ## Alternatives Considered
 

package/docs/architecture.md

@@ -10,9 +10,9 @@ LibraVDB Memory is split into two cooperating pieces:
 
 - a TypeScript OpenClaw plugin that owns the `memory` slot and registers
   context-engine capability at runtime
-- a Go sidecar daemon that owns storage, retrieval, and compaction
+- a Go vector service that owns storage, retrieval, and compaction
 
-The plugin keeps the host integration light and stable. The daemon keeps the
+The plugin keeps the host integration light and stable. The vector service keeps the
 data path local-first and handles the expensive memory operations outside the
 main chat process.
 
@@ -22,9 +22,9 @@ main chat process.
 flowchart LR
   Host["OpenClaw host"]
   Plugin["TypeScript plugin\nregistration + context engine"]
-  Runtime["Plugin runtime\nlazy daemon connect + RPC"]
+  Runtime["Plugin runtime\nlazy vector service connect + RPC"]
   MPS["memoryPromptSection\ncapability header"]
-  Sidecar["Go daemon"]
+  Sidecar["Go vector service"]
   Store["LibraVDB store"]
   Embed["Embedding engine"]
   Summarizer["Summarizer(s)"]
@@ -47,7 +47,7 @@ main retrieval path.
 
 ### `ingest`
 
-Session messages are written into the sidecar-backed store. User turns may also
+Session messages are written into the vector service-backed store. User turns may also
 be promoted into durable user memory after gating.
 
 ### `assemble`
@@ -72,13 +72,13 @@ thresholds, compaction declines instead of forcing a rewrite.
 - retrieval happens in `assemble`
 - compaction is separate from prompt construction
 - lifecycle hints such as `before_reset` and `session_end` are advisory
-- the sidecar is the source of truth for stored memory state
+- the vector service is the source of truth for stored memory state
 
 ## Failure Handling
 
 The plugin is designed to degrade gracefully:
 
-- if the daemon is unavailable, prompt assembly continues without recall
+- if the vector service is unavailable, prompt assembly continues without recall
 - if compaction fails, the active session is not blocked
 - if summarization is unavailable, the system falls back to the safer path
 
@@ -93,5 +93,5 @@ This architecture keeps the host integration simple while still supporting:
 - explicit compaction
 - local-first storage and retrieval
 
-In short, the plugin owns the lifecycle contract, and the sidecar owns the
+In short, the plugin owns the lifecycle contract, and the vector service owns the
 heavy lifting.

package/docs/configuration.md

@@ -34,45 +34,45 @@ Use `grpcEndpointTlsMode` to override the default behavior:
 
 | Value | When to use |
 |---|---|
-| `"auto"` (default) | Standard operation — plugin heuristic matches daemon TLS setting automatically. |
-| `"tls"` | Daemon has TLS enabled on loopback or unix socket (rare; use when the daemon's `LIBRAVDB_GRPC_TLS_*` env vars are set on a local address). |
+| `"auto"` (default) | Standard operation — plugin heuristic matches vector service TLS setting automatically. |
+| `"tls"` | Daemon has TLS enabled on loopback or unix socket (rare; use when the vector service's `LIBRAVDB_GRPC_TLS_*` env vars are set on a local address). |
 | `"insecure"` | Service mesh or TLS-terminating tunnel handles encryption externally; both sides are plaintext. |
 
-**Default (local daemon):** No TLS configuration needed.
+**Default (local vector service):** No TLS configuration needed.
 Unix socket and loopback endpoints are always plaintext regardless
 of any TLS settings.
 
-**K8 / remote daemon with CA-issued cert:**
+**K8 / remote vector service with CA-issued cert:**
 No extra configuration needed. The plugin uses the system CA pool,
 which trusts certs issued by Let's Encrypt, cert-manager, and
 other public CAs automatically.
 
-**Remote daemon with self-signed or private CA cert:**
+**Remote vector service with self-signed or private CA cert:**
 Set `grpcEndpointTlsCa` to the path of the CA certificate PEM file:
 ```json
 {
-  "grpcEndpoint": "tcp:yourdaemon.internal:50051",
+  "grpcEndpoint": "tcp:yourvector service.internal:50051",
   "grpcEndpointTlsCa": "/etc/certs/ca.pem"
 }
 ```
-The daemon must be configured with matching TLS cert and key via
+The vector service must be configured with matching TLS cert and key via
 `LIBRAVDB_GRPC_TLS_CERT` and `LIBRAVDB_GRPC_TLS_KEY`.
 
-**Remote daemon with mTLS (mutual TLS):**
-When the daemon requires client certificate authentication, set both
+**Remote vector service with mTLS (mutual TLS):**
+When the vector service requires client certificate authentication, set both
 `grpcEndpointTlsClientCert` and `grpcEndpointTlsClientKey` (they must both
 be present or both be omitted):
 ```json
 {
-  "grpcEndpoint": "tcp:yourdaemon.internal:50051",
+  "grpcEndpoint": "tcp:yourvector service.internal:50051",
   "grpcEndpointTlsCa": "/etc/certs/ca.pem",
   "grpcEndpointTlsClientCert": "/etc/certs/client-cert.pem",
   "grpcEndpointTlsClientKey": "/etc/certs/client-key.pem"
 }
 ```
 
-**Local daemon with TLS enabled:**
-If the daemon has `LIBRAVDB_GRPC_TLS_CERT`/`LIBRAVDB_GRPC_TLS_KEY` set on a loopback
+**Local vector service with TLS enabled:**
+If the vector service has `LIBRAVDB_GRPC_TLS_CERT`/`LIBRAVDB_GRPC_TLS_KEY` set on a loopback
 address, explicitly set `grpcEndpointTlsMode: "tls"` to match:
 ```json
 {
@@ -89,7 +89,7 @@ address, explicitly set `grpcEndpointTlsMode: "tls"` to match:
 | `fallbackProfile` | string | `bge-small-en-v1.5` | Fallback when primary model fails dimension checks |
 | `embeddingBackend` | string | — | `bundled`, `onnx-local`, `custom-local`, or `remote` |
 | `onnxDevice` | string | `auto` | ONNX execution provider: `auto`, `cpu`, `coreml` (macOS), `cuda` (Linux/Windows), `directml` (Windows), `openvino` (Linux) |
-| `embeddingRuntimePath` | string | — | Path to ONNX runtime library visible to the daemon (maps to `LIBRAVDB_ONNX_RUNTIME`; required with `embeddingBackend: "onnx-local"`) |
+| `embeddingRuntimePath` | string | — | Path to ONNX runtime library visible to the vector service (maps to `LIBRAVDB_ONNX_RUNTIME`; required with `embeddingBackend: "onnx-local"`) |
 | `embeddingModelPath` | string | — | Path to the model directory containing `embedding.json`, `model.onnx`, and `tokenizer.json` (maps to `LIBRAVDB_EMBEDDING_MODEL`; required with `embeddingBackend: "onnx-local"`) |
 | `embeddingTokenizerPath` | string | — | Path to custom tokenizer file |
 | `embeddingDimensions` | number | — | Embedding dimension override |

package/docs/contributing.md

@@ -1,6 +1,6 @@
 # Contributing
 
-Use [Development](./development.md) for source setup, local daemon preparation,
+Use [Development](./development.md) for source setup, local vector service preparation,
 generated IPC files, and validation commands. This document covers contribution
 expectations.
 
@@ -13,11 +13,11 @@ pnpm check
 npm run test:integration
 ```
 
-Integration tests require a running daemon or a prepared local daemon binary.
+Integration tests require a running vector service or a prepared local vector service binary.
 Use:
 
 ```bash
-bash scripts/build-daemon.sh
+bash scripts/build-vector service.sh
 ```
 
 ## Behavioral Changes
@@ -28,8 +28,8 @@ regression.
 
 ## PR Expectations
 
-- Keep plugin lifecycle and daemon lifecycle separate.
+- Keep plugin lifecycle and vector service lifecycle separate.
 - Include focused docs updates for user-visible behavior or config changes.
 - Keep internal design changes reflected in the appropriate design notes.
-- Do not add install-time daemon bootstrap to the npm/OpenClaw package without
+- Do not add install-time vector service bootstrap to the npm/OpenClaw package without
   documenting the security and distribution trade-off.

package/docs/dependencies.md

@@ -33,6 +33,6 @@ Slab-style raw-vector storage was selected because:
 - collections grow in bursty append patterns
 - compaction and search create pressure on allocation churn
 
-The measured conclusion from the internal profiling pass was that slab-backed raw-vector storage was performance-competitive with the plain in-memory backend while making allocation behavior more predictable. The main trade-off is reserved-but-unused capacity, which is acceptable for this local sidecar workload.
+The measured conclusion from the internal profiling pass was that slab-backed raw-vector storage was performance-competitive with the plain in-memory backend while making allocation behavior more predictable. The main trade-off is reserved-but-unused capacity, which is acceptable for this local vector service workload.
 
 The dependency is therefore justified by workload shape, not by novelty.

package/docs/development.md

@@ -8,9 +8,9 @@ installation, use [Install](./install.md).
 - Node.js `>= 22`
 - `pnpm`
 - OpenClaw CLI for end-to-end plugin testing
-- a published or locally built `libravdbd` daemon for integration tests
+- a published or locally built `libravdbd` vector service for integration tests
 
-Go is only required when building the daemon from a local daemon checkout or
+Go is only required when building the vector service from a local vector service checkout or
 regenerating Go gRPC stubs.
 
 ## Source Setup
@@ -29,19 +29,19 @@ pnpm run test:ts
 
 ## Local Daemon Build
 
-Prepare `.daemon-bin/libravdbd` for local plugin testing:
+Prepare `.vector service-bin/libravdbd` for local plugin testing:
 
 ```bash
-bash scripts/build-daemon.sh
+bash scripts/build-vector service.sh
 ```
 
 Supported inputs:
 
-- installed daemon on `PATH`, such as `brew install libravdbd`
+- installed vector service on `PATH`, such as `brew install libravdbd`
 - `LIBRAVDBD_BINARY_PATH=/path/to/libravdbd`
-- `LIBRAVDBD_SOURCE_DIR=/path/to/libravdbd` to build from a local daemon repo
+- `LIBRAVDBD_SOURCE_DIR=/path/to/libravdbd` to build from a local vector service repo
 
-For daemon-internal Go development and release work, use the separate
+For vector service-internal Go development and release work, use the separate
 `libravdbd` repository.
 
 ## Validation Commands
@@ -96,7 +96,7 @@ The npm package contains:
 - `dist/`
 
 The package is connect-only. It does not compile Go code, download models, or
-manage the daemon process during plugin installation.
+manage the vector service process during plugin installation.
 
 ## Release Automation
 
@@ -113,5 +113,5 @@ label. The workflow auto-bumps, tags, and publishes.
 
 ## Auto-Install Script
 
-`scripts/auto-install.sh` automates daemon + plugin installation. Run it when
+`scripts/auto-install.sh` automates vector service + plugin installation. Run it when
 setting up a machine that needs the full stack quickly.

package/docs/embedding-profiles.md

@@ -9,7 +9,7 @@ Default selection baseline:
 
 Why:
 
-- Nomic is the default because its Matryoshka-trained embeddings deliver significantly higher retrieval accuracy than MiniLM, with principled dimensionality tiering (`64d → 256d → 768d`) that lets the daemon trade memory for precision without re-embedding.
+- Nomic is the default because its Matryoshka-trained embeddings deliver significantly higher retrieval accuracy than MiniLM, with principled dimensionality tiering (`64d → 256d → 768d`) that lets the vector service trade memory for precision without re-embedding.
 - bge-small-en-v1.5 is the fallback for resource-constrained systems and is automatically selected when the primary model's dimensions do not match the active collection.
 - Intel Macs without reliable Metal/MPS support should set `onnxDevice: "cpu"` to force CPU ONNX execution and bypass CoreML.
 
@@ -32,33 +32,33 @@ How it works:
 - `embeddingProfile` supplies metadata defaults like family, dimensions, and normalize behavior.
 - `onnx-local` still requires local model assets through `embeddingModelPath`, typically a directory containing `embedding.json`.
 - The manifest may override or refine the profile, but explicit dimension mismatches fail closed.
-- The sidecar store persists an embedding fingerprint, so reopening an existing store with a different effective model profile will fail instead of silently mixing vector spaces.
-- `onnxDevice` is passed through as `LIBRAVDB_ONNX_DEVICE` for daemon versions that support execution-provider selection (`auto`, `cpu`, `cuda`, `coreml`, `directml`, `openvino`).
+- The vector service store persists an embedding fingerprint, so reopening an existing store with a different effective model profile will fail instead of silently mixing vector spaces.
+- `onnxDevice` is passed through as `LIBRAVDB_ONNX_DEVICE` for vector service versions that support execution-provider selection (`auto`, `cpu`, `cuda`, `coreml`, `directml`, `openvino`).
 
 ## Store Compatibility and Upgrades
 
 The persisted embedding fingerprint is part of the database compatibility check.
-That is intentional: if a daemon opens a store with a different effective model
+That is intentional: if a vector service opens a store with a different effective model
 profile, the safest outcome is to stop before mixing vector spaces.
 
 When updating `libravdbd`, keep the same effective embedding profile unless you
 intend to rebuild the store. The effective profile includes the profile family,
 dimensions, normalization setting, and any metadata supplied by the model
-manifest or daemon defaults.
+manifest or vector service defaults.
 
 Legacy local setups can be more fragile than the current packaged profiles. For
-example, older `all-minilm-l6-v2` stores may fail to reopen after a daemon update
-if the daemon now computes different metadata for that local profile. This does
+example, older `all-minilm-l6-v2` stores may fail to reopen after a vector service update
+if the vector service now computes different metadata for that local profile. This does
 not imply that current packaged `nomic-embed-text-v1.5` or
 `bge-small-en-v1.5` stores are incompatible; it means the old local profile must
 be treated as a separate vector space unless a migration path is provided.
 
-If a daemon update reports that the database format or embedding profile is
+If a vector service update reports that the database format or embedding profile is
 incompatible:
 
 1. back up both the `.libravdb` file and its `.embedding.json` metadata file;
-2. either downgrade to the previous daemon that created the store, or move the
-   old store aside and let the new daemon initialize a fresh database;
+2. either downgrade to the previous vector service that created the store, or move the
+   old store aside and let the new vector service initialize a fresh database;
 3. rebuild/reingest memories with the new effective embedding profile.
 
 Do not delete the old store until the replacement has been verified.

package/docs/features.md

@@ -7,7 +7,7 @@ commands.
 ## Markdown Ingestion
 
 LibraVDB Memory can watch markdown roots and sync changed notes into vector
-memory without changing the sidecar RPC contract.
+memory without changing the vector service gRPC interface.
 
 The built-in source adapters are:
 
@@ -78,7 +78,7 @@ Each promoted bullet should include trailing metadata with the gating fields:
 - Preserve the recent tail buffer {score=0.82 recall=3 unique=2}
 ```
 
-Only bullets that satisfy the sidecar gates are inserted. The dream collection
+Only bullets that satisfy the vector service gates are inserted. The dream collection
 is isolated from normal `user:` and `global` retrieval by default, and dream
 phrasing in chat or search queries routes there automatically.
 
@@ -109,7 +109,7 @@ openclaw memory dream-promote --user-id <userId> --dream-file ~/DREAMS.md
 ```
 
 Dream diary files must live under the operator's home directory or the configured
-`OPENCLAW_STATE_DIR`. The manual command and watcher both use the same sidecar
+`OPENCLAW_STATE_DIR`. The manual command and watcher both use the same vector service
 promotion RPC, so admission gates and provenance metadata are identical.
 
 ## Memory CLI
@@ -119,14 +119,14 @@ CLI API.
 
 | Command | Purpose |
 |---|---|
-| `openclaw memory status` | Show sidecar health, counts, active thresholds, and model readiness. Use `--deep` to probe authored collection search health. |
-| `openclaw memory index --force` | Refresh delegated sidecar index state for OpenClaw memory CLI compatibility. |
+| `openclaw memory status` | Show vector service health, counts, active thresholds, and model readiness. Use `--deep` to probe authored collection search health. |
+| `openclaw memory index --force` | Refresh delegated vector service index state for OpenClaw memory CLI compatibility. |
 | `openclaw memory search "query"` | Search LibraVDB memory through the active memory runtime bridge. |
 | `openclaw memory export --user-id <userId>` | Stream stored memories as newline-delimited JSON for one durable namespace. |
 | `openclaw memory export --session-key <sessionKey>` | Export a namespace derived from a session key. |
 | `openclaw memory flush --user-id <userId>` | Delete one durable user namespace after confirmation. |
 | `openclaw memory flush --session-key <sessionKey>` | Delete a namespace derived from a session key after confirmation. |
-| `openclaw memory journal --limit 50` | Inspect bounded lifecycle hints recorded by the sidecar. |
+| `openclaw memory journal --limit 50` | Inspect bounded lifecycle hints recorded by the vector service. |
 | `openclaw memory dream-promote --user-id <userId> --dream-file <path>` | Promote vetted dream diary bullets from a file under the operator home directory or `OPENCLAW_STATE_DIR`. |
 
 Use `--yes` with `flush` only when you intentionally want to skip the

package/docs/install.md

@@ -2,11 +2,11 @@
 
 LibraVDB Memory is a connect-only OpenClaw plugin. Install the plugin as a
 normal package, install `libravdbd` separately, and point the plugin at the
-daemon endpoint when you need a non-default location.
+vector service endpoint when you need a non-default location.
 
 OpenClaw compatibility note:
 
-- the plugin is currently verified against OpenClaw `2026.4.23`
+- the plugin is currently verified against OpenClaw `2026.5.22`
 
 For deeper operational detail, use the full
 [installation reference](./installation.md).
@@ -26,7 +26,7 @@ This gives you:
 
 - a managed `libravdbd` service
 - a scanner-clean plugin install
-- a clean separation between plugin lifecycle and daemon lifecycle
+- a clean separation between plugin lifecycle and vector service lifecycle
 
 ## Plugin Install
 
@@ -53,7 +53,7 @@ Activate the plugin in `~/.openclaw/openclaw.json`:
 }
 ```
 
-If you run the daemon on a non-default endpoint, add a plugin config:
+If you run the vector service on a non-default endpoint, add a plugin config:
 
 ```json
 {
@@ -76,15 +76,15 @@ If you run the daemon on a non-default endpoint, add a plugin config:
 
 When `sidecarPath` is set to `"auto"`, the plugin resolves endpoints in this order on macOS/Linux:
 
-1. `LIBRAVDB_GRPC_ENDPOINT` if it is set to a valid daemon endpoint
+1. `LIBRAVDB_GRPC_ENDPOINT` if it is set to a valid vector service endpoint
 2. `$HOME/.libravdbd/run/libravdb.sock` if it exists
 3. `/opt/homebrew/var/libravdbd/run/libravdb.sock` if it exists
 4. `/usr/local/var/libravdbd/run/libravdb.sock` if it exists
 5. fallback to `$HOME/.libravdbd/run/libravdb.sock`
 
-## Sidecar Daemon Install
+## Vector Service Install
 
-The daemon owns the local database, embeddings, and gRPC endpoint.
+The vector service owns the local database, embeddings, and gRPC endpoint.
 
 Default endpoints:
 
@@ -100,7 +100,7 @@ Default data path:
 
 ### Homebrew
 
-Homebrew is the preferred daemon lifecycle on macOS:
+Homebrew is the preferred vector service lifecycle on macOS:
 
 ```bash
 brew tap xDarkicex/homebrew-openclaw-libravdb-memory
@@ -118,7 +118,7 @@ brew info libravdbd
 
 ### Manual Service Management
 
-If you are not using Homebrew, manage the daemon explicitly.
+If you are not using Homebrew, manage the vector service explicitly.
 
 Linux user service from the repo template:
 
@@ -146,7 +146,7 @@ Windows uses a loopback TCP endpoint by default:
 - `tcp:127.0.0.1:37421`
 
 This guide does not yet include a full Windows service-install walkthrough.
-For now, use the published Windows daemon asset from the GitHub releases page
+For now, use the published Windows vector service asset from the GitHub releases page
 and run it under your preferred process supervisor or a manual terminal session.
 
 Foreground manual run:
@@ -161,11 +161,11 @@ you wrap it in `brew services`, `systemd`, or `launchd`.
 ### Containers and Docker
 
 The npm plugin does not start `libravdbd`. In a container, either run a separate
-daemon sidecar or use a small entrypoint wrapper that starts the daemon before
+vector service or use a small entrypoint wrapper that starts the vector service before
 the OpenClaw gateway.
 
-Keep the daemon assets and database in a mounted volume and point both the
-daemon and plugin at paths inside the container:
+Keep the vector service assets and database in a mounted volume and point both the
+vector service and plugin at paths inside the container:
 
 ```sh
 export LIBRAVDB_GRPC_ENDPOINT=unix:/home/node/.openclaw/libravdbd/run/libravdb.sock
@@ -223,19 +223,19 @@ store directly. The context engine can still use LibraVDB for recall while
 - Update it with your normal OpenClaw plugin update flow.
 - Disable it by removing the slot assignment from `~/.openclaw/openclaw.json`.
 
-The plugin does not manage the daemon process. Treat plugin activation and
-daemon supervision as separate lifecycle decisions.
+The plugin does not manage the vector service process. Treat plugin activation and
+vector service supervision as separate lifecycle decisions.
 
 ### Daemon Lifecycle
 
 - Start it with `brew services`, `systemd --user`, `launchctl bootstrap`, or a manual `libravdbd serve`.
-- Restart it when you change daemon-level environment variables or replace the binary.
+- Restart it when you change vector service-level environment variables or replace the binary.
 - Stop it before uninstalling or deleting on-disk data.
 - Point the plugin at the correct endpoint with `sidecarPath` if you do not use the default location.
 
 ## Verification
 
-After the plugin and daemon are both in place, run:
+After the plugin and vector service are both in place, run:
 
 ```bash
 openclaw memory status
@@ -243,11 +243,11 @@ openclaw memory status
 
 Healthy output should show that:
 
-- the daemon answered the local health check
+- the vector service answered the local health check
 - the memory and context-engine slots are active
 - the plugin can read stored counts and runtime settings
 
-If OpenClaw cannot reach the daemon, verify the endpoint first:
+If OpenClaw cannot reach the vector service, verify the endpoint first:
 
 - macOS/Linux default: `unix:$HOME/.libravdbd/run/libravdb.sock`
 - Windows default: `tcp:127.0.0.1:37421`

package/docs/installation.md

@@ -10,23 +10,23 @@ This is the full installation reference for
 |---|---:|---|
 | Node.js | `22.0.0` | Enforced by `package.json` `engines.node`. |
 | OpenClaw | `2026.3.22` | Earliest supported host version for this plugin API shape. |
-| `libravdbd` | published daemon asset | Required for normal runtime. |
-| Go | `1.22` | Required only for local daemon development. |
+| `libravdbd` | published vector service asset | Required for normal runtime. |
+| Go | `1.22` | Required only for local vector service development. |
 | OS | macOS, Linux, Windows | Unix uses a local socket; Windows uses TCP loopback. |
-| Architecture | `arm64`, `x64` | Must match the daemon release asset. |
+| Architecture | `arm64`, `x64` | Must match the vector service release asset. |
 
 Resource sizing and benchmark data live in
 [Performance and tuning](./performance-and-tuning.md).
 
 OpenClaw compatibility note:
 
-- the plugin is currently verified against OpenClaw `2026.4.23`
+- the plugin is currently verified against OpenClaw `2026.5.22`
 
 ## Install Flow
 
 The published plugin package is connect-only. It installs TypeScript plugin code
 and docs; it does not compile Go code, download model assets, or supervise the
-daemon.
+vector service.
 
 Recommended macOS path:
 
@@ -55,7 +55,7 @@ tcp:127.0.0.1:37421
 ```
 
 This repository does not yet include a full Windows service-install walkthrough.
-Use the published Windows daemon asset under your preferred process supervisor
+Use the published Windows vector service asset under your preferred process supervisor
 or run `libravdbd serve` in a terminal for validation.
 
 ## Activation
@@ -77,7 +77,7 @@ The memory slot owns `openclaw memory ...` and memory-runtime calls. The
 context-engine slot enables automatic bootstrap, ingest, after-turn, and recall
 hooks during sessions.
 
-If the daemon uses a non-default endpoint, add `sidecarPath`:
+If the vector service uses a non-default endpoint, add `sidecarPath`:
 
 ```json
 {
@@ -122,7 +122,7 @@ $HOME/.libravdbd/data_nomic-embed-text-v1_5.libravdb
 
 ## Container Layout
 
-In Docker, keep the daemon, model assets, socket, logs, and database in the
+In Docker, keep the vector service, model assets, socket, logs, and database in the
 same mounted OpenClaw state volume. A typical container-side layout is:
 
 ```text
@@ -133,7 +133,7 @@ same mounted OpenClaw state volume. A typical container-side layout is:
 /home/node/.openclaw/libravdbd/models/nomic-embed-text-v1.5/embedding.json
 ```
 
-Start the daemon with explicit local ONNX paths before starting the gateway:
+Start the vector service with explicit local ONNX paths before starting the gateway:
 
 ```sh
 LIBRAVDB_GRPC_ENDPOINT=unix:/home/node/.openclaw/libravdbd/run/libravdb.sock \
@@ -171,7 +171,7 @@ Then configure the plugin with the same socket and asset paths:
 
 Do not let a container initialize a database with deterministic fallback
 embeddings and later switch the same file to ONNX embeddings. Move the fallback
-database aside first, then let the daemon create a fresh ONNX-backed store.
+database aside first, then let the vector service create a fresh ONNX-backed store.
 
 ## Verification
 
@@ -185,7 +185,7 @@ Expected output shape:
 
 ```text
 ┌────────────────────┬──────────────────────────────┐
-│ Sidecar            │ running                      │
+│ Daemon             │ running                      │
 │ Turns stored       │ 0                            │
 │ Memories stored    │ 0                            │
 │ Lifecycle hints    │ 0                            │
@@ -198,7 +198,7 @@ Expected output shape:
 
 Interpretation:
 
-- `Sidecar=running` means the daemon answered the health check.
+- `Daemon=running` means the vector service answered the health check.
 - `Gate threshold=0.35` confirms the default durable-memory gate.
 - `Abstractive model=not provisioned` is acceptable; compaction falls back to
   the extractive path.
@@ -216,7 +216,7 @@ Common causes:
 - `embeddingBackend` is set to `onnx-local` but `embeddingRuntimePath` or
   `embeddingModelPath` is missing from plugin config
 
-Check the daemon first:
+Check the vector service first:
 
 ```bash
 openclaw memory status
@@ -231,8 +231,8 @@ libravdbd serve
 
 ### Deterministic fallback embeddings
 
-If daemon logs mention deterministic fallback mode, the daemon did not find the
-configured ONNX runtime or model manifest. Stop the daemon, set
+If vector service logs mention deterministic fallback mode, the vector service did not find the
+configured ONNX runtime or model manifest. Stop the vector service, set
 `LIBRAVDB_ONNX_RUNTIME` and `LIBRAVDB_EMBEDDING_MODEL`, confirm the model
 directory contains `embedding.json`, then restart. If a database was created
 while fallback mode was active, move that `.libravdb` file and its adjacent
@@ -240,9 +240,9 @@ while fallback mode was active, move that `.libravdb` file and its adjacent
 
 ### Incompatible database or embedding profile
 
-If the daemon exits with `database format is incompatible` or `database
+If the vector service exits with `database format is incompatible` or `database
 embedding profile is incompatible`, it is refusing to open a store whose saved
-format or embedding fingerprint differs from the current daemon settings. This
+format or embedding fingerprint differs from the current vector service settings. This
 fail-closed behavior protects the store from mixing incompatible vector spaces.
 
 Before changing anything, back up both files for the affected store:
@@ -252,12 +252,12 @@ Before changing anything, back up both files for the affected store:
 
 Then choose one recovery path:
 
-- downgrade to the daemon version that created the store; or
-- move the old store aside, start the new daemon so it creates a fresh store,
+- downgrade to the vector service version that created the store; or
+- move the old store aside, start the new vector service so it creates a fresh store,
   and rebuild/reingest memories with the current embedding profile.
 
 This can affect legacy local profiles such as older `all-minilm-l6-v2` setups
-when daemon defaults or model metadata change across releases. It is not
+when vector service defaults or model metadata change across releases. It is not
 expected for stores that stay on the current packaged profiles and assets. See
 [Embedding Profiles](./embedding-profiles.md#store-compatibility-and-upgrades)
 for more detail.
@@ -276,6 +276,6 @@ automatic session ingest and recall may not run.
 
 ### Lifecycle journal looks empty
 
-The sidecar journal only records advisory lifecycle hints such as `before_reset`
+The vector service journal only records advisory lifecycle hints such as `before_reset`
 and `session_end`. It is bounded by `lifecycleJournalMaxEntries`, default `500`,
 and is not part of normal memory recall.

package/docs/mTLS_configuration.md

@@ -6,7 +6,7 @@ The plugin supports mutual TLS (mTLS) for gRPC connections to the Vector Service
 
 The Vector Service operator enables mTLS by configuring a client CA on the service side. When this is enabled, the Vector Service requires every connecting client to present a certificate signed by that CA. If the plugin is configured to use TLS but does not present a client certificate, the TLS handshake will fail and the connection will be rejected.
 
-The plugin cannot detect whether the daemon requires mTLS — it must be configured explicitly. If connections fail with a "client did not provide a certificate" error, the plugin likely needs a client certificate configured.
+The plugin cannot detect whether the vector service requires mTLS — it must be configured explicitly. If connections fail with a "client did not provide a certificate" error, the plugin likely needs a client certificate configured.
 
 ## Configuration fields
 
@@ -65,7 +65,7 @@ openssl x509 -req -in client.csr -CA ca.crt -CAkey ca.key \
   -CAcreateserial -out client.crt -days 365
 ```
 
-Replace `ca.crt` and `ca.key` with the CA certificate and key that the daemon operator provided.
+Replace `ca.crt` and `ca.key` with the CA certificate and key that the vector service operator provided.
 
 ## Error reference
 

package/docs/models.md

@@ -8,7 +8,7 @@ available offline after assets are installed.
 
 `assemble` runs before each response build. An embedding request that crosses a
 process and HTTP server boundary adds avoidable tail latency. Local ONNX
-inference inside the sidecar keeps retrieval close to the database and avoids a
+inference inside the vector service keeps retrieval close to the database and avoids a
 runtime dependency on a separate model server.
 
 ONNX assets can be provisioned once and reused without network access. Given
@@ -23,7 +23,7 @@ latency and offline operation are part of the product contract.
 The default profile is `nomic-embed-text-v1.5`. Nomic was chosen as the default
 because its Matryoshka-trained embeddings deliver significantly higher retrieval
 accuracy than MiniLM, with principled dimensionality tiering (`64d → 256d →
-768d`) that lets the daemon trade memory for precision without re-embedding.
+768d`) that lets the vector service trade memory for precision without re-embedding.
 
 `bge-small-en-v1.5` is the fallback profile. It has a smaller disk and memory
 footprint than Nomic and is automatically selected when the primary model's
@@ -35,7 +35,7 @@ For exact profile metadata, read [Embedding profiles](./embedding-profiles.md).
 ## Summarization
 
 Compaction can run without an abstractive summarizer. When the optional T5-small
-assets are not provisioned, the daemon degrades to the extractive path.
+assets are not provisioned, the vector service degrades to the extractive path.
 
 T5-small is the optional local abstractive summarizer because it is small enough
 for CPU-local operation while still useful for session-cluster summaries. Larger

package/docs/performance-and-tuning.md

@@ -12,7 +12,7 @@ The numbers below are local measurements from this repository as of
 
 Measured local asset sizes:
 
-- daemon binary: `7.7M`
+- vector service binary: `7.7M`
 - bundled Nomic model directory: `523M`
 - bundled MiniLM fallback model directory: `87M`
 - optional T5 summarizer directory: `371M`
@@ -34,7 +34,7 @@ structure, and index state are stored as well.
 
 ### Memory
 
-Measured on Apple M2 by starting the daemon and reading RSS after startup:
+Measured on Apple M2 by starting the vector service and reading RSS after startup:
 
 - Nomic embedding path loaded without optional T5 summarizer: about `266 MB`
 - Nomic plus local ONNX T5 summarizer loaded: about `503 MB`
@@ -89,7 +89,7 @@ are advanced controls, not required install settings.
 | `compactionThresholdFraction` | Dynamic trigger ratio when `compactThreshold` is unset, default `0.8`. |
 | `compactSessionTokenBudget` | Auto-compaction budget since the last compaction, default `2000`; set `0` to disable. |
 | `rpcTimeoutMs` | Sidecar RPC timeout, default `30000`. |
-| `maxRetries` | Retry budget for sidecar RPC calls. |
+| `maxRetries` | Retry budget for vector service RPC calls. |
 | `logLevel` | Plugin log level. |
 
 Model-related fields live in [Embedding profiles](./embedding-profiles.md) and
@@ -111,7 +111,7 @@ Run it with:
 LONGMEMEVAL_DATA_FILE=/path/to/longmemeval_oracle.json pnpm run benchmark:longmemeval
 ```
 
-If you already have a daemon running and do not want the benchmark to spawn
+If you already have a vector service running and do not want the benchmark to spawn
 another one, set:
 
 ```bash
@@ -127,7 +127,7 @@ Optional controls:
 - `LONGMEMEVAL_OUT_FILE` writes JSONL records for analysis
 
 The harness writes JSONL incrementally, so partial results survive if a
-transient daemon failure interrupts a long run. If the local test daemon drops
+transient vector service failure interrupts a long run. If the local test vector service drops
 mid-run, the benchmark restarts it and retries the current instance once before
 recording an error result.
 

package/docs/problem.md

@@ -9,7 +9,7 @@ The default `memory-lancedb` style plugin is still a good fit when you want:
 - a simple top-k semantic lookup over durable notes
 - a low-complexity setup
 - a heuristic capture model where the agent decides what to save
-- no additional sidecar process
+- no additional vector service process
 
 For short sessions and light persistent memory, that is often the right answer.
 

package/docs/security.md

@@ -18,7 +18,7 @@ The system is designed so a failure in one layer does not automatically collapse
 
 The published plugin package intentionally avoids install-time process execution.
 That is a deliberate trust and distribution choice: the OpenClaw plugin is a
-thin client, and the local `libravdbd` daemon is a separate operator-managed
+thin client, and the local `libravdbd` vector service is a separate operator-managed
 component.
 
 Current implementation facts:
@@ -28,9 +28,9 @@ Current implementation facts:
 - the published plugin source contains no direct `child_process` usage
 - the plugin connects only to a configured local endpoint such as
   `unix:/Users/<you>/.libravdbd/run/libravdb.sock` or `tcp:127.0.0.1:37421`
-- daemon installation and lifecycle are explicit user or operator actions
+- vector service installation and lifecycle are explicit user or operator actions
 
-The daemon distribution surface should be evaluated separately from the plugin
+The vector service distribution surface should be evaluated separately from the plugin
 package. If you install `libravdbd` from release assets or another package
 channel, validate that channel directly.
 
@@ -76,7 +76,7 @@ It reduces risk; it does not create a trusted execution environment.
 
 ## Deletion and Data Protection
 
-The daemon exposes deletion and flush primitives. That matters operationally for:
+The vector service exposes deletion and flush primitives. That matters operationally for:
 
 - user-requested memory removal
 - namespace cleanup

package/docs/uninstall.md

@@ -1,10 +1,10 @@
 # Uninstall Guide
 
 This guide covers safe removal of the OpenClaw / OpenClaw.ai plugin and the
-separately managed `libravdbd` daemon.
+separately managed `libravdbd` vector service.
 
 If you only want to disable the memory replacement temporarily, remove the
-plugin slot assignment first and leave the daemon plus data in place.
+plugin slot assignment first and leave the vector service plus data in place.
 
 ## 1. Disable the Plugin
 
@@ -29,7 +29,7 @@ your standard OpenClaw plugin removal flow for
 
 ## 2. Stop the Daemon
 
-Stop the sidecar before deleting binaries or stored data.
+Stop the vector service before deleting binaries or stored data.
 
 Homebrew:
 
@@ -69,7 +69,7 @@ brew untap xDarkicex/homebrew-openclaw-libravdb-memory
 
 ### Manual Daemon Install
 
-Delete the service file or launch agent you installed, along with the daemon
+Delete the service file or launch agent you installed, along with the vector service
 binary you copied into place.
 
 Common locations:
@@ -96,5 +96,5 @@ delete during uninstall.
 ## 5. Post-Uninstall Check
 
 After cleanup, `openclaw memory status` should no longer show this plugin as the
-active memory provider, and the daemon endpoint should no longer be reachable
+active memory provider, and the vector service endpoint should no longer be reachable
 unless you intentionally kept it running for another workflow.

package/openclaw.plugin.json

@@ -2,7 +2,7 @@
   "id": "libravdb-memory",
   "name": "LibraVDB Memory",
   "description": "Persistent vector memory with three-tier hybrid scoring",
-  "version": "1.6.22",
+  "version": "1.6.25",
   "kind": [
     "memory",
     "context-engine"

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "@xdarkicex/openclaw-memory-libravdb",
-  "version": "1.6.22",
+  "version": "1.6.25",
   "type": "module",
   "main": "./dist/index.js",
   "types": "./dist/index.d.ts",