- Refactored the `calculate_proxy_internal_load_7d` function to `calculate_proxy_internal_load_window`, allowing for dynamic day range input. - Introduced new functions for calculating training volume deltas and building fitness progress insights, enhancing user feedback on training metrics. - Updated the fitness dashboard to include new charts for quality sessions and load monitoring, improving data visualization. - Integrated these new metrics into the fitness dashboard overview, providing users with comprehensive insights into their training performance. - Streamlined the router to utilize the new chart-building functions, ensuring consistency and maintainability across the application.
2.6 KiB
2.6 KiB
Fitness-Dashboard (Layer 2b) – Abnahme & technische Zuordnung
Status: umgesetzt (Frontend + Backend)
Bezug: Issue #53 (Phase 0c) – Layer 1 → Layer 2b Bundle → UI nur Darstellung
Stand: 2026-04-19
Ziel
- Eine Fitness-Übersicht auf
/history(Tab Fitness), analog Körper/Ernährung — keine parallelen Berechnungen im Client für Layer 2b. - Single Source of Truth:
data_layer/activity_metrics(und Scores/Focus wie bei den Platzhaltern), identische Chart-Payloads wie die bestehenden Chart-Endpunkte A1/A2.
Backend
| Bestandteil | Pfad / Endpoint |
|---|---|
| Chart-Payloads (A1/A2) | build_training_volume_chart_payload, build_training_type_distribution_chart_payload in backend/data_layer/activity_metrics.py |
| KPI-Kacheln (Struktur für UI) | backend/data_layer/fitness_interpretation.py → build_fitness_dashboard_kpi_tiles |
| Bundle | backend/data_layer/fitness_viz.py → get_fitness_dashboard_viz_bundle(profile_id, days) |
| API | GET /api/charts/fitness-dashboard-viz?days=7…9999 in backend/routers/charts.py |
Hinweise:
days >= 9999wählt eine lange Historie für die Zusammenfassung (analog Ernährungs-Bundle).calculate_quality_sessions_pct(profile_id, days)unterstützt ein variables Fenster (wird auch vom Quality-Chart genutzt).
Frontend
| Bestandteil | Pfad |
|---|---|
| API-Client | getFitnessDashboardViz(days) in frontend/src/utils/api.js |
| Darstellung | frontend/src/components/FitnessDashboardOverview.jsx |
| Einbindung | frontend/src/pages/History.jsx → ActivitySection (gemeinsamer PeriodSelector wie die Liste darunter) |
| Erfassung | /activity bleibt reine Erfassung; Capture-Hub-Label Aktivität |
Erweiterungen (optional)
- Weitere Charts aus A5–A8 ins Bundle (Monotonie, Fähigkeiten …), gleiches Muster: Builder in
activity_metrics, Router nur delegieren.
Abnahme-Checkliste
- Bundle liefert u. a.
has_activity_entries,summary,kpi_tiles,progress_insights,volume_delta,charts.training_volume,charts.training_type_distribution,charts.quality_sessions,charts.load_monitoring,load_chart_days_used,meta. - Verlauf
/history→ Fitness: keine zweiten Charts/KPIs ausactivities-Liste (keine Redundanz zur Erfassungs-API). - Chart-Endpunkte A3/A4 nutzen dieselben Builder wie das Bundle (
build_quality_sessions_chart_payload,build_load_monitoring_chart_payload). calculate_proxy_internal_load_windowersetzt fehlerhaftendays=28-Aufruf an der alten 7-Tage-Funktion (chronische Last).