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
Regelmotorn är nu plattformens styrande subsystem — systemet kan inte
skriva en slutsats som ECM inte godkänt.
Sex motorer (src/felsokning/ecm.ts):
- Evidence: evidensposter ur loggen med nivå E0–E6, tekniker och
deterministisk innehållshash
- Rule: dokumentationskrav + undantagsregeln med obligatorisk orsak
- Compliance: ärendetypen (garanti/goodwill/försäkring/reklamation/
begagnatgaranti …) styr extra krav — claim, skadenummer, historik,
miltal, bildbevis
- Validation: "Evidens saknas" i stället för antaganden (orkesterns
grundprompt + projektioner + grind)
- Completion: utökad kvalitetsgrind som spärrar slutrapporten
- Traceability: spårbarhetspaket (regelversion, grindstatus per
regel-id, evidensposter med hash) i varje export
Pre-Diagnostic Validation — metodiken låses upp först när:
- fordonshistoriken kontrollerats (eller motiverats: kvalitetsvarning),
med orsakskedja för tidigare arbeten
- ingående mätarställning fotograferats (bildtolkningen föreslår värdet)
- kundens felbeskrivning verifierats
- tidiga observationer hanterats
Utgående mätarställning fotograferas inför avslut och blir obligatorisk
i grinden när ärendet stängs.
Ärendeidentitet (Case Identity): fordonsobjektet utökat med VIN, miltal,
AO-, claim- och skadenummer (läses ur arbetsordern) — registreras en
gång, synligt i identitetsraden i arbetsytan (med ärendetypsval), låst
panel i Live Share, slutrapportens första sida och exporten.
49 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
Regelmotorn kodar plattformens viktigaste princip: systemet får aldrig
anta att en kontroll är utförd eller att dokumentation finns. Varje
påstående måste kunna härledas till evidens i händelseloggen.
- Nytt versionshanterat regelbibliotek (src/felsokning/ecm.ts, ECM v1.0):
evidensnivåer E0–E6 härledda ur loggen, fullbordansregler och
kvalitetsgrind — skilt från applikationslogiken
- Fullbordansregel i guiden: en kontroll slutförs med evidens ELLER
uttryckligt undantag "Underlag kan inte tas fram" med obligatorisk
orsak — loggas och flaggas ⚠ i brief, överlämning och rapport
- Kvalitetsgrind före slutrapport: utskriften spärrad tills
objektidentifiering, metodikens kontroller, fotokrav och evidensnivå
är gröna; varje röd rad visar exakt vad som saknas
- Orkesterns grundprompt utökad: aldrig "OK/kontrollerad/inga fel" utan
evidens — skriv "Evidens saknas" och begär rätt underlag (foto/video/
mätvärde/skärmfoto)
- Visual-first instrumentavläsning: ny vision-uppgift läser multimetrar,
diagnosskärmar m.m. — värden/enheter/felkoder med konfidens, teknikern
bekräftar, originalbilden loggas alltid bredvid strukturerad data;
kameran är integrationslagret, inga verktygsintegrationer krävs
- Terminologi: "AI" ersatt med systemspråk i hela gränssnittet
(Beslutsstöd, Systemet analyserar, Granskning av underlaget …)
- Dokumentation: docs/moduler/evidensmotor.md; 41 vitest-tester
Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_012EQg3rJsrQ1ZNTvkzmQAtt
Primärvägen när ett ärende startas: teknikern fotar arbetsorderns
framsida, orkesterns nya dokumenttolkningsuppgift (Sonnet 5, vision)
läser dokumentet layoutoberoende och returnerar strukturerade fält
(kund, fordon, verkstad, felbeskrivning) med konfidens per värde.
- Konfidensvalidering: ≥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: dokumentet bredvid fälten; klick på ett fält
markerar ungefärlig position i bilden
- "Starta diagnos" skapar hela ärendet: objekt ur fordonsfälten,
metodikval ur felbeskrivningen, tolkningen loggad som ny
organisationsintern händelse arbetsorder_skannad (filtreras ur
kund- och partnerdelningar i server, RPC och klient)
- Schema-bunden vision-uppgift i båda orkestertjänsterna; bild som
data-URL, validerad på servern
- Inloggade användare tillfrågas aldrig om namn — kontot används
- Manuell inmatning kvar som andrahandsväg; tydligt märkt
demo-tolkning i lokalt läge
- 37 vitest-tester; integrationstestet verifierar filtreringen
Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_012EQg3rJsrQ1ZNTvkzmQAtt
Sista externa beroendet borta — hela stacken kör i eget kluster:
- Ny plattformstjänst (services/plattform): egen inloggning
(registrering + inloggning, lösenord bcrypt-hashade med pgcrypto,
HS256-JWT), append-only händelse-API för synken (endast insert,
on conflict do nothing) och publik delningsendpoint för Live Share
med samma filtrering som Supabase-funktionen. Fail closed utan
hemligheter; inga update/delete-operationer exponeras.
- Postgres som StatefulSet med PVC och init-schema; append-only
garanterat i databasen med triggers på både händelser och ärenden —
historik kan inte ändras oavsett ansluten roll. CloudNativePG
rekommenderas för produktion i docs.
- JWT-hemligheten delas mellan plattform och AI-orkester (orkestern
läser JWT_SECRET med SUPABASE_JWT_SECRET som fallback) — flödet
livetestat: plattformens token accepteras av orkestern, fel
hemlighet och utgångna tokens avvisas.
- Klienten får självhostat läge via VITE_PLATTFORM_URL: inloggnings-
panel på startsidan, synk mot plattformens API (samma konfliktfria
flätning), Live Share via /api/delad och AI via klustrets orkester.
Utan variabeln är Supabase-läget oförändrat.
- Ingress routar /api/ai → orkestern, /api + /halsa → plattformen,
/ → webben; kustomize inkluderar hela stacken; CI bygger alla tre
bilderna; DRIFT.md omskriven för självhostad drift.
Verifierat: 28 vitest-tester gröna (inkl. append-only-triggers och
API-ytan), plattformstjänsten livetestad (hälsa, 401, fail closed),
JWT-paritet mellan tjänsterna testad, alla manifest YAML-validerade,
produktionsbygge ok, Playwright-röktest grönt.
Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_012EQg3rJsrQ1ZNTvkzmQAtt
Målarkitekturen ur Master Prompt som kod:
- Webben containeriserad (flerstegs-Dockerfile → oprivilegierad nginx
med SPA-fallback, hashade assets cachas hårt, säkerhetsheaders).
- AI-orkestern som egen tjänst (services/ai-orkester): samma routing
och AI-regler som edge-funktionen men körbar som pod — egen
HS256-JWT-verifiering (fail closed), /halsa, storleksgränser,
read-only container som kör som node-användaren. Livetestad:
hälsokontroll ok, 401 utan/med ogiltig token, 400-validering bakom
giltig JWT.
- Kubernetes-manifest (infra/k8s, kustomize): namespace, Deployments
med readiness/liveness och åtstramad securityContext, Services,
HPA 2–10 pods på 70 % CPU, PodDisruptionBudgets, Ingress med TLS
via cert-manager, secret-mall (riktiga värden skapas utanför git).
- Klienten väljer AI-väg vid bygget: VITE_AI_ORKESTER_URL → tjänsten
i klustret, annars Supabase-edge-funktionen. Samma orkester i båda,
låst av paritetstest.
- CI-arbetsflöde: tester + produktionsbygge + verifierande
containerbyggen av båda bilderna på varje push/PR.
- docs/DRIFT.md: arkitekturdiagram, driftsättningssteg, skalning,
och vad som återstår mot full självhostning.
Verifierat: 27 vitest-tester gröna, produktionsbygge ok, alla
K8s-manifest YAML-validerade, orkestertjänsten livetestad,
Playwright-röktest grönt.
Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_012EQg3rJsrQ1ZNTvkzmQAtt
Claude