From 031d6d5a3d25be2b511c08cc01a7fdb0d60adbbd Mon Sep 17 00:00:00 2001 From: Claude Date: Tue, 4 Aug 2026 20:25:45 +0000 Subject: [PATCH] =?UTF-8?q?All=20produktdokumentation=20p=C3=A5=20engelska?= =?UTF-8?q?=20som=20k=C3=A4lla?= MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit De återstående dokumenten — VISION, MVP, DEMO, DRIFT och MASTER-PROMPT — får engelska versioner, och de svenska blir översättningar med samma notis som systembeskrivningen redan hade. DRIFT.md heter nu OPERATIONS.md; ett svenskt filnamn på ett engelskt dokument hade varit inkonsekvent. Dokumentationen är därmed 33 filer: sexton dokument med engelska som källa, sexton svenska syskon, och systembeskrivningen dessutom på tyska, danska och norska. Två fel hittades under översättningen, båda rättade i bägge språken: DRIFT.md pekade ut .github/workflows/ci.yml som Guidad Felsöknings CI och sa tre rader längre ned att samma fil tillhör Semantika och inte rörs. Det stämde innan CI flyttades till egen Gitea; rätt fil är .gitea/workflows/felsokning.yml. MVP.md kallade styrdokumentet Master Prompt v1.0 men länkade till v2.0. Att översätta ett dokument är den grundligaste läsning det får. Båda felen hade överlevt flera genomgångar av samma text på svenska. Kodidentifierare, miljövariabler, sökvägar och UI-etiketter står oöversatta i de engelska versionerna. Att skriva "Create demo case" i demomanuset hade gjort manuset obrukbart — knappen heter "Skapa demoärende". Co-Authored-By: Claude Opus 5 Claude-Session: https://claude.ai/code/session_012EQg3rJsrQ1ZNTvkzmQAtt --- felsokning/docs/DEMO.md | 105 +++--- felsokning/docs/DEMO.sv.md | 74 ++++ felsokning/docs/MASTER-PROMPT.md | 214 ++++++++---- felsokning/docs/MASTER-PROMPT.sv.md | 186 ++++++++++ felsokning/docs/MVP.md | 157 +++++---- felsokning/docs/MVP.sv.md | 82 +++++ felsokning/docs/OPERATIONS.md | 319 ++++++++++++++++++ .../docs/{DRIFT.md => OPERATIONS.sv.md} | 7 +- felsokning/docs/SYSTEM-DESCRIPTION.da.md | 9 +- felsokning/docs/SYSTEM-DESCRIPTION.de.md | 9 +- felsokning/docs/SYSTEM-DESCRIPTION.md | 9 +- felsokning/docs/SYSTEM-DESCRIPTION.no.md | 9 +- felsokning/docs/SYSTEM-DESCRIPTION.sv.md | 9 +- felsokning/docs/VISION.md | 248 ++++++++------ felsokning/docs/VISION.sv.md | 183 ++++++++++ .../docs/modules/brand-integrations.sv.md | 2 +- 16 files changed, 1331 insertions(+), 291 deletions(-) create mode 100644 felsokning/docs/DEMO.sv.md create mode 100644 felsokning/docs/MASTER-PROMPT.sv.md create mode 100644 felsokning/docs/MVP.sv.md create mode 100644 felsokning/docs/OPERATIONS.md rename felsokning/docs/{DRIFT.md => OPERATIONS.sv.md} (96%) create mode 100644 felsokning/docs/VISION.sv.md diff --git a/felsokning/docs/DEMO.md b/felsokning/docs/DEMO.md index d28dfb8..1c22e42 100644 --- a/felsokning/docs/DEMO.md +++ b/felsokning/docs/DEMO.md @@ -1,71 +1,98 @@ -# Guidad Felsökning – Demomanus +# Guidad Felsökning — demo script -Ett 5–10 minuters manus för att visa plattformen. Allt körs lokalt utan konton eller nycklar. +> Canonical version. Swedish: [DEMO.sv.md](DEMO.sv.md). -## Förberedelser +A 5–10 minute script for showing the platform. Everything runs locally, with no +accounts and no keys. + +## Preparation ```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). +Open `http://localhost:8080/felsokning` — ideally on a phone, or in mobile mode +in the browser (the app is built for the workshop floor). Enter a name +(everything is logged per user). -Chrome rekommenderas: då fungerar även röstinmatningen (Push-to-Talk). +Chrome is recommended: voice input (push-to-talk) then works as well. -## Demoflöde +## Demo flow -### 1. Dashboarden och demoärendet (1 min) +### 1. The dashboard and the demo case (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. +Click **Skapa demoärende (Volvo XC60, vibration)** — create demo case. A complete +case with 1 h 35 min of work history is loaded: identified object, answered +symptom questions, four wheel photos, measured values, a road test, a handover +between two technicians, and a hypothesis. -Poäng att göra: dashboarden visar bara det viktigaste — pågående, klara, nytt ärende. +The point to make: the dashboard shows only what matters — in progress, done, +new case. -### 2. Ärendebriefen (2 min) +### 2. The case brief (2 min) -Öppna ärendet → fliken **Brief**. Det här är kärnargumentet: +Open the case → the **Brief** tab. This is the core argument: -- **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**. +- **Checks performed** with results — not just tick boxes. +- **Not checked** — derived automatically from the methodology; what causes + duplicated work at shift change is the thing nobody wrote down that nobody + did. +- **Hypotheses** clearly marked 🔴 — the system never presents a hypothesis as a + confirmed fault. +- **Reliability** and **total working time**. -Poäng: en ny tekniker är produktiv på under en minut, utan att läsa hundratals loggrader. +The point: a new technician is productive in under a minute, without reading +hundreds of log lines. -### 3. Guiden och verifierade checklistor (2 min) +### 3. The guide and verified checklists (2 min) -Fliken **Guide**. Metodiken fortsätter där den slutade: en fråga eller kontroll i taget, stora knappar. +The **Guide** tab. The methodology carries on where it left off: one question or +check at a time, large buttons. -- 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. +- Show that a measurement check **cannot be verified without a measured value** + (the button is locked until the value is filled in). +- Press 🎤 and dictate an observation — the text lands in the field, editable, + and is saved only when you press Save. Speech in, text out; nothing is sent + automatically. +- Show the category buttons (active diagnosis / waiting / road test …) — time + reporting takes care of itself. -### 4. Arbetsloggen (1 min) +### 4. The work log (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. +The **Logg** tab: every event timestamped with its user, append-only — nothing +can be changed or deleted afterwards. Point out the handover between Anna and +Johan. -### 5. Kundrapporten och Live Share (2 min) +### 5. The customer report and Live Share (2 min) -Fliken **Rapport**: +The **Rapport** tab: -- **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. +- **Print / PDF** — the report becomes black on white automatically. +- **Export JSON** — versioned (version = number of events), and the export logs + itself. +- **Open Live Share view** — what the customer sees through the share link: + status ✔/🔄/⏳, images, measured values, timeline. No hypotheses, no internal + entries. -Poäng: i stället för "Felsökning – 2,5 timmar" på fakturan får kunden en tidslinje över vad som faktiskt gjorts. +The point: instead of "Diagnosis — 2.5 hours" on the invoice, the customer gets +a timeline of what was actually done. -### 6. Avsluta med filosofin (30 sek) +### 6. Close with the philosophy (30 sec) -> Systemet dokumenterar observationer, leder användaren genom verifierbara kontroller och rekommenderar nästa steg — men presenterar aldrig en hypotes som ett konstaterat fel. +> The system documents observations, leads the user through verifiable checks +> and recommends the next step — but never presents a hypothesis as a confirmed +> fault. -Det ersätter inte teknikern. Det ersätter pärmen, minneslapparna och "fråga Kent, han skruvade på den i torsdags". +It does not replace the technician. It replaces the binder, the sticky notes, +and "ask Kent, he was working on it on Thursday". -## Vad som är demoläge respektive produktion +## What is demo mode and what is production -| I demon | I produktion | +| In the demo | In production | | --- | --- | -| Deterministisk metodikmotor (16 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å) | +| Deterministic methodology engine (16 methodologies) | The model selects/generates steps through the same engine interface | +| The browser's speech recognition | The vendor's voice-to-text behind the same interface | +| localStorage + sync on login | Multi-tenant backend (the migration exists), roles per the Master Prompt | +| Share link requires a synced case | Live Share with permission levels customer/internal/partner | +| Demo images drawn by the system | Real photos via the camera (already works in the demo too) | diff --git a/felsokning/docs/DEMO.sv.md b/felsokning/docs/DEMO.sv.md new file mode 100644 index 0000000..07192cf --- /dev/null +++ b/felsokning/docs/DEMO.sv.md @@ -0,0 +1,74 @@ +# Guidad Felsökning – Demomanus + +> **Svensk översättning.** Källan är [DEMO.md](DEMO.md) (engelska). +> Vid avvikelse gäller det engelska dokumentet. + +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 (16 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å) | diff --git a/felsokning/docs/MASTER-PROMPT.md b/felsokning/docs/MASTER-PROMPT.md index 9672a9c..a32cf3f 100644 --- a/felsokning/docs/MASTER-PROMPT.md +++ b/felsokning/docs/MASTER-PROMPT.md @@ -1,183 +1,255 @@ -# Guidad Felsökning – Master Prompt v2.0 +# Guidad Felsökning — Master Prompt v2.0 + +> Canonical version. Swedish: [MASTER-PROMPT.sv.md](MASTER-PROMPT.sv.md). **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). +This is a product directive, not a technical specification. The vision and the +reasoning behind it are in [VISION.md](VISION.md); v1.0 is in the version +history. Detailed module specifications: +[communication model (voice/PTT)](modules/communication-model.md), +[Live Share](modules/live-share.md), +[verified checklists](modules/verified-checklists.md), +[case brief](modules/case-brief.md), +[work log and time tracking](modules/work-log-and-time-tracking.md), +[customer report](modules/customer-report.md). --- -## Projekt +## Project -Bygg en produktionsredo SaaS-plattform med namnet **Guidad Felsökning**. +Build a production-ready SaaS platform named **Guidad Felsökning**. -Plattformen är en AI-wrapper ovanpå Claude API (Anthropic) och fungerar som ett professionellt arbetsverktyg för mekaniker och servicetekniker. +The platform is a wrapper on top of the Claude API (Anthropic) and works as a +professional tool for mechanics and service technicians. -**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. +**The model is operated by the platform, not by the customer.** The Claude API +keys are platform secrets in the backend and are never exposed to customers or +clients — the guidance is part of the service. The backend owns the system +prompt, the model selection and the response schema, so the rules cannot be +circumvented from the client side. -**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: +**The model orchestra.** We run several Claude models in our infrastructure and +route per task — the backend owns the routing table, so it can be adjusted +without client changes: -| Uppgift | Modell | Motiv | +| Task | Model | Rationale | | --- | --- | --- | -| 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 | +| Guidance (a response to each piece of documentation) | Claude Sonnet 5 | Many calls, latency-sensitive on the workshop floor | +| Review (contradictions and gaps across the whole record) | Claude Opus 5, high effort | The deepest reasoning — quality before latency | +| Handover summary (risks and uncertainties) | Claude Sonnet 5, low effort | Balance | +| Methodology classification of the fault description | Claude Haiku 4.5 | Pure classification — fastest and cheapest | -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. +All tasks share the same base rules (below) and the same classified response +schema. On a declined request the call automatically falls back to Anthropic's +recommended reserve model. The system should not replace technical competence or +the manufacturer's documentation, but guide the user through a structured +diagnostic process, document all work, and create full traceability. -Målet är att lansera en stabil, enkel och köpvärdig beta-version. +The goal is to launch a stable, simple beta version worth paying for. --- -## Produktfilosofi +## Product philosophy -Produkten ska kännas som ett verktyg från en stor industrileverantör: enkel, stabil, extremt snabb, professionell, förutsägbar, tydlig, minimalistisk. +The product should feel like a tool from a major industrial supplier: simple, +stable, extremely fast, professional, predictable, clear, minimal. -Ingen "AI-leksak". Ingen onödig design. Inga experimentella funktioner. Allting ska kännas robust. +No toy. No unnecessary design. No experimental features. Everything should feel +robust. --- -## Roller +## Roles -### Systemadministratör +### System administrator -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. +Normally one or more people at the customer. Permissions: manage the +organisation, API keys, integrations, create and remove users, roles, +permissions, export, security settings, billing, logs. -### Tekniker +### Technician -Kan skapa ärenden, fortsätta ärenden, ta över ärenden, skriva, prata, fotografera, filma, mäta, exportera rapport. +Can create cases, continue cases, take over cases, write, speak, photograph, +record video, measure, and export reports. -### Arbetsledare +### Supervisor -Kan dessutom se alla ärenden, omfördela ärenden, följa status, läsa rapporter, skapa statistik. +Can additionally see all cases, reassign cases, follow status, read reports, and +produce statistics. --- -## Multi-tenant +## Multi-tenancy -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.** +Each customer is its own tenant with its own users, API keys, integrations, +cases, database logic and security. **No data may be mixed between customers.** --- -## Enkel onboarding +## Simple onboarding -Första gången en kund loggar in: +The first time a customer logs in: -1. Skapa företag -2. Lägg till logotyp -3. Lägg till användare -4. Lägg till eventuella integrationer +1. Create the company +2. Add a logo +3. Add users +4. Add any integrations -Klart. Hela onboarding ska ta mindre än fem minuter. AI-handledningen ingår i tjänsten — kunden hanterar inga AI-nycklar. +Done. The whole onboarding should take less than five minutes. The guidance is +part of the service — the customer handles no model keys. --- ## Dashboard -Visa endast det viktigaste: Mina ärenden · Pågående · Väntar · Klara · Starta nytt ärende. +Show only what matters: My cases · In progress · Waiting · Done · Start new +case. --- -## Nytt ärende +## New case -Identifiera objekt genom registreringsnummer, VIN, maskinnummer, QR, streckkod, OCR, foto eller manuell identifiering. Objektet verifieras innan felsökning startar. +Identify the object by registration number, VIN, machine number, QR code, +barcode, OCR, photo or manual identification. The object is verified before +diagnosis starts. --- -## AI-guidning +## Guidance -Systemet arbetar stegvis. Inte långa svar. En kontroll åt gången: +The system works step by step. Not long answers. One check at a time: -> Kontrollera säkring F24. → Användaren svarar. → AI går vidare. +> Check fuse F24. → The user answers. → The system moves on. -### AI-regler +### Rules -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. +The model may never invent facts, pretend to know, or guess. It must distinguish +**Observation**, **Verified**, **Hypothesis** and **Recommendation**. Every +answer must carry a clear confidence level. --- -## Kommunikationsmodell +## Communication model -**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. +**Speech in, text out.** All voice input goes through speech-to-text on a +push-to-talk basis — no background listening, no voice agent, never automatic +sending. The transcription is always editable before it is saved to the work +log. See [the module](modules/communication-model.md) for the full +specification. --- -## Kamerastöd +## Camera support -Foto, video, OCR, bildanalys och objektidentifiering: däck, typskyltar, serienummer, skyltar, komponenter, mätinstrument. +Photo, video, OCR, image analysis and object identification: tyres, type plates, +serial numbers, labels, components, measuring instruments. --- -## Arbetslogg +## Work log -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. +Everything is logged: time, user, object, comment, photo, video, measured value, +question, answer, result. Nothing may disappear. The log must be audit-proof. --- -## Tidrapportering +## Time reporting -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 …). +Once the object is identified, the working time starts. After a longer period of +inactivity the system asks for a short description of what was done. The final +report shows the total time distributed across activities (road test, diagnosis, +administration …). --- -## Ärendebrief +## Case brief -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. +The system always maintains a living summary. When another technician opens the +case, it automatically shows: what the customer describes, what has been done, +what has been verified, what remains, the recommended next steps and the total +working time. --- -## Verifierade checklistor +## Verified checklists -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). +A check item is not complete merely by ticking a box — every check collects +evidence and context (observation, measured value, photo) with minimum +requirements adapted to the type of check. See +[the module](modules/verified-checklists.md). --- -## Samarbete +## Collaboration -Flera tekniker kan arbeta samtidigt. Alla ser bilder, filmer, mätningar, anteckningar, AI-sammanfattning, status och rekommendationer. +Several technicians can work at the same time. Everyone sees images, video, +measurements, notes, the generated summary, status and recommendations. --- -## Kundrapport och Live Share +## Customer report and 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). +The customer report is generated automatically (object, fault description, +images, tests, measured values, checks performed, time, recommendation, next +step) and shared as a PDF, a link or via the API. Each case can additionally be +published through a secure, permission-controlled share link that updates in +real time — see [the Live Share module](modules/live-share.md). Every export is +versioned (version, date, time, who, format). --- -## API First +## API first -Bygg hela systemet API-first. Alla resurser ska kunna skapas, läsas, uppdateras, exporteras och integreras. Dokumentera API:erna med OpenAPI/Swagger. +Build the whole system API-first. All resources must be creatable, readable, +updatable, exportable and integrable. Document the APIs with OpenAPI/Swagger. --- -## Integrationer +## Integrations -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. +Prepare an integration framework for DMS, ERP, CRM, electronic service books, +time reporting, invoicing, parts systems and manufacturer systems via the +customer's own credentials. A modular integration architecture so that new +integrations can be added without affecting the core platform. --- -## Infrastruktur +## Infrastructure -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. +Build for production. Example target architecture: AWS, Kubernetes, Docker, +PostgreSQL, Redis, object storage, CDN, autoscaling, load balancing, backup, +central logging, monitoring, CI/CD, infrastructure as code. --- -## Säkerhet +## Security -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. +Role-based access, encryption at rest and in transit, secure API +authentication, audit logs, the principle of least privilege, secure handling of +API keys and secrets. Design the system so that it can meet relevant +requirements, for example GDPR, depending on how the customer uses the service. --- -## Beta-fokus +## Beta focus -Prioritera ett litet antal funktioner med hög kvalitet framför många halvfärdiga funktioner. +Prioritise a small number of features at high quality over many half-finished +ones. -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. +The MVP must contain: login, organisation (tenant), user management, start a +case, object identification, guided diagnosis, camera and image analysis, work +log, time reporting, case brief, customer report, API, administration. -All övrig funktionalitet planeras för senare versioner. +All other functionality is planned for later versions. --- -## Slutmål +## Ultimate goal -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. +Build a platform that feels as obvious to a mechanic or service technician as a +diagnostic instrument does today. Focus on speed, clarity, methodical guidance +and traceable documentation. When a user opens the app it should feel like a +reliable professional tool — not like a general-purpose chat. It should be easy +to get started, easy to collaborate, and easy to show the customer exactly how +the diagnosis was carried out. diff --git a/felsokning/docs/MASTER-PROMPT.sv.md b/felsokning/docs/MASTER-PROMPT.sv.md new file mode 100644 index 0000000..5728353 --- /dev/null +++ b/felsokning/docs/MASTER-PROMPT.sv.md @@ -0,0 +1,186 @@ +# Guidad Felsökning – Master Prompt v2.0 + +> **Svensk översättning.** Källan är [MASTER-PROMPT.md](MASTER-PROMPT.md) (engelska). +> Vid avvikelse gäller det engelska dokumentet. + +**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.sv.md); v1.0 finns i versionshistoriken. Detaljerade modulspecifikationer: [kommunikationsmodell (röst/PTT)](modules/communication-model.sv.md), [Live Share](modules/live-share.sv.md), [verifierade checklistor](modules/verified-checklists.sv.md), [ärendebrief](modules/case-brief.sv.md), [arbetslogg & tidredovisning](modules/work-log-and-time-tracking.sv.md), [kundrapport](modules/customer-report.sv.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](modules/communication-model.sv.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](modules/verified-checklists.sv.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](modules/live-share.sv.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. diff --git a/felsokning/docs/MVP.md b/felsokning/docs/MVP.md index 844a3ce..778fa3d 100644 --- a/felsokning/docs/MVP.md +++ b/felsokning/docs/MVP.md @@ -1,79 +1,120 @@ -# Guidad Felsökning – MVP +# 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`. +> Canonical version. Swedish: [MVP.sv.md](MVP.sv.md). +> Code identifiers, paths, environment variables and UI labels are Swedish and +> appear verbatim. -## Kör +The first runnable version of the core of [Master Prompt v2.0](MASTER-PROMPT.md). +Built as a self-contained part of this codebase under `/felsokning`. + +## Running it ```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) +npm run dev # open http://localhost:8080/felsokning +npm test # projection, sync and demo tests +npm run typkontroll # tsc --noEmit (vite build does not typecheck) ``` -**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: +**A single-file preview** (for sharing, say) is built with hash routing — +otherwise it only works when served from the root: ```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å. +In that mode `/` is Guidad Felsökning rather than the host application's home +page, and the page works from any path. -Fullständig systembeskrivning i ett dokument (för granskning eller resonemang utanför repot): [SYSTEM-DESCRIPTION.md](SYSTEM-DESCRIPTION.md) — engelska är källan, och finns även på [svenska](SYSTEM-DESCRIPTION.sv.md), [tyska](SYSTEM-DESCRIPTION.de.md), [danska](SYSTEM-DESCRIPTION.da.md) och [norska](SYSTEM-DESCRIPTION.no.md). Alla versioner behåller kodidentifierarna oöversatta — koden är svensk oavsett vilket språk dokumentet är på. +The complete system description in one document (for review, or for reasoning +about the system outside the repository): [SYSTEM-DESCRIPTION.md](SYSTEM-DESCRIPTION.md) +— also available in [Swedish](SYSTEM-DESCRIPTION.sv.md), +[German](SYSTEM-DESCRIPTION.de.md), [Danish](SYSTEM-DESCRIPTION.da.md) and +[Norwegian](SYSTEM-DESCRIPTION.no.md). Every version keeps the code identifiers +untranslated — the code is Swedish whatever language the document is in. -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. +Demo script for presentations: [DEMO.md](DEMO.md). The **Skapa demoärende** +button on the home page loads a complete vibration case with 1 h 35 min of +history. -## Vad som ingår +## What is included -| Direktivets kärna | Status i MVP | +| Core of the directive | Status in the 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, sexton 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 | ✅ **Sexton**, i `src/felsokning/metodiker.ts`: vibration, bromsar, styrning/fjädring, elsystem (relä-exemplet ur visionen), start & laddning, motorgång, kylsystem, drivlina, avgas & emission, klimat, högvolt (elbil/hybrid), felkoder & kommunikation, läckage, missljud, förarassistans (ADAS) — plus generisk. Metodiken väljs på nyckelord ur felbeskrivningen, poängsatt så att det mest specifika ordet vinner (`traktionsbatteri` slår `batteri`); träffar inget väljs generisk, som är strukturellt komplett — ett ärligt "vi vet inte var vi ska börja" i stället för en gissning, varefter orkesterns klassificerare (Haiku 4.5) får försöka. Tre regler är låsta av test: varje kontroll har ett minimikrav, varje metodik börjar med att verifiera symptomet, och där arbetet kan skada någon ligger säkerhetssteget först — högvoltsmetodiken kan inte påbörjas utan dokumenterad spänningsfrihet, urtagen servicebrytare och skyddsutrustning. | -| 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. | -| Observation | ✅ **Noll nya beroenden**: W3C Trace Context (`traceparent` från klienten genom plattformen till orkestern) och CloudWatch EMF — strukturerad JSON på stdout som CloudWatch extraherar mätvärden ur, utan agent eller SDK. Varje anrop ger en loggrad med **nedbrytning av tiden** per del (databas, modellanrop, objektlagring, leverantörsuppslag), så frågan "var tog tiden vägen" besvaras av en rad i stället för av gissningar. Vägen normaliseras innan den blir dimension och organisation/ärende/spår blir aldrig dimensioner — låst av test, eftersom varje unik kombination är en tidsserie som kostar. Tre larm på det teknikern märker: svarstid p95, serverfel och att modellen avböjer. | -| Drift på AWS | ✅ Allt eget, inget GitHub: **Gitea med egna Actions-runners** i samma kluster, **ECR** med oföränderliga taggar, **EKS** med noder utan publika adresser, **Aurora PostgreSQL** i ett subnätlager utan routing ut, **S3** för bilagor och **Secrets Manager** som sanningskälla för hemligheter — speglade av External Secrets, aldrig synliga för Terraform. Åtkomst via IRSA där varje roll är bunden till exakt ett tjänstekonto i en namnrymd; bygge och drift har skilda roller så ett komprometterat bygge inte kan driftsätta. **Observation**: CloudWatch med Container Insights, instrumentpanel och fyra larm — varav ett larmar på *saknad* data, eftersom en backup man tror finns är värre än ingen. | -| 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. Två lager i ordning: `infra/aws` (VPC, EKS, Aurora, S3, ECR, Secrets Manager, Route 53/ACM, CloudWatch) och `infra/terraform` (arbetslasten), där det andra läser det förstas utdata så inget anges två gånger. Uppdelningen är inte smak — en apply som både skapar ett kluster och schemalägger in i det är en känd Terraform-fälla. | -| Ö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`. | +| Object identification first | ✅ **QR/barcode reading** (`src/felsokning/streckkod.ts`): the camera stream reads QR, Code 39/128, Data Matrix and PDF417 through the browser's BarcodeDetector. A scanned code is classified before it is used — VIN (17 characters without I/O/Q), Swedish registration number (both series) or serial number — and the identifier is extracted even from QR content such as URLs or `vin=…` fields; free text and bare URLs are rejected. If the browser lacks the API (iOS/Safari, for instance) **the type plate is photographed** instead and the platform's image interpretation reads it — the camera is the interface whatever the device. Manual entry with a confirmation step remains. | +| Guided diagnosis | ✅ A deterministic methodology engine (one question at a time, sixteen methodologies) **plus the Claude orchestra driven by the platform**: the edge function `felsokning-ai` owns the Claude API key (the server secret `ANTHROPIC_API_KEY`) and routes per task — live guidance (Sonnet 5), deep review of the whole record from a button in the brief (Opus 5, high effort), completion of the handover with risks and uncertainties (Sonnet 5) and methodology classification of the fault description (Haiku 4.5). All answers are schema-bound and classified according to the rules, with automatic fallback to Anthropic's recommended reserve model on a declined request; the model that answered is logged in every event. Requires a logged-in user; the answers are internal and are never shared in customer views. In local mode the methodology guides on its own. | +| Work log | ✅ Append-only event log with a timestamp and user on every entry. Nothing is overwritten. | +| Time reporting | ✅ Categories (active diagnosis, waiting, road test …) via category changes in the log; a pause does not count towards total time. An inactivity prompt after 20 minutes without events. | +| Documentation | ✅ Observations, measured values, photos (downscaled), **video with sound** (E3 evidence for what makes noise or moves — a short clip with a mandatory description, a hard size limit, the original file preserved and shown in the log, the report and Live Share), comments and hypotheses. Hypotheses are always marked as unverified and can never be logged as confirmed faults. **Closing is signed automatically** by the technician ("Felsökning avslutad — signerad av …"), reported in the quality gate. | +| Case brief | ✅ Regenerated from the log on every view: checks performed, observations, **not checked**, recommended next step, reliability, total working time. | +| Handover | ✅ "Lämna över arbete" generates a handover report from the brief and logs the handover. | +| Customer report | ✅ A timeline view without internal entries, with images and time distribution. Print/PDF through the browser, with a reminder to review before sharing. | +| Voice input (speech in, text out) | ✅ Push-to-talk via the browser's speech recognition (sv-SE): listens only while actively pressed, a red indicator with a live transcript, the text lands in an editable field and is never sent automatically. The button appears only in browsers with speech support. The production version swaps the engine for the vendor's voice-to-text behind the same interface. | +| Verified checklists | ✅ Every check in the methodology has a minimum requirement (photo, measured value or a short observation). Photo checks are verified with an image; measurements cannot be marked verified without a value. | +| Export | ✅ Versioned JSON export (version = number of events at the time of export, with user and timestamp); the export itself is logged as an event. PDF via printing. CSV and API in the backend phase. | +| Multi-tenancy and roles | ✅ In self-hosted mode: registration creates an organisation plus a system administrator; admins manage users (technician/supervisor/admin) through the UI; all case data is organisation-isolated in the API; role and organisation in the JWT. **Supervisor view** (`/felsokning/oversikt`): all the organisation's cases with status, participating technicians and statistics (in progress/closed/lead time) — derived from the event log; cases can be pulled to the device with conflict-free merging. **Root-cause statistics** (fleet data): the cause categories from all root-cause analyses are aggregated per organisation and shown as a bar overview in the supervisor view. The **responsible technician** per case is derived from the log (creator → handover → reassignment) and the supervisor can reassign ongoing cases — logged as the organisation-internal event `ansvarig_satt`, never visible in customer or partner shares. Integration-tested against real Postgres (isolation, role enforcement, append-only, the supervisor view's permissions and derivations). | +| Backend and sync | ✅ Database migration (`supabase/migrations/20260802230000_guidad_felsokning.sql`): cases and events with RLS, append-only in the database too (no update/delete privileges). A sync layer in the client: conflict-free merging of events by id (tested), pushing local events and pulling colleagues' events every 15 seconds. Without login the app works in local mode; the status is shown in the case header. | +| Methodologies | ✅ **Sixteen**, in `src/felsokning/metodiker.ts`: vibration, brakes, steering/suspension, electrical (the relay example from the vision), starting and charging, engine running, cooling, drivetrain, exhaust and emissions, climate, high voltage (EV/hybrid), fault codes and communication, leakage, abnormal noise, driver assistance (ADAS) — plus generic. The methodology is selected on keywords from the fault description, scored so that the most specific word wins (`traktionsbatteri` beats `batteri`); if nothing matches, generic is selected — structurally complete, an honest "we don't know where to start" rather than a guess, after which the orchestrator's classifier (Haiku 4.5) gets a try. Three rules are locked by tests: every check has a minimum requirement, every methodology begins by verifying the symptom, and where the work can injure someone the safety step comes first — the high-voltage methodology cannot be started without documented absence of voltage, a removed service disconnect and protective equipment. | +| Live Share | ✅ **The sharing boundary is an allowlist**: event types are enumerated per level (customer/partner/internal) instead of being denied one by one, so a new event type is internal until someone actively releases it — locked by a test that requires every type in the domain model to be classified. A read-only live view per case (`/felsokning/dela/:id`): status ✔/🔄/⏳, images, a table of measured values, a timeline, the recommended next step. Updates automatically; internal entries are filtered out. The public share page (`/felsokning/delad/:kod`) reads via `hamta_delat_arende` without login and polls for live updates; "Kopiera delningslänk" is in the report tab. **Permission levels**: revocable share links per level — customer (the customer-shareable material), external partner (also hypotheses, marked unverified), internal (full visibility) — with server-side filtering, managed from the report tab in self-hosted mode. | +| Dashboard | ✅ Per the directive: counters and filters for All/In progress/Done, plus Start new case. | +| Case start via work order | ✅ The primary path when a case is started: photograph the front of the work order — the orchestrator's document interpretation (Claude Sonnet 5, vision) reads customer, vehicle and workshop details regardless of layout and assigns a confidence per field. 🟢 ≥95 % accepted automatically, 🟡 80–95 % flagged for reading, 🔴 <80 % requires active confirmation — the technician reviews only the uncertain fields. Visual review with the document beside the fields (clicking marks the approximate position), then the whole case is created with one tap. The interpretation is logged as an organisation-internal event (`arbetsorder_skannad`) and is never shared in customer or partner views. Manual entry remains as a fallback; in local mode a clearly marked demo interpretation is shown. Logged-in users are never asked for their name — the account already knows. | +| Settings | ✅ The system administrator chooses which object types and identification methods are shown when a case is started (`/felsokning/installningar`). On the platform the choice applies to the whole organisation (stored on the organisation, only admins may change it — verified in the integration test); in local mode the choice applies to the device. Unknown values are filtered out and empty lists fall back to the default. | +| Evidence engine (ECM) | ✅ Its own subsystem with six engines ([modules/evidence-engine.md](modules/evidence-engine.md), `src/felsokning/ecm.ts`, **ECM v2.0**): Evidence (evidence entries with level E0–E6, technician and content hash), Rule (documentation requirements plus the exemption rule with a mandatory reason), Compliance (the case type — warranty/insurance/complaint and others — governs additional requirements), Validation ("Evidens saknas" instead of assumptions, encoded in the orchestrator's base prompt), Completion (a quality gate that blocks the final report) and Traceability (a traceability package with rule version and hash in every export). **The ECM Knowledge Library**: the compliance rules are declarative data served by the platform (`GET /api/ecm/regler`, replaceable via a ConfigMap) — updated in operations without an app change; the client caches them and falls back to its built-in default pack when offline. | +| Pre-diagnostics | ✅ No diagnosis until the basic checks are done or justified: vehicle history — earlier cases on the same vehicle are retrieved automatically with their root causes (from the server when logged in, the local store otherwise) and the causal chain is linked with one tap; Yes/No with a mandatory reason → quality warning, the **incoming odometer reading** (a photo of the instrument cluster, the image interpretation proposes the value), the customer's fault description verified, and early observations handled. Only then does the methodology unlock. The **outgoing odometer reading** is photographed before closing and becomes mandatory in the gate when the case is closed. | +| Symptom verification (SVP) | ✅ The customer's description ≠ a confirmed fault: the description is documented verbatim, clarified through the methodology's symptom questions (the generic methodology carries the when/where/how set) and reproduced — Yes (how and under what conditions), Partly (what could and could not be recreated) or No (mandatory justification). The report's chain of evidence separates the customer's description, verified observation, root-cause analysis and recommended action; the wording "kunde inte reproduceras under de förhållanden som rådde" is used instead of "fault confirmed" (encoded in the orchestrator's base prompt too). | +| Root-cause analysis | ✅ Mandatory before closing: the observed deviation (the quality rule rejects "broken/defective/worn" without explanation), cause categories (including Unknown cause, which requires a justification), at least one evidence source validated against the log, a confidence level (medium/low requires strengthening checks) and a recommended action. The close button is blocked until SVP and root cause exist; the quality gate makes both mandatory on closing. Its own section in the final report. | +| Customer approval | ✅ A repair proposal is given to the customer before work starts (pre-filled from the root-cause analysis, with an estimated cost) and **shown in Live Share** — the customer sees what is proposed. The customer's decision is recorded with an outcome, a channel (telephone/in person/e-mail/SMS/share link) and a justification when declined. The repair button is locked until the decision exists and stays locked on a refusal; the quality gate flags it hard if work was performed despite a declined proposal. **The customer can also answer directly in their share link** — the only writing public route, with six safeguards (customer level only, not revoked, a proposal must exist, one decision per case, limited content, rate limiting), all verified in the integration test. | +| Repair and quality check | ✅ The last link in the workflow: the repair is documented (what was done plus parts) or justified as to why it did not happen (the customer declined, waiting for a part …). If a repair has been performed, a **quality check** is required — symptom gone / remains / partly / could not be verified, with a description of how it was verified under the same conditions the symptom was reproduced. A remaining symptom is flagged in the gate rather than hidden. The close button is blocked until the whole chain symptom verification → root cause → repair → quality check is complete; the report has its own section "Utförd åtgärd och verifiering". | +| Case identity | ✅ The vehicle object as the connecting thread: the identity (work order number, claim/warranty number, insurance reference, registration, VIN, odometer, customer) is recorded once — normally via the work-order scan — and reused in the identity row in the workspace (with the case type selector), the locked panel at the top of Live Share, the first page of the final report (case information plus vehicle information) and the export. | +| Instrument reading (visual-first) | ✅ The camera as a universal interface: `📷 Instrument` in the documentation panel photographs multimeters, diagnostic screens, battery testers and so on — the image interpretation identifies the instrument type and extracts values, units and fault codes with a confidence per value; the technician confirms before anything is logged. The original image is always logged together with the structured measurements — structured data never replaces the original evidence. No integration with diagnostic systems is required. | +| Printing | ✅ The customer report and the Live Share view print black on white; interactive elements are hidden automatically. Printing goes through the ECM quality gate. | +| Brand-specific integrations | ✅ The workshop configures its own OEM/vehicle-data vendors under Settings with its own credentials ([modules/brand-integrations.md](modules/brand-integrations.md)): the credentials are encrypted with AES-256-GCM at rest, always returned masked (`••••3456`) and **all lookups are performed by the server** — vendor keys never reach the browser. Only the system administrator manages them, the integrations are organisation-scoped, and if the encryption key is missing nothing at all is saved (fail closed). Vendors are data, not code: the URL template, authentication type (bearer/header/basic/query) and response mapping are described in `integrationer.json` (ConfigMap-replaceable via `INTEGRATIONER_FIL`) — new brands are added without a rebuild. Every lookup logs its test status, so an expired subscription shows up in settings instead of producing silently empty answers. Verified in the integration test (role enforcement, masking, encryption in the database, organisation isolation, fail closed). | +| Attachments | ✅ Photos, video and instrument images live **outside the event**; the log carries a reference with the content's SHA-256. That strengthens the probative value: the hash sits in the append-only-protected log, so a swapped image can be detected — and the content is checked against the hash every time it is served (409 instead of showing the image). Content-addressed, so the same photo is stored once. Two modes: `databas` (bytea, works everywhere) and `s3` (AWS/MinIO/Ceph) with our own SigV4 signing, cross-verified bit for bit against botocore in the tests. The sharing boundary applies to attachments too — the scanned work order is never reachable through the customer link. Older events with an embedded data URL keep working forever, and local mode still embeds so documentation is never lost without a network. | +| Access control | ✅ **Revocation is immediate**: every authenticated call checks that the account is active and that the token version matches, instead of a suspension taking effect when the token expires. The administrator disables and re-enables accounts in the user list (cannot disable themselves, never across the organisation boundary), and anyone can log out on all devices when a phone is lost. **Login rate limiting** lives in the database and therefore holds behind several replicas: 10 attempts per account and 30 per source address within 15 minutes, and the block applies to the account even on a correct password. All limits verified in the integration test. | +| Observability | ✅ **Zero new dependencies**: W3C Trace Context (`traceparent` from the client through the platform to the orchestrator) and CloudWatch EMF — structured JSON on stdout from which CloudWatch extracts metrics, with no agent and no SDK. Every call produces a log line with a **breakdown of the time** per part (database, model call, object storage, vendor lookup), so the question "where did the time go" is answered by one line instead of by guesswork. The route is normalised before it becomes a dimension, and organisation/case/trace never become dimensions — locked by a test, because every unique combination is a time series that costs money. Three alarms on what the technician notices: response time p95, server errors, and the model declining. | +| Operations on AWS | ✅ All our own, no GitHub: **Gitea with its own Actions runners** in the same cluster, **ECR** with immutable tags, **EKS** with nodes without public addresses, **Aurora PostgreSQL** in a subnet layer with no route out, **S3** for attachments and **Secrets Manager** as the source of truth for secrets — mirrored by External Secrets, never visible to Terraform. Access via IRSA where every role is bound to exactly one service account in one namespace; build and operations have separate roles so a compromised build cannot deploy. **Observability**: CloudWatch with Container Insights, a dashboard and four alarms — one of which alarms on *missing* data, because a backup you believe exists is worse than none. | +| Infrastructure as code | ✅ `infra/terraform` is the system's definition ([README](../infra/terraform/README.md)): `karta.tf` describes the whole system once as data — services, ports, routing, secrets per service, data flows and boundaries — and `terraform output karta` prints the same thing in plain text. The namespace is closed with network policies (only ingress→services, platform→postgres, HTTPS out except private networks), Postgres runs with a security context, and secrets can be generated or come from a secrets manager. Two layers in order: `infra/aws` (VPC, EKS, Aurora, S3, ECR, Secrets Manager, Route 53/ACM, CloudWatch) and `infra/terraform` (the workload), where the second reads the first's outputs so nothing is stated twice. The split is not a matter of taste — an apply that both creates a cluster and schedules into it is a known Terraform trap. | +| Open API | ✅ The platform API is documented with OpenAPI 3.0 (`services/plattform/openapi.yaml`) — auth, users, cases/events (append-only), the supervisor overview, public sharing and the orchestrator, with schemas for every event type. The spec is validated mechanically, parity-tested against the server's routes and served live at `GET /api/openapi.yaml`. | -## Arkitekturprinciper i koden +## Architectural principles in the code -- **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` är motorn (typer, val av metodik, härledning av nästa steg); `src/felsokning/metodiker.ts` är innehållet. Nästa steg härleds ur vad som redan dokumenterats. Biblioteket kan växa utan att motorn ändras, och orkesterns metodikkatalog jämförs mot klientens i test så att listorna inte kan glida isär. -- **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. +- **The event log is the single source of truth.** `src/felsokning/domain.ts` + defines the event types; entries are only appended. +- **All views are projections.** `src/felsokning/projektioner.ts` — the brief, + the time distribution, the handover text and the customer report are pure + functions of the log and can always be regenerated. The tests in + `src/felsokning/__tests__/` lock this. +- **The methodology engine is deterministic.** `src/felsokning/metodik.ts` is the + engine (types, methodology selection, derivation of the next step); + `src/felsokning/metodiker.ts` is the content. The next step is derived from + what is already documented. The library can grow without the engine changing, + and the orchestrator's methodology catalogue is compared against the client's + in a test so the lists cannot drift apart. +- **No conclusion without evidence.** `src/felsokning/ecm.ts` — the rule engine + (ECM) validates every claim against the event log: completion rules, evidence + levels and the quality gate. The camera is the integration layer + (visual-first) — what appears on a screen or an instrument is photographed and + interpreted rather than integrated. +- **Terminology.** The product is described as an evidence-based diagnostic + system / intelligent decision support — in the UI and in customer + communication the words used are *the system / the analysis / the assessment / + the decision support*, never "AI" unless technically necessary. +- **Our own icons.** `src/felsokning/ikoner.tsx` — simple industrial line icons + (SVG, stroke in the current text colour) instead of emojis; reliability and + status levels are shown as colour dots. +- **Industrial workshop UI (ETKA-inspired).** `src/felsokning/ui.tsx` — flat + light-grey surfaces (#ECECEC/#F7F7F7), sharp edges, deep navy as the primary + colour, dense typography (11–15 px), rectangular buttons (max 4 px radius), + toolbar ~44 px. The case page has a classic three-column layout on desktop: a + navigation tree (views plus the methodology steps' status) on the left, the + workspace in the middle, a context panel (technical information, reliability, + technical recommendation) on the right; one column with a tab bar on narrow + screens. -## Medvetna avgränsningar +## Deliberate limitations -- 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. +- The framework for manufacturer integrations exists (the customer enters their + own credentials and looks up vehicle details), but the enriched data sets — + equipment level, recalls, technical service bulletins — are not mapped yet; + the register needs more response fields and vendor profiles before that is + meaningful. diff --git a/felsokning/docs/MVP.sv.md b/felsokning/docs/MVP.sv.md new file mode 100644 index 0000000..6cfde7b --- /dev/null +++ b/felsokning/docs/MVP.sv.md @@ -0,0 +1,82 @@ +# Guidad Felsökning – MVP + +> **Svensk översättning.** Källan är [MVP.md](MVP.md) (engelska). +> Vid avvikelse gäller det engelska dokumentet. + +Första körbara versionen av kärnan i [Master Prompt v2.0](MASTER-PROMPT.sv.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å. + +Fullständig systembeskrivning i ett dokument (för granskning eller resonemang utanför repot): [SYSTEM-DESCRIPTION.md](SYSTEM-DESCRIPTION.md) — engelska är källan, och finns även på [svenska](SYSTEM-DESCRIPTION.sv.md), [tyska](SYSTEM-DESCRIPTION.de.md), [danska](SYSTEM-DESCRIPTION.da.md) och [norska](SYSTEM-DESCRIPTION.no.md). Alla versioner behåller kodidentifierarna oöversatta — koden är svensk oavsett vilket språk dokumentet är på. + +Demomanus för visning: [DEMO.sv.md](DEMO.sv.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, sexton 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 | ✅ **Sexton**, i `src/felsokning/metodiker.ts`: vibration, bromsar, styrning/fjädring, elsystem (relä-exemplet ur visionen), start & laddning, motorgång, kylsystem, drivlina, avgas & emission, klimat, högvolt (elbil/hybrid), felkoder & kommunikation, läckage, missljud, förarassistans (ADAS) — plus generisk. Metodiken väljs på nyckelord ur felbeskrivningen, poängsatt så att det mest specifika ordet vinner (`traktionsbatteri` slår `batteri`); träffar inget väljs generisk, som är strukturellt komplett — ett ärligt "vi vet inte var vi ska börja" i stället för en gissning, varefter orkesterns klassificerare (Haiku 4.5) får försöka. Tre regler är låsta av test: varje kontroll har ett minimikrav, varje metodik börjar med att verifiera symptomet, och där arbetet kan skada någon ligger säkerhetssteget först — högvoltsmetodiken kan inte påbörjas utan dokumenterad spänningsfrihet, urtagen servicebrytare och skyddsutrustning. | +| 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 ([modules/evidence-engine.sv.md](modules/evidence-engine.sv.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 ([modules/brand-integrations.sv.md](modules/brand-integrations.sv.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. | +| Observation | ✅ **Noll nya beroenden**: W3C Trace Context (`traceparent` från klienten genom plattformen till orkestern) och CloudWatch EMF — strukturerad JSON på stdout som CloudWatch extraherar mätvärden ur, utan agent eller SDK. Varje anrop ger en loggrad med **nedbrytning av tiden** per del (databas, modellanrop, objektlagring, leverantörsuppslag), så frågan "var tog tiden vägen" besvaras av en rad i stället för av gissningar. Vägen normaliseras innan den blir dimension och organisation/ärende/spår blir aldrig dimensioner — låst av test, eftersom varje unik kombination är en tidsserie som kostar. Tre larm på det teknikern märker: svarstid p95, serverfel och att modellen avböjer. | +| Drift på AWS | ✅ Allt eget, inget GitHub: **Gitea med egna Actions-runners** i samma kluster, **ECR** med oföränderliga taggar, **EKS** med noder utan publika adresser, **Aurora PostgreSQL** i ett subnätlager utan routing ut, **S3** för bilagor och **Secrets Manager** som sanningskälla för hemligheter — speglade av External Secrets, aldrig synliga för Terraform. Åtkomst via IRSA där varje roll är bunden till exakt ett tjänstekonto i en namnrymd; bygge och drift har skilda roller så ett komprometterat bygge inte kan driftsätta. **Observation**: CloudWatch med Container Insights, instrumentpanel och fyra larm — varav ett larmar på *saknad* data, eftersom en backup man tror finns är värre än ingen. | +| 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. Två lager i ordning: `infra/aws` (VPC, EKS, Aurora, S3, ECR, Secrets Manager, Route 53/ACM, CloudWatch) och `infra/terraform` (arbetslasten), där det andra läser det förstas utdata så inget anges två gånger. Uppdelningen är inte smak — en apply som både skapar ett kluster och schemalägger in i det är en känd Terraform-fälla. | +| Ö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` är motorn (typer, val av metodik, härledning av nästa steg); `src/felsokning/metodiker.ts` är innehållet. Nästa steg härleds ur vad som redan dokumenterats. Biblioteket kan växa utan att motorn ändras, och orkesterns metodikkatalog jämförs mot klientens i test så att listorna inte kan glida isär. +- **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. diff --git a/felsokning/docs/OPERATIONS.md b/felsokning/docs/OPERATIONS.md new file mode 100644 index 0000000..07867d9 --- /dev/null +++ b/felsokning/docs/OPERATIONS.md @@ -0,0 +1,319 @@ +# Guidad Felsökning — operations on Kubernetes (fully self-hosted) + +> Canonical version. Swedish: [OPERATIONS.sv.md](OPERATIONS.sv.md). +> Code identifiers, environment variables and file paths are Swedish and appear +> verbatim. + +The target architecture from the [Master Prompt](MASTER-PROMPT.md) as code: the +whole stack runnable in our own cluster — web, orchestrator, platform backend +(auth + event API + Live Share) and Postgres. No external service dependencies +beyond the Anthropic API for the model calls. + +## Architecture + +```mermaid +flowchart LR + T[Technician] -->|HTTPS| I[Ingress + TLS] + T2[Customer via share link] -->|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 +``` + +| Component | What | Where | +| --- | --- | --- | +| `web` | The SPA behind unprivileged nginx (`Dockerfile`, `docker/nginx.conf`) | Deployment + Service + HPA + PDB | +| `plattform` | Self-hosted backend (`services/plattform`): **multi-tenant** — registration creates an organisation plus a system administrator, admins manage users (technician/supervisor/admin), all case data organisation-isolated. Login (bcrypt via pgcrypto, HS256 JWT with role and org in the claims), append-only event API, public share endpoint | Deployment + Service + HPA + PDB | +| `ai-orkester` | The orchestrator (`services/ai-orkester`): tasks routed to Sonnet 5 / Opus 5 / Haiku 4.5 — verifies the platform's JWT (shared secret) | Deployment + Service + HPA + PDB | +| `postgres` | Event log and users; **append-only guaranteed by database triggers** — history cannot be changed or deleted regardless of role | **Aurora PostgreSQL Serverless v2** outside the cluster, in a subnet layer with no route out. Automatic backup with PITR to the second | +| Secrets | `anthropic-api-key`, `jwt-secret` (shared by platform and orchestrator), `postgres-losenord`, `integration-nyckel` (encrypts the customers' brand-specific credentials) | +| Environment flags | `TILLATNA_URSPRUNG` (CORS list; omitted = `*`), `TILLAT_INTERNA_UPPSLAG` (`true` allows vendor lookups against private networks), `REGISTRERING_OPPEN`, `ECM_REGLER_FIL`, `INTEGRATIONER_FIL` | Secret `felsokning-hemligheter` — never in images or manifests | + +**The client has two operating modes**, chosen at build time: with +`VITE_PLATTFORM_URL`, login, sync, Live Share and the model calls go to the +cluster (fully self-hosted); without it the Supabase mode is used (edge function +plus managed Postgres/Auth) as before. Same event model, same orchestrator — +locked by parity tests. + +## Infrastructure as code + +Two layers, in order: + +| Layer | Where | What | +| --- | --- | --- | +| 1 | `felsokning/infra/aws` | VPC, EKS, Aurora, S3, ECR, Secrets Manager, Route 53/ACM, CloudWatch | +| 2 | `felsokning/infra/terraform` | The workload in the cluster — reads layer 1's outputs | + +The split is not a matter of taste. A single apply that both creates an EKS +cluster and schedules into it is a known trap: the Kubernetes provider has to be +configured with details that do not exist until the cluster does. + +Layer 2 decides almost nothing on its own — `05-aws.tf` reads the base's +outputs, so domain, registry, roles, certificate, bucket and secret names are +stated in exactly one place. + +`terraform output karta` in either layer prints the whole truth in plain text, +straight from the definition. + +## Network boundaries + +The Terraform path closes the namespace and opens only the actual flows: + +| From | To | Why | +| --- | --- | --- | +| the ingress controller | web, plattform, ai-orkester :8080 | the only way in | +| plattform | postgres :5432 | the event log | +| plattform | internet :443 except private networks | the customers' vendors | +| ai-orkester | internet :443 except private networks | Claude | +| web, postgres | — | call nothing | + +The exceptions for private networks (10/8, 172.16/12, 192.168/16, 169.254/16, +127/8, 100.64/10) are the same boundary the code itself enforces in `pekarInat` +— two independent barriers against a customer-configured lookup being used to +reach the cluster's interior or the cloud metadata service. Requires a CNI that +enforces NetworkPolicy; otherwise the rules are documentation, not protection. + +## Deploying + +```sh +# Layer 1 — the AWS base +cd felsokning/infra/aws +cp terraform.tfvars.exempel terraform.tfvars # domain, region, alarm address +terraform init && terraform apply +terraform output karta + +# Layer 2 — the workload +cd ../terraform +cp terraform.tfvars.exempel terraform.tfvars # state bucket and image tag +terraform init && terraform apply -var bildtagg= +``` + +After the first apply, three things remain, listed by `terraform output karta` +under `kvar_att_gora` (still to do): fill in the Claude key in Secrets Manager, +run `felsokning/infra/postgres-init.sql` against Aurora, and narrow +`tillatna_api_cidr` from `0.0.0.0/0`. + +Creating new organisations is closed by default (`registrering_oppen = false`); +users within an organisation are always created by its system administrator. + +## The database + +Aurora PostgreSQL Serverless v2, outside the cluster, in a subnet layer **with +no route out at all** — the database's inability to reach the internet therefore +does not depend on a security group being configured correctly. + +Automatic backup with PITR to the second within the retention window. If the +event log is lost, what disappears is not "data" but every case's probative +value: what was checked, by whom, when, with what evidence. That cannot be +recreated afterwards. + +The schema with the append-only triggers is +`felsokning/infra/postgres-init.sql` — the same file the integration test runs, +so they cannot drift apart. + +## Secrets + +AWS Secrets Manager is the source of truth. External Secrets mirrors them into +the cluster every hour, and the pods read them as ordinary environment +variables. + +**Terraform never sees the values**, and that is the whole point: a secret that +passes through Terraform ends up in the state file. When a secret is rotated, +the cluster follows on its own within the hour. + +Access goes via IRSA: the platform's service account has a role bound to exactly +that account in that namespace. The neighbouring pod on the same node gets +nothing for free, and IMDSv2 with hop limit 1 stops a pod from borrowing the +node's role via the metadata service. The same role signs against S3 — no keys +exist to leak. + +## Attachments + +Photos, video clips and instrument images used to sit as data URLs inside the +events. That affected everything that reads the log: sync dragged the entire +image payload along every fifteen seconds, the customer view likewise, and a +backup of the log was in practice a copy of every photo. + +Now the content lives outside the event and the log carries a reference with the +content's SHA-256. **That strengthens the probative value rather than weakening +it**: the hash sits in the append-only-protected log, so an image that has been +swapped can be detected — previously the image sat in the log and simply had to +be taken on trust. The content is checked against the hash every time it is +served; if it does not match, the service answers 409 instead of showing the +image. + +Content-addressed, so the same photo documented twice is stored once. + +| `bilage_lage` | Where the content lives | Use when | +| --- | --- | --- | +| `databas` (default) | `bilage_innehall` (bytea) | Works everywhere with no configuration; the images travel with the database backups | +| `s3` | S3-compatible object storage (AWS, MinIO, Ceph) | The log and the images should grow independently of each other | + +The signing against object storage is our own (SigV4 for PUT and GET) rather +than the cloud provider's SDK — two operations do not justify tens of megabytes +of dependencies. It is cross-verified against botocore in the tests, bit for +bit. + +**The sharing boundary applies to attachments too.** An attachment can be +fetched through a share link only if the event it belongs to is visible at that +level; the scanned work order is therefore never reachable through the customer +link. + +Older events with an embedded data URL keep working and always will — the log is +append-only. Local mode, without login, also embeds: there is no server to +upload to, and the documentation must not be lost because the network is down. + +## Access: blocking and revocation + +A valid JWT signature is not enough. Every authenticated call looks up the +account and checks two further things: that it is still active, and that the +token version matches. It costs one primary-key lookup per call and in return +gives **immediate** revocation, instead of a suspension taking effect only when +the token expires up to twelve hours later. + +| Situation | Route | Effect | +| --- | --- | --- | +| Someone leaves | `POST /api/anvandare/{id}/avaktivera` (admin) | Login is closed and ongoing sessions end immediately | +| The account should come back | `POST /api/anvandare/{id}/aktivera` (admin) | Can log in again; previously revoked tokens stay dead | +| Phone lost | `POST /api/auth/logga-ut-alla` (oneself) | All devices are logged out | + +An administrator cannot disable themselves, and the boundary between +organisations holds — org B cannot touch org A's users. The event log is never +touched: the history is still tied to the person who did the work. + +**Login rate limiting** lives in the database, not in memory, so the block holds +behind several replicas: 10 failed attempts per account and 30 per source +address within 15 minutes give a 429. The block applies to the account even on a +correct password — otherwise it could be bypassed by whoever eventually guesses +right. Other accounts are unaffected. No password is stored, only that an +attempt happened and whether it succeeded; rows older than a day are cleaned up +on the write path. + +## Observability + +The services deliberately have almost no dependencies. Pulling in an +OpenTelemetry SDK with thirty packages to measure four things would be the wrong +trade, so observability rests on two standards that are both just text on +stdout: + +**W3C Trace Context.** The client starts the trace and `traceparent` travels +through the platform to the orchestrator. A technician's action can therefore be +followed all the way to the model's answer, instead of becoming two unrelated +traces. + +**CloudWatch EMF.** Structured JSON from which CloudWatch itself extracts +metrics — no agent, no SDK, nothing that can silently stop working. + +Every call produces a log line with a **breakdown of the time**: + +```json +{"nivå":"info","meddelande":"plattform","spårId":"fd5dec…","väg":"/api/arenden/:id/handelser", + "status":200,"ms":842.1,"delar":{"databas":{"antal":3,"ms":31.2},"bilaga_skriv":{"antal":1,"ms":780.4}}} +``` + +That answers the question you actually have at three in the morning: *where did +the time go*. Here in object storage, not in the database. + +### The route is always normalised + +The route is normalised (`/api/arenden/:id/handelser`) before it becomes a +dimension. Organisation, case id and trace id **never** become dimensions — +every unique combination is its own time series that costs money. They sit as +ordinary fields, searchable in Logs Insights. A test locks this. + +### Queries that tend to be needed + +``` +# Where did the time go on a slow call? +fields tid, väg, ms, delar.databas.ms, delar.modell_handledning.ms, spårId +| filter ms > 1000 | sort ms desc | limit 20 + +# The whole chain for one trace — platform and orchestrator in the same view +fields tid, meddelande, väg, ms, status | filter spårId = "fd5dec…" | sort tid + +# Which model calls cost the most? +stats sum(ut) as ut_tokens, avg(ms) as snitt by Uppgift, Modell +``` + +### Alarms + +Beyond the infrastructure alarms there are three on the application's own +metrics: response time **p95** above three seconds (the mean hides that every +twentieth technician waits unreasonably long), server errors, and the model +declining — the last of which indicates that the input contains something +unexpected, not an operational fault. + +## Multi-tenancy and roles + +Per the Master Prompt: each customer is its own tenant, no data is mixed between +customers. + +- **Registration creates the organisation** and makes the user its system + administrator. +- **Admins create users** (technician/supervisor/admin) in their organisation — + through the UI or `POST /api/anvandare`. +- **All case data is organisation-scoped**: cases are created in the user's + organisation and the event API verifies organisation membership on every call + — another organisation's cases give a 404. +- **The role lives in the JWT** and is verified on the server; the client only + adapts the UI. + +The integration test (`services/plattform/integrationstest.sh`, also run in CI +against real Postgres) verifies the whole chain: registration, sync, idempotency, +the append-only trigger, organisation isolation, share filtering and role +enforcement. + +## Security and robustness + +- **Append-only in three layers:** the client only appends, the API exposes no + update or delete, and database triggers reject changes even for a + misconfigured role. +- **The JWT flow is verified across the services:** the platform signs, the + orchestrator verifies the same secret; a wrong secret and expired tokens are + rejected (tested). +- All containers run **non-root** without capabilities; the backend services + with a read-only root filesystem. Both fail closed without their secrets. +- **HPA** 2–10 pods per service at 70 % CPU; **PDB** keeps at least one pod up + during node drain; readiness and liveness probes everywhere (`pg_isready` for + Postgres). + +## CI/CD with GitOps + +**CI** (`.gitea/workflows/felsokning.yml`): tests, production build, integration +test against real Postgres and verifying container builds on every push and PR. + +**CD** — all our own, no GitHub. Source code, build, registry and operations +live in our AWS environment. + +```mermaid +flowchart LR + D[Developer] --> G[Gitea +on our own EKS] + G --> R[Actions runner +same cluster] + R --> T[tests +typecheck +integration test] + T --> E[(ECR +immutable tags)] + E -.->|manual step| P[terraform apply] + P --> K[EKS] +``` + +1. **Gitea** runs in the cluster with its own Actions runners. The workflow + syntax is the same as GitHub Actions, so `.gitea/workflows/felsokning.yml` is + the same file that used to sit under `.github` — just moved. +2. **The build** publishes to ECR with immutable tags: a tag that has pointed at + one build cannot point at another, so "which code is running in production" + has an unambiguous answer. +3. **Deployment** is a separate, manual step with an image tag. An image in the + registry is not the same thing as an image that is running. Rollback = run + again with the previous tag. +4. **Split permissions:** the build role may publish to ECR but not touch the + cluster; the operations role the other way round. A compromised build cannot + deploy. + +`.github/workflows/ci.yml` belongs to Semantika and is not touched. diff --git a/felsokning/docs/DRIFT.md b/felsokning/docs/OPERATIONS.sv.md similarity index 96% rename from felsokning/docs/DRIFT.md rename to felsokning/docs/OPERATIONS.sv.md index b529f9f..06f7cae 100644 --- a/felsokning/docs/DRIFT.md +++ b/felsokning/docs/OPERATIONS.sv.md @@ -1,6 +1,9 @@ # 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. +> **Svensk översättning.** Källan är [OPERATIONS.md](OPERATIONS.md) (engelska). +> Vid avvikelse gäller det engelska dokumentet. + +Målarkitekturen ur [Master Prompt](MASTER-PROMPT.sv.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 @@ -256,7 +259,7 @@ Integrationstestet (`services/plattform/integrationstest.sh`, körs även i CI m ## CI/CD med GitOps -**CI** (`.github/workflows/ci.yml`): tester, produktionsbygge, integrationstest mot riktig Postgres och verifierande containerbyggen på varje push/PR. +**CI** (`.gitea/workflows/felsokning.yml`): tester, produktionsbygge, integrationstest mot riktig Postgres och verifierande containerbyggen på varje push/PR. **CD** — allt eget, inget GitHub. Källkod, bygge, register och drift ligger i vår AWS-miljö. diff --git a/felsokning/docs/SYSTEM-DESCRIPTION.da.md b/felsokning/docs/SYSTEM-DESCRIPTION.da.md index 8694a0f..a237ec3 100644 --- a/felsokning/docs/SYSTEM-DESCRIPTION.da.md +++ b/felsokning/docs/SYSTEM-DESCRIPTION.da.md @@ -825,15 +825,18 @@ docs/VISION.md produktvisionen docs/MASTER-PROMPT.md grundinstruktionen docs/MVP.md hvad der er bygget, funktion for funktion docs/DEMO.md demomanuskript til fremvisning -docs/DRIFT.md drift +docs/OPERATIONS.md drift docs/SYSTEM-DESCRIPTION.md engelsk — den gældende udgave docs/SYSTEM-DESCRIPTION.sv.md svensk docs/SYSTEM-DESCRIPTION.de.md tysk docs/SYSTEM-DESCRIPTION.da.md dette dokument docs/SYSTEM-DESCRIPTION.no.md norsk (bokmål) -docs/exempel/vibration-vid-88-km-h.md gennemgående eksempel -docs/moduler/ otte moduldokumenter +docs/examples/vibration-at-88-km-h.md gennemgående eksempel +docs/modules/ otte moduldokumenter ``` +Alle dokumenter ovenfor har engelsk som kilde og et `.sv.md`-søskendedokument +på svensk. Kun SYSTEM-DESCRIPTION findes på alle fem sprog. + --- diff --git a/felsokning/docs/SYSTEM-DESCRIPTION.de.md b/felsokning/docs/SYSTEM-DESCRIPTION.de.md index c62884a..252ba4f 100644 --- a/felsokning/docs/SYSTEM-DESCRIPTION.de.md +++ b/felsokning/docs/SYSTEM-DESCRIPTION.de.md @@ -858,15 +858,18 @@ docs/VISION.md die Produktvision docs/MASTER-PROMPT.md die Gründungsinstruktion docs/MVP.md was gebaut ist, Funktion für Funktion docs/DEMO.md Demoskript für Vorführungen -docs/DRIFT.md Betrieb +docs/OPERATIONS.md Betrieb docs/SYSTEM-DESCRIPTION.md Englisch — die maßgebliche Fassung docs/SYSTEM-DESCRIPTION.sv.md Schwedisch docs/SYSTEM-DESCRIPTION.de.md dieses Dokument docs/SYSTEM-DESCRIPTION.da.md Dänisch docs/SYSTEM-DESCRIPTION.no.md Norwegisch (Bokmål) -docs/exempel/vibration-vid-88-km-h.md durchgerechnetes Beispiel -docs/moduler/ acht Moduldokumente +docs/examples/vibration-at-88-km-h.md durchgerechnetes Beispiel +docs/modules/ acht Moduldokumente ``` +Alle Dokumente oben sind auf Englisch maßgeblich und haben ein schwedisches +`.sv.md`-Gegenstück. Nur SYSTEM-DESCRIPTION liegt in allen fünf Sprachen vor. + --- diff --git a/felsokning/docs/SYSTEM-DESCRIPTION.md b/felsokning/docs/SYSTEM-DESCRIPTION.md index 4aa2095..1f7ddff 100644 --- a/felsokning/docs/SYSTEM-DESCRIPTION.md +++ b/felsokning/docs/SYSTEM-DESCRIPTION.md @@ -833,15 +833,18 @@ docs/VISION.md the product vision docs/MASTER-PROMPT.md the founding instruction docs/MVP.md what is built, feature by feature docs/DEMO.md demo script for presentations -docs/DRIFT.md operations +docs/OPERATIONS.md operations docs/SYSTEM-DESCRIPTION.md this document — the canonical version docs/SYSTEM-DESCRIPTION.sv.md Swedish docs/SYSTEM-DESCRIPTION.de.md German docs/SYSTEM-DESCRIPTION.da.md Danish docs/SYSTEM-DESCRIPTION.no.md Norwegian (Bokmål) -docs/exempel/vibration-vid-88-km-h.md worked example -docs/moduler/ eight module documents +docs/examples/vibration-at-88-km-h.md worked example +docs/modules/ eight module documents ``` +Every document above is canonical in English; each has a `.sv.md` Swedish +sibling. Only SYSTEM-DESCRIPTION is translated into all five languages. + --- diff --git a/felsokning/docs/SYSTEM-DESCRIPTION.no.md b/felsokning/docs/SYSTEM-DESCRIPTION.no.md index 3e93fa4..7de04f7 100644 --- a/felsokning/docs/SYSTEM-DESCRIPTION.no.md +++ b/felsokning/docs/SYSTEM-DESCRIPTION.no.md @@ -822,15 +822,18 @@ docs/VISION.md produktvisjonen docs/MASTER-PROMPT.md grunninstruksjonen docs/MVP.md hva som er bygget, funksjon for funksjon docs/DEMO.md demomanus for framvisning -docs/DRIFT.md drift +docs/OPERATIONS.md drift docs/SYSTEM-DESCRIPTION.md engelsk — den gjeldende utgaven docs/SYSTEM-DESCRIPTION.sv.md svensk docs/SYSTEM-DESCRIPTION.de.md tysk docs/SYSTEM-DESCRIPTION.da.md dansk docs/SYSTEM-DESCRIPTION.no.md dette dokumentet -docs/exempel/vibration-vid-88-km-h.md gjennomgående eksempel -docs/moduler/ åtte moduldokumenter +docs/examples/vibration-at-88-km-h.md gjennomgående eksempel +docs/modules/ åtte moduldokumenter ``` +Alle dokumentene over har engelsk som kilde og et `.sv.md`-søskendokument på +svensk. Bare SYSTEM-DESCRIPTION finnes på alle fem språk. + --- diff --git a/felsokning/docs/SYSTEM-DESCRIPTION.sv.md b/felsokning/docs/SYSTEM-DESCRIPTION.sv.md index 463043f..dfe6351 100644 --- a/felsokning/docs/SYSTEM-DESCRIPTION.sv.md +++ b/felsokning/docs/SYSTEM-DESCRIPTION.sv.md @@ -794,14 +794,14 @@ docs/VISION.md produktvisionen docs/MASTER-PROMPT.md grundinstruktionen docs/MVP.md vad som är byggt, funktion för funktion docs/DEMO.md demomanus för visning -docs/DRIFT.md drift +docs/OPERATIONS.md drift docs/SYSTEM-DESCRIPTION.md engelska — källan docs/SYSTEM-DESCRIPTION.sv.md detta dokument docs/SYSTEM-DESCRIPTION.de.md tyska docs/SYSTEM-DESCRIPTION.da.md danska docs/SYSTEM-DESCRIPTION.no.md norska (bokmål) -docs/exempel/vibration-vid-88-km-h.md genomgående exempelflöde -docs/moduler/ +docs/examples/vibration-at-88-km-h.md genomgående exempelflöde +docs/modules/ arbetslogg-och-tidredovisning.md arendebrief.md evidensmotor.md @@ -811,6 +811,9 @@ docs/moduler/ markesspecifika-kopplingar.md verifierade-checklistor.md ``` +Samtliga dokument ovan har engelska som källa och ett `.sv.md`-syskon på +svenska. Bara SYSTEM-DESCRIPTION finns på alla fem språk. + --- diff --git a/felsokning/docs/VISION.md b/felsokning/docs/VISION.md index 9608f94..7342168 100644 --- a/felsokning/docs/VISION.md +++ b/felsokning/docs/VISION.md @@ -1,180 +1,218 @@ -# Guidad Felsökning +# Guidad Felsökning (Guided Diagnostics) -> Styrdokument för utveckling: [Master Prompt v2.0](MASTER-PROMPT.md) +> Canonical version. Swedish: [VISION.sv.md](VISION.sv.md). +> Development is governed by [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. +Guidad Felsökning is a professional diagnostic platform that guides technicians +step by step through a structured diagnostic process. The platform documents +every step, retrieves information from the manufacturer's systems using the +user's own credentials, and creates a complete, traceable diagnostic history. -Systemet ersätter inte teknikerens kompetens – det säkerställer att arbetet utförs metodiskt, dokumenteras korrekt och kan följas i efterhand. +The system does not replace the technician's competence — it ensures the work is +carried out methodically, documented correctly, and can be reviewed afterwards. -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. +The product should not try to be an automated mechanic, but a **digital +diagnostic supervisor**. That makes it both more credible and easier to use in +professional environments. --- -## Ledstjärna +## Guiding principle -> **Systemet dokumenterar observationer, leder användaren genom verifierbara kontroller och rekommenderar nästa steg – men presenterar aldrig en hypotes som ett konstaterat fel.** +> **The system documents observations, leads the user through verifiable checks +> and recommends the next step — but never presents a hypothesis as a confirmed +> fault.** -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. +That principle makes the tool useful both to experienced technicians and to less +experienced users, while providing a robust record for customers, workshops and +future analysis. Guidad Felsökning is a digital diagnostic process, not a chat. --- -## Grundprinciper +## Core principles -### 1. Ingen gissning +### 1. No guessing -Systemet får aldrig presentera spekulation som fakta. +The system must never present speculation as fact. -Varje påstående märks med en tillförlitlighetsnivå: +Every claim is marked with a confidence level: -- 🟢 **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. +- 🟢 **High** — verified through measurement, manufacturer information or the + user's own input. +- 🟡 **Medium** — a logical conclusion based on available information. +- 🔴 **Low** — a hypothesis or possible cause requiring verification. -Om tillräckligt underlag saknas ska systemet uttryckligen säga det. +If there is not enough to go on, the system must say so explicitly. -### 2. Identifiera objektet först +### 2. Identify the object first -Ingen felsökning börjar innan objektet identifierats. +No diagnosis begins before the object has been identified. -Identifiering kan ske genom: +Identification can happen through: -- registreringsnummer +- registration number - VIN -- maskinnummer -- serienummer -- QR-kod -- streckkod -- OCR från typskylt -- foto av objektet -- manuell inmatning av objekt-ID +- machine number +- serial number +- QR code +- barcode +- OCR from the type plate +- a photo of the object +- manual entry of an object ID -När identifieringen är klar visas en tydlig bekräftelse innan felsökningen fortsätter. +Once identification is complete, a clear confirmation is shown before the +diagnosis continues. -### 3. Integration med tillverkarsystem +### 3. Integration with manufacturer systems -Användaren ansluter sina egna behörigheter via API eller motsvarande integrationslösning. +The user connects their own credentials via an API or an equivalent integration. -Exempel på informationskällor: +Examples of information sources: -- tillverkarens verkstadssystem -- reservdelskataloger -- elscheman -- servicebulletiner -- servicehistorik -- elektroniska serviceböcker -- interna DMS-system +- the manufacturer's workshop system +- parts catalogues +- wiring diagrams +- service bulletins +- service history +- electronic service books +- internal DMS systems -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. +Guidad Felsökning uses these as reference but does not store copyrighted +documentation unless the user or the organisation has the right to do so. -### 4. Samtalsbaserad guidning +### 4. Conversational guidance -Teknikern arbetar naturligt: +The technician works naturally: -> ”Jag har mätt.” +> "I've measured." > -> ”Det finns 13,9 volt.” +> "There's 13.9 volts." > -> ”Reläet klickar inte.” +> "The relay doesn't click." -Systemet väljer nästa steg utifrån tidigare observationer och den etablerade felsökningsmetodiken. +The system chooses the next step based on earlier observations and the +established diagnostic methodology. -### 5. Fullständig revisionslogg +### 5. Complete audit log -Varje aktivitet registreras. +Every activity is recorded. -Exempel på loggposter: +Examples of log entries: -- tidpunkt -- användare -- objekt -- mätvärden -- bilder -- dokument -- observationer -- AI:s rekommendation -- användarens svar -- nästa steg +- timestamp +- user +- object +- measured values +- images +- documents +- observations +- the system's recommendation +- the user's answer +- next step -Ingenting skrivs över. Händelser läggs endast till, vilket ger full spårbarhet. +Nothing is overwritten. Events are only appended, which gives full traceability. -### 6. Export och API +### 6. Export and API -Varje avslutat ärende kan exporteras som ett strukturerat felsökningsprotokoll. +Every completed case can be exported as a structured diagnostic record. -Det ska även finnas ett API för att: +There should also be an API for: -- hämta loggar -- hämta rapporter -- koppla mot DMS -- koppla mot affärssystem -- koppla mot ERP -- koppla mot elektroniska serviceböcker -- koppla mot garantiadministration +- retrieving logs +- retrieving reports +- connecting to a DMS +- connecting to business systems +- connecting to an ERP +- connecting to electronic service books +- connecting to warranty administration -På så sätt blir Guidad Felsökning en komponent i befintliga arbetsflöden, inte ett isolerat system. +In this way Guidad Felsökning becomes a component in existing workflows, not an +isolated system. --- -## Moduler +## Modules -Utöver grundprinciperna byggs plattformen upp av moduler som specificeras separat: +Beyond the core principles, the platform is built from modules specified +separately: -- [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. +- [Work log and time tracking](modules/work-log-and-time-tracking.md) — timed, + traceable work tied to concrete activities; a digital work record in which + time, activity and technical reasoning hang together. +- [Shareable customer report (customer view)](modules/customer-report.md) — a + clear timeline with images, measured values and comments that shows the + customer what they actually paid for. +- [The case brief](modules/case-brief.md) — a continuously updated working + picture of the case that makes a new technician productive in under a minute; + a multi-user workspace with one-click handover. +- [Communication model (voice)](modules/communication-model.md) — speech in, + text out via push-to-talk; voice is an input method, not a separate interface, + and nothing is sent without confirmation. +- [Verified checklists](modules/verified-checklists.md) — a check item is not + complete by ticking a box; every check collects evidence and context, with a + minimum requirement per type of check. +- [Live Share](modules/live-share.md) — a permission-controlled share link that + shows the case in real time; versioned exports from the same event log. -Hur processen fungerar i praktiken illustreras i exempelflödet [”Bilen vibrerar runt 88 km/h”](exempel/vibration-vid-88-km-h.md). +How the process works in practice is illustrated in the worked example +["The car vibrates at around 88 km/h"](examples/vibration-at-88-km-h.md). --- -## Användargränssnitt +## User interface -Gränssnittet ska vara avsiktligt enkelt. +The interface should be deliberately simple. -Ingen chatt med långa AI-svar. +No chat with long generated answers. -Istället: +Instead: -- en fråga i taget -- en tydlig rekommenderad åtgärd -- stora knappar -- tydliga statusindikatorer -- hög kontrast -- få val per skärm +- one question at a time +- one clear recommended action +- large buttons +- clear status indicators +- high contrast +- few choices per screen -Designen ska ge samma känsla som ett modernt fabriksverktyg: funktion före estetik. +The design should give the same feeling as a modern factory tool: function +before aesthetics. --- -## Säkerhet +## Security -Systemet ska utformas för professionell användning med fokus på informationssäkerhet. +The system is designed for professional use with a focus on information +security. -Målet är att: +The aim is to: -- 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. +- encrypt data in transit and at rest, +- log all changes and access, +- support role-based access control, +- offer secure API authentication, +- enable export and deletion in line with the organisation's policy and + applicable regulation. --- -## Produktfilosofi +## Product philosophy -Den viktigaste principen är att Guidad Felsökning aldrig försöker ersätta teknikern. +The most important principle is that Guidad Felsökning never tries to replace +the technician. -Den ersätter inte erfarenhet. +It does not replace experience. -Den ersätter inte tillverkarens dokumentation. +It does not replace the manufacturer's documentation. -Den ersätter inte verkstadshandboken. +It does not replace the workshop manual. -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. +It acts as a consistent supervisor that ensures the right questions are asked in +the right order, that no steps are overlooked, and that the whole diagnostic +process is documented in a way that is traceable, reusable and easy to integrate +with the rest of the organisation's systems. -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. +That gives workshops and service organisations higher quality, more consistent +working methods, better knowledge transfer between technicians, and a clear +record towards customers, warranty handling and internal follow-up. diff --git a/felsokning/docs/VISION.sv.md b/felsokning/docs/VISION.sv.md new file mode 100644 index 0000000..fa7c866 --- /dev/null +++ b/felsokning/docs/VISION.sv.md @@ -0,0 +1,183 @@ +# Guidad Felsökning + +> **Svensk översättning.** Källan är [VISION.md](VISION.md) (engelska). +> Vid avvikelse gäller det engelska dokumentet. + +> Styrdokument för utveckling: [Master Prompt v2.0](MASTER-PROMPT.sv.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](modules/work-log-and-time-tracking.sv.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)](modules/customer-report.sv.md) – en tydlig tidslinje med bilder, mätvärden och kommentarer som visar kunden vad de faktiskt betalat för. +- [Ärendebrief](modules/case-brief.sv.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)](modules/communication-model.sv.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](modules/verified-checklists.sv.md) – en kontrollpunkt är inte slutförd genom en kryssruta; varje kontroll samlar bevis och kontext med minimikrav per kontrolltyp. +- [Live Share](modules/live-share.sv.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”](examples/vibration-at-88-km-h.sv.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. diff --git a/felsokning/docs/modules/brand-integrations.sv.md b/felsokning/docs/modules/brand-integrations.sv.md index 61a4deb..b0afcbc 100644 --- a/felsokning/docs/modules/brand-integrations.sv.md +++ b/felsokning/docs/modules/brand-integrations.sv.md @@ -100,5 +100,5 @@ Fullständigt dokumenterat i `services/plattform/openapi.yaml`. `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; +[OPERATIONS.sv.md](../OPERATIONS.sv.md). Byts nyckeln måste kopplingarna sparas om; tjänsten visar då inga värden i stället för att gissa.