diff --git a/FEATURE_BACKLOG.md b/FEATURE_BACKLOG.md index c67fea5..824e30c 100644 --- a/FEATURE_BACKLOG.md +++ b/FEATURE_BACKLOG.md @@ -1771,25 +1771,23 @@ er en annen streng, ikke rørt. Ekte typesjekket produksjonsbuild kompilerte rent. Rullet ut (kun `teecup_frontend`), ingen migrasjon, `teeoff.no` upåvirket. -## Notat 2026-07-30: per-hull historikk/statistikk for spilleren — 📋 NOTERT, IKKE bygget +## Notat 2026-07-30: per-hull historikk/statistikk for spilleren — ✅ HELT FERDIG, BYGGET OG LIVE (ADR-072 2026-08-15, relokert + full historikk med grafer ADR-079 2026-08-16) Reist av brukeren: spilleren bør kunne se all historikk/statistikk for NØYAKTIG det hullet vedkommende skal spille (eller har spilt) — f.eks. "du har i snitt brukt X slag/Y putter på hull 7 på denne banen, GIR Z% av gangene" — ikke bare hva som skjedde DENNE runden. -**Ikke trivielt, verdt å notere hvorfor:** dagens data er scoped PER -RUNDE (`round_hole`), ingen eksisterende spørring aggregerer "alle mine -tidligere runder på DENNE banen, filtrert til DETTE hullnummeret". Banen -identifiseres i dag kun ved navn-snapshot (`round.course_name_snapshot`, -se `PlayedCourses`/`course-rounds.tsx` sin eksisterende gruppering på -akkurat dette navnet) — samme identifikator kan trolig gjenbrukes til en -ny spørring: `GET /rounds/holes/{course_name}/{hole_number}/history` (eller -tilsvarende), som slår sammen `round_hole`-rader på tvers av alle -fullførte runder brukeren eier/har spilt på den banen. Naturlig plassering -i UI-et: en liten utvidbar seksjon i `ScoringWizard` sitt "strokes"-steg -(`round-detail.tsx`), og/eller i `round-scorecard.tsx`/`round-stats.tsx` -sine hull-visninger. Ingen design/ADR skrevet ennå — kun fanget opp her. +**RETTELSE 2026-08-16 — "📋 NOTERT, IKKE bygget" var stale.** Bygget som +ADR-072 (2026-08-15): `app/hole_history.py`, ny `GET .../holes/{n}/ +history`, aggregerer PÅ TVERS AV BÅDE frittstående runder OG +org-turneringer (bredere enn notatets opprinnelige "kun frittstående +runder"-forslag), banebro via `teeoff_facility_slug`/`teeoff_course_id` +(ikke navn-snapshotet notatet foreslo). Siden utvidet videre 2026-08-16 +(ADR-079): historikken flyttet UT av selve slagvinduet/-registrerings- +skjermen til skjermen før, og et klikk åpner nå FULL historikk med en +score-fordelingsgraf (samme stolpe-mønster som `round-stats.tsx`), ikke +bare en kort oppsummering. ## Notat 2026-07-30: lenke til rundestatistikk fra scorekortet, og hvorvidt scorekort/statistikk/live-registrering bør slås sammen til én visning — lenke + prikker ✅ BYGGET, BROWSERVERIFISERT OG LIVE; sammenslåing bevisst UTSATT til brukertesting @@ -4349,7 +4347,7 @@ denne veien er plattform-offentlig). --- -## Order of Merit (sesong-sammenlagt rangering) — ✅ SPILLER-OOM BYGGET, SCRATCH-/BROWSERVERIFISERT OG LIVE 2026-08-04 (ADR-043, migrasjon 055). Eclectic + lag-OOM 📋 GJENSTÅR +## Order of Merit (sesong-sammenlagt rangering) — ✅ HELT FERDIG, ALLE TRE DELER BYGGET OG LIVE (spiller-OOM 2026-08-04 ADR-043/migrasjon 055; lag-OOM + eclectic på tvers av turneringer + offentlig visning 2026-08-15/16, ADR-074/075/076) Brukeren ba om en vurdering av GolfBox sin Order of Merit-funksjon og tok den til en full designrunde. Bygget denne runden: skjema (fire nye @@ -4363,31 +4361,22 @@ for de fem arkitektoniske beslutningene og CHANGELOG.md 2026-08-04 for full bygge-/verifiseringsdetalj (63/63 håndregnede API-sjekker + RLS- isolasjon + ekte nettleser-gjennomgang). -**Gjenstår fra opprinnelig plan (bevisst utsatt, ikke glemt):** -- **Eclectic-aggregering PÅ TVERS AV LENKEDE TURNERINGER (OOM-nivå)** - ("drømmerunde" -- beste resultat PER HULL på tvers av ALLE lenkede - turneringer en spiller deltok i gjennom sesongen, kun for - resultattype Stableford/brutto/netto). **IKKE det samme som** det - Eclectic-formatet som ble bygget 2026-08-14 (ADR-068, migrasjon - 072) -- det er scoping til RUNDENE INNENFOR ÉN ENKELT turnering - (`tournament.scoring_method = eclectic_*`), ikke på tvers av flere - turneringer i en OOM-sesong. Motoren (`eclectic_best_per_hole()` i - handicap_engine.py) er generell nok til trolig å kunne GJENBRUKES - direkte for OOM-varianten også -- selve per-hull-datainnsamlingen på - tvers av turneringer (ikke bare runder) er fortsatt ubygget og - krever egen design-/verifiseringsrunde. -- **Lag-OOM sin faktiske leaderboard-beregning.** Skjema - (`order_of_merit_team`/`_team_member`) og prinsippet (sesong-par satt - opp DIREKTE i OOM-en, summerer/velger-beste-N-av medlemmenes allerede - beregnede individuelle OOM-resultater -- IKKE strengmatching på - turnering-lag, se ADR-043 Beslutning C) er avklart og bygget inn i - skjemaet, men selve `GET .../leaderboard`-grenen for `kind='team'` - finnes ikke ennå (avviser eksplisitt med en tydelig feilmelding). - Trenger CRUD-endepunkter for lag/medlemmer (ingen finnes ennå) pluss - selve aggregering-oppå-aggregering-logikken. -- **Offentlig/delt visning.** `public_visible`-feltet finnes og er - redigerbart i innstillinger, men ingen egen, ikke-innlogget-tilgjengelig - visning er bygget (kun den vanlige org-scopede detaljsiden). +**RETTELSE 2026-08-16 — "Eclectic + lag-OOM 📋 GJENSTÅR" var stale.** Alle +tre punktene under ble tatt i én samlet runde 2026-08-15/16: +- **Eclectic-aggregering PÅ TVERS AV LENKEDE TURNERINGER (OOM-nivå)** -- + ✅ BYGGET (ADR-075). `eclectic_best_per_hole()` fra `handicap_engine.py` + gjenbrukt UENDRET, som antatt her -- kun datainnsamlingen på tvers av + turneringer var ny. Samme-bane-håndheving lagt til (avviser lenking/ + modus-bytte som ville gjort eclectic meningsløst på tvers av ulike + baner). +- **Lag-OOM sin faktiske leaderboard-beregning** -- ✅ BYGGET (ADR-074). + Full CRUD for lag/medlemmer + `GET .../leaderboard`-grenen for + `kind='team'`, nøyaktig prinsippet som var avklart (ETT lagret + aggregeringsvalg styrer begge nivåer, ingen egen lag-konfig). +- **Offentlig/delt visning** -- ✅ BYGGET (ADR-076, migrasjon 076). Ny + SECURITY DEFINER-bro + `/public/order-of-merits/{id}`-endepunkt + ny + uautentisert side, samme anti-enumereringsmønster som resten av appens + offentlige sider. ---