feat: enhance error dialogs with delete functionality and improve documentation

filanalys.md

@@ -24,18 +24,29 @@ Ge en detaljerad rapport enligt följande struktur:
 
 ---
 ### **1. Allmän kodkvalitet**
-- **Optimeringar**:
-  - Finns det ineffektiva algoritmer (t.ex. O(n²) istället för O(n))?
-  - Kan loopar, databaserfrågor (Prisma) eller API-anrop optimeras (t.ex. med caching, batch-behandling)?
-  - Finns det onödig kod (död kod, duplicerad logik)?
-  - Kan minne eller CPU-användning reduceras (t.ex. undvika djupa kopior, använda streams)?
 
-- **Läsbarhet/underhållbarhet**:
+- **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**:
@@ -82,13 +93,27 @@ Ge en detaljerad rapport enligt följande struktur:
 - **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: `Critical`, `High`, `Medium`, `Low`.
-- För varje fynd: ange fil, kort riskbeskrivning, varför det är ett problem, och konkret åtgärd.
+- 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.
@@ -100,9 +125,11 @@ Ge en detaljerad rapport enligt följande struktur:
 ### **Outputformat (obligatoriskt)**
 1. `Scope`
 2. `Gate-beslut` (`PASS` eller `BLOCK`)
-3. `1. Allmän kodkvalitet`
-4. `2. Säkerhetsanalys`
-5. `3. Sammanfattning`
+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).