Design fuer g/kg + ml/l Konsolidierung in listShoppingList():
500 g + 1 kg Kartoffeln aus verschiedenen Rezepten → 1,5 kg.
- unit-consolidation.ts mit unitFamily + consolidate
- GROUP BY wechselt auf family-key (weight/volume/raw)
- formatQuantity auf toLocaleString('de-DE', ...) app-weit
- Migration 015: shopping_cart_check.unit_key → family-key,
bestehende Abhaks migriert, Duplikate dedupliziert
- Test-Coverage fuer alle Edge-Cases
Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
Tabellen-Konvention im Repo ist singular — siehe Code-Review-Findings
zu Task 1 (commit 543008b). Plan und Spec angeglichen damit weitere
Tasks nicht mit dem alten Plural arbeiten.
Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
Spec fuer zwei Hauptseite-Features aus Brainstorming am 2026-04-22:
1) Neue Sort-Option "Zuletzt angesehen" fuer "Alle Rezepte". Tracking
per Profil in neuer SQLite-Tabelle recipe_views, beim Laden der
Detail-Seite per Beacon (POST /api/recipes/[id]/view) gesetzt.
Server-Sort macht LEFT JOIN mit ORDER BY last_viewed_at DESC NULLS
LAST, alphabetischer Tiebreaker.
2) "Deine Favoriten" und "Zuletzt hinzugefuegt" auf-/zuklappbar.
Default offen, User-Wahl persistiert in localStorage pro Device.
Header als button mit Chevron + Count-Pill, slide-Transition.
"Alle Rezepte" bleibt nicht-collapsibel (Hauptliste).
Spec deckt Schema, API-Endpoint, DB-Layer, Markup-Pattern,
Reactive-Refetch bei Profile-Switch, Snapshot-Kompatibilitaet (rehydrate
muss profile_id mitbekommen), Test-Strategie und Reihenfolge.
Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
Neue Spec fuer das Einkaufslisten-Feature:
- Globale (haushaltsweite) Einkaufsliste, aus Rezepten der Wunschliste gefuellt
- Portionen zentral auf der Listen-Seite skalierbar
- Flache Aggregation via (LOWER(TRIM(name)), LOWER(TRIM(unit)))
- Abhaken persistiert, Cleanup manuell
- Header-Badge zaehlt nicht-abgehakte Zeilen
- Relayout der Wunschlisten-Karte: Action-Icons horizontal oben, Quell-Domain raus
- Kein Fuzzy-Matching, keine manuellen Eintraege (YAGNI fuer v1)
E2E-Tests erst nach Deploy.
Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
Random-Auswahl server-seitig nach AI-Call; description steht
nicht im Gemini-Schema, keine Halluzinationsflaeche.
Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
Design-Spec fuer Gemini-basierten Foto->Rezept-Import:
Kamera-Icon im Header, Extraktion auf Server, Editor-Prefill
ohne DB-Record, Foto wird nicht persistiert.
Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
Ergebnis des Brainstormings. Entscheidungen:
- Alle Rezepte + Bilder synchronisieren (~60 MB, ~200 Rezepte)
- SvelteKits eingebauter Service Worker, keine externe PWA-Abhängigkeit
- Hintergrund-Pre-Cache ohne Blocker, sichtbarer Fortschritt im
dezenten Sync-Indikator unten rechts
- Stale-While-Revalidate für Rezept-Daten, Cache-First für Shell+Bilder
- Schreib-Aktionen offline: proaktiver Check + Toast, keine Queue
- Neuer Admin-Tab "App" für Install-Button, Sync-Status, Reset
- Unit-Tests für Cache-Strategy/Diff, Playwright-E2E für Offline-Flows
Bereit für Nutzer-Review und anschließende Plan-Erstellung.
Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
