Add comprehensive documentation for Flutter frontend migration and backend review

- Introduced user guide for Flutter frontend in README.md, detailing user flows and recent improvements.
- Created next steps roadmap for Flutter migration in next_steps_flutter.md, outlining current tasks and priorities.
- Developed technical description for Flutter frontend in teknisk_beskrivning_flutter.md, covering architecture and security status.
- Removed outdated migration documentation for Prisma P3009 and added recovery steps for failed migrations in migrering-MSI.md.
- Established a release checklist for product launches in produktlansering.md, ensuring security and stability measures are met.
- Formulated a systematic backend review and optimization plan in review_backend.md, focusing on reducing complexity and improving performance.

_archive/docs/review_backend.md

@@ -0,0 +1,104 @@
+# Plan för systematisk backend-review och optimering
+
+## Mål
+1. Minska komplexitet och duplicering.
+2. Förbättra prestanda och stabilitet.
+3. Göra koden enklare att underhålla och vidareutveckla.
+4. Införa kvalitetsgrindar så förbättringar håller över tid.
+
+## Arbetssätt
+1. Jobba i små, säkra iterationer per modul/domän.
+2. Mät före och efter varje förändring.
+3. Lås upp förbättringar med tester och CI-gates.
+4. Prioritera förändringar med hög effekt och låg risk först.
+
+## Fas 1: Baslinje och kartläggning (1 vecka)
+1. Inventera backend per modul:
+- Endpoints, tjänster, databasaccess, externa integrationer.
+2. Sätt baslinjemätningar:
+- Responstider per kritisk endpoint (p50/p95), felgrad, DB-latens.
+- Nuvarande testtäckning per modul.
+3. Skapa hotspot-lista:
+- Långa metoder, hög cyclomatic complexity, duplicerad logik, N+1-frågor.
+4. Leverabel:
+- Prioriterad backlog med topp 10 förbättringsområden.
+
+## Fas 2: Snabba vinster och kodhygien (1-2 veckor)
+1. Standardisera felhantering:
+- Enhetlig exception mapping och API-felmodell.
+2. Rensa duplicerad kod:
+- Flytta gemensam logik till tydliga utilities/domänservices.
+3. Förbättra validering:
+- Konsekvent DTO/valideringslager in och ut.
+4. Inför striktare lint-regler:
+- Max function length, complexity-tak, no-dead-code.
+5. Leverabel:
+- Minskad kodvolym i hotspots och jämnare kodstandard.
+
+## Fas 3: Arkitektur-förenkling (2-3 veckor)
+1. Tydlig separering av lager:
+- Controller = transport.
+- Service = affärslogik.
+- Repository/data layer = persistens.
+2. Minska beroendekoppling:
+- Ta bort korsberoenden mellan moduler.
+3. Inför tydliga domängränser:
+- En modul ska kunna förstås utan att läsa flera andra.
+4. Leverabel:
+- Enklare call-flöden och färre starkt kopplade beroenden.
+
+## Fas 4: Databas och prestanda (1-2 veckor)
+1. Granska tunga queries:
+- N+1, överhämtning, saknade index, ineffektiva joins.
+2. Förbättra dataåtkomst:
+- Standard för pagination/filtering.
+- Selektiv hämtning av fält.
+3. Caching där det är motiverat:
+- Endast för dyra och frekventa läsningar.
+4. Leverabel:
+- Mätbar förbättring i p95 och minskad DB-belastning.
+
+## Fas 5: Teststrategi och regressionsskydd (1-2 veckor, löpande)
+1. Lägg tester där risk och affärsvärde är högst:
+- Kritiska use cases först.
+2. Balans i testpyramiden:
+- Fler enhetstester för domänlogik.
+- Fokuserade integrations- och API-tester för flöden.
+3. Kontrakttester för externa integrationer.
+4. Leverabel:
+- Högre täckning i kritiska moduler och färre regressionsbuggar.
+
+## Fas 6: Säkerhet och driftbarhet (parallellt)
+1. Säkerhetsgranskning:
+- Input-validering, auth/role-kontroller, secret-hantering.
+- Inventory är nu user-scopad och IDOR-skyddad: Alla inventory-operationer kräver och filtrerar på userId i backend (schema, migration, service, controller, tester). Tester verifierar att åtkomst nekas vid försök till IDOR.
+2. Driftbarhet:
+- Strukturerad loggning, korrelations-id, tydligare metrics.
+3. Resiliens:
+- Timeout/retry/circuit-breaker för externa beroenden.
+4. Leverabel:
+- Färre driftincidenter och enklare felsökning.
+
+## Kvalitetsgrindar i CI
+1. Build och lint måste passera.
+2. Tester måste passera.
+3. Miniminivå för täckning i ändrade moduler.
+4. Blockera PR vid ökad komplexitet över satt tröskel.
+5. Enkel performance-smoke på kritiska endpoints.
+
+## Prioriteringsmodell för varje förbättring
+1. Effekt: prestanda, stabilitet, underhållbarhet.
+2. Risk: regressionsrisk och driftsrisk.
+3. Insats: utvecklingstid.
+4. Välj först: hög effekt + låg/medel risk + låg/medel insats.
+
+## Definition of Done
+1. Kritiska endpoints har förbättrad p95.
+2. Topp-hotspots är refaktorerade eller borttagna.
+3. Kodduplicering reducerad i prioriterade moduler.
+4. Testskydd finns för alla kritiska flöden.
+5. CI-gates förhindrar att kvaliteten glider tillbaka.
+
+## 2026-05-10: Admin-inventarie (CRUD, merge, filter, sortering, preview, säkerhet), user-scope, IDOR-skydd, säkerhetshärdning, optimeringar och utökad testtäckning är nu genomförda och dokumenterade i README, TEKNISK_BESKRIVNING, SÄKERHETSHÄRDNINGSPLAN och SESSIONLOGGAR.
+
+## 2026-05-10: Admin-inventarie (CRUD, merge, filter, sortering, preview, säkerhet), user-scope, IDOR-skydd, säkerhetshärdning, optimeringar och utökad testtäckning är nu genomförda och dokumenterade i README, TEKNISK_BESKRIVNING, SÄKERHETSHÄRDNINGSPLAN och SESSIONLOGGAR.