openclaw - 💡(How to fix) Fix [Bug]: REM phase ignores light-sleep staged candidates — rescans full short-term store, recycling old high-scoring entries

Summary

REM phase does not consume the candidates staged by light sleep. Instead it re-ingests the entire short-term recall store independently and selects winners by accumulated recall history, causing old high-scoring entries to dominate REM output indefinitely while freshly staged light-sleep candidates are never promoted.

Environment

• OpenClaw: 2026.5.19
• OS: Linux (Ubuntu/Mint)
• Memory plugin: memory-core, local embeddings
• Dreaming phases enabled: light, REM, deep

Expected behaviour

Docs and third-party guides (dev.to, blink.new) describe the pipeline as sequential: Light → REM → Deep. Light stages candidates and records lightHits in phase-signals.json. REM is supposed to synthesise patterns from those staged candidates and add remHits. Deep ranks using the combined boost from both.

Actual behaviour

REM re-ingests all daily memory and session signals from scratch (duplicating light sleep's work), then calls selectRemCandidateTruths() against the full unfiltered short-term store with no reference to which keys were staged by light sleep.

Confidence scoring in calculateCandidateTruthConfidence() weights 45% on accumulated averageScore and 25% on recallStrength (log-scaled recallCount). Entries that have been recalled many times in previous sweeps consistently outscore newly staged candidates, which have only a single sweep of data.

Result: the same 2–3 high-recall entries surface in every REM report. phase-signals.json never accumulates lightHits on the new material because REM selects a different set entirely, so Deep never sees a combined light+REM boost on current candidates.

Observed symptom: REM reports show "No strong patterns surfaced" while staging the same recycled snippets for weeks; Light reports correctly stage rich, relevant new material that never advances.

Root cause (code references)

File: dist/dreaming-phases-Lvsoqrmb.js

• runRemDreaming() ~line 1751: reads all short-term recall entries, no filter by lightHits
• selectRemCandidateTruths() ~line 1596: filters only for non-promoted entries and 88% similarity dedup; no preference for light-staged keys
• calculateCandidateTruthConfidence() ~line 1589: averageScore * 0.45 + recallStrength * 0.25 + consolidation * 0.2 + conceptual * 0.1 — old high-recall entries permanently dominate new ones
• recordDreamingPhaseSignals() for light phase records lightHits on staged keys, but REM's independent selection means those keys rarely appear in REM's candidate set, so lightHits never pairs with remHits for deep ranking

Suggested fix

In runRemDreaming(), before passing entries to previewRemDreaming(), filter to entries whose key appears in phase-signals.json with lightHits > 0 from the current dreaming run. This restores the intended sequential hand-off without changing REM's scoring logic.

Reproduction

1. Enable all three dreaming phases
2. Have active daily memory notes with recent content
3. Run a full dreaming sweep
4. Observe: light report stages current material; REM report surfaces different, older entries
5. Repeat over several days — same entries recycle in REM regardless of new light-staged material

Related issues

• #80858 (empty placeholder promotion — downstream symptom of same disconnect)
• #77831 (session-corpus pollution — separate but also affects candidate quality)