mitai-jinkendo/.claude/docs/functional/BLS_FOOD_REFERENCE.md
Lars a7e5511039
All checks were successful
Deploy Development / deploy (push) Successful in 1m1s
Build Test / pytest-backend (push) Successful in 8s
Build Test / lint-backend (push) Successful in 0s
Build Test / build-frontend (push) Successful in 29s
feat: Rezepte beim Zuordnen anlegen und offene Zutaten listen
Lebensmittel oder Rezept wählbar; gemappte Zutaten werden übernommen, offene erscheinen in der Liste. Dazu Fettgehalt-Suche, EPA-Stoffe, Rezept-CRUD und Wechsel bestehender Zuordnungen.

Co-authored-by: Cursor <cursoragent@cursor.com>
2026-09-12 16:59:24 +02:00

3.3 KiB

BLS-Lebensmittelreferenz und FDDB-Mapping

Stand: 2026-09-12 · Status: Phase 1 (Umsetzung)

WAS

Optionale Grundlage für verlässliche Nährwerte: offizieller Bundeslebensmittelschlüssel (BLS) 4.0 plus manuelle Katalogerweiterung, lernendes Mapping von FDDB-Bezeichnern, persistierte Tagebuchzeilen. Reine Tagesmakros bleiben First Class.

Zuordnung (UX)

Offene Zuordnungen zeigen Vorschläge in der Zeile (z. B. Haferflocken → Hafer Flocken); Bestätigen ohne Dialog. Mehrere nahe Treffer werden gekennzeichnet. Fehlt ein Treffer, Lebensmittel oder Rezept in derselben Zeile (oder im Such-Popup). Ein Lebensmittel wird ein Katalogeintrag. Ein Rezept bekommt Zutaten (Name + Gramm): schon zugeordnete Namen werden übernommen, offene Zutaten erscheinen danach in der Offene-Liste (Kennzeichnung „Rezeptzutat“) und lassen sich dort nur als Lebensmittel zuordnen. Nicht-Gramm-Einheiten (Stück, EL, TL, …) bekommen ein Gramm-pro-Einheit-Feld am Mapping. Vorschläge und Katalogsuche laufen nur für die sichtbare Arbeit, nicht über alle offenen Namen auf einmal. Die Offene-Liste startet bei den letzten 4 Wochen; ältere Namen (z. B. Getreide nach Glutenverzicht) bleiben unter „Alle“ und müssen nicht gemappt werden.

FDDB-Listen / eigene Rezepte

FDDB-Tagebuchexport fasst selbst angelegte Listen oft zu einer Zeile (Rezeptname + Menge) zusammen. Die Zutaten stehen in einem separaten Listen-Export (lists_*.csv, Spalte produkte). Ablauf: Listen importieren → passende Tagebuchzeilen werden als Rezept verknüpft → Zutaten zuordnen, nicht das Rezept als Ganzes. Unvollständige Zutaten-Mappings fallen auf die FDDB-Makros der Tagebuchzeile zurück.

Gelernte Zuordnungen und Listen lassen sich als JSON sichern und auf einer anderen Instanz (Dev → Prod) wieder einspielen. Offizielle Lebensmittel werden über den BLS-Code gefunden — der BLS-Katalog muss auf dem Ziel bereits importiert sein.

Fachliche Regeln

  • BLS-Code (bls_code, Stoff-attr_key) bleibt die stabile Identität bei Reimports.
  • BLS 4.0 (~7140 Lebensmittel) ist frei nutzbar (MRI / blsdb.de); Dateien nicht im Git.
  • Mapping ohne KI: Normalisierung + exakter Lookup (User vor Global) + Bestätigung neuer Namen.
  • Gelernte Zuordnungen bleiben dauerhaft, sind aber änder- und löschbar.
  • Ungemappte / Fertiggerichte: FDDB-Makros, keine erfundenen Mikros.
  • Fasten und „unvollständig“ sind explizite Marken, kein Auto-Schluss aus fehlendem Import.
  • Import-Policy (Profil): nachfragen / Katalog überschreiben / FDDB überschreiben / Makros behalten.

Manuelle Lebensmittel / Supplemente

Eigene Einträge (z. B. Norsan Omega-3 + EPA) speichern dieselben Stoffwerte wie BLS-Lebensmittel (food_attribute_values, immer pro 100 g). Beim Anlegen: Makros plus Suche nach weiteren Stoffen (EPA, DHA, Omega-3). Etikett „pro 8 ml“ → Portionsgröße in g angeben, Umrechnung auf 100 g erfolgt serverseitig. Einheit des Stoffs beachten (oft g, Etikett in mg: 1100 mg = 1,1 g). Fehlt ein Stoff im Katalog: Admin → Stoffe & Attribute.

Weitere Quellen (USDA, Schweizer Nährwertdatenbank) kommen später als zusätzliche Katalogherkunft, nicht als zweite Wertetabelle.

Später

Platzhalter (Registry) für Mikros, Esszeitpunkte (logged_at), Fasten; Bezug Gitea #106 (Grundlage) und #75 (Folge).