Battery chart shows doubled/incorrect data at today/tomorrow midnight boundary

[johanzander]

Description

Between ~23:45 and 00:00, the Battery SOC and Energy Flow chart shows doubled/overlapping data right at the today/tomorrow divider, instead of a clean split.

Root cause (identified via debug bundle analysis)

Once per evening, BESS Manager runs a standalone "prepare next day" optimization that stores a schedule anchored at tomorrow 00:00 with optimization_period = 0. Until midnight actually rolls over, core/bess/daily_view_builder.py (build_daily_view, ~lines 109-130) uses this schedule to fill in the remaining future periods of today:

predicted_index = i - optimization_period   # daily_view_builder.py:128

This assumes optimization_period always anchors the stored predicted_periods to today. That's false for the standalone next-day schedule — its period_data[0] is tomorrow 00:00, not today 00:00. So today's tail periods (e.g. period 95 / 23:45) get filled with tomorrow's period 95 (tomorrow 23:45) data instead of today's actual forecast for that slot.

backend/api.py (~lines 702-711) already has an is_next_day_only guard for exactly this case, applied when building tomorrow_data (from commit 9ca5b8b, issue #173/#287 fix). That guard was never applied to daily_view_builder.build_daily_view, which has no equivalent check when computing predicted_index for today's remaining periods.

Evidence

Debug bundle docs/bess-debug-2026-07-23-235706.md (export 2026-07-23 23:57:02, during the nightly "prepare next day" window):

• The stored schedule has optimization_period: 0 and period_data[0].timestamp = "2026-07-24 00:00:00+02:00" — confirmed tomorrow-anchored schedule.
• period_data[95] (timestamp 2026-07-24 23:45:00+02:00) has battery_action=-0.4875, battery_soe_start=3.5131578947368434, battery_soe_end=3.0000000000000013, shadow_price=2.1071249999999924.
• Today's rendered period at 23:45 (period index 95) shows the identical values to 13 decimal places — i.e. tomorrow's 23:45 data is being rendered as today's 23:45 data, while tomorrow's actual data for that same slot is also rendered correctly elsewhere — hence the visual doubling.

Fix location

core/bess/daily_view_builder.py:109-130 needs the same next-day-anchor detection/correction that backend/api.py:702-711 already implements for tomorrow_data, applied when computing predicted_index for today's remaining periods.

Attachments

Debug bundle available locally at docs/bess-debug-2026-07-23-235706.md (not attached here — contains system data).

[johanzander]

Scope expanded after design review: the underlying bug is fragile period_index - optimization_period arithmetic used to index into a stored schedule's period_data, which silently breaks whenever a schedule isn't anchored the way the caller assumes (e.g. the prepare_next_day schedule has optimization_period=0 but period_data[0] is tomorrow 00:00). This same pattern, unguarded, also affects two live-control paths (battery_system_manager.py:1636 strategic-intent recovery, battery_system_manager.py:2543 discharge-rate shadow-price lookup) and a second dashboard endpoint (backend/api.py ~1719), not just the chart.

Fix: replace all positional-arithmetic lookups with a timestamp-based lookup (ScheduleStore.get_period_data_at(timestamp)), since every PeriodData already carries its real timestamp — removing the anchor-assumption class of bug entirely rather than patching it a third/fourth time. Will include regression tests covering the 23:55-00:00 window specifically.