CLAUDE.md: turneringsoppsett skal designes stor skjerm først
Organisatoren sitter som regel foran en PC ved oppsett (lag/tropper/ spillerimport/runder/klasser), ikke på mobil på banen -- gjelder kun oppsett-/administrasjonsskjermer, ikke spillerens skjermer under selve rundens gang (scorekort/rangefinder/leaderboard), som forblir mobil- først. Samme STÅENDE ufravikelig-mønster som tilgjengelighets- og navneformat-reglene over. Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
This commit is contained in:
parent
00809d6817
commit
d83bfef7c4
1 changed files with 29 additions and 0 deletions
29
CLAUDE.md
29
CLAUDE.md
|
|
@ -108,6 +108,35 @@ Les dette først i hver økt. Det koder hva vi har bestemt og hvordan vi jobber.
|
||||||
`first_name` separat, ingen backend-endring nødvendig). Se
|
`first_name` separat, ingen backend-endring nødvendig). Se
|
||||||
CHANGELOG.md for full detalj.
|
CHANGELOG.md for full detalj.
|
||||||
|
|
||||||
|
## Turneringsoppsett — stor skjerm først (ufravikelig, gjelder ALT, eksisterende og fremtidig)
|
||||||
|
- Brukeren instruerte eksplisitt 2026-08-17: turneringsOPPSETT (opprette
|
||||||
|
turnering, sette opp lag/tropper, importere/administrere spillere,
|
||||||
|
runder, klasser, baneoppsett, alt organisator-arbeid FØR/RUNDT selve
|
||||||
|
spillingen) skal designes "stor skjerm først", IKKE "mobil først" —
|
||||||
|
organisatoren sitter som regel foran en PC når dette gjøres, ikke på
|
||||||
|
mobil på banen. Dette er en STÅENDE forventning til alt fremtidig
|
||||||
|
UI-arbeid på denne typen skjermer, ikke en engangsting.
|
||||||
|
- Gjelder KUN oppsett-/administrasjonsskjermer. Skjermer SPILLEREN bruker
|
||||||
|
UNDER selve rundens gang (scorekort/slag-registrering/rangefinder/
|
||||||
|
leaderboard-under-spilling) forblir mobil-først som før — de brukes på
|
||||||
|
banen, på mobil, ikke ved en PC. Grensen følger hvem som sitter hvor,
|
||||||
|
ikke en fast liste — vurder per skjerm hvem som faktisk bruker den og
|
||||||
|
fra hvilken enhet.
|
||||||
|
- Praktisk konsekvens: layout/typografi/tett-vs-luftig-avstand
|
||||||
|
optimaliseres for et bredt skjermbilde som førstevalg (f.eks. tabeller
|
||||||
|
med flere synlige kolonner samtidig i stedet for kortstabler, sidepanel-
|
||||||
|
layout i stedet for full-bredde-modaler, hover-tilstander som en reell
|
||||||
|
interaksjon), men skal FORTSATT fungere og være betjenbart på smal
|
||||||
|
skjerm (samme STÅENDE tilgjengelighetsregel over gjelder uansett
|
||||||
|
skjermbredde) — "stor skjerm først" er en prioritering av hvilket
|
||||||
|
format som designes FOR primært, ikke en unnskyldning for å la mobil
|
||||||
|
forfalle.
|
||||||
|
- Gjelder begge retninger: (a) ta dette eksplisitt med som krav når en ny
|
||||||
|
V0-prompt skrives for et oppsett-/administrasjonsskjermer, og (b) rett
|
||||||
|
opportunistisk opp eksisterende oppsett-skjermer når de likevel røres i
|
||||||
|
en annen runde — ingen egen stor retrofit-runde er igangsatt eller bedt
|
||||||
|
om ennå.
|
||||||
|
|
||||||
## Arbeidsmåte
|
## Arbeidsmåte
|
||||||
- Inkrementelt. Ingenting tas for gitt før det er testet. Bekreft hvert steg før
|
- Inkrementelt. Ingenting tas for gitt før det er testet. Bekreft hvert steg før
|
||||||
du går videre.
|
du går videre.
|
||||||
|
|
|
||||||
Loading…
Reference in a new issue