feat: implement API client with JSON handling and error mapping; enhance routing and state management in app shell

next_steps_flutter.md

@@ -1,53 +1,101 @@
-# Next Steps: Flutter-migrering (Alternativ 3)
+# 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)
 
-## 1. Definiera malbild och scope forst
-- Bestam vilka floden som maste vara parity i v1: login, receptlista, receptdetalj, inventarie, matsedel, profil.
-- Satt tydlig definition of done per feature: UI, navigation, API, felhantering, loading states, auth-skydd.
+## Icke-forhandlingsbara ramar
 
-## 2. Bygg gemensam app-shell innan fler sidor
-- Stabil routingstruktur.
-- Gemensam navigation (top/bottom/nav drawer).
-- Auth-gate och logout-flode.
-- Standardkomponenter for tomma lagen, felmeddelanden och laddning.
+1. Inget ska tas bort eller andras i `recipe-api`.
+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.
 
-Det gor att varje ny sida gar snabbare och mer konsekvent.
+## Malbild for v1 (funktionell parity)
 
-## 3. Migrera i denna ordning (hogst affarsvarde forst)
-- Auth: login, session, logout.
-- Recept: lista -> detalj -> skapa/andra.
-- Inventarie: lista -> skapa -> uppdatera -> forbrukning.
-- Import-funktionen
-- Matsedel.
-- Profil/admin.
+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.
 
-Ordningen minimerar blockerare eftersom recept + auth ofta anvands av allt annat.
+Adminfloden migreras efter att ovanstaende ar verifierat.
 
-## 4. Kor API-contract first per feature
-- Verifiera exakt request/response mot backend innan UI putsas.
-- Mappa datamodeller robust (null, typskillnader, fallback-falt).
-- Lagg in central felhantering for 401/403/500 tidigt.
+## Prioriterad plan (ordning)
 
-## 5. Satt enhetliga kvalitetsgrindar per migrerad feature
-- Manuell testlista for kritiska scenarier.
-- En liten smoke-test efter varje deploy.
-- Kontroll att web + mobilanpassning fungerar (utan web-specifika genvagar).
+## 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).
 
-## 6. Leverera i korta iterationer
-- 1 feature at gangen till testmiljo.
-- Demo + snabb feedback.
-- Justera innan nasta feature.
+Motivering: minskar regressionsrisk och gor resten av migreringen snabbare.
 
-Det minskar risken att du bygger fel saker for langt.
+## 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).
 
-## 7. Avveckla gamla frontend stegvis
-- Kor dubbel drift under en period.
-- Peka en testdoman mot Flutter tills parity ar bekräftad.
-- Flytta trafik gradvis nar karnfloden ar stabila.
+## 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 backendforandring goras for att "fa Flutter att funka".
+
+## 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 1: app-shell hardening.
+2. Fas 2: auth parity helt klar.
+3. Fas 3 (del 1): receptdetalj + skapa recept.
+4. Smoke-test pa testdomanen och avstamning.
 
 ## Tumregel
-- Sikta pa funktionell parity forst, pixel-perfect parity senare.
-- Det ger snabbare nytta och farre regressionsproblem.
+
+- Sikta pa funktionell parity forst.
+- Pixel-perfect parity tas efter stabil funktion.