Felorsaksanalys och symptomverifiering (SVP) som obligatoriska grindar

Skillnaden mellan VAD som är fel och VARFÖR felet uppstått är nu kodad:
ett ärende kan aldrig avslutas med enbart "komponent defekt, byt
komponent", och en kundbeskrivning blir aldrig ett konstaterat fel utan
verifiering.

Symptom Verification Protocol:
- Ny händelse reproducering (ja/delvis/nej): ja kräver hur/förhållanden,
  delvis vad som kunde respektive inte kunde återskapas, nej kräver
  motivering
- Generiska metodiken utökad med SVP-frågorna var/hur
- Rapportens beviskedja skiljer kundens beskrivning, verifierad
  observation, felorsaksanalys och rekommenderad åtgärd; "kunde inte
  reproduceras under de förhållanden som rådde" i stället för "felet
  konstaterat" — kodat även i orkesterns grundprompt

Felorsaksanalys (Root Cause Analysis):
- Ny händelse felorsak: avvikelse + orsakskategorier + underlag +
  säkerhetsnivå + rekommenderad åtgärd
- Kvalitetsregeln avvisar generella formuleringar ("trasig", "defekt",
  "sliten", "behöver bytas") utan förklaring
- Valda evidenskällor valideras mot loggen — "Foto" godtas bara om ett
  foto faktiskt finns
- Okänd orsak kräver motivering; medel/låg säkerhet kräver vilka
  ytterligare kontroller som stärker bedömningen
- Avslutsknappen spärrad tills SVP + felorsak dokumenterats;
  kvalitetsgrinden gör båda obligatoriska vid stängning

Demoärendet bär hela beviskedjan; 54 vitest-tester, integrationstest
och OpenAPI-validering gröna.

Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_012EQg3rJsrQ1ZNTvkzmQAtt

docs/MVP.md

@@ -36,6 +36,8 @@ Demomanus för visning: [DEMO.md](DEMO.md). Knappen **Skapa demoärende** på st
 | Inställningar | ✅ Systemadministratören väljer vilka objekttyper och identifieringsmetoder som visas när ett ärende startas (`/felsokning/installningar`). På plattformen gäller valet hela organisationen (sparas på organisationen, endast admin får ändra — verifierat i integrationstestet); i lokalt läge gäller valet enheten. Okända värden filtreras och tomma listor faller tillbaka till standard. |
 | Evidensmotor (ECM) | ✅ Eget subsystem med sex motorer ([moduler/evidensmotor.md](moduler/evidensmotor.md), `src/felsokning/ecm.ts`, **ECM v2.0**): Evidence (evidensposter med nivå E0–E6, tekniker och innehållshash), Rule (dokumentationskrav + undantagsregeln med obligatorisk orsak), Compliance (ärendetypen — garanti/försäkring/reklamation m.fl. — styr extra krav), Validation ("Evidens saknas" i stället för antaganden, kodat i orkesterns grundprompt), Completion (kvalitetsgrind som spärrar slutrapporten) och Traceability (spårbarhetspaket med regelversion + hash i varje export). |
 | Pre-diagnostik | ✅ Ingen felsökning förrän grundkontrollerna är gjorda eller motiverade: fordonshistorik (Ja med ev. orsakskedja / Nej med obligatorisk orsak → kvalitetsvarning), **ingående mätarställning** (foto av instrumentpanelen, bildtolkningen föreslår värdet), kundens felbeskrivning verifierad och tidiga observationer hanterade. Metodiken låses upp först därefter. **Utgående mätarställning** fotograferas inför avslut och blir obligatorisk i grinden när ärendet stängs. |
+| Symptomverifiering (SVP) | ✅ Kundens beskrivning ≠ konstaterat fel: beskrivningen dokumenteras ordagrant, förtydligas via metodikens symptomfrågor (generiska metodiken har SVP-setet när/var/hur) och reproduceras — Ja (hur/förhållanden), Delvis (vad kunde/kunde inte) eller Nej (obligatorisk motivering). Rapportens beviskedja skiljer kundens beskrivning, verifierad observation, felorsaksanalys och rekommenderad åtgärd; formuleringen "kunde inte reproduceras under de förhållanden som rådde" används i stället för "felet konstaterat" (kodat även i orkesterns grundprompt). |
+| Felorsaksanalys | ✅ Obligatorisk före avslut: konstaterad avvikelse (kvalitetsregeln avvisar "trasig/defekt/sliten" utan förklaring), orsakskategorier (inkl. Okänd orsak med krav på motivering), minst en evidenskälla som valideras mot loggen, säkerhetsnivå (medel/låg kräver stärkande kontroller) och rekommenderad åtgärd. Avslutsknappen spärrad tills SVP + felorsak finns; kvalitetsgrinden gör båda obligatoriska vid stängning. Eget avsnitt i slutrapporten. |
 | Ärendeidentitet | ✅ Fordonsobjektet som röd tråd: identiteten (AO-nummer, claim-/garantinummer, skadenummer, regnr, VIN, miltal, kund) registreras en gång — normalt via arbetsorderskanningen — och återanvänds i identitetsraden i arbetsytan (med ärendetypsval), låst panel överst i Live Share, slutrapportens första sida (Ärendeinformation + Fordonsinformation) och exporten. |
 | Instrumentavläsning (visual-first) | ✅ Kameran som universellt gränssnitt: `📷 Instrument` i Dokumentera-panelen fotograferar multimetrar, diagnosskärmar, batteritestare m.m. — bildtolkningen identifierar instrumenttyp och extraherar värden/enheter/felkoder med konfidens per värde; teknikern bekräftar innan något loggas. Originalbilden loggas alltid tillsammans med de strukturerade mätvärdena — strukturerad data ersätter aldrig originalevidensen. Ingen integration mot diagnossystem krävs. |
 | Utskrift | ✅ Kundrapport och Live Share-vy skrivs ut svart på vitt; interaktiva element döljs automatiskt. Utskriften går genom ECM-kvalitetsgrinden. |

docs/moduler/evidensmotor.md

@@ -104,6 +104,49 @@ dokumenterat motiverade — metodiken låses upp först därefter:
 **Utgående mätarställning** fotograferas inför avslut och blir
 obligatorisk i grinden när ärendet stängs. Rapporten visar in/ut.
 
+## Symptom Verification Protocol (SVP)
+
+Ett fel diagnostiseras aldrig direkt från en vag kundbeskrivning.
+Kedjan är alltid: **dokumenterats → förtydligats → reproducerats eller
+dokumenterats som ej reproducerbart.**
+
+- Kundens beskrivning registreras ordagrant vid ärendestart och
+  verifieras i pre-diagnostiken; nya symptom blir separata observationer.
+- Förtydligandet sker genom metodikens symptomfrågor (när/var/hur/
+  förhållanden/frekvens — generiska metodiken har hela SVP-frågesetet).
+- **Reproducering** (Ja/Delvis/Nej) dokumenteras innan avslut: Ja kräver
+  hur och under vilka förhållanden; Delvis vad som kunde respektive inte
+  kunde återskapas; Nej kräver motivering. Systemet skriver aldrig
+  "felet konstaterat" utan reproducering eller annan verifiering — i
+  stället: *"Kundens beskrivning kunde inte reproduceras under de
+  förhållanden som rådde vid undersökningen."* (kodat även i orkesterns
+  grundprompt).
+- Rapportens beviskedja skiljer alltid: kundens beskrivning →
+  verifierad observation → felorsaksanalys → rekommenderad åtgärd.
+
+## Felorsaksanalys (Root Cause Analysis)
+
+Ett ärende avslutas aldrig med enbart "komponent defekt, byt komponent".
+Varje konstaterat fel kräver fyra obligatoriska svar:
+
+1. **Konstaterad avvikelse** — kvalitetsregeln avvisar generella
+   formuleringar ("trasig", "defekt", "sliten", "behöver bytas") utan
+   förklaring.
+2. **Mest sannolik orsak** — en eller flera kategorier (normalt slitage,
+   materialutmattning, tillverkningsfel, bristande underhåll, felaktig
+   tidigare reparation, yttre påverkan, korrosion, överhettning,
+   modifiering … samt *Okänd orsak*, som kräver motivering).
+3. **Underlag** — minst en evidenskälla, och källan valideras mot
+   loggen: "Foto" godtas bara om ett foto faktiskt finns.
+4. **Säkerhetsnivå** — hög/medel/låg; vid medel/låg krävs vilka
+   ytterligare kontroller som skulle stärka bedömningen.
+
+Avslutsknappen är spärrad tills SVP + felorsaksanalys är dokumenterade,
+och kvalitetsgrinden gör båda obligatoriska när ärendet stängs. Efter
+tusentals ärenden ger orsakskategorierna dessutom flottdata: vilka
+komponenter fallerar av slitage, vilka efter tidigare reparationer,
+vilka tyder på konstruktionsproblem.
+
 ## Ärendeidentitet (Case Identity & Vehicle Context)
 
 Fordonsobjektet är den röda tråden: identiteten registreras **en gång**