@xdarkicex/openclaw-memory-libravdb 1.3.12 → 1.3.17

package/docs/install.md

@@ -0,0 +1,181 @@
+# Install Guide
+
+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.
+
+For deeper operational detail, use the full
+[installation reference](./installation.md).
+
+## Recommended Path: Homebrew + OpenClaw Plugin
+
+On macOS, the shortest supported path is:
+
+```bash
+brew tap xDarkicex/openclaw-libravdb-memory
+brew install libravdbd
+brew services start libravdbd
+openclaw plugins install @xdarkicex/openclaw-memory-libravdb
+```
+
+This gives you:
+
+- a managed `libravdbd` service
+- a scanner-clean plugin install
+- a clean separation between plugin lifecycle and daemon lifecycle
+
+## Plugin Install
+
+Install the plugin package with the OpenClaw CLI:
+
+```bash
+openclaw plugins install @xdarkicex/openclaw-memory-libravdb
+```
+
+If you use the OpenClaw.ai plugin UI instead of the CLI, install the same
+package and then assign the plugin id `libravdb-memory` to both the `memory`
+and `contextEngine` slots.
+
+Activate the plugin in `~/.openclaw/openclaw.json`:
+
+```json
+{
+  "plugins": {
+    "slots": {
+      "memory": "libravdb-memory",
+      "contextEngine": "libravdb-memory"
+    }
+  }
+}
+```
+
+If you run the daemon on a non-default endpoint, add a plugin config:
+
+```json
+{
+  "plugins": {
+    "slots": {
+      "memory": "libravdb-memory",
+      "contextEngine": "libravdb-memory"
+    },
+    "configs": {
+      "libravdb-memory": {
+        "sidecarPath": "unix:/Users/<you>/.clawdb/run/libravdb.sock"
+      }
+    }
+  }
+}
+```
+
+## Sidecar Daemon Install
+
+The daemon owns the local database, embeddings, and JSON-RPC endpoint.
+
+Default endpoints:
+
+- macOS/Linux: `unix:$HOME/.clawdb/run/libravdb.sock`
+- Windows: `tcp:127.0.0.1:37421`
+
+Default data path:
+
+- macOS/Linux/Windows user installs: `$HOME/.clawdb/data.libravdb`
+
+### Homebrew
+
+Homebrew is the preferred daemon lifecycle on macOS:
+
+```bash
+brew tap xDarkicex/openclaw-libravdb-memory
+brew install libravdbd
+brew services start libravdbd
+```
+
+Useful lifecycle commands:
+
+```bash
+brew services restart libravdbd
+brew services stop libravdbd
+brew info libravdbd
+```
+
+### Manual Service Management
+
+If you are not using Homebrew, manage the daemon explicitly.
+
+Linux user service from the repo template:
+
+```bash
+# Replace vX.Y.Z with the latest tag from:
+# https://github.com/xDarkicex/openclaw-memory-libravdb/releases
+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
+curl -L -o ~/.config/systemd/user/libravdbd.service \
+  https://raw.githubusercontent.com/xDarkicex/openclaw-memory-libravdb/main/packaging/systemd/libravdbd.service
+systemctl --user enable --now libravdbd.service
+```
+
+macOS LaunchAgent from the repo template:
+
+1. Download `com.xdarkicex.libravdbd.plist` from:
+   `https://raw.githubusercontent.com/xDarkicex/openclaw-memory-libravdb/main/packaging/launchd/com.xdarkicex.libravdbd.plist`
+2. Replace `__HOME__` with your home directory.
+3. Save it to `~/Library/LaunchAgents/com.xdarkicex.libravdbd.plist`.
+4. Load it with `launchctl bootstrap gui/$(id -u) ~/Library/LaunchAgents/com.xdarkicex.libravdbd.plist`.
+
+### Windows
+
+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
+and run it under your preferred process supervisor or a manual terminal session.
+
+Foreground manual run:
+
+```bash
+libravdbd serve
+```
+
+That mode is useful for debugging or validating a local release asset before
+you wrap it in `brew services`, `systemd`, or `launchd`.
+
+## Lifecycle Management
+
+### Plugin Lifecycle
+
+- Install the package with `openclaw plugins install`.
+- Activate it by assigning `libravdb-memory` to both `memory` and `contextEngine`.
+- 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.
+
+### 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.
+- 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:
+
+```bash
+openclaw memory status
+```
+
+Healthy output should show that:
+
+- the daemon answered the local health check
+- the memory slot is active
+- the plugin can read stored counts and runtime settings
+
+If OpenClaw cannot reach the daemon, verify the endpoint first:
+
+- macOS/Linux default: `unix:$HOME/.clawdb/run/libravdb.sock`
+- Windows default: `tcp:127.0.0.1:37421`

package/docs/installation.md

@@ -7,7 +7,7 @@ This document is the full installation reference for `@xdarkicex/openclaw-memory
 | Requirement | Minimum | Recommended | Notes |
 |---|---|---|---|
 | 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 |
+| 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 base plugin API shape this repo uses. Newer hosts may also expose the optional `registerMemoryRuntime` seam, which this plugin now adopts when available |
 | 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 |
@@ -183,6 +183,8 @@ The release workflow generates a publish-ready `libravdbd.rb` formula asset from
 - `libravdbd-linux-amd64`
 - `libravdbd-linux-arm64`
 
+The generated Homebrew formula also stages the bundled ONNX Runtime archive, the shipped embedding profile assets, and the T5 summarizer bundle into the install prefix so the daemon can start without a separate manual asset unpack step.
+
 If your GitHub Actions configuration includes:
 
 - repository variable `HOMEBREW_TAP_REPO`, for example `xDarkicex/homebrew-openclaw-libravdb-memory`
@@ -196,7 +198,8 @@ Example plugin config:
 {
   "plugins": {
     "slots": {
-      "memory": "libravdb-memory"
+      "memory": "libravdb-memory",
+      "contextEngine": "libravdb-memory"
     },
     "configs": {
       "libravdb-memory": {
@@ -217,7 +220,7 @@ Installed plugin: libravdb-memory
 
 ## Activation
 
-The plugin declares `kind: ["memory", "context-engine"]` and registers for both the `memory` and `context-engine` slots. Either slot assignment activates the plugin.
+The plugin declares `kind: ["memory", "context-engine"]` and is intended to own both the `memory` and `contextEngine` slots together. Treat partial slot assignment as a misconfiguration.
 
 Add this to `~/.openclaw/openclaw.json`:
 
@@ -225,18 +228,7 @@ Add this to `~/.openclaw/openclaw.json`:
 {
   "plugins": {
     "slots": {
-      "memory": "libravdb-memory"
-    }
-  }
-}
-```
-
-If your OpenClaw build uses the `contextEngine` slot instead, you can assign it there:
-
-```json
-{
-  "plugins": {
-    "slots": {
+      "memory": "libravdb-memory",
       "contextEngine": "libravdb-memory"
     }
   }
@@ -245,8 +237,13 @@ If your OpenClaw build uses the `contextEngine` slot instead, you can assign it
 
 Notes:
 
-- Either `memory` or `contextEngine` slot assignment activates the plugin. You do not need both.
+- This plugin should own both `memory` and `contextEngine`. Do not assign only one of them.
 - The plugin id is `libravdb-memory`. The npm package name used at install time is `@xdarkicex/openclaw-memory-libravdb`.
+- On newer OpenClaw versions, the plugin also registers a memory runtime bridge so the built-in `memory_search` tool can query libraVDB through the same sidecar-backed retrieval path.
+- On newer OpenClaw versions, the plugin also listens for `before_reset` and `session_end` so it can send best-effort lifecycle hints into the sidecar.
+- Those hints are journaled internally by the sidecar and can be inspected with `openclaw memory journal` without exposing them to normal memory export or recall.
+- The journal keeps only a bounded number of newest entries. Override that cap with `plugins.configs.libravdb-memory.lifecycleJournalMaxEntries` if you need a different retention window.
+- The plugin does not currently register `registerMemoryFlushPlan`; transcript ingest and compaction remain owned by the context-engine lifecycle and the sidecar.
 
 Without a slot entry, OpenClaw's default memory can continue to run in parallel.
 

package/docs/mathematics-v2.md

@@ -5,7 +5,9 @@ by the plugin. The gating scalar is documented separately in
 [gating.md](./gating.md). The continuity model and recent-tail preservation
 layer are documented in [continuity.md](./continuity.md). The authored
 invariant/variant partitioning rules are documented in
-[ast-v2.md](./ast-v2.md). Earlier non-versioned math docs are preserved for
+[ast-v2.md](./ast-v2.md). The protected-shadow-rule Tier 1.5 model is
+documented in [elevated-guidance.md](./elevated-guidance.md). Earlier
+non-versioned math docs are preserved for
 historical context, but the reviewed `*-v*` documents are authoritative when
 both forms exist.
 
@@ -603,6 +605,69 @@ $$
 
 This makes compaction load-bearing in retrieval rather than archival only.
 
+### 5.6 Optional Lossless Compaction Extension
+
+The current implementation replaces compacted session turns in the searchable
+session collection after summary insertion succeeds. A stronger future variant
+is to preserve compacted raw turns in an immutable session-history layer and
+treat summary records as derived view nodes over that history. This extension is
+inspired by the immutable-store and expandable-summary architecture in the LCM
+paper ([Ehrlich and Blackman, 2026](https://papers.voltropy.com/LCM)), but the
+formalization here is adapted to this repository's existing compaction and
+continuity math.
+
+Let:
+
+$$
+\mathcal{R}_{\mathrm{session}}=\langle r_1,\dots,r_n\rangle
+$$
+
+be the immutable raw session history, and let:
+
+$$
+\mathbf{S}=\{s_1,s_2,\dots\}
+$$
+
+be the set of compacted summary nodes. Define the summary-coverage DAG:
+
+$$
+\mathcal{G}_{\mathrm{cont}}=(\mathbf{S}\cup\mathcal{R}_{\mathrm{session}}, E_{\triangleleft})
+$$
+
+with:
+
+$$
+E_{\triangleleft}\subseteq (\mathbf{S}\times\mathbf{S})\cup(\mathbf{S}\times\mathcal{R}_{\mathrm{session}})
+$$
+
+Recursive raw expansion is:
+
+$$
+\mathrm{Expand}^{*}(x)=
+\begin{cases}
+\{x\} & \text{if } x\in\mathcal{R}_{\mathrm{session}} \\
+\bigcup_{y:(x,y)\in E_{\triangleleft}} \mathrm{Expand}^{*}(y) & \text{if } x\in\mathbf{S}
+\end{cases}
+$$
+
+The continuity contract for this extension is:
+
+$$
+\forall s\in\mathbf{S},\ \mathrm{Expand}^{*}(s)\neq\emptyset
+$$
+
+and:
+
+$$
+\forall r\in\mathcal{R}_{\mathrm{session}},\ \exists x\in \mathbf{S}\cup T_{\mathrm{recent}} \text{ such that } r\in\mathrm{Expand}^{*}(x)
+$$
+
+Under this extension, compaction changes the active retrievable view and the
+assembly surface, but not the existence of raw historical evidence. This is
+compatible with the section-1 through section-5 retrieval math because the
+hybrid score still applies to the injected/searchable nodes; the extension only
+strengthens the recoverability contract beneath those nodes.
+
 ## 6. Why These Pieces Compose
 
 The full quality loop is:
@@ -1226,3 +1291,98 @@ Q(d)\in[1-\delta,\,1]\subseteq[0,1]
 $$
 
 for all valid inputs with $\delta\in[0,1]$.
+
+## 8. Theory Boundary And Future Refinement
+
+Cross-review of this document and [`continuity.md`](./continuity.md) surfaced a
+useful mathematical boundary that this reference should keep explicit:
+
+1. storage and continuity axioms
+2. primary retrieval and assembly math
+3. optional recoverability policy
+
+### 8.1 What Is Core Math
+
+The core retrieval theorem in this document is the scored, budgeted selection
+of retrievable nodes from $\mathcal{V}_{\mathrm{rest}}$ together with authored
+invariants and the exact recent tail. In other words, the primary law remains:
+
+$$
+C_{\mathrm{total}}(q)=\mathcal{I}_1\cup \mathcal{I}_2^{*}\cup T_{\mathrm{recent}}\cup \mathrm{Proj}(\mathcal{V}_{\mathrm{rest}}, q)
+$$
+
+with the retrieval side governed by:
+
+$$
+S_{\mathrm{final}}(d)=S_{\mathrm{base}}(d)\cdot Q(d)
+$$
+
+and the budget side governed by the residual variant budget
+$\tau_{\mathcal{V}}(q)$ defined in Section 7.8.
+
+### 8.2 What Is Not Core Math
+
+The following should be treated as policy or heuristic unless they are derived
+from the governing score equations and budget laws:
+
+- automatic query-time summary expansion
+- fixed expansion penalties
+- fixed expansion token sub-budgets
+- confidence thresholds for expansion eligibility
+- recursion-depth limits for summary expansion
+
+These controls may be useful in runtime experiments, but they are not theorem
+terms by default. They should not be mistaken for new axioms of the scoring
+model.
+
+### 8.3 Lossless Does Not Mean Always Expand
+
+The lossless extension in Section 5.6 strengthens the storage and
+recoverability contract. It does not imply that every relevant summary should be
+expanded into raw turns during ordinary retrieval.
+
+The mathematically safe reading is:
+
+- raw immutability is an axiom
+- $\mathrm{Expand}^{*}$ is a recoverability theorem over the summary DAG
+- query-time expansion is **explicit recovery/audit only** — it was removed from
+  the hot retrieval path and is not the default behavior; any expansion beyond
+  the core $C_{\mathrm{total}}(q)$ assembly must be triggered deliberately, not
+  applied silently to ranked candidates
+
+This distinction preserves the design goal that continuity and recoverability
+support retrieval without silently replacing it.
+
+### 8.4 Preferred Direction For Future Refinement
+
+If a future version wants query-time expansion inside the main retrieval path,
+the preferred direction is to re-derive it from the existing two-pass and
+multi-hop framework rather than introduce standalone penalties and thresholds
+that float outside the score model.
+
+In practical terms, future refinement should prefer one of two paths:
+
+1. keep summary expansion as a separate recovery or audit layer
+2. formally unify summary expansion with the existing hop-expansion math
+
+What this document should avoid is an in-between state where recoverability
+logic behaves like a second retrieval theorem without being derived as one.
+
+### 8.5 Preserved Research Ideas
+
+The review process also surfaced several strong theoretical ideas that are worth
+retaining for future work:
+
+- rate-distortion views of compaction quality
+- information-adaptive clustering instead of equal-size chronological buckets
+- hot-spot preservation tiers driven by access concentration
+- causal-centrality-aware compaction penalties or vetoes
+- entropy-based tail selection
+- retrieval-failure-triggered raw-history recovery (the specific observable
+  signals S1/S2/S3 are defined in the vNext spec slice; this entry refers to the
+  general concept, not the current implementation)
+- closed-loop compaction tuning driven by observed retrieval quality
+
+These ideas are intentionally preserved as future mathematics rather than
+current contract. The present document remains normative only for the formulas
+and invariants already defined above.

package/docs/uninstall.md

@@ -0,0 +1,100 @@
+# Uninstall Guide
+
+This guide covers safe removal of the OpenClaw / OpenClaw.ai plugin and the
+separately managed `libravdbd` daemon.
+
+If you only want to disable the memory replacement temporarily, remove the
+plugin slot assignment first and leave the daemon plus data in place.
+
+## 1. Disable the Plugin
+
+Remove the plugin from the active OpenClaw slot in `~/.openclaw/openclaw.json`:
+
+```json
+{
+  "plugins": {
+    "slots": {}
+  }
+}
+```
+
+Treat that JSON as a minimal example only. If you assigned `libravdb-memory`
+under both `memory` and `contextEngine`, remove those two slot entries and
+leave any other plugin slots intact.
+
+If you installed the package through the OpenClaw.ai plugin UI, remove or
+disable the same package there as well. If you use the CLI, remove it through
+your standard OpenClaw plugin removal flow for
+`@xdarkicex/openclaw-memory-libravdb`.
+
+## 2. Stop the Daemon
+
+Stop the sidecar before deleting binaries or stored data.
+
+Homebrew:
+
+```bash
+brew services stop libravdbd
+```
+
+Linux user service:
+
+```bash
+systemctl --user disable --now libravdbd.service
+```
+
+macOS LaunchAgent:
+
+```bash
+launchctl bootout gui/$(id -u)/com.xdarkicex.libravdbd
+```
+
+Foreground manual run:
+
+- stop the `libravdbd serve` process in the terminal where it is running
+
+## 3. Remove Installed Assets
+
+### Plugin Package
+
+Remove the published plugin package from OpenClaw or OpenClaw.ai after it is no
+longer assigned to an active slot.
+
+### Homebrew Daemon
+
+```bash
+brew uninstall libravdbd
+brew untap xDarkicex/openclaw-libravdb-memory
+```
+
+### Manual Daemon Install
+
+Delete the service file or launch agent you installed, along with the daemon
+binary you copied into place.
+
+Common locations:
+
+- `~/.config/systemd/user/libravdbd.service`
+- `~/Library/LaunchAgents/com.xdarkicex.libravdbd.plist`
+- `~/.local/bin/libravdbd`
+
+## 4. Optional Full Data Cleanup
+
+Only do this if you want to permanently remove stored LibraVDB memory.
+
+Common local state:
+
+- socket directory: `~/.clawdb/run/`
+- database file: `~/.clawdb/data.libravdb`
+
+If you configured a custom Unix socket endpoint in `sidecarPath`, remove that
+socket path or containing directory if applicable. If you configured `dbPath`,
+remove that custom database location instead of the default path. TCP
+`sidecarPath` endpoints are not filesystem paths and do not have anything to
+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
+unless you intentionally kept it running for another workflow.

package/openclaw.plugin.json

@@ -10,6 +10,7 @@
     "properties": {
       "dbPath": { "type": "string" },
       "sidecarPath": { "type": "string" },
+      "useSessionSummarySearchExperiment": { "type": "boolean" },
       "embeddingRuntimePath": { "type": "string" },
       "embeddingBackend": { "type": "string", "enum": ["bundled", "onnx-local", "custom-local"] },
       "embeddingProfile": {
@@ -64,6 +65,10 @@
         "type": "number",
         "default": 10
       },
+      "lifecycleJournalMaxEntries": {
+        "type": "number",
+        "default": 500
+      },
       "compactionQualityWeight": {
         "type": "number",
         "default": 0.5,

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "@xdarkicex/openclaw-memory-libravdb",
-  "version": "1.3.12",
+  "version": "1.3.17",
   "type": "module",
   "publishConfig": {
     "access": "public"
@@ -27,6 +27,10 @@
     "check": "./.ts-toolchain/node_modules/.bin/tsc --noEmit && pnpm run test:ts",
     "test:ts": "./.ts-toolchain/node_modules/.bin/tsc -p tsconfig.tests.json && node --test .ts-build/test/unit/*.test.js",
     "test:integration": "./.ts-toolchain/node_modules/.bin/tsc -p tsconfig.tests.json && node --test .ts-build/test/integration/checklist-validation.test.js .ts-build/test/integration/host-flow.test.js .ts-build/test/integration/sidecar-lifecycle.test.js",
+    "benchmark:session_search_mid": "./.ts-toolchain/node_modules/.bin/tsc -p tsconfig.tests.json && OPENCLAW_PROFILE_ASSEMBLE=1 node --test --test-name-pattern=\"real sidecar mid-sized session search benchmark\" .ts-build/test/integration/host-flow.test.js",
+    "gate:assemble_optimization": "./.ts-toolchain/node_modules/.bin/tsc -p tsconfig.tests.json && OPENCLAW_PROFILE_ASSEMBLE=1 OPENCLAW_ENFORCE_ASSEMBLE_EVIDENCE_GATE=1 node --test --test-name-pattern=\"real sidecar mid-sized session search benchmark\" .ts-build/test/integration/host-flow.test.js",
+    "probe:session_recall": "./.ts-toolchain/node_modules/.bin/tsc -p tsconfig.tests.json && OPENCLAW_PROFILE_ASSEMBLE=1 node --test --test-name-pattern=\"real sidecar mid-sized session search benchmark\" .ts-build/test/integration/host-flow.test.js",
+    "probe:session_recall_threshold": "./.ts-toolchain/node_modules/.bin/tsc -p tsconfig.tests.json && OPENCLAW_PROFILE_ASSEMBLE=1 node --test --test-name-pattern=\"real sidecar session_recall index threshold probe\" .ts-build/test/integration/host-flow.test.js",
     "build:daemon": "bash scripts/build-daemon.sh"
   },
   "dependencies": {

package/packaging/README.md

@@ -11,16 +11,51 @@ The templates assume the default daemon endpoint contract used by the plugin:
 - macOS/Linux: `unix:$HOME/.clawdb/run/libravdb.sock`
 - Windows: `tcp:127.0.0.1:37421`
 
+## LaunchAgent plist
+
 Before loading the macOS plist, replace:
 
 - `__LIBRAVDBD_PATH__` with the absolute path to the `libravdbd` binary
 - `__HOME__` with the current user's home directory
+- `__ONNX_RUNTIME_LIB__` with the absolute path to the ONNX runtime shared library (e.g. `/path/to/onnxruntime/onnxruntime-osx-arm64-1.23.0/lib/libonnxruntime.dylib`)
+
+## Provisioning models and runtime
+
+**Primary install path:** The Homebrew formula (`brew install libravdbd`)
+provisions all required assets — ONNX Runtime, nomic-embed-text-v1.5,
+all-minilm-l6-v2, and t5-small — inline during `brew install`.  No
+additional steps are needed for a clean install.
+
+**Repair / recovery:** If assets are deleted or corrupted after install,
+`scripts/provision.sh` can rebuild them.  This is an operator tool, not
+the normal install path.
+
+```bash
+bash scripts/provision.sh                     # provisions into .daemon-bin/
+bash scripts/provision.sh --target /opt/libravdbd/assets  # custom target
+bash scripts/provision.sh --skip-summarizer   # skip optional t5-small model
+```
+
+The script downloads models from HuggingFace and the ONNX runtime from
+GitHub Releases, verifies SHA-256 checksums, and writes the `embedding.json`
+manifests that `libravdbd` needs at startup.  It is idempotent — existing
+verified assets are left in place.
+
+The npm package does not include `provision.sh` or any install-time
+provisioning hooks.  The `scripts/` directory is excluded from the
+published npm tarball via the `files` whitelist in `package.json`.
+
+## Homebrew formula
 
 The release workflow now generates `dist/libravdbd.rb` from this template using
 the release version and SHA-256 files. If `HOMEBREW_TAP_REPO` and
 `HOMEBREW_TAP_TOKEN` are configured in GitHub Actions, the workflow also updates
 the tap automatically.
 
+The Homebrew formula stages the bundled ONNX Runtime archive, the shipped
+embedding profile assets, and the T5 summarizer bundle into the install prefix
+so the daemon can boot without an extra asset-unpack step.
+
 Expected GitHub configuration:
 
 - repository variable `HOMEBREW_TAP_REPO`, for example `xDarkicex/homebrew-openclaw-libravdb-memory`
@@ -33,3 +68,4 @@ Template placeholders:
 - `__SHA256_DARWIN_AMD64__`
 - `__SHA256_LINUX_ARM64__`
 - `__SHA256_LINUX_AMD64__`
+- `__SHA256_PROVISION__`