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.