Ernährung: Zucker/Ballaststoffe/Lebensmittelqualität + automatisches Lebensmittelprofil #75

New Issue

Lars · 2026-04-11T19:22:04+02:00

Lars commented

2026-04-11 19:22:04 +02:00

Ausgangslage

Im Ernährungstagebuch stehen aktuell vor allem Energie (kcal), Protein, Kohlenhydrate, Fett sowie eine Bezeichnung des Lebensmittels.
Es fehlen strukturierte Daten zu Zucker, Ballaststoffen und Qualität der Lebensmittel (Nährwertdichte, Verarbeitungsgrad, o. ä.).
Im Backend existieren bereits Teilfunktionen/Platzhalter-Ideen (z. B. Fiber/Sugar-Avg in nutrition_metrics), ohne durchgängige Datenbasis im Log.

Ziel

Fachliches Datenmodell für fehlende Nährwert-/Qualitätsdimensionen (mind. Zucker, Ballaststoffe; optional weitere Kennzahlen).
Automatische Anreicherung („Lebensmittelprofil“) aus der erfassten Bezeichnung (Lookup/Matching gegen eine Lebensmittel-/Nährwertdatenbank oder API; Offline-Cache/Admin-Pflege beachten).
Einheitliche Nutzung in Layer 1 (Berechnungen), Charts und Platzhalter/Registry (keine parallelen Formeln).

Follow-up / spätere Ausbaustufe

Zeitliche Einordnung (Mahlzeiten, Uhrzeit) und Kombinationen von Lebensmitteln.
Abgleich mit sportlicher Aktivität (z. B. Timing von Kohlenhydraten/Protein relativ zu Training) – eigene Epics/Endpoints, sobald Mahlzeiten-Zeitstempel zuverlässig vorliegen.

Akzeptanz (grob)

Migration/Schema nur nach Projekt-Pattern (backend/migrations/).
Import/Erfassung bleibt abwärtskompatibel (bestehende Einträge ohne Profil weiterhin gültig).
Dokumentation in .claude/docs/issues/ bei größerem Umfang.

Angelegt aus Product/Architektur-Diskussion (Agent), 2026-04-11.

## Ausgangslage - Im Ernährungstagebuch stehen aktuell vor allem **Energie (kcal), Protein, Kohlenhydrate, Fett** sowie eine **Bezeichnung des Lebensmittels**. - Es fehlen strukturierte Daten zu **Zucker**, **Ballaststoffen** und **Qualität der Lebensmittel** (Nährwertdichte, Verarbeitungsgrad, o. ä.). - Im Backend existieren bereits Teilfunktionen/Platzhalter-Ideen (z. B. Fiber/Sugar-Avg in `nutrition_metrics`), ohne durchgängige Datenbasis im Log. ## Ziel 1. **Fachliches Datenmodell** für fehlende Nährwert-/Qualitätsdimensionen (mind. Zucker, Ballaststoffe; optional weitere Kennzahlen). 2. **Automatische Anreicherung („Lebensmittelprofil“)** aus der erfassten Bezeichnung (Lookup/Matching gegen eine Lebensmittel-/Nährwertdatenbank oder API; Offline-Cache/Admin-Pflege beachten). 3. Einheitliche Nutzung in **Layer 1** (Berechnungen), **Charts** und **Platzhalter/Registry** (keine parallelen Formeln). ## Follow-up / spätere Ausbaustufe - **Zeitliche Einordnung** (Mahlzeiten, Uhrzeit) und **Kombinationen** von Lebensmitteln. - **Abgleich mit sportlicher Aktivität** (z. B. Timing von Kohlenhydraten/Protein relativ zu Training) – eigene Epics/Endpoints, sobald Mahlzeiten-Zeitstempel zuverlässig vorliegen. ## Akzeptanz (grob) - Migration/Schema nur nach Projekt-Pattern (`backend/migrations/`). - Import/Erfassung bleibt abwärtskompatibel (bestehende Einträge ohne Profil weiterhin gültig). - Dokumentation in `.claude`/`docs/issues/` bei größerem Umfang. _Angelegt aus Product/Architektur-Diskussion (Agent), 2026-04-11._

Lars commented

2026-04-11 19:31:37 +02:00

Stand im Repo (2026-04-11, Agent)

Bereits umgesetzt (Kontext zu diesem Issue)

Ernährung Layer 1: Einheitliche TDEE-Regel (Gewicht × 32,5 kcal/kg), Bilanz und Mittelwerte über Kalendertag (Tages-Summen kcal / konsistente Aggregation), siehe backend/data_layer/nutrition_metrics.py und backend/routers/charts.py (Energiebilanz-/Protein-Timeline).
Platzhalter nutrition_score: jetzt in der Registry, Modul backend/placeholder_registrations/nutrition_score.py, Import in placeholder_registrations/__init__.py; Doppel-Eintrag im Katalog unter „Scores“ entfernt.

Bezug zu diesem Issue (#75)

Die hier gewünschten Dimensionen (Zucker, Ballaststoffe, Lebensmittelqualität, automatisches Lebensmittelprofil, später Mahlzeiten-Timing und Abgleich mit Training) sind bewusst noch offen und werden nicht durch die obigen Änderungen abgedeckt.
Nächster sinnvoller technischer Schritt laut Beschreibung: Schema/Migration für neue Felder oder verknüpfte Lebensmittel-Entitäten + Strategie Datenquelle (API vs. lokale Tabelle vs. Admin-Pflege).

Bei Rückfragen oder Priorisierung einfach kommentieren.

## Stand im Repo (2026-04-11, Agent) ### Bereits umgesetzt (Kontext zu diesem Issue) - **Ernährung Layer 1:** Einheitliche TDEE-Regel (**Gewicht × 32,5 kcal/kg**), Bilanz und Mittelwerte über **Kalendertag** (Tages-Summen kcal / konsistente Aggregation), siehe `backend/data_layer/nutrition_metrics.py` und `backend/routers/charts.py` (Energiebilanz-/Protein-Timeline). - **Platzhalter `nutrition_score`:** jetzt in der Registry, Modul `backend/placeholder_registrations/nutrition_score.py`, Import in `placeholder_registrations/__init__.py`; Doppel-Eintrag im Katalog unter „Scores“ entfernt. ### Bezug zu diesem Issue (#75) - Die hier gewünschten Dimensionen (**Zucker, Ballaststoffe, Lebensmittelqualität, automatisches Lebensmittelprofil**, später **Mahlzeiten-Timing** und **Abgleich mit Training**) sind **bewusst noch offen** und werden **nicht** durch die obigen Änderungen abgedeckt. - Nächster sinnvoller technischer Schritt laut Beschreibung: **Schema/Migration** für neue Felder oder verknüpfte Lebensmittel-Entitäten + Strategie Datenquelle (API vs. lokale Tabelle vs. Admin-Pflege). Bei Rückfragen oder Priorisierung einfach kommentieren.

Lars commented

2026-04-11 19:32:01 +02:00

Stand / nächster Schritt (Agent, 2026-04-11)

Ernährung Layer 1: TDEE aus weight_log + Tagesaggregation für Bilanz/Protein/Konsistenz; nutrition_score ist in der Registry; Legacy-Dopplung im Katalog zu nutrition_score im Resolver bereinigt.
Parallel: Modul Körper wird analog geprüft (17 Registry-Keys in body_metrics.py vs. PLACEHOLDER_MAP, Charts vs. Data Layer). Kleine Konsolidierung: Gewichts-Chart soll die bereits im Data Layer geladenen Serien nutzen (kein zweites weight_log-Query).
Dieses Issue bleibt Fokus Lebensmittelprofil / Makros erweitert (Zucker, Ballaststoffe, Qualität); Körper-Refactor ist kein Blocker dafür.

**Stand / nächster Schritt (Agent, 2026-04-11)** - Ernährung Layer 1: TDEE aus `weight_log` + Tagesaggregation für Bilanz/Protein/Konsistenz; `nutrition_score` ist in der Registry; Legacy-Dopplung im Katalog zu `nutrition_score` im Resolver bereinigt. - **Parallel:** Modul **Körper** wird analog geprüft (17 Registry-Keys in `body_metrics.py` vs. `PLACEHOLDER_MAP`, Charts vs. Data Layer). Kleine Konsolidierung: Gewichts-Chart soll die bereits im Data Layer geladenen Serien nutzen (kein zweites `weight_log`-Query). - Dieses Issue bleibt Fokus **Lebensmittelprofil / Makros erweitert** (Zucker, Ballaststoffe, Qualität); Körper-Refactor ist kein Blocker dafür.

Sign in to join this conversation.