Project Status Inquiry: 2.5 months without updates - is this project still maintained?

[DerekEXS]

Hi @CortexReach,

I noticed this repository has had no commits or activity for approximately 2.5 months (last push: 2026-03-23). I want to check in before raising concerns, and I'm hoping to get a clear answer on the project's status.

What I observed

• Last push: 2026-03-23
• Last general update: 2026-02-24
• No formal releases published (only one tag: v1.1.0)
• Stars: 2
• Open issues: 2 (unanswered)
• No recent activity from the maintainer

My use case

I've been using the npm-published community fork @ruliu/memory-lancedb-pro (v1.1.9), which appears to be a maintained continuation of your work. While debugging integration with OpenClaw 2026.5.27+, I encountered a fundamental architectural issue that I believe originates from this plugin's design rather than configuration:

The core problem

The plugin's management tools (memory_store, memory_recall, etc.) are not exposed to the Agent through OpenClaw's tool routing system. Despite:

• enableManagementTools: true being set
• hooks.allowConversationAccess: true being configured
• The LanceDB database being healthy (356 entries intact)
• embedding, retrieval, and rerank all working at the API level

...the Agent cannot see or call any of these tools. It falls back to writing MD files and using LCM (lossless-claw) compression history as a poor man's memory.

Specific questions

1. Are you still actively maintaining this project?
2. Is there a successor repository or official handoff to the @ruliu community fork?
3. Have you seen the same tool-exposure issue in newer OpenClaw versions? Is this a known regression?
4. Would you be open to adding a contracts.tools declaration (currently missing in the community fork, causing OpenClaw startup warnings) to make tool exposure explicit?

Suggestions if you'd like to revive it

If you do have time/interest, here are concrete improvements that would dramatically increase adoption:

1. Publish formal releases to npm (currently only v1.1.0 tag exists). Semantic versioning helps users trust upgrades.
2. Add contracts.tools declaration in openclaw.plugin.json for OpenClaw 2026.5.27+ compatibility. This eliminates startup warnings and may fix the tool-routing issue.
3. Document the auto-capture behavior explicitly. Currently agent_end hook triggering is unpredictable and undocumented.
4. Consider explicit enableManagementTools: true default in the schema, since the management tools are the most valuable feature.
5. Add an ARCHIVED notice or transfer ownership to the active community fork if you don't plan to continue. This would help users like me avoid the dead-end we hit.

Why I'm asking

I spent significant time debugging what turned out to be an architectural issue, not a configuration problem. A clear status update would help others avoid the same path. And if there's any chance of revival, I'd be happy to help test or contribute documentation.

Thanks for your time and the great work on this plugin — even with the tool-exposure issue, the underlying LanceDB + hybrid retrieval design is excellent.

---

Environment details:

• OpenClaw: 2026.5.27 → 2026.5.28
• Plugin version tested: 1.1.9 (community fork)
• LanceDB: 356 entries, vector retrieval working
• Embedding: text-embedding-v4 @ 2048d (dimensions + requestDimensions both required)
• Rerank: qwen3-rerank via DashScope

[DerekEXS]

cc @ruliu (the maintainer of the npm-published community fork @ruliu/memory-lancedb-pro v1.1.9)

Hi! I opened this issue on the upstream repo, but I want to flag the same concerns specifically to you as the active community maintainer, since your npm scope is the one most users are actually running today.

Quick context

I'm using @ruliu/memory-lancedb-pro@1.1.9 on OpenClaw 2026.5.28. The plugin runs perfectly in the background (LanceDB healthy, 356 entries, hybrid retrieval OK at the API level), but its management tools (memory_store, memory_recall, etc.) are not visible to the Agent in OpenClaw 2026.5.27+ — see the upstream issue for full repro steps.

I've also opened an architecture-level bug against OpenClaw core here: openclaw/openclaw#89173 — please chime in there if you have any insight on the tool-routing side, since you're closest to the plugin code.

Specific requests for the @ruliu fork

1. Add contracts.tools declaration in openclaw.plugin.json. I tried manually patching the build artifact and the runtime warning went away, but it didn't fix the tool exposure. Still, this declaration should be present for OpenClaw 2026.5.27+ compatibility and to silence the startup warning.

2. Document enableManagementTools: true more prominently. This was the most valuable knob to flip, and it's hidden in the schema. A README section "Enabling Agent-callable memory tools" would save hours of debugging.

3. Document agent_end hook auto-capture behavior explicitly. From the user's side, the trigger is unpredictable — sometimes captures fire, sometimes they don't, and there's no clear doc on what controls it.

4. Consider bumping to 1.2.0 when these land. The current 1.1.x line is stable, and a minor version bump signals "here are the OpenClaw 2026.5.27+ fixes."

5. Add a CHANGELOG.md if you don't have one. Right now there's no record of what changed between 1.1.8 and 1.1.9.

Why I'm asking you specifically

Your fork is the one in active use — I've seen CortexReach's repo go quiet, but your npm releases are still flowing. Maintaining just a few of these items would make the plugin dramatically more reliable for everyone using it on modern OpenClaw.

If you're open to it, I'd be happy to send a PR for the contracts.tools patch and the README additions, and to help with the changelog.

Thanks for keeping this alive.

---

Environment:

• OpenClaw: 2026.5.28
• Plugin: @ruliu/memory-lancedb-pro@1.1.9
• Embedding: text-embedding-v4 @ 2048d (both dimensions and requestDimensions set)
• Rerank: qwen3-rerank via DashScope
• LCM fallback: lossless-claw 0.11.3 + MD files in ~/.openclaw/workspace/memory/

[AliceLJY]

Thanks for the detailed status report. Current maintainer status is: this repo is active again, but the release surface still needs cleanup.

Recent activity that changes the picture a bit:

• Fix default scopes for memory management tools #844 was merged on 2026-06-01 for default scopes on memory management tools.
• Fix reflection legacy upgrade classification #846 was merged on 2026-06-01 for reflection legacy upgrade classification.
• feat: add Obsidian memory sync command #849 was merged today for the first-pass Obsidian export command.

You are right that npm/release state is still messy. As of today, latest is 1.0.32, beta is still 1.1.0-beta.9, while the repo package version is already 1.1.0-beta.11. That needs a release/dist-tag follow-up before users can trust the published line.

On the OpenClaw 2026.5.x tool exposure issue: contracts.tools / hook contract compatibility is being tracked in #834, but that PR is currently conflict-blocked and needs a rebase before it can be reviewed or merged. #844 helps the management-tool scope defaults, but I would not claim it fully solves the newer OpenClaw tool-routing issue until the contracts path is clean and tested.

No official handoff to the @ruliu fork has been made from my side; treat it as a community fork unless the project owner states otherwise. I am keeping this issue open until the contracts + release status is clearer.

[TurboTheTurtle]

On the OpenClaw 2026.5.x tool exposure issue: contracts.tools / hook contract compatibility is being tracked in #834, but that PR is currently conflict-blocked and needs a rebase before it can be reviewed or merged. #844 helps the management-tool scope defaults, but I would not claim it fully solves the newer OpenClaw tool-routing issue until the contracts path is clean and tested.

No official handoff to the @ruliu fork has been made from my side; treat it as a community fork unless the project owner states otherwise. I am keeping this issue open until the contracts + release status is clearer.

@AliceLJY The contracts/tool-routing blocker appears resolved on master and CI is green. Can we cut a new npm release and update the beta/latest dist-tags?