openclaw - 💡(How to fix) Fix [Bug] Dreaming promotion still blocked by minUniqueQueries=3 — 99.8% of entries have only 1 query hash

Bug Description

The memory-core dreaming promotion is still gated by minUniqueQueries=3 (default), which is practically impossible to reach because the dreaming pipeline reuses the same internal query hashes (__dreaming_daily__:YYYY-MM-DD and __dreaming_sessions__:YYYY-MM-DD) on every sweep. As a result, 99.8% of recall entries never accumulate unique query diversity, so promotion consistently reports Promoted 0 candidate(s).

Data from production (11749 entries)

Query hash distribution:

  1 hashes: 11730 entries (99.8%)
  2 hashes: 12 entries (0.1%)
  3 hashes: 4 entries (0.0%)
  4 hashes: 3 entries (0.0%)

Promotion gate breakdown:

Total entries: 11749
Score >= 0.8: 1534
Score >= 0.8 AND totalCounts >= 3: 690
Score >= 0.8 AND totalCounts >= 3 AND uniqueQueries >= 3: 7 (blocked)

Root cause

The dreaming pipeline generates daily signals using only 2 internal query hash patterns (__dreaming_daily__ and __dreaming_sessions__). With dedupeByQueryPerDay enabled, these collapse to effectively 1 hash per entry per day. Entries can have dailyCount=9 and totalScore=5.58, but still only 1 query hash — so they never pass minUniqueQueries=3.

The only entries that pass are those that happen to be hit by organic memory_search queries (which have different hashes). For pure dreaming-only setups, promotion is permanently stuck at 0.

Related

• #64068: original "promotion always finds 0 candidates" — closed as fixed but the uniqueQueries gate was not addressed
• #87630: Dreaming UI phase cards show dash instead of last run time

Suggested Fix

One of:

1. Use date-unique query hashes for each daily dreaming sweep (e.g. include a nonce so each day creates a new hash)
2. Lower the default minUniqueQueries to 1 or remove the gate for dreaming-only signals
3. Make minUniqueQueries configurable in the dreaming config schema