openclaw - 💡(How to fix) Fix [Feature] Decouple dreaming from memory-core — allow any memory plugin to implement dreaming protocol

Summary

Dreaming (Light → Deep → REM consolidation) is a powerful feature, but it is currently tightly coupled to memory-core. Users who run alternative memory plugins (e.g. memory-lancedb-pro) cannot use dreaming even when the plugin is otherwise feature-complete.

The problem

Dreaming depends on memory-core internal state formats:

• short-term-recall.json
• Daily memory files (memory/YYYY-MM-DD.md)
• phase-signals.json
• Managed cron with hardcoded internal paths

None of these are exposed as a plugin protocol. A memory plugin cannot "opt in" to dreaming — it must either be memory-core or nothing.

Proposed solution

Expose dreaming as a memory plugin protocol consisting of:

1. Config schema: dreaming config block that any plugin can declare (e.g. enabled, frequency, model)
2. Required capabilities: a set of interface methods the plugin must implement to participate in the dreaming lifecycle:
   • Query recent memories (for light phase candidate collection)
   • Promote candidates (for deep phase durable writes)
   • Report state (for REFLECTION/REM phase)
3. Dreaming runtime: OpenClaw manages the cron scheduling and phase orchestration; the plugin implements the storage backend

This mirrors the pattern where OpenClaw already supports pluggable memory backends — dreaming should be part of that contract.

Related

• memory-lancedb-pro lacks dreaming support (CortexReach/memory-lancedb-pro#565)
• Existing dreaming bugs that stem from tight coupling: #84286, #84847, #84882
• //dreaming slash command and Dreams UI currently hardcode memory-core assumptions

Benefit

Any memory plugin could implement the dreaming protocol, enabling:

• memory-lancedb-pro users to get automatic memory consolidation
• Future memory plugins to ship with dreaming support from day one
• Reduced maintenance burden on OpenClaw core (protocol vs. monolith)