openclaw - 💡(How to fix) Fix Design issue: Dreaming activeHours coupling confuses users; docs contradict config defaults

Summary

Issue #67397 was closed as COMPLETED, but the root design problem persists: Dreaming is architecturally gated by heartbeat.activeHours with no user-facing config to bypass it, leading to silent failures that contradict the documentation.

Evidence

• Docs (dreaming.md): Default example uses frequency: "0 3 * * *" (3 AM UTC), implying overnight runs are supported
• Config schema (memory-config.md): Only 3 user-facing dreaming keys: enabled, frequency, model. No ignoreActiveHours, no escape hatch
• Runtime behavior: Dreaming cron runs through heartbeat-runner, which unconditionally applies isWithinActiveHours() gate. If frequency falls outside the window → silent skip with error: quiet-hours
• User experience: User enables dreaming, configures it for 3 AM (per docs), sets activeHours to 08:00–22:00 (sensible for heartbeat notifications), then wonders why dreaming never runs

Root Cause

Dreaming is implemented as a managed cron job on top of the heartbeat-runner infrastructure. The heartbeat-runner applies activeHours universally because heartbeats are user-facing signals that shouldn't spam at 3 AM. But dreaming is pure background maintenance with zero user-facing output — it shouldn't be subject to the same gate.

Proposed Solutions (pick one)

Option A: Dreaming-specific activeHours config

Give plugins.entries.memory-core.config.dreaming its own optional activeHours key that defaults to 24/7 and overrides the heartbeat window.

Option B: Skip activeHours for managed background crons

Flag dreaming cron payloads as systemEvent: true or background: true and skip the heartbeat activeHours check for such crons. Heartbeat-runner already knows the difference; extend that logic to gate selection.

Option C: Docs + safe defaults

Update docs to reflect the coupling (e.g. "Note: dreaming frequency must fall within heartbeat.activeHours"), and change the default dreaming frequency from 0 3 * * * to something inside 08:00–22:00 (e.g. 0 9 * * *).

Impact

• Users who read the docs in good faith configure dreaming for 3 AM and then silently get zero runs
• No error message, no CLI warning, no UI indicator — just forever-silent skips
• The closed issue #67397 had this exact report but no fix was shipped

Workaround (current)

Move dreaming frequency to fall inside activeHours (e.g. 0 9 * * *). Semantically awkward but functional.