Dreaming: dayBucket uses file date instead of ingestion date, preventing dailyCount from growing and blocking short-term promotion

Summary

When dreaming ingests the same daily memory file across multiple days, dailyCount stays stuck at 1 instead of incrementing. This means signalCount (recallCount + dailyCount + groundedCount) never exceeds 1, which falls below the default minRecallCount=3 promotion gate — so no entries ever reach the scoring stage, and zero promotions result.

The #64068 fix (raising phase reinforcement for dreaming-only revisits) cannot help because all entries are filtered out by signalCount < minRecallCount before phase reinforcement is even computed.

Root cause

In dreaming-*.js, the recordShortTermRecalls call passes dayBucket: batch.day (the date represented by the file, e.g. "2026-04-11"), but the dedupe logic in short-term-promotion-*.js checks:

const dedupeSignal = Boolean(params.dedupeByQueryPerDay)
    && queryHashesBase.includes(queryHash)
    && recallDaysBase.includes(todayBucket);

Since both query (__dreaming_daily__:2026-04-11) and dayBucket (2026-04-11) are identical across ingestion sweeps, the same file re-ingested on a later day is treated as "already recorded today" and dailyCount is not incremented.

dayBucket should be the ingestion date (when the sweep runs), not the file date. The intent of dedupeByQueryPerDay is to prevent counting the same file twice within the same sweep, not to prevent counting it across different days.

Evidence

After enabling dreaming on 2026-04-11, I collected 1,675 entries over 4 days. 621 entries have recallDays spanning multiple days (e.g. ['2026-04-11', '2026-04-14']), yet zero entries have dailyCount > 1:

The recallDays array correctly tracks that the file was ingested on multiple distinct days, but dailyCount remains 1 because dayBucket is the file date, not the ingestion date.

Reproduction

1. Enable dreaming with default config (plugins.entries.memory-core.config.dreaming.enabled: true)
2. Have daily memory files from at least 2 different dates
3. Wait for 2+ dreaming sweeps (default: daily at 03:00)
4. Check memory/.dreams/short-term-recall.json: entries with multi-day recallDays will still have dailyCount: 1

Or trigger manually:

openclaw cron run <memory-dreaming-promotion-job-id>

Fix

Change dayBucket from the file date to the ingestion date in three locations in dreaming-*.js:

Location 1: ingestSessionTranscriptSignals

- dayBucket: batch.day,
+ dayBucket: formatMemoryDreamingDay(params.nowMs, params.timezone),

Location 2: ingestDailyMemorySignals

- dayBucket: batch.day,
+ dayBucket: formatMemoryDreamingDay(params.nowMs, params.timezone),

Location 3: seedHistoricalDailyMemorySignals

- dayBucket: entry.day,
+ dayBucket: formatMemoryDreamingDay(params.nowMs, params.timezone),

formatMemoryDreamingDay is already imported at the top of the file:

import { M as formatMemoryDreamingDay, ... } from "./dreaming-I-7PDomQ.js";

And both params.nowMs and params.timezone are available in all three function contexts.

After fix

With the fix applied, re-ingesting the same file on a new day uses a different dayBucket (the current date), so dedupeSignal is false and dailyCount increments normally:

After a few days, signalCount grows enough to pass minRecallCount=3, entries reach the scoring stage, and phase reinforcement from #64068 can actually take effect.

Version

OpenClaw 2026.4.14 (323493f) — also present in 2026.4.12

Related

• [Bug]: memory-core dreaming promotion always finds 0 candidates - recallCount never accumulates (normalized recall artifacts resets scores) #64068: Dreaming promotion — raised phase reinforcement for repeated dreaming-only revisits (workaround that depends on this bug being fixed to take effect)
• [Bug]: Light Sleep phase produces all candidates with confidence=0.00 #64599: Dreaming light-sleep — compute confidence from all short-term signals