openclaw - 💡(How to fix) Fix [Bug]: Dreaming writes .txt files but memory_search only indexes .md — recallCount永远为0，promotion永远不触发

Bug Description

Dreaming system writes session corpus to .txt files, but memory_search only indexes MEMORY.md + memory/*.md. This creates a permanent disconnect: dreaming entries are never recalled during conversations, so recallCount stays at 0 forever, and deep-phase promotion (requiring recallCount ≥ 3) never triggers.

Environment

• OpenClaw version: 2026.5.16-beta.5 (5dab5ce)
• Node: v24.15.0
• OS: Windows 11 x64
• Memory backend: Builtin (SQLite + sqlite-vec)
• Embedding provider: OpenAI (nvidia/llama-nemotron-embed-1b-v2 via NVIDIA API)
• Dreaming config: enabled: true, frequency: "0 3 * * *" (default thresholds, no custom overrides)
• Memory search config: Only provider, model, queryInputType, documentInputType set. No extraPaths, no custom sources.

What We Observed

1. Dreaming runs daily, produces reports correctly

• 3 Agent workspaces (xue, baom, wechat) all have daily dreaming outputs
• memory/dreaming/{light,rem,deep}/YYYY-MM-DD.md files generated correctly
• DREAMS.md diary entries appended correctly
• memory/.dreams/session-corpus/*.txt files exist (10 files, May 10–19)

2. All short-term recall entries have recallCount = 0

xue:   942 entries, 0 promoted, all recallCount=0, all totalScore=0.58
baom:  228 entries, 0 promoted, all recallCount=0
wechat: 207 entries, 0 promoted, all recallCount=0

3. memory_search with corpus=memory returns 0 results for most queries

// Searching "OpenClaw 版本更新 mimo 修复"
{ "results": [], "hits": 0 }

// Searching "小雪 老板 对话"
{ "results": [], "hits": 0 }

But corpus=all finds results from the wiki bridge (memory-wiki plugin), not from memory corpus.

4. The .txt files are not indexed

From the builtin memory engine docs:

OpenClaw indexes MEMORY.md and memory/*.md into chunks

The dreaming corpus lives at:

memory/.dreams/session-corpus/2026-05-10.txt  ← .txt, NOT indexed
memory/.dreams/session-corpus/2026-05-11.txt  ← .txt, NOT indexed
...

While memory_search indexes:

MEMORY.md                   ← indexed ✓
memory/2026-05.md            ← indexed ✓
memory/dreaming/light/*.md   ← indexed ✓ (if glob matches)

5. The disconnect chain

Dreaming imports session transcripts → writes .dreams/session-corpus/*.txt
                                          ↓
memory_search only indexes MEMORY.md + memory/*.md → .txt excluded
                                          ↓
During conversations, memory_search never returns dreaming entries
                                          ↓
recallCount stays at 0 forever
                                          ↓
Deep phase: minRecallCount ≥ 3 never satisfied
                                          ↓
MEMORY.md never gets auto-promoted

Our Config (clean, no custom overrides)

{
  "plugins": {
    "entries": {
      "memory-core": {
        "config": {
          "dreaming": {
            "enabled": true,
            "frequency": "0 3 * * *"
          }
        }
      }
    }
  },
  "agents": {
    "defaults": {
      "memorySearch": {
        "provider": "openai",
        "model": "nvidia/llama-nemotron-embed-1b-v2",
        "queryInputType": "query",
        "documentInputType": "passage"
      }
    }
  }
}

No extraPaths, no custom sources, no storage mode overrides. This is default configuration behavior.

Related Issues

• #76737 (closed): recallCount always 0, short_term_recalls table missing — different root cause
• #74334 (closed): snippet normalization mismatch causing rehydration failure — different root cause
• #70104 (closed): REM corpus lock + signal pipeline not wiring — different root cause
• #71976 (open): light sleep sort order issue — related but distinct
• #71656 (open): corpus noise + flat scoring — related but distinct

Questions

1. Is this by design? Was the dreaming system intentionally designed to write .txt files that memory_search doesn't index? If so, how is recallCount supposed to accumulate?

2. Is this a regression? Did a recent change break the indexing of dreaming corpus files? Or has this never worked?

3. What's the intended architecture? Should:

   • (a) Dreaming write .md files instead of .txt?
   • (b) memory_search be extended to index .txt files?
   • (c) recallCount be driven by the dreaming system's own phase signals rather than memory_search hits?
   • (d) Something else entirely?

Suggested Investigation

# Verify the indexing gap
openclaw memory status --deep --agent xue
# Check: "Indexed: 25/25 files" — are the .txt corpus files included?

# Check what memory_search actually finds
openclaw memory search "MiMo 修复" --agent xue
# vs what we'd expect from 942 short-term recall entries

Impact

• Severity: High (feature silently broken)
• Scope: All 3 agents affected identically
• Duration: At least 10 days (May 10–19), likely since dreaming was first enabled
• User impact: Memory Palace empty, MEMORY.md never auto-updated, dreaming produces reports but no actionable promotion