Consolidate PredictionSnapshotStore + ScheduleStore into the unified per-day DailyView format

[johanzander]

Summary

Follow-up to #408 (HistoricalDataStore persistence). The "today" store landscape is still fragmented across four stores with three different persistence patterns:

Store	Persists?	Where
HistoricalDataStore	✅ (via #408, folded into DailyViewStore)	/data/daily_views/{date}.json
DailyViewStore	✅	/data/daily_views/{date}.json, one file/day
PredictionSnapshotStore	✅	/data/bess_prediction_snapshots.json
ScheduleStore (strategic intents)	✅	/config/bess_strategic_intents.json

PredictionSnapshotStore and ScheduleStore each still have their own bespoke JSON format and location (note /config vs /data inconsistency too), separate from the DailyView schema HistoricalDataStore/DailyViewStore now share.

Proposal

Fold PredictionSnapshotStore and ScheduleStore into the same DailyView-per-day file DailyViewStore already owns, the same direction #408 took for HistoricalDataStore — one file format, one persistence convention, instead of four.

Explicitly deferred from #408

Per the design spec (docs/superpowers/specs/2026-07-27-historical-data-store-persistence-design.md, "Out of scope" section):

Consolidating PredictionSnapshotStore and ScheduleStore into the same file/format. Explicitly deferred; this design is one step toward that end state, not the full migration.

Scope note

This is a bigger blast radius than #408 — touches ScheduleStore's optimization-result storage (used for schedule application, not just display) and PredictionSnapshotStore's snapshot-evolution tracking (used by the AI chat "predicted vs actual" comparisons), not just a display-layer store. Should get its own brainstorm/design pass before implementation, not a direct port of #408's plan.

Related

• fix: persist HistoricalDataStore to disk via DailyViewStore #408 — HistoricalDataStore persistence (the first step toward this)
• Quarterly schedule-update tick can be silently skipped when hardware retries run long, permanently dropping a period's actuals #403 — quarterly schedule-update tick can be silently skipped (unrelated root cause, but in the same code neighborhood)

[johanzander]

Revised approach — supersedes the Proposal section above

#490 attempted this and is being closed unmerged. It's worth recording why, because the cause was in this issue's framing, not just the implementation.

"One format" was read as "one file": both stores writing into daily_views/{date}.json under view / snapshots keys. That single choice forced everything else — a shared read-modify-write container, a process-wide lock, unique temp filenames plus stale-temp cleanup, a legacy flat-file fallback, cross-owner pruning, view-less husk files (and a savings_aggregator day_count fix to compensate), and a replay guard that skipped snapshot capture entirely. Net effect: ~6 behavioural changes and a doubling of daily write volume (~400 MB/day → ~800 MB/day, since each owner now rewrites the other's data on every tick) in exchange for a maintainability refactor.

Redoing it as three small steps instead:

1. Characterization tests for PredictionSnapshotStore. It's currently untested, which is exactly why Consolidate PredictionSnapshotStore into the unified per-day DailyView format #490 could accumulate behaviour changes unnoticed. Pure addition.
2. The actual refactor. Move _daily_view_from_dict / _period_data_from_dict out of prediction_snapshot.py into daily_view_builder.py, which owns the dataclasses they construct; both stores import from there. No storage changes. This is where the real maintainability win is — the fragmentation that hurt was three hand-rolled serializers, not three file paths.
3. Storage location, if still worth it. daily_views/{date}.snapshots.json beside {date}.json — separate files, same directory, same per-day lifecycle. No shared container, no lock, no wrapper (so DailyViewStore's format is untouched and needs no legacy fallback), no husk files, and retention is an unlink rather than a read-modify-write.

Explicitly out of scope for all three: replacing the midnight clear() with self-anchoring day rollover, and any change to snapshot capture during BESS_HISTORICAL_SEED_FILE replay. Both are behaviour changes; the rollover one may be an improvement but belongs on its own issue.

After step 2 most of this issue's actual pain is gone. Step 3 buys one directory for backup/disk-usage/clear-all plus matching retention semantics — real but modest, and a fair place to close this out if the churn isn't worth it. ScheduleStore consolidation remains deferred and needs its own design pass regardless.