feat(web): simplify dashboard and unify terminal theme

[erikarenhill]

Summary

• Reshape the dashboard around five clear destinations: Overview, Energy, Plan, History, and More.
• Make Power now default to the existing Flow visualization while keeping Values as the secondary table/list view.
• Add compact price, next-plan, today, savings, and fuse summaries without introducing duplicate polling paths.
• Unify the header, setup flow, Energy History, settings, components, and canvas charts around the neutral terminal-native palette.
• Preserve the latest master Energy History work: daily energy storytelling stays primary, source data remains optional, and past plan decisions live under Plan.
• Remove the redundant FTW header text and reset mobile scroll position when changing bottom destinations.

Why

The existing dashboard exposed useful data through competing cards, older blue-slate surfaces, and mixed navigation patterns. This pass reduces the number of simultaneous decisions, makes live power and the next safe action immediately legible, and gives the full product one consistent visual system without removing technical detail.

Impact

Users get a simpler default Overview, a compact current-price view, a plain-language plan summary, consistent dark/light themes, and a mobile navigation model that behaves like destination switching. Existing Flow and Values modes remain available, and the technical history/diagnostic views are retained behind contextual disclosures.

Validation

• npm test — 134 tests passed.
• make verify — Go, Python optimizer, E2E, Compose migration/boundary checks, vet, and build passed.
• Headless Chrome QA — desktop/mobile, dark/light, all five routes, Flow default, Values persistence, /setup, mobile scroll reset, and overflow/page-error checks passed.
• Raspberry Pi field validation — deployed ARM64 build v1.10.5-33-g127fa25 with the matching web bundle, verified against real data; service remained healthy with zero restarts and no startup errors.

[miravoss26]

Big but well-contained web pass. Two things going on: (1) theme unification, web/components/theme.css becomes the single palette authority and the legacy light-DOM tokens are aliased onto canonical roles, with a small shared runtime (theme-runtime.js) resolving CSS colors for the canvas components; (2) two isolated behavior changes, a persisted hero-mode toggle in power-now.js and a new mobile-navigation.js scroll-reset module. 39 files, and each behavior change ships with a test. CI is green on web and go test/vet (Go/optimizer/drivers correctly path-skipped).

Security screen: clean. The only storage write is a UI mode string in localStorage (ftw-hero-mode), no credentials. The http://127.0.0.1 / local-IP curl lines are in the design-doc verification steps, not runtime code. No innerHTML/eval, no new network destinations, no secrets.

Correctness read: the two behavior modules are defensively written. initPowerNow wraps every storage access in try/catch (private-browsing safe) and no-ops if the expected DOM isn't present; the stored/normalized mode names round-trip consistently. initMobileDestinationScroll feature-checks closest, guards on nav.contains, and returns a listener-cleanup fn. No issues from my read.

The rest is CSS token remapping, which a diff can't fully validate: the one thing that needs human eyes is the visual outcome (light/dark, 390px mobile), since CI can't judge whether the theme intent actually landed. The design docs + design-pass.json are in the PR to check against. Safe to merge from my read once someone has eyeballed the rendered result.

[miravoss26]

Read the diff (large, but it's a contained frontend pass: theme-token unification + dashboard simplification across web/*.js, *.css, plus design docs and tests).

• Scope matches the claim: theme.css stays the single palette authority, legacy tokens are aliased onto canonical roles, and the two behavior changes are isolated in power-now.js and the new mobile-navigation.js module. Good that both ship with tests (*.test.mjs) and CI is green.
• Security screen: nothing of concern. No eval/new Function, no innerHTML sinks on untrusted data, no fetch to new external hosts, no secrets. The only localStorage use is UI state in power-now.js (injectable via a storage param, nice for testing). The http://127.0.0.1 / 192.168.1.139 URLs are all local-dev steps inside the design docs, not runtime calls.

Safe to merge from my read. Risk here is visual regression, not correctness. the theme-runtime + snapshot tests cover the token wiring, so I'd let those + a quick dark/light eyeball be the gate.