@xdarkicex/openclaw-memory-libravdb 1.6.23 → 1.6.27

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,8 @@ 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.
+- GGUF is the recommended default and preferred backend for local embedding. It delivers Matryoshka-trained `nomic-embed-text-v1.5` embeddings with no ONNX Runtime dependency and hardware-native acceleration on Apple Silicon (Metal), NVIDIA (CUDA), and CPU.
+- `bundled` uses the ONNX build of `nomic-embed-text-v1.5` and is the full-featured fallback when GGUF is unavailable.
 - 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,39 +33,40 @@ 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` (default), `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.
 
 Recommended usage:
 
-- `bundled` for the shipped default path, which uses `nomic-embed-text-v1.5`.
+- `gguf` for the recommended local embedding path, using `nomic-embed-text-v1.5` with hardware-native acceleration and no ONNX Runtime dependency.
+- `bundled` for the ONNX build of `nomic-embed-text-v1.5` when GGUF is unavailable.
 - `onnx-local` plus `embeddingProfile` when a power user wants a known model family with local assets.
 - treat remote/Ollama providers as future separate backend types, not as overloads of `custom-local`.

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,18 +231,26 @@ 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
-`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
-`.embedding.json` aside before starting with ONNX assets.
+If the vector service falls back to deterministic embeddings, it could not locate
+the configured ONNX runtime or model assets. The service will still run but all
+embedding operations will fail until resolved.
+
+To resolve: stop the vector service, then set `LIBRAVDB_ONNX_RUNTIME` to the
+full path of the ONNX runtime library (e.g. `libonnxruntime.so` or
+`libonnxruntime.dylib`) and `LIBRAVDB_EMBEDDING_MODEL` to the model directory
+containing `embedding.json`. Verify the model directory also contains the
+corresponding `.onnx` model file and `tokenizer.json`.
+
+If a database was created while the service was in fallback mode, move that
+`.libravdb` file and its adjacent `.embedding.json` aside before restarting —
+a store initialized with deterministic embeddings is incompatible with ONNX-backed
+operation.
 
 ### 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 +260,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 +284,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