recipe-app/flutter/next_steps_flutter.md

Senaste ändringar (2026-04-24)

Arkitektur- och UX-förbättringar:

• Grid-vy för recept: Kolumnval (2/4/6/8) via ikon i AppShell, med Riverpod-provider och SharedPreferences.
• RecipesScreen är nu body-only, ingen egen Scaffold/AppBar.
• AppShell visar grid-ikon endast på /recipes.
• Buggfix: Produktväljaren i pantry/inventarie (ProductPickerField) — bottenark implementeras.
• Sprint 2: Databas > Produkter visar nu en riktig adminpanel i profilflödet med sök, okategoriserat-filter och bulk-kategorisering.
• Sprint 2: Användare-fliken stödjer nu Premium av/på direkt från användarmenyn.
• Kodkvalitet: Inga absoluta Windows-sökvägar.
• Dokumentation och next_steps uppdaterade.

Nästa steg: Flutter-migrering

Relaterade dokument:

• README.md
• teknisk_beskrivning_flutter.md

Mål och prioriteringar för produktion

Övergripande mål

• Funktionell parity: Säkerställa att alla kärnfunktioner är stabila och fungerar som förväntat.
• Användarupplevelse: Förenkla onboarding och säkerställa att användare snabbt förstår appens värde.
• Produktionsklar: Säkerställa att appen är redo för lansering genom att adressera kritiska buggar och förbättra prestanda.

Icke-förhandlingsbara ramar

1. Inget ska tas bort eller ändras i recipe-api utom explicit beslutade backend-ändringar för användarscope i pantry och matplan.
2. Inget ska tas bort eller ändras i recipe-frontend.
3. Migreringen sker i Flutter-spåret som separat klient mot befintliga API-kontrakt.
4. Next-frontend körs parallellt tills Flutter har verifierad parity i kärnflöden.

Arbetsplan

Pågående arbete

• Kvittoimport (Fas 6b): Påbörjad men granskningssteg och bulk-spara återstår.
• Bildimport: Säkerställa att containrar är uppdaterade med senaste kod och att diagnostikloggar syns vid felsökning.
• Adminfunktioner: Avancerad AI-integration och ytterligare adminfunktioner planeras men är ej migrerade.

Prioriterade nästa steg

1. Slutför kvittoimport och bulk-spara.
2. Säkerställa robust bildimport och diagnostik.
3. Implementera avancerad AI-integration för produktkategorisering.
4. Utöka adminfunktioner för användarhantering och produktadministration.
5. Förbättra UI/UX för användarflöden, inklusive onboarding och profilhantering.

Beslut 2026-04-22 - User-scope för pantry och matplan

• Pantry och matplan ska vara per användare, inte globala.
• Detta kräver backend-ändringar i recipe-api innan Flutter kan nå full parity för dessa flöden.
• Flutter ska följa de nya kontrakten när de finns på plats, utan klientspecifik speciallogik.

Malbild för v1 (funktionell parity)

För v1 ska dessa flöden vara stabila i Flutter:

• Auth: login, session, logout, auth-guard.
• Recept: lista, detalj, skapa, uppdatera, ta bort.
• Inventarie: lista, skapa, uppdatera, konsumera, historik.
• Matplan: veckovy, val av recept per dag, portionsjustering, inköpslista, inventariejämförelse.
• Import: quick-import + parse-markdown-flöde.
• Produktadmin: lista, sök, sortera, filtrera, AI-kategorisering, merge, restore, inline kategori.
• Användaradmin: lista, premium, e-post, skapa, ta bort, återställ lösenord.

Arbetsordning för produktion

Fas 1: Kritiska funktioner och buggfixar

• Mål: Säkerställa att alla kärnfunktioner är stabila och buggfria.

• Åtgärder:

  • Kvittoimport (OCR, bulk-spara):

    • Implementera granskningssteg för kvittoimport.
    • Bulk-spara för bekräftade rader.
    • Säkerställa att file_picker: ^8.0.0 är integrerat för filval på Flutter Web.

  • UI/UX-förbättringar för adminpaneler:

    • Lägg till tydlig placeholder-text i sökfältet.
    • Gör filtreringsalternativen mer visuellt tydliga.
    • Lägg till bekräftelsedialog för bulk-åtgärder.
    • Förbättra laddningsindikatorn för AI-kategorisering.

  • Receptvy:

    • Lägg till tydlig växlingsknapp för grid- och listvy.
    • Implementera sorteringsalternativ.
    • Förbättra det tomma tillståndet med en tydlig CTA.

  • Receptdetaljvy:

    • Lägg till stöd för att visa receptbilder i större format.
    • Gör ingredienslistan mer läsbar.

  • Gemensamma UI-komponenter:

    • Förbättra felmeddelanden med tydliga instruktioner.
    • Använd en visuellt tilltalande laddningsindikator.

  • Allmänt:

    • Säkerställa tillgänglighet med tydliga tooltip-texter och tillräcklig kontrast.
    • Lägg till bekräftelsemeddelanden efter åtgärder.

Fas 2: Förbättra konverteringsvägen och onboarding

• Mål: Säkerställa att användare snabbt får värde och förstår appens fördelar.

• Åtgärder:

  • CTA (Call-to-Action):

    • Skapa tydliga och lockande CTAs som "Se vad du kan laga med det du har hemma."
    • Placera CTAs strategiskt i appen för att maximera synlighet.

  • Förenkla onboarding:

    • Implementera en gästinloggning eller demo-läge så att användare kan prova appen utan att registrera sig direkt.
    • Minska antalet obligatoriska fält vid registrering och implementera sociala inloggningar (t.ex. Google, Facebook).
    • Skapa en kort välkomstguide för nya användare som visar de viktigaste funktionerna.
    • Använd pop-up-tips eller tooltips för att visa hur man använder olika funktioner.

  • Snabb start med exempeldata:

    • Låt användare börja med förifyllt exempeldata, t.ex. en standardinköpslista eller vanliga ingredienser.
    • Lägg till en "Snabbstart"-knapp som automatiskt fyller i exempeldata och visar receptförslag.

  • Fokusera på "Aha!"-momentet:

    • Visa omedelbara receptförslag när användaren lägger till sina första ingredienser.
    • Generera en automatisk inköpslista baserad på de recept användaren väljer.

  • Tydliga instruktioner och feedback:

    • Visa tydliga instruktioner för varje steg i onboarding-processen.
    • Ge omedelbar feedback när användaren utfört en åtgärd.

  • Användarvänlig design:

    • Håll gränssnittet enkelt och fokuserat på kärnfunktioner.
    • Visa endast de viktigaste funktionerna för nya användare.

  • Möjlighet att hoppa över onboarding:

    • Lägg till en knapp som låter användare hoppa över onboarding och börja använda appen direkt.

Fas 3: Testa och iterera

• Mål: Identifiera friktion och förbättra konverteringsvägen.

• Åtgärder:

  • Gå igenom appen som en ny användare för att identifiera eventuella problem.
  • A/B-testa olika CTAs och onboarding-flöden för att se vad som fungerar bäst.
  • Implementera analytik för att spåra var användare hoppar av och varför.

Fas 4: Anpassa till målgruppen

• Mål: Se till att marknadsföring och CTAs talar direkt till målgruppen.

• Åtgärder:

  • Anpassa marknadsföring och CTAs till målgruppen (t.ex. familjer, matintresserade, meal preppers).
  • Var tydlig med appens värdeproposition, t.ex. "Slipp slösa mat – vi visar vad du kan laga med det du har hemma."

3. Avancerade adminfunktioner

• Implementera "Visa endast ändrade rader" i produktadmin.
• Säkerställa att AI-integration för kategorisering är robust.

4. Dokumentation och testning

• Uppdatera README.md med senaste ändringar.
• Lägg till testfall för nya funktioner.
• Validera med flutter analyze och fixa eventuella varningar.

5. Övrigt

• Säkerställa att alla containrar är uppdaterade för robust bildhantering.

Prioriterad plan (ordning)

Fas 0 - Backend-förarbete för user-scope (KLAR 2026-04-22)

• Gör PantryItem user-scopad (userId + productId unik per användare).
• Gör matplan user-scopad och filtrera list/upsert/delete per inloggad användare.
• Uppdatera matplanens inventory-jämförelse till användarspecifikt pantry.
• Publicera uppdaterade API-kontrakt innan vidare Flutter-parity för matplan/baslager.
• Migration 20260422130000_user_scope_pantry_meal_plan applicerad.

Fas 1 - Stabil app-shell (KLAR 2026-04-22)

• Bygg tydlig auth-gate i router.
• Centralisera API-fel (401/403/500) i ett gemensamt lager (mapErrorToUserMessage).
• Skapa gemensamma UI-komponenter för loading, empty, error.
• Sätt en enhetlig navigationsstruktur (web först, mobil-redo).
• Lokalisering: ARB-infrastruktur på plats (flutter_localizations, l10n.yaml, app_sv.arb, synthetic-package: false, flutter gen-l10n i Dockerfile).
• Regressionstest för svenska strängkvalitet tillagd.

Fas 2 - Auth parity (KLAR 2026-04-22)

• Hårdna loginflödet (tydliga felmeddelanden, retries där relevant).
• Verifiera token-livscykel (reload/hard refresh/logout).
• Implementera automatisk hantering av utgången token (401 -> logout -> login).

Fas 3 - Recept parity (KLAR 2026-04-22)

• Lista -> detalj -> skapa -> redigera -> ta bort.
• Knyt ihop med parse-markdown-proxy.
• Behåll backend som enda plats för matchning, validering och affärslogik.

Fas 4 - Inventarie parity (KLAR 2026-04-22)

• Lista med filter/sortering (plats + sort via Riverpod-querystate).
• Skapa och uppdatera inventariepost.
• Konsumtion och konsumtionshistorik.

Fas 5 - Matplan parity (KLAR 2026-04-22)

• Veckovy med receptval per dag mot user-scopat GET /api/meal-plan?from=&to=.
• Portionsjustering per dag.
• Inköpslista och inventariejämförelse mot användarens pantry.

Fas 6 - Import parity

6a — Recept-import

• URL via JSON-body { input: string }.
• Svar: { markdown: string, source: 'ica'|'pdf'|'image'|'other', imageUrl?: string }.
• På lyckat resultat: navigera till /recipes/create med markdown-texten förifylld.

6b — Kvittoimport

• Endpoint: POST /api/receipt-import
• Läge: filuppladdning, multipart/form-data, fält file, max 15 MB.
• Svar: ParsedReceiptItem[] med fälten rawName, quantity, unit, suggestedProductId?, suggestedProductName?, categorySuggestion?.
• På lyckat resultat: granskningssteg där användaren bekräftar/skippar rader.

UI/UX-förbättringar (KLAR 2026-04-22)

• Produktval med bottenark (ProductPickerField) i inventarie/pantry.
• Swipe-för-±1 på inventarielistan (SwipeableInventoryTile med visuell ledtråd).

Prioriterad plan (ordning)

Fas 0 - Backend-forarbete for user-scope (KLAR 2026-04-22)

• Gor PantryItem user-scopad (userId + productId unik per anvandare).
• Gor matplan user-scopad och filtrera list/upsert/delete per inloggad anvandare.
• Uppdatera matplanens inventory-jamforelse till anvandarspecifikt pantry.
• Publicera uppdaterade API-kontrakt innan vidare Flutter-parity for matplan/baslager.
• Migration 20260422130000_user_scope_pantry_meal_plan applicerad.

Fas 1 - Stabil app-shell (KLAR 2026-04-22)

• Bygg tydlig auth-gate i router.
• Centralisera API-fel (401/403/500) i ett gemensamt lager (mapErrorToUserMessage).
• Skapa gemensamma UI-komponenter for loading, empty, error.
• Satt en enhetlig navigationsstruktur (web forst, mobil-redo).
• Lokalisering: ARB-infrastruktur pa plats (flutter_localizations, l10n.yaml, app_sv.arb, synthetic-package: false, flutter gen-l10n i Dockerfile).
• Regressionstest for svenska strangkvalitet tillagd.

Fas 2 - Auth parity (KLAR 2026-04-22)

• Hardna loginflodet (tydliga felmeddelanden, retries dar relevant).
• Verifiera token-livscykel (reload/hard refresh/logout).
• Implementera automatisk hantering av utgangen token (401 -> logout -> login).

Fas 3 - Recept parity (KLAR 2026-04-22)

• Lista -> detalj -> skapa -> redigera -> ta bort.
• Knyt ihop med parse-markdown-proxy.
• Behall backend som enda plats for matchning, validering och affarslogik.

Fas 4 - Inventarie parity (KLAR 2026-04-22)

• Lista med filter/sortering (plats + sort via Riverpod-querystate).
• Skapa och uppdatera inventariepost.
• Konsumtion och konsumtionshistorik.

Fas 5 - Matplan parity (KLAR 2026-04-22)

• Veckovy med receptval per dag mot user-scopat GET /api/meal-plan?from=&to=.
• Portionsjustering per dag.
• Inkoplista och inventariejamforelse mot anvandarens pantry.

UI/UX-förbättringar (KLAR 2026-04-22)

• Produktval med bottenark (ProductPickerField) i inventarie/pantry.
• Swipe-för-±1 på inventarielistan (SwipeableInventoryTile med visuell ledtråd).

Fas 6 - Import parity

Analys (2026-04-22)

6a — Recept-import

(2) URL via JSON-body { input: string }.

• Svar: { markdown: string, source: 'ica'|'pdf'|'image'|'other', imageUrl?: string }.

• På lyckat resultat: navigera till /recipes/create med markdown-texten förifylld.

• Endpoint: POST /api/receipt-import

• Läge: filuppladdning, multipart/form-data, fält file, max 15 MB,

• Svar: ParsedReceiptItem[] med fälten rawName, quantity, unit, suggestedProductId?, suggestedProductName?, categorySuggestion?.

• På lyckat resultat: granskningssteg där användaren bekräftar/skippar rader

• Komplexitetsgrad: hög — granskningsvyn är det tyngsta steget.

Nytt paket som krävs:

• file_picker: ^8.0.0 — hanterar filval på Flutter web (ger Uint8List bytes, ingen filsökväg). Läggs till i pubspec.yaml.

Fil-/mappstruktur:

flutter/lib/features/import/
  domain/
    quick_import_result.dart      # { markdown, source, imageUrl? }
    parsed_receipt_item.dart      # { rawName, quantity, unit, ... }
  data/
    import_repository.dart        # API-anrop (multipart + JSON URL-läge)
    import_providers.dart         # Riverpod-providers
  presentation/
    import_screen.dart            # TabBar: "Recept" | "Kvitto"
    recipe_import_tab.dart        # Fas 6a — fil + URL, laddningsindikator

**Router och shell:**
- Ny route `/import` inuti `ShellRoute` i `app_router.dart`.
  placeras efter "Baslager" och innan "Profil".
- Multipart-uppladdning kan ta 5–30 s (OCR, LLM) — `LinearProgressIndicator`
  med text "Tolkar…" under hela anropet, inte en vanlig spinner.
- Timeout via `http`-klienten: sätt `Duration(seconds: 120)` för import-anrop.
- Nätverks- och serverfel mappas via befintlig `mapErrorToUserMessage`.

**Genomförandeordning:**
1. Lägg till `file_picker` i `pubspec.yaml`.
2. Utöka `CreateRecipeScreen` med `initialMarkdown`-parameter + GoRouter extra-stöd.
3. Bygg `domain/` + `data/` (modeller, repository, providers).
4. Bygg `recipe_import_tab.dart` (fas 6a — enklare).
- [x] Registrera `/import` i router och lägg till nav-destination i AppShell.
- [ ] Verifiera recept-import end-to-end (fil + URL → create-screen).
- [ ] Bygg `presentation/receipt_import_tab.dart` (uppladdning + granskningssteg).
- Adminfunktioner migreras sist for att minimera risk i karnfloden.

1. Verifiera request/response mot befintligt backendkontrakt.
3. Kontrollera felbanor innan UI-polish.

Ingen ad-hoc backendforandring goras for att "fa Flutter att funka".
Backend-andringar for user-scope i pantry/matplan ar explicit beslutade och ska goras kontrollerat forst.

## Kvalitetsgrind (Definition of Done)

En feature ar klar nar allt nedan ar uppfyllt:
2. Auth/rollskydd fungerar (inklusive 401/403).
3. Loading/empty/error ar konsekvent hanterat.
4. Navigation in/ut ur feature fungerar utan specialfall.
5. Smoke-test i testmiljo ar godkant.

## Leveransmodell

- Leverera 1 feature i taget till testdoman.
- Demo och snabb feedback innan nasta feature.
- Hall dubbel drift (Next + Flutter) tills karnfloden ar stabila.
- Flytta trafik gradvis nar parity ar verifierad.


## Nästa konkreta sprint (rekommenderad)

1. Fas 6: Import parity (URL/PDF/bild, robust felhantering).
2. Fas 7: Profil/admin parity.
3. Fortsatt flytt av UI-strängar till ARB (inventarie, pantry, recept).
4. Smoke-test på testdomän och avstämning.

## Tumregel

- Sikta pa funktionell parity forst.
- Pixel-perfect parity tas efter stabil funktion.

## Utförda förbättringar och nästa steg (2026-04-24)

- Navigationslänkar har lagts till mellan recept, inventarie, baslager och matplan för att förenkla användarflödet.
- Efter redigering av recept och konsumtion av inventariepost sker nu automatisk navigering till relevant vy.
- Efter import av recept sker automatisk navigering till receptlistan.
- Receptdetaljvyn har fått förbättrad bakgrundsbildshantering och mjukare scrollning.
- Kodbasen har granskats för att säkerställa att inga absoluta Windows-sökvägar används.

**Nästa steg:**
- Fortsatt användartestning av nya navigationsflöden och insamling av feedback.
- Finslipa UI och tillgänglighet i samband med de nya navigationsmöjligheterna.
- Färdigställ kvittoimport och adminfunktioner enligt plan.
- Lägg till snabbfilter i Produkt-admin: "Visa endast ändrade rader" för inline-kategoribyten (planerad förbättring till nästa pass).

# Nästa steg: Flutter-migrering

Relaterade dokument:
- [README.md](README.md)
- [teknisk_beskrivning_flutter.md](teknisk_beskrivning_flutter.md)

## Mål och prioriteringar för produktion

### Övergripande mål
- **Funktionell parity:** Säkerställa att alla kärnfunktioner är stabila och fungerar som förväntat.
- **Användarupplevelse:** Förenkla onboarding och säkerställa att användare snabbt förstår appens värde.
- **Produktionsklar:** Säkerställa att appen är redo för lansering genom att adressera kritiska buggar och förbättra prestanda.

### Icke-förhandlingsbara ramar

1. Inget ska tas bort eller ändras i `recipe-api` utom explicit beslutade backend-ändringar för användarscope i pantry och matplan.
2. Inget ska tas bort eller ändras i `recipe-frontend`.
3. Migreringen sker i Flutter-spåret som separat klient mot befintliga API-kontrakt.
4. Next-frontend körs parallellt tills Flutter har verifierad parity i kärnflöden.

## Arbetsplan

### Pågående arbete
- **Kvittoimport (Fas 6b):** Påbörjad men granskningssteg och bulk-spara återstår.
- **Bildimport:** Säkerställa att containrar är uppdaterade med senaste kod och att diagnostikloggar syns vid felsökning.
- **Adminfunktioner:** Avancerad AI-integration och ytterligare adminfunktioner planeras men är ej migrerade.

### Prioriterade nästa steg
1. Slutför kvittoimport och bulk-spara.
2. Säkerställa robust bildimport och diagnostik.
3. Implementera avancerad AI-integration för produktkategorisering.
4. Utöka adminfunktioner för användarhantering och produktadministration.
5. Förbättra UI/UX för användarflöden, inklusive onboarding och profilhantering.

## Plan för Implementering av Fas 6b

### 1. Slutför Kvittoimport
- **Aktiviteter:**
  - Implementera parsers för kvitton (PDF, bildbaserade kvitton).
  - Utveckla gränssnitt för att granska importerade kvitton.
  - Implementera bulk-spara-funktionalitet för kvitton.

- **Tekniska Detaljer:**
  - Använd `pdf-parse` och `tesseract.js` för att extrahera data från kvitton.
  - Säkerställa att API-endpoints (`/receipt-import`) hanterar filuppladdning och returnerar strukturerad data.

### 2. Förbättra Bildhantering
- **Aktiviteter:**
  - Säkerställa att `downloadAndOptimizeImage` fungerar korrekt i Docker-miljön.
  - Implementera robust felhantering och diagnostikloggning för bildimport.

- **Tekniska Detaljer:**
  - Använd miljövariabler för att definiera sökvägar för bildlagring.
  - Säkerställa att bilder optimeras och lagras korrekt på servern.

### 3. Säkerställa Kompatibilitet med Linux/Ubuntu
- **Aktiviteter:**
  - Kontrollera att alla sökvägar är relativa eller konfigurerbara via miljövariabler.
  - Säkerställa att Docker-miljön är korrekt konfigurerad för att köra på Ubuntu.

- **Tekniska Detaljer:**
  - Använd `path.join()` för att bygga sökvägar på ett plattformsoberoende sätt.
  - Säkerställa att `IMAGE_DEST_DIR` är korrekt konfigurerad för Linux/Ubuntu.

### 4. Förbättra API-Integration
- **Aktiviteter:**
  - Säkerställa att API-endpoints har korrekt felhantering och tidsgränser.
  - Implementera robusta tidsgränser och återförsöksmekanismer för API-anrop.

- **Tekniska Detaljer:**
  - Använd `http.Client` med korrekta tidsgränser för API-anrop.
  - Implementera återförsöksmekanismer för tillfälliga fel.

## Verifiering och Testning

### 1. Enhets- och Integrationstester
- **Aktiviteter:**
  - Skapa enhets- och integrationstester för nya parsers och API-endpoints.
  - Säkerställa att alla tester körs i Docker-miljön.

- **Tekniska Detaljer:**
  - Använd `flutter test` för att köra enhetstester.
  - Använd `jest` eller `supertest` för att testa API-endpoints.

### 2. Manuell Testning
- **Aktiviteter:**
  - Manuell testning av kvittoimport och bulk-spara-funktionalitet.
  - Säkerställa att bildhantering fungerar korrekt i Docker-miljön.

- **Tekniska Detaljer:**
  - Använd Postman eller liknande verktyg för att testa API-endpoints.
  - Säkerställa att gränssnittet för kvittoimport fungerar som förväntat.

## Slutsats
För att slutföra Fas 6b krävs implementering av parsers för kvitton, förbättringar av bildhantering, och säkerställande av kompatibilitet med Linux/Ubuntu. En robust API-integration och omfattande testning är avgörande för att säkerställa att importfunktionen fungerar som förväntat i produktion.