openclaw - 💡(How to fix) Fix Dream diary fallback exposes raw memory staging fragments

Bug

The dream diary feature (DREAMS.md) sometimes contains raw system data instead of diary prose — things like session identifiers, conversation summaries, or backup logs. These should never appear in the diary output.

Steps to reproduce

1. Have the dream diary feature enabled with a nightly cron that generates entries from memory fragments
2. Cause the diary generation to fail (LLM timeout, empty response, etc.)
3. The fallback handler writes the raw input fragments directly into DREAMS.md instead of skipping or using a placeholder

Expected behavior

If diary generation fails, the entry should be skipped or a generic placeholder written. Raw pipeline content should never reach the diary file.

Actual behavior

Raw memory staging fragments appear in DREAMS.md as diary entries. Example leaked content:

• Conversation Summary: 343 files copied, 30 MB on B2 so far
• Session: 2026-05-22 00:02:16 GMT+1: Session Key: agent:main:dashboard:...

Root cause

In the narrative generation code (dreaming-narrative-CLDLCd8U.js), the fallback function buildRequestScopedFallbackNarrative returns the first non-empty raw snippet from the input data:

function buildRequestScopedFallbackNarrative(data) {
  return data.snippets.map((v) => v.trim()).find((v) => v.length > 0)
    ?? (data.promotions ?? []).map((v) => v.trim()).find((v) => v.length > 0)
    ?? "A memory trace surfaced, but details were unavailable in this run.";
}

The snippets array contains pre-processing memory fragments (session metadata, conversation summaries, operational logs). When the LLM-generated narrative fails, these raw fragments are written directly to the diary instead of being filtered out.

Proposed fix

Change the fallback to never expose raw snippets:

function buildRequestScopedFallbackNarrative(data) {
  return "A memory trace surfaced, but details were unavailable in this run.";
}

Environment

• OpenClaw 2026.5.27 (27ae826)