Feature Request: Allow memory-core to run alongside external memory plugins (e.g., memory-lancedb-pro) for dreaming functionality

Problem Description

Currently, OpenClaw's memory slot mechanism uses an exclusive allocation strategy, meaning only one plugin can occupy the memory slot at a time. This prevents memory-core (bundled plugin) from running alongside external memory plugins like memory-lancedb-pro, which breaks the intended architecture of:

• memory-lancedb-pro: External plugin for enhanced storage + retrieval (hybrid Vector + BM25, Rerank, Scope isolation)
• memory-core: Bundled plugin providing dreaming framework (automatic memory consolidation)
• dreaming: Automatic memory organization that should use the storage capabilities of memory-lancedb-pro

Current Behavior

1. When slots.memory = "memory-lancedb-pro" is configured:

   • memory-lancedb-pro occupies the memory slot ✓
   • memory-core is marked as disabled (Gateway shows: plugin disabled (memory slot set to "memory-lancedb-pro")) ✗
   • dreaming does NOT start (no dreaming logs in Gateway startup) ✗
   • Manual memory_store and memory_recall work fine (via memory-lancedb-pro) ✓

2. Gateway startup logs show:

[plugins] memory-lancedb-pro: initialized successfully
Config warnings: plugins.entries.memory-core: plugin disabled (memory slot set to "memory-lancedb-pro") but config is present

Expected Behavior

The resolveMemoryDreamingPluginId() function already determines which plugin dreaming should use based on slots.memory:

function resolveMemoryDreamingPluginId(cfg) {
  const configuredSlot = cfg.plugins?.slots?.memory?.trim();
  if (configuredSlot && configuredSlot !== "none") return configuredSlot;
  return DEFAULT_MEMORY_DREAMING_PLUGIN_ID; // "memory-core"
}

This suggests dreaming was designed to work with external memory plugins, but the plugin activation logic (resolveEffectivePluginActivationState) still enforces the exclusive slot constraint, preventing memory-core from starting even when it's needed for dreaming.

Desired Architecture

• memory-lancedb-pro occupies memory slot (for storage/retrieval) ✓
• memory-core starts without occupying memory slot (for dreaming framework) ✓
• dreaming uses memory-lancedb-pro storage (via resolveMemoryDreamingPluginId) ✓

Root Cause Analysis

The issue is in shouldConsiderForGatewayStartup():

function shouldConsiderForGatewayStartup(params) {
  if (isGatewayStartupSidecar(params.plugin)) return true;
  if (!isGatewayStartupMemoryPlugin(params.plugin)) return false;
  if (params.startupDreamingPluginIds.has(params.plugin.id)) return true; // memory-core should start via dreaming
  return params.explicitMemorySlotStartupPluginId === params.plugin.id; // BUT this checks memory slot occupation
}

Even when memory-core is in startupDreamingPluginIds (when dreaming.enabled = true), the activation state resolver (resolveEffectivePluginActivationState) still checks if the plugin's memory slot is occupied, causing it to be marked as disabled.

Suggested Solution

Modify the plugin activation logic to allow bundled plugins启动through special mechanisms (like dreaming) to bypass the memory slot exclusive check:

1. If a plugin is in startupDreamingPluginIds, it should be allowed to start without requiring the memory slot
2. The plugin should only provide the framework functionality (dreaming orchestration), not storage
3. Storage operations are delegated to the plugin specified in slots.memory

This would enable the intended architecture:

• dreaming framework runs via memory-core ✓
• storage/retrieval runs via memory-lancedb-pro ✓
• Both plugins work together seamlessly ✓

Configuration Example

{
  "plugins": {
    "entries": {
      "memory-lancedb-pro": {
        "enabled": true,
        "config": {
          "embedding": {...},
          "retrieval": {"mode": "hybrid"}
        }
      },
      "memory-core": {
        "enabled": true,
        "config": {
          "dreaming": {
            "enabled": true,
            "storage": {"mode": "separate"}
          }
        }
      }
    },
    "slots": {
      "memory": "memory-lancedb-pro"
    }
  }
}

Environment

• OpenClaw: 2026.4.21
• Gateway: v2026.4.15
• Plugin: [email protected]
• Platform: Linux (WSL2 on Windows)

Additional Context

This issue prevents users from benefiting from both:

• Enhanced memory retrieval (hybrid search, Rerank, multi-scope isolation from memory-lancedb-pro)
• Automatic memory consolidation (dreaming's light/deep/REM phases from memory-core)

Users currently have to choose one or the other, which defeats the purpose of the modular plugin architecture.

Thank you for considering this enhancement! This would significantly improve OpenClaw's memory system capabilities.