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".