Dreaming REM phase stuck on stale corpus; phase signals not propagating from light → REM → deep

[manic pivot]

Version: 2026.4.15-beta.1 (489404d) | Linux WSL2, systemd

Summary:
Dreaming has been running nightly since 4/17. Light sleep works correctly each night — stages candidates from daily memory files and session transcripts. But REM and deep sleep are broken: REM references a stale corpus (stuck on 4/16 every night), phase signals aren't accumulating, and deep sleep promotes 0 candidates every run.

Evidence:
phase-signals.json only has entries from memory/2026-04-17.md (lightHits: 2, remHits: 0). Nothing from 4/18–4/21 accumulates despite 4+ successful sweeps. REM output for every night since 4/17 cites session-corpus/2026-04-16.txt as its evidence source — never advances.

Deep sleep result every night:

- Ranked 2 candidate(s) for durable promotion.
- Promoted 0 candidate(s) into MEMORY.md.

Expected: REM builds from current night's light phase output. Phase signals accumulate across sweeps until candidates cross minRecallCount/minUniqueQueries thresholds.

Actual: Signal pipeline between light → REM → deep is not wiring up. Light ingests correctly but nothing ever graduates.

Config:

"dreaming": { "enabled": true },
"shortTermPromotion": { "enabled": true, "limit": 10, "minScore": 0.800, "minRecallCount": 3, "minUniqueQueries": 3 }

Multiple sessions/day (direct chat + isolated cron sessions). Session transcripts indexed, daily-ingestion.json shows 5 files tracked (4/16–4/20). Memory search working fine.

[mint copper]

To help others find answers, you can mark your question as solved via Right click solution message -> Apps -> ✅ Mark Solution

[visual yew]

I’m checking the docs and source now, this does smell like a real bug rather than a config mistake.

I found a repair path in current source too, so I’m checking whether this lines up with a known dreaming-artifacts/state bug versus just thresholds being too strict.

Yeah, this looks like a real bug or stuck derived state, not a config mistake.

Two useful bits from the current code:

• phase-signals.json only boosts score a little. It does not increment minRecallCount or minUniqueQueries.
• Ranked 2 candidate(s) ... Promoted 0 specifically means deep found candidates, but the apply step could not rehydrate them from the live source files anymore, or filtered them as contaminated.

So I think you have two separate problems:

1. REM/session corpus is pinned to stale derived data (session-corpus/2026-04-16.txt, session-ingestion.json, maybe phase-signals.json).
2. Deep is ranking candidates whose provenance no longer rehydrates cleanly, which is why it ranks 2 but writes 0.

Also, I checked 489404d, and that build already has the 4/15 dreaming dayBucket fix. So this is less “missing patch” and more “stale/bad dream state” or a remaining regression.

Safest recovery

Move aside these derived files and let dreaming rebuild them on the next sweep:

• memory/.dreams/session-corpus/
• memory/.dreams/session-ingestion.json
• memory/.dreams/phase-signals.json

I would leave memory/.dreams/short-term-recall.json alone for now, unless you want a full reset.

Quick checks first

If you want to confirm before resetting, these are the most useful:

openclaw memory rem-harness --json
openclaw memory promote --json
openclaw memory status --deep --json

If promote --json shows candidates pointing at stale session-corpus/2026-04-16.txt paths, that’s basically the smoking gun.

Docs

• https://docs.openclaw.ai/concepts/dreaming
• https://docs.openclaw.ai/cli/memory
• https://docs.openclaw.ai/gateway/doctor

If resetting those derived dreaming files does not fix the next sweep, I’d file it as a bug here with your evidence plus the 3 JSON outputs above:

• https://github.com/openclaw/openclaw/issues

If you want, paste the rem-harness --json and promote --json outputs here and I’ll help narrow it down further.

[manic pivot]

I moved aside the derived files and let memory run as you suggested, but the newly regenerated files still are pinned to the old corpus (4-16).

[visual yew]

That’s really helpful, and it narrows it down a lot.

If a full derived-state reset still regenerates 4/16, then the problem is probably upstream of REM/deep, in session transcript ingestion/bucketing itself.

What I think is happening from the code:

• dreaming buckets session corpus by the message timestamp when it can
• otherwise it falls back to the transcript file time
• so if regenerated corpus is still all 2026-04-16.txt, then either:
  1. the transcript records for later messages are still carrying a 4/16 timestamp, or
  2. dreaming is only seeing an old 4/16 session file / wrong agent session set

So at this point I would stop treating this as “stale artifacts” and treat it as a real regression.

Best next checks

Please grab these, if you can:

openclaw memory rem-harness --json
openclaw memory promote --json
openclaw status --all

And if possible, also share a redacted sample of one recent session transcript record for a message sent after 4/16, specifically its timestamp fields.

Very useful A/B test

Start a brand-new chat/thread/session, send a couple test messages, then let dreaming sweep once.

• If that creates session-corpus/<today>.txt, the bug is probably tied to long-lived session timestamping
• If it still goes to 2026-04-16.txt, then dreaming is likely reading the wrong session source / wrong agent mapping

My recommendation

Since you already tried the safe rebuild and it still repros, I’d file this as a bug now: