From d0167b3882eb2aaa3f06bb408943c325ff315b12 Mon Sep 17 00:00:00 2001
From: Erol Haagenrud <erol.haagenrud@envide.no>
Date: Sat, 8 Aug 2026 15:06:59 +0200
Subject: [PATCH] =?UTF-8?q?Dokumenter=20slagm=C3=A5ling-produksjonsbugfiks?=
 =?UTF-8?q?en=20i=20CHANGELOG.md?=
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit

Punkt 49. Se forrige commit for koden.
---
 CHANGELOG.md | 47 +++++++++++++++++++++++++++++++++++++++++++++++
 1 file changed, 47 insertions(+)

diff --git a/CHANGELOG.md b/CHANGELOG.md
index 161f760..f79f3dd 100644
--- a/CHANGELOG.md
+++ b/CHANGELOG.md
@@ -9285,3 +9285,50 @@ Neste steg:
     Med dette er ADR-048 (slag-for-slag GPS-avstandsmåling) fullt bygget,
     verifisert og live -- begge inngangspunkt, begge hull-eiertyper,
     begge Mapbox-token-veier (kart-valg + delings-satellittbilde).
+
+49. **PRODUKSJONSBUG: slagmåling ga alltid 0 meter, delinger forsvant
+    stille — 2026-08-08, brukerrapport rett etter punkt 48s utrulling.**
+    Brukeren: "den målte aldri mer enn 0 meter. Jeg så ingen bilder."
+
+    **Rotårsak 1 (selve 0-meter-buggen):** `shot-measurement-sheet.tsx`
+    sitt "end"-steg (ballens posisjon) avfyrte GPS-målingen AUTOMATISK i
+    et `useEffect` idet steget ble aktivt -- rett etter at startpunktet
+    var målt, med null tid for brukeren til faktisk å gå fra utslagsstedet
+    til ballen. Start- og sluttpunkt endte dermed på praktisk talt samme
+    sted, samme øyeblikk -- avstanden ble alltid ~0m, uavhengig av hvor
+    langt slaget faktisk var. Rettet ved å fjerne auto-avfyringen og
+    kreve et eksplisitt "Jeg er ved ballen nå"-trykk (samme mønster som
+    "Prøv igjen" ved feil, nå gjenbrukt for begge) -- brukeren går fysisk
+    til ballen FØR målingen skjer, i stedet for at appen antar de allerede
+    er der.
+
+    **Rotårsak 2 (stille tap, "ingen bilder"):** en konsekvens av
+    rotårsak 1 -- en 0m-avstand ble avvist av backendens
+    `distance_meters > 0`-validering (422), men `submitShot()` i
+    `round-detail.tsx` sin `ShotMeasurementEntry` gjorde da bare
+    `setOpen(false)` og returnerte -- INGEN feilmelding, arket lukket seg
+    stille som om alt var i orden. Brukeren fikk aldri vite at slaget
+    (og dermed en eventuell deling) aldri ble lagret. Rettet: `submitShot`
+    setter nå en `submitError`-state (parser backendens feilrespons,
+    som kan være enten appens vanlige `{detail:{message}}`-form ELLER
+    FastAPI/Pydantic sin rå valideringsform `{detail:[{msg,...}]}` --
+    bekreftet eksakt hvilken av de to ved å faktisk trigge en 422 mot
+    scratch-API-et: det er listeformen), viser feilen i arket
+    (`role="alert"`, ny `submitError`/`submitting`-prop på
+    `ShotMeasurementSheetProps`), og holder arket ÅPENT ved feil i stedet
+    for å anta suksess og lukke.
+
+    `tsc --noEmit` rent. **Scratch-verifisert i ekte nettleser** (nittende
+    scratch-miljø denne økten, samme migrasjon-002-forsiktighet,
+    `teecup_db` bekreftet uendret): CDP-automatiserte nettlesersesjoner
+    har `geolocation`-tillatelse permanent `denied` i dette miljøet (samme
+    begrensning som punkt 45-46), så `navigator.geolocation.
+    getCurrentPosition` ble midlertidig overstyrt via `evaluate_script`
+    for å drive den EKTE React-komponentens fulle flyt (ikke bare et
+    API-nivå-kall) -- bekreftet "Jeg er ved ballen nå"-knappen faktisk
+    vises i stedet for å auto-måle, at et ekte gap mellom start-/
+    sluttkoordinat ga "MÅLT LENGDE: 130 m" (ikke 0), at delingen faktisk
+    postet riktig tekst til `/rounds/{id}/messages`, OG (motsatt test,
+    identisk start-/sluttkoordinat) at en avvist 0m-innsending nå viser
+    feilmeldingen i arket i stedet for å lukke seg stille. Scratch-miljøet
+    ryddet opp fullstendig.