Summary

• Problem: light dreaming could keep sending the same high-recall first-day memory into the Dream Diary generator after that memory was already written, so repeated sweeps kept producing the same "first day" narrative.
• Solution: make light dreaming read recent Dream Diary entries, expand the candidate pool before the phase limit, prefer snippets not already covered by recent diary history, and pass the current sweep day plus recent diary context into the narrative prompt.
• Latest review follow-up: readRecentDreamDiaryEntries() now treats unreadable optional DREAMS.md context as empty history, including permission/safe-read failures such as EACCES and EPERM, so light dreaming does not abort before staging/reporting.
• What did NOT change: public memory-core config, plugin SDK API, provider/model routing, DREAMS.md markers/file format, short-term recall store schema, append/dedupe cleanup commands, and the strict managed DREAMS.md write path are unchanged.
• Why it matters / User impact: later memories can reach Dream Diary snippets after repeated sweeps instead of the same early memory monopolizing the one-page input, and optional diary history can no longer stop light dreaming just because DREAMS.md is unreadable.

Fixes #83830

Maintainer-ready notes

• Fix classification: Root cause fix.
• Maintainer-ready confidence: High for the Linux/source-level memory-core behavior exercised here; external provider prose quality, desktop/mobile, and live channel behavior are not claimed.
• Patch quality notes: The latest follow-up is deliberately narrow: only optional diary prompt-context reads degrade to empty history on read/permission/safe-read errors. Managed DREAMS.md updates still go through the existing updateDreamsFile() path and still reject unreadable files.
• Architecture / source-of-truth check: Light snippet selection remains owned by extensions/memory-core/src/dreaming-phases.ts; prompt/DREAMS.md context remains owned by extensions/memory-core/src/dreaming-narrative.ts; shared path/read/write safety remains owned by extensions/memory-core/src/dreaming-dreams-file.ts.
• Out of scope: deleting or rewriting existing diary entries, semantic duplicate cleanup during append, provider/model output quality, recall persistence schema migration, public dreaming defaults, external channel behavior, and relaxing managed write safety checks.

Real behavior proof

• Behavior or issue addressed: A high-recall first-day memory that was already present in DREAMS.md previously won the light phase's limited snippet slot because selection sorted by recent recall time and recall count before the phase limit. The latest review finding covered the follow-up path: recent diary history is optional prompt context, but an unreadable DREAMS.md could abort the required light-dreaming path before staging/reporting.
• Real environment tested: Local Linux OpenClaw worktree at /media/vdc/code/ai/aispace/openclaw-worktrees/pr-91225, branch repair/pr-91225, latest HEAD 1eb48a6c6c311e2ba8325b0f7343a6ca3ebc5786. The latest proof uses real local filesystem permissions (chmod 000) through the production memory-core diary context reader and the production DREAMS.md update helper.
• Exact steps or command run after this patch:

TASK_WORKTREE="/media/vdc/code/ai/aispace/openclaw-worktrees/pr-91225" PNPM_CONFIG_VERIFY_DEPS_BEFORE_RUN=false corepack [email protected] --dir "/media/vdc/code/ai/aispace/openclaw-worktrees/pr-91225" exec tsx "/media/vdc/code/ai/aispace/openclaw-pr-91225-evidence/latest-head-diary-context-proof.ts" 2>&1 | tee "/media/vdc/code/ai/aispace/openclaw-pr-91225-evidence/latest-head-diary-context-proof.log"
PNPM_CONFIG_VERIFY_DEPS_BEFORE_RUN=false corepack [email protected] --dir "/media/vdc/code/ai/aispace/openclaw-worktrees/pr-91225" exec vitest run extensions/memory-core/src/dreaming-narrative.test.ts --hookTimeout 300000 --testTimeout 300000 2>&1 | tee "/media/vdc/code/ai/aispace/openclaw-pr-91225-evidence/latest-head-focused-vitest.log"

• Evidence after fix:

{
  "head": "1eb48a6c6c311e2ba8325b0f7343a6ca3ebc5786",
  "proofScope": "real local filesystem permissions through production memory-core diary context and DREAMS.md update helpers",
  "readableContext": {
    "returnedEntries": 1,
    "firstEntry": "The old routing memory stayed available for the next light sweep."
  },
  "unreadableOptionalContext": {
    "chmod": "000",
    "returnedEntries": 0,
    "lightDreamingContextContinuesAsEmptyHistory": true
  },
  "strictWritePath": {
    "chmod": "000",
    "rejectedCode": "EACCES",
    "writePathStillStrict": true
  }
}

RUN  v4.1.7 /media/vdc/code/ai/aispace/openclaw-worktrees/pr-91225

Test Files  1 passed (1)
     Tests  58 passed (58)
Duration  7.18s

Existing broader source-runtime proof from the earlier revision also showed the original diary-repeat fix: with light.limit=1, the old limit-first ranking selected the already-written first-day snippet with recallCount=4; after the patch, the production light sweep selected the later routing snippet as the memory fragment, kept the first-day text only as recent diary context, wrote the fresh candidate into the light block, and appended a new diary entry while preserving the existing first-day entry as history.

• Observed result after fix: Readable diary history is still returned for prompt continuity. When DREAMS.md exists but is unreadable on the local filesystem, readRecentDreamDiaryEntries() returns empty history instead of throwing, so light dreaming can continue. The same unreadable file still causes the managed write path to reject with EACCES, proving the optional prompt-context fallback did not loosen updateDreamsFile() safety.
• What was not tested: No long-running HTTP gateway listener, external provider/model prose-quality run, desktop/mobile environment, external channel, live transport, Windows ACL, WSL ownership, or Docker bind-mount ownership behavior was exercised. The latest proof is Linux/source-level and local-filesystem-level only.

Main sync conflict verification

• Conflict addressed: origin/main moved DREAMS.md path and locking helpers into dreaming-dreams-file.ts; this update keeps readRecentDreamDiaryEntries() on that source-of-truth by importing resolveDreamsPath() and readDreamsFile() instead of reintroducing private path/file helpers.
• Latest synced base: the branch was rebased onto current main before the latest follow-up fix; the current local PR head is 1eb48a6c6c311e2ba8325b0f7343a6ca3ebc5786.
• Observed result: focused memory-core narrative tests pass at latest head: Test Files 1 passed (1); Tests 58 passed (58).

Review findings addressed

• RF-001: The earlier ClawSweeper/Codex review did not complete and did not provide a source-level close action. This update refreshes the PR with current-head local proof and keeps the remaining decision to the next ClawSweeper/maintainer review rather than treating the incomplete bot run as a code finding.
• RF-002: The earlier ClawSweeper/Codex review did not complete and did not make a work-lane recommendation. The PR now supplies current-head focused tests and real local filesystem proof for the latest reviewer finding so the next review has concrete evidence to evaluate.
• RF-003: Addressed the reviewer finding from sallyom: unreadable optional DREAMS.md history now degrades to empty recent diary context for light dreaming, while the strict managed DREAMS.md write path remains unchanged and still rejects unreadable files.
• Earlier security-boundary follow-up: The recent diary prompt-context read uses the shared DREAMS.md helper and safe file-read boundary; symlinked and non-file DREAMS.md paths return empty recent diary context before target contents can reach buildNarrativePrompt().
• Earlier original-behavior follow-up: The light-dreaming selection fix is still covered by the existing production-path proof and regression tests for diary-history-aware snippet selection.

Regression Test Plan

• Target test file: extensions/memory-core/src/dreaming-narrative.test.ts, extensions/memory-core/src/dreaming-phases.test.ts, extensions/memory-core/src/short-term-promotion.test.ts.
• Scenario locked in: a real short-term recall store contains a high-count first-day snippet and a lower-count newer snippet, DREAMS.md already contains the first-day snippet, and a light dreaming sweep with limit=1 sends the newer snippet to the narrative prompt while keeping the first-day text only as diary history. The latest follow-up adds coverage that unreadable DREAMS.md prompt context resolves to empty history.
• Why this is the smallest reliable guardrail: the tests and local proof cover the owner selection boundary, prompt context boundary, real DREAMS.md read path, unreadable optional context, and unchanged strict write path without changing config/schema or relying on provider-specific prose output.

Merge risk

• Risk labels considered: session-state; security-boundary; compatibility; availability.
• Risk explanation: session-state applies because this changes which short-term memory snippets are staged into Dream Diary entries. Security-boundary applies because local DREAMS.md file shape and readability determine whether text may enter prompt context. Availability applies because unreadable optional diary history should not abort light dreaming. Compatibility risk is low because public config, file markers, store schema, plugin SDK API, provider routing, and append/dedupe commands are unchanged.
• Why acceptable: the latest follow-up catches read/permission/safe-read failures only inside readRecentDreamDiaryEntries(), where diary history is optional context. It does not change readDreamsFile() globally and does not relax updateDreamsFile(); proof shows the write path still rejects an unreadable DREAMS.md with EACCES.
• Out-of-scope boundary: this PR does not delete existing diary content, does not add semantic duplicate removal to appendNarrativeEntry(), does not change external provider/model behavior, does not migrate DREAMS.md or short-term recall state, does not change public dreaming defaults, and does not relax managed write safety checks.

Root Cause

• Root cause: the original failing chain was in the light dreaming source-of-truth boundary: runLightDreaming() sorted live short-term recall entries by lastRecalledAt and recallCount, sliced to the phase limit, and only then generated the diary prompt. Because Dream Diary had no feedback into that selection step, an early first-day memory that was repeatedly recalled could keep winning the limited input slot even after DREAMS.md already contained that same memory. The latest reviewer finding exposed a separate optional-context availability boundary: readRecentDreamDiaryEntries() could let an unreadable DREAMS.md abort light dreaming even though diary history is only prompt continuity context.
• Why this is root-cause fix: the selection fix moves the freshness decision to the source-of-truth phase selection boundary, before the limited snippet set is written and before the narrative prompt is built. The latest follow-up fixes the optional-context boundary at the only call site that needs degradation: readRecentDreamDiaryEntries() catches read/permission/safe-read failures and returns empty history, while leaving managed writes strict.
• Architecture / source-of-truth check: the source-of-truth owner is extensions/memory-core/src/dreaming-phases.ts for light snippet selection, extensions/memory-core/src/dreaming-narrative.ts for prompt/DREAMS.md context, and extensions/memory-core/src/dreaming-dreams-file.ts for shared DREAMS.md path/read/write safety. Public contract scope is narrow: no SDK/API/config/protocol/schema/default migration changed.