Summary
Once tomorrow's real day-ahead prices enter the optimization horizon, the DP correctly plans a full 2-day (192-period) schedule — but the dashboard's "Net Cost" figure only reflects today's slice of that plan. When the plan correctly redirects value to a better price tomorrow (e.g. holding a reserve overnight because tomorrow's evening peak pays more, or because it needs less grid import), today's Net Cost necessarily looks worse, with no visibility into the larger gain landing on the following day.
Evidence
Reported by Frank (#126, #275) as "Net Cost dropped from -0.80 EUR to -0.15 EUR" the moment prices_tomorrow arrived and the horizon extended to 48h. Investigated in #275/#276/#285 (see docs/superpowers/specs/2026-07-12-issue-275-root-cause-investigation.md for full methodology) — the underlying battery decision was verified financially optimal (beats the alternative by 0.756 EUR over 48h on Frank's own real data, confirmed via the actual hardware simulator, not just planning numbers). The "loss" was never real; it's an artifact of the dashboard only summing today's periods:
Today-only slice of the 2-day plan: +1.459 (looks like a loss)
Tomorrow-only slice (not shown anywhere): -1.513 (the actual gain)
True 48h total: -0.055 (net profit)
Proposed fix
When the optimization horizon spans more than today (i.e. prices_tomorrow is present and the DP is running a 2-day plan), the dashboard should show the plan's total value across the full horizon it actually optimized over — not just today's slice — so a decision that correctly defers value to tomorrow doesn't look like a regression. Needs product/UX input on exactly how to present this (e.g. a "Today" vs "Full plan (2 days)" toggle, or an explicit "includes X EUR expected tomorrow" annotation) rather than just changing the number silently.
References
Summary
Once tomorrow's real day-ahead prices enter the optimization horizon, the DP correctly plans a full 2-day (192-period) schedule — but the dashboard's "Net Cost" figure only reflects today's slice of that plan. When the plan correctly redirects value to a better price tomorrow (e.g. holding a reserve overnight because tomorrow's evening peak pays more, or because it needs less grid import), today's Net Cost necessarily looks worse, with no visibility into the larger gain landing on the following day.
Evidence
Reported by Frank (#126, #275) as "Net Cost dropped from -0.80 EUR to -0.15 EUR" the moment
prices_tomorrowarrived and the horizon extended to 48h. Investigated in #275/#276/#285 (seedocs/superpowers/specs/2026-07-12-issue-275-root-cause-investigation.mdfor full methodology) — the underlying battery decision was verified financially optimal (beats the alternative by 0.756 EUR over 48h on Frank's own real data, confirmed via the actual hardware simulator, not just planning numbers). The "loss" was never real; it's an artifact of the dashboard only summing today's periods:Proposed fix
When the optimization horizon spans more than today (i.e.
prices_tomorrowis present and the DP is running a 2-day plan), the dashboard should show the plan's total value across the full horizon it actually optimized over — not just today's slice — so a decision that correctly defers value to tomorrow doesn't look like a regression. Needs product/UX input on exactly how to present this (e.g. a "Today" vs "Full plan (2 days)" toggle, or an explicit "includes X EUR expected tomorrow" annotation) rather than just changing the number silently.References
docs/superpowers/specs/2026-07-12-issue-275-root-cause-investigation.md— full methodology and numbers