recipe-app/.kilo/plans/plan-multiplatform.md

Plan: Anpassad multiplattformsplan for recipe-app

Mal

Gora Flutter-klienten i flutter/ till en riktig multiplattformsklient (web + Android + iOS) utan att bryta befintligt webbflode via Docker/Caddy, och med tydlig miljohantering for API-anrop pa mobil.

Nulagesanalys (projektanpassad)

• Flutter-projektet ar i praktiken web-only just nu: flutter/ saknar android/ och ios/.
• Webbbygget ar redan etablerat och stabilt via Docker:
  • flutter/Dockerfile bygger flutter build web --dart-define=API_BASE_URL=/api.
  • compose.flutter.yml och flutter/Caddyfile proxar /api/* till recipe-api:8080.
• API-basurl hanteras redan med --dart-define (bra grund for multiplattform):
  • flutter/lib/core/api/api_client.dart
  • flutter/lib/features/import/data/import_repository.dart
• Token-lagring ar forberedd for mobil men inte implementerad:
  • flutter/lib/core/platform/token_storage.dart
  • flutter/lib/core/platform/platform_providers.dart (har TODO om secure storage).

Viktig skillnad mot gamla planen

• Ingen hardkodad Config.apiUrl med fasta domaner ska inforas som huvudlosning.
• Projektet anvander redan String.fromEnvironment('API_BASE_URL'); vi behaller detta och utokar till mobil.
• Befintlig Docker-setup for web ska inte ersattas, bara kompletteras med mobil-byggflode.

Foreslagen implementation

Fas 1: Aktivera plattformsstommar utan att rora webdeploy

1. Skapa Android/iOS-mappar i flutter/:
   • flutter create --platforms android,ios .
2. Verifiera att webfiler och befintliga Dart-filer inte overskrivs pa ett destruktivt satt.
3. Bekrafta att Docker-webbygget fortfarande fungerar oforandrat.

Leverabel: Projektet innehaller flutter/android/ och flutter/ios/ samtidigt som webflodet ar intakt.

Fas 2: Plattformsaker konfiguration av API-basurl

1. Standardisera API-konfiguration kring en enda kontraktspunkt:
   • Behall API_BASE_URL via --dart-define.
2. Satt tydliga miljoer:
   • Web i Docker: API_BASE_URL=/api (som idag).
   • Android emulator lokalt: t.ex. http://10.0.2.2:8080/api (vid lokal backend utan reverse proxy).
   • Fysisk mobil/test/prod: publik HTTPS-url (doman som ar natbar utanfor Docker).
3. Se over alla direkta API-basar i Flutter-koden sa att de gar via samma pattern (inga hardkodade hostnamn).

Leverabel: Samma kodbas fungerar pa web och mobil genom miljoinjektering, inte forks av API-klient.

Fas 3: Mobilanpassad auth/tokenlagring

1. Implementera SecureTokenStorage med flutter_secure_storage for mobil.
2. Uppdatera platform_providers.dart till plattformsval:
   • Web -> befintlig WebTokenStorage.
   • Android/iOS -> SecureTokenStorage.
3. Verifiera att inloggning/logout/session beter sig lika mellan web och mobil.

Leverabel: JWT lagras sakert pa mobil, befintligt webbeteende bibehalls.

Fas 4: UI- och UX-hardning for mindre skarmar

1. Identifiera skarmar med hog informationsdensitet (admin/import/tabeller).
2. Lagg in responsiva brytpunkter med LayoutBuilder/MediaQuery dar det behovs.
3. Prioritera funktionellt minimum for mobil i forsta iteration:
   • Login
   • Inventarie
   • Receptlista
   • Grundlaggande importfloden
4. Markera admin-tunga vyer som sekundara om de inte ar mobilkritiska i fas 1.

Leverabel: Nyckelfloden ar anvandbara pa telefon utan horisontell overflow eller blockerande layoutfel.

Fas 5: Build- och releaseflode (utan att blanda ihop med Docker-runtime)

1. Dokumentera separata kommandon:
   • Web (befintligt): Docker/compose.
   • Android: flutter build apk --release (och ev. appbundle).
   • iOS: flutter build ios --release (kraver macOS/Xcode).
2. Behall principen: mobilappar kor inte i Docker; Docker far anvandas som byggmiljo dar det ar rimligt.
3. Om CI ska byggas senare: separera web-jobb och mobil-jobb for tydlighet.

Leverabel: Reproducerbar byggprocess for web och mobil med tydlig ansvarsskillnad.

Fas 6: Test- och verifieringsplan

1. Statisk kvalitet:
   • flutter analyze
   • flutter test
2. Plattformsverifiering:
   • Web via befintlig container
   • Android emulator + fysisk enhet
   • iOS simulator (pa macOS)
3. Natverksverifiering:
   • Bekrafta att mobil kan na vald API_BASE_URL over HTTPS/CORS/proxyregler.
4. Regression:
   • Inloggning, token-refresh/logout
   • CRUD i inventarie/recept
   • Importendpoints med storre payloads

Leverabel: Checklista med passerade verifieringspunkter innan distribution.

Konkreta filer som sannolikt berors

• flutter/pubspec.yaml (nytt beroende for secure storage)
• flutter/lib/core/platform/platform_providers.dart
• flutter/lib/core/platform/token_storage.dart (ev. endast kontraktsjustering)
• Ny fil: flutter/lib/core/platform/secure_token_storage.dart
• Mobilplattformar som genereras: flutter/android/**, flutter/ios/**
• Dokumentation: README.md och/eller TEKNISK_BESKRIVNING.md (kommandon och miljoexempel)

Risker och hantering

• iOS-bygg kan inte verifieras i Windows/Linux-miljo -> hanteras med separat macOS-steg.
• Hardkodade URL:er kan smyga sig in i featurekod -> hanteras med kodsok + central konfigpolicy.
• UI-regression pa web vid responsiva andringar -> hanteras med web-regressionstest av kritiska vyer.

Prioriterad ordning for implementation

1. Fas 1 (plattformsstommar)
2. Fas 2 (API-konfiguration)
3. Fas 3 (secure token storage)
4. Fas 6 del 1 (analyze/test tidigt)
5. Fas 4 (mobil UI-hardning)
6. Fas 5 + Fas 6 slutlig verifiering och dokumentation

Definition of Done

• Flutter-projektet bygger for web + android (och ios dar macOS finns).
• Mobil och web anvander samma API-konfigmodell via --dart-define.
• Mobil lagrar token sakert; webflodet ar oforandrat.
• Minst nyckelfloden login/inventarie/recept/import ar verifierade pa mobil.
• Dokumentationen beskriver exakt hur man bygger och kor respektive plattform i detta repo.