Bug Description

The managed dreaming cron job created by memory-core at startup does not actually trigger the dreaming promotion logic. The cron runs but completes in ~4ms with deliveryStatus: "not-requested" — it appears to do nothing.

Steps to Reproduce

1. Install openclaw v2026.4.5
2. Enable dreaming: openclaw config set plugins.entries.memory-core.config.dreaming.enabled true
3. Ensure plugins.slots.memory is NOT explicitly set (default behavior)
4. Restart gateway: openclaw gateway restart
5. After restart, observe: openclaw cron list shows managed "Memory Dreaming Promotion" cron job
6. Wait for cron to trigger (or manually trigger: openclaw cron run <job-id>)
7. Check: openclaw cron runs --id <job-id> shows status: ok, durationMs: 4, deliveryStatus: "not-requested"

Expected: dreaming promotion runs for ~30-60 seconds, scans short-term recall, promotes memories
Actual: 4ms, nothing happens

Root Cause Analysis

In dreaming-CnlsXIYM.js, registerShortTermPromotionDreaming() registers a before_agent_reply hook:

api.on("before_agent_reply", async (event, ctx) => {
  return await runShortTermDreamingPromotionIfTriggered({...});
});

When the cron triggers, it sends a system-event to session: main. However:

• system-event delivered to session → session does NOT generate a reply
• before_agent_reply hook only fires when there IS a reply
• Without a reply, the hook never runs → 4ms completion time
• The deliveryStatus: "not-requested" confirms no agent turn was created

Workaround

Use session: isolated instead of session: main with an explicit message:

openclaw cron add \
  --name "Memory Dreaming" \
  --cron "0 9 * * *" \
  --tz "Asia/Shanghai" \
  --message "Please run the memory dreaming promotion flow..." \
  --session isolated \
  --timeout-seconds 300 \
  --no-deliver

With this workaround, the cron properly triggers an isolated agent turn that executes the dreaming logic (~59 seconds).

Environment

• macOS 26.4 (arm64)
• Node v25.9.0
• OpenClaw v2026.4.5
• memory-core plugin

Additional Context

The same cron job created manually with --system-event + --session main exhibits identical broken behavior (4ms, no action). This confirms the issue is in how memory-core's managed cron delivers its trigger to the session, not in the cron system itself.

Logs from manual trigger:

action: "finished"
status: "ok"
durationMs: 4
deliveryStatus: "not-requested"
summary: "__openclaw_memory_core_short_term_promotion_dream__"

vs. workaround (isolated session):

action: "finished"
status: "ok"  
durationMs: 58685
deliveryStatus: "not-delivered"
summary: "梦境巩固完成..."