Dokumenter kart-CSS-fiksen i CHANGELOG.md

Punkt 51. Se forrige commit for koden.

CHANGELOG.md

@@ -9388,3 +9388,85 @@ Neste steg:
     faktisk postet riktig tekst til `/rounds/{id}/messages`, slettet
     7-jern-slaget og bekreftet det forsvant fra listen ("1 slag målt"
     etterpå). Scratch-miljøet ryddet opp fullstendig.
+
+51. **PRODUKSJONSBUG: kart-steget viste "Kunne ikke laste kartet" for
+    alle -- CSS-arv-krasj med mapbox-gl.css — 2026-08-08, brukeroppfølging
+    ("jeg ser ikke noe kart eller satellittfoto").** Bruker bekreftet
+    "alle tre" da spurt hvor de forventet kart/foto: (1) kart-valg under
+    måling, (2) forhåndsvisning i resultatsteget, (3) bilde i den delte
+    meldingen.
+
+    **(1) Rotårsak:** `mapbox-gl.css` (selve biblioteket sin stilark,
+    importert i `map-point-picker.tsx`) definerer `.mapboxgl-map {
+    position: relative }`. Mapbox GL JS legger `mapboxgl-map`-klassen til
+    PÅ kart-beholderen sin egen `<div>` ved initialisering -- denne
+    klassen kom SENERE i CSS-cascaden enn Tailwind sin `absolute`-klasse
+    (samme element), og vant dermed kappløpet, og overstyrte `position`
+    fra `absolute` til `relative`. Så snart `position` ikke lenger var
+    `absolute`, mistet Tailwind sin `inset-0`-klasse all effekt på
+    STØRRELSEN (den styrer kun posisjon for absolutt/fixed-plasserte
+    elementer) -- beholderen kollapset til `height: 0`, og selve
+    Mapbox-kartet (som TEKNISK sett lastet helt fint -- style/tiles/
+    events ga alle 200/204) ble usynlig, klippet vekk av en 0px-høy
+    forelder. Bekreftet direkte via `getBoundingClientRect()`-kjeden opp
+    DOM-treet: `containerRect.height: 0` til tross for at Mapbox sitt
+    eget `<canvas>`-element hadde en normal størrelse. Rettet ved å bytte
+    `absolute inset-0` til `h-full w-full` på beholder-diven -- løser
+    størrelsen via prosent-arv, upåvirket av hvilken `position`-verdi som
+    vinner cascade-kappløpet.
+
+    Denne konkrete feilen kunne IKKE vært fanget opp i noen av de
+    tidligere scratch-testene denne økten (femtende, sekstende), siden
+    Mapbox sitt eget offentlige token alltid ble avvist av URL-
+    restriksjonen mot `localhost`-scratch-opprinnelser der -- kartet
+    kom aldri langt nok til å faktisk RENDRE for at CSS-krasjen skulle
+    bli synlig. Verifisert denne runden ved å midlertidig overstyre
+    nettleserens `Referer`-header til `https://teecup.golf/` (CDP-nivå,
+    forbi selve nettleserens fetch()-header-restriksjon) for å simulere
+    det ekte, godkjente domenet i scratch -- avdekket samtidig at
+    scratch-testen selv hadde en snubletråd: en `grep`-basert token-
+    utpakking (`grep NEXT_PUBLIC_MAPBOX_TOKEN .env`, uten `^`-anker)
+    matchet FEILAKTIG også `.env` sin forklarende kommentarlinje over
+    selve variabelen (som også inneholder teksten "NEXT_PUBLIC_MAPBOX_
+    TOKEN"), og satte sammen kommentarteksten med selve tokenet til en
+    ugyldig verdi -- bekreftet at DENNE spesifikke feilen kun rammet
+    scratch-testverktøyet mitt, ikke selve produksjonsutrullingen
+    (`docker-compose.yml` sin `${NEXT_PUBLIC_MAPBOX_TOKEN}`-variabel-
+    substitusjon er upåvirket, bekreftet ved å grepe direkte i den ekte,
+    kjørende frontend-containerens bygde JS-bunt).
+
+    Underveis avdekket også en ekte SERVICE WORKER-cache-fallgruve verdt
+    å ha i bakhoden for senere feilsøking: en omstart av scratch-
+    frontend-containeren (SAMME port) beholdt en GAMMEL, cachet JS-bunt
+    i nettleseren til service workeren ble eksplisitt avregistrert og
+    cachen tømt -- PWA-installasjonen cacher altså aggressivt nok til å
+    overleve en full container-utrulling, noe som er relevant å huske
+    ved fremtidig feilsøking av "jeg ser fortsatt det gamle" -rapporter.
+
+    **(2) Bygget (ikke opprinnelig planlagt, brukerønske):** en client-
+    side forhåndsvisning i resultatsteget, FØR "Lagre slag" trykkes.
+    Bruker Mapbox Static Images API direkte som en `<img src>`, med det
+    OFFENTLIGE tokenet (trygt i nettleseren) -- ingen server-tur-retur
+    nødvendig kun for en forhåndsvisning, adskilt fra selve delingens
+    server-side-genererte bilde (som fortsatt inkluderer en linje mellom
+    punktene, ikke bare to nåler).
+
+    **(3) Allerede fungerende:** bekreftet tidligere denne økten
+    (scratch18, punkt 48) at selve delings-bildegenereringen fungerer
+    server-side med `TEECUP_MAPBOX_SECRET_TOKEN` -- brukerens opplevelse
+    av "ingen bilde" der skyldtes at selve DELINGEN aldri fullførte
+    (punkt 50s diagnose: "Del i feeden"-valget nullstilles hver gang
+    arket åpnes på nytt), ikke en feil i bildegenereringen selv.
+
+    `tsc --noEmit` rent. **Scratch-verifisert i ekte nettleser** (tjueførste
+    scratch-miljø denne økten, samme migrasjon-002-forsiktighet,
+    `teecup_db` bekreftet uendret) MED `Referer`-overstyring for å komme
+    forbi URL-restriksjonen: kartet viste nå ekte satellittbilder (Oslo
+    sentrum, default-koordinat), et simulert klikk på kartet plasserte en
+    markør korrekt og aktiverte "Bekreft punkt", og resultatsteget viste
+    en korrekt forhåndsvisning med A/B-markører og riktig avstand (130m).
+    Scratch-miljøet ryddet opp fullstendig.
+
+    **Rullet ut umiddelbart** (produksjonsbug som traff ALLE brukere som
+    prøvde kart-basert måling) -- kun frontend-image, `teecup_api`
+    bekreftet uendret.