[Feature Request] Dreaming support — implement OpenClaw dreaming protocol when available

[Footree]

Summary

Requesting dreaming (Light → Deep → REM consolidation) support for memory-lancedb-pro, ideally aligned with the upstream effort to decouple dreaming from memory-core (openclaw/openclaw#85473).

Background

Dreaming is OpenClaw's background memory consolidation system. It periodically runs three phases:

• Light: collects and stages recent memory candidates
• Deep: scores and promotes strong candidates to durable memory
• REM: reflects on themes and recurring patterns

Currently, dreaming only works with memory-core. Users of memory-lancedb-pro cannot enable it (see #565, #705, #571, #608).

Prior art

Issue #577 presented a comprehensive analysis with three implementation strategies:

Strategy	Approach	Effort
A: Full implementation	Native Light/Deep/REM with LanceDB backend	High
B: Bridge mode	Implement the dreaming config contract, delegate phases to internal LanceDB operations	Medium
C: Prompt mode	Surface-level config compatibility only	Low

Strategy B seems the most practical near-term path — implement the dreaming config schema and wire phase operations to smart-extractor + auto-recall internals already in LanceDB.

What we need

1. dreaming config block compatibility (so OpenClaw UI does not reject it)
2. Phase pipeline backed by LanceDB (light = query recent, deep = promote, rem = reflect)
3. Ideally aligned with whatever protocol OpenClaw defines (ref: [Feature] Decouple dreaming from memory-core — allow any memory plugin to implement dreaming protocol openclaw/openclaw#85473)

Context

We run memory-lancedb-pro in production with autoCapture + autoRecall enabled. The missing piece is automated periodic consolidation — currently promotion is manual-only.

Related: #565, #577, #608, #705

[AliceLJY]

Thanks for the clear request. There is an active implementation PR for this path: #815.

Current maintainer-side status: I reviewed #815 and requested changes because the new CanonicalCorpusIndexer read surface can path-traverse out of memory/ via inputs like memory/../SECRET.md. I assigned that PR to @rwmjhb for the maintainer pass.

Once that blocker is fixed, #815 is the right thread to continue validating dreaming support against the OpenClaw protocol shape.

[airbing11]

Hi — thanks for tracking native dreaming protocol support here.

Until the in-repo engine path (#898 / broader protocol work) lands, we've been using a companion community plugin for LanceDB slots that need a full external Light / REM / Deep workflow today:

• memory-lancedb-dreaming on ClawHub
• LanceDB-vector-native pipeline + bilingual DREAMS.md
• Optional zero-LLM daily report push to Feishu, WeCom, or any other OpenClaw channel
• v0.2.9 packaging hotfix (please install @0.2.9, not ClawHub 0.2.8)

openclaw plugins install clawhub:memory-lancedb-dreaming@0.2.9

This is meant as a complement, not a replacement for native pro dreaming — more of a report / narrative / anti-repeat layer that works alongside memory-lancedb-pro today.

• https://clawhub.ai/plugins/memory-lancedb-dreaming
• https://github.com/airbing11/memory-lancedb-dreaming/releases/tag/v0.2.9

Happy to share production notes if useful for the protocol design.