🦞 Issue: Dreaming Promotion — Cron-triggered memory entries saturate ranking, blocking real session recalls

Repository: openclaw/openclaw
Version: 2026.4.26 (be8c246)

Bug Description

The dreaming promotion system (memory promote) consistently produces 0 promotions despite having numerous candidates with genuine recall signals. The root cause is that cron-triggered daily recall counts (dailyCount) saturate the ranking, crowding out entries that were genuinely recalled in real user sessions (recallCount).

Environment

OpenClaw: 2026.4.26 (be8c246)
Memory store: ~/.openclaw/workspace/memory/.dreams/short-term-recall.json
Recall store entries: 5830
Recall total signal count: 130 (recallCount) + heavy dailyCount from cron
Promoted: 9 (historical)
Dreaming: enabled, frequency="0 3 * * *"

Steps to Reproduce

1. Set up daily cron jobs (e.g., 07:40 greeting, 03:00 dreaming trigger)
2. Use the system for several weeks — real conversations generate meaningful memory signals
3. Observe that openclaw memory promote returns 0 promoted entries

Technical Details

Data Flow Analysis

Observed Data

short-term-recall.json has real recall data:

memory:memory/2026-03-31.md:44:85   → recallCount=7,  dailyCount=0
memory:memory/2026-03-31.md:77:111  → recallCount=11, dailyCount=0
memory:memory/2026-04-13.md:240:264  → recallCount=10, dailyCount=0
memory:memory/2026-04-14.md:115:137  → recallCount=10, dailyCount=0

But openclaw memory promote top-10 ranking results:

Rank  1: recallCount=0, dailyCount=7, score=0.910  ← cron-saturated
Rank  2: recallCount=0, dailyCount=7, score=0.910  ← cron-saturated
...
Rank 15: recallCount=7, dailyCount=0, score=0.864  ← real recall, excluded from top-10

phase-signals.json shows all-zero recallCount (only lightHits/remHits populated). This file appears to only track dreaming-phase signals, not actual session recalls.

Promoted count in each store:

• phase-signals.json total recallCount: 0
• short-term-recall.json total recallCount: 130
• These two stores are NOT synchronized.

Threshold Configuration

minScore: 0.8
minRecallCount: 3        ← requires recallCount ≥ 3
minUniqueQueries: 3
recencyHalfLifeDays: 14
limit: 10

Hypothesis

1. Root cause: Cron jobs (daily greeting, health check, etc.) run every day and generate persistent dailyCount signals. These cron-triggered entries accumulate high dailyCount (e.g., 7 consecutive days) and dominate the top-10 ranking by score.

2. Contributing factor: recallCount entries (real session recalls) have dailyCount=0, so their combined score is lower, placing them outside the top-10 window.

3. The two stores may be used differently: phase-signals.json tracks dreaming-phase signals (lightHits/remHits) while short-term-recall.json tracks actual session recalls. If the promotion logic reads from phase-signals.json for recallCount, it would see all zeros.

Expected vs Actual Behavior

Proposed Fixes (for discussion)

1. Separate ranking tracks: Distinguish cron-triggered (dailyCount) vs session-triggered (recallCount) in the scoring formula — e.g., apply a penalty to purely cron-sourced entries or cap dailyCount contribution.

2. Increase limit: From 10 to 50+ so that high-recallCount entries below the top-10 cut-off can still be promoted.

3. Add dailyCount cap: Cap dailyCount contribution after N days to prevent cron刷屏 (e.g., max 2 days of cron signal).

4. Separate promotion source: Ensure recallCount is read from short-term-recall.json (which has real data) rather than phase-signals.json (which appears to only track dreaming-phase hits).

Workaround

# Manually run promotion with lower thresholds
openclaw memory promote --agent main --apply --limit 20

# Or disable daily cron tasks that poll memory (recommended workaround)
openclaw cron list

Additional Context

• openclaw memory status --deep shows: recall store: 5830 entries · 9 promoted
• short-term-recall.json updated: 2026-04-28T19:00:45.081Z
• phase-signals.json updated: 2026-04-28T19:00:00.483Z
• No lock files present; promotion not blocked