Merge main: Guidad Felsökning flyttar ur roten till felsokning/

Main är sedan den här grenen skapades en helt annan produkt — Semantika,
en mobilapp med egen CDK-infrastruktur. Den äger nu repots rot: en
npm-workspaces-monorepo med apps/mobile, services/api och infra.

För att båda ska rymmas i samma repo flyttar Guidad Felsökning in i en
egen katalog i stället för att göra anspråk på roten:

  felsokning/app        webbklienten (Vite, egen package.json och
                        eslint-/vitest-konfiguration)
  felsokning/services   plattformstjänsten och AI-orkestern
  felsokning/infra      Terraform och databasschemat
  felsokning/docs       vision, moduler, drift
  felsokning/supabase   edge-funktion och migrationer

Merge:n hade tagit bort 128 filer som Guidad Felsökning bygger på —
värdapplikationens komponenter, Supabase-klienten, tillgångar — eftersom
main raderat dem och den här grenen inte råkat ändra just dem. De är
återställda på sin nya plats. Utan dem gick varken bygget eller
testerna: ai.ts och synk.ts importerar Supabase-klienten.

Semantikas rotfiler är orörda: package.json, eslint.config.js och
.github/workflows/ är deras. Guidad Felsökning har egna motsvarigheter i
sin katalog.

CI flyttar samtidigt från GitHub Actions till .gitea/workflows — samma
syntax, egna runners. .github/workflows/ tillhör Semantika härefter.

Verifierat på den nya platsen: 96 vitest-tester, typkontroll, eslint på
både klient och tjänster, bygge, och integrationstest mot riktig Postgres.

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

felsokning/docs/DEMO.md

@@ -0,0 +1,71 @@
+# Guidad Felsökning – Demomanus
+
+Ett 5–10 minuters manus för att visa plattformen. Allt körs lokalt utan konton eller nycklar.
+
+## Förberedelser
+
+```sh
+npm install
+npm run dev
+```
+
+Öppna `http://localhost:8080/felsokning` — helst på mobil eller i mobilläge i webbläsaren (appen är byggd för verkstadsgolvet). Ange ett namn (allt loggas per användare).
+
+Chrome rekommenderas: då fungerar även röstinmatningen (Push-to-Talk).
+
+## Demoflöde
+
+### 1. Dashboarden och demoärendet (1 min)
+
+Klicka **Skapa demoärende (Volvo XC60, vibration)**. Ett komplett ärende med 1 tim 35 min arbetshistorik läggs in: identifierat objekt, besvarade symptomfrågor, fyra hjulfoton, mätvärden, provkörning, en överlämning mellan två tekniker och en hypotes.
+
+Poäng att göra: dashboarden visar bara det viktigaste — pågående, klara, nytt ärende.
+
+### 2. Ärendebriefen (2 min)
+
+Öppna ärendet → fliken **Brief**. Det här är kärnargumentet:
+
+- **Utförda kontroller** med resultat — inte bara kryssrutor.
+- **Ej kontrollerat** — härlett automatiskt ur metodiken; det som orsakar dubbelarbete vid skiftbyte är det ingen skrivit ner att ingen gjort.
+- **Hypoteser** tydligt märkta 🔴 — systemet presenterar aldrig en hypotes som ett konstaterat fel.
+- **Tillförlitlighet** och **total arbetstid**.
+
+Poäng: en ny tekniker är produktiv på under en minut, utan att läsa hundratals loggrader.
+
+### 3. Guiden och verifierade checklistor (2 min)
+
+Fliken **Guide**. Metodiken fortsätter där den slutade: en fråga eller kontroll i taget, stora knappar.
+
+- Visa att en mätkontroll **inte kan verifieras utan mätvärde** (knappen är låst tills värdet är ifyllt).
+- Tryck på 🎤 och diktera en observation — texten hamnar i fältet, redigerbar, och sparas först när man trycker Spara. Tal in, text ut; inget skickas automatiskt.
+- Visa kategoriknapparna (aktiv felsökning / väntetid / provkörning …) — tidrapporteringen sköter sig själv.
+
+### 4. Arbetsloggen (1 min)
+
+Fliken **Logg**: varje händelse tidsstämplad med användare, append-only — ingenting kan ändras eller raderas i efterhand. Peka på överlämningen mellan Anna och Johan.
+
+### 5. Kundrapporten och Live Share (2 min)
+
+Fliken **Rapport**:
+
+- **Skriv ut / PDF** — rapporten blir svart på vitt automatiskt.
+- **Exportera JSON** — versionsmärkt (version = antal händelser), och exporten loggas själv.
+- **Öppna Live Share-vy** — det kunden ser via delningslänken: status ✔/🔄/⏳, bilder, mätvärden, tidslinje. Inga hypoteser, inga interna poster.
+
+Poäng: i stället för "Felsökning – 2,5 timmar" på fakturan får kunden en tidslinje över vad som faktiskt gjorts.
+
+### 6. Avsluta med filosofin (30 sek)
+
+> Systemet dokumenterar observationer, leder användaren genom verifierbara kontroller och rekommenderar nästa steg — men presenterar aldrig en hypotes som ett konstaterat fel.
+
+Det ersätter inte teknikern. Det ersätter pärmen, minneslapparna och "fråga Kent, han skruvade på den i torsdags".
+
+## Vad som är demoläge respektive produktion
+
+| I demon | I produktion |
+| --- | --- |
+| Deterministisk metodikmotor (3 metodiker) | LLM väljer/genererar steg genom samma motorgränssnitt |
+| Webbläsarens taligenkänning | Leverantörens Voice-to-Text bakom samma gränssnitt |
+| localStorage + synk vid inloggning | Multi-tenant-backend (migration finns), roller enligt Master Prompt |
+| Delningslänk kräver synkat ärende | Live Share med behörighetsnivåer kund/intern/partner |
+| Demobilder ritade av systemet | Riktiga foton via kameran (fungerar redan i demon också) |

felsokning/docs/DRIFT.md

@@ -0,0 +1,211 @@
+# Guidad Felsökning – Drift i Kubernetes (helt självhostat)
+
+Målarkitekturen ur [Master Prompt](MASTER-PROMPT.md) som kod: hela stacken körbar i eget kluster — webb, AI-orkester, plattformsbackend (auth + händelse-API + Live Share) och Postgres. Inga externa tjänstberoenden utöver Anthropic-API:et för AI-anropen.
+
+## Arkitektur
+
+```mermaid
+flowchart LR
+    T[Tekniker] -->|HTTPS| I[Ingress + TLS]
+    T2[Kund via delningslänk] -->|HTTPS| I
+    I -->|/| W[web\n2–10 pods, HPA]
+    I -->|/api/ai| A[ai-orkester\n2–10 pods, HPA]
+    I -->|/api, /halsa| P[plattform\n2–10 pods, HPA]
+    A -->|Claude API| C[(Anthropic)]
+    P --> DB[(Postgres\nStatefulSet + PVC)]
+    K[Secret: felsokning-hemligheter] --> A & P & DB
+```
+
+| Komponent | Vad | Var |
+| --- | --- | --- |
+| `web` | SPA:n bakom oprivilegierad nginx (`Dockerfile`, `docker/nginx.conf`) | Deployment + Service + HPA + PDB |
+| `plattform` | Självhostad backend (`services/plattform`): **multi-tenant** — registrering skapar organisation + systemadministratör, admin hanterar användare (tekniker/arbetsledare/admin), all ärendedata organisationsisolerad. Inloggning (bcrypt via pgcrypto, HS256-JWT med roll + org i anspråken), append-only händelse-API, publik delningsendpoint | Deployment + Service + HPA + PDB |
+| `ai-orkester` | AI-orkestern (`services/ai-orkester`): fyra uppgifter routade till Sonnet 5 / Opus 5 / Haiku 4.5 — verifierar plattformens JWT (delad hemlighet) | Deployment + Service + HPA + PDB |
+| `postgres` | Händelselogg + användare; **append-only garanterat med databastriggers** — historik kan inte ändras eller raderas oavsett roll | Tre lägen: extern managerad Postgres (rekommenderat), CloudNativePG i klustret, eller en enkel StatefulSet utan backup för prov |
+| Hemligheter | `anthropic-api-key`, `jwt-secret` (delas av plattform + orkester), `postgres-losenord`, `integration-nyckel` (krypterar kundernas märkesspecifika credentials) |
+| Miljöflaggor | `TILLATNA_URSPRUNG` (CORS-lista; utelämnad = `*`), `TILLAT_INTERNA_UPPSLAG` (`true` tillåter leverantörsuppslag mot privata nät), `REGISTRERING_OPPEN`, `ECM_REGLER_FIL`, `INTEGRATIONER_FIL` | Secret `felsokning-hemligheter` — aldrig i bilder eller manifest |
+
+**Klienten har två driftlägen**, valda vid bygget: med `VITE_PLATTFORM_URL` går inloggning, synk, Live Share och AI mot klustret (helt självhostat); utan den används Supabase-läget (edge-funktion + managerad Postgres/Auth) som tidigare. Samma händelsemodell, samma orkester — låst av paritetstester.
+
+## Infrastrukturen som kod
+
+`infra/terraform` är systemets definition — läs [README:n där](../infra/terraform/README.md).
+Börja i `karta.tf`: hela systemet beskrivet en gång som data (tjänster,
+portar, routing, hemligheter, dataflöden, gränser). `terraform output
+karta` skriver ut samma sak i klartext.
+
+Definitionen omfattar hemligheter, databasschema, nätverksgränser och
+alla tre databaslägena. Kustomize- och Argo CD-vägen är borttagen —
+`infra/postgres-init.sql` är det enda som blivit kvar utanför Terraform,
+och den läses av både Terraform och integrationstestet så att schemat
+inte kan glida isär från det som testas.
+
+## Nätverksgränser
+
+Terraform-vägen stänger namnrymden och öppnar bara de faktiska flödena:
+
+| Från | Till | Varför |
+| --- | --- | --- |
+| ingress-kontrollern | web, plattform, ai-orkester :8080 | den enda vägen in |
+| plattform | postgres :5432 | händelseloggen |
+| plattform | internet :443 utom privata nät | kundernas leverantörer |
+| ai-orkester | internet :443 utom privata nät | Claude |
+| web, postgres | — | ringer ingenting |
+
+Undantagen för privata nät (10/8, 172.16/12, 192.168/16, 169.254/16,
+127/8, 100.64/10) är samma gräns som koden själv upprätthåller i
+`pekarInat` — två oberoende spärrar mot att ett kundkonfigurerat uppslag
+används för att nå klustrets insida eller molnets metadatatjänst.
+Kräver en CNI som tillämpar NetworkPolicy; annars är reglerna
+dokumentation, inte skydd.
+
+## Driftsätta
+
+Allt går genom Terraform — hemligheter, schema och nätverksgränser
+ingår. Det finns ingen `kubectl apply` att komma ihåg.
+
+```sh
+cd infra/terraform
+cp terraform.tfvars.exempel terraform.tfvars   # domän, register, databasläge, nycklar
+terraform init
+terraform plan
+terraform apply -var bildtagg=<git-sha>
+
+terraform output karta       # hela systemet i klartext
+terraform output endpoints   # adresser att kontrollera
+```
+
+Sedan:
+
+```sh
+curl https://app.exempel.se/halsa            # → {"status":"ok"}
+curl https://app.exempel.se/api/openapi.yaml # hela API-specen
+```
+
+Klustret behöver: en CNI som tillämpar NetworkPolicy, ingress-nginx,
+cert-manager, en metrics-server och en StorageClass med ReadWriteOnce.
+
+Att skapa nya organisationer är stängt som standard
+(`registrering_oppen = false`); användare inom en organisation skapas
+alltid av dess systemadministratör.
+
+## Databasen: valet som avgör om det finns backup
+
+`databas_lage` saknar standardvärde med flit.
+
+| Läge | Backup | Failover | Använd när |
+| --- | --- | --- | --- |
+| `extern` | Leverantörens, med PITR | Leverantörens | **Produktion.** Cloud SQL, RDS, Neon, Azure |
+| `cnpg` | Basbackup 02:30 + WAL-arkiv → objektlagring, PITR | Ja | Produktion när databasen måste ligga i klustret |
+| `inbyggd` | **Ingen** | Nej | Prov och demo — spärras när `miljo = "produktion"` |
+
+Går händelseloggen förlorad är det inte "data" som försvinner utan varje
+ärendes bevisvärde: vad som kontrollerades, av vem, när, med vilken
+evidens. Det går inte att återskapa i efterhand.
+
+`cnpg` kräver CloudNativePG-operatorn installerad först — Terraform slår
+upp dess CRD redan vid plan. I `extern` läge kör ni
+`infra/postgres-init.sql` mot databasen själva; det är samma fil som
+integrationstestet kör.
+
+## Bilagor
+
+Foton, videoklipp och instrumentbilder låg tidigare som data-URL:er inne
+i händelserna. Det drabbade allt som läser loggen: synken drog med hela
+bildmassan var femtonde sekund, kundvyn likaså, och en säkerhetskopia av
+loggen var i praktiken en kopia av alla foton.
+
+Nu ligger innehållet utanför händelsen och loggen bär en referens med
+innehållets SHA-256. **Det stärker bevisvärdet i stället för att försvaga
+det**: hashen står i den append-only-skyddade loggen, så en bild som
+bytts ut går att upptäcka — tidigare låg bilden i loggen och måste helt
+enkelt tros på. Innehållet kontrolleras mot hashen varje gång det lämnas
+ut; stämmer det inte svarar tjänsten 409 i stället för att visa bilden.
+
+Innehållsadresserat, så samma foto som dokumenteras två gånger lagras en
+gång.
+
+| `bilage_lage` | Var innehållet ligger | Använd när |
+| --- | --- | --- |
+| `databas` (standard) | `bilage_innehall` (bytea) | Fungerar överallt utan konfiguration; bilderna följer med databasens säkerhetskopior |
+| `s3` | S3-kompatibel objektlagring (AWS, MinIO, Ceph) | Loggen och bilderna ska växa oberoende av varandra |
+
+Signeringen mot objektlagringen är egen (SigV4 för PUT och GET) i stället
+för molnleverantörens SDK — två operationer motiverar inte tiotals
+megabyte beroenden. Den korsverifieras mot botocore i testerna, bit för
+bit.
+
+**Delningsgränsen gäller även bilagor.** En bilaga kan bara hämtas via en
+delningslänk om händelsen den hör till är synlig på den nivån; den
+skannade arbetsordern nås alltså aldrig via kundlänken.
+
+Äldre händelser med inbäddad data-URL fortsätter att fungera och kommer
+alltid att göra det — loggen är append-only. Lokalt läge, utan
+inloggning, bäddar också in: det finns ingen server att ladda upp till,
+och dokumentationen får inte gå förlorad för att nätet ligger nere.
+
+## Åtkomst: spärr och återkallelse
+
+En giltig JWT-signatur räcker inte. Varje autentiserat anrop slår upp
+kontot och kontrollerar två saker till: att det fortfarande är aktivt och
+att token-versionen stämmer. Det kostar ett uppslag på primärnyckeln per
+anrop och ger i gengäld **omedelbar** återkallelse i stället för att en
+avstängning börjar gälla först när token går ut om upp till tolv timmar.
+
+| Situation | Väg | Effekt |
+| --- | --- | --- |
+| Någon slutar | `POST /api/anvandare/{id}/avaktivera` (admin) | Inloggning stängs och pågående sessioner upphör direkt |
+| Kontot ska tillbaka | `POST /api/anvandare/{id}/aktivera` (admin) | Kan logga in igen; tidigare återkallade tokens förblir döda |
+| Telefon borttappad | `POST /api/auth/logga-ut-alla` (sig själv) | Alla enheter loggas ut |
+
+En administratör kan inte stänga av sig själv, och gränsen mellan
+organisationer gäller — org B kan inte röra org A:s användare.
+Händelseloggen rörs aldrig: historiken är fortfarande knuten till
+personen som utförde arbetet.
+
+**Takt-begränsning på inloggning** ligger i databasen, inte i minnet, så
+spärren håller bakom flera repliker: 10 misslyckade försök per konto och
+30 per källadress inom 15 minuter ger 429. Spärren gäller kontot även vid
+rätt lösenord — annars kunde den kringgås av den som till slut gissar
+rätt. Andra konton påverkas inte. Inget lösenord lagras, bara att ett
+försök skedde och om det lyckades; rader äldre än ett dygn städas bort i
+skrivvägen.
+
+## Multi-tenant och roller
+
+Enligt Master Prompt: varje kund är en egen tenant, ingen data blandas mellan kunder.
+
+- **Registrering skapar organisationen** och gör användaren till systemadministratör.
+- **Admin skapar användare** (tekniker/arbetsledare/admin) i sin organisation — via UI:t eller `POST /api/anvandare`.
+- **All ärendedata är organisationsknuten**: ärenden skapas i användarens organisation och händelse-API:t verifierar organisationstillhörighet på varje anrop — en annan organisations ärenden ger 404.
+- **Rollen ligger i JWT:n** och verifieras på servern; klienten anpassar bara UI:t.
+
+Integrationstestet (`services/plattform/integrationstest.sh`, körs även i CI mot riktig Postgres) verifierar hela kedjan: registrering, synk, idempotens, append-only-triggern, organisationsisolering, delningsfiltrering och rollstyrning.
+
+## Säkerhet och robusthet
+
+- **Append-only i tre lager:** klienten lägger bara till, API:t exponerar inga update/delete, och databastriggers avvisar ändringar även för en felkonfigurerad roll.
+- **JWT-flödet är verifierat tvärs tjänsterna:** plattformen signerar, orkestern verifierar samma hemlighet; fel hemlighet och utgångna tokens avvisas (testat).
+- Alla containrar kör **non-root** utan capabilities; backend-tjänsterna med read-only rotfilsystem. Båda failar closed utan sina hemligheter.
+- **HPA** 2–10 pods per tjänst på 70 % CPU; **PDB** minst en pod uppe vid noddränering; readiness/liveness-prober överallt (`pg_isready` för Postgres).
+
+## CI/CD med GitOps
+
+**CI** (`.github/workflows/ci.yml`): tester, produktionsbygge, integrationstest mot riktig Postgres och verifierande containerbyggen på varje push/PR.
+
+**CD** — två flöden, medvetet åtskilda: en bild i registret är inte samma sak som en bild som kör.
+
+```mermaid
+flowchart LR
+    P[Push till main] --> B[Publicera:\nbygger 3 bilder\ntaggade med git-SHA] --> G[(GHCR)]
+    G -.-> D[Driftsätt:\nstartas för hand\nmed en tagg]
+    D --> M[miljö: produktion\ngodkännande] --> T[terraform apply] --> K[Klustret]
+    T --> R[Rökkontroll\nhälsa + API-spec]
+```
+
+1. **Publicera** vid varje main-push: bygger de tre bilderna och taggar med git-SHA:t (`GITHUB_TOKEN`, inga externa hemligheter).
+2. **Driftsätt** startas för hand med en tagg, mot GitHub-miljön `produktion` som kan kräva godkännande. Kör `fmt`, `init`, `validate`, `plan`, `apply`, skriver ut kartan och rökkontrollerar hälsa och API-spec. `bara_plan` visar planen utan att applicera.
+3. **Rollback** = kör Driftsätt igen med en tidigare tagg.
+
+Kustomize- och Argo CD-vägen är borttagen. Den beskrev samma system en gång till och kunde inte köras samtidigt som Terraform utan att de motarbetade varandra — `selfHeal` återställde det Terraform ändrade och `prune` tog bort det Terraform skapade.
+

felsokning/docs/MASTER-PROMPT.md

@@ -0,0 +1,183 @@
+# Guidad Felsökning – Master Prompt v2.0
+
+**Production Ready AI Wrapper Platform (MVP/Beta)**
+
+Det här är ett produktdirektiv, inte en teknisk specifikation. Visionen och resonemangen bakom finns i [VISION.md](VISION.md); v1.0 finns i versionshistoriken. Detaljerade modulspecifikationer: [kommunikationsmodell (röst/PTT)](moduler/kommunikationsmodell.md), [Live Share](moduler/live-share.md), [verifierade checklistor](moduler/verifierade-checklistor.md), [ärendebrief](moduler/arendebrief.md), [arbetslogg & tidredovisning](moduler/arbetslogg-och-tidredovisning.md), [kundrapport](moduler/kundrapport.md).
+
+---
+
+## Projekt
+
+Bygg en produktionsredo SaaS-plattform med namnet **Guidad Felsökning**.
+
+Plattformen är en AI-wrapper ovanpå Claude API (Anthropic) och fungerar som ett professionellt arbetsverktyg för mekaniker och servicetekniker.
+
+**AI:n drivs av plattformen, inte av kunden.** Claude API-nycklarna är plattformshemligheter i backend och exponeras aldrig för kunder eller klienter — AI-handledningen ingår i tjänsten. Backend äger systemprompt, modellval och svarsschema, så AI-reglerna kan inte kringgås från klientsidan.
+
+**Modellorkestern.** Vi kör flera Claude-modeller i vår infrastruktur och routar per uppgift — backend äger routingtabellen, så den kan justeras utan klientändringar:
+
+| Uppgift | Modell | Motiv |
+| --- | --- | --- |
+| Handledning (svar på varje dokumentation) | Claude Sonnet 5 | Många anrop, latenskänsligt på verkstadsgolvet |
+| Granskning (motsägelser/luckor i hela underlaget) | Claude Opus 5, hög effort | Djupaste resonemanget — kvalitet före latens |
+| Överlämningssammanfattning (risker & osäkerheter) | Claude Sonnet 5, låg effort | Balans |
+| Metodikklassificering av felbeskrivning | Claude Haiku 4.5 | Ren klassificering — snabbast och billigast |
+
+Alla uppgifter delar samma grundregler (AI-reglerna nedan) och samma klassificerade svarsschema. Vid avböjd förfrågan faller anropet automatiskt tillbaka till Anthropics rekommenderade reservmodell. Den ska inte ersätta teknisk kompetens eller tillverkarens dokumentation, utan vägleda användaren genom en strukturerad felsökningsprocess, dokumentera allt arbete och skapa full spårbarhet.
+
+Målet är att lansera en stabil, enkel och köpvärdig beta-version.
+
+---
+
+## Produktfilosofi
+
+Produkten ska kännas som ett verktyg från en stor industrileverantör: enkel, stabil, extremt snabb, professionell, förutsägbar, tydlig, minimalistisk.
+
+Ingen "AI-leksak". Ingen onödig design. Inga experimentella funktioner. Allting ska kännas robust.
+
+---
+
+## Roller
+
+### Systemadministratör
+
+Normalt en eller flera personer hos kunden. Behörigheter: hantera organisation, API-nycklar, integrationer, skapa/ta bort användare, roller, behörigheter, export, säkerhetsinställningar, fakturering, loggar.
+
+### Tekniker
+
+Kan skapa ärenden, fortsätta ärenden, ta över ärenden, skriva, prata, fotografera, filma, mäta, exportera rapport.
+
+### Arbetsledare
+
+Kan dessutom se alla ärenden, omfördela ärenden, följa status, läsa rapporter, skapa statistik.
+
+---
+
+## Multi-tenant
+
+Varje kund är en egen tenant med egna användare, API-nycklar, integrationer, ärenden, databaslogik och säkerhet. **Ingen data får blandas mellan kunder.**
+
+---
+
+## Enkel onboarding
+
+Första gången en kund loggar in:
+
+1. Skapa företag
+2. Lägg till logotyp
+3. Lägg till användare
+4. Lägg till eventuella integrationer
+
+Klart. Hela onboarding ska ta mindre än fem minuter. AI-handledningen ingår i tjänsten — kunden hanterar inga AI-nycklar.
+
+---
+
+## Dashboard
+
+Visa endast det viktigaste: Mina ärenden · Pågående · Väntar · Klara · Starta nytt ärende.
+
+---
+
+## Nytt ärende
+
+Identifiera objekt genom registreringsnummer, VIN, maskinnummer, QR, streckkod, OCR, foto eller manuell identifiering. Objektet verifieras innan felsökning startar.
+
+---
+
+## AI-guidning
+
+Systemet arbetar stegvis. Inte långa svar. En kontroll åt gången:
+
+> Kontrollera säkring F24. → Användaren svarar. → AI går vidare.
+
+### AI-regler
+
+AI får aldrig hitta på fakta, låtsas veta eller gissa. Den ska skilja på **Observation**, **Verifierat**, **Hypotes** och **Rekommendation**. Alla svar ska ha tydlig tillförlitlighet.
+
+---
+
+## Kommunikationsmodell
+
+**Tal in, text ut.** All röstinmatning sker via tal-till-text enligt Push-to-Talk — ingen bakgrundslyssning, ingen röstagent, aldrig automatiskt skick. Transkriberingen är alltid redigerbar innan den sparas i arbetsloggen. Se [modulen](moduler/kommunikationsmodell.md) för fullständig specifikation.
+
+---
+
+## Kamerastöd
+
+Foto, video, OCR, bildanalys och objektidentifiering: däck, typskyltar, serienummer, skyltar, komponenter, mätinstrument.
+
+---
+
+## Arbetslogg
+
+Allt loggas: tid, användare, objekt, kommentar, foto, video, mätvärde, AI-fråga, AI-svar, resultat. Ingenting får försvinna. Loggen ska vara revisionssäker.
+
+---
+
+## Tidrapportering
+
+När objektet identifierats startar arbetstiden. Vid längre inaktivitet ber systemet om en kort beskrivning av vad som gjorts. Slutrapporten visar total tid fördelad på moment (provkörning, diagnos, administration …).
+
+---
+
+## Ärendebrief
+
+AI håller alltid en levande sammanfattning. När en annan tekniker öppnar ärendet visas automatiskt: vad kunden beskriver, vad som gjorts, vad som verifierats, vad som återstår, rekommenderade nästa steg och total arbetstid.
+
+---
+
+## Verifierade checklistor
+
+En kontrollpunkt är inte slutförd enbart genom en kryssruta — varje kontroll samlar bevis och kontext (observation, mätvärde, foto) med minimikrav anpassade efter kontrolltyp. Se [modulen](moduler/verifierade-checklistor.md).
+
+---
+
+## Samarbete
+
+Flera tekniker kan arbeta samtidigt. Alla ser bilder, filmer, mätningar, anteckningar, AI-sammanfattning, status och rekommendationer.
+
+---
+
+## Kundrapport och Live Share
+
+Kundrapporten genereras automatiskt (objekt, felbeskrivning, bilder, tester, mätvärden, utförda kontroller, tid, rekommendation, nästa steg) och delas som PDF, länk eller API. Varje ärende kan dessutom publiceras via en säker, behörighetsstyrd delningslänk som uppdateras i realtid — se [Live Share-modulen](moduler/live-share.md). Alla exporter versionsmärks (version, datum, tid, vem, format).
+
+---
+
+## API First
+
+Bygg hela systemet API-first. Alla resurser ska kunna skapas, läsas, uppdateras, exporteras och integreras. Dokumentera API:erna med OpenAPI/Swagger.
+
+---
+
+## Integrationer
+
+Förbered integrationsramverk för DMS, ERP, CRM, elektroniska serviceböcker, tidredovisning, fakturering, reservdelssystem och tillverkarsystem via kundens egna behörigheter. Modulär integrationsarkitektur så att nya integrationer läggs till utan att påverka kärnplattformen.
+
+---
+
+## Infrastruktur
+
+Bygg för produktion. Exempel på målarkitektur: AWS, Kubernetes, Docker, PostgreSQL, Redis, objektlagring, CDN, automatisk skalning, lastbalansering, backup, central loggning, övervakning, CI/CD, Infrastructure as Code.
+
+---
+
+## Säkerhet
+
+Rollbaserad åtkomst, kryptering i vila och under överföring, säker API-autentisering, revisionsloggar, principen om minsta behörighet, säker hantering av API-nycklar och hemligheter. Utforma systemet så att det kan uppfylla relevanta krav, exempelvis GDPR, beroende på hur kunden använder tjänsten.
+
+---
+
+## Beta-fokus
+
+Prioritera ett litet antal funktioner med hög kvalitet framför många halvfärdiga funktioner.
+
+MVP ska innehålla: inloggning, organisation (tenant), användarhantering, starta ärende, objektidentifiering, AI-guidad felsökning, kamera och bildanalys, arbetslogg, tidrapportering, ärendebrief, kundrapport, API, administration.
+
+All övrig funktionalitet planeras för senare versioner.
+
+---
+
+## Slutmål
+
+Bygg en plattform som känns lika självklar för en mekaniker eller servicetekniker som ett diagnosinstrument är idag. Fokus på snabbhet, tydlighet, metodisk vägledning och spårbar dokumentation. När en användare öppnar appen ska den upplevas som ett pålitligt professionellt verktyg — inte som en generell AI-chatt. Det ska vara enkelt att komma igång, enkelt att samarbeta och enkelt att visa kunden exakt hur felsökningen har genomförts.

felsokning/docs/MVP.md

@@ -0,0 +1,75 @@
+# Guidad Felsökning – MVP
+
+Första körbara versionen av kärnan i [Master Prompt v1.0](MASTER-PROMPT.md). Byggd som en fristående del av denna kodbas under `/felsokning`.
+
+## Kör
+
+```sh
+npm install
+npm run dev        # öppna http://localhost:8080/felsokning
+npm test           # projektions-, synk- och demotester
+npm run typkontroll # tsc --noEmit (vite build typkontrollerar inte)
+```
+
+**Förhandsvisning som en enda fil** (t.ex. för delning) byggs med
+hash-routing, annars fungerar den bara när den serveras från roten:
+
+```sh
+VITE_HASH_ROUTER=1 npm run build
+```
+
+I det läget är `/` Guidad Felsökning i stället för värdapplikationens
+startsida, och sidan fungerar oavsett vilken sökväg den ligger på.
+
+Demomanus för visning: [DEMO.md](DEMO.md). Knappen **Skapa demoärende** på startsidan lägger in ett komplett vibrationsärende med 1 tim 35 min historik.
+
+## Vad som ingår
+
+| Direktivets kärna | Status i MVP |
+| --- | --- |
+| Objektidentifiering först | ✅ **QR-/streckkodsläsning** (`src/felsokning/streckkod.ts`): kameraströmmen läser QR, Code 39/128, Data Matrix och PDF417 via webbläsarens BarcodeDetector. Avläst kod klassificeras innan den används — VIN (17 tecken utan I/O/Q), svenskt regnr (båda serierna) eller serienummer — och identifieraren plockas ut även ur QR-innehåll som URL:er eller `vin=…`-fält; fritext och nakna URL:er avvisas. Saknar webbläsaren API:t (t.ex. iOS/Safari) **fotograferas typskylten** i stället och plattformens bildtolkning läser av den — kameran är gränssnittet oavsett enhet. Manuell inmatning med bekräftelsesteg finns kvar. |
+| AI-guidad felsökning | ✅ Deterministisk metodikmotor (en fråga i taget, tre metodiker) **plus Claude-orkestern driven av plattformen**: edge-funktionen `felsokning-ai` äger Claude API-nyckeln (serverhemligheten `ANTHROPIC_API_KEY`) och routar per uppgift — handledning i realtid (Sonnet 5), djupgranskning av hela underlaget via knapp i briefen (Opus 5, hög effort), AI-komplettering av överlämningen med risker & osäkerheter (Sonnet 5) och metodikklassificering av felbeskrivningen (Haiku 4.5). Alla svar är schema-bundna och klassificerade enligt AI-reglerna, med automatisk fallback till Anthropics rekommenderade reservmodell vid avböjd förfrågan; modellen som svarade loggas i varje händelse. Kräver inloggad användare; svaren är interna och delas aldrig i kundvyer. I lokalt läge guidar metodiken ensam. |
+| Arbetslogg | ✅ Append-only händelselogg med tidsstämpel och användare på varje post. Ingenting skrivs över. |
+| Tidredovisning | ✅ Kategorier (aktiv felsökning, väntetid, provkörning …) via kategoribyten i loggen; paus räknas inte i total tid. Inaktivitetsfråga efter 20 min utan händelser. |
+| Dokumentation | ✅ Observationer, mätvärden, foton (nedskalade), **video med ljud** (E3-evidens för det som låter eller rör sig — kort klipp med obligatorisk beskrivning, hård storleksgräns, originalfilen bevaras och visas i logg, rapport och Live Share), kommentarer och hypoteser. Hypoteser märks alltid som ej verifierade och kan aldrig loggas som konstaterade fel. **Avslutet signeras automatiskt** av teknikern (”Felsökning avslutad — signerad av …”), redovisat i kvalitetsgrinden. |
+| Ärendebrief | ✅ Regenereras ur loggen vid varje visning: utförda kontroller, observationer, **ej kontrollerat**, rekommenderat nästa steg, tillförlitlighet, total arbetstid. |
+| Överlämning | ✅ ”Lämna över arbete” genererar överlämningsrapport ur briefen och loggar överlämningen. |
+| Kundrapport | ✅ Tidslinjevy utan interna poster, med bilder och tidsfördelning. Utskrift/PDF via webbläsaren, med påminnelse om granskning före delning. |
+| Röstinmatning (tal in, text ut) | ✅ Push-to-Talk via webbläsarens taligenkänning (sv-SE): lyssnar bara efter aktivt tryck, röd indikator med realtidstranskript, texten hamnar i ett redigerbart fält och skickas aldrig automatiskt. Knappen visas bara i webbläsare med talstöd. Produktionsversionen byter motor till leverantörens Voice-to-Text bakom samma gränssnitt. |
+| Verifierade checklistor | ✅ Varje kontroll i metodiken har ett minimikrav (foto, mätvärde eller kort observation). Foto-kontroller verifieras med bild; mätningar kan inte markeras verifierade utan värde. |
+| Export | ✅ Versionsmärkt JSON-export (version = antal händelser vid exporttillfället, med användare och tidpunkt); exporten loggas själv som händelse. PDF via utskrift. CSV och API i backend-fasen. |
+| Multi-tenant & roller | ✅ I självhostat läge: registrering skapar organisation + systemadministratör; admin hanterar användare (tekniker/arbetsledare/admin) via UI; all ärendedata organisationsisolerad i API:t; roll + organisation i JWT:n. **Arbetsledarvy** (`/felsokning/oversikt`): organisationens alla ärenden med status, deltagande tekniker och statistik (pågående/avslutade/ledtid) — härlett ur händelseloggen; ärenden kan hämtas till enheten med konfliktfri flätning. **Felorsaksstatistik** (flottdata): orsakskategorierna ur alla felorsaksanalyser aggregeras per organisation och visas som stapelöversikt i arbetsledarvyn. **Ansvarig tekniker** per ärende härleds ur loggen (skapare → överlämning → omfördelning) och arbetsledaren kan omfördela pågående ärenden — loggat som den organisationsinterna händelsen `ansvarig_satt`, aldrig synlig i kund-/partnerdelningar. Integrationstestat mot riktig Postgres (isolering, rollstyrning, append-only, översiktens behörighet och härledningar). |
+| Backend & synk | ✅ Databas-migration (`supabase/migrations/20260802230000_guidad_felsokning.sql`): ärenden + händelser med RLS, append-only även i databasen (inga update/delete-rättigheter). Synklager i klienten: konfliktfri ihopflätning av händelser per id (testad), push av lokala + pull av kollegors händelser var 15:e sekund. Utan inloggning arbetar appen i lokalt läge; status visas i ärendehuvudet. |
+| Metodiker | ✅ Tre: vibration, elsystem/strömförsörjning (relä-exemplet ur visionen) och generisk — vald automatiskt utifrån felbeskrivningen. |
+| Live Share | ✅ **Delningsgränsen är en tillåtelselista**: händelsetyper räknas upp per nivå (kund/partner/intern) i stället för att nekas en och en, så en ny händelsetyp är intern tills någon aktivt släpper fram den — låst av ett test som kräver att varje typ i domänmodellen är klassificerad. Skrivskyddad livevy per ärende (`/felsokning/dela/:id`): status ✔/🔄/⏳, bilder, mätvärdestabell, tidslinje, rekommenderat nästa steg. Uppdateras automatiskt, interna poster filtreras bort. Publik delningssida (`/felsokning/delad/:kod`) läser via `hamta_delat_arende` utan inloggning och pollar för liveuppdatering; "Kopiera delningslänk" finns i rapportfliken. **Behörighetsnivåer**: återkallbara delningslänkar per nivå — kund (det kunddelbara), extern partner (även hypoteser, märkta ej verifierade), intern (full insyn) — med serverstyrd filtrering, hanterade från rapportfliken i självhostat läge. |
+| Dashboard | ✅ Enligt direktivet: räknare och filter för Alla/Pågående/Klara plus Starta nytt ärende. |
+| Ärendestart via arbetsorder | ✅ Primärvägen när ett ärende startas: fota arbetsorderns framsida — orkesterns dokumenttolkning (Claude Sonnet 5, vision) läser kund-, fordons- och verkstadsuppgifter oavsett layout och sätter konfidens per fält. 🟢 ≥95 % godkänns automatiskt, 🟡 80–95 % markeras för genomläsning, 🔴 <80 % kräver aktiv bekräftelse — teknikern granskar bara osäkra fält. Visuell granskning med dokumentet bredvid fälten (klick markerar ungefärlig position), sedan skapas hela ärendet med ett tryck. Tolkningen loggas som organisationsintern händelse (`arbetsorder_skannad`) och delas aldrig i kund-/partnervyer. Manuell inmatning finns kvar som andrahandsväg; i lokalt läge visas en tydligt märkt demo-tolkning. Inloggade användare tillfrågas aldrig om namn — kontot vet redan. |
+| 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). **ECM Knowledge Library**: compliance-reglerna är deklarativ data som serveras av plattformen (`GET /api/ecm/regler`, utbytbar via ConfigMap) — uppdateras i driften utan appändring; klienten cachar och faller tillbaka till inbyggt standardpaket offline. |
+| Pre-diagnostik | ✅ Ingen felsökning förrän grundkontrollerna är gjorda eller motiverade: fordonshistorik — tidigare ärenden på samma fordon hämtas automatiskt med sina felorsaker (server i inloggat läge, lokala storen annars) och orsakskedjan kopplas med ett tryck; Ja/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. |
+| Kundgodkännande | ✅ Åtgärdsförslag lämnas till kund innan arbetet påbörjas (förifyllt ur felorsaksanalysen, med uppskattad kostnad) och **visas i Live Share** — kunden ser vad som föreslås. Kundens besked registreras med utfall, kanal (telefon/på plats/e-post/SMS/delningslänk) och motivering vid avböjt. Åtgärdsknappen är låst tills beskedet finns och förblir låst vid avböjt; kvalitetsgrinden flaggar hårt om arbete utförts trots avböjt förslag. **Kunden kan även svara direkt i sin delningslänk** — den enda skrivande publika vägen, med sex spärrar (endast kundnivå, ej återkallad, förslag måste finnas, ett besked per ärende, begränsat innehåll, takt-begränsning), samtliga verifierade i integrationstestet. |
+| Åtgärd och kvalitetskontroll | ✅ Arbetsflödets sista led: åtgärden dokumenteras (vad som gjordes + delar) eller motiveras varför den uteblev (kunden avböjde, väntar på reservdel …). Har en åtgärd utförts krävs **kvalitetskontroll** — symptomet borta / kvarstår / delvis / kunde inte verifieras, med beskrivning av hur det verifierades under samma förhållanden som symptomet reproducerades. Kvarstående symptom flaggas i grinden i stället för att döljas. Avslutsknappen är spärrad tills hela kedjan symptomverifiering → felorsak → åtgärd → kvalitetskontroll är komplett; rapporten har ett eget avsnitt ”Utförd åtgärd och verifiering”. |
+| Ä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. |
+| Märkesspecifika kopplingar | ✅ Verkstaden konfigurerar sina egna OEM-/fordonsdataleverantörer under Inställningar med sina egna credentials ([moduler/markesspecifika-kopplingar.md](moduler/markesspecifika-kopplingar.md)): uppgifterna krypteras med AES-256-GCM i vila, returneras alltid maskerade (`••••3456`) och **alla uppslag görs av servern** — leverantörsnycklar når aldrig webbläsaren. Endast systemadministratören hanterar dem, kopplingarna är organisationsknutna och saknas krypteringsnyckeln sparas ingenting alls (fail closed). Leverantörer är data, inte kod: URL-mall, autentiseringstyp (bearer/header/basic/query) och svarsmappning beskrivs i `integrationer.json` (ConfigMap-utbytbar via `INTEGRATIONER_FIL`) — nya märken läggs till utan ombyggnad. Varje uppslag loggar teststatus, så ett utgånget abonnemang syns i inställningarna i stället för att ge tysta tomma svar. Verifierat i integrationstestet (rollstyrning, maskering, kryptering i databasen, organisationsisolering, fail closed). |
+| Bilagor | ✅ Foton, video och instrumentbilder ligger **utanför händelsen**; loggen bär en referens med innehållets SHA-256. Det stärker bevisvärdet: hashen står i den append-only-skyddade loggen, så en utbytt bild går att upptäcka — och innehållet kontrolleras mot hashen varje gång det lämnas ut (409 i stället för att visa bilden). Innehållsadresserat, så samma foto lagras en gång. Två lägen: `databas` (bytea, fungerar överallt) och `s3` (AWS/MinIO/Ceph) med egen SigV4-signering som korsverifieras bit för bit mot botocore i testerna. Delningsgränsen gäller även bilagor — den skannade arbetsordern nås aldrig via kundlänken. Äldre händelser med inbäddad data-URL fortsätter fungera för alltid, och lokalt läge bäddar in som förut så dokumentation aldrig går förlorad utan nät. |
+| Åtkomstkontroll | ✅ **Återkallelse är omedelbar**: varje autentiserat anrop kontrollerar att kontot är aktivt och att token-versionen stämmer, i stället för att en avstängning börjar gälla när token går ut. Administratören stänger av och öppnar konton i användarlistan (kan inte stänga av sig själv, aldrig över organisationsgränsen), och var och en kan logga ut på alla enheter när en telefon tappats bort. **Takt-begränsning på inloggning** ligger i databasen och håller därför bakom flera repliker: 10 försök per konto och 30 per källadress inom 15 minuter, och spärren gäller kontot även vid rätt lösenord. Samtliga gränser verifierade i integrationstestet. |
+| Infrastruktur som kod | ✅ `infra/terraform` är systemets definition ([README](../infra/terraform/README.md)): `karta.tf` beskriver hela systemet en gång som data — tjänster, portar, routing, hemligheter per tjänst, dataflöden och gränser — och `terraform output karta` skriver ut samma sak i klartext. Namnrymden är stängd med nätverkspolicyer (bara ingress→tjänster, plattform→postgres, HTTPS ut utom privata nät), Postgres kör med säkerhetskontext, hemligheter kan genereras eller komma från en secrets-hanterare. **Databasen har tre lägen** och `databas_lage` saknar standardvärde med flit — valet avgör om det finns säkerhetskopiering: `extern` (managerad Postgres, leverantörens PITR — rekommenderat i produktion), `cnpg` (CloudNativePG i klustret: basbackup 02:30 + WAL-arkivering + failover) och `inbyggd` (en volym, ingen backup, spärrad av en precondition när miljön är produktion). Driftsättning är ett eget CI-flöde som startas för hand med en bildtagg mot en miljö med godkännandekrav, kör plan/apply, skriver ut kartan och rökkontrollerar. Kustomize-/Argo CD-vägen är borttagen. |
+| Öppet API | ✅ Plattforms-API:t är dokumenterat med OpenAPI 3.0 (`services/plattform/openapi.yaml`) — auth, användare, ärenden/händelser (append-only), översikt, publik delning och AI-orkestern, med scheman för alla händelsetyper. Specen valideras maskinellt, paritetstestas mot serverns rutter och serveras live på `GET /api/openapi.yaml`. |
+
+## Arkitekturprinciper i koden
+
+- **Händelseloggen är enda sanningskällan.** `src/felsokning/domain.ts` definierar händelsetyperna; poster läggs endast till.
+- **Alla vyer är projektioner.** `src/felsokning/projektioner.ts` — brief, tidsfördelning, överlämningstext och kundrapport är rena funktioner av loggen och kan alltid regenereras. Testerna i `src/felsokning/__tests__/` låser detta.
+- **Metodikmotorn är deterministisk.** `src/felsokning/metodik.ts` — nästa steg härleds ur vad som redan dokumenterats. Det är här den framtida AI:n ansluter, utan att logg eller projektioner ändras.
+- **Ingen slutsats utan evidens.** `src/felsokning/ecm.ts` — regelmotorn (ECM) validerar varje påstående mot händelseloggen: fullbordansregler, evidensnivåer och kvalitetsgrind. Kameran är integrationslagret (visual-first) — det som syns på en skärm eller ett instrument fotograferas och tolkas i stället för att integreras.
+- **Terminologi.** Produkten beskrivs som ett evidensbaserat diagnossystem/intelligent beslutsstöd — i UI och kundkommunikation används *systemet/analysen/bedömningen/beslutsstödet*, aldrig "AI" om det inte är tekniskt nödvändigt.
+- **Egen ikongrafik.** `src/felsokning/ikoner.tsx` — enkla industriella linjeikoner (SVG, stroke i aktuell textfärg) i stället för emojis; tillförlitlighets- och statusnivåer visas som färgpunkter.
+- **Industriellt verkstads-UI (ETKA-inspirerat).** `src/felsokning/ui.tsx` — plana ljusgrå ytor (#ECECEC/#F7F7F7), skarpa kanter, djup marinblå som primärfärg, tät typografi (11–15 px), rektangulära knappar (max 4 px radie), verktygsrad ~44 px. Ärendesidan har klassisk trekolumnslayout på skrivbord: navigationsträd (vyer + metodikstegens status) till vänster, arbetsyta i mitten, kontextpanel (teknisk information, tillförlitlighet, teknisk rekommendation) till höger; en kolumn med flikrad på smala skärmar.
+
+## Medvetna avgränsningar
+
+- Ramen för tillverkarintegrationer finns (kunden lägger in sina egna credentials och slår upp fordonsuppgifter), men de anrikade datamängderna — utrustningsnivå, återkallelser, TSB:er — mappas inte ännu; registret behöver fler svarsfält och leverantörsprofiler innan det är meningsfullt.

felsokning/docs/VISION.md

@@ -0,0 +1,180 @@
+# Guidad Felsökning
+
+> Styrdokument för utveckling: [Master Prompt v2.0](MASTER-PROMPT.md)
+
+## Vision
+
+Guidad Felsökning är en professionell diagnostikplattform som steg för steg vägleder tekniker genom en strukturerad felsökningsprocess. Plattformen dokumenterar varje moment, hämtar information från tillverkarens system via användarens egna behörigheter och skapar en komplett, spårbar felsökningshistorik.
+
+Systemet ersätter inte teknikerens kompetens – det säkerställer att arbetet utförs metodiskt, dokumenteras korrekt och kan följas i efterhand.
+
+Produkten ska inte försöka vara en AI-mekaniker, utan en **digital felsökningshandledare**. Det gör den både mer trovärdig och lättare att använda i professionella miljöer.
+
+---
+
+## Ledstjärna
+
+> **Systemet dokumenterar observationer, leder användaren genom verifierbara kontroller och rekommenderar nästa steg – men presenterar aldrig en hypotes som ett konstaterat fel.**
+
+Den principen gör verktyget användbart både för erfarna tekniker och för mindre erfarna användare, samtidigt som det ger ett robust underlag för kunder, verkstäder och framtida analyser. Guidad Felsökning är en digital diagnostikprocess, inte en AI-chat.
+
+---
+
+## Grundprinciper
+
+### 1. Ingen gissning
+
+Systemet får aldrig presentera spekulation som fakta.
+
+Varje påstående märks med en tillförlitlighetsnivå:
+
+- 🟢 **Hög** – verifierat genom mätning, tillverkarinformation eller användarens inmatning.
+- 🟡 **Medel** – logisk slutsats baserad på tillgänglig information.
+- 🔴 **Låg** – hypotes eller möjlig felorsak som kräver verifiering.
+
+Om tillräckligt underlag saknas ska systemet uttryckligen säga det.
+
+### 2. Identifiera objektet först
+
+Ingen felsökning börjar innan objektet identifierats.
+
+Identifiering kan ske genom:
+
+- registreringsnummer
+- VIN
+- maskinnummer
+- serienummer
+- QR-kod
+- streckkod
+- OCR från typskylt
+- foto av objektet
+- manuell inmatning av objekt-ID
+
+När identifieringen är klar visas en tydlig bekräftelse innan felsökningen fortsätter.
+
+### 3. Integration med tillverkarsystem
+
+Användaren ansluter sina egna behörigheter via API eller motsvarande integrationslösning.
+
+Exempel på informationskällor:
+
+- tillverkarens verkstadssystem
+- reservdelskataloger
+- elscheman
+- servicebulletiner
+- servicehistorik
+- elektroniska serviceböcker
+- interna DMS-system
+
+Guidad Felsökning använder dessa som referens men lagrar inte upphovsrättsskyddad dokumentation om inte användaren eller organisationen har rätt att göra det.
+
+### 4. Samtalsbaserad guidning
+
+Teknikern arbetar naturligt:
+
+> ”Jag har mätt.”
+>
+> ”Det finns 13,9 volt.”
+>
+> ”Reläet klickar inte.”
+
+Systemet väljer nästa steg utifrån tidigare observationer och den etablerade felsökningsmetodiken.
+
+### 5. Fullständig revisionslogg
+
+Varje aktivitet registreras.
+
+Exempel på loggposter:
+
+- tidpunkt
+- användare
+- objekt
+- mätvärden
+- bilder
+- dokument
+- observationer
+- AI:s rekommendation
+- användarens svar
+- nästa steg
+
+Ingenting skrivs över. Händelser läggs endast till, vilket ger full spårbarhet.
+
+### 6. Export och API
+
+Varje avslutat ärende kan exporteras som ett strukturerat felsökningsprotokoll.
+
+Det ska även finnas ett API för att:
+
+- hämta loggar
+- hämta rapporter
+- koppla mot DMS
+- koppla mot affärssystem
+- koppla mot ERP
+- koppla mot elektroniska serviceböcker
+- koppla mot garantiadministration
+
+På så sätt blir Guidad Felsökning en komponent i befintliga arbetsflöden, inte ett isolerat system.
+
+---
+
+## Moduler
+
+Utöver grundprinciperna byggs plattformen upp av moduler som specificeras separat:
+
+- [Arbetslogg & Tidredovisning](moduler/arbetslogg-och-tidredovisning.md) – tidsatt, spårbart arbete kopplat till konkreta aktiviteter; ett digitalt arbetsprotokoll där tid, aktivitet och tekniskt resonemang hänger ihop.
+- [Delningsbar kundrapport (Kundvy)](moduler/kundrapport.md) – en tydlig tidslinje med bilder, mätvärden och kommentarer som visar kunden vad de faktiskt betalat för.
+- [Ärendebrief](moduler/arendebrief.md) – en löpande uppdaterad arbetsbild av ärendet som gör att en ny tekniker blir produktiv på under en minut; fleranvändararbetsyta med överlämning med ett klick.
+- [Kommunikationsmodell (röst)](moduler/kommunikationsmodell.md) – tal in, text ut via Push-to-Talk; röst är ett inmatningssätt, inte ett separat gränssnitt, och inget skickas utan bekräftelse.
+- [Verifierade checklistor](moduler/verifierade-checklistor.md) – en kontrollpunkt är inte slutförd genom en kryssruta; varje kontroll samlar bevis och kontext med minimikrav per kontrolltyp.
+- [Live Share](moduler/live-share.md) – behörighetsstyrd delningslänk som visar ärendet i realtid; versionsmärkta exporter ur samma händelselogg.
+
+Hur processen fungerar i praktiken illustreras i exempelflödet [”Bilen vibrerar runt 88 km/h”](exempel/vibration-vid-88-km-h.md).
+
+---
+
+## Användargränssnitt
+
+Gränssnittet ska vara avsiktligt enkelt.
+
+Ingen chatt med långa AI-svar.
+
+Istället:
+
+- en fråga i taget
+- en tydlig rekommenderad åtgärd
+- stora knappar
+- tydliga statusindikatorer
+- hög kontrast
+- få val per skärm
+
+Designen ska ge samma känsla som ett modernt fabriksverktyg: funktion före estetik.
+
+---
+
+## Säkerhet
+
+Systemet ska utformas för professionell användning med fokus på informationssäkerhet.
+
+Målet är att:
+
+- kryptera data under överföring och lagring,
+- logga alla förändringar och åtkomster,
+- stödja rollbaserad behörighetsstyrning,
+- erbjuda säker API-autentisering,
+- möjliggöra export och radering enligt organisationens policy och tillämpliga regelverk.
+
+---
+
+## Produktfilosofi
+
+Den viktigaste principen är att Guidad Felsökning aldrig försöker ersätta teknikern.
+
+Den ersätter inte erfarenhet.
+
+Den ersätter inte tillverkarens dokumentation.
+
+Den ersätter inte verkstadshandboken.
+
+Den fungerar som en konsekvent arbetsledare som säkerställer att rätt frågor ställs i rätt ordning, att inga steg förbises och att hela felsökningsprocessen dokumenteras på ett sätt som är spårbart, återanvändbart och enkelt att integrera med övriga verksamhetssystem.
+
+Det gör att verkstäder och serviceorganisationer får högre kvalitet, jämnare arbetssätt, bättre kunskapsöverföring mellan tekniker och ett tydligt underlag gentemot kunder, garantihantering och intern uppföljning.

felsokning/docs/exempel/vibration-vid-88-km-h.md

@@ -0,0 +1,99 @@
+# Exempelflöde: ”Bilen vibrerar runt 88 km/h”
+
+Det här exemplet illustrerar hur Guidad Felsökning fungerar i praktiken: en digital diagnostikprocess, inte en AI-chat. AI:n hoppar inte direkt till ”det är nog hjulbalansering”, utan följer en reproducerbar metod.
+
+---
+
+## Ärende
+
+**Kundens beskrivning**
+
+> ”Bilen vibrerar runt 88 km/h.”
+
+---
+
+## Steg 1 – Verifiera symptom
+
+Systemet frågar:
+
+- Är vibrationen hastighetsberoende?
+- Känns den i ratten, stolen eller hela bilen?
+- Sker den vid acceleration, jämn fart eller inbromsning?
+- Försvinner den över eller under ett visst hastighetsintervall?
+
+När svaren finns dokumenterade går processen vidare.
+
+---
+
+## Steg 2 – Visuell kontroll
+
+Systemet ber teknikern att fotografera:
+
+- Vänster framhjul
+- Höger framhjul
+- Vänster bakhjul
+- Höger bakhjul
+
+Bildanalysen kan därefter hjälpa till att identifiera sådant som faktiskt går att observera, till exempel:
+
+- däckets DOT-/tillverkningsdatum (via OCR),
+- ovanligt eller ojämnt slitage,
+- synliga skador eller deformationer,
+- saknade eller lösa balanseringsvikter om de är tydligt synliga,
+- felaktig däckdimension eller olika däcktyper.
+
+Det viktiga är att systemet skiljer på **observation** och **slutsats**. Exempelvis kan det säga:
+
+> ”En balanseringsvikt verkar saknas på höger framhjul. Kontrollera hjulet manuellt.”
+
+i stället för att slå fast att det är orsaken till felet.
+
+---
+
+## Steg 3 – Rekommenderade kontroller
+
+Därefter föreslår systemet nästa steg, exempelvis:
+
+- kontrollera lufttryck,
+- kontrollera hjulmoment,
+- kontrollera radial- och sidokast,
+- kontrollera hjulbalansering,
+- kontrollera bussningar och leder,
+- genomför provkörning.
+
+Varje punkt bockas av och dokumenteras.
+
+---
+
+## Steg 4 – Provkörning
+
+Systemet sammanfattar vad som ska verifieras under provkörningen:
+
+- Hastighet där vibration uppstår.
+- Förändring vid acceleration.
+- Förändring vid motorbroms.
+- Förändring vid kurvtagning.
+- Om vibration känns i ratt eller kaross.
+
+---
+
+## Steg 5 – Sammanfattning
+
+När teknikern väljer att pausa eller avsluta arbetet genereras automatiskt en rapport, exempelvis:
+
+**Utförda kontroller**
+
+- Fyra hjul fotograferade.
+- DOT-koder dokumenterade.
+- Däckslitage kontrollerat.
+- Lufttryck verifierat.
+- Hjulbalansering kontrollerad.
+- Provkörning genomförd.
+
+**Resultat**
+
+Observationer och mätvärden sammanfattas utan att systemet drar slutsatser som saknar stöd.
+
+**Rekommenderade nästa steg**
+
+Exempelvis kontroll av drivaxlar, hjullager eller andra komponenter om tidigare kontroller inte identifierat orsaken.

felsokning/docs/moduler/arbetslogg-och-tidredovisning.md

@@ -0,0 +1,128 @@
+# Modul: Arbetslogg & Tidredovisning
+
+## Syfte
+
+Allt arbete som utförs under ett felsökningsärende ska vara tidsatt, spårbart och kopplat till konkreta aktiviteter.
+
+Systemet registrerar inte bara hur lång tid ett arbete tagit, utan även vad som utförts under tiden.
+
+Det här är mer än en stämpelklocka – ett digitalt arbetsprotokoll där tid, aktivitet och tekniskt resonemang hänger ihop. Det ger ett betydligt starkare underlag än traditionell tidrapportering.
+
+---
+
+## Start av arbete
+
+Teknikern börjar genom att identifiera objektet.
+
+Exempel:
+
+- Foto av registreringsnummer
+- VIN-skanning
+- QR-kod
+- Serienummer
+- Maskinnummer
+
+När objektet är verifierat startar arbetsloggen.
+
+Exempel:
+
+```
+08:03  Arbete startat
+       Objekt: ABC123
+       Volvo XC60
+```
+
+---
+
+## Automatisk tidslinje
+
+Alla aktiviteter tidsstämplas automatiskt.
+
+Exempel:
+
+```
+08:03  Objekt identifierat
+08:05  Felbeskrivning registrerad
+08:11  Säkring F23 kontrollerad
+08:18  Mätning av matningsspänning
+08:27  Foto uppladdat
+08:35  Direktmatning utförd
+08:48  Elschema öppnat
+09:01  Ny kontroll
+09:09  Felsökning avslutad
+```
+
+Ingen manuell administration krävs.
+
+---
+
+## Aktiv arbetstid
+
+Systemet skiljer på:
+
+- aktiv felsökning
+- väntetid
+- administrativ tid
+- reservdelssökning
+- provkörning
+- kundkontakt
+
+Det ger en mer rättvisande tidsredovisning.
+
+---
+
+## Kontext vid längre avbrott
+
+Om det gått en längre stund utan aktivitet kan systemet fråga efter sammanhang, exempelvis:
+
+> ”Ingen aktivitet har registrerats de senaste 20 minuterna. Beskriv kort vad som gjorts under denna period.”
+
+Teknikern kan svara med text eller tal, till exempel:
+
+> ”Demonterade instrumentpanelen för att komma åt kabelstammen.”
+
+Det blir en del av arbetsloggen.
+
+---
+
+## AI som dokumentationsstöd
+
+AI bedömer inte om teknikern arbetar ”tillräckligt snabbt”. Däremot hjälper den till att säkerställa att loggen blir begriplig och komplett. Om ett steg saknar sammanhang kan den be om ett kort förtydligande så att rapporten blir användbar för kunden eller den egna organisationen.
+
+---
+
+## Slutrapport
+
+När arbetet avslutas genereras automatiskt en rapport med exempelvis:
+
+**Total tid: 1 timme 37 minuter**
+
+Fördelning:
+
+- Diagnos: 54 min
+- Demontering: 18 min
+- Mätningar: 11 min
+- Dokumentation: 6 min
+- Provkörning: 8 min
+
+Rapporten innehåller även:
+
+- utförda kontroller,
+- mätvärden,
+- bifogade bilder,
+- tekniska slutsatser,
+- rekommenderade nästa steg.
+
+---
+
+## Affärsvärde
+
+Den här funktionen kan bli ett av systemets starkaste argument, eftersom den:
+
+- minskar administration efter avslutat arbete,
+- ger kunden ett tydligt underlag för debiteringen,
+- stärker underlaget vid garanti- och försäkringsärenden,
+- gör intern uppföljning enklare,
+- skapar en sökbar kunskapsbank över tidigare felsökningar.
+
+Det gör att Guidad Felsökning blir mer än en AI-assistent – den blir ett komplett arbetsverktyg där identifiering, metodisk felsökning, dokumentation och tidredovisning bildar en sammanhängande och spårbar process.

felsokning/docs/moduler/arendebrief.md

@@ -0,0 +1,137 @@
+# Modul: Ärendebrief
+
+## Syfte
+
+När en ny tekniker tar över ett pågående ärende ska denne kunna bli produktiv på under en minut, utan att behöva läsa hela historiken.
+
+Systemet genererar automatiskt en strukturerad sammanfattning av ärendet som uppdateras löpande.
+
+Det här är inte en chatt, utan ett **levande ärende** där AI:n hela tiden håller en uppdaterad arbetsbild.
+
+---
+
+## Exempel
+
+**Objekt**
+
+> Volvo XC60 D4 2019
+> Reg.nr ABC123
+> Kund: Anders Svensson
+
+**Kundens beskrivning**
+
+> Bilen vibrerar runt 88 km/h.
+> Symptomet uppträder endast under körning.
+
+**Utförda kontroller**
+
+- ✓ Lufttryck kontrollerat
+- ✓ Hjulmoment kontrollerat
+- ✓ DOT-koder dokumenterade
+- ✓ Fyra hjul fotograferade
+- ✓ Provkörning genomförd
+- ✓ Balanseringsvikter kontrollerade
+
+**Observationer**
+
+- Höger framdäck visar ojämnt slitage.
+- Ingen uppenbar skada på fälgar.
+- Vibration känns främst i ratten.
+- Ingen förändring vid acceleration.
+
+**Ej kontrollerat**
+
+- Radialkast
+- Drivaxlar
+- Hjullager
+- Fyrhjulsmätning
+
+**Rekommenderat nästa steg**
+
+1. Mät radialkast.
+2. Kontrollera drivaxlar.
+3. Ny provkörning.
+
+**Total arbetstid**
+
+2 timmar 14 minuter
+
+**Tillförlitlighet**
+
+- 🟢 Kunduppgifter verifierade
+- 🟢 Bilder dokumenterade
+- 🟢 Mätvärden registrerade
+- 🟡 Felorsak ännu inte verifierad
+
+---
+
+## AI:s roll
+
+AI:n ska inte bara sammanfatta historiken, utan också hålla reda på ärendets aktuella läge. Om en ny tekniker ansluter ska systemet kunna svara på frågor som:
+
+- ”Vad återstår?”
+- ”Vad är mest sannolikt att kontrollera härnäst?”
+- ”Vilka tester är redan utförda?”
+- ”Finns det några motsägelsefulla observationer?”
+- ”Vad behöver verifieras innan vi går vidare?”
+
+---
+
+## Samarbete
+
+Detta byggs som ett riktigt fleranvändarsystem. Varje ärende blir en arbetsyta där flera personer kan delta.
+
+Exempel:
+
+```
+Ärende #45281
+Ansvarig:   Anna
+Deltagare:  Johan, Erik, Lisa
+```
+
+- Alla ser samma information i realtid.
+- Alla bilder hamnar i samma ärende.
+- Alla mätvärden hamnar i samma logg.
+- Alla kommentarer tidsstämplas.
+- Alla AI-sammanfattningar uppdateras automatiskt.
+
+---
+
+## Skiftbyte – Överlämning med ett klick
+
+Vid skiftbyte trycker teknikern bara på **Lämna över arbete**. Systemet genererar då automatiskt en överlämningsrapport.
+
+Den nya teknikern får:
+
+- vad kunden upplever,
+- vad som redan gjorts,
+- vilka mätningar som finns,
+- vilka bilder som tagits,
+- vilka slutsatser som kan dras med hög säkerhet,
+- vilka frågor som fortfarande är obesvarade,
+- nästa rekommenderade steg.
+
+Ingen behöver läsa igenom hundratals chattmeddelanden.
+
+Samma funktion används vid eskalering: när en tekniker lämnar sitt pass eller eskalerar ett ärende genereras automatiskt en kort briefing med:
+
+- nuläge,
+- verifierade fakta,
+- återstående arbete,
+- risker eller osäkerheter,
+- rekommenderade nästa steg.
+
+Det gör att nästa tekniker kan fortsätta arbetet nästan omedelbart, vilket är särskilt värdefullt i större verkstäder och serviceorganisationer där flera personer arbetar med samma objekt under olika skift.
+
+---
+
+## Arkitektur
+
+Modulen passar mycket bra med en multi-tenant SaaS-arkitektur:
+
+- **Tenant** = verkstad eller serviceorganisation.
+- **Användare** = tekniker, arbetsledare, verkstadschef, administratör.
+- **Ärende** = en delad arbetsyta med gemensam kontext.
+- **AI-kontext** = en strukturerad, löpande sammanfattning av ärendet som används för briefing och vägledning.
+
+Det sista är viktigt: AI:n bör inte behöva läsa hela historiken varje gång någon öppnar ett ärende. I stället underhålls en strukturerad ärendesammanfattning som uppdateras efter varje relevant händelse. Det gör systemet snabbare, billigare att köra och mer konsekvent, samtidigt som hela loggen fortfarande finns kvar för revision och export.

felsokning/docs/moduler/evidensmotor.md

@@ -0,0 +1,242 @@
+# Modul: Evidensmotorn (ECM — Evidence & Compliance Matrix)
+
+**Version: ECM v2.0** · ECM är ett eget subsystem — inte en tabell i
+databasen — och motorn som styr hela plattformen: den avgör vilken
+dokumentation som krävs, när dokumentation saknas, vilken bevisnivå som
+uppnåtts, vilka regler som gäller och om ett ärende kan avslutas.
+**Systemet kan aldrig skriva en slutsats som ECM inte har godkänt.**
+
+Regelbiblioteket är versionshanterat och skilt från applikationslogiken
+(`src/felsokning/ecm.ts`); vyerna anropar bara motorns rena funktioner.
+
+## De sex motorerna
+
+### 1. Evidence Engine
+Katalogiserar all bevisning ur händelseloggen. Varje evidenspost får
+id, tidpunkt, tekniker, kategori, evidensnivå, sammanfattning och
+**innehållshash** — samma post ger alltid samma hash, och den
+append-only-låsta loggen (databastriggers) gör varje ändringsförsök
+omöjligt.
+
+| Nivå | Typ | Bevisvärde |
+| --- | --- | --- |
+| E0 | Inget underlag | 0 % |
+| E1 | Teknikerns observation | Lågt |
+| E2 | Foto | Medel |
+| E3 | Video (med ljud — för det som låter eller rör sig) | Högt |
+| E4 | Mätvärde | Högt |
+| E5 | Diagnosdata/dokument | Mycket högt |
+| E6 | Flera oberoende källor | Högsta |
+
+### 2. Rule Engine
+Dokumentationskraven: metodikens `krav`-fält per kontroll plus de
+automatiska reglerna — *kan det fotograferas → begär foto; låter det →
+video med ljud; rör det sig → video; mäts det → mätvärde; visar en
+display informationen → fota displayen; finns ett dokument → fota
+dokumentet.* Undantagsorsakerna ("Underlag kan inte tas fram") ligger
+här.
+
+### 3. Compliance Engine
+Ärendetypen styr vilka regler som gäller utöver metodiken. Ärendetyp
+väljs i identitetsraden och loggas (`arendetyp_satt`):
+
+| Ärendetyp | Extra krav (v2.0) |
+| --- | --- |
+| Garanti | Miltal dokumenterat · servicehistorik kontrollerad · claim-/garantinummer |
+| Goodwill | Miltal · servicehistorik |
+| Försäkring | Skadenummer · bildbevis |
+| Reklamation | Historik och tidigare försök kontrollerade |
+| Begagnatgaranti | Miltal |
+
+**ECM Knowledge Library är implementerat**: reglerna är deklarativa data
+(krav-typ, inte kod) och distribueras från plattformen via
+`GET /api/ecm/regler` (`services/plattform/ecm-regler.json` — i klustret
+utbytbar via ConfigMap och miljövariabeln `ECM_REGLER_FIL`). Klienten
+hämtar paketet vid sidladdning, cachar det och faller tillbaka till sitt
+inbyggda standardpaket offline; trasiga paket och okända krav-typer
+filtreras. Regelpaketets version följer med i varje spårbarhetspaket.
+Nya regler — garantivillkor per tillverkare, försäkringsbolagens krav,
+reklamationslagstiftning, OEM-kontrollpunkter — läggs till i driften
+utan att applikationen byggs om.
+
+### 4. Validation Engine
+Inga påståenden utan underlag, i tre lager: (a) orkesterns grundprompt —
+aldrig "OK/kontrollerad/inga fel/åtgärdad" utan evidens, i stället
+"Evidens saknas" plus begäran om rätt underlag; (b) projektionerna —
+hypoteser kan aldrig bli konstaterade fel; (c) kvalitetsgrinden nedan.
+
+### 5. Completion Engine
+Kvalitetsgrinden före slutrapport/avslut — utskriften är spärrad tills
+alla obligatoriska rader är gröna:
+
+| Kontroll | Krav |
+| --- | --- |
+| Fordons-/objektidentifiering verifierad | Obligatorisk |
+| Arbetsorder inläst | Rekommenderas |
+| Fordonshistorik kontrollerad eller motiverad | Obligatorisk |
+| Ingående mätarställning dokumenterad | Obligatorisk |
+| Kundens felbeskrivning verifierad | Rekommenderas |
+| Kundens besked på åtgärdsförslaget | Obligatoriskt när arbete utförts |
+| Åtgärd dokumenterad eller motiverad | Obligatorisk vid avslut |
+| Kvalitetskontroll genomförd | Obligatorisk vid avslut efter utförd åtgärd |
+| Utgående mätarställning | Obligatorisk vid avslut |
+| Metodikens kontroller: evidens eller dokumenterat undantag | Obligatorisk |
+| Foton för fotokrävande kontroller | Obligatorisk |
+| Ärendetypens compliance-krav | Obligatoriska |
+| Teknikerns slutsats signerad | Automatisk vid avslut |
+| Evidensnivå över E0 | Obligatorisk |
+
+### 6. Traceability Engine
+Varje export bär ett spårbarhetspaket: ECM-version, ärendetyp,
+evidensnivå, grindstatus per regel-id och samtliga evidensposter med
+hash. Tillsammans med loggen kan varje slutsats härledas: vilken bild →
+vilken mätning → vilken tekniker → vilken regel → vilken regelverksversion
+→ när.
+
+## Pre-Diagnostic Validation
+
+Ingen felsökning påbörjas förrän grundkontrollerna är genomförda eller
+dokumenterat motiverade — metodiken låses upp först därefter:
+
+1. **Fordonshistorik** — systemet hämtar automatiskt organisationens
+   tidigare ärenden på samma objekt (regnr/VIN) med deras dokumenterade
+   felorsaker (`GET /api/fordon/{identifierare}/historik`; lokala storen
+   offline) och visar dem i historiksteget. Teknikern kan koppla
+   **orsakskedjan** till det aktuella ärendet med ett tryck ("kopplat
+   till tidigare ärende #N — …"), kvitterar kontrollen — eller anger Nej
+   med obligatorisk orsak → kvalitetsvarning.
+2. **Ingående mätarställning** — instrumentpanelen fotograferas;
+   bildtolkningen föreslår värdet, teknikern bekräftar. Fotot blir den
+   officiella ingående mätarställningen.
+3. **Kundens felbeskrivning verifierad** — ytterligare symptom
+   dokumenteras som separata observationer, aldrig hopblandade med
+   kundens beskrivning.
+4. **Tidiga observationer** — reparationsspår, modifieringar, skador,
+   läckage m.m. dokumenteras med foto/observation, eller kvitteras
+   "inga ytterligare".
+
+**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.
+Flottdatan är redan igång: **felorsaksstatistiken** i arbetsledarvyn
+(`GET /api/statistik/felorsaker`) aggregerar orsakskategorierna över
+organisationen — vilka komponenter fallerar av slitage, vilka efter
+tidigare reparationer, vilka tyder på konstruktionsproblem.
+
+## Kundgodkännande före arbete
+
+Verkstaden får aldrig utföra föreslaget arbete utan att kundens besked är
+registrerat och spårbart:
+
+- **Åtgärdsförslaget** skrivs i guiden (förifyllt ur felorsaksanalysens
+  rekommenderade åtgärd) med eventuell uppskattad kostnad, och **visas
+  för kunden i Live Share** — det är kunddelbart material.
+- **Kundens besked** registreras med utfall (godkänt/avböjt/delvis),
+  **kanal** (telefon, på plats, e-post, SMS, delningslänk) och
+  motivering vid avböjt/delvis. Loggposten bär vem i verkstaden som tog
+  emot beskedet och när.
+- **Knappen "Dokumentera utförd åtgärd" är låst** så länge ett förslag
+  saknar besked — och förblir låst vid avböjt besked. Vägen "Ingen
+  åtgärd utförd" är öppen och hänvisar till det registrerade beskedet.
+- Kvalitetsgrinden kräver registrerat besked när arbete utförts, och
+  flaggar konflikten *"Utfört arbete trots avböjt åtgärdsförslag"* som
+  ett hårt fel.
+
+**Kunden kan svara direkt i sin delningslänk** (`POST /api/delad/{kod}/beslut`)
+— den enda skrivande publika vägen i hela API:t, med sex spärrar som var
+och en verifieras i integrationstestet:
+
+1. Endast delningar på **kundnivå** (partner-/internlänkar får aldrig
+   svara åt kunden) och aldrig återkallade.
+2. Ärendets ursprungliga delningskod saknar registrerad nivå och kan inte
+   heller svara.
+3. Det måste finnas ett åtgärdsförslag att svara på.
+4. **Ett besked per ärende** — svaret kan inte ändras i efterhand
+   (kontakta verkstaden i stället).
+5. Endast `godkant`/`avbojt`/`delvis` plus en kommentar på högst 500
+   tecken; inget annat kan skrivas till loggen den vägen.
+6. Takt-begränsning per delningskod.
+
+Beskedet loggas som `kundbeslut` med kanal `Delningslänk` och avsändaren
+"Kund via delningslänk" — verkstadens egna registreringar (telefon, på
+plats …) fungerar precis som förut.
+
+## Åtgärdsfasen (Repair & Verification)
+
+Loopen som symptomverifieringen öppnade sluts här — ett ärende kan inte
+avslutas utan att det framgår vad som gjordes och om det hjälpte:
+
+1. **Åtgärd dokumenterad eller motiverad** — antingen vad som faktiskt
+   utfördes (med eventuella delar), eller varför ingen åtgärd gjordes
+   (kunden avböjde, väntar på reservdel, endast utredning beställd,
+   kostnadsförslag lämnat, åtgärd hos annan verkstad).
+2. **Kvalitetskontroll** — obligatorisk när en åtgärd faktiskt utförts:
+   är symptomet borta, kvarstår det helt eller delvis, eller kunde det
+   inte verifieras? Utfallet dokumenteras med hur verifieringen gick
+   till (samma förhållanden som symptomet reproducerades under).
+
+Kvarstående symptom döljs aldrig: grinden skriver ut att ärendet inte
+bör avslutas som åtgärdat. Avslutsknappen är spärrad tills kedjan
+**symptomverifiering → felorsaksanalys → åtgärd → kvalitetskontroll** är
+komplett, och rapporten redovisar den i egna avsnitt.
+
+## Ärendeidentitet (Case Identity & Vehicle Context)
+
+Fordonsobjektet är den röda tråden: identiteten registreras **en gång**
+(normalt via arbetsorderskanningen, som nu även läser claim-/garantinummer
+och skadenummer) och återanvänds sedan överallt:
+
+- **Identitetsrad i arbetsytan** — AO, claim, skadenummer, fordon, regnr,
+  VIN, miltal, ansvarig tekniker + ärendetypsval.
+- **Live Share** — låst panel överst med fordon, referenser och status,
+  härledd ur det nivåfiltrerade underlaget.
+- **Slutrapportens första sida** — Ärendeinformation + Fordonsinformation
+  automatiskt.
+- **Exporten** — identitet + spårbarhetspaket i varje JSON.
+
+## Terminologi
+
+Produkten beskrivs aldrig som en "AI-app" utan som ett **evidensbaserat
+diagnossystem** / **intelligent beslutsstöd**. I användargränssnitt och
+dokument används *systemet, analysen, bedömningen, tolkningen,
+bildtolkningen, beslutsstödet, regelmotorn* — inte "AI", om det inte är
+tekniskt nödvändigt.

felsokning/docs/moduler/kommunikationsmodell.md

@@ -0,0 +1,78 @@
+# Modul: Kommunikationsmodell (röst)
+
+## Grundprincip
+
+**Användaren pratar, systemet skriver.**
+
+Systemet använder tal-till-text (Voice-to-Text) för all röstinmatning. Teknikern ska aldrig behöva skriva med tangentbord under ett pågående arbete.
+
+Ingen röstagent: systemet för inte ett löpande röstsamtal, läser inte upp långa svar och försöker inte efterlikna en mänsklig konversation. Kommunikationen är **tal in, text ut**.
+
+## Viktig designprincip
+
+> All röst behandlas som ett inmatningssätt, inte som ett separat gränssnitt.
+
+All logik i systemet bygger på text. Voice-to-Text är endast ett sätt att skapa den texten. Det gör lösningen enklare att underhålla, enklare att söka i, enklare att exportera och enklare att utveckla vidare med nya AI-modeller i framtiden.
+
+## Arbetsflöde
+
+1. Teknikern trycker på mikrofonen: *"Jag har mätt mellan stift 14 och jord. Jag får 12,4 volt."*
+2. Voice-to-Text transkriberar talet.
+3. Den transkriberade texten skickas till AI:n som en vanlig textförfrågan.
+4. AI:n svarar alltid skriftligt: *Verifierat: Matningsspänning finns på stift 14. Nästa steg: Kontrollera jordanslutningen på stift 7.*
+
+## Varför detta val?
+
+- fungerar bättre i bullriga verkstäder,
+- ger en permanent textlogg utan extra steg,
+- gör det enkelt att söka i historiken,
+- minskar risken för missförstånd jämfört med ett kontinuerligt röstsamtal,
+- passar bättre när flera tekniker arbetar i samma ärende.
+
+## Push-to-Talk (PTT)
+
+Röstinmatning fungerar enligt Push-to-Talk. Appen lyssnar **endast** när användaren aktivt håller inne mikrofonknappen eller har startat en tydlig inspelning. Ingen bakgrundslyssning. Ingen automatisk aktivering.
+
+### Flöde
+
+1. Användaren håller inne mikrofonknappen (eller trycker på en tydlig "Spela in"-knapp beroende på plattform).
+2. Inspelning startar omedelbart.
+3. Appen visar tydligt att inspelning pågår: röd indikator, timer, ljudnivåmätare, texten "Inspelning pågår".
+4. Talet transkriberas i realtid — användaren ser texten växa fram och får direkt återkoppling om talet uppfattats korrekt.
+5. När inspelningen avslutas visas den transkriberade texten i ett **redigerbart** textfält.
+6. Användaren kan godkänna, redigera eller spela in på nytt.
+7. **Först när användaren bekräftar** skickas texten vidare till AI:n och sparas i arbetsloggen.
+
+### Redigering före skick
+
+Transkriberingen är alltid redigerbar. Vanliga korrigeringar: registreringsnummer, serienummer, komponentbeteckningar, personnamn, facktermer.
+
+**"Skicka" sker aldrig automatiskt.** Teknikern får alltid en snabb chans att rätta transkriberingen innan den blir en del av den permanenta arbetsloggen. Det minskar risken för felaktiga registreringsnummer, komponentbeteckningar och mätvärden.
+
+### Ingen dold funktionalitet
+
+Användaren ska alltid kunna se:
+
+- när inspelning pågår,
+- när den är avslutad,
+- vad som kommer att skickas,
+- vad som faktiskt har sparats.
+
+Det ska aldrig råda någon tvekan om när ljud spelas in eller när information skickas.
+
+## Automatisk journalföring
+
+Varje transkriberad mening blir automatiskt en del av arbetsloggen:
+
+```
+08:14  "Mätt spänning mellan stift 14 och jord. 12,4 volt."
+08:14  AI: Matningsspänning verifierad.
+08:15  "Relä klickar inte."
+08:15  AI: Kontrollera styrsignal till relä.
+```
+
+Allt sparas utan att teknikern behöver skriva en enda rad.
+
+## Handsfree-arbete
+
+Appen är optimerad för upptagna eller smutsiga händer. Under ett normalt ärende ska användaren kunna identifiera objektet med kameran, fotografera komponenter, diktera observationer, få nästa steg presenterat och fortsätta arbetet — utan att skriva manuellt. Gränssnittet ska fungera med handskar, smutsiga händer, starkt solljus, buller och vibrationer; mikrofonknappen är stor, lätt att träffa och har tydlig visuell återkoppling.

felsokning/docs/moduler/kundrapport.md

@@ -0,0 +1,25 @@
+# Modul: Delningsbar kundrapport (Kundvy)
+
+## Syfte
+
+I stället för att kunden får en rad på fakturan som säger ”Felsökning – 2,5 timmar” kan de få en tydlig tidslinje över vad som faktiskt utförts.
+
+Exempel:
+
+```
+08:03  Fordonet identifierat
+08:10  Felbeskrivning registrerad
+08:18  Däck dokumenterade
+08:26  Visuell kontroll genomförd
+08:42  Lufttryck verifierat
+08:57  Provkörning utförd
+09:18  Slutsats och rekommendation dokumenterad
+```
+
+Med bilder, mätvärden och kommentarer blir det tydligt vad kunden faktiskt har betalat för. Det stärker förtroendet och kan minska diskussioner om felsökningstid.
+
+---
+
+## Relation till övriga moduler
+
+Kundrapporten är en härledd vy av samma händelselogg som [Arbetslogg & Tidredovisning](arbetslogg-och-tidredovisning.md) bygger på – ingen separat dokumentation behöver skapas. Verkstaden väljer vilken detaljnivå som delas med kund, i linje med den rollbaserade behörighetsstyrningen.

felsokning/docs/moduler/live-share.md

@@ -0,0 +1,72 @@
+# Modul: Live Share
+
+## Syfte
+
+Varje ärende kan publiceras via en unik säker delningslänk. Länken visar ärendets aktuella status i realtid och uppdateras automatiskt när ny information registreras. Ingen manuell export behövs.
+
+En livevy ger stort värde för kunder, arbetsledare, försäkringsbolag och tillverkare — men den ska **alltid vara under verkstadens kontroll**, med tydliga behörigheter och säkerhetsnivåer.
+
+## Exempel på kundvy
+
+```
+Ärende: Volvo XC60
+Status: 🟢 Felsökning pågår
+
+Kundens felbeskrivning
+  Bilen vibrerar vid cirka 88 km/h.
+
+Aktuell status
+  ✔ Objekt identifierat
+  ✔ Provkörning utförd
+  ✔ Däck dokumenterade
+  ✔ Lufttryck kontrollerat
+  🔄 Hjulbalansering kontrolleras
+  ⏳ Drivaxlar ej kontrollerade
+
+Bilder · Mätvärden · Tidslinje
+
+Rekommenderat nästa steg
+  Kontroll av radialkast.
+```
+
+## Liveuppdatering
+
+När teknikern arbetar uppdateras sidan automatiskt, utan omladdning. Mottagaren ser direkt nya bilder, nya mätvärden, nya kommentarer och statusändringar.
+
+## Behörighetsnivåer
+
+Länkar kan skapas med olika åtkomstnivåer:
+
+- **Kund** – läsbehörighet till den information verkstaden valt att dela.
+- **Intern** – full insyn för kollegor och arbetsledare.
+- **Extern partner** – exempelvis försäkringsbolag eller tillverkare, med avgränsad information (inklusive hypoteser, tydligt märkta som ej verifierade).
+
+Implementerat i plattformen: varje länk skapas med en nivå, filtreringen sker på serversidan och länkar kan återkallas — en återkallad länk ger 404.
+
+## Export
+
+Från samma ärende ska det gå att exportera:
+
+- PDF
+- JSON
+- CSV
+- API
+- Utskriftsvänlig HTML
+
+Alla exporter bygger på samma datakälla (händelseloggen), vilket minskar risken för avvikelser.
+
+## Versionshantering
+
+Varje export märks med:
+
+- versionsnummer,
+- datum,
+- tid,
+- vem som exporterade,
+- exportformat.
+
+Det gör det möjligt att i efterhand se exakt vilken information som delades vid en viss tidpunkt.
+
+## Produktvision
+
+Ett felsökningsärende är inte bara en chatt eller en logg, utan en **levande digital arbetsjournal**. Den kan följas i realtid, tas över av en kollega, granskas av en arbetsledare, delas med kunden och avslutas med en komplett rapport — allt från samma datamodell. Det minskar dubbelarbete och gör att alla parter utgår från samma aktuella information.

felsokning/docs/moduler/markesspecifika-kopplingar.md

@@ -0,0 +1,101 @@
+# Märkesspecifika kopplingar
+
+Verkstaden har redan sina avtal. Volvo-verkstaden har VIDA, VAG-verkstaden
+har erWin, den fria verkstaden har en fordonsdataleverantör. Ingen av dem
+vill att vi ska vara mellanhand för deras abonnemang — och ingen av dem
+har samma uppsättning som grannen.
+
+Därför konfigurerar **kunden själv** sina kopplingar under
+**Inställningar → Märkesspecifika kopplingar**, med sina egna credentials.
+Vi tillhandahåller ramen, inte kontot.
+
+## Principer
+
+**Uppgifterna når aldrig webbläsaren.** Samma regel som för
+plattformens egna API-nycklar: hemligheter bor på servern. Credentials
+krypteras med AES-256-GCM innan de skrivs till databasen, och API:t
+returnerar hemliga fält maskerade (`••••3456`). Klienten kan se *att* en
+koppling finns och när den senast fungerade — aldrig vad nyckeln är.
+
+**Alla uppslag görs av servern.** Klienten skickar en identifierare
+(VIN eller regnr); servern hämtar uppgifterna, dekrypterar dem i minnet,
+anropar leverantören och returnerar bara de mappade fordonsfälten.
+
+**Fail closed.** Saknas krypteringsnyckeln (`INTEGRATION_NYCKEL`) sparas
+ingenting — API:t svarar 503 och inställningssidan förklarar varför.
+Alternativet, att lagra i klartext "så länge", finns inte.
+
+**Endast systemadministratören.** Att lägga till, ändra och ta bort
+kopplingar kräver rollen `admin`. Teknikern kan läsa registret över
+tillgängliga leverantörer (annars kan inställningssidan inte visa dem)
+men aldrig någon organisations uppgifter.
+
+**Organisationsknutet.** Kopplingarna hör till organisationen, precis
+som ärendedata. Ingen tenant ser en annans.
+
+## Leverantörer är data, inte kod
+
+Registret ligger i `services/plattform/integrationer.json` och kan bytas
+mot en ConfigMap-mount via `INTEGRATIONER_FIL`. En leverantör beskrivs
+helt deklarativt:
+
+```json
+{
+  "id": "volvo_vida",
+  "namn": "Volvo VIDA",
+  "falt": [
+    { "nyckel": "bas_url", "etikett": "Bas-URL (använd {vin} som platshållare)", "hemlig": false },
+    { "nyckel": "api_nyckel", "etikett": "API-nyckel", "hemlig": true }
+  ],
+  "uppslag": {
+    "urlFalt": "bas_url",
+    "auth": "header",
+    "authHeader": "X-Api-Key",
+    "authFalt": "api_nyckel",
+    "svarsfalt": { "marke": "make", "modell": "model", "arsmodell": "year" }
+  }
+}
+```
+
+* `falt` — vad administratören ska fylla i. `hemlig: true` styr både
+  kryptering och maskering.
+* `uppslag.auth` — `bearer`, `header`, `basic` eller `query`. Inga
+  leverantörsspecifika kodgrenar; all variation ligger i registret.
+* `svarsfalt` — mappning från leverantörens JSON (punktnotation stöds)
+  till våra fordonsfält.
+* `nyckeltyp: "regnr"` — uppslaget sker på registreringsnummer i stället
+  för VIN. `{vin}`/`{regnr}` i URL-mallen ersätts URL-kodat.
+
+Ett nytt märke läggs alltså till genom att beskriva det — inte genom att
+bygga om applikationen.
+
+## Vad ett uppslag gör och inte gör
+
+Uppslaget fyller i **fordonsbeskrivningen** (märke, modell, årsmodell,
+motor, växellåda). Det är kontextdata, inte evidens: ett svar från en
+leverantör är aldrig en utförd kontroll och räknas inte i
+[evidensmotorn](evidensmotor.md). Returnerar leverantören inga kända fält
+säger systemet det rakt ut i stället för att visa tomma rader.
+
+Varje uppslag skriver `senast_testad` och `senaste_status` på
+kopplingen. Ett utgånget abonnemang syns därför i inställningarna som ett
+felmeddelande från leverantören, inte som tysta tomma svar.
+
+## API
+
+| Väg | Metod | Roll | Vad |
+| --- | --- | --- | --- |
+| `/api/integrationer/leverantorer` | GET | inloggad | Registret (fältdefinitioner, inga uppgifter) |
+| `/api/integrationer` | GET | admin | Organisationens kopplingar, hemligheter maskerade |
+| `/api/integrationer` | POST | admin | Spara/uppdatera credentials (krypteras) |
+| `/api/integrationer/{leverantor}` | DELETE | admin | Ta bort |
+| `/api/integrationer/{leverantor}/uppslag` | POST | inloggad | Slå upp VIN/regnr via servern |
+
+Fullständigt dokumenterat i `services/plattform/openapi.yaml`.
+
+## Drift
+
+`INTEGRATION_NYCKEL` är 32 byte hex eller base64 (`openssl rand -hex 32`),
+levererad via secret:en `felsokning-hemligheter` — se
+[DRIFT.md](../DRIFT.md). Byts nyckeln måste kopplingarna sparas om;
+tjänsten visar då inga värden i stället för att gissa.

felsokning/docs/moduler/verifierade-checklistor.md

@@ -0,0 +1,73 @@
+# Modul: Verifierade checklistor
+
+## Grundprincip
+
+En kontrollpunkt är inte slutförd enbart genom att kryssa i en ruta.
+
+Systemet registrerar inte bara *att* en ruta har kryssats i — det samlar in **bevis och kontext**. Varje kontroll ska innehålla ett eller flera av följande:
+
+- ✔ Bekräftelse att kontrollen är utförd.
+- 📝 Kort observation eller slutsats.
+- 📷 Foto (när det är relevant).
+- 📹 Video (vid behov).
+- 🎤 Tal-till-text (för snabb dokumentation).
+- 📏 Mätvärde (när tillämpligt).
+
+På så sätt blir varje moment både spårbart och begripligt.
+
+## Exempel
+
+**Kontrollera batterispänning**
+
+> Teknikern markerar "Utförd".
+> Systemet: *Vilket värde uppmättes?* → **12,63 V**
+> Systemet: *Hur mättes detta? (valfritt)* → **Direkt på batteripolerna.**
+> Kontrollpunkten markeras som verifierad.
+
+**Kontrollera säkring F24**
+
+> ✔ Utförd
+> Systemet: *Vad observerades?* → **Säkringen är hel och spänning finns på båda sidor.**
+> Kontrollpunkten avslutas.
+
+## AI:s roll
+
+AI:n hjälper till att upptäcka när dokumentationen verkar ofullständig:
+
+> "Du har markerat att hjulbalanseringen är kontrollerad, men ingen observation eller mätning har registrerats. Vill du lägga till en kort kommentar innan du går vidare?"
+
+Det ska vara ett **stöd, inte ett hinder**.
+
+## Anpassning efter kontrolltyp
+
+Alla moment behöver inte samma nivå av dokumentation.
+
+| Kontrolltyp | Minimikrav |
+| --- | --- |
+| Visuell kontroll | Bekräftelse + kort kommentar |
+| Mätning | Mätvärde + kommentar |
+| Demontering | Kommentar, foto vid behov |
+| Provkörning | Sammanfattning av resultat |
+| Bildbaserad kontroll | Foto + observation |
+
+## Syfte
+
+Målet är inte att "fånga" teknikern, utan att skapa ett arbetsunderlag som visar:
+
+- vad som kontrollerades,
+- hur det kontrollerades,
+- vad resultatet blev,
+- och vilka slutsatser som är rimliga att dra.
+
+Det stärker kvaliteten i arbetet, gör överlämningar enklare och ger ett bättre underlag gentemot kund och arbetsledning.
+
+## Viktig designprincip
+
+Undvik att göra fritext obligatorisk överallt. Om varje kontroll kräver långa texter upplevs systemet snabbt som tungrott. Använd i stället en kombination av:
+
+- förvalda svar där det passar,
+- kort tal-till-text för observationer,
+- mätvärdesfält,
+- och foto eller video när det ger mest värde.
+
+Då blir dokumentationen rik utan att arbetsflödet bromsas — och teknikerna använder systemet konsekvent i vardagen.