teecup/FEATURE_BACKLOG.md

TeeCup — Funksjons-backlog

Formål: fange ALT som er ønsket for TeeCup på ett sted, slik at intet krav går tapt mellom økter, modeller eller samtaler. Kilder: de to opprinnelige Gemini-samtalene (funksjonalitet + Docker) og arbeidet gjort med Claude.

Status-koder: ✅ ferdig · 🔨 pågår · 📋 planlagt/fanget · ❓ trenger beslutning · 🔀 endret fra opprinnelig råd · 💤 utsatt (bevisst)

Sist oppdatert: 2026-07-16

---

Fundament (bygget)

Funksjon	Status	Notat
Handicap-/matchmotor (testet)	✅	24 tester, R&A-verifisert. Erstatter Geminis løse JS-funksjon.
Formater: singles, fourball, foursome, greensome, scramble	✅	I motoren, allowance som konfig.
Brutto/netto + prosent-allowance (75 %, 90 %, 3/4)	✅	ADR-005. Prosentene bekreftet mot Golf GameBook (ADR-014).
9-hulls (front/back) slagfordeling	✅	ADR-008, egen funksjon + test.
Miksede formater per turnering (økter)	✅	ADR-007. Ryder Cup-strukturen.
Spiller-pool m/ reserver, delvis deltakelse	✅	ADR-007.
Multi-tenant skjema + RLS	✅	ADR-001/003. Isolasjon bevist med oppførselstest.
Dedikert app-rolle (ingen superuser/BYPASSRLS)	✅	migrasjon 002.
API: oppsett (spillere/lag/roster/økter/matcher/blind draw)	✅	Verifisert for ekte mot scratch-db + engangscontainer. Scoring gjenstår.
Banedata fra teeoff via API	🔀	ADR-004. Endret fra Geminis «delt database direkte».
Konfigurerbar handicap-pipeline (4 brytere)	📋	ADR-014. Motoren støtter alle fire steg (course handicap / allowance / matchplay-hcp / helt av) som atskilte kall; API/skjema eksponerer dem ikke som brytere ennå. Bygges sammen med scoring-endepunktene.

---

Ønsket, men IKKE fanget før nå (fra Gemini-samtalene)

Brukerroller (utover org-medlemskap)

• Status: ❓ trenger beslutning
• De opprinnelige samtalene beskriver: turneringsadmin, lagkaptein, spiller, tilskuer (les-only, følger live uten skriverettigheter).
• Vi har i dag org-roller (owner/admin/member) + is_captain på roster.
• Mangler: «tilskuer» som begrep. Henger sammen med hvem som ser den offentlige feeden (se Kommunikasjon). Kaptein-rollen bør kanskje gi spesifikke rettigheter (sette oppstilling), ikke bare være et flagg.

Blind draw (skjult lagoppstilling)

• Status: 🔨 skjema bygget (migrasjon 003, lineup_lock) — app-logikk gjenstår
• Kapteinene låser oppstillingen skjult; matchene avsløres samtidig når begge er ferdige.
• Skjemakonsekvens: oppstillinger trenger en tilstand «utkast → låst → avslørt» før match_participant gjøres synlig. Egen lineup_submission-modell e.l. Ikke bygget.

Forenklet scoreføring (uten slagtall)

• Status: 🔨 skjema bygget (migrasjon 003) — begge moduser besluttet
• Ønske: kunne registrere ENTEN slag per hull ELLER bare «Lag rød vant hullet / delt».
• Skjemakonsekvens: dagens hole_score.gross_strokes er NOT NULL. En ren hull-resultat-modus krever enten at slag kan være NULL + et resultatfelt, eller en egen match_hole_result-tabell. Må avgjøres før scoring-API-et.

Bøtekasse (Kangaroo Court)

• Status: 📋 planlagt
• Meld inn overtramp med bøter («kastet kølla på hull 4»).
• Henger sammen med Kommunikasjon: bøter deles i feeden. Sannsynligvis en egen post-type i meldingsmodellen.

Flerårig statistikk / historikk / MVP

• Status: 📋 planlagt (datamodell støtter det allerede)
• Seiersprosent i singelmatcher, historisk MVP, statistikk over år.
• Datamodellen tillater dette fordi spillere lever på org-nivå og gjenbrukes på tvers av turneringer, og handicap fryses per turnering (reproduserbart).

Push-varsler

• Status: 📋 planlagt (infrastruktur)
• «BREAKING: X vant matchen». PWA push. Egen infrastruktur-bit.

Sanntid (WebSockets)

• Status: ❓ trenger beslutning
• Live leaderboard og chat som oppdateres uten refresh. Vi har leaderboard-viewet, men ikke sanntidsleveringen. Valg: WebSockets vs. polling.

Knockout / cup-turnering (egen turneringstype)

• Status: 💤 utsatt (egen fremtidig type, ADR-011)
• Utslagsmatcher: 128 spillere → finale + bronsefinale. Rundene er avhengige (vinner går videre), krever bracket/progresjon, seeding, fripass. IKKE i v1.
• v1 er låst til nøyaktig to lag (Ryder Cup-format). Match-modellen er generell, så denne typen kan legges til senere uten dataomskriving — den legger bare til et progresjons-lag.

---

Kommunikasjon (under design)

Del	Status	Notat
Lag-intern chat («det hemmelige rommet»)	🔨	Bekreftet ønsket. Kanal m/ scope team.
Offentlig runde-feed («Banter Board»)	❓	Synlighetsnivå ikke besluttet (deltakere/org/offentlig lenke).
Bilder i feed/chat	📋	v1. Objektlagring (MinIO), presigned opplasting.
Video	💤	Arkitekt for det, bygg senere (ADR-forslag).
1-til-1 direktemeldinger	💤	Gemini frarådet for v1; ikke etterspurt av deg.
Moderering (for offentlig innhold)	❓	Kreves hvis «alle med lenken». Mønster finnes i teeoff.

---

UX / frontend (senere fase)

• 📋 Høy kontrast, dark/light, store +/- knapper, stor «Neste hull»-knapp (banebruk i sollys/med solbriller).
• ✅ Offline-first (ADR-006) — prinsipp besluttet; implementasjon senere.
• 📋 PWA: manifest, service workers, «Legg til på hjemskjerm».

---

Bevisst endret fra opprinnelige (Gemini-)råd

• 🔀 Banedata: API mot teeoff (ADR-004), IKKE direkte delt database. Direkte DB-kobling ville låst TeeCup til teeoffs skjemaendringer.
• 🔀 Handicap-motor: egen testet Python-modul, ikke den innlimte JS-funksjonen (som bl.a. ikke håndterte 9-hull eller konfigurerbare allowances korrekt).
• 🔀 Tenant-modell: organisasjon som tenant med RLS, ikke bare «turnering-ID».
• 🔀 Sesjons-secret: egne secrets for TeeCup, ikke fallback til teeoffs (teeoff selv bruker en slik fallback — bevisst unngått her).