Bug type

Behavior bug (incorrect output/state without crash)

Beta release blocker

No

Summary

memory.dream.completed events record only file paths and line counts but carry no outcome field (success, failure, partial, timeout). Agent runs normalize terminal state through agent-run-terminal-outcome.ts (7 distinct reasons: completed, hard_timeout, timed_out, cancelled, aborted, blocked, failed), but dreaming phases have no equivalent. When a dreaming phase fails partway through, the failure is logged separately and the completion event is either never emitted or emitted without indicating partial success.

Steps to reproduce

1. Enable dreaming in openclaw.json with dreaming.enabled: true.
2. Set a short timeoutMs on a dreaming execution config (e.g., timeoutMs: 5000).
3. Trigger a deep dreaming phase that exceeds the timeout (e.g., large memory corpus).
4. Observe the memory.dream.completed event in the event log — it contains phase, lineCount, storageMode but no status or reason field.
5. Check logs: the timeout failure is logged separately (memory-core: dreaming promotion failed for workspace ...) but the event log has no record of the failure.

Expected behavior

The MemoryHostDreamCompletedEvent type should include an outcome field (e.g., outcome: "completed" | "partial" | "failed" | "timed_out") analogous to AgentRunTerminalOutcome.reason. This would allow:

1. Downstream consumers (status dashboards, doctor checks, health metrics) to distinguish successful from failed dreaming runs without parsing log text.
2. The cron system to record dreaming run outcomes consistently with agent run outcomes.
3. Recovery logic to identify partial runs and resume or retry them.

Actual behavior

MemoryHostDreamCompletedEvent (defined in src/memory-host-sdk/events.ts:58-66) has these fields only:

type MemoryHostDreamCompletedEvent = {
  type: "memory.dream.completed";
  timestamp: string;
  phase: MemoryDreamingPhaseName;
  inlinePath?: string;
  reportPath?: string;
  lineCount: number;
  storageMode: "inline" | "separate" | "both";
};

No status, reason, error, or outcome field. Failed dreaming runs are invisible in the event log.

OpenClaw version

2026.6.5

Operating system

macOS 15.4

Install method

pnpm from source

Model

N/A (dreaming system behavior, not model-specific)

Provider / routing chain

N/A

Logs

Evidence from source:

1. src/memory-host-sdk/events.ts:58-66 — MemoryHostDreamCompletedEvent type definition: no outcome/status field.
2. extensions/memory-core/src/dreaming-markdown.ts:111-119 — event emission: only phase, lineCount, storageMode are recorded.
3. src/agents/agent-run-terminal-outcome.ts:18-25 — AgentRunTerminalReason has 7 distinct terminal reasons that normalize agent run outcomes. Dreaming has no equivalent.
4. extensions/memory-core/src/dreaming-narrative.ts:960-962 — narrative generation failure is caught and logged but never recorded in the event: "Narrative generation is best-effort — never fail the parent phase."
5. extensions/memory-core/src/dreaming.ts:695 — failure is logged to console but not persisted in the event log: "memory-core: dreaming promotion failed for workspace ..."

Impact and severity

Affected: All users with dreaming enabled who rely on event logs for monitoring or diagnostics.
Severity: Medium (failures are invisible in structured event data; only visible in unstructured logs).
Frequency: Every failed or partial dreaming run.
Consequence: Doctor checks and status dashboards cannot distinguish successful from failed dreaming runs. Partial runs cannot be identified for retry. Health metrics based on event logs undercount failures.

Additional information

The DEFAULT_MEMORY_DEEP_DREAMING_RECOVERY_ENABLED = true config (in src/memory-host-sdk/dreaming.ts:45) is for memory recovery (re-promoting forgotten memories when health score drops below 0.35), NOT for crash recovery (resuming a dreaming phase that crashed mid-execution). These are fundamentally different recovery concerns.

The existing qa/maturity-scores.yaml (97K) tracks dreaming maturity scores but has no structured way to correlate them with run outcomes from the event log.