Dokumenter Augusta-stil resultattavle i CHANGELOG/FEATURE_BACKLOG

Fullfører dokumentasjonen for den nye slagspill-resultattavlen (POS/
PLAYER/TODAY/THRU/TOTAL/R1-Rn), rullet ut 2026-08-04: V0-integrering
(zip 29), Golfscore-språk-fiksen for rundekolonnenes eksakt-par-tilfelle,
og den reelle til-par-rangeringsbugen funnet og rettet under
scratch-verifisering.

Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
This commit is contained in:
Erol Haagenrud 2026-08-04 04:51:09 +02:00
parent 50653303f4
commit 828b508c53
2 changed files with 123 additions and 0 deletions

View file

@ -7120,3 +7120,90 @@ Neste steg:
053 mot ekte `teecup_db`, `docker compose up -d --build teecup_api 053 mot ekte `teecup_db`, `docker compose up -d --build teecup_api
teecup_frontend`, begge containere boot-et rent, `/health`/ teecup_frontend`, begge containere boot-et rent, `/health`/
`/dashboard` → 200. `/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å
`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.

View file

@ -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 ## Bevisst endret fra opprinnelige (Gemini-)råd
- 🔀 **Banedata:** API mot teeoff (ADR-004), IKKE direkte delt database. Direkte - 🔀 **Banedata:** API mot teeoff (ADR-004), IKKE direkte delt database. Direkte