Lars
bf84e3c2a5
- 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.
55 lines
2.6 KiB
Markdown
55 lines
2.6 KiB
Markdown
# 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 >= 9999` wä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
|
||
|
||
- [x] 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`.
|
||
- [x] Verlauf `/history` → Fitness: **keine** zweiten Charts/KPIs aus `activities`-Liste (keine Redundanz zur Erfassungs-API).
|
||
- [x] Chart-Endpunkte A3/A4 nutzen dieselben Builder wie das Bundle (`build_quality_sessions_chart_payload`, `build_load_monitoring_chart_payload`).
|
||
- [x] `calculate_proxy_internal_load_window` ersetzt fehlerhaften `days=28`-Aufruf an der alten 7-Tage-Funktion (chronische Last).
|