111 lines
5.1 KiB
Markdown
111 lines
5.1 KiB
Markdown
# 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-15
|
|
|
|
---
|
|
|
|
## 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. |
|
|
| 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-fundament m/ trygg org-kontekst | 🔨 | Skjelett klart; CRUD gjenstår. |
|
|
| Banedata fra teeoff via API | 🔀 | ADR-004. Endret fra Geminis «delt database direkte». |
|
|
|
|
---
|
|
|
|
## Ø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:** 📋 planlagt (i din egen utviklingsplan)
|
|
- 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:** ❓ trenger beslutning (påvirker skjema)
|
|
- Ø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.
|
|
|
|
---
|
|
|
|
## 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).
|