Garantiregimer, försäkringsvillkor och felanmälan i ärendet

---- Garantier (ALVA-SPEC-040) -----------------------------------------

Skiljelinjen mellan LAGSTADGAT och AVTALAT bär allt annat, och den
förväxlas dagligen åt bägge håll. Överraskande lite av det verkstaden
kallar garanti är lagstadgat:

  nybilsgaranti      avtalad. Ingen lag i EU eller USA kräver den.
  rostskyddsgaranti  avtalad. Ingen lag kräver den, någonstans.
  lackgaranti        avtalad.
  drivlinegaranti    avtalad.
  avgasgaranti       LAGSTADGAD i bägge, och den enda som är det.

Att kalla rostskyddet lagstadgat är fel; att kalla avgasgarantin en
tillverkarutfästelse är fel åt andra hållet, och det andra felet kostar
kunden pengar — en katalysator på en sexårig bil offereras rutinmässigt
som en betald reparation när den inte är det.

Varje lagstadgad post bär källa och kontrolldatum: 2019/771 (2 år,
säljaren — inte tillverkaren), MVBER 461/2010 förlängd till 2028,
715/2007 (5 år/100 000 km), 2024/1257 (8 år/160 000 km, batteri 80 %
vid 5 år och 72 % vid 8), CAA § 207 (2/24 000 och 8/80 000 miles),
Magnuson–Moss § 2302(c), CARB (3/50 000 och 7/70 000), ACC II (70 % SoH
vid 8 år/100 000 miles).

Bedömningen skiljer INOM, UTANFÖR och OKLART. Saknas underlag blir det
oklart, aldrig utanför — att påstå att en garanti gått ut när underlaget
inte räcker är det enda felet här som kostar kunden pengar.

---- Försäkring (ALVA-SPEC-041) ----------------------------------------

Modulen avgör ingenting och kan inte avgöra något. Vad som gäller
bestäms av kundens eget försäkringsbrev och villkoren vid tecknandet —
inte av vad ett bolag skriver i dag och inte av vad vi noterat. Testerna
låser att resultatet inte innehåller något fält som liknar ett utfall,
och att ett fordon utanför samtliga noterade gränser ändå inte får ett
nej: registret kan vara ofullständigt och produkten en annan.

Det som står överst är de sju villkoren som avgör en maskinskadefråga.
Ålder och sträcka är två av dem; de fem andra avgör oftare. Registret
med If, Folksam, Trygg-Hansa, Svedea, WaterCircles och Hedvig ligger
under, med källa och avläsningsdatum per post, och märks som föråldrat
efter 180 dagar i stället för att se aktuellt ut.

---- Felanmälan i ärendet (ALVA-PROC-0050) -----------------------------

En anmälningsknapp som bara finns i en portalvy nås aldrig av den som
står med händerna i en bil. Den ligger därför i varje ärende, och tar
med sitt sammanhang självt: ärende, metodik, plattformsversion och
spår-id. Teknikern minns inte plattformsversionen, och att fråga efter
den är att lägga över vårt problem på verkstaden.

Sammanhanget HÄRLEDS och kan inte smugglas: ett regnr i anropet släpps
inte igenom. En supportanmälan är inte ett skäl att flytta
personuppgifter till ett annat system. Bevisat i integrationstestet.

Anmälan är oföränderlig och statusen en projektion av inläggen — samma
skäl som för fakturan: en anmälan vars historia kan skrivas om är inte
ett underlag när någon frågar hur länge felet var känt. Verkstaden
svarar i sitt eget ärende; status sätts av supporten med egen nyckel.

---- Historikkontrollen -------------------------------------------------

Kravet fanns redan: klienten öppnar inte metodiken förrän
pre-diagnostiken är besvarad, och ett nej kräver skriven motivering.
Det var dock aldrig BEVISAT att spärren håller. Genomgången prövar nu
att metodiken inte går att nå medan historikfrågan står obesvarad — i
det enda ögonblick det går att pröva, eftersom svaret därefter redan är
avgivet.

429 enhetstester · 157 integrationskontroller mot riktig Postgres ·
genomgången 4/4 · portalspärren 16/16.

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

felsokning/services/gemensam/support.mjs

@@ -0,0 +1,108 @@
+// ALVA-PROC-0050 · Felanmälan och supportärenden.
+//
+// ---- Varför anmälan sitter i ärendet ------------------------------------
+//
+// En felanmälan som skrivs någon annanstans än där felet uppstod tappar
+// det som gör den användbar. Teknikern minns inte ärendenumret, vet inte
+// vilken metodik som kördes, och kan inte plattformsversionen — så
+// anmälan blir "det funkar inte" och supporten får börja med att fråga
+// tillbaka. Två dagar går innan någon vet vad som hände.
+//
+// Sammanhanget HÄRLEDS därför i stället för att skrivas in: ärende,
+// metodik, plattformsversion, spår-id och vilket steg som var öppet. Det
+// är samma hållning som mot sammanfattningen och fakturan — det som går
+// att härleda ska inte skrivas av.
+//
+// ---- Status är en projektion --------------------------------------------
+//
+// Anmälan är oföränderlig. Det som händer med den — svar, statusbyten —
+// är egna poster, och statusen härleds ur dem. Samma skäl som för
+// fakturan: en anmälan vars historia kan skrivas om är inte ett underlag
+// när någon senare frågar hur länge felet var känt.
+
+/** ALVA-SUP-0001 */
+export const supportbeteckning = (nummer) => `ALVA-SUP-${String(nummer).padStart(4, "0")}`;
+
+/**
+ * Vad anmälan gäller.
+ *
+ * Skilt åt därför att de har olika brådska och olika mottagare. En
+ * felanmälan om systemet mitt i ett ärende blockerar arbete just nu;
+ * ett förbättringsförslag gör det inte, och att blanda dem gör att
+ * bägge behandlas som det senare.
+ */
+export const TYPER = [
+  { id: "felanmalan", rubrik: "Fault report", text: "The platform did something wrong, or stopped working." },
+  { id: "fraga", rubrik: "Question", text: "The methodology or the rules are unclear in this case." },
+  { id: "forbattring", rubrik: "Improvement", text: "Something works, but could work better." },
+];
+
+/**
+ * Tillstånden. Ordningen är enkelriktad — utom att en stängd anmälan kan
+ * öppnas igen, vilket händer när felet visar sig inte vara borta.
+ */
+export const STATUSAR = ["mottagen", "under_arbete", "atgardad", "stangd"];
+
+/**
+ * Statusen härleds ur inläggen, den lagras inte.
+ *
+ * Senaste statusposten gäller. Saknas statusposter är anmälan mottagen —
+ * det är vad den är i det ögonblick den skapas, och ingenting behöver
+ * skrivas för att det ska bli sant.
+ */
+export function supportstatus(inlagg = []) {
+  const senaste = [...inlagg].filter((i) => i?.typ === "status" && STATUSAR.includes(i.status)).pop();
+  return senaste?.status ?? "mottagen";
+}
+
+/**
+ * Granskar en anmälan innan den tas emot.
+ *
+ * Kraven är låga med flit. En tröskel som gör det jobbigt att anmäla ger
+ * färre anmälningar, inte färre fel — och de fel som inte anmäls är de
+ * som lever längst. Men en rubrik som "fel" och en tom beskrivning gör
+ * anmälan obrukbar för den som ska svara, så det finns ett golv.
+ */
+export function granskaAnmalan({ typ, rubrik, beskrivning } = {}) {
+  if (!TYPER.some((t) => t.id === typ)) return "Ange vad anmälan gäller.";
+  if (typeof rubrik !== "string" || rubrik.trim().length < 5) {
+    return "Rubriken behöver säga vad det gäller — minst fem tecken.";
+  }
+  if (rubrik.trim().length > 200) return "Rubriken är för lång (max 200 tecken).";
+  if (typeof beskrivning !== "string" || beskrivning.trim().length < 20) {
+    return "Beskriv vad som hände och vad du väntade dig — minst tjugo tecken. Den som ska svara ser inte din skärm.";
+  }
+  if (beskrivning.length > 20_000) return "Beskrivningen är för lång (max 20 000 tecken).";
+  return null;
+}
+
+/**
+ * Sammanhanget, härlett ur det som redan finns.
+ *
+ * Fälten är medvetet få och tekniska. Ingenting identifierande om
+ * fordonet eller kunden följer med: en supportanmälan är inte ett skäl
+ * att flytta personuppgifter till ett annat system, och den som svarar
+ * behöver dem inte för att läsa ett spår.
+ */
+export function sammanhang({ arendeId, metodikId, steg, plattformsversion, sparId, klient } = {}) {
+  const ut = {};
+  if (arendeId) ut.arende = String(arendeId);
+  if (metodikId) ut.metodik = String(metodikId);
+  if (steg) ut.steg = String(steg);
+  if (plattformsversion) ut.plattform = String(plattformsversion);
+  if (sparId) ut.spar = String(sparId);
+  if (klient) ut.klient = String(klient).slice(0, 200);
+  return ut;
+}
+
+/** Fälten som ALDRIG får följa med en anmälan. Låst av test. */
+export const FORBJUDET_I_SAMMANHANG = [
+  "identifierare",
+  "regnr",
+  "vin",
+  "agare",
+  "kund",
+  "personnummer",
+  "telefon",
+  "epost",
+];