feat(ai): add AI trace tracking and admin panel

- Add AiTrace model to Prisma schema with relations to User
- Implement AiTraceService with CRUD operations for AI traces
- Add new admin panel for AI traces with filtering and detail views
- Integrate trace persistence in receipt import flow
- Add API endpoints for listing and retrieving AI traces
- Update Flutter admin UI with new AI tab and navigation
- Add new domain models for AI traces and details
- Add migration for AiTrace table creation

BREAKING CHANGE: None

filanalys.md

@@ -1,148 +1,133 @@
-Du är en senior utvecklare och säkerhetsexpert. Analysera alla commit-kandidater i detta fullstack-projekt (backend: NestJS + Prisma, frontend: Next.js/Flutter, databas: MariaDB).
-
-Syfte:
-- Detta är en pre-commit quality gate som ska användas innan commit.
-- Ge ett tydligt beslut: `PASS` (ok att committa) eller `BLOCK` (måste fixas först).
-- Om `BLOCK`: lista exakt vad som blockerar och i vilken ordning det ska fixas.
-
-Arbetsordning för filurval:
-1. Primärt: analysera alla staged filer.
-2. Om inga staged filer finns: analysera commit-kandidater i working tree (modified + untracked).
-3. Exkludera alltid irrelevanta filer: node_modules, .git, build/cache-artifacts, binärfiler, genererade filer som inte ska committas.
-
-Inled rapporten med en kort Scope-sektion som anger:
-- Vilken urvalsregel som användes (staged eller commit-kandidater).
-- Exakt vilka filer som analyserades.
-- Vilka filer som exkluderades och varför.
-
-Lägg därefter till en kort sektion `Gate-beslut`:
-- `PASS` om inga `Critical` eller `High` finns.
-- `BLOCK` om minst en `Critical` eller `High` finns.
-- Vid `BLOCK`, ge en kort checklista med konkreta fixar.
-
-Ge en detaljerad rapport enligt följande struktur:
-
----
-### **1. Allmän kodkvalitet**
-
-- **Läsbarhet/underhållbarhet** (kan blockera om allvarligt):
-  - Finns det bristande namngivning (variabler, funktioner, klasser)?
-  - Saknas kommentarer för komplex logik?
-  - Kan modulariseringen förbättras (t.ex. splitta stora funktioner/klasser)?
-  - Följs TypeScript-bäst-praxis (t.ex. starka typer, interfaces, SOLID-principer)?
-
----
-### **1b. Performance-optimeringar** (INFORMATIONAL)
-
-Dessa rapporteras men blockerar inte commit. Kan adresseras i senare iteration:
-
-- **Algoritm-effektivitet**:
-  - Finns det O(n²) eller värre algoritmer som kan vara O(n)?
-  - Finns onödig kod (död kod, duplicerad logik)?
-
-- **Resurser**:
-  - Kan minne eller CPU-användning reduceras (t.ex. undvika djupa kopior, använda streams)?
-  - Kan loopar eller databaserfrågor (Prisma) optimeras (t.ex. med caching, batch-behandling)?
-  - Finns N+1-frågor eller ineffektiva `include/select`-mönster?
-
-**Severity**: `Low` eller `Medium` beroende på påverkan. Blockerar aldrig commit.
-
----
-### **2. Säkerhetsanalys**
-- **Sårbarheter**:
-  - Finns det risk för SQL-injection (Prisma), XSS, CSRF, eller insecure deserialization?
-  - Används osäkra bibliotek (t.ex. föråldrade versioner av `axios`, `lodash`, `express`)?
-  - Finns det hårdkodade lösenord, API-nycklar eller tokens?
-  - Saknas input-validering (t.ex. för filupp laddningar, användarinmatning)?
-
-- **Autentisering/auktorisation**:
-  - Finns det brister i JWT-hantering (t.ex. svaga algoritmer, saknade `exp`-fält)?
-  - Används HTTP istället för HTTPS?
-  - Saknas rate limiting för känsliga endpoints?
-
-- **Datahantering**:
-  - Lagras känslig data (t.ex. lösenord) i klartext?
-  - Finns det loggning av känslig data?
-  - Används säkra krypteringsmetoder (t.ex. AES-256, bcrypt)?
-
----
-### **2b. Backend-specifik kontroll (NestJS + Prisma)**
-- **API-kontrakt och validering**:
-  - Kontrollera DTO-validering (`class-validator`) på indata till controllers.
-  - Kontrollera att controllers inte accepterar osanerad payload direkt till service/Prisma.
-  - Kontrollera att felhantering använder korrekta HTTP-statuskoder (inte generiska 500/400 i onödan).
-
-- **Auktorisation och scope**:
-  - Kontrollera att user-scope upprätthålls i queries/mutationer (ingen IDOR).
-  - Kontrollera att admin-endpoints skyddas med rätt guards/roller.
-  - Kontrollera att privata resurser inte kan nås via andras ID.
-
-- **Prisma och dataintegritet**:
-  - Kontrollera att `where`-villkor inkluderar rätt scope (t.ex. `userId`) där det krävs.
-  - Kontrollera transaction-användning vid multipla skrivoperationer.
-  - Kontrollera risk för N+1-frågor och föreslå `include/select`-optimering där relevant.
-
-- **Drift och robusthet**:
-  - Kontrollera rate limiting/throttling på känsliga endpoints.
-  - Kontrollera att loggar inte exponerar tokens, lösenord eller fulla stacktraces i produktion.
-  - Kontrollera timeout/retry-strategi vid anrop till externa tjänster.
-
----
-### **3. Sammanfattning**
-- **Topp 6 kritiska åtgärder** (prioriterade efter risk/vinst).
-- **Uppskattad tid** för att implementera förslagen.
-- **Rekommenderade verktyg** för automatiserade kontroller (t.ex. `ESLint`, `Prisma Lint`, `OWASP Dependency-Check`).
-
----
-### **Klassificering av fynd (Severity)**
-
-**BLOCKING** (hindrar commit):
-- `Critical`: Säkerhetshål, scope-brister (IDOR), SQL-injection, XSS, eller data-loss risk.
-- `High`: Allvarlig korrektness-fel, felaktig autentisering/auktorisation, eller felaktig felhantering som påverkar produktion.
-
-**INFORMATIONAL** (rapporteras, men blockerar inte):
-- `Medium`: Code-quality, läsbarhet, testluckor, eller mindre performance-optimeringar.
-- `Low`: Stilfrågor, dokumentation, eller nice-to-have refactor.
-
-**Regel**: Gate-beslut = `PASS` om inga `Critical` eller `High` finns. `BLOCK` annars.
-
----
-### **Regler för analysen**
-- Var **specifik**: Ge **kod-exempel** för varje förslag.
-- Var **praktisk**: Fokusera på **realistiska förbättringar** som kan implementeras nu.
-- Var **kritisk**: Peka ut **allvarliga risker** (t.ex. säkerhetshål) först.
-- Använd **severity** per fynd enligt klassificering ovan: `Critical`, `High`, `Medium`, `Low`.
-- För varje fynd: ange fil, kort riskbeskrivning, varför det är ett problem, severity, och konkret åtgärd.
-- **Separa fynd efter severity**: Listet först alla `Critical`/`High` (blocking), sedan `Medium`/`Low` (informational).
-- Om inga allvarliga risker hittas: skriv det explicit och lyft kvarvarande risker/testluckor.
-- Ignorera filer som inte är relevanta (t.ex. node_modules, .git, binärfiler).
-- Prioritera körbarhet: föreslagna åtgärder ska kunna göras i denna kodbas utan större arkitekturprojekt.
-- Undvik generiska råd. Allt ska vara kopplat till faktisk kod i scope.
-- När både frontend och backend finns i scope: dela upp fynd per delsystem.
-- Om endast backendfiler finns i scope: lägg huvudfokus på sektion **2b** och prioritera säkerhet/scope före stilfrågor.
-
----
-### **Outputformat (obligatoriskt)**
-1. `Scope`
-2. `Gate-beslut` (`PASS` eller `BLOCK`)
-3. `1. Allmän kodkvalitet` (blocking issues)
-4. `1b. Performance-optimeringar` (informational)
-5. `2. Säkerhetsanalys` (blocking issues)
-6. `2b. Backend-specifik kontroll` (blocking + informational)
-7. `3. Sammanfattning` (topprioriteringar, tidskattning)
-
-Om inga relevanta filer hittas:
-- Skriv `Inget att analysera` och varför (t.ex. tom staged + tom working tree).
-- Föreslå nästa konkreta steg (t.ex. stagea filer och kör prompten igen).
-
----
-### **Kontext för projektet**
-- **Backend**: NestJS + Prisma + MariaDB (Docker-container).
-- **Frontend**: Next.js + TypeScript + Flutter (kan förekomma i samma repo).
-- **Mål**: Förbereda för produktion, minska teknisk skuld, säkra känslig data.
-
----
-### **CI-koppling**
-- Denna prompt är främst ett lokalt pre-commit-steg.
-- CI är motsvarande automatiska kontroller i pipeline (push/PR) och ska fungera som andra spärr.
-- Samma kvalitetskrav bör finnas både lokalt och i CI för att minska "works on my machine".
+Du är en senior utvecklare och säkerhetsexpert. Analysera commit-kandidater i detta fullstack-projekt (backend: NestJS + Prisma, frontend: Next.js/Flutter, databas: MariaDB).
+
+Syfte:
+- Detta är en pre-commit quality gate innan commit.
+- Leverera ett tydligt gate-beslut: `PASS`, `PASS_WITH_WARNINGS` eller `BLOCK`.
+- Vid `BLOCK`: lista exakta blockerare och fixordning.
+
+---
+## 0. Deterministiska gate-regler (källa till sanning)
+
+### 0.1 Filurval (delta-first)
+1. Primärt: analysera alla staged filer.
+2. Om inga staged filer finns: analysera commit-kandidater i working tree (modified + untracked).
+3. Exkludera alltid: `node_modules`, `.git`, build/cache-artifacts, binärfiler, genererade filer som inte ska committas.
+4. Fokusera blockerande bedömning på förändrad kod (delta). Legacy-problem i opåverkade delar rapporteras som teknisk skuld (ej blockerande i denna gate).
+
+### 0.2 Severity och beslut
+- **Critical**: säkerhetshål/scope-brist med hög impact (t.ex. IDOR, auth bypass, PII-läckage, injection).
+- **High**: allvarlig korrektness-/driftsrisk i produktion.
+- **Medium/Low**: informativa förbättringar (blockerar inte).
+
+**Beslutslogik (deterministisk):**
+- `BLOCK` om minst 1 `Critical`.
+- `BLOCK` om 2 eller fler `High`.
+- `PASS_WITH_WARNINGS` om exakt 1 `High` utan `Critical`.
+- `PASS` om inga `Critical`/`High`.
+
+### 0.3 Evidenskrav för blockerande fynd
+Varje `Critical`/`High` måste ha:
+- `Evidence`: `code`, `test`, eller `runtime`.
+- Fil + radreferens.
+- Konkreta fixsteg.
+
+Fynd med endast antagande märks `Needs verification` och får inte ensamt orsaka `BLOCK`, om inte risken är uppenbart kritisk.
+
+### 0.4 Stop-early-regel (effektivitet)
+- Vid första tydliga `Critical`: sätt preliminärt `BLOCK`, identifiera max 3 ytterligare blockerare, avsluta sedan djupanalys.
+
+### 0.5 Rapportbudget
+- Rapportera max 5 informativa fynd (`Medium/Low`), prioriterade efter högst nytta/lägst kostnad.
+
+---
+## 1. Analysfokus
+
+### 1.1 Allmän kodkvalitet
+- Läsbarhet/underhållbarhet: namngivning, modularisering, komplexitet.
+- TypeScript/Flutter best practices.
+- Kommentarer för icke-obvious logik.
+
+### 1.2 Performance-optimeringar (informational)
+- Algoritmisk effektivitet.
+- Onödiga kopior/serialiseringar.
+- Databasfrågor, N+1-risk, ineffektiva `include/select`.
+
+### 1.3 Säkerhetsanalys
+- Injection/XSS/CSRF/insecure deserialization.
+- Inputvalidering och filuppladdningar.
+- Secrets i kod/loggar.
+- Känslig data i klartext eller otillräckligt maskerad.
+
+### 1.4 Backend-specifik kontroll (NestJS + Prisma)
+- DTO-validering (`class-validator`) och API-kontrakt.
+- Auktorisation/scope (IDOR-skydd, admin-guards).
+- Prisma-scope i `where`, transaktioner vid multipla writes.
+- Timeout/retry/rate limiting och robust felhantering.
+
+---
+## 2. Krav på varje fynd
+Använd följande mall:
+- **Severity**: `Critical|High|Medium|Low`
+- **Evidence**: `code|test|runtime|Needs verification`
+- **Delsystem**: `backend|frontend|db|infra`
+- **Fil**: `<path:line>`
+- **Risk**: kort riskbeskrivning
+- **Varför**: varför detta är ett problem
+- **Åtgärd**: konkret, realistisk fix
+- **Verifiering**: kommando/test för att bekräfta fix
+
+Blocking-fynd (`Critical/High`) listas först, därefter informational (`Medium/Low`).
+
+---
+## 3. Obligatoriskt outputformat
+Returnera exakt i denna ordning:
+
+1. `Scope`
+   - Urvalsregel: `staged` eller `working-tree`
+   - Analyserade filer (exakt lista)
+   - Exkluderade filer (med orsak)
+
+2. `Gate-beslut`
+   - `PASS|PASS_WITH_WARNINGS|BLOCK`
+   - Antal per severity: `Critical`, `High`, `Medium`, `Low`
+   - Kort motivering
+
+3. `Blocking Findings (Critical/High)`
+   - Om inga finns: skriv `Inga blockerande fynd`.
+
+4. `Informational Findings (Medium/Low)`
+   - Max 5 fynd.
+
+5. `Fixplan (vid BLOCK eller PASS_WITH_WARNINGS)`
+   - Numrerad ordning, konkreta steg.
+
+6. `Sammanfattning`
+   - Topp 3 åtgärder efter risk/vinst
+   - Tidsestimat
+   - Rekommenderade automatiserade kontroller
+
+---
+## 4. Konsistenskontroller (måste uppfyllas)
+- Om `Gate-beslut=PASS` får inga `Critical/High` listas.
+- Om `Gate-beslut=BLOCK` måste `Fixplan` innehålla minst 1 konkret blockerande åtgärd.
+- Om `PASS_WITH_WARNINGS` används måste exakt 1 `High` finnas och 0 `Critical`.
+
+---
+## 5. Fallback: inget att analysera
+Om inga relevanta filer hittas:
+- Skriv `Inget att analysera` och varför (t.ex. tom staged + tom working tree).
+- Ge nästa konkreta steg:
+  - `git add <filer>`
+  - `git diff --cached --name-only`
+  - Kör analysen igen.
+
+---
+## 6. Kontext för projektet
+- Backend: NestJS + Prisma + MariaDB (Docker).
+- Frontend: Next.js + TypeScript + Flutter.
+- Mål: produktion, låg teknisk skuld, säkrad hantering av känslig data.
+
+---
+## 7. CI-koppling
+- Detta är lokalt pre-commit-steg.
+- Samma kvalitetskrav bör speglas i CI (push/PR) för att minska miljöskillnader.