diff --git a/CHANGELOG.md b/CHANGELOG.md index 24103b7..3973f7f 100644 --- a/CHANGELOG.md +++ b/CHANGELOG.md @@ -7120,3 +7120,90 @@ Neste steg: 053 mot ekte `teecup_db`, `docker compose up -d --build teecup_api teecup_frontend`, begge containere boot-et rent, `/health`/ `/dashboard` → 200. +18. **Augusta-stil resultattavle for slagspill-turneringer (POS/PLAYER/ + TODAY/THRU/TOTAL/R1-Rn) — BYGGET, SCRATCH-VERIFISERT OG LIVE + 2026-08-04, ingen migrasjon.** Brukeren viste et bilde av en fysisk + leaderboard-tavle fra Augusta National og ba om samme kolonneoppsett + for individuelle turneringer med brutto/netto/stableford-scoring — + med lederen alltid øverst, valgfri automatisk rulling, og eksplisitt + krav om at det skal se bra ut på storskjerm (ikke bare mobil). Bygget + via V0 (zip 29, `stroke-play-leaderboard.tsx`) etter etablert mønster: + ren visuell komponent med mock-data først, ekte backend-kobling + etterpå. + **V0-prompten** (skrevet FØR eksporten) spesifiserte eksplisitt at + fargevalget (grønn=under par/oransje=over par) skal følge appens EGEN + etablerte konvensjon, IKKE referansebildets amerikanske rød-for- + under-par-tradisjon — V0 traff dette presist. Eksporten matchet + datakontrakten i prompten nesten ordrett (`RoundCell`/`LeaderboardRow` + -typene er identiske), inkludert korrekt implementert lederrad + fastspent i gull, av/på-knapp for automatisk rulling som respekterer + `prefers-reduced-motion`, frossen POS/PLAYER-kolonne på mobil, og en + egen, betydelig større "storskjerm"-skalering (`lg:`-brekkpunkt) -- + første skjerm i appen bygget eksplisitt for dette. **Én reell, + forventet justering gjort ved integrering** (prompten dekket ikke + dette presist nok selv): rundekolonnenes eksakt-par-tilfelle + ("E") fikk feilaktig samme kvadrat+oransje-behandling som over par -- + rettet til appens egen "E → ren tekst, ingen ramme"-regel + (DESIGN_SYSTEM.md) ved å utvide `RoundCell.isUnderPar: boolean|null` + til en eksplisitt `tone: "under"|"even"|"over"|null`, bekreftet + visuelt riktig i scratch (72 mot par 72 vises nå som ren tekst, ingen + ramme). + **Backend** (`individual_tournaments.py`): ingen skjemaendring -- + `individual_leaderboard`-endepunktet utvidet med nye, valgfrie felt + (`position`/`is_leader`/`today_label`/`thru_label`/`total_label`/ + `rounds[]`), KUN populert for scoring_method brutto/netto/stableford + (uendret `null`/tom liste for København/BBB, som fortsatt bruker den + enkle listevisningen). "I dag" (TODAY/THRU) utledes som runden med + høyest sekvensnummer som NOEN deltaker har påbegynt (bekreftet med + bruker: ingen eksplisitt "aktiv runde"-markering finnes eller trengs + -- runder spilles sekvensielt i praksis). Par-for-spilte-hull regnes + per (runde, deltaker) via en ny korrelert subquery mot + `tournament_round_hole`, gjenbruker de allerede cachede + `gross_total`/`net_total`/`stableford_points`-verdiene fra + `tournament_round_score` uendret. + **Reell rangeringsbug funnet OG rettet UNDER selve scratch- + verifiseringen** (ikke antatt riktig fra koden alene): den + EKSISTERENDE sorteringslogikken (uendret siden ADR-037) rangerte på + RÅ `gross_total`/`stableford_total` -- riktig for en enkelt-rundes + sammenligning, men i en flerrunde-turnering der deltakere har spilt + ULIKT antall hull til enhver tid, er rå sum ikke sammenlignbar (en + deltaker med kun 18 hull spilt fikk et lavere rått slagtall enn + deltakere med -5 til par over 27-36 hull, og rangerte dermed FORAN + dem som leder — funnet ved at test-scriptets egne håndregnede + assert-sjekker feilet). Rettet ved å innføre en til-par-normalisert + rangeringsnøkkel (`gross_total/net_total − par_for_spilte_hull`, + negert for stableford siden flere poeng er bedre der) brukt BÅDE til + sortering og uavgjort-deteksjon, i stedet for rå totaler. Ny + `entries.sort(...)`-plassering flyttet inn i denne funksjonen + (erstatter den gamle grenen kun for disse tre metodene — København/ + BBB/default-brutto beholder sin uendrede, allerede riktige rå-sum- + sortering, siden alle deltakere der alltid har likt antall + hull/runder tilgjengelig i de formatene). + **Frontend** (`individual-tournament-detail.tsx`): `LeaderboardTab` + grener nå på `scoring_method` -- `StrokePlayLeaderboard` (ny + komponent) for brutto/netto/stableford, uendret gammel flat/klasse- + gruppert liste for København/BBB/Flagg. Klasse-gruppering (2026-08-04 + tidligere samme dag) virker uendret -- komponenten instansieres én + gang per klasse-seksjon, akkurat som den gamle listen ble. + **Scratch-verifisert grundig** (isolert `teecup_app_scratch`-rolle + + engangs API-/frontend-container, ekte nettleser-innlogging inkl. + 2FA): en 4-spiller, 2-rundes turnering med et bevisst konstruert + scenario -- ekte uavgjort i toppen (to spillere -5 til par, ulikt + antall hull spilt hver), én spiller midt i runde 2 (thru 9), én + spiller som IKKE hadde startet runde 2 i det hele tatt, én ferdig + begge runder. ALLE håndregnede tall (POS med "T1"-uavgjort, TODAY, + THRU inkl. "F"/"-"/hull-tall, TOTAL, R1/R2 med riktig form+farge per + Golfscore-språket) bekreftet eksakt riktige, både via rå API-JSON og + i ekte nettleser på BÅDE 390px mobil (frossen POS/PLAYER, resten + skrollbar) og 1920px storskjerm (alt synlig uten skrolling, betydelig + større tekst). Rull-automatisk-knappen bekreftet å veksle av/på. + Regresjonstestet: en BBB-turnering bekreftet fortsatt å returnere + tomme/`null`-verdier for de nye feltene (gammel visning uendret, + ingen ny kode-vei berørt for de formatene). 98/98 eksisterende + `handicap_engine.py`-enhetstester uendret (ingen motorendring), ekte + typesjekket produksjonsbuild. + **Rullet ut live 2026-08-04**, bruker bekreftet eksplisitt: INGEN + migrasjon (rene response-felt-tillegg), `docker compose up -d --build + teecup_api teecup_frontend`, begge containere boot-et rent, + `/health`/`/dashboard` → 200. V0-zip-en slettet etter merge, per + etablert rutine. diff --git a/FEATURE_BACKLOG.md b/FEATURE_BACKLOG.md index f58a958..4489d42 100644 --- a/FEATURE_BACKLOG.md +++ b/FEATURE_BACKLOG.md @@ -4014,6 +4014,42 @@ teecup_frontend`. Full detalj i CHANGELOG.md 2026-08-04 og ADR-041. --- +## Augusta-stil resultattavle for slagspill-turneringer — ✅ HELT FERDIG, BYGGET, SCRATCH-/BROWSERVERIFISERT OG LIVE 2026-08-04 + +Brukeren viste et bilde av en fysisk leaderboard-tavle fra Augusta +National (POS/PLAYER/TODAY/THRU/TOTAL/R1-R4) og ba om samme oppsett for +individuelle turneringer med brutto/netto/stableford-scoring — lederen +alltid øverst, valgfri automatisk rulling, må se bra ut på storskjerm +(ikke bare mobil). Bygget via V0 (zip 29) etter etablert mønster: ren +visuell komponent med mock-data først (`stroke-play-leaderboard.tsx`), +ekte backend-kobling etterpå. Ny `Tone`-tredeling ("under"/"even"/"over") +rettet inn i komponenten ved integrering — V0s eksport hadde ikke fått +med seg appens egen "E → ren tekst, ingen ramme"-regel for rundekolonnene +presist nok (kun for TODAY/TOTAL, ikke R1-Rn). + +Backend (`individual_tournaments.py`, `individual_leaderboard`- +endepunktet) utvidet med POS/TODAY/THRU/TOTAL/runde-for-runde-data — kun +populert for brutto/netto/stableford, ingen endring for København/BBB. +"I dag" utledes som runden med høyest sekvensnummer noen har påbegynt +(ingen eksplisitt aktiv-runde-markering finnes eller trengs). + +**Reell rangeringsbug funnet og rettet under scratch-verifiseringen** +(ikke antatt riktig fra koden alene): den eksisterende sorteringen +rangerte på RÅ slagtotal/poengtotal — riktig for én runde, men i en +flerrunde-turnering med deltakere på ulike stadier (noen midt i runde 2, +andre ikke startet den) er rå sum ikke sammenlignbar. En deltaker med +færre spilte hull kunne rangere FORAN den faktiske lederen kun fordi det +rå tallet var lavere. Rettet ved å innføre en til-par-normalisert +rangeringsnøkkel brukt til BÅDE sortering og uavgjort-håndtering. + +Ingen migrasjon (rene response-felt-tillegg). Scratch-verifisert grundig +med et bevisst konstruert flerrunde-scenario (ekte uavgjort i toppen, én +spiller midt i runde, én ikke startet runde 2) — alle håndregnede tall +bekreftet eksakt riktige, både API-JSON og ekte nettleser på 390px mobil +og 1920px storskjerm. Full detalj i CHANGELOG.md 2026-08-04. + +--- + ## Bevisst endret fra opprinnelige (Gemini-)råd - 🔀 **Banedata:** API mot teeoff (ADR-004), IKKE direkte delt database. Direkte