Summary

Memory-core dreaming phase reports are generated successfully, but Dream Diary narrative entries are not reliably appended to DREAMS.md. The narrative subagent path often times out before usable model output is available, leaving the human-facing dream diary stale even though the underlying dreaming sweep completed.

Observed behavior

Recent 3am dreaming runs completed successfully:

• 2026-05-02: memory-core: dreaming promotion complete (workspaces=3, candidates=30, applied=1, failed=0)
• 2026-05-03: memory-core: dreaming promotion complete (workspaces=3, candidates=30, applied=0, failed=0)

Phase report files are present/current under:

• memory/dreaming/light/YYYY-MM-DD.md
• memory/dreaming/rem/YYYY-MM-DD.md
• memory/dreaming/deep/YYYY-MM-DD.md

But DREAMS.md diary narratives are stale/incomplete:

• Main workspace diary tail was older than the latest phase files.
• Some workspaces had no recent diary entries even though phase files existed.
• Logs showed repeated narrative failures such as memory-core: narrative generation ended with status=timeout for light phase.

Diagnosis

The narrative timeout appears to be hardcoded:

const NARRATIVE_TIMEOUT_MS = 60_000;

in extensions/memory-core/src/dreaming-narrative.ts.

In the failing runs, narrative subagent setup consumed most/all of that budget before model output could be read. Example evidence from logs/transcripts:

• Narrative prep often took ~42–70s.
• bundle-tools alone often consumed ~32–39s, including repeated tool/MCP startup timeout warnings (notably cua-driver).
• By the time the subagent reached stream-ready, the parent waitForRun(... timeoutMs: 60000) was nearly expired or already expired.
• Some transcripts later contained assistant output after the parent path had already recorded timeout or produced no text, suggesting a race/settle issue as well.

Expected behavior

If phase reports are generated successfully, the optional Dream Diary narrative should either:

1. complete and append to DREAMS.md, or
2. fail with a clear, non-stale diagnostic without discarding late-but-successful narrative output.

Impact

This does not appear to break core memory promotion/recall. The phase outputs and promotion pass still run. The impact is mostly on the human-facing dream diary / reflective narrative layer, and on any downstream consumers that use DREAMS.md diary text as a source.

Proposed fixes

Possible fixes, in rough order:

1. Make the narrative timeout configurable, e.g. plugins.entries.memory-core.config.dreaming.narrative.timeoutMs, or at least raise the hardcoded default to ~180–240s.
2. Separate setup/tool-bundle timeout from model-output timeout, so slow tool loading does not consume the entire narrative budget.
3. For lightContext dreaming narrative subagents, avoid starting unavailable/irrelevant MCP tools, or cache tool-start failures so each narrative run does not pay the same ~30s cost.
4. Add a short settle/retry read after successful/late subagent completion before logging produced no text or deleting/ignoring the narrative session.
5. Add regression coverage around late narrative output and configurable timeout behavior.

Notes

The recurring warning memory-core: managed dreaming cron could not be reconciled (cron service unavailable) appears related but probably not causal: the managed cron exists and runs successfully. The diary append issue is specifically in the narrative-generation subagent path after the dreaming phases complete.