mitai-jinkendo/docs/issues/issue-fitness-dashboard-layer2b.md
Lars bf84e3c2a5
All checks were successful
Deploy Development / deploy (push) Successful in 51s
Build Test / pytest-backend (push) Successful in 4s
Build Test / lint-backend (push) Successful in 0s
Build Test / build-frontend (push) Successful in 17s
feat: enhance fitness dashboard with new metrics and insights
- 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.
2026-04-20 08:04:50 +02:00

2.6 KiB
Raw Blame History

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.pybuild_fitness_dashboard_kpi_tiles
Bundle backend/data_layer/fitness_viz.pyget_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.jsxActivitySection (gemeinsamer PeriodSelector wie die Liste darunter)
Erfassung /activity bleibt reine Erfassung; Capture-Hub-Label Aktivität

Erweiterungen (optional)

  • Weitere Charts aus A5A8 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 aus activities-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_window ersetzt fehlerhaften days=28-Aufruf an der alten 7-Tage-Funktion (chronische Last).