Goal
Break down the current monolithic app.py into smaller, focused modules while preserving dashboard behavior and data-source provenance.
Why
app.py currently mixes Flask app setup, API routes, update endpoints, request parsing, response shaping, and page routes. Recent performance work moved aggregation into dashboard/snapshot.py, but the route layer still carries enough responsibility that future token/source changes are harder to review safely.
Scope
- Keep behavior stable unless a sub-issue explicitly changes it.
- Preserve existing API contracts, source labels, token definitions, and simulated mode behavior.
- Prefer small, reviewable PRs over a single broad rewrite.
- Update tests with each behavior-preserving move so regressions are visible.
Proposed Sub-Issues
- Move dashboard API routes out of
app.py into a focused module or blueprint.
- Move local update/version routes and helpers out of
app.py.
- Centralize shared request parsing and response helpers.
- Extract large inline frontend JS/CSS only if route/template cleanup leaves the template as the next bottleneck.
Done
app.py is mostly Flask wiring and page route registration.- API/update route modules have clear ownership and tests.
- Existing review commands pass:
scripts/review.sh, unit tests, and py_compile.
Goal
Break down the current monolithic
app.pyinto smaller, focused modules while preserving dashboard behavior and data-source provenance.Why
app.pycurrently mixes Flask app setup, API routes, update endpoints, request parsing, response shaping, and page routes. Recent performance work moved aggregation intodashboard/snapshot.py, but the route layer still carries enough responsibility that future token/source changes are harder to review safely.Scope
Proposed Sub-Issues
app.pyinto a focused module or blueprint.app.py.Done
app.pyis mostly Flask wiring and page route registration.scripts/review.sh, unit tests, and py_compile.