Bug Description

Summary: The short-term dreaming promotion step consistently reports candidates=0, applied=0, failed=0 across all workspaces. Inspection of .dreams/short-term-recall.json shows 1323 entries where every entry has recallCount: 0 and totalScore never exceeds 0.62 — both below the promotion thresholds (minScore=0.800 and minRecallCount=3).

Root Cause Hypothesis

The gateway log shows this sequence during each dreaming run:

memory-core: light dreaming staged 67 candidate(s) [workspace=.../workspace]
memory-core: REM dreaming wrote reflections from 1323 recent memory trace(s)
memory-core: normalized recall artifacts before dreaming (rewrote recall store)  ← ⚠️
memory-core: dreaming promotion complete (workspaces=5, candidates=0, applied=0, failed=0)

The normalized recall artifacts before dreaming (rewrote recall store) step appears to reset recallCount to 0 for all entries. Because this normalization runs on every dreaming cycle, recall counts can never accumulate between runs, making promotion permanently impossible.

Evidence

.dreams/short-term-recall.json inspection (1323 entries):

{
  "key": "memory:memory/2026-04-08.md:5:5",
  "totalScore": 0.62,
  "recallCount": 0,
  "dailyCount": 1,
  "groundedCount": 0
}

• Max totalScore across all 1323 entries: 0.62
• recallCount for every single entry: 0
• Promotion candidates meeting threshold (score >= 0.8 AND recallCount >= 3): 0

Full log excerpt (2026-04-09T17:45:00Z):

memory-core: light dreaming staged 67 candidate(s) [workspace=/Users/.../workspace]
memory-core: REM dreaming wrote reflections from 1323 recent memory trace(s)
memory-core: normalized recall artifacts before dreaming (rewrote recall store)
memory-core: light dreaming staged 72 candidate(s) [workspace=.../workspace-scout]
memory-core: REM dreaming wrote reflections from 386 recent memory trace(s)
memory-core: REM dreaming wrote reflections from 1116 recent memory trace(s)
memory-core: normalized recall artifacts before dreaming (rewrote recall store)
memory-core: dreaming promotion complete (workspaces=5, candidates=0, applied=0, failed=0)

Expected Behavior

• recallCount should persist and accumulate between dreaming cycles
• Entries that are repeatedly retrieved during memory searches should gradually reach promotion threshold
• Promotion should eventually write high-signal snippets into MEMORY.md or designated long-term memory files

Actual Behavior

• recallCount is reset to 0 on every dreaming run ("rewrote recall store")
• No entries ever reach the promotion threshold
• dreams/ directory shows no new promotions despite weeks of operation
• lastDurationMs for the dreaming cron is ~4ms (effectively a no-op)

Environment

• OpenClaw version: 2026.4.9 (build 0512059)
• Node.js: v25.9.0
• Platform: macOS Darwin 25.4.0 (arm64)
• memory-core config:

{
  "enabled": true,
  "config": {
    "dreaming": {
      "enabled": true,
      "frequency": "45 1 * * *"
    }
  }
}

Relation to Other Issues

• Related to [Bug]: memory-core plugin: Missing idempotencyKey property causes REM dreaming to fail #64003 (Missing idempotencyKey in REM dreaming)
• Related to Memory dreaming managed cron job deleted on gateway restart but never recreated #64043 (managed cron job deleted on restart)

The "normalization" resetting recallCount appears to be a separate, independent defect from both of the above.

Suggested Fix

In the normalizeRecallArtifacts (or equivalent) function, the normalization step should:

1. Preserve recallCount, dailyCount, groundedCount and cumulative score fields — only normalize structural/schema issues, not semantic state
2. If a schema migration is necessary, add a version guard to avoid re-normalizing already-normalized stores
3. The totalScore accumulation logic should not depend on recallCount alone; alternatively, lower or make the promotion threshold configurable