Eve-phase schemes are never pushed: the night before an event resolves as a no-event night #163

New issue

Open

opened 2026-09-26 08:32:42 +00:00 by claude-bot · 0 comments

claude-bot commented

2026-09-26 08:32:42 +00:00

Collaborator

Bug

With the eve phase enabled (globally via EVE_PHASE_ENABLED, or per event), the night before an event should show that event's eve scheme. It never does.

priority_resolver.get_events_for_date selects candidates with Event.start <= target_date <= Event.end. The eve night is event.start - 1, which fails that filter, so the night resolves as a no-event night and pushes the no-event default. phase_resolver.resolve_phase does handle target_date == event.start - timedelta(days=1), but its docstring says the "caller must ensure target_date is in [event.start-1 (if eve), event.end]", and no caller does.

It affects every path that resolves a night:

the on job
"Push now"
the calendar
the review summary and day plan (#149 / #162). The parity test there documents the current behaviour rather than changing it.

Found while building the shared day-plan resolver in #162.

Fix

Widen the candidate query to include events whose eve night is target_date (Event.start == target_date + 1) when eve is enabled for that event, globally or per event.
Priority: decide whether an eve should lose to any event that is actually active that night. Almost certainly it should: an eve is a preview, not the event. Encode that in resolve_active.
Do it inside get_events_for_date, so the day plan, the calendar and "Push now" all pick it up at once.
Tests: an eve night resolves to the eve scheme; an eve that overlaps another event's day loses to that event; eve disabled leaves behaviour unchanged. Update the #162 parity test's eve expectation.

Eve is off by default, which is presumably why nobody has seen this.

## Bug With the eve phase enabled (globally via `EVE_PHASE_ENABLED`, or per event), the night before an event should show that event's `eve` scheme. It never does. `priority_resolver.get_events_for_date` selects candidates with `Event.start <= target_date <= Event.end`. The eve night is `event.start - 1`, which fails that filter, so the night resolves as a **no-event** night and pushes the no-event default. `phase_resolver.resolve_phase` does handle `target_date == event.start - timedelta(days=1)`, but its docstring says the "caller must ensure target_date is in [event.start-1 (if eve), event.end]", and no caller does. It affects every path that resolves a night: - the on job - "Push now" - the calendar - the review summary and day plan (#149 / #162). The parity test there documents the current behaviour rather than changing it. Found while building the shared day-plan resolver in #162. ## Fix - **Widen the candidate query** to include events whose eve night is `target_date` (`Event.start == target_date + 1`) when eve is enabled for that event, globally or per event. - **Priority:** decide whether an eve should lose to any event that is actually active that night. Almost certainly it should: an eve is a preview, not the event. Encode that in `resolve_active`. - **Do it inside `get_events_for_date`,** so the day plan, the calendar and "Push now" all pick it up at once. - **Tests:** an eve night resolves to the eve scheme; an eve that overlaps another event's day loses to that event; eve disabled leaves behaviour unchanged. Update the #162 parity test's eve expectation. Eve is off by default, which is presumably why nobody has seen this.

claude-bot added this to the v1.2.0 milestone

2026-09-26 08:32:55 +00:00

claude-bot added the

labels

2026-09-26 08:33:11 +00:00

claude-bot referenced this issue

2026-09-26 08:52:17 +00:00