Add Arven Memory provider plugin#1
Closed
efe-arv wants to merge 10000 commits into
Closed
Conversation
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
What Problem This Solves
OpenClaw can select memory backends through bundled plugin metadata and
plugins.slots.memory, but there is no bundled Arven Memory option. Users who want to run an Arven-compatible local MCP memory bridge currently need an out-of-tree integration or a UI/config workaround.This PR adds a bundled
arven-memorymemory-slot plugin that exposes Arven Memory through an HTTP MCP bridge without patching OpenClaw UI code.Summary
extensions/arven-memorywithkind: "memory", config schema, UI hints, and tool contracts.memory_searchandmemory_getwhen the Arven slot is selected.arven/arven-memory->plugins.slots.memory = "arven-memory").Update-agnostic design
This does not edit dropdown/UI code. OpenClaw discovers the provider through normal plugin manifest metadata and exclusive memory-slot selection, so UI/provider list changes should keep picking it up via the existing registry path.
The MCP tool names are configurable (
recallTool,getTool,storeTool,statusTool) so bridge implementations can evolve without another OpenClaw UI patch.Sensitive-data check
Checked the PR diff for common secret patterns, high-entropy strings, tokens, private keys, personal identifiers, and internal references. The only matches are non-secret code/docs references to an optional Authorization header environment variable and loopback example URLs.
Evidence
CI=true corepack pnpm install --frozen-lockfilePATH=/tmp/openclaw-pnpm-shim:$PATH pnpm tsgoPATH=/tmp/openclaw-pnpm-shim:$PATH pnpm exec oxlint extensions/arven-memory/index.ts extensions/arven-memory/index.test.tscorepack pnpm exec oxfmt --check extensions/arven-memory/index.ts extensions/arven-memory/index.test.ts extensions/arven-memory/package.json extensions/arven-memory/openclaw.plugin.json docs/concepts/memory-arven.mdPATH=/tmp/openclaw-pnpm-shim:$PATH pnpm vitest run src/plugins/contracts/plugin-tool-contracts.test.ts— 1 file passed, 2 tests passed.corepack pnpm vitest run extensions/arven-memory/index.test.tsPATH=/tmp/openclaw-pnpm-shim:$PATH node scripts/test-extension.mjs arven-memoryNote: after rebasing onto current upstream main, focused extension Vitest spent minutes in upstream plugin timing/build metadata and was stopped before test execution. Full
tsgo, lint, format, frozen install, and the tool-contract Vitest passed on the rebased branch.