# Next Steps: Flutter-migrering

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

## Icke-forhandlingsbara ramar

1. Inget ska tas bort eller andras i `recipe-api` utom explicit beslutade backend-andringar for anvandarscope i pantry och matplan.
2. Inget ska tas bort eller andras i `recipe-frontend`.
3. Migreringen sker i Flutter-sparet som separat klient mot befintliga API-kontrakt.
4. Next-frontend kor parallellt tills Flutter har verifierad parity i karnfloden.

## Beslut 2026-04-22 - User-scope for pantry och matplan

- Pantry och matplan ska vara per anvandare, inte globala.
- Detta kraver backend-andringar i `recipe-api` innan Flutter kan na full parity for dessa floden.
- Flutter ska folja de nya kontrakten nar de finns pa plats, utan klientspecifik speciallogik.

## Malbild for v1 (funktionell parity)

For v1 ska dessa floden 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, inkopslista, inventariejamforelse.
- Import: quick-import + parse-markdown-flode.
- Profil: basfunktioner for anvandarprofil.

Adminfloden migreras efter att ovanstaende ar verifierat.

## Prioriterad plan (ordning)

## Fas 0 - Backend-forarbete for user-scope (ny)
- 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.

## Fas 1 - Stabil app-shell (forst)
- Bygg tydlig auth-gate i router.
- Centralisera API-fel (401/403/500) i ett gemensamt lager.
- Skapa gemensamma UI-komponenter for loading, empty, error.
- Satt en enhetlig navigationsstruktur (web forst, mobil-redo).

Motivering: minskar regressionsrisk och gor resten av migreringen snabbare.

## Fas 2 - Auth parity
- 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
- 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
- Lista med filter/sortering.
- Skapa och uppdatera inventariepost.
- Konsumtion och konsumtionshistorik.

## Fas 5 - Matplan parity
- Veckovy med receptval per dag.
- Portionsjustering per dag.
- Inkoplista och inventariejamforelse.

## Fas 6 - Import parity
- URL/PDF/bild via befintliga endpoints.
- Tydlig hantering av langkorande anrop och fel.

## Fas 7 - Profil/admin parity
- Profil for alla anvandare.
- Role-aware navigation och skydd for adminytor.
- Adminfunktioner migreras sist for att minimera risk i karnfloden.

## Contract-first per feature

For varje feature:
1. Verifiera request/response mot befintligt backendkontrakt.
2. Mappa modeller robust (null-safe, fallback-falt, typskillnader).
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:
1. API-floden fungerar for bade success och fel.
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.

## Nasta konkreta sprint (rekommenderad)

1. Fas 0: backend-andringar for user-scope i pantry/matplan.
2. Fas 1: app-shell hardening.
3. Fas 2: auth parity helt klar.
4. Smoke-test pa testdomanen och avstamning.

## Tumregel

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