@xdarkicex/openclaw-memory-libravdb 1.3.5 → 1.3.7

package/README.md

@@ -6,7 +6,7 @@
 openclaw plugins install @xdarkicex/openclaw-memory-libravdb
 ```
 
-The installer builds the Go sidecar, provisions the bundled embedding/runtime assets, optionally provisions the T5 summarizer, and fails fast if the sidecar cannot pass its startup health check.
+The published plugin is connect-only. It does not spawn a local binary during install or at runtime. For durable memory, run a local `libravdbd` daemon separately and point the plugin at its endpoint.
 
 Minimum host version:
 
@@ -14,11 +14,26 @@ Minimum host version:
 
 Security note:
 
-- `scripts/setup.ts` verifies SHA-256 checksums for downloaded sidecar/runtime/model assets
-- the sidecar installer downloads prebuilt sidecar release assets only from `github.com/xDarkicex/openclaw-memory-libravdb` releases
+- the published plugin package contains no `postinstall`, no `openclaw.setup`, and no direct `child_process` usage
+- the plugin only connects to a local `libravdbd` endpoint such as `unix:/Users/<you>/.clawdb/run/libravdb.sock` or `tcp:127.0.0.1:37421`
 - after install, the plugin makes no required network calls for embedding or extractive compaction
 - the only optional runtime network path is an explicitly configured remote summarizer endpoint such as `ollama-local`
 
+## Daemon
+
+Install and start `libravdbd` separately, then point the plugin at the running daemon if you do not want the default endpoint.
+
+Default endpoints:
+
+- macOS/Linux: `unix:$HOME/.clawdb/run/libravdb.sock`
+- Windows: `tcp:127.0.0.1:37421`
+
+Phase 2 packaging assets now live under [`packaging/`](./packaging):
+
+- `packaging/systemd/libravdbd.service` for Linux user services
+- `packaging/launchd/com.xdarkicex.libravdbd.plist` for macOS LaunchAgents
+- `packaging/homebrew/libravdbd.rb.tmpl` as the source template for a generated Homebrew formula
+
 ## Activate
 
 Add this to `~/.openclaw/openclaw.json`:
@@ -28,6 +43,11 @@ Add this to `~/.openclaw/openclaw.json`:
   "plugins": {
     "slots": {
       "memory": "libravdb-memory"
+    },
+    "configs": {
+      "libravdb-memory": {
+        "sidecarPath": "unix:/Users/<you>/.clawdb/run/libravdb.sock"
+      }
     }
   }
 }
@@ -43,4 +63,4 @@ Run:
 openclaw memory status
 ```
 
-Expected output includes a readable status table showing the sidecar is running, stored turn/memory counts, the active ingestion gate threshold, and whether the abstractive summarizer is provisioned.
+Expected output includes a readable status table showing the daemon is reachable, stored turn/memory counts, the active ingestion gate threshold, and whether the abstractive summarizer is provisioned.

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

@@ -1,4 +1,4 @@
-# ADR-004: Sidecar Over Native TypeScript
+# ADR-004: Daemon Over Native TypeScript
 
 ## Context
 
@@ -6,7 +6,7 @@ The plugin requires local vector storage, ONNX inference, transport isolation, a
 
 ## Decision
 
-Implement the memory engine as a Go sidecar with a narrow JSON-RPC transport boundary.
+Implement the memory engine as a Go daemon with a narrow JSON-RPC transport boundary.
 
 ## Alternatives Considered
 

package/docs/architecture.md

@@ -11,8 +11,8 @@ flowchart LR
   Host["OpenClaw host process\n(TypeScript plugin shell)"]
   CE["Context engine factory\nbootstrap / ingest / assemble / compact"]
   MPS["memoryPromptSection\nuser+global recall"]
-  Runtime["Plugin runtime\nlazy sidecar startup + RPC client"]
-  Sidecar["Go sidecar process"]
+  Runtime["Plugin runtime\nlazy daemon connect + RPC client"]
+  Sidecar["Go daemon process"]
   RPC["JSON-RPC over newline-delimited frames\nUnix socket or TCP loopback on Windows"]
   Store["LibraVDB store on disk"]
   Session["session:<sessionId>"]
@@ -47,7 +47,7 @@ Implementation anchors:
 
 - plugin entry: [`src/index.ts`](../src/index.ts)
 - lazy runtime startup: [`src/plugin-runtime.ts`](../src/plugin-runtime.ts)
-- sidecar supervision and endpoint discovery: [`src/sidecar.ts`](../src/sidecar.ts)
+- daemon supervision and endpoint discovery: [`src/sidecar.ts`](../src/sidecar.ts)
 - transport listener: [`sidecar/server/transport.go`](../sidecar/server/transport.go)
 - RPC method table: [`sidecar/server/rpc.go`](../sidecar/server/rpc.go)
 - store: [`sidecar/store/libravdb.go`](../sidecar/store/libravdb.go)
@@ -60,8 +60,8 @@ Implemented in [`src/context-engine.ts`](../src/context-engine.ts).
 
 For every non-heartbeat message:
 
-1. The host gets an RPC client from the plugin runtime. This lazily starts the
-   sidecar if it is not already running.
+1. The host gets an RPC client from the plugin runtime. This lazily connects to
+   the configured daemon endpoint when the plugin is first used.
 2. The message is written to `session:<sessionId>` with `type: "turn"`.
 3. If `message.role === "user"`, the same text is written to `turns:<userId>`.
 4. The host calls `gating_scalar` with `{ userId, text }`.
@@ -120,7 +120,7 @@ and [`sidecar/compact/summarize.go`](../sidecar/compact/summarize.go).
 When compaction is triggered:
 
 1. the host calls `compact_session` with `{ sessionId, force, targetSize }`
-2. the sidecar loads eligible non-summary turns from `session:<sessionId>`
+2. the daemon loads eligible non-summary turns from `session:<sessionId>`
 3. turns are sorted by `(ts, id)` and partitioned into deterministic
    chronological clusters
 4. each cluster is routed to:
@@ -144,8 +144,8 @@ from the original spec phrasing.
 
 | Failure | Current behavior | User impact |
 |---|---|---|
-| Sidecar unavailable on first RPC use | `getRpc()` rejects when lazy startup or health check fails | That hook fails or falls back, but plugin registration itself does not crash eagerly |
-| Sidecar connection closes mid-session | `SidecarSupervisor` retries with exponential backoff until retry budget is exhausted, then enters degraded mode | Memory becomes unavailable until restart succeeds |
+| Daemon unavailable on first RPC use | `getRpc()` rejects when first connect or health check fails | That hook fails or falls back, but plugin registration itself does not crash eagerly |
+| Daemon connection closes mid-session | `SidecarSupervisor` retries with exponential backoff until retry budget is exhausted, then enters degraded mode | Memory becomes unavailable until the daemon is reachable again |
 | `memoryPromptSection` RPC failure | individual searches are caught and replaced with empty result sets | Prompt section becomes empty rather than crashing the run |
 | `assemble` RPC failure | returns original messages, original token count, and empty `systemPromptAddition` | That turn gets no recall augmentation |
 | `ingest` gating or durable insert failure | session write already happened; durable promotion is skipped | Session memory survives, durable memory may miss that turn |
@@ -156,7 +156,7 @@ from the original spec phrasing.
 Relevant code:
 
 - retry/degraded behavior: [`src/sidecar.ts`](../src/sidecar.ts)
-- lazy startup and health gate: [`src/plugin-runtime.ts`](../src/plugin-runtime.ts)
+- lazy daemon connect and health gate: [`src/plugin-runtime.ts`](../src/plugin-runtime.ts)
 - compaction routing and insert/delete ordering:
   [`sidecar/compact/summarize.go`](../sidecar/compact/summarize.go)
 
@@ -166,10 +166,10 @@ The gating decision spans both layers:
 
 1. `ingest` writes the user turn to `turns:<userId>`
 2. the host calls `gating_scalar`
-3. the Go sidecar performs exactly two searches:
+3. the Go daemon performs exactly two searches:
    - `SearchText("turns:<userId>", text, 10, nil)`
    - `SearchText("user:<userId>", text, 5, nil)`
-4. the sidecar computes `GatingSignals` with [`compact.ComputeGating`](../sidecar/compact/gate.go)
+4. the daemon computes `GatingSignals` with [`compact.ComputeGating`](../sidecar/compact/gate.go)
 5. the host compares `g` to `ingestionGateThreshold`
 6. on pass, the host writes the turn into `user:<userId>` with all gating
    metadata fields

package/docs/contributing.md

@@ -3,7 +3,7 @@
 ## Prerequisites
 
 - Node.js `>= 22`
-- Go `>= 1.22` for development and local fallback builds
+- Go `>= 1.22` for daemon development and release builds
 - `pnpm`
 - OpenClaw CLI for end-to-end plugin testing
 
@@ -21,7 +21,7 @@ Integration tests:
 npm run test:integration
 ```
 
-Go sidecar tests:
+Go daemon tests:
 
 ```bash
 cd sidecar
@@ -29,13 +29,13 @@ env GOCACHE=/tmp/openclaw-memory-libravdb-gocache go test ./...
 env GOCACHE=/tmp/openclaw-memory-libravdb-gocache go test -race ./...
 ```
 
-## Local Sidecar Build
+## Local Daemon Build
 
 ```bash
-bash scripts/build-sidecar.sh
+bash scripts/build-daemon.sh
 ```
 
-This creates `.sidecar-bin/libravdb-sidecar` and copies locally available bundled assets into `.sidecar-bin/`.
+This creates `.daemon-bin/libravdbd` and copies locally available bundled assets into `.daemon-bin/`.
 
 ## Gating Invariants
 

package/docs/implementation.md

@@ -70,29 +70,37 @@ Important boundary:
 - prompt-budget fitting uses a separate host-side chars-per-token heuristic in
   [`src/tokens.ts`](../src/tokens.ts)
 
-## Why the Sidecar Emits Its Endpoint on stdout
+## Why the Daemon Uses a Stable Endpoint
 
 Implemented in [`sidecar/main.go`](../sidecar/main.go) and
 [`src/sidecar.ts`](../src/sidecar.ts).
 
-The sidecar prints its runtime endpoint to stdout on startup instead of binding
-to a fixed path known in advance.
+The daemon binds to a stable, predictable local endpoint instead of advertising
+a per-process endpoint on stdout.
 
 Why:
 
-- fixed Unix socket paths create collision risk across concurrent runs
-- temporary per-process endpoints avoid stale socket cleanup problems
-- Windows already requires a dynamic TCP fallback
+- the published plugin no longer spawns the process itself
+- connect-only plugin startup needs a known endpoint contract
+- user services such as `systemd --user`, launchd, and Homebrew service support
+  work better with a stable socket or loopback address
+- Windows still uses a fixed loopback TCP endpoint because Unix sockets are not
+  the common user-service path there
 
-The host watches stdout, captures the endpoint, and then establishes the
-JSON-RPC transport.
+Current defaults:
+
+- macOS/Linux: `unix:$HOME/.clawdb/run/libravdb.sock`
+- Windows: `tcp:127.0.0.1:37421`
+
+The plugin resolves that configured endpoint and then establishes the JSON-RPC
+transport.
 
 ## Why Degraded Mode Continues the Session
 
 Implemented in [`src/sidecar.ts`](../src/sidecar.ts) and
 [`src/context-engine.ts`](../src/context-engine.ts).
 
-If the sidecar fails repeatedly, the plugin enters degraded mode instead of
+If the daemon connection fails repeatedly, the plugin enters degraded mode instead of
 failing the chat session.
 
 Why:

package/docs/installation.md

@@ -8,13 +8,13 @@ This document is the full installation reference for `@xdarkicex/openclaw-memory
 |---|---|---|---|
 | Node.js | `22.0.0` | Latest LTS | Enforced in [`package.json`](../package.json) `engines.node` |
 | OpenClaw | `2026.3.22` | Current stable | Pinned by [`package.json`](../package.json) `peerDependencies.openclaw`; this is the earliest local tag confirmed to expose `definePluginEntry`, `registerContextEngine`, `registerMemoryPromptSection`, and the plugin API shape this repo uses |
-| Go | `1.22` | Latest stable | Dev/fallback build only; not required when prebuilt release assets exist |
+| Go | `1.22` | Latest stable | Required only for local daemon development, not for normal plugin install |
 | Disk | about `1 GB` free for default Nomic install | `2 GB+` if provisioning optional T5 and leaving room for DB growth | See Resource Requirements below |
 | RAM | about `512 MB` for embed-only runtime | `1 GB+` if optional T5 summarizer is provisioned | Based on local RSS measurements below |
-| OS | macOS, Linux, Windows | Current stable releases | Windows uses TCP loopback instead of Unix sockets |
-| Architecture | `arm64`, `x64` | Match published release assets | Current release matrix builds five sidecar targets |
+| OS | macOS, Linux, Windows | Current stable releases | Unix uses a local socket; Windows uses TCP loopback |
+| Architecture | `arm64`, `x64` | Match published daemon release assets | Current release matrix builds five daemon targets |
 
-The published install path is prebuilt-first. End users should not normally need Go.
+The published plugin install path is scanner-clean and connect-only. End users should not need Go to install the OpenClaw plugin itself.
 
 ## Resource Requirements
 
@@ -25,7 +25,7 @@ build on `2026-03-29` or explicitly labeled as estimates.
 
 Measured locally from this checkout:
 
-- sidecar binary: `7.7M`
+- daemon binary: `7.7M`
 - bundled Nomic model directory: `523M`
 - bundled MiniLM fallback model directory: `87M`
 - optional T5 summarizer directory: `371M`
@@ -55,7 +55,7 @@ as well.
 
 ### Memory
 
-Measured locally on Apple M2, `2026-03-29`, by starting the sidecar and reading
+Measured locally on Apple M2, `2026-03-29`, by starting the daemon and reading
 RSS after startup:
 
 - idle RSS with Nomic embedding path loaded and no optional T5 summarizer:
@@ -121,39 +121,78 @@ extractive compaction. The only optional runtime network path is:
 openclaw plugins install @xdarkicex/openclaw-memory-libravdb
 ```
 
-Expected successful install shape on a published release:
+The plugin package installs as normal OpenClaw source without daemon bootstrap hooks.
 
-```text
-[openclaw-memory-libravdb] Sidecar installed (prebuilt clawdb-sidecar-<platform>)
-[openclaw-memory-libravdb] Provisioning embedding model...
-[openclaw-memory-libravdb] Provisioning ONNX runtime...
-[openclaw-memory-libravdb] Provisioning summarizer model... (optional)
-[openclaw-memory-libravdb] Verifying sidecar health...
-[openclaw-memory-libravdb] Setup complete.
-Installed plugin: libravdb-memory
+## Daemon Install
+
+Install and start `libravdbd` separately for the same user account that runs OpenClaw. The daemon owns the local DB engine and listens on a local endpoint.
+
+Default endpoints:
+
+- macOS/Linux: `unix:$HOME/.clawdb/run/libravdb.sock`
+- Windows: `tcp:127.0.0.1:37421`
+
+If you run the daemon on a different endpoint, set `plugins.configs.libravdb-memory.sidecarPath` in `~/.openclaw/openclaw.json`.
+
+### Linux
+
+Recommended layout:
+
+```bash
+mkdir -p ~/.local/bin ~/.config/systemd/user
+curl -L -o ~/.local/bin/libravdbd https://github.com/xDarkicex/openclaw-memory-libravdb/releases/download/vX.Y.Z/libravdbd-linux-amd64
+chmod +x ~/.local/bin/libravdbd
+cp packaging/systemd/libravdbd.service ~/.config/systemd/user/libravdbd.service
+systemctl --user enable --now libravdbd.service
 ```
 
-If the host also activates the plugin into the exclusive memory slot during the
-same flow, output should additionally include a line like:
+Then verify:
 
-```text
-Exclusive slot "memory" switched from "memory-core" to "libravdb-memory".
+```bash
+systemctl --user status libravdbd.service
+openclaw memory status
 ```
 
-That slot-takeover line is the proof that OpenClaw is no longer using the stock
-memory provider.
+### Homebrew / macOS
 
-Development fallback shape when a prebuilt sidecar asset is not available:
+The release workflow now generates a publish-ready `libravdbd.rb` formula asset from [`packaging/homebrew/libravdbd.rb.tmpl`](../packaging/homebrew/libravdbd.rb.tmpl). It is designed for GitHub release assets named:
 
-```text
-[openclaw-memory-libravdb] Prebuilt binary unavailable. Attempting local go build...
-[openclaw-memory-libravdb] This requires Go >= 1.22: https://go.dev/dl/
-[openclaw-memory-libravdb] Sidecar installed (local build)
-...
+- `libravdbd-darwin-arm64`
+- `libravdbd-darwin-amd64`
+- `libravdbd-linux-amd64`
+- `libravdbd-linux-arm64`
+
+If your GitHub Actions configuration includes:
+
+- repository variable `HOMEBREW_TAP_REPO`, for example `xDarkicex/homebrew-openclaw-libravdb-memory`
+- repository secret `HOMEBREW_TAP_TOKEN`
+
+then tagged releases also push the generated formula into `Formula/libravdbd.rb` in that tap repository automatically.
+
+Example:
+
+```json
+{
+  "plugins": {
+    "slots": {
+      "memory": "libravdb-memory"
+    },
+    "configs": {
+      "libravdb-memory": {
+        "sidecarPath": "unix:/Users/<you>/.clawdb/run/libravdb.sock"
+      }
+    }
+  }
+}
 ```
 
-Published users should rarely see the fallback path. If they do, the plugin
-version likely has not published sidecar release assets for that platform yet.
+## Expected Install Shape
+
+Expected successful plugin install shape:
+
+```text
+Installed plugin: libravdb-memory
+```
 
 ## Activation
 
@@ -205,7 +244,7 @@ Expected output shape:
 
 Interpretation:
 
-- `Sidecar=running` means the Go sidecar booted and answered JSON-RPC `health`.
+- `Sidecar=running` means the local `libravdbd` daemon answered JSON-RPC `health`.
 - `Gate threshold=0.35` confirms the default gating scalar boundary is active.
 - `Abstractive model=not provisioned` is acceptable. The system degrades to extractive compaction.
 
@@ -216,26 +255,43 @@ For contributors working from a clone:
 ```bash
 pnpm check
 cd sidecar && env GOCACHE=/tmp/openclaw-memory-libravdb-gocache go test -race ./... && cd ..
-node scripts/setup.ts
+bash scripts/build-daemon.sh
 ```
 
-Optional direct dev build:
+This produces a local daemon binary in `.daemon-bin/libravdbd` (or `.exe` on Windows) and copies any locally available model/runtime assets there for testing.
+
+## User-Service Templates
+
+Phase 2 packaging assets are included in-repo:
+
+- Linux user service: [`packaging/systemd/libravdbd.service`](../packaging/systemd/libravdbd.service)
+- macOS LaunchAgent: [`packaging/launchd/com.xdarkicex.libravdbd.plist`](../packaging/launchd/com.xdarkicex.libravdbd.plist)
+
+Linux example:
 
 ```bash
-bash scripts/build-sidecar.sh
+mkdir -p ~/.config/systemd/user
+cp packaging/systemd/libravdbd.service ~/.config/systemd/user/libravdbd.service
+systemctl --user enable --now libravdbd.service
 ```
 
-This produces a local sidecar in `.sidecar-bin/` and copies any locally available model/runtime assets there for testing.
+macOS example:
+
+1. Copy `packaging/launchd/com.xdarkicex.libravdbd.plist`
+2. Replace `__LIBRAVDBD_PATH__` and `__HOME__`
+3. Save it to `~/Library/LaunchAgents/com.xdarkicex.libravdbd.plist`
+4. Load it with `launchctl load ~/Library/LaunchAgents/com.xdarkicex.libravdbd.plist`
 
 ## Troubleshooting
 
-### Sidecar fails to start
+### Daemon unavailable
 
 Common causes:
 
 - ONNX Runtime library missing or unpacked in the wrong place
 - downloaded model file hash mismatch
-- local Go fallback unavailable and no prebuilt asset for the requested version
+- `libravdbd` not started for the current user
+- plugin pointed at the wrong endpoint
 
 Check:
 
@@ -243,21 +299,19 @@ Check:
 openclaw memory status
 ```
 
-If the sidecar is down, rerun:
+If the daemon is down, start it and verify the configured endpoint:
 
 ```bash
-node scripts/setup.ts
+libravdbd serve
 ```
 
-### Model download fails
-
-The setup script verifies hashes for required assets. A failed or partial download is deleted and retried on the next run. This is intentional. A model file that exists but fails hash verification is treated as corrupt.
+On macOS/Linux, the default endpoint is `unix:$HOME/.clawdb/run/libravdb.sock`. On Windows, the default endpoint is `tcp:127.0.0.1:37421`.
 
 ### Hash mismatch
 
 Hash mismatch means one of:
 
-- the release asset is corrupt
+- the daemon asset is corrupt
 - the local cache is stale
 - the expected checksum is wrong
 
@@ -265,8 +319,10 @@ Do not bypass this. Delete the asset and rerun setup, or republish the release w
 
 ### Windows behavior
 
-On Windows the sidecar advertises a loopback TCP endpoint instead of a Unix socket. This is expected. The plugin’s transport layer already handles the fallback.
+On Windows the daemon uses a loopback TCP endpoint instead of a Unix socket. This is expected. The plugin’s transport layer already handles the fallback.
 
-### Local fallback path
+### Published daemon requirement
 
-If the installer logs that it is attempting a local `go build`, the prebuilt release asset was not available for the plugin version being installed. For published tags this should be unusual; for branch or unreleased work it is expected.
+The daemon must come from a published `libravdbd` binary for the current platform.
+If that download or checksum verification fails, setup stops instead of falling
+back to a local `go build`.

package/docs/mathematics.md

@@ -444,7 +444,7 @@ r(d)=\exp\left(-\lambda_r\cdot \Delta t(d)\right)
 $$
 
 $$
-f(d)=\frac{\log(1+\operatorname{acc}(d))}{\log\left(1+\max_{d'\in\mathcal{V}}\operatorname{acc}(d')\right)}
+f(d)=\frac{\log(1+\mathrm{acc}(d))}{\log\left(1+\max_{d'\in\mathcal{V}}\mathrm{acc}(d')\right)}
 $$
 
 $$
@@ -459,19 +459,19 @@ and authored authority without baking those concerns into the raw cosine term.
 Pass 1 computes cosine similarity:
 
 $$
-\operatorname{sim}(q,d)=\varphi(q)^\top \varphi(d)
+\mathrm{sim}(q,d)=\varphi(q)^\top \varphi(d)
 $$
 
 and selects the coarse candidate set:
 
 $$
-\mathcal{C}_1(q)=\operatorname{top\text{-}k_1}_{d\in\mathcal{V}}\ \operatorname{sim}(q,d)
+\mathcal{C}_1(q)=\mathrm{TopK}_{d\in\mathcal{V}}\!\left(k_1,\mathrm{sim}(q,d)\right)
 $$
 
 with a hard similarity floor:
 
 $$
-\mathcal{C}_1(q)=\{d\in\mathcal{C}_1(q)\mid \operatorname{sim}(q,d)\ge \theta_1\}
+\mathcal{C}_1(q)=\{d\in\mathcal{C}_1(q)\mid \mathrm{sim}(q,d)\ge \theta_1\}
 $$
 
 The purpose of this pass is breadth with cheap semantic recall. Documents below
@@ -483,13 +483,13 @@ first pass must not admit semantically orthogonal noise into second-pass work.
 Let the query keyword extractor return:
 
 $$
-K = \operatorname{KeyExt}(q)
+K = \mathrm{KeyExt}(q)
 $$
 
 and define normalized keyword coverage:
 
 $$
-M_{norm}(K,d)=\frac{|K\cap \operatorname{terms}(d)|}{|K|}\in[0,1]
+M_{norm}(K,d)=\frac{|K\cap \mathrm{terms}(d)|}{|K|}\in[0,1]
 $$
 
 The proposed normalized second-pass score is:
@@ -497,7 +497,7 @@ The proposed normalized second-pass score is:
 $$
 S_{final}(d)=
 \frac{
-\omega(d)\cdot\max(\operatorname{sim}(q,d), 0)\cdot\left(1+\kappa\cdot M_{norm}(K,d)\right)
+\omega(d)\cdot\max(\mathrm{sim}(q,d), 0)\cdot\left(1+\kappa\cdot M_{norm}(K,d)\right)
 }{
 1+\kappa
 }
@@ -515,7 +515,7 @@ truncating the result.
 The second-pass candidate set is:
 
 $$
-\mathcal{C}_2(q)=\operatorname{top\text{-}k_2}_{d\in\mathcal{C}_1(q)}\ S_{final}(d)
+\mathcal{C}_2(q)=\mathrm{TopK}_{d\in\mathcal{C}_1(q)}\!\left(k_2,S_{final}(d)\right)
 $$
 
 with:
@@ -529,7 +529,7 @@ $$
 Let:
 
 $$
-s=\max(\operatorname{sim}(q,d),0)\in[0,1]
+s=\max(\mathrm{sim}(q,d),0)\in[0,1]
 $$
 
 Then:
@@ -611,19 +611,19 @@ $$
 Variant projection is:
 
 $$
-\operatorname{Proj}(\mathcal{V}, q)=\mathcal{C}_2(q)\cup\mathcal{C}_{hop}^{*}(q)
+\mathrm{Proj}(\mathcal{V}, q)=\mathcal{C}_2(q)\cup\mathcal{C}_{hop}^{*}(q)
 $$
 
 Total injected soul context is:
 
 $$
-C_{soul}(q)=\mathcal{I}\cup \operatorname{Proj}(\mathcal{V}, q)
+C_{soul}(q)=\mathcal{I}\cup \mathrm{Proj}(\mathcal{V}, q)
 $$
 
 Let the total prompt budget be $\tau$. If the invariant set consumes:
 
 $$
-\tau_{\mathcal{I}}=\sum_{d\in\mathcal{I}} \operatorname{toks}(d)
+\tau_{\mathcal{I}}=\sum_{d\in\mathcal{I}} \mathrm{toks}(d)
 $$
 
 then the variant budget is:
@@ -632,11 +632,11 @@ $$
 \tau_{\mathcal{V}}=\tau-\tau_{\mathcal{I}}
 $$
 
-Documents in $\operatorname{Proj}(\mathcal{V}, q)$ are injected in descending
+Documents in $\mathrm{Proj}(\mathcal{V}, q)$ are injected in descending
 score order until:
 
 $$
-\sum_{d\in \text{injected}} \operatorname{toks}(d)\le\tau_{\mathcal{V}}
+\sum_{d\in \text{injected}} \mathrm{toks}(d)\le\tau_{\mathcal{V}}
 $$
 
 The merged score sequence is:
@@ -684,7 +684,7 @@ $$
 4. Token budget respect:
 
 $$
-\sum_{d\in C_{soul}(q)} \operatorname{toks}(d)\le\tau
+\sum_{d\in C_{soul}(q)} \mathrm{toks}(d)\le\tau
 $$
 
 with the invariant set never truncated

package/docs/security.md

@@ -16,26 +16,25 @@ The system is designed so a failure in one layer does not automatically collapse
 
 ## Supply Chain and Installer Trust Boundary
 
-This repository uses both `postinstall` and `openclaw.setup`. That is a real
-security-sensitive surface in the OpenClaw ecosystem and should be evaluated
-explicitly rather than hand-waved away.
+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
+component.
 
 Current implementation facts:
 
-- [`scripts/postinstall.js`](../scripts/postinstall.js) installs the sidecar
-  binary using a prebuilt-first strategy with a local Go fallback
-- [`scripts/setup.ts`](../scripts/setup.ts) provisions model/runtime assets and
-  verifies them before they are accepted
-- required downloaded assets are SHA-256 checked before use
-- an asset that exists but fails verification is deleted and re-downloaded
+- the published npm package has no `postinstall`
+- the published plugin manifest does not register `openclaw.setup`
+- the published plugin source contains no direct `child_process` usage
+- the plugin connects only to a configured local endpoint such as
+  `unix:/Users/<you>/.clawdb/run/libravdb.sock` or `tcp:127.0.0.1:37421`
+- daemon installation and lifecycle are explicit user or operator actions
 
-The current installer fetches from these classes of sources only:
+The daemon 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.
 
-- GitHub release assets for prebuilt sidecar binaries
-- ONNX Runtime release assets
-- model artifacts explicitly referenced in `setup.ts`
-
-After installation, the plugin is local-first:
+After installation, the plugin remains local-first:
 
 - no required network calls are made for embedding
 - no required network calls are made for extractive compaction
@@ -77,7 +76,7 @@ It reduces risk; it does not create a trusted execution environment.
 
 ## Deletion and Data Protection
 
-The sidecar exposes deletion and flush primitives. That matters operationally for:
+The daemon exposes deletion and flush primitives. That matters operationally for:
 
 - user-requested memory removal
 - namespace cleanup

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.3.3",
+  "version": "1.3.7",
   "kind": "memory",
   "configSchema": {
     "type": "object",