teecup/CLAUDE.md

# CLAUDE.md — arbeidsinstruks for TeeCup

Les dette først i hver økt. Det koder hva vi har bestemt og hvordan vi jobber.

## Autoritative kilder (les før du gjør noe)
- `ARCHITECTURE_DECISIONS.md` — hva som er bestemt og hvorfor (ADR-001…029). Fasit.
- `FEATURE_BACKLOG.md` — hva som gjenstår, hva som er utsatt, hva som mangler.
- Endres en beslutning: legg til en ny ADR, ikke slett historikk. Hold begge
  filene oppdatert når noe avgjøres.
- **Regelverk for HCP/slagfordeling — tre PDF-er lastet opp av brukeren til
  prosjektroten 2026-07-19** (ikke innsjekket i git, kun lokale filer på
  serveren): `spilletyper-og-spilleformer-2023.pdf`,
  `Live Tourney _ A Guide to Handicap Scoring in Golf for Tournaments.pdf`,
  `SCGA Club Digest.pdf`. Brukeren: disse tre gir til sammen en tydelig
  beskrivelse av hvordan HCP og mottatte/tildelte slag skal beregnes/
  fordeles. Les disse FØR videre arbeid med `handicap_engine.py`,
  `app/handicap.py`, allowance-strategier (ADR-005/014) eller
  slagfordeling (ADR-008) — spesielt relevant for de fire
  turneringsformatene som ennå ikke er designet (Københavner/High-low-high/
  Robbins/Try all, se FEATURE_BACKLOG.md), siden disse dokumentene trolig
  dekker akkurat de reglene som trengs der.
- **Design-dokumentasjon, to filer med bevisst motsatt retning (2026-07-27):**
  `DESIGN_SYSTEM.md` (innsjekket i git) er DESKRIPTIV — hva som faktisk ER i
  koden i dag (farger/typografi/komponentmønstre/golfscore-språket), avledet
  direkte fra `globals.css`/`components/ui/*`. `teecup-scorekort-og-entry-
  spec.md` (lastet opp av brukeren til prosjektroten, IKKE innsjekket i git)
  er PRESKRIPTIV — hva scorekort-/score-entry-skjermene BØR bli, basert på en
  sammenligning mot fem etablerte golf-apper. Der de to avviker vinner
  kildekoden (DESIGN_SYSTEM.md beskriver den), men spec-dokumentets §3
  "Compliance-pass" er en konkret sjekkliste over kjente avvik — les den FØR
  videre visuelt arbeid på scorekort-/score-entry-skjermene.

## Sikkerhetsregler (ufravikelige)
- Rør ALDRI `teeoff`-databasen eller den ekte `teecup_db` uten at brukeren
  eksplisitt har bekreftet det i samme økt. Test alltid migrasjoner mot en egen
  scratch-database først, og rydd opp etterpå.
- Vis planen (hvilke kommandoer, mot hvilken database) FØR du kjører noe som
  skriver, migrerer eller sletter. Vent på bekreftelse.
- Hemmeligheter (passord, secrets) bor i `.env` (filrettigheter 600), dekkes av
  `.gitignore`, committes aldri, og skrives aldri i klartekst i chatten eller i
  SQL-filer. Generer dem på serveren (`openssl rand -base64 32`).
- Kjør appen som databaserollen `teecup_app` (NOSUPERUSER, NOBYPASSRLS) — aldri
  som `teeoff_admin`/superuser i runtime.

## Arkitektur-invarianter (ikke bryt uten en ny ADR)
- Tenant = organisasjon. `organization_id` på alle domenetabeller, håndhevet av
  RLS. App-koden setter `app.current_org` med `SET LOCAL` per transaksjon.
- Verifiser at brukeren er medlem av organisasjonen FØR org-konteksten settes.
  RLS stoler blindt på `app.current_org`.
- Egen innlogging (uavhengig av teeoff). Banedata hentes fra teeoff via lesende
  API, ikke delt database.
- v1 = nøyaktig to lag (Ryder Cup-format), håndhevet i app-laget. Match-modellen
  holdes generell (to sider) så knockout/flere lag kan komme senere.
- Handicap-/matchlogikk skal ligge i `handicap_engine.py` (rent, testet, uten
  db/API-avhengigheter). Allowances er konfig, ikke hardkodet.
- Media (bilder/video) skal i objektlagring (MinIO), ikke i Postgres. Postgres
  holder bare metadata + nøkkel.

## Tilgjengelighet — frontend (ufravikelig, gjelder ALT, eksisterende og fremtidig)
- Brukeren instruerte eksplisitt 2026-07-22: ALL frontend — det som
  allerede finnes OG alt som designes med V0 fremover — skal være
  lesbart, forståelig og betjenbart for noen med noe redusert syn UTEN
  briller, så langt det praktisk lar seg gjøre. Dette er en STÅENDE
  forventning til alt fremtidig UI-arbeid, ikke en engangsting for én
  skjerm.
- Praktisk konsekvens: god kontrast, stor nok skrift, store nok
  trykkflater, ikke ikon-only uten tekst-label for viktige handlinger,
  ikke avhengig av finmotorikk/skarpt syn for å bruke appen.
- Gjelder begge retninger: (a) ta dette eksplisitt med som krav når en ny
  V0-prompt skrives eller en V0-eksport gjennomgås, og (b) rett
  opportunistisk opp eksisterende skjermer når de likevel røres i en
  annen runde — ingen egen stor retrofit-runde er igangsatt eller bedt
  om ennå.

## Navneformat (ufravikelig, gjelder ALT, eksisterende og fremtidig)
- Brukeren instruerte eksplisitt 2026-07-26: når TeeCup kommuniserer
  DIREKTE TIL brukeren (adresserer dem, "snakker til" dem) — f.eks. en
  dashbord-hilsen ("God morgen Erol") eller en e-post/varsel rettet til
  mottakeren selv — skal KUN FORNAVN brukes, aldri fullt navn.
- Til vanlig (lister, roster, chat-forfatter, "fjern X"-bekreftelser,
  administrasjonsvisninger, alt som IKKE er direkte adressering) brukes
  fortsatt fullt navn, eller initial(er)+etternavn, eller annet som er
  nødvendig for å skille personer fra hverandre — ikke fornavn alene der.
- Samme STÅENDE forventning som tilgjengelighetsregelen over: gjelder
  fremtidig arbeid direkte, og rettes opportunistisk når en skjerm
  likevel røres — ingen egen retrofit-runde igangsatt.
- **✅ FIKSET 2026-07-26** (samme dag, i "fiks alle kjente små bugs"-
  runden): dashbordets hilsen brukte fullt navn — rettet til
  `me.first_name ?? me.display_name` (`/auth/me` eksponerte allerede
  `first_name` separat, ingen backend-endring nødvendig). Se
  CLAUDE.md-status lenger ned for full detalj.

## Arbeidsmåte
- Inkrementelt. Ingenting tas for gitt før det er testet. Bekreft hvert steg før
  du går videre.
- Bruk git (remote: brukerens Forgejo). Commit i logiske steg med tydelige
  meldinger.
- Er du usikker på omfang eller en beslutning: spør heller enn å gjette.

## Status (oppdater denne når ting endres)
Ferdig og verifisert:
- Handicap-motor + tester (24/24, R&A-verifisert).
- Skjema `001` + roller `002` + scoring/blind draw `003`. Isolasjon bevist med
  `test_isolation.sql` (RLS-oppførsel, ikke bare at skjemaet kjører).
- 002 hadde en reell bug (psql interpolerer ikke `:'var'` inne i `DO $$...$$`)
  — permanent fikset, verifisert mot scratch to ganger.
- API-et kjørt for ekte (ikke bare syntaks-sjekket) i en engangs Docker-
  container mot en scratch-database, RLS bevist gjennom hele
  asyncpg-pool-stacken (ikke bare i rå SQL).
- Oppsett-endepunktene er bygget og verifisert: `app/routers/players.py`
  (spillerpool), `tournaments.py` (turnering/lag/roster/økter, ADR-011
  to-lags-grense håndhevet med `FOR UPDATE`-lås), `matches.py` (matcher/
  deltakere/blind draw-lås, ADR-013-synlighet push-down i SQL). Delt
  feiloversettelse i `app/errors.py`, delte synlighetsspørringer i
  `app/blind_draw.py`. `main.py` er nå bare app-factory + `include_router`.
- Scoring-runden er bygget og verifisert for ekte mot scratch-db (18-hulls
  bane med `tee_rating`, 4 spillere for fourball-testing): `app/handicap.py`
  (ADR-014 fire brytere via `parse_allowance_config`, handicap beregnes i
  `compute_and_store_side_handicaps` rett etter deltaker-innsetting —
  singles/fourball per spiller umiddelbart, foursome/greensome/scramble kun
  når siden er komplett), `app/routers/scoring.py` (`hole-scores`/
  `hole-results`-upsert, `scorecard`-GET, matchstatus-recompute med
  `FOR UPDATE`-lås mot race og SAMMENHENGENDE-prefiks-regel for uferdige
  hull). `app/team_authz.py` skilt ut fra `matches.py` (delt med
  `scoring.py`). Alle 10 planlagte tester bestått, inkl. fourball
  better-ball-aggregering (MIN av to nettoer, venter til begge partnere har
  registrert), poeng-caching ved tidlig avgjort match, og ADR-014-bryteren
  `use_handicap=false`.
  **Fant og fikset underveis:** `tournaments.py` sin `SessionCreate` manglet
  `scoring_mode` helt (økter kunne aldri opprettes i `hole_result`-modus via
  API-et) — lagt til.
  **Bevisst utelatt/kjente begrensninger:** en side som aldri når forventet
  deltakerantall (no-show) får aldri beregnet handicap og matchen kan da
  aldri avgjøres — ingen manuell overstyring bygget. Score-skriving er
  upsert (ingen avvisning ved duplikat) — ingen audit-trail på rettelser.
  Kapteins-only autorisasjon fortsatt ikke bygget (FEATURE_BACKLOG ❓); bar
  er «rostret på laget».
- **Match-lås ved avgjørelse (2026-07-16):** `submit_hole_score`/
  `submit_hole_result` avviser nå 409 hvis `match.points_side_a IS NOT NULL`
  (matchen er avgjort) — FØR upserten kjøres, både for nye hull og
  korrigering av allerede talte hull. Tetter en reell bug: uten dette kunne
  «spøkelses-hull» lagt inn etter avgjørelse endre en allerede cachet margin
  ved neste omregning. Automatisk, ingen ny autorisasjon involvert.
- **Ekte autentisering bygget og verifisert (2026-07-16):** `X-Debug-User-Id`-
  stubben er HELT fjernet (ingen fallback). Magic-link + JWT-sesjon i
  `app/routers/auth.py` + `app/auth.py` (`request-link`/`verify-link`/
  `logout`/`me`), ny migrasjon `004_auth.sql` (`magic_link_token`-tabell +
  unik e-post-indeks på `app_user`). Token = `secrets.token_urlsafe(32)`, kun
  SHA-256-hash lagres, atomisk forbruk (`UPDATE ... RETURNING`, ikke
  les-sjekk-skriv), generisk respons uansett om e-posten finnes (unngår
  enumerering), gamle uforbrukte lenker ugyldiggjøres når en ny utstedes,
  `app_user` opprettes FØRST ved vellykket verifisering (ikke ved
  forespørsel). Sesjons-JWT (PyJWT, `algorithms=["HS256"]` eksplisitt) i
  HttpOnly/SameSite=Lax/dynamisk-Secure-cookie, 30 dager, med et ekte
  eksistens-oppslag mot `app_user` på hver forespørsel (faktisk
  tilbakekalling — en slettet bruker kan ikke ri ut sesjonen). Alle 12
  planlagte tester bestått.
  **Fant og fikset underveis:** `ON CONFLICT (email)` matchet ikke den nye
  PARTIELLE unike indeksen uten eksplisitt `WHERE email IS NOT NULL` (samme
  klasse feil som `hole_score`s partielle indekser i scoring-runden).
  **Fant, IKKE fikset i denne runden (egen runde rett etterpå — se under):**
  `organization`-tabellens RLS-policy kastet en 500 i stedet for skjemaets
  lovede "trygg standard: se ingenting" ved tomstreng-GUC.
- **RLS-tomstreng-bug FIKSET (2026-07-16):** ny migrasjon
  `005_rls_null_guard.sql` — delt `STABLE` SQL-funksjon `app_current_org()`
  gjør `NULLIF(current_setting('app.current_org', true), '')::uuid` i stedet
  for det rå uttrykket, brukt av alle 15 RLS-policyer (`ALTER POLICY`,
  14 `org_isolation` + `org_self`). Verifisert med 3 nye regresjonstester i
  `test_isolation.sql` (Test 10-12) OG ved faktisk å gjenskape original-
  buggen mot en ekte container (pool-størrelse 1, varm opp med
  `org_connection()`, deretter `/auth/me` på samme gjenbrukte tilkobling —
  gikk fra 500 til 200).
  **Viktig presisering fra denne runden:** fiksen gjør IKKE at `/auth/me` kan
  joine `organization` direkte via `plain_connection()` — det var en feilaktig
  antakelse i forrige runde. `org_self` krever fortsatt en MATCHENDE
  `app.current_org` for å vise en rad (riktig RLS-design, ikke noe fiksen
  skulle endre), og en bruker kan tilhøre flere organisasjoner samtidig, så
  det finnes ingen ÉN kontekst å sette for en tverr-org-spørring. `/auth/me`
  slår derfor opp hvert org-navn ett om gangen via `org_connection()` (N+1,
  N = antall org-er brukeren tilhører) — dette er riktig løsning, ikke en
  omvei.
- **Organisasjon-bootstrap bygget og verifisert (2026-07-16):** nytt
  `POST /orgs` (`app/routers/organizations.py`) — det ENESTE stedet i API-et
  som setter inn en `organization`-rad. Fant under statusgjennomgang at dette
  manglet helt (alle tidligere org-er var seedet med superbruker-SQL). Ingen
  ny migrasjon. Selvrefererende RLS-bootstrap bekreftet å fungere: generer
  org-ens uuid i Python, sett `app.current_org` til nøyaktig den via
  eksisterende `org_connection()`, sett inn `organization`-raden med samme
  id — `org_self`s implisitte `WITH CHECK` blir da trivielt sann, ingen
  privilegert tilkobling nødvendig (i motsetning til hva 002s kommentar
  antydet). Verifisert med 5 tester inkl. en negativ kontroll (mismatchende
  id avvist med `insufficient_privilege`) og full kryss-org-isolasjon mellom
  to uavhengig opprettede organisasjoner.
- **Ekte SMTP-utsending bygget og verifisert (2026-07-16):** ny `app/email.py`
  (`send_magic_link_email`, `smtplib` via `asyncio.to_thread`, håndterer
  både implisitt TLS/port 465 og STARTTLS dynamisk). Brukeren la egne
  SMTP-credentials i `.env` (`TEECUP_SMTP_*`, `TEECUP_FROM_EMAIL` — ADR-009,
  ikke delt med teeoff); jeg leste kun nøkkelnavnene for å bekrefte de
  fantes, aldri verdiene. `app/config.py` sin `SMTP_CONFIGURED` er valgfri
  (ikke `_required`) — dev-only logging (`TEECUP_DEV_LOG_MAGIC_LINKS`)
  fortsatt fungerer uendret når SMTP ikke er satt opp. Driftsfeil i
  utsendingen lekker aldri til klientresponsen (bevarer anti-enumerering).
  **Verifisert med faktisk levering:** sendte én ekte test-e-post til en
  adresse brukeren oppga — brukeren bekreftet mottak. Første gang noe i
  prosjektet er bevist ved ekte levering, ikke bare curl/scratch.
- **Containerisert og LIVE på `teecup.teeoff.no` (2026-07-16):** ekte
  `teecup_db` opprettet (migrasjoner 001→005 kjørt permanent, `test_isolation.sql`
  består), `Dockerfile` + `docker-compose.yml` (tjeneste `teecup_api`, joiner
  det eksisterende `teeoff_default`-nettverket), Caddy-blokk lagt til i
  `/opt/teeoff/deploy/Caddyfile`. Ekte innlogging (magic-link → e-post →
  JWT-sesjon med `Secure`-cookie) verifisert ende-til-ende mot den live
  stacken. `teeoff.no` upåvirket gjennom hele prosessen.
  **To reelle hendelser underveis, begge løst:**
  1. **Caddy plukket ikke opp filendringen** — `teeoff_caddy` sin
     `Caddyfile`-mount er en ENKELTFIL-bind-mount, låst til inoden som fantes
     da containeren sist startet. Min fil-redigering (atomisk rename) laget
     en ny inode på samme sti, så containeren fortsatte å lese den GAMLE
     filen uansett hvor mange ganger `caddy validate`/`caddy reload`/admin-API
     `/load` ble kjørt (alle validerte/lastet den uendrede gamle filen, derav
     ingen feilmelding). Løst med en full `docker restart teeoff_caddy`
     (brukeren bekreftet — avvek fra planens "kun graceful reload, ingen
     omstart"-løfte, noen sekunders nedetid for `teeoff.no`).
  2. **Alvorlig nettverksalias-kollisjon** (funnet RETT ETTER omstarten, da
     ekte teeoff-trafikk som `/api/facilities?...` med ekte klubb-slugs dukket
     opp i `teecup_api` sin logg): `docker-compose.yml` sin service-nøkkel var
     `api:` — SAMME nøkkel som teeoffs eget `api`-servicenavn
     (`docker-compose.prod.yml`). Docker Compose registrerer nettverksalias
     basert på service-NAVNET (ikke bare `container_name`) på delte nettverk,
     så BEGGE containerne fikk alias `api` på `teeoff_default` — Caddys
     `reverse_proxy api:8000` i teeoff sin egen config kunne da tilfeldig
     treffe enten ekte `teeoff_api` eller `teecup_api`. **Rettet umiddelbart**
     (stoppet `teecup_api` først for å hindre videre feilruting av ekte
     teeoff-trafikk, ga service-nøkkelen navnet `teecup_api` i stedet,
     gjenopprettet — bekreftet med `docker network inspect` at alias `api` nå
     KUN peker på ekte `teeoff_api`).
  **Mindre driftslærdom:** (a) jeg eksponerte ved et uhell
  `TEECUP_SMTP_PASS`/`TEECUP_FROM_EMAIL` i eget debug-output mens jeg
  feilsøkte en `.env`-korrupsjon (manglende linjeskift fra min egen
  `>>`-tilføyelse) — brukeren roterte passordet som forsiktighetsregel; (b)
  Docker leser IKKE `.env` på nytt for en allerede kjørende container —
  `docker compose up -d --force-recreate` kreves etter enhver `.env`-endring
  som skal tas i bruk; (c) et `#`-tegn i et upassordet `.env`-passord kuttes
  som en kommentar av Compose sin parser — anførselstegn (fortrinnsvis enkle)
  løser dette.
- **Dato/klokkeslett + feilkode-kontrakt + i18n-forberedelse (2026-07-17,
  ADR-015):** reist av brukeren rett før frontend-arbeidet. Ny migrasjon
  `006_scheduling_and_locale.sql` (alt additivt): `tournament.end_date`,
  `session.scheduled_at`/`tee_interval_minutes`/`start_hole`,
  `match.tee_time_override`, `app_user.preferred_locale`,
  `magic_link_token.locale`. `match.tee_time` er UTLEDET i Python
  (`scheduled_at + (sequence-1)*tee_interval_minutes`, override vinner hvis
  satt) — aldri lagret per match. Full retrofit av ALLE 39 daværende
  `HTTPException(..., detail="norsk streng")`-steder på tvers av 6 filer til
  en delt `app_error(status_code, code, message)`-factory
  (`app/errors.py`) — responsformen er nå konsekvent
  `{"detail":{"code":...,"message":...}}` i hele API-et, verifisert med et
  siste `grep -rn 'detail="' app/` som ga NULL treff. i18n: `locale`
  (`nb`/`en`) sendes av klienten ved `request-link`, styrer e-postmalen
  (ekte engelsk mal lagt inn i `app/email.py`, ikke bare rørlegging) OG
  settes som en HELT NY brukers `preferred_locale` — en eksisterende bruker
  som logger inn på et annet språk får IKKE sin lagrede preferanse
  overskrevet.
  **Fant og fikset underveis:** `tournament.start_date` har ligget i
  skjemaet siden migrasjon 001, men var ALDRI koblet til
  `TournamentCreate`/`Tournament`-modellene — funnet som en naturlig
  bivirkning av å legge til `end_date`.
  **Verifisert grundig mot fersk `teecup_scratch`** (001→006,
  `test_isolation.sql` fortsatt 12/12): feilkode-form bekreftet på tvers av
  5 filer (`NOT_FOUND`/`LIMIT_REACHED` tournaments.py, `DUPLICATE` roster,
  `NOT_AUTHENTICATED` uten cookie, `NOT_ROSTERED_ON_TEAM` matches.py),
  tee_time-beregning bekreftet (10 min intervall → 08:00/08:10/08:20,
  override vinner, `scheduled_at=null` gir `tee_time:null` ikke feil), full
  i18n-runde bekreftet (ny bruker `locale:"en"` → `preferred_locale:"en"`;
  påfølgende `request-link` for samme bruker med `locale:"nb"` skiftet
  e-postmalen men IKKE den lagrede preferansen, bekreftet via `/auth/me`).
  **Kjørt mot ekte `teecup_db` 2026-07-17** (bruker bekreftet eksplisitt i
  samme økt): migrasjonen kjørte rent, `test_isolation.sql` fortsatt 12/12
  (ruller alltid tilbake, ingen domenerader berørt).
  **Mindre driftslærdom, funnet OG rettet samme runde:** et `.env`-filter
  (`grep -v -i 'pass|secret|key'`) jeg brukte for å lese ikke-sensitive
  nøkler fanget ikke opp `TEECUP_DATABASE_URL`, som bar `teecup_app`-
  passordet innebygd i selve URL-en (i tillegg til at det SAMME passordet
  allerede lå rent i `TEECUP_APP_PASSWORD` — duplisert, ikke bare skjult) —
  passordet ble dermed synlig i et verktøyresultat. Flagget til brukeren
  umiddelbart (samme mønster som SMTP-passord-hendelsen over).
- **`.env`/tilkobling ryddet opp (2026-07-17), samme runde:** roten til
  hendelsen over var at `TEECUP_DATABASE_URL` var én sammensatt DSN-streng
  med passordet URL-kodet inni — usynlig for navnebaserte secret-filtre.
  Erstattet med fem separate, rent navngitte felt:
  `TEECUP_DB_HOST`/`TEECUP_DB_PORT`/`TEECUP_DB_NAME`/`TEECUP_DB_USER`/
  `TEECUP_DB_PASS` (sistnevnte omdøpt fra `TEECUP_APP_PASSWORD`, kun
  nøkkelnavnet — verdien aldri lest eller skrevet av meg). `app/config.py`
  og `app/db.py` bygger nå `asyncpg`-poolen fra disse fem separate feltene
  (`host=`/`port=`/`user=`/`password=`/`database=`) i stedet for én DSN —
  fjerner også URL-prosentkoding-problemet fra SMTP-passord-hendelsen sin
  klasse av feil. `docker-compose.yml` sin `environment:`-liste oppdatert
  tilsvarende. **Krevde et fullt image-rebuild, ikke bare
  `--force-recreate`:** `Dockerfile` sin `COPY app/ app/` bakes inn i
  imaget ved build-tid (ingen bind-mount i prod, i motsetning til
  scratch-verifiseringens engangscontainere) — en ren `--force-recreate`
  gjenbrukte det GAMLE imaget og krasjet umiddelbart på den nå fjernede
  `TEECUP_DATABASE_URL`. Rettet med `docker compose up -d --build
  --force-recreate`. **Verifisert ende-til-ende mot den live stacken:**
  containeren boot-et rent (`Application startup complete` i loggen, som
  krever en vellykket `init_pool()` — asyncpg ville kastet og forhindret
  akkurat den logglinjen ved feil tilkoblingsparametre), `/auth/me` over
  ekte https ga et rent `401 NOT_AUTHENTICATED` (ikke 500/502), `teeoff.no`
  upåvirket (`200` gjennom hele omstarten, kun `teecup_api` restartet — ikke
  delt Caddy-instans, ikke samme risikoklasse som Caddy-hendelsen fra
  containeriseringsrunden).

- **Frontend startet, innlogging LIVE (2026-07-17, ADR-016):** første
  frontend-skjerm i prosjektet. Designet i V0 (Next.js + Tailwind +
  shadcn/ui), hentet inn som `frontend/` — merkevare-form/farge fra
  Teeoff-logoen, IKKE navn/logo (egne, separate produkter, se ADR-009).
  **Kvalitetsrunde før bruk:** V0s fargetokens var OKLCH-TILNÆRMINGER, ikke
  eksakte — regnet ut presise verdier fra `#8bc24a`/`#ff5722` og rettet alle
  6 forekomster i `globals.css`. Fjernet `@vercel/analytics` (unødvendig på
  egen-hostet infra), fjernet `typescript: { ignoreBuildErrors: true }`
  (ekte typesjekk kjører nå), fjernet dødt `pnpm.overrides`-felt.
  `frontend/.gitignore` manglet `.pnpm-store/` — årsaken til at brukerens
  VSCode viste 10 000 "ukjente" filer ved første commit-forsøk; rettet.
  **Kablet mot ekte API:** `next.config.mjs` sin `rewrites()` proxyer
  `/auth/*`/`/orgs/*`/`/health` server-side til `teecup_api` — same-origin,
  ingen CORS, cookie uendret (full begrunnelse i ADR-016). Login-skjermet
  sender ekte `POST /auth/request-link`; ny `/verify`-side mottar
  `?token=...` fra e-postlenken (auto-verifiserer) eller viser et manuelt
  "lim inn koden"-felt. `app/email.py` fikk en ny `PUBLIC_BASE_URL`-
  innstilling og sender nå en EKTE klikkbar lenke (koden beholdes som
  fallback).
  **Reell fallgruve funnet og fikset ved containerisering:** Next.js sin
  `rewrites()` løses ved BUILD-tid for `output: "standalone"`, ikke ved
  container-oppstart — en runtime `-e TEECUP_API_ORIGIN=...` ble stille
  ignorert (proxy-kall feilet med `ECONNREFUSED` mot `localhost:8000`).
  Løst med en Docker build-time `ARG TEECUP_API_ORIGIN` i
  `frontend/Dockerfile`, satt via `docker-compose.yml` sin `build.args`.
  **Rullet ut live:** ny `teecup_frontend`-tjeneste i `docker-compose.yml`.
  Caddy (`teecup.teeoff.no`, i det SEPARATE `teeoff`-repoet,
  `/opt/teeoff/deploy/Caddyfile`) endret fra å peke direkte på `teecup_api`
  til å peke på `teecup_frontend` — samme stale-inode-oppførsel som
  containeriseringsrunden (graceful `reload` plukket IKKE opp endringen,
  `/` fortsatte å gi `teecup_api` sin egen 404 i stedet for innloggingssiden
  til reload faktisk skjedde). Løst likt: full `docker restart
  teeoff_caddy`, brukeren bekreftet eksplisitt på forhånd. `teeoff.no`
  upåvirket gjennom hele omstarten.
  **Verifisert med FAKTISK e-postlevering:** ekte magic-link sendt til
  brukerens egen adresse over `https://teecup.teeoff.no`, ekte e-post
  mottatt med en ekte klikkbar lenke, åpnet i nettleser, landet på en
  fungerende `/verify`-side, sesjon opprettet — brukeren bekreftet innlogget
  status. Første gang en hel bruker-vendt flyt er bevist ende-til-ende i
  produksjon, ikke bare API-et isolert.
  **Merk for neste økt:** `deploy/Caddyfile`-endringen ligger uncommitted i
  det SEPARATE `/opt/teeoff`-repoet, ikke i `teecup`-repoet — lett å glemme
  siden denne økten ellers kun har jobbet i `/opt/teecup`.
- **Dashboard-skjerm LIVE (2026-07-18):** andre V0-skjerm — organisasjon-
  bytter/-opprettelse + turneringsliste (`/dashboard`), samme mønster som
  login-runden. **Reell integrasjonsfelle unngått:** V0s eksport denne gangen
  var en FULL re-eksport av hele prosjektet (inkl. `login-form.tsx`,
  `next.config.mjs`, `package.json`), ikke bare de nye filene — en naiv
  utpakking ville stille reversert `rewrites()`-proxyen, `output:
  "standalone"`, den ekte fetch-kablingen i login-skjemaet, og alle
  V0-uavhengige opprydninger fra forrige runde. Løst ved å pakke ut til et
  scratch-område FØRST, diffe mot live-treet fil for fil, og kun ta inn det
  som faktisk var nytt (`dashboard.tsx`, `tournament-card.tsx`,
  `tournament-status-badge.tsx`, `wordmark.tsx`, `badge.tsx`,
  `dropdown-menu.tsx`, `app/dashboard/page.tsx`) — `next.config.mjs`,
  `package.json`, `globals.css`, Docker-filene ble bevisst IKKE overskrevet.
  `login-form.tsx` fikk en kirurgisk patch (kun Wordmark flyttet til egen
  fil, som V0 selv hadde gjort — all egen fetch-/feilhåndteringslogikk
  urørt).
  **`dashboard.tsx` sitt datalag skrevet om fra bunnen** (V0 leverte kun
  mock `useState`): henter `/auth/me` for organisasjonsmedlemskap,
  `/orgs/{id}/tournaments` per valgt org, `POST /orgs`/`POST
  /orgs/{id}/tournaments` for opprettelse, `POST /auth/logout` for utlogging
  — presentasjonskomponentene (kort, bytter, tomme tilstander) beholdt
  uendret fra V0. `/verify`-siden oppdatert til å sende brukeren videre til
  `/dashboard` etter vellykket innlogging (fantes ingen dit å gå før nå).
  **Verifisert:** ekte typesjekket build, redeploy av kun `teecup_frontend`
  (ingen Caddy-endring nødvendig denne gangen — ADR-016s mønster holder),
  `teecup.teeoff.no/dashboard` → 200, `teeoff.no` upåvirket.
  **Skrive-flyten bekreftet med EKTE data samme dag (brukeren testet selv,
  ikke meg):** organisasjon "Tjøme Gents" og turnering "De Gamle er Eldst"
  opprettet via UI-et mot den ekte `teecup_db` — statusmerket viste riktig
  "Utkast", "Ingen datoer satt" håndtert korrekt (ingen krasj på manglende
  dato), ett-org-visningen viste riktig uten unødvendig bytter-UI. Første
  gang en HEL skrive-flyt (ikke bare lesing) er bevist ende-til-ende fra
  frontend mot ekte produksjonsdata.
- **Lag/roster-skjerm LIVE (2026-07-18):** tredje V0-skjerm
  (`/tournaments/[id]`), samme re-eksport-mønster som dashboard-runden —
  diffet mot live-treet, tok kun inn `tournament-detail.tsx` og et
  `Link`-basert `tournament-card.tsx` (navigasjon fra dashbordet).
  **URL-design bevisst avvikende fra V0s forslag:** V0s genererte side leste
  aldri `params.id` og hadde ingen organization_id i det hele tatt — holdt
  derfor V0s flate `/tournaments/[id]`-struktur (i stedet for en nøstet
  `/orgs/[orgId]/tournaments/[id]`, som ville krevd manuell ombygging ved
  HVER fremtidig V0-reeksport) og la `org`+`name` til som søkeparametre i
  `tournament-card.tsx` sin lenke — API-et krever organization_id på alle
  team-/roster-kall (RLS).
  **Reelt hull funnet FØR integrering, ikke etter:** V0-skjermen bygger inn
  "fjern spiller"/"gjør til kaptein"-handlinger, men backend hadde KUN
  GET/POST på `team_roster` — ingen DELETE eller PATCH. Spurte bruker
  eksplisitt (samme mønster som andre scope-avklaringer denne økten) — svar:
  bygg de to endepunktene nå. Lagt til i `app/routers/tournaments.py`:
  `PATCH .../roster/{roster_id}` (bevisst enkel — setter/fjerner
  `is_captain` på NØYAKTIG denne raden, håndhever IKKE "kun én kaptein per
  lag", siden kaptein fortsatt bare er et merke, ikke en egen
  autorisasjonsrolle) og `DELETE .../roster/{roster_id}` (204, idempotent
  `NOT_FOUND` ved dobbel sletting — ikke krasj).
  **`tournament-detail.tsx` sitt datalag skrevet om fra V0s mock:** henter
  lag + roster (roster-radene bærer allerede `display_name`/
  `handicap_index_snapshot` fra APIet, så V0s separate `poolById`-oppslag
  ble fjernet som overflødig) og organisasjonens spillerpool
  (`GET /orgs/{id}/players`, brukt til type-ahead ved "legg til spiller").
  Alle fem mutasjonene (opprett lag, legg til eksisterende spiller, opprett
  ny spiller inline + rostre, endre kaptein, fjern fra roster) kablet mot
  ekte endepunkter — presentasjonskomponentene (kort, type-ahead,
  fargevelger, bekreft-fjerning) beholdt uendret fra V0.
  **Verifisert:** de to nye endepunktene testet mot en fersk
  `teecup_scratch` (PATCH setter kaptein + riktig `NOT_FOUND` på ugyldig id,
  DELETE gir 204 + idempotent `NOT_FOUND` ved gjentak, `test_isolation.sql`
  fortsatt 12/12), ekte typesjekket frontend-build (5 ruter), redeploy av
  BEGGE containere (backend-endepunktene er nye), `teecup.teeoff.no/dashboard`
  → 200, `teeoff.no` upåvirket. Selve skrive-flyten på `/tournaments/[id]`
  (opprett lag/roster) ikke testet med ekte data i denne runden — venter på
  brukeren, samme mønster som dashboard-rundens skrive-test.
- **ADR-017 + migrasjon 007 (2026-07-18):** brukeren reiste selvregistrering
  rett etter at roster-skrive-flyten var bekreftet. Full ADR skrevet
  (5 beslutninger: offentlig påmelding uten innlogging, e-post som
  sammenkoblingsnøkkel mot forhåndsopprettede spillere, egen
  `tournament_registration`-tabell atskilt fra `team_roster` med
  konfigurerbar godkjenning/kapasitet/venteliste, utvidet spillerprofil +
  obligatorisk samtykke, og `public_tournament_org()`). Migrasjon
  `007_registration_and_player_fields.sql` skrevet og scratch-verifisert
  (001→007 kjører rent, `test_isolation.sql` fortsatt 12/12).
  **Reelt arkitekturproblem løst underveis, ikke bare skjema:** et
  offentlig (uautentisert) påmeldingskall kjenner en turnering-id, men
  ingen org-kontekst — og uten `app.current_org` slipper RLS ingen rader
  gjennom, heller ikke oppslaget for å FINNE riktig org. Løst med en snever
  `SECURITY DEFINER`-funksjon (`public_tournament_org`) som KUN eksponerer
  uuid→uuid-koblingen. **Verifisert presist, ikke bare "kjørte uten feil":**
  kalt funksjonen som `teecup_app`-rollen med ingen `app.current_org` satt
  — ga korrekt org-id for en kjent turnering, `NULL` (ikke feil) for en
  ukjent — OG et RÅTT `SELECT` på `tournament` på SAMME tilkobling/rolle ga
  fortsatt 0 rader, som beviser RLS ikke er brutt generelt, bare dette ene
  smale unntaket eksisterer.
  **Kjørt mot ekte `teecup_db` 2026-07-18** (bruker bekreftet eksplisitt i
  samme økt): migrasjonen kjørte rent, `test_isolation.sql` fortsatt 12/12.
- **Registrerings-API LIVE (2026-07-18), samme dag:** ny
  `app/routers/registration.py` — `GET /public/tournaments/{id}` og
  `POST /public/tournaments/{id}/register`, begge UTEN `get_current_user`
  eller `get_authorized_org` (helt uautentisert, egen `/public`-prefiks,
  bevisst atskilt fra `/orgs/...` i koden). Bruker `public_tournament_org()`
  (migrasjon 007) til å slå opp org-kontekst FØR RLS kan håndheve noe.
  `app/routers/players.py` utvidet med alle sju nye ADR-017-feltene
  (`mobile`/`email`/`birth_date`/`nickname`/`country`/`club`/
  `club_member_number`). `frontend/next.config.mjs` sin `rewrites()`
  utvidet med `/public/*` (ADR-016s konsekvens: enhver ny API-prefiks MÅ
  inn her).
  **Ny brukers-oppdaget notat fanget FØR bygging, ikke etter:** brukeren
  krevde eksplisitt at synlighet (offentlig/kun org/kun turnering-
  deltakere) må være et VALG for fremtidige landingssider — notert grundig
  i `FEATURE_BACKLOG.md` (koblet til samme åpne spørsmål for "Banter
  Board"-feeden) FØR dette registrerings-API-et ble bygget, akkurat for at
  det ikke skal gå i glemmeboken til landingsside-runden.
  **Verifisert grundig mot fersk `teecup_scratch`** (001→007,
  `test_isolation.sql` 12/12): hele registreringsløpet testet reelt —
  samtykke-avvisning (400), duplikat-avvisning (409 `DUPLICATE`),
  e-post-matching mot en organisator-forhåndsopprettet spiller (BEKREFTET:
  ingen duplikatrad, mobil fylt inn via `COALESCE`, `display_name` IKKE
  overskrevet), kapasitet+`waitlist`-policy (→ `waitlisted`),
  kapasitet+`closed`-policy (→ 409 `LIMIT_REACHED`), `registration_
  requires_approval` (→ `pending`), utløpt frist (→ 409
  `REGISTRATION_CLOSED`), og `confirmed_count` i `GET`-responsen talt
  riktig (kun `confirmed`+`pending`, ikke `waitlisted`/avviste).
  **Rullet ut live:** begge containere redeployet, `teecup.teeoff.no/
  dashboard` og `/health` fortsatt 200, `teeoff.no` upåvirket, det
  offentlige endepunktet bekreftet nåbart over ekte https (ukjent
  turnering-id ga korrekt `404`/`NOT_FOUND`, ikke-destruktiv sjekk — selve
  påmeldingsflyten med ekte data ikke testet mot prod i denne runden).
  **E-post-basert kontosammenkobling LIVE, samme dag:** ny migrasjon
  `008_link_player_by_email.sql` — `link_player_by_email(user_id, email)`,
  samme `SECURITY DEFINER`-mønster som `public_tournament_org()` (007),
  denne gangen for en tverr-org UPDATE i stedet for et lese-oppslag.
  `verify_magic_link` (`app/routers/auth.py`) kaller den på HVER
  innlogging (idempotent — funksjonens `WHERE user_id IS NULL` gjør
  gjentatte kall til en no-op), ikke bare ved førstegangsopprettelse.
  **Verifisert presist:** to separate org-er, hver med sin egen
  organisator-opprettede "Kari"-rad (samme e-post, ulik store/små
  bokstaver for å teste case-insensitivitet også) — ved Karis FØRSTE
  innlogging ble BEGGE radene koblet til kontoen hennes, i to org-er hun
  aldri har vært medlem av. Eksplisitt bekreftet: `organization_membership`
  har NULL rader for henne etterpå — ren identitetskobling, ingen
  privilegie-eskalering (å ha `player.user_id` satt gir ingen ny tilgang
  gjennom `get_authorized_org`, som fortsatt krever ekte org-medlemskap
  uavhengig av dette). Andre innlogging idempotent, ingen feil.
  `test_isolation.sql` fortsatt 12/12. **Kjørt mot ekte `teecup_db`
  2026-07-18**, bruker bekreftet eksplisitt, backend redeployet, live
  sjekker OK, `teeoff.no` upåvirket.
  **ADR-017s backend er dermed komplett** (registrering + kontokobling).
  Gjenstående: frontend-påmeldingsskjema og landingssider — egen, senere
  ADR-runde (se `FEATURE_BACKLOG.md`).
- **ADR-018 + migrasjon 009: landingssider, backend LIVE (2026-07-18),
  samme dag:** trenivås synlighet (`tournament.visibility`:
  `public`/`org`/`participants`, default `org` — trygg standard) +
  `organization.public_profile`. **Reell presisering funnet underveis, ikke
  antatt på forhånd:** RLS (`org_isolation`) beskytter kun TENANT-grenser
  (org A ser aldri org B), IKKE innholds-synlighet innenfor riktig
  org-kontekst — det eksisterende `GET /public/tournaments/{id}` (ADR-017)
  leste allerede fullt innhold uten synlighetssjekk, fordi RLS er fornøyd
  så snart org-konteksten er satt, uansett hvem som spør. `visibility`
  håndheves derfor eksplisitt i `app/routers/registration.py`, på BÅDE
  lesing og registrering (ADR-018 Beslutning D: kan du ikke se turneringen,
  kan du heller ikke melde deg på den — bekreftet med bruker FØR bygging).
  Ny `get_current_user_optional` i `app/auth.py` (som `get_current_user`,
  men returnerer `None` i stedet for 401 — offentlige endepunkter skal
  fungere for anonyme lesere også). Ny "deltaker"-autorisasjonsvei: en
  innlogget bruker med `player.user_id` koblet (ADR-017) OG en
  `tournament_registration`- eller `team_roster`-rad for NØYAKTIG den
  turneringen får se `participants`-synlige turneringer, uansett
  org-medlemskap.
  **Ekte migrasjonsfeil funnet OG rettet UNDER scratch-verifisering, ikke
  antatt riktig:** migrasjonen feilet først ("column slug already exists")
  — `organization.slug` har ligget i skjemaet siden migrasjon 001
  ("f.eks. subdomene/URL-vennlig", allerede med en plain `UNIQUE`), noe jeg
  hadde oversett fullstendig og forsøkt å legge til på nytt. Rettet ved å
  fjerne den doble `ADD COLUMN` + den overflødige partielle unik-indeksen
  (001 sin plain `UNIQUE` dekker "unik når satt" allerede, siden Postgres
  behandler NULL som distinkt), beholde kun de nye `CHECK`-constraintene.
  Kjørte rent på ny etter fiksen. **Lærdom:** grep alltid eksisterende
  skjema for feltnavn FØR en ny migrasjon skrives, ikke bare stol på
  hukommelsen om hva som "sikkert" ikke finnes fra før.
  Ny tabell `tournament_sponsor` (navn+lenke aktivt, `logo_key` inert til
  MinIO-runden — samme med `tournament.hero_image_key`). Tredje
  `SECURITY DEFINER`-bro i prosjektet: `public_org_by_slug()` (etter
  `public_tournament_org` 007, `link_player_by_email` 008) — returnerer
  `NULL` for BÅDE "finnes ikke" og "finnes, men er privat", samme
  anti-enumerering som magic-link.
  **Fylte også et implisitt hull oppdaget underveis:** ADR-en beskrev
  hvordan synlighet skulle håndheves, men ingen tidligere runde hadde bygget
  noen vei for organisator til faktisk å SETTE disse feltene. Lagt til:
  `PATCH /orgs/{id}/tournaments/{id}` (visibility/description/
  registrerings-innstillinger, ekte PATCH-semantikk via Pydantic sin
  `exclude_unset` — et utelatt felt nullstilles IKKE), `PATCH /orgs/{id}`
  (slug/public_profile), full sponsor-CRUD. `_fetch_sessions()` trukket ut
  som delt hjelpefunksjon i `tournaments.py` (delt mellom den innloggede
  og den nye offentlige `GET /public/tournaments/{id}/sessions` — blind
  draw-hemmelighold, ADR-013, arves automatisk, ikke reimplementert).
  **Verifisert grundig mot fersk `teecup_scratch`** (001→009,
  `test_isolation.sql` 12/12): hele synlighetsmatrisen testet med ekte
  HTTP-kall — anonym avvist på `org`-synlig turnering (både lesing OG
  registrering), `PATCH` til `public` + beskrivelse + sponsor fungerte,
  anonym lesing fungerte deretter, `participants`-synlighet bekreftet
  reell chicken-and-egg-konsekvens av Beslutning D (ingen kan selv-
  registrere seg til en `participants`-synlig turnering, kun organisator
  kan legge til direkte — korrekt, ikke en bug), en organisator-rostret
  spiller som logget inn fikk tilgang, en tilfeldig innlogget FREMMED
  (ikke deltaker) ble fortsatt avvist, org-landingsside viste KUN
  `public`-synlige turneringer, `CHECK`-constraint (`public_profile`
  krever `slug`) avvist korrekt, ugyldig slug-format avvist av Pydantic,
  sponsor-sletting fungerte.
  **Kjørt mot ekte `teecup_db` 2026-07-18**, bruker bekreftet eksplisitt,
  backend redeployet, live sjekker OK, `teeoff.no` upåvirket. Ingen
  frontend-endring nødvendig for selve API-tilgangen (det brede
  `/public/:path*`-mønsteret fra ADR-016 dekker allerede `/public/orgs/*`).
  **Gjenstår:** selve landingsside-SKJERMENE i frontend (V0), og
  MinIO/bildeopplasting — bevisst utsatt, egen runde.
- **Offentlig turnering-landingsside LIVE (2026-07-18), samme dag:** fjerde
  V0-skjerm (`components/public-tournament.tsx`, ny rute `/t/[id]`) —
  banner (bevisst permanent farge-/gradient-utseende, ikke en "bilde
  kommer"-plassholder), presenterende tekst, status (datoer + "X av Y
  plasser"), program, sponsorer (navn+lenke), og et påmeldingsskjema med
  navn+e-post synlig først og resten bak en "flere detaljer"-utvidelse —
  tre distinkte bekreftelsestilstander (bekreftet/venteliste/godkjenning
  venter), ikke én generisk "takk".
  **Ingen ny reeksport-kollisjon denne gangen** — kun étt genuint nytt
  filnavn (`public-tournament.tsx`), resten var kjent V0-revert av
  allerede-tilpassede filer, samme mønster som før.
  **V0 opprettet komponenten, men ingen rute** — la selv til `app/t/[id]/
  page.tsx` (bevisst en FLAT `/t/[id]`-sti, ikke nøstet under `/orgs/...`
  som den innloggede turnering-detalj-siden, siden det offentlige API-et
  kun trenger turnering-id, ikke org-id).
  **Datalaget skrevet om fra V0s mock:** ekte `fetch` mot
  `GET /public/tournaments/{id}` + `/sessions`, ekte `POST .../register`.
  Håndterer 403 (`NOT_VISIBLE`, ADR-018) og 404 med en egen tilgang-avvist-
  tilstand V0 ikke hadde bedt om (fantes ikke i prompten, men trengs for at
  siden faktisk skal fungere for `org`/`participants`-synlige turneringer).
  Mappet `status:"waitlisted"` fra API-et til komponentens `"waitlist"`, og
  skjemaets norske kjønnsvalg ("kvinne"/"mann"/"annet") til API-ets
  `^[mfx]$`-mønster — to reelle navnekollisjoner mellom V0s UI-språk og
  API-kontrakten, ikke bare et rett-frem felt-for-felt-uttrekk.
  **Reell driftsfeil funnet OG rettet under scratch-test, ikke i
  produksjon:** `pnpm install` (uten `--ignore-scripts`) i dev-server-
  testoppsettet feilet stille med tom logg og exit 1 — corepack hadde
  hentet en NY pnpm-versjon (11.13.1 → 11.14.0) siden sist, som gjør
  "ignored builds"-varselet til en hard feil i stedet for bare en
  advarsel. Rettet ved å bruke samme `--ignore-scripts`-flagg som
  `frontend/Dockerfile` allerede bruker (upåvirket av denne — bekreftet
  ved at selve prod-buildet fortsatt gikk rent). **Lærdom:** `Dockerfile`
  sin pinning av *kode* er ikke det samme som å pinne *verktøyene rundt*
  (corepack henter alltid siste pnpm) — verdt å huske neste gang et
  scratch-dev-server-oppsett plutselig feiler uten åpenbar grunn.
  **Verifisert grundig mot fersk `teecup_scratch` + en ekte kjørende
  frontend-dev-server** (ikke bare `next build`): ekte turnering med
  beskrivelse, kapasitet, sponsor og økt opprettet via API-et, hentet
  gjennom frontend-proxyen (ikke direkte mot backend) og bekreftet
  byte-for-byte riktig — inkludert en ekte `POST`-registrering som økte
  `confirmed_count` fra 0 til 1.
  **Rullet ut live**, kun `teecup_frontend` (ingen backend-endring denne
  runden), `teeoff.no` upåvirket.
  **Gjenstår:** org-landingssiden (egen V0-prompt), Open Graph-metadata for
  deling, MinIO/bilder.
- **Offentlig klubb-landingsside LIVE (2026-07-18), samme dag:** femte og
  siste V0-skjerm i ADR-018 (`components/public-club.tsx`, ny rute
  `/clubs/[slug]`). Samme banner-språk som turnering-siden, liste over
  klubbens turneringer (gjenbrukte eksisterende `TournamentCard`), egen tom-
  tilstand.
  **Reell delt-komponent-kollisjon løst, ikke duplisert bort:**
  `TournamentCard` var bygget for KUN den innloggede konteksten (krevde
  `orgId`, lenket til `/tournaments/{id}?org=...`). I stedet for en egen
  kopi av kortet for den offentlige siden, gjort `orgId` valgfri —
  satt (dashbordet) gir innlogget lenke, utelatt (klubbsiden) gir
  `/t/{id}` i stedet. Samme kort, to kontekster, ingen duplisering.
  Bekreftet dashbordets egen bruk uendret/upåvirket etterpå.
  **V0 opprettet denne gangen selv en rute** (`app/clubs/[id]/page.tsx`,
  uten noen props sendt inn i det hele tatt) — men navnga parameteren
  `[id]` selv om den faktisk er en SLUG (`public_org_by_slug()`, ADR-018).
  Skrev selv en ny, riktig `app/clubs/[slug]/page.tsx` i stedet for å bruke
  V0s (feilnavngitte og prop-løse) versjon.
  **Verifisert mot fersk `teecup_scratch` + ekte kjørende frontend-dev-
  server:** org med slug+`public_profile`, én turnering satt `public`, én
  latt stå på default `org` — klubbsiden viste GJENNOM frontend-proxyen
  kun den ene offentlige turneringen, den org-private var korrekt
  usynlig (samme filtermønster som API-et selv, bekreftet fra
  klientsiden også). Ukjent slug ga korrekt 404.
  **Rullet ut live**, kun `teecup_frontend`, `teeoff.no` upåvirket.
  **ADR-018s planlagte skjermer er dermed komplette.** Gjenstår: Open
  Graph-metadata for deling, MinIO/bilder — begge bevisst egne, senere
  runder.
- **Open Graph-metadata LIVE (2026-07-18), samme dag — ADR-018 dermed
  helt ferdig:** `generateMetadata()` lagt til på `/t/[id]` og
  `/clubs/[slug]` (ekte tittel/beskrivelse fra API-et, `og:site_name`,
  trygg fallback-tittel ved ukjent id/slug — feil her skal ALDRI hindre
  selve siden i å laste).
  **Reell driftsfeil funnet FØR den nådde produksjon, ikke etter:**
  `generateMetadata()` kjører server-side ved REQUEST-tid, ikke i
  nettleseren — går derfor IKKE gjennom `next.config.mjs` sin
  `rewrites()` (som kun gjelder nettleser-trafikk inn til Next.js-
  serveren). Måtte derfor lese `TEECUP_API_ORIGIN` direkte, men den
  variabelen fantes KUN i `Dockerfile` sitt builder-steg — `ENV` satt i
  ett `FROM`-steg arves ikke til et senere. Rettet ved å sette samme
  `ARG`/`ENV` på nytt i runner-steget også.
  **Verifisert presist at fiksen faktisk virker, ikke bare at bygget gikk
  gjennom:** bygget det EKTE produksjonsimaget (ikke dev-server) pekt mot
  en scratch-backend med en ekte offentlig turnering+org, hentet den
  faktiske server-rendrede HTML-en og bekreftet ekte `<title>`/`og:title`/
  `og:description` — ikke bare at TypeScript kompilerte. Ukjent
  turnering-id ga korrekt trygg fallback-tittel.
  **Bevisst utenfor omfang:** `og:image` — ingen ekte bilde finnes ennå
  (MinIO-runden). La til `metadataBase` i `app/layout.tsx` nå likevel, som
  forarbeid slik at et fremtidig relativt bilde-URL løses riktig uten en
  egen fiks da.
  **Rullet ut live**, kun `teecup_frontend`, `teeoff.no` upåvirket.
- **MinIO-runden LIVE (2026-07-18), samme dag — ADR-018 dermed HELT
  ferdig, ingenting utsatt igjen:** ny `teecup-minio`-tjeneste (persistent
  volum, genererte credentials i `.env`), backend-endepunkter for ekte
  bildeopplasting til `tournament.hero_image_key`/`tournament_sponsor.
  logo_key` (som lå inerte siden migrasjon 009), offentlige API-svar bygger
  nå fulle URL-er, `og:image` koblet på i `/t/[id]` sin `generateMetadata`.
  **Sent, men viktig presisert krav underveis:** brukeren avbrøt en
  verktøyskall midtveis for å presisere at ALLE bilder skal konverteres
  til AVIF for plassbesparelse. Snudde HELE opplastingsarkitekturen på
  dette: droppet den opprinnelige planen om presignerte URL-er (nettleser
  laster opp DIREKTE til MinIO) til fordel for ekte multipart-opplasting
  GJENNOM API-et, som konverterer til AVIF (Pillow + pillow-avif-plugin)
  FØR lagring. Dette forenklet arkitekturen betydelig: kun ÉN MinIO-klient
  trengs nå (før: to separate klient-oppsett for henholdsvis internt
  admin-arbeid og offentlig presignering), og Caddy sin nye rute trenger
  ikke lenger bevare Host-headeren presist (relevant kun for SigV4-
  signaturverifisering av presignerte URL-er, ikke for anonym public-read).
  **To reelle feil funnet UNDER scratch-verifisering, aldri i produksjon:**
  (1) `pillow-avif-plugin` krever ingen ekstra systempakker i
  `python:3.12-slim` -- verifisert med et frittstående encode/decode-
  rundtrip FØR det ble tatt i bruk i selve API-et. (2) MinIO validerer
  `Host`-headeren STRENGT og avviser understrek som ugyldig vertsnavn --
  et tjenestenavn med understrek (`teecup_minio`, konsistent med
  `teecup_api`/`teecup_frontend`) feilet umiddelbart ved oppstart
  ("Invalid Request (invalid hostname)"). Bekreftet presist ved å teste
  samme oppsett med bindestrek i stedet (`teecup-minio`) -- fungerte
  umiddelbart. Alle referanser rettet til bindestrek FØR noe ble forsøkt
  mot ekte infrastruktur.
  **Caddy:** ny `/teecup-media/*`-rute på det EKSISTERENDE
  `teecup.teeoff.no`-blokket (IKKE et nytt subdomene -- en tidlig sjekk
  avdekket at `media.teecup.teeoff.no` fantes som en wildcard DNS-post,
  men pekte til en IPv6-adresse denne serveren ikke har i det hele tatt;
  path-prefiks på et allerede fungerende domene unngikk hele den DNS-
  avhengigheten). Samme stale-inode-oppførsel som alle tidligere Caddy-
  runder -- full `docker restart teeoff_caddy`, brukeren bekreftet
  eksplisitt. `teeoff.no` upåvirket.
  **Verifisert grundig, i flere lag:** frittstående AVIF-encode/decode-
  test, full scratch-kjede (fersk Postgres + en ISOLERT scratch-MinIO-
  container) med et ekte opplastet bilde -- bekreftet konvertert til
  gyldig AVIF (800×400, 406 bytes for et helfarget testbilde), bekreftet
  lagret med riktig nøkkel, bekreftet lesbart ANONYMT direkte mot MinIO
  (uten Caddy, isolerer bucket-policyen), bekreftet `hero_image_url`/
  `logo_url` bygget riktig i det offentlige API-svaret. Alle tre
  valideringsveier testet (ugyldig content-type, korrupt bildeinnhold,
  for stor fil >8MB) -- alle ga korrekt `VALIDATION_FAILED`. Etter
  Caddy-omstart: et ekte anonymt kall mot `/teecup-media/...` på
  produksjonsdomenet ga en ekte MinIO S3-XML-feilrespons (`NoSuchKey` for
  en scratch-nøkkel som naturligvis ikke finnes i prod) -- beviser ruten
  treffer MinIO selv, ikke frontend sin egen 404-side.
  `test_isolation.sql` fortsatt 12/12 gjennom hele runden.
  **Bevisst utenfor omfang:** ingen faktisk opplasting av et EKTE bilde
  til en EKTE, live turnering i denne runden (ville krevd å skrive
  test-data i brukerens ekte konto uten å bli spurt) -- tilbudt, ikke
  utført. Selve dra-og-slipp-opplastingsskjermen i frontend (V0) er
  fortsatt ikke bygget, som avtalt fra starten av runden.

- **Program-skjerm (økter/tidsplan), bygget og SCRATCH-verifisert, IKKE
  live ennå (2026-07-18):** sjette V0-skjerm, første i "bygg i rekkefølgen
  ting brukes"-serien (etter lag/roster: program → blind draw → scorekort →
  leaderboard). `components/tournament-program.tsx`, ny rute
  `/tournaments/[id]/program`. Tidslinje over økter + opprett-skjema
  (format, hullomfang, scoringsmodus, poeng, klokkeslett+intervall,
  starthull, kollapsbar "avansert"-seksjon med ADR-014s fire brytere).
  **Reelt blokkerende hull funnet FØR integrering:** `SessionCreate.
  course_id` er påkrevd, men INGEN endepunkt kunne noensinne produsere en —
  ADR-004s teeoff-integrasjon er fortsatt bare vedtatt (ingen utgående
  HTTP-klient finnes). Spurte bruker eksplisitt — svar: bygg enkel
  course-CRUD nå. Ny `app/routers/courses.py` (`GET`/`POST /orgs/{id}/
  courses`, kun `source='custom'`). Program-skjemaet fikk et
  type-ahead-felt for bane (samme mønster som spiller-type-ahead i
  roster-skjermen).
  **Reell korrekthetsfeil rettet FØR integrering:** V0-promptet mitt ba om
  ett generisk "Scramble"-valg, men skjemaets `CHECK`-constraint og
  `handicap_engine.py` sin `Format`-enum krever `scramble_2`/`scramble_4`
  som distinkte verdier -- ren `"scramble"` avvises med 400. Rettet i
  frontend-mappingen til to segment-knapper.
  **`allowance_override`-JSON-formen verifisert eksakt** mot
  `app/handicap.py` sin `parse_allowance_config`/`_strategy_from_json`
  (`{type: "combined"|"per_player", percentage: 0..1}`, ikke en flat
  prosent) -- frontend velger riktig `type` ut fra om formatet er
  side-enhet eller spiller-enhet, konverterer 0–100-skjemafelt til 0–1.
  **Scratch-infrastruktur denne runden, bevisst forskjellig fra tidligere:**
  brukte en ISOLERT `teecup_app_scratch`-rolle (`GRANT teecup_app TO
  teecup_app_scratch`) i stedet for den ekte `teecup_app`-rollen -- den er
  nå cluster-global og produksjonskritisk (delt Postgres-instans med
  `teecup_db`), så et eldre plandokuments "drop teecup_app-rolle"-
  opprydning (skrevet FØR go-live) er utdatert og ble bevisst IKKE fulgt.
  Egen isolert scratch-MinIO-container også (app-oppstart krever en
  nåbar MinIO for `ensure_bucket()`).
  **Verifisert:** courses opprettet+listet, kryss-org-isolasjon bekreftet,
  økt med klokkeslett, økt med `scramble_4`+full `allowance_override`-
  rundtur, gammel `"scramble"`-verdi avvist (400), `test_isolation.sql`
  12/12, ekte typesjekket PRODUKSJONSBUILD (samme `Dockerfile` som faktisk
  deployes) kjørt og bekreftet.
  **Diffet V0-eksporten mot live-treet FØR noe ble tatt inn** (samme mønster
  som alle tidligere runder): kun tre reelt nye filer, resten forventede
  full-reverts, ikke rørt. Fjernet V0s dev-only forhåndsvisnings-toggle;
  lagt til fanerad ("Lag og spillere" / "Program") i BEGGE skjermene siden
  V0 ikke visste om den andre når den ble generert i egen prompt.
  **Rullet ut live 2026-07-18**, bruker bekreftet eksplisitt: `docker
  compose up -d --build teecup_api teecup_frontend` (kun disse to, `teecup-
  minio` urørt). Verifisert: begge containere boot-et rent (`Application
  startup complete`, Next.js `Ready`), `teecup.teeoff.no/health` og
  `/dashboard` → 200, `teeoff.no` upåvirket (200).
- **ADR-004 (teeoff-banedata) kartlagt, IKKE bygget (2026-07-18):** brukeren
  påpekte rett etter program-skjerm-rullingen at ADR-004s teeoff-
  integrasjon fortsatt bare er vedtatt, ikke bygget (kun `source='custom'`
  finnes). Kartlagt `/opt/teeoff/backend/main.py` (annet repo, kun lest):
  `GET /api/facilities/{slug}` (offentlig, INGEN auth/API-nøkkel) returnerer
  allerede alt teecup trenger — `courses[].holes[]` (`par`, `hcp_index`
  = stroke index), `courses[].tees[]` (`name`, `cr_men`/`slope_men`,
  `cr_women`/`slope_women` — kjønnsdelt WHS-rating). CORS-lista på teeoff-
  siden ekskluderer teecups origin, men er IRRELEVANT for et server-til-
  server-kall (kun nettleser-fetch rammes av CORS). Ingen dokumentasjon
  (README/OpenAPI) finnes for dette API-et i teeoff-repoet — kartleggingen
  over er basert på å lese koden direkte. Stabil identifikator: `facilities.
  slug` (f.eks. `borregaard-golfklubb`) — selve banen har kun en intern
  serial-id, ingen egen slug, så `course.external_course_ref` må bære
  facility-slug + bane-id sammen.
  **Oppdatering samme dag: brukeren ba meg ta fatt på dette NÅ** (bevisst
  sidesprang fra "bygg i rekkefølgen ting brukes"-planen — blind draw-
  skjermen er fortsatt neste steg i den planen ETTERPÅ, ikke droppet).
  Design besluttet og skrevet som **ADR-019** (se ARCHITECTURE_DECISIONS.md):
  import (kopi) ved organisators eksplisitte valg, ikke live oppslag ved
  hver bruk — fryser data på importtidspunktet, samme reproduserbarhets-
  prinsipp som handicap-snapshotten (ADR-007). Server-til-server-kall
  (`teecup_api` → `http://teeoff_api:8000`, internt Docker-nettverk, ingen
  auth trengs). Ny migrasjon `010` (unik `external_course_ref` per org,
  hindrer dupliserte importer). Se ADR-019 for alle fem delbeslutningene.
  **Bygget, scratch-verifisert MOT EKTE `teeoff_api`** (ikke en simulert
  respons — ekte HTTP-kall til den kjørende produksjonscontaineren, kun
  lesing): søkte opp "Borregaard" i teeoff sine 174 publiserte anlegg,
  hentet Borregaard Golfklubb sin hovedbane (18 hull, 4 tee-farger ×
  kjønn), importerte den til en scratch-org — alle 18 hull med riktig
  par/stroke-index (1-18, unik), alle 8 tee/tee_rating-rader med riktig
  full_18 course/slope-rating verifisert direkte i databasen, opprettet
  deretter en ekte økt med den importerte banen som `course_id` (beviser
  hele veien til handicap-motoren fungerer, ikke bare selve importen).
  Reimport av samme bane korrekt avvist (409 DUPLICATE, migrasjon 010 sin
  indeks). Kryss-org-isolasjon bekreftet, ukjent teeoff-slug ga korrekt 404,
  `test_isolation.sql` 12/12. Ekte typesjekket produksjonsbuild av
  frontend-utvidelsen (bane-søk i program-skjemaet: søk anlegg → velg bane →
  importer, samme UI-mønster som spiller-/bane-type-ahead ellers i appen).
  **Rullet ut live 2026-07-18**, bruker bekreftet eksplisitt: migrasjon 010
  kjørt mot ekte `teecup_db` (kun én ny partiell unik-indeks, ingen
  eksisterende rader rørt), begge containere bygget+redeployet, live
  sjekker OK, `teeoff.no` upåvirket. **"Bygg i rekkefølgen ting brukes"-
  planen gjenopptas nå** — blind draw-skjermen er neste steg.
  **Reell produksjonsbug funnet OG fikset samme dag, rapportert av bruker
  som faktisk brukte funksjonen:** brukeren klikket seg korrekt via
  dashbord → turnering → Program-fane (bekreftet med skjermbilde + full
  klikk-sti, ikke gjettet), åpnet "Hent bane fra teeoff", søkte "Tjøme", og
  fikk feilmeldingen "Mangler organisasjon i lenken" — URL-en hadde da
  MISTET `?org=...&name=...`. Root-cause: `OfficialCourseSearch` sitt eget
  søke-`<form onSubmit={runSearch}>` var rendret INNI `CreateSessionCard`
  sitt eksisterende `<form onSubmit={handleSubmit}>` -- nestede
  `<form>`-elementer er ugyldig HTML. Nettleseren slår sammen de to
  skjemaene i den faktiske DOM-en, så "Søk"-knappen submittet i praksis det
  YTRE økt-skjemaet som en ekte native side-navigasjon (GET til gjeldende
  sti, ingen navngitte felt => tom spørrestreng) -- dette vasket bort
  org-parameteren og landet brukeren på siden sin egen org-guard. **Fikset**
  ved å fjerne det indre `<form>`-elementet helt (vanlig `<div>` +
  Enter-tast-håndtering på inputet + `type="button"` i stedet for
  `type="submit"` på søkeknappen) -- gjør nestede skjemaer strukturelt
  umulig fremover for denne komponenten. Ekte typesjekket
  produksjonsbuild kjørt på nytt, kun `teecup_frontend` redeployet (ingen
  backend-endring). **Lærdom for fremtidige skjermer:** en ny
  søk-/underskjema-widget som skal plasseres INNI et eksisterende skjema
  (slik som denne bane-søk-widgeten ligger inni økt-opprett-skjemaet) må
  ALDRI være et eget `<form>` -- bruk `<div>` + eksplisitt
  klikk-/Enter-håndtering.

- **Organisator-overstyring i `team_authz.py`, LIVE (2026-07-18):** reist av
  brukeren rett før blind draw-skjermen skulle designes: `app/team_authz.py`
  sin `user_may_act_for_team` krevde tidligere en `team_roster`-rad med
  lenket bruker-konto — ingen vei for organisatoren til å låse/legge til
  deltakere/føre score hvis ingen spiller hadde logget inn ennå (vanlig
  tidlig i en turnering). Utvidet til også å godta org-eier/admin
  (`organization_membership.role IN ('owner','admin')`), på ETHVERT lag,
  ingen unntak for at organisatoren selv er rostret på motstanderlaget.
  **Det unntaket ble bevisst vurdert og avvist** (brukeren spurte selv om
  det, jeg anbefalte det opprinnelig, men vi kom sammen frem til at det ville
  skapt en verre låsning: er organisatoren spillende på Lag A og
  Lag B heller ikke har noen innlogget spiller, ville Lag B blitt helt
  låst ute) — TeeCup er et tillitsbasert klubb-/vennegjeng-verktøy, ikke en
  sikkerhetsgrense mot en fiendtlig organisator som uansett allerede ser
  begge lags fulle troppe-liste (blind draw skjuler kun selve
  kamp-paringen). Alle 5 kallsteder oppdatert (matches.py sin
  add_participant/lock_lineup, scoring.py sin submit_hole_score/
  submit_hole_result). **Verifisert grundig i scratch:** org-eier uten
  roster kan nå låse BEGGE lag + føre score, en vanlig 'member'-rolle
  fortsatt blokkert (uendret), en rostret spiller fungerer uendret
  uavhengig av org-rolle. `test_isolation.sql` 12/12. Ingen migrasjon (ren
  Python-endring) — kun `teecup_api` redeployet, `teeoff.no` upåvirket.

- **Tee-endepunkter bygget og LIVE (2026-07-18), rett før blind draw-skjermen:**
  fant et hull som blokkerte selve blind draw-flyten: `match_participant.
  tee_id` er påkrevd, men det fantes INGEN `GET`-vei for å liste en banes
  tee-er (selv offisielt importerte baner har tee-rader, men ingenting
  eksponerte dem) OG egendefinerte («custom») baner har ALDRI hatt noen
  vei til å FÅ tee-er i det hele tatt — dette er ikke noe ADR-019 innførte,
  det var et hull som fantes fra før custom-baner ble lagt til i første
  omgang, bare usynlig til nå. Konsekvens før fiksen: en turnering satt opp
  på en manuelt navngitt bane kunne ALDRI få en ekte deltaker lagt til på
  noen match. **Presisering (brukeren spurte eksplisitt):** dette er IKKE
  noe som må løses i teeoff.no sin kode — egendefinerte baner er per
  definisjon baner teeoff ikke kjenner til, så dette er en ren
  teecup-intern funksjon, uavhengig av ADR-019-integrasjonen.
  Ny `GET/POST /orgs/{id}/courses/{id}/tees` i `app/routers/courses.py`.
  `POST` avviser eksplisitt forsøk på offisielle baner (400
  `VALIDATION_FAILED` — de får tee-ene sine fra teeoff-importen, ikke
  manuelt). Kun full_18-rating dekket (samme begrunnelse som ADR-019
  Beslutning D). **Bevisst UTENFOR omfang denne runden, egen senere sak:**
  hull-/stroke-index-data for egendefinerte baner (`hole`-tabellen forblir
  tom for custom-baner) — trengs for korrekt slagfordeling i SCORING-fasen
  (ADR-008), ikke i blind draw, så det løses naturlig når scorekort-
  skjermen bygges (samme "bygg i rekkefølgen ting brukes"-logikk).
  **Verifisert grundig i scratch:** tom tee-liste på fersk custom-bane,
  opprett+list tee på custom-bane, offisiell bane viser alle 8 importerte
  tee-er, manuell tee-opprettelse avvist på offisiell bane, og — den
  faktiske payoff-en — en deltaker lagt til en match på en custom-bane-økt
  for FØRSTE gang noensinne (`POST .../matches/{id}/participants` lykkes
  nå med en tee_id fra en nyopprettet custom-tee). `test_isolation.sql`
  12/12. Ingen migrasjon, kun `teecup_api` redeployet, `teeoff.no`
  upåvirket.

- **Blind draw-skjermen LIVE (2026-07-18):** syvende V0-skjerm,
  `components/session-blind-draw.tsx`, ny rute
  `/tournaments/[id]/sessions/[sessionId]`. To lag-kolonner, hver med sine
  matcher ("flights"), legg til/fjern spiller+tee per plass (antall plasser
  avhenger av format), lås-knapp med bekreftelse, avslørings-visning når
  begge lag har låst. Program-skjermens økt-kort er nå klikkbare inn hit.
  **Datamodell tilpasset fra V0s mock til API-ets faktiske sett-modell:**
  V0 designet faste, indekserte "Slot"-arrays (kontrollert skjema-state);
  API-et har verken PATCH på `match_participant` eller noen slot-indeks —
  kun opprett/slett av en løs deltaker-mengde per side. Løst med en
  "legg til spiller"-inline-form (samme mønster som spiller-/bane-type-ahead
  ellers i appen) i stedet for faste dropdown-rader; funksjonelt likeverdig,
  strukturelt riktigere for API-ets faktiske form.
  **To reelle hull funnet og fikset FØR/UNDER integrering:**
  1. Ingen `DELETE` fantes for `match_participant` — en kaptein kunne aldri
     angre et valg før låsing uten å etterlate en foreldreløs rad. Ny
     `DELETE /orgs/{id}/matches/{match_id}/participants/{participant_id}`
     (samme ALREADY_LOCKED/NOT_ROSTERED_ON_TEAM-sjekker som opprett).
  2. **"Skriv blindt"-hull, funnet under selve scratch-testingen (ikke bare
     tenkt ut på forhånd):** forrige rundes org-admin-overstyring i
     `team_authz.py` lot en organisator LEGGE TIL deltakere på et lag de
     ikke selv er rostret på, men `app/blind_draw.py` sin `own_team_ids()`
     sjekket KUN rostret spiller for SYNLIGHET — så organisatoren så aldri
     sine egne tilføyelser igjen før begge lag hadde låst. Fikset ved å gi
     `own_team_ids()` samme owner/admin-utvidelse som `user_may_act_for_
     team()` — en org-admin ser nå BEGGE lag umiddelbart (konsistent med at
     de uansett allerede har full tilgang, se forrige rundes resonnement),
     mens en faktisk rostret kaptein fortsatt kun ser sitt eget lag før
     reveal. Kun ett reelt kallsted (`matches.py` sin `list_matches`).
  **Tredje, urelatert bug fanget under samme scratch-økt og fikset på
  brukerens eksplisitte forespørsel:** `POST .../matches/{id}/participants`
  krasjet med en rå 500 (`TypeError` i `handicap_engine.py` sin
  `course_handicap_raw`) hvis spilleren manglet `handicap_index` OG
  `use_handicap` var på (standard) — preeksisterende, ikke noe denne
  runden introduserte. Fikset i `app/routers/matches.py` sin
  `add_participant`: sjekker nå `handicap_index_snapshot IS NULL` EKSPLISITT
  FØR innsetting når `use_handicap` er sann, avviser med en klar
  `VALIDATION_FAILED` (400) i stedet for å krasje. Bekreftet at
  `use_handicap=false` fortsatt tillater en spiller uten handicap
  (scratch-spill), og at en spiller MED handicap fortsatt fungerer uendret.
  **Verifisert grundig i scratch, flere runder:** DELETE-endepunktet
  (fjern+idempotent 404 ved gjentak+409 etter lås), synlighetsfikset (org-
  admin ser begge sider, rostret kaptein ser fortsatt kun eget lag),
  null-handicap-fikset (avvist rent, scratch-modus upåvirket, normal
  spiller upåvirket), full opprett-match→legg-til-deltaker→lås→avslør-
  syklus ende-til-ende. `test_isolation.sql` 12/12 etter hver runde. Ekte
  typesjekket produksjonsbuild.
  **Rullet ut live**, bruker bekreftet eksplisitt: begge containere
  bygget+redeployet (ingen migrasjon), `teeoff.no` upåvirket.

- **Backend-forarbeid for scorekort-skjermen, LIVE (2026-07-18):** to hull
  funnet ved gjennomlesing av `scoring.py` FØR V0-prompten ble skrevet,
  samme føre-var-mønster som resten av økten.
  1. **Hull-/stroke-index-data for egendefinerte baner** (bevisst utsatt fra
     tee-rundens status-notat) — `hole`-tabellen har ALDRI hatt noen vei inn
     for custom-baner, som blokkerte `stroke`-scoringsmodus helt (`hole_
     result`-modus trenger den ikke). Ny `GET/POST /orgs/{id}/courses/{id}/
     holes` i `app/routers/courses.py` — engangs alle-18-på-en-gang
     (avviser feil antall, avviser hvis banen allerede har hull, avviser på
     offisielle baner som får hullene sine fra teeoff-import).
  2. **`GET scorecard` viste kun UTLEDET vinn/tap/delt per hull, aldri de
     faktiske tallene som var registrert** — umulig å bygge en skjerm som
     viser gjeldende tilstand ved gjenlasting. Utvidet `Scorecard`-modellen
     i `app/routers/scoring.py` med `stroke_entries`/`hole_result_entries`
     (rå `hole_score`/`match_hole_result`-rader, nøyaktig ett av de to fylt
     ut avhengig av øktens scoring_mode).
  **Verifisert grundig i scratch:** hull-validering (feil antall avvist,
  gjentatt oppsett avvist), og en FULL `stroke`-modus scoringsrunde med
  ekte handicap-justert nettoberegning på en egendefinert bane for FØRSTE
  gang noensinne (ulikt slagtall — 4 mot 5 — ga korrekt "halved" etter
  handicap-utjevning), scorecard sin nye `stroke_entries` bekreftet å
  returnere nøyaktig det som ble registrert. `test_isolation.sql` 12/12.
  **Rullet ut live**, ingen migrasjon, kun `teecup_api` redeployet,
  `teeoff.no` upåvirket.

- **Scorekort-skjermen LIVE (2026-07-18):** åttende V0-skjerm,
  `components/session-scorecard.tsx`, ny rute `/tournaments/[id]/sessions/
  [sessionId]/matches/[matchId]`. Ett hull i fokus om gangen (banebruk,
  ikke et regneark) — store slag-steppere for `stroke`-modus, tre-valgs
  vinner-knapper for `hole_result`-modus, hull-chip-navigasjon, kollapsbar
  full oversikt, feiret "avgjort"-banner som låser alt til read-only.
  Blind draw sin avslørte visning lenker nå til hver match sitt scorekort.
  **Ingen nye backend-hull denne runden** — forrige rundes forarbeid
  (hull-endepunkter + `stroke_entries`/`hole_result_entries` i scorecard)
  dekket akkurat det skjermen trengte.
  **Verifisert grundig i scratch, inkludert et fullt oppsett som speiler
  NØYAKTIG frontend-ens egen last-sekvens** (sessions→teams→matches→
  holes→scorecard, deretter en ekte `POST hole-scores` for begge spillere
  på hull 1 og en refetch): status_text/derivert resultat oppdaterte seg
  korrekt ("1 UP (A)", hull 1 → "a"), alle feltnavn stemte eksakt med
  TypeScript-typene uten justering. `test_isolation.sql` 12/12, ekte
  typesjekket build.
  **Rullet ut live**, ren frontend-endring, `teeoff.no` upåvirket.

- **Leaderboard-backend LIVE (2026-07-18):** ny `GET /orgs/{id}/
  tournaments/{id}/leaderboard` i `app/routers/tournaments.py` — summerer
  poeng på tvers av ALLE økter/matcher i turneringen, både total og
  per-økt-delsum.
  **Reelt korrekthetshull funnet OG designet rundt FØR koden ble skrevet,
  ikke oppdaget i ettertid:** `match.team_a_id`/`team_b_id` settes PER
  MATCH ved opprettelse, ikke garantert konsistent på tvers av matcher —
  en organisator kunne i prinsippet opprettet match 1 med team_a=Rød og
  match 2 med team_a=Blå. En naiv summering av `points_side_a`/`points_
  side_b` ville da blandet sammen poeng fra to ULIKE fysiske lag. Løst ved
  å ALDRI summere på "a"/"b"-labelen — kun på det ekte lag-id-et
  (`points_by_team: dict[team_id, float]`, både i totalen og per økt).
  **Verifisert presist, ikke bare "kjørte uten feil":** bygget et scratch-
  scenario med 3 matcher over 2 økter der match 2 sin team_a/team_b
  BEVISST var byttet om i forhold til de to andre — satte poeng direkte
  (Rød vinner alle tre, ett delt) og bekreftet at leaderboardet likevel ga
  riktig total (Rød 2.5, Blå 0.5) og riktig per-økt-delsum, til tross for
  swap-en. `test_isolation.sql` 12/12. Ingen migrasjon, kun `teecup_api`
  redeployet, `teeoff.no` upåvirket. Frontend-skjermen gjenstår.

- **Leaderboard-skjermen LIVE (2026-07-18), samme dag:** niende og siste
  V0-skjerm i "bygg i rekkefølgen ting brukes"-serien for kamp-play-flyten.
  `components/tournament-leaderboard.tsx`, ny rute `/tournaments/[id]/
  leaderboard`. Stort scoreboard-kort med de to lagenes totalpoeng
  (lederen fremhevet), pluss en per-økt poeng-fordelingsliste med
  fullført/ikke-startet-status. V0 la selv til et tredje faneelement
  ("Leaderboard") i BÅDE program- og roster-skjermens fanerad denne
  runden — portert inn i de LIVE versjonene av begge (med riktig `org`-
  parameter, som V0s eksport som vanlig manglet).
  **Ingen nye backend-hull** — forrige rundes leaderboard-endepunkt dekket
  akkurat det skjermen trengte.
  **Verifisert i scratch:** full datamodell-runde (samme felt-for-felt
  som backend-verifiseringen dagen før) OG et eget tomtilstand-scenario
  (fersk turnering med 2 lag, 0 økter — `sessions: []`, `matches_total: 0`)
  for å bekrefte at "ingen økter opprettet ennå"-meldingen vises riktig
  i stedet for å krasje på et tomt array. `test_isolation.sql` 12/12, ekte
  typesjekket build.
  **Rullet ut live**, ren frontend-endring, `teeoff.no` upåvirket.
  **Hele "bygg i rekkefølgen ting brukes"-serien for match-play-flyten er
  dermed komplett:** oppsett (lag/roster) → program → blind draw →
  scorekort → leaderboard.
- **Offisiell bane-import: idempotent + tydeligere navn, LIVE (2026-07-18),
  rapportert av brukeren som faktisk brukte funksjonen på ekte
  produksjonsdata:** to reelle problemer, begge funnet ved å lese (kun
  lesing) de faktiske dataene for "De Gamle er Eldst" FØR noe ble antatt.
  1. **`POST .../courses/official-import` var IKKE idempotent** — å
     importere samme bane på nytt (helt vanlig: flere økter spilles ofte
     på samme bane) ga en 409 `DUPLICATE`-feil (migrasjon 010 sin sperre)
     i stedet for å bare gi tilbake den allerede importerte banen. Fikset:
     sjekker nå `external_course_ref` FØR noe teeoff-kall gjøres — finnes
     banen fra før, returneres den eksisterende raden direkte (også
     raskere, og robust mot at teeoff er nede akkurat da).
  2. **Lagret navn var kun selve banens navn ("Hovedbanen"), ikke hvilken
     klubb** — ubrukelig til å skille baner fra hverandre, siden mange
     klubber navngir hovedbanen sin identisk. Fikset: navnet kombineres nå
     til "{anlegg} – {bane}" (f.eks. "Tjøme Golfklubb – Hovedbanen") ved
     import.
  **Reell konsekvens av hull #1 funnet i produksjonsdata:** brukeren hadde,
  mens hen forsøkte å søke opp Tjøme via det ØVERSTE banefeltet (som søker
  organisasjonens EGNE baner, ikke teeoff), ved et uhell trigget «Opprett
  ny bane: «Tj»»-snarveien og fått en tom, søppel `custom`-bane hengende på
  Foursome-økten -- en ekte forvekslingsfelle mellom de to adskilte
  bane-søkeflatene (eget vs. teeoff), ikke en kodefeil i seg selv.
  **Data ryddet opp i EKTE `teecup_db`, bruker bekreftet eksplisitt:**
  Foursome-økten pekt om til den allerede importerte, ekte Tjøme-banen
  (samme bane som Fourball-økten allerede brukte -- nøyaktig det
  organisatoren egentlig ønsket), søppel-«Tj»-banen slettet (bekreftet
  ingen matcher/tee-er/hull hang på den FØR sletting), og den ekte banens
  navn oppdatert til "Tjøme Golfklubb – Hovedbanen". Verifisert i etterkant
  at begge økter nå peker til samme, korrekt navngitte bane.
  **Verifisert mot ekte teeoff_api i scratch FØR utrulling:** importerte
  Borregaard på nytt to ganger — andre kallet ga nøyaktig samme course-id
  (ikke en duplikat-rad), navnet kom ut som "Borregaard Golfklubb –
  Hovedbanen". `test_isolation.sql` 12/12. Ingen migrasjon, kun `teecup_api`
  redeployet, `teeoff.no` upåvirket.
- **`PATCH`/`DELETE` for økter, LIVE (2026-07-18), samme dag:** brukeren
  spurte rett etter opprydningen om det i det hele tatt var mulig å
  rette/slette en feiloppsatt økt — det var det ikke (kun `POST`/`GET`
  fantes). Ny `PATCH /orgs/{id}/sessions/{id}` (`app/routers/
  tournaments.py`) for enkle felt (navn, klokkeslett/intervall, starthull,
  poeng, handicap-brytere) via vanlig `exclude_unset`-mønster, PLUSS en egen
  gren for bane-bytte. Ny `DELETE /orgs/{id}/sessions/{id}` — kun tomme
  økter (ingen matcher), avviser med 409 ellers (bruk PATCH til å korrigere
  i stedet).
  **Banebytte-scenarioet brukeren selv reiste** ("5 hull spilt, oppdager
  feil bane — slagene er ekte, utregningen er trolig feil") krevde egen
  design: `match_participant.tee_id` peker til en tee som HØRER til den
  gamle banen. Løst med `_remap_course()` — finner en tee med samme
  navn+kjønn på den nye banen for hver allerede tillagte deltaker, flytter
  dem dit, og avviser HELE bane-byttet tydelig (400, ingenting skrevet,
  bekreftet transaksjonell rollback) hvis den nye banen mangler en
  tilsvarende tee. Etter et vellykket bytte: handicap regnes om for alle
  berørte deltakere, og matchstatus/poeng regnes om for HVER match i
  økten — **bevisst uavhengig av om matchen allerede er avgjort** (brukeren
  bekreftet eksplisitt at en bane-korrigering skal kunne endre et allerede
  cachet resultat). `recompute_and_cache_match_state` i `app/routers/
  scoring.py` gjort delt (fjernet ledende understrek) for gjenbruk fra
  tournaments.py.
  **Reelt, urelatert funn underveis i scratch-testingen, IKKE fikset:**
  `tee_rating` lages i dag ALLTID kun med `full_18`-omfang (både ved
  teeoff-import og manuell tee-opprettelse) — en økt satt til `front_9`/
  `back_9` i `stroke`-modus kan derfor ALDRI få handicap beregnet
  (`compute_and_store_side_handicaps` sin `tee_rating`-join finner aldri
  noen rad), og dermed aldri avgjøre noen hull. `hole_result`-modus
  upåvirket. Flagget til bruker, bevisst latt urørt denne runden.
  **Verifisert grundig i scratch:** enkelt feltbytte (kun navn), fullt
  banebytte-scenario bygget nøyaktig som brukerens eksempel (10 hull spilt
  under feil bane, matchen allerede avgjort 10&8, PATCH til riktig bane →
  tee-er ombyttet korrekt, handicap endret fra 7/9 til 10/13 under den nye
  banens rating, matchstatus regnet på nytt med UENDREDE rå slagtall),
  avvist bane-bytte ved manglende tee-match (bekreftet full rollback,
  også av det urelaterte navnefeltet i samme kall), DELETE avvist på økt
  med match (409) og godtatt på tom økt (204). `test_isolation.sql` 12/12.
  Ingen migrasjon, kun `teecup_api` redeployet, `teeoff.no` upåvirket.
  Frontend (rediger-/slett-knapper i program-skjermen) ikke bygget ennå —
  kun backend-kapasiteten denne runden.
- **Rediger/slett-UI for økter LIVE (2026-07-19):** V0-utvidelse av den
  eksisterende Program-skjermen (ingen ny rute) — "..."-meny (samme
  DropdownMenu-mønster som roster-skjermens per-spiller-handlinger) med
  "Rediger"/"Slett" per øktkort. Rediger bytter kortet til et inline-skjema
  (samme felt som PATCH støtter: navn, poeng, starthull, klokkeslett/
  intervall, bane). Slett viser en bekreftelse; treffer den ekte 409-en
  (økt har matcher), vises backend sin egen feiltekst i stedet for en
  forhåndsberegnet klient-tilstand.
  **Reell regresjon funnet OG UNNGÅTT i selve V0-eksporten, ikke i
  etterkant:** denne rundens V0-prompt handlet kun om rediger/slett, men
  eksporten hadde samtidig (utilsiktet) FJERNET bane-feltet fra "Legg til
  økt"-skjemaet helt — nye økter ville stille blitt satt til en hardkodet
  mock-bane. Fanget under diff-mot-live-treet FØR noe ble tatt inn (samme
  rutine som alltid) — `CreateSessionCard` (med sitt ekte bane-søk/
  teeoff-import) beholdt fullstendig urørt; kun de nye rediger/slett-
  delene ble hentet inn.
  **Bane-bytte i redigeringsskjemaet er bevisst ENKLERE enn opprett-
  skjemaets bane-felt** — kun velg blant organisasjonens eksisterende
  baner eller hent fra teeoff, INGEN "opprett ny bane: X"-snarvei her
  (PATCH sin `course_id` må være en ekte, allerede eksisterende bane, ikke
  en tekststreng) — unngår at samme "Tj"-forvekslingsfelle fra forrige
  banebytte-hendelse kan gjenta seg via redigeringsveien.
  **Verifisert:** ekte PATCH med nøyaktig skjemaets feltform, ekte DELETE
  (204 tom økt, 409 med matcher — bekreftet at `{"detail":{"code",
  "message"}}`-formen leses riktig av UI-et), `test_isolation.sql` 12/12,
  ekte typesjekket build. Rullet ut live, ren frontend-endring, `teeoff.no`
  upåvirket.

- **Invitasjonskode + ledende side + projisert stilling, BACKEND LIVE
  (2026-07-19, ADR-020):** brukeren reiste tre relaterte hull rett etter at
  "bygg i rekkefølgen ting brukes"-serien var ferdig: (1) ingen vei inn til
  en turnering for en spiller som bare har fått muntlig beskjed, (2)
  leaderboardet viser kun faktisk opptjente poeng, ikke hva stillingen ville
  blitt om pågående matcher holder seg, (3) ingen fargekoding i matchlister
  for hvem som leder. Full ADR-020 skrevet (4 delbeslutninger, se
  ARCHITECTURE_DECISIONS.md) — nøkkelbeslutning bekreftet eksplisitt av
  bruker FØR bygging: en invitasjonskode OVERSTYRER `tournament.visibility`
  helt (koden ER selve invitasjonen, ikke en snarvei som fortsatt krever
  eksisterende tilgang).
  Ny migrasjon `011_join_code_and_leading_side.sql`: `tournament.join_code`
  (6 tegn, alfabet uten 0/O/1/I, globalt unikt, backfylt for eksisterende
  rader), `match.leading_side` (cachet fortegn av `MatchState.lead`, samme
  mønster som `status_text`/`points_side_a/b`), fjerde
  `SECURITY DEFINER`-bro `public_tournament_by_code()` (etter
  `public_tournament_org` 007, `link_player_by_email` 008,
  `public_org_by_slug` 009).
  **Backend bygget:** `create_tournament` genererer koden (retry-løkke ved
  kollisjon, astronomisk usannsynlig med 33^6 kombinasjoner). Ny
  `GET /public/tournaments/by-code/{code}` (MÅ registreres FØR
  `/{tournament_id}` i routeren, ellers tolkes "by-code" som en ugyldig
  UUID). `GET /public/tournaments/{id}`, `GET .../sessions` og
  `POST .../register` godtar alle en valgfri `code`-parameter som — når den
  matcher — hopper `_check_visibility()` helt over.
  `recompute_and_cache_match_state` (scoring.py) cacher nå `leading_side`
  ved HVER hull-innsending, ikke bare ved avgjørelse. Leaderboard-
  endepunktet fikk `projected_points`/`projected_points_by_team`:
  avgjorte matcher bidrar likt til faktisk og projisert, ikke-avgjorte gir
  hele `points_per_match` til `leading_side` (delt 0,5/0,5 ved "AS"/ikke
  startet) — speiler hvordan Ryder Cup-TV-dekning viser "hvis det sluttet
  nå".
  **Reell hendelse underveis, håndtert transparent (ikke skjult):** en
  feilformulert `docker exec teeoff_db env | grep -i POSTGRES`-kommando
  (ment å liste variabelNAVN) fanget opp `POSTGRES_PASSWORD` sin VERDI også,
  siden selve nøkkelnavnet matchet søkemønsteret — eksponerte `teeoff_db`
  sitt superbruker-passord (`teeoff_admin`) i verktøyresultatet. Alvorligere
  enn de to tidligere passord-hendelsene i prosjektet siden dette er
  superbrukeren for HELE den delte Postgres-klyngen (teeoff OG teecup), ikke
  en enkelt tjeneste-credential. Flagget til bruker umiddelbart, som valgte
  å rotere. Rotert trygt UTEN å noensinne re-eksponere gammel ELLER ny verdi
  i noe synlig kommandoresultat: `ALTER ROLE` kjørt via lokal
  Unix-socket-`trust`-auth (bekreftet ved å lese `pg_hba.conf`, ingen
  hemmelighet involvert i den sjekken) — krevde altså IKKE det gamle
  passordet i det hele tatt. Nytt passord generert med `openssl rand -hex
  32` (hex, ikke base64 — unngår SAMME klasse URL-enkodings-felle som
  `TEECUP_DATABASE_URL`-hendelsen tidligere, siden verdien også ligger i en
  `postgres://`-DSN). `/opt/teeoff/.env` sine TO forekomster
  (`POSTGRES_PASSWORD` og `DATABASE_URL`) oppdatert med `sed`-mønstre som
  ALDRI leser/skriver ut den gamle verdien. `teeoff_api`/`teeoff_worker`
  service-nøklene i `docker-compose.prod.yml` viste seg å hete `api`/
  `worker` (ikke `teeoff_api`/`teeoff_worker` — det er kun
  `container_name`), samme "service-nøkkel ≠ container-navn"-fallgruve som
  nettverksalias-hendelsen fra containeriseringsrunden. `docker compose up
  -d --force-recreate api worker` gjenskapte OGSÅ `teeoff_db` selv (ikke
  eksplisitt navngitt) — Compose oppdager konfigurasjonsendring
  (`${POSTGRES_PASSWORD}` i `db`-tjenestens egen `environment:`) og
  gjenskaper uansett hvilke tjenester som ble navngitt. Verifisert grundig
  ETTERPÅ: `teeoff_db`-loggen viste "Skipping initialization" (datavolum
  urørt, ikke reinitialisert) + ren oppstart, `teeoff_api`/`teeoff_worker`
  ren oppstart uten en eneste feil-/auth-/passord-linje i hele loggen,
  `teeoff.no` OG `teecup.teeoff.no/health` begge `200` etterpå.
  **Scratch-verifisert grundig** (fersk `teecup_scratch` 001→011,
  isolert `teecup_app_scratch`-rolle, isolert scratch-MinIO, engangs
  API-container): `test_isolation.sql` 12/12 (måtte først rettes — tre
  RÅ `INSERT INTO tournament`-steder i selve testfilen predaterte
  `join_code` og traff den nye NOT NULL-constrainten, rettet med
  dummy-koder). Full ende-til-ende-runde: to turneringer opprettet, ulike
  koder bekreftet; `by-code`-oppslag bekreftet for kjent OG ukjent kode
  (404); anonym lesing av en `org`-synlig turnering BLOKKERT uten kode
  (403 NOT_VISIBLE), TILLATT med riktig kode (inkl. case-insensitivt),
  FORTSATT blokkert med feil kode; samme mønster bekreftet for
  `POST .../register`. Full hull-for-hull-simulering av en singel-match
  (hole_result-modus): `leading_side`/`status_text` fulgte hverandre
  eksakt gjennom "1 UP (A)" → "AS" (leading_side=null) → avgjort "9&7
  (A)", leaderboardets `projected_points` traff nøyaktig 1.0/0.0 mens A
  ledet, 0.5/0.5 ved "AS", og ble likt `points`/`projected_points` (begge
  1.0/0.0) etter avgjørelse.
  **Rullet ut mot ekte `teecup_db` 2026-07-19**, bruker bekreftet
  eksplisitt: migrasjon 011 kjørt (eneste eksisterende turnering fikk
  automatisk generert kode), `test_isolation.sql` fortsatt 12/12, kun
  `teecup_api` redeployet (ingen frontend-endring i denne del-runden),
  `teeoff.no` upåvirket.
  **Frontend fullført samme dag, egen del-runde:** `login-form.tsx` fikk et
  eget kode-modus (`JoinByCode`) — «Har du en invitasjonskode?»-lenke bytter
  ut e-post-skjemaet, slår opp `/public/tournaments/by-code/{code}` og
  navigerer til `/t/{id}?code=...` med Next sin `useRouter`. `code`
  query-param tres gjennom hele veien: `app/t/[id]/page.tsx` leser
  `searchParams`, `public-tournament.tsx` sender den med på BÅDE
  info-/sessions-lesingen og selve `POST .../register` (ikke bare det
  første oppslaget som tok deg dit).
  `tournament-detail.tsx` viser koden i en egen kopier-chip i headeren —
  ingen enkelt-turnering-`GET` fantes, så komponenten henter i stedet hele
  org-ens turneringsliste (som allerede bærer `join_code`) og finner egen
  rad, i stedet for å legge til et nytt endepunkt kun for dette.
  `tournament-leaderboard.tsx` fikk en ny `SegmentedBar`-komponent — ETT
  fargesegmentert rektangel per bar (ikke tall side om side), proporsjonalt
  med hvert lags poeng, 50/50 nøytralt ved 0-0. To slike bares rett under
  headeren: "Stilling nå" (faktisk) og "Projisert (hvis pågående matcher
  holder seg)" — den EKSISTERENDE store tall-scoreboarden beholdt uendret
  lenger ned som detaljvisning.
  `session-blind-draw.tsx` sin `RevealedView`: matchkortet får nå en farget
  toppkant (leaderens `team.color`) og en `status_text`-chip (fylt farge
  ved avgjort match m/ konfetti-ikon, lys tone ved pågående) i stedet for
  kun klokkeslettet; `RevealSide` for ledende side får en svak fargetonet
  bakgrunn. `leading_side`/`status_text`/`points_side_a/b` lagt til
  `ApiMatch`-typen (var der allerede i API-et, bare ikke konsumert
  frontend-siden før nå).
  **Verifisert:** ekte typesjekket produksjonsbuild (samme `Dockerfile`
  som deployes, ikke dev-server) kompilerte rent, alle 10 ruter listet.
  Rullet ut (kun `teecup_frontend`, ingen backend-endring i denne delen),
  `teecup.teeoff.no/dashboard` og `/` → 200, `teeoff.no` upåvirket. Ekte
  smoke-test i produksjon: `by-code`-oppslag for "De Gamle er Eldst" sin
  faktiske kode ga riktig turnering-id, `/t/{id}?code=...` ga 200.
  **ADR-020 er dermed helt ferdig** (backend + frontend, alle fire
  del-ønsker: kode-basert oppdagelse, kode-felt på login, projisert
  stilling, fargekoding av matcher) — bortsett fra kode-regenerering, som
  er bevisst utsatt (se FEATURE_BACKLOG.md).
  **Reell driftshendelse underveis** (mellom backend- og frontend-delen,
  under scratch-oppsett): en feilformulert `grep -i POSTGRES`-kommando
  eksponerte `teeoff_db` sitt superbruker-passord ved et uhell. Flagget
  umiddelbart, brukeren valgte å rotere — se detaljene under
  backend-avsnittet over for hele hendelsen og hvordan roteringen ble
  gjennomført uten å noensinne re-eksponere gammel eller ny verdi.
- **Sesjons-bug diagnostisert og FIKSET, LIVE (2026-07-19):** brukeren
  rapporterte at hen måtte be om ny magic-link-kode ved HVERT besøk til
  `teecup.teeoff.no`, til tross for ADR-009s 30-dagers sesjonscookie. Bad
  brukeren sjekke den EKTE cookien i nettleseren fremfor å gjette — kom
  tilbake korrekt satt i alle henseender (`Expires` 30 dager frem,
  `Secure`/`HttpOnly`/`SameSite=Lax`). Rot-årsaken var derfor IKKE cookien
  eller backend-en: `frontend/app/page.tsx` (rot-siden) viste ALLTID
  innloggingsskjemaet uten noensinne å sjekke om en gyldig sesjon allerede
  fantes. `Dashboard`-komponenten sjekker `/auth/me` og sender til `/` ved
  MANGLENDE sesjon, men ingen kode gjorde det motsatte — en bruker som
  besøkte roten direkte (i stedet for å navigere til `/dashboard`) så
  derfor alltid innloggingsskjemaet uansett sesjonsstatus.
  **Fikset:** `page.tsx` gjort om til en async server-komponent som leser
  sesjonscookien via `next/headers`, kaller `/auth/me` server-til-server
  direkte mot `TEECUP_API_ORIGIN` (samme mønster som `generateMetadata` i
  `app/t/[id]/page.tsx` — IKKE gjennom `next.config.mjs` sin `rewrites()`,
  som kun gjelder nettleser-trafikk), og sender en allerede innlogget
  bruker videre til `/dashboard` med `redirect()` FØR innloggingsskjemaet
  når rendres.
  **Verifisert presist mot den ekte, live stacken, med brukerens EGEN
  ekte sesjonscookie** (ikke en syntetisk test): `curl` uten cookie mot
  `https://teecup.teeoff.no/` ga `200` (skjemaet vises, riktig for en
  anonym besøkende); samme kall MED den ekte cookien ga `307` til
  `/dashboard` (riktig — sender en allerede innlogget bruker rett videre).
  Ekte typesjekket produksjonsbuild kjørt FØR utrulling (build-outputet
  viste selv at `/` nå er `ƒ` dynamisk i stedet for `○` statisk — bekrefter
  at server-sjekken faktisk ble tatt i bruk). Rullet ut live, kun
  `teecup_frontend`, ingen migrasjon, `teeoff.no` upåvirket.
  **Samme runde:** brukeren stilte to oppfølgingsspørsmål om
  autentisering/autorisasjon — «er flere-organisasjoner-eierskap tenkt
  gjennom» (bekreftet: ja, ADR-002 fra dag én, ingen kodeendring nødvendig)
  og et ønske om passord (valgfritt tillegg)+2FA. Fullt design skrevet som
  **ADR-021** (passord/2FA) og **ADR-022** (dele/invitere/frasi seg
  eierskap + superadmin) — se ARCHITECTURE_DECISIONS.md.
- **ADR-021 (passord/2FA) + ADR-022 (org-eierskap) BYGGET OG LIVE
  (2026-07-19), samme dag:** brukeren ba om begge sammen («Bygg det»,
  bekreftet eksplisitt at det gjaldt begge ADR-ene i samme runde). Ny
  migrasjon `012_password_2fa_and_org_invitations.sql`: `app_user.
  password_hash`/`two_factor_method`/`totp_secret`/`is_super_admin`, ny
  tabell `two_factor_code` (samme hash-og-utløp-mønster som
  `magic_link_token`), ny tabell `organization_invitation` (RLS
  org-isolert, INGEN egen klikkbar aksept-lenke — godtas automatisk ved
  neste innlogging med matchende e-post), femte
  `SECURITY DEFINER`-bro `accept_pending_invitations_by_email()` (etter
  `public_tournament_org` 007, `link_player_by_email` 008,
  `public_org_by_slug` 009, `public_tournament_by_code` 011).
  **Sesjons-STADIER innført i `app/auth.py`:** en sesjonscookie er ikke
  nødvendigvis en full sesjon lenger — `create_session_token()` tar nå en
  `stage`-parameter (`full`/`pending_2fa`/`must_enroll_2fa`), lagt inn som
  et JWT-claim. `get_current_user` avviser eksplisitt alt annet enn `full`
  ELLER en ELDRE token uten stage-claim i det hele tatt (utstedt før denne
  runden — behandlet som `full` for bakoverkompatibilitet, ingen
  eksisterende bruker logget brått ut). To nye avhengigheter:
  `get_pending_user` (kun for 2FA-verifiseringsendepunktene) og
  `get_current_or_enrolling_user` (godtar BÅDE en full sesjon — frivillig
  2FA-oppsett fra kontoinnstillinger — OG `must_enroll_2fa` — tvunget
  oppsett rett etter innlogging — samme oppsett-logikk dekker begge
  veiene). `get_current_user_optional` fikk samme stage-sjekk for
  konsistens.
  **Passord (Argon2id, ikke bcrypt):** bevisst valg for å unngå bcrypt sin
  stille 72-byte-trunkering, siden brukeren eksplisitt ba om korrekt
  håndtering av spesialtegn/mellomrom. `POST /auth/set-password`/
  `/remove-password`/`/login-password` — sistnevnte svarer med IDENTISK
  401 uansett om e-posten finnes, mangler passord, eller passordet er
  feil (samme anti-enumerering som magic-link).
  **2FA (TOTP via `pyotp` ELLER e-post-engangskode via eksisterende SMTP,
  brukerens eget valg):** `POST /auth/2fa/setup/start` genererer en
  TOTP-secret UTEN å lagre den (rundturer til klienten, som ekkoer den
  tilbake i `/setup/confirm` — unngår en halvferdig 2FA-tilstand i
  databasen hvis brukeren forlater oppsettet). QR-kode generert
  server-side (`qrcode`-biblioteket + eksisterende Pillow-avhengighet,
  ingen ny ekstern tjeneste). `POST /auth/2fa/verify` fullfører en
  PÅGÅENDE innlogging.
  **Tvungen 2FA for org-eier/admin (ADR-021 Beslutning D):**
  `user_requires_2fa_enrollment()` sjekket ved HVER innlogging (ikke bare
  første gang, siden en bruker kan bli eier av en NY org etter at kontoen
  allerede eksisterer uten 2FA) — verifisert eksplisitt: en fersk
  org-eier uten 2FA ble korrekt blokkert fra all normal tilgang (401) og
  tvunget inn i oppsett-flyten før noe annet ble tilgjengelig.
  **Organisasjonseierskap (ADR-022):** `POST/GET/DELETE
  /orgs/{id}/invitations` (owner→enhver rolle, admin→KUN member — ellers
  en privilegie-eskaleringsvei), `PATCH/DELETE /orgs/{id}/memberships/
  {id}` (owner kan endre/fjerne hvem som helst; en bruker kan ALLTID
  SENKE egen rolle selv — aldri heve den, ville vært selv-forfremmelse —
  og alltid forlate selv), «siste eier»-vern (409 `LAST_OWNER`, `FOR
  UPDATE`-lås mot race på alle eier-rader, samme TOCTOU-mønster som
  ADR-011s to-lags-grense). Superadmin (`app_user.is_super_admin`, KUN
  manuelt DB-tildelt — bevisst INGEN API-vei til å gi seg selv eller
  andre flagget) får en parallell autorisasjonssti
  (`get_superadmin_user`) som kan sette medlemskap på ENHVER org,
  uavhengig av eget medlemskap — bevisst avgrenset til nøyaktig dette,
  ikke generell tilgang til andres turnering-/spillerdata.
  **Tre reelle bugs funnet OG fikset UNDER scratch-testing, ingen nådde
  produksjon:**
  1. `verify_magic_link` sendte en rå asyncpg-`UUID` (ikke streng) videre
     til sesjonsutstedelse — `jwt.encode()` sin JSON-serialisering
     krasjet rått (500) på selve innloggingen. Fant umiddelbart ved første
     reelle innloggingstest. Rettet med en eksplisitt `str()`.
  2. OG 3. Både `2fa/setup/confirm` og `2fa/verify` kalte først den delte
     `_issue_login_result()`-hjelpefunksjonen (ment for PRIMÆR
     autentisering) EN GANG TIL etter at 2FA nettopp var bekreftet — som
     så (korrekt, men feil kontekst) at `two_factor_method` nå var satt
     og krevde EN NY runde med 2FA for akkurat den samme innloggingen,
     en uendelig løkke. Fant ved å faktisk fullføre hele innloggings-
     syklusen med ekte genererte TOTP-koder (`pyotp` i test-scriptet),
     ikke bare ved å lese koden. Rettet ved at begge endepunktene nå
     utsteder en full sesjon DIREKTE etter vellykket 2FA-bekreftelse,
     ikke via gjenbruk av den generelle sjekken.
  **Frontend:** `login-form.tsx` fikk en tredje modus (passord, ved siden
  av magic-link og ADR-020s invitasjonskode-modus). Ny delt
  `two-factor-flow.tsx` (`TwoFactorVerifyForm`/`TwoFactorSetupForm`),
  brukt av BÅDE `login-form.tsx` og `verify-form.tsx` siden begge
  primær-autentiseringsveiene kan returnere samme 2FA-mellomtilstand. Ny
  `/account`-skjerm (sett/fjern passord, aktiver/deaktiver 2FA) og ny
  `/orgs/[id]/members`-skjerm (invitere, endre rolle, fjerne/forlate),
  begge lenket fra dashbordets header/org-visning. `next.config.mjs` sin
  `rewrites()` utvidet med `/superadmin/:path*` (ADR-016s konsekvens for
  enhver ny API-prefiks, selv om ingen frontend-UI faktisk bruker den
  ennå).
  **Verifisert grundig mot fersk `teecup_scratch`** (001→012,
  `test_isolation.sql` 12/12): full magic-link-bakoverkompatibilitet
  (eksisterende flyt uendret for brukere uten 2FA), passord med ekte
  spesialtegn/mellomrom/æøå satt og brukt til pålogging, full TOTP-runde
  (oppsett→bekreft→logg ut→logg inn→krev 2FA→verifiser med ekte
  `pyotp`-generert kode), full e-post-2FA-runde (samme mønster, feil kode
  avvist, kode ikke gjenbrukbar), tvungen 2FA-registrering for ny
  org-eier, invitasjon→auto-aksept ved førstegangsinnlogging,
  rolle-eskalering-forsøk avvist på tre distinkte måter (medlem kan ikke
  invitere, admin kan ikke gi eierskap, bruker kan ikke forfremme seg
  selv), siste-eier-vern (både PATCH og DELETE), duplikat-invitasjon
  avvist, superadmin-sti fungerer/avvises riktig i begge retninger. Ekte
  typesjekket produksjonsbuild av frontend (alle nye ruter listet).
  **Rullet ut mot ekte systemer 2026-07-19**, bruker bekreftet eksplisitt:
  migrasjon 012 kjørt mot ekte `teecup_db`, `test_isolation.sql` fortsatt
  12/12, begge containere (`teecup_api`, `teecup_frontend`) redeployet og
  bekreftet ren oppstart, `/health` og `/dashboard` fortsatt 200 (eksisterende
  sesjoner uendret av stage-bakoverkompatibiliteten), `/auth/login-password`
  bekreftet nåbart over ekte https, `teeoff.no` upåvirket.
  **ADR-021 og ADR-022 er dermed begge helt ferdig** — backend + frontend.
  Bevisst utenfor omfang: dedikert superadmin-UI (brukes via API av en
  betrodd operatør), SMS som 2FA-metode.

- **Program-skjerm: tydeligere klikk-hint på øktkort (2026-07-19):** brukeren
  påpekte at ingenting i grensesnittet indikerte at et øktkort er klikkbart
  inn til blind draw-skjermen. Lagt til en synlig "Sett opp flights og lås
  oppstilling →"-rad nederst i hvert kort (`components/tournament-program.tsx`).
  Ren frontend-endring, ingen backend-rørt.
- **Brukerroller: kaptein som reell autorisasjon, deltaker-avgrenset scoring
  (2026-07-19, ADR-023):** direkte oppfølging av det lenge åpne
  "Brukerroller"-punktet i FEATURE_BACKLOG.md. Fire beslutninger avklart
  eksplisitt med bruker (AskUserQuestion) før bygging — alle anbefalte valg.
  **Bygget:** `app/team_authz.py` skrevet om — `user_is_team_captain`
  (erstatter `user_may_act_for_team`) krever `is_captain=true` på
  `team_roster` (eller org-eier/admin) for å legge til/fjerne deltakere og
  låse et lag (`matches.py`); ny `user_is_match_participant` krever en ekte
  `match_participant`-rad for brukeren i AKKURAT den matchen (valgfritt
  side-spesifikk via `team_side`) for å føre/korrigere score (`scoring.py`)
  — uavhengig av kapteinmerket. Nye feilkoder `NOT_TEAM_CAPTAIN` og
  `NOT_MATCH_PARTICIPANT` (erstatter `NOT_ROSTERED_ON_TEAM` på disse fem
  stedene). `app/routers/tournaments.py` sin `PATCH`/`POST .../roster`
  håndhever nå "kun én kaptein per lag" (fjerner automatisk forrige
  kapteins merke i samme transaksjon).
  **Reelt funn FØR utrulling, ikke antatt:** sjekket (kun lesing, superbruker
  mot ekte `teecup_db`) om noen eksisterende lag ville blitt låst ute av en
  ren kaptein-only-regel — "De Unge" i "De Gamle er Eldst" har i dag 0 av 2
  roster-rader merket kaptein. Designet derfor en bevisst fallback i
  `user_is_team_captain`: har laget INGEN utpekt kaptein ennå, godtas enhver
  rostret spiller i stedet for å låse laget helt ute. Ingen lag hadde flere
  kapteiner, så "kun én kaptein"-håndhevelsen krevde ingen data-opprydning.
  **Reell bug funnet OG fikset UNDER scratch-testing:** `user_is_match_
  participant` sin SQL sammenlignet `mp.team_side` (enum-kolonne) direkte
  mot en tekst-parameter uten cast når `team_side=None` (hole_result-modus)
  — ga en rå 500 (`UndefinedFunctionError: operator does not exist: team_side
  = text`). Rettet med et eksplisitt `mp.team_side::text = $3`.
  **Verifisert grundig mot fersk `teecup_scratch`** (isolert
  `teecup_app_scratch`-rolle, isolert scratch-MinIO, engangs API-container):
  et 15-punkts Python/httpx-testskript som simulerte fire innloggede
  brukere (organisator + tre rostrede spillere på to lag) gjennom hele
  syklusen — lag uten kaptein tillater enhver rostret (fallback bekreftet),
  kaptein utpekt fjerner andre rostredes rettighet, "kun én kaptein" bekreftet
  (ny kaptein avsetter automatisk forrige), org-admin fungerer uendret
  uavhengig av kaptein, og scoring (`hole_result`-modus) bekreftet begrenset
  til faktiske matchdeltakere (en kaptein som IKKE selv spiller matchen ble
  korrekt avvist med `NOT_MATCH_PARTICIPANT`, mens en faktisk deltaker og
  org-admin begge fikk føre score). Måtte også oppdage og legge til et
  forutsetning-steg underveis: `get_authorized_org` krever
  `organization_membership` for ALLE org-scopede endepunkter uansett — en
  rostret spiller må derfor også være invitert som org-medlem (minimum
  'member', ADR-022s invitasjonsflyt) for i det hele tatt å nå
  team_authz-vurderingen; ikke en bug, men en forutsetning testskriptet
  først manglet. `test_isolation.sql` 12/12 uendret (ingen skjemaendring).
  Ekte typesjekket produksjonsbuild av frontend (øktkort-hintet fra samme
  runde) kjørt og bekreftet, alle 11 ruter listet.
  **Rullet ut live 2026-07-19**, bruker bekreftet eksplisitt: ingen
  migrasjon, `docker compose up -d --build teecup_api teecup_frontend`,
  begge containere boot-et rent (`Application startup complete`, Next.js
  `Ready`), `/health` og `/dashboard` → 200, `teeoff.no` upåvirket.

- **Walkover/konsesjon LIVE (2026-07-19, ADR-024):** direkte oppfølging av
  Brukerroller-runden samme dag — brukeren ba eksplisitt om å ta fatt på
  dette som naturlig neste steg. Løser det lenge kjente hullet: en side som
  aldri stiller nok spillere fikk aldri beregnet handicap og matchen kunne
  derfor aldri avgjøres — hang uendelig.
  Fire beslutninger avklart eksplisitt med bruker (AskUserQuestion) før
  bygging — tre anbefalte valg, ett (omfang: match+turnering-nivå samtidig,
  ikke bare match) valgt utover anbefalingen.
  **Bygget:** ny `apply_concession`-hjelpefunksjon i `app/routers/
  scoring.py` (skriver til de samme fire kolonnene som
  `recompute_and_cache_match_state` -- `status_text`/`points_side_a/b`/
  `leading_side` -- men direkte, ikke utledet fra hull). Ny
  `POST /orgs/{id}/matches/{id}/concede` (kun kaptein for det TAPENDE laget,
  speiler ekte golf-etikette -- du gir bort DITT tap, krever ikke seier på
  motstanderens vegne -- eller org-admin, gjenbruker `user_is_team_captain`
  fra ADR-023 uendret). Ny `POST /orgs/{id}/tournaments/{id}/concede`
  (`app/routers/tournaments.py`) som gir opp ALLE ikke-avgjorte matcher
  laget har i turneringen i én operasjon -- v1s to-lags-grense (ADR-011)
  gjør dette trivielt (bare én motstander uansett), `FOR UPDATE`-låser alle
  berørte match-rader (samme race-vern som ellers). Kan erklæres uansett
  hvor mange hull som allerede er registrert (match-play teller kun
  seier/tap/delt for poeng, ikke marginen) -- allerede registrerte hull i
  `hole_score`/`match_hole_result` forblir urørt, kun matchens
  avgjørelses-felt endres.
  **Frontend:** `session-scorecard.tsx` fikk en kollapsbar
  "Gi opp matchen (walkover)"-seksjon (to knapper, én per lag, med
  bekreftelsessteg) synlig når matchen ikke er avgjort.
  `tournament-detail.tsx` sin `TeamPanel` fikk en tilsvarende "Gi opp resten
  av turneringen for laget"-knapp nederst i hvert lagkort. Ingen
  klientside-forhåndsfiltrering på kapteinstatus noe sted -- begge knappene
  vises alltid, en 403 fra backend vises bare som vanlig feiltekst (samme
  mønster som resten av appen).
  **Verifisert grundig mot fersk `teecup_scratch`** (isolert
  `teecup_app_scratch`-rolle, isolert scratch-MinIO, engangs
  API-container): to separate 15-punkts Python/httpx-testløp. Match-nivå:
  vinnende lags kaptein NEKTES å konsedere på vegne av det tapende laget
  (kan ikke kreve seier på andres vegne), tapende lags kaptein FÅR, allerede
  avgjort match avvist 409, fremmed team_id avvist 400, konsesjon ETTER at
  ett hull allerede er registrert bekreftet å fungere OG bekreftet at det
  registrerte hull-resultatet forblir synlig i scorekortet etterpå (ikke
  overskrevet), org-admin FÅR konsedere direkte uavhengig av kapteinmerke.
  Turnering-nivå: feil lags kaptein nektes, riktig kaptein FÅR gi opp
  resten (kun de faktisk ikke-avgjorte matchene telles -- allerede avgjorte
  matcher fra match-nivå-testene i samme løp ble korrekt hoppet over),
  gjentatt kall er trygt (0 nye, idempotent i praksis), ukjent team_id gir
  404. `test_isolation.sql` 12/12 uendret (ingen skjemaendring). Ekte
  typesjekket produksjonsbuild av frontend kjørt og bekreftet, alle 11
  ruter listet.
  **Rullet ut live 2026-07-19**, bruker bekreftet eksplisitt: ingen
  migrasjon, `docker compose up -d --build teecup_api teecup_frontend`,
  begge containere boot-et rent, `/health` og `/dashboard` → 200,
  `teeoff.no` upåvirket.

- **Turnering-status via API, SCRATCH-VERIFISERT (2026-07-19):** brukeren
  valgte dette som neste steg etter walkover/konsesjon-runden (fikk velge
  mellom denne lille opprydningen og å starte Kommunikasjon-runden). `status`
  (draft/active/completed/archived) har ligget i skjemaet siden migrasjon
  001, men INGEN endepunkt kunne endre det — kun `INSERT`-defaulten `'draft'`
  fra `create_tournament`.
  **Bygget:** lagt til i `TournamentUpdate` (`app/routers/tournaments.py`),
  settes via det eksisterende generiske `PATCH /orgs/{id}/tournaments/{id}`
  (`exclude_unset`-mønsteret, ekte PATCH-semantikk uendret).
  **Reelt funn UNDER scratch-testing, ikke antatt riktig på forhånd:**
  `status` er -- ulikt `visibility` (som er ren `text`+`CHECK`) -- en EKTE
  Postgres ENUM-type (`tournament_status`). Den generiske
  `set_clauses`-byggeren (`f"{key} = ${i}"`) hadde derfor trengt et
  eksplisitt cast for at asyncpg sin ukjent-typede parameter skulle løses
  riktig mot en enum-kolonne -- lagt til en spesialsjekk (`::tournament_status`
  kun for `status`-nøkkelen) FØR jeg antok mekanismen "bare fungerer" fordi
  den gjør det for de andre feltene.
  Bevisst INGEN tilstandsmaskin/overgangsregler bygget (kan f.eks. gå fra
  `completed` tilbake til `draft` fritt) -- samme tillitsnivå som resten av
  appen, ikke etterspurt.
  **Frontend:** `tournament-status-badge.tsx` fikk en ny redigerbar
  `TournamentStatusPicker` (dropdown over de fire verdiene, optimistisk
  UI-oppdatering med rollback ved feil), koblet inn i `tournament-detail.tsx`
  sin header ved siden av invitasjonskode-chipen. Den eksisterende
  skrivebeskyttede `TournamentStatusBadge` (dashbordets kortliste) urørt.
  **Verifisert i scratch:** ny turnering får riktig default `draft`, PATCH
  til `active` bekreftet enum-castet faktisk løser problemet, PATCH med
  status+et annet felt samtidig fungerer, PATCH UTEN status-felt lar
  verdien stå urørt (regresjon på eksisterende PATCH-semantikk), ugyldig
  status-verdi avvist med 422 (Pydantic-mønster), `GET`-listen viser samme
  verdi etterpå. `test_isolation.sql` 12/12 uendret (ingen skjemaendring).
  Ekte typesjekket produksjonsbuild kjørt og bekreftet.
  **Rullet ut live 2026-07-19**, bruker bekreftet eksplisitt: ingen
  migrasjon, `docker compose up -d --build teecup_api teecup_frontend`,
  begge containere boot-et rent, `/health` og `/dashboard` → 200,
  `teeoff.no` upåvirket.

- **Kommunikasjon LIVE (2026-07-19, ADR-025) — det største enkeltløftet i
  prosjektet så langt:** lag-intern chat («det hemmelige rommet») + offentlig
  runde-feed («Banter Board»), begge med bilder og ekte WebSocket-sanntid,
  bygget i samme runde. Fire hovedbeslutninger avklart eksplisitt med bruker
  (AskUserQuestion) før bygging — brukeren valgte den mest ambisiøse
  kombinasjonen på alle fire (begge deler nå, WebSockets fremfor polling,
  ekte privat chat, bilder fra start).
  **Datamodell:** ny migrasjon `013_messaging.sql` — delt `message`-tabell
  med `scope`-diskriminator (`team`/`tournament_feed`) i stedet for to
  separate tabeller, RLS org_isolation som ellers. `author_display_name`
  FRYSES ved skrivetidspunkt (samme prinsipp som handicap-snapshot,
  ADR-007) — spillerens `player.display_name` i org-en hvis den finnes,
  ellers e-postens lokaldel (dekker org-ansatte uten egen spillerprofil).
  **Lag-chat er BEVISST ekte privat** — ny `user_is_rostered_on_team` i
  `app/team_authz.py`, med VILJE uten org-admin-fallback, ulikt de to andre
  funksjonene i samme fil (`user_is_team_captain`/`user_is_match_participant`,
  ADR-023, som begge har et slikt unntak). Første sted i hele appen der
  org-eier/admin er strukturelt utestengt fra noe.
  **Offentlig feed:** LESING gjenbruker `registration.py` sitt eksisterende
  trenivå-visibility-mønster (ADR-018) helt uendret, inkl. anonym tilgang.
  POSTING er strengere enn lesing — krever ekte innlogging OG org-
  medlemskap/faktisk deltakelse, selv på en `public`-synlig turnering (en
  helt urelatert innlogget bruker skal ikke kunne poste på en fremmed
  offentlig side). Moderering: forfatteren selv ELLER org-eier/admin kan
  slette et feed-innlegg (motsatt av lag-chatten, som ikke har noen
  ekstern moderator).
  **`registration.py` sine fire interne hjelpefunksjoner gjort delt**
  (fjernet ledende understrek — samme "gjort delt for gjenbruk"-mønster som
  tidligere runder): `resolve_org`, `is_participant`, `code_matches`,
  `check_visibility`. `team_authz.py` sin `_is_org_admin` likeens →
  `is_org_admin`. Ingen atferdsendring, kun navn, for at `messaging.py`
  skulle kunne gjenbruke dem uendret i stedet for å duplisere logikk.
  **WebSockets, ikke polling:** in-memory tilkoblingsregister PER PROSESS i
  `app/routers/messaging.py` — trygt med dagens ene `teecup_api`-container,
  men deles IKKE på tvers av flere prosesser/containere (samme klasse
  begrensning som den allerede aksepterte in-memory-cachen, se ARCHITECTURE_
  DECISIONS.md "Åpne spørsmål"). Ny `get_current_user_from_websocket` i
  `app/auth.py` — WS-ruter kan ikke bruke `get_current_user`/
  `get_authorized_org` direkte via `Depends()` (de er `Request`-typet, ingen
  ekte HTTP Request finnes i en WS-scope), derfor en bevisst minimal, egen
  kopi av samme cookie-dekode-/oppslagslogikk.
  **Reell infrastrukturoppdagelse FØR noe ble forsøkt, ikke i etterkant:**
  Next.js sin `rewrites()` proxyer ikke WebSocket-oppgraderinger pålitelig i
  "standalone"-modus — løst likt som MinIO-media-ruten (ADR-018): en egen
  Caddy-rute (`handle /ws/* { reverse_proxy teecup_api:8000 }`) rett til
  API-et, forbi Next.js/`teecup_frontend` helt. Caddyfile ligger i det
  SEPARATE `/opt/teeoff`-repoet — samme stale-bind-mount-inode-oppførsel som
  ALLE tidligere Caddyfile-runder (graceful reload plukker ikke opp
  endringen), løst likt: full `docker restart teeoff_caddy`, brukeren
  bekreftet eksplisitt på forhånd, noen sekunders nedetid for `teeoff.no`.
  **Verifisert grundig mot fersk `teecup_scratch`** (isolert
  `teecup_app_scratch`-rolle, isolert scratch-MinIO, engangs API-container
  med `websockets`-Python-biblioteket installert kun for testen): et
  20-punkts asyncio/httpx/websockets-testskript som dekket BEGGE
  meldingstyper ende-til-ende. Kritiske personvern-/sanntid-funn, alle
  bekreftet med ekte tilkoblinger (ikke bare REST):
  - Rostret spiller på lag A FÅR lese/skrive lag A sin chat; rostret spiller
    på lag B NEKTES; **organisatoren (org-eier) NEKTES OGSÅ** — bekreftet
    BÅDE over REST (`GET`) og over selve WebSocket-håndtrykket (avvist med
    lukkekode 4403 før `accept()` i det hele tatt kalles).
  - Sanntid bekreftet reelt: A1 koblet til lag A sin chat-socket, A2 sendte
    en melding over vanlig REST, A1 mottok den umiddelbart over den åpne
    WebSocket-tilkoblingen (ikke bare at REST-svaret så riktig ut).
  - Bildeopplasting i chat bekreftet (ekte AVIF-konvertert `image_url`
    returnert).
  - Offentlig feed: anonym NEKTES å poste (401), en tilfeldig INNLOGGET men
    uvedkommende bruker NEKTES (403 `NOT_A_PARTICIPANT`), org-medlem FÅR,
    en faktisk deltaker (rostret, IKKE org-medlem) FÅR — beviser
    `is_participant`-veien fungerer uavhengig av `is_member`-veien. Anonym
    WebSocket-tilkobling til en `public`-synlig turnerings feed FÅR lov og
    mottar sanntidsoppdateringer.
  - Moderering bekreftet: forfatter sletter eget innlegg, org-admin sletter
    ANDRES innlegg (feeden), uvedkommende NEKTES å slette andres innlegg.
  `test_isolation.sql` 12/12 uendret (additiv migrasjon). Ekte typesjekket
  produksjonsbuild av frontend kjørt og bekreftet, inkl. den nye
  `/tournaments/[id]/teams/[teamId]/chat`-ruten.
  **Frontend:** ny `components/team-chat.tsx` (meldingsliste med egen/andres-
  styling, bildeopplasting, sanntid via nettleserens native `WebSocket`,
  slett-egen-melding), lenket fra en ny chat-ikon-knapp i `tournament-
  detail.tsx` sin `TeamPanel`. Ny seksjon `TournamentFeed` i
  `components/public-tournament.tsx` (nederst på den offentlige
  turneringssiden) — viser 401/403-svar fra posting som forklarende
  inline-tekst ("logg inn for å poste" / "du må være medlem/deltaker") i
  stedet for en generisk feilmelding.
  **Rullet ut live 2026-07-19**, bruker bekreftet eksplisitt for alle tre
  stegene (migrasjon, containere, Caddy-restart): migrasjon 013 kjørt mot
  ekte `teecup_db`, `test_isolation.sql` fortsatt 12/12, begge containere
  boot-et rent, Caddy validert (`caddy validate` — "Valid configuration")
  FØR restart, restarten ren (ingen feil i loggen). Verifisert grundig
  etterpå: `/health`/`dashboard` → 200, `teeoff.no` → 200, et ekte
  `wss://`-håndtrykk over produksjons-https bekreftet å nå helt frem til
  applikasjonslaget (testet mot en ukjent turnering-id — ingen ekte data
  berørt — ga korrekt 404 fra selve WS-ruten, ikke en Caddy/Next.js-feil),
  og et ren-HTTP-kall mot en `/ws/*`-sti bekreftet å returnere FastAPI sin
  egen JSON-404 (`{"detail":"Not Found"}`) og ikke Next.js sin HTML-404 —
  beviser Caddy-ruten faktisk treffer `teecup_api`, ikke `teecup_frontend`.

- **Tilskuer-rolle LIVE (2026-07-19, ADR-026):** brukeren valgte dette som
  neste steg rett etter Kommunikasjon-runden — "tilskuer" var bevisst
  utsatt til feed-synligheten (ADR-025) fantes, og nå gjorde den det.
  **Kjernebeslutning:** ingen ny rolle/tabell — "tilskuer" er ganske enkelt
  enhver som kan SE en turnering per `tournament.visibility` (ADR-018),
  utvidet til også å dekke LIVE-data (leaderboard, matcher, scorekort), ikke
  bare info-siden/programtidene som før.
  **Bygget:** `GET /orgs/.../leaderboard`, `.../sessions/{id}/matches` og
  `.../matches/{id}/scorecard` fantes allerede (organisator-/spiller-siden),
  men krevde org-medlemskap — en ren spectator kunne aldri se dem. Løst ved
  å ekstrahere den delte kjernelogikken til gjenbrukbare funksjoner
  (`fetch_leaderboard` i tournaments.py, `fetch_matches` i matches.py,
  `fetch_scorecard` i scoring.py — samme "gjort delt"-mønster som tidligere
  runder), og la tre nye offentlige endepunkter i `registration.py` kalle
  dem etter egen visibility-sjekk. `own_team_ids()` (`blind_draw.py`) gjort
  null-sikker (`user_id: str | None`) -- en anonym leser har per definisjon
  ingen egne lag, korrekt oppførsel er tom mengde (ser kun avslørte
  matcher), ikke en feil.
  **To nye sikkerhetssjekker funnet under DESIGN, ikke i etterkant, samme
  disiplin som tidligere ADR-018 Beslutning B-lærdommen:**
  1. `session_id`/`match_id` i URL-en må eksplisitt verifiseres å høre til
     NØYAKTIG `tournament_id` i samme URL — `org_connection()` setter kun
     TENANT-grensen (RLS), ikke at stiens id-er faktisk henger sammen. Uten
     dette kunne noen med tilgang til én offentlig turnering i en
     organisasjon lest en HVILKEN SOM HELST økt/match i samme organisasjon
     (inkl. en privat en) ved å gjette/prøve id-er.
  2. Scorekortet krever eksplisitt at BEGGE lag har låst oppstillingen
     (blind draw, ADR-013) — leaderboard/matchliste arver reveal-skjuling
     automatisk via `own_team_ids()`, men scorekortet har ingen tilsvarende
     innebygd sjekk.
  **Bruker valgte omfang utover anbefalingen:** BÅDE leaderboard+matchliste
  OG fullt hull-for-hull-scorekort per match i samme runde (anbefalingen var
  kun de to første).
  **Frontend:** ny `/t/[id]/live`-side (`components/public-live.tsx`) —
  fargesegmentert stillingsbar (faktisk + projisert, samme visuelle idé som
  den org-autentiserte leaderboard-skjermen, men egen enklere implementasjon
  siden komponentene har ulik autentiseringskontekst), utvidbar øktliste →
  matchliste → hull-for-hull-scorekort (fargede hull-chips per lag). Lenket
  fra hovedsiden (`public-tournament.tsx`) med en ny "Følg live"-knapp.
  **Verifisert grundig mot fersk `teecup_scratch`** (isolert
  `teecup_app_scratch`-rolle, isolert scratch-MinIO, engangs API-container):
  16 automatiserte sjekker, inkl. en PRESIS test av den nye tenant-vs-sti-
  sjekken (ikke bare en ukjent id, men en EKTE ANNEN turnering i SAMME org
  — bekreftet at match/økt fra turnering A fortsatt ikke kan leses via
  turnering B sin offentlige URL), full blind-draw-skjuling FØR/ETTER
  reveal for en anonym leser, kode-overstyring (ADR-020) fungerer uendret
  for de nye endepunktene, scorekort eksplisitt nektet før reveal. Ekte
  typesjekket produksjonsbuild av frontend, inkl. den nye `/t/[id]/live`-
  ruten.
  **Rullet ut live 2026-07-19**, bruker bekreftet eksplisitt: ingen
  migrasjon, `docker compose up -d --build teecup_api teecup_frontend`,
  begge containere boot-et rent, `/health`/`dashboard` → 200, `teeoff.no`
  upåvirket.

- **"Følg live"-siden koblet til sanntid (2026-07-19, ADR-027):** brukeren
  fulgte anbefalingen fra forrige runde — `/t/[id]/live` (bygget i
  tilskuer-runden samme dag) krevde omlasting for nye resultater.
  **Bygget:** ny, RUTEFRI modul `app/realtime.py` (in-memory
  tilkoblingsregister + `broadcast_live_update(tournament_id)`) -- ligger
  bevisst BAK alle routere i importgrafen for å unngå en sirkulær import
  (`registration.py` importerer allerede fra `scoring.py`/`tournaments.py`/
  `matches.py`, og `messaging.py` importerer fra `registration.py`; en
  kringkastingsfunksjon i noen av routerne ville derfor bitt seg selv i
  halen). Kringkastingen er lagt INN I `recompute_and_cache_match_state` og
  `apply_concession` selv (sistnevnte fikk en ny påkrevd `tournament_id`-
  parameter) -- kallerne (hole-score/hole-result-innsending, walkover på
  både match- og turnering-nivå) trenger ikke huske å gjøre noe selv. Nytt
  WS-endepunkt `/ws/public/tournaments/{id}/live` i `messaging.py`
  (gjenbruker `/ws/*`-Caddy-ruten fra ADR-025 uendret -- ingen ny
  infrastruktur). Sender bevisst kun et "noe endret seg, hent på nytt"-
  signal, ikke selve dataene -- unngår å duplisere leaderboardets
  projeksjons-regnestykke/blind draw-filtrering i kringkastings-payloaden.
  **Frontend:** `components/public-live.tsx` åpner en WebSocket ved
  montering; hver melding teller opp en `refreshKey` som utløser refetch av
  leaderboardet ALLTID, og av en økts matcher/et scorekort KUN hvis det
  faktisk er utvidet/åpent på skjermen akkurat da (ingen unødvendige kall
  for lukket innhold). Liten pulserende prikk lagt til ved siden av
  "Følg live"-teksten som visuell bekreftelse.
  **Verifisert i scratch:** anonym avvist på live-WS for en `org`-synlig
  turnering (samme visibility-sjekk som REST), satt til `public`, deretter
  bekreftet FAKTISK sanntidsmottak (ikke bare at REST-svaret så riktig ut)
  for BÅDE et vanlig hull-resultat OG en walkover-konsesjon -- en åpen
  WebSocket-tilkobling mottok kringkastings-signalet i begge tilfeller.
  Leaderboard fortsatt korrekt lesbar over REST etterpå (regresjon). Ekte
  typesjekket produksjonsbuild kjørt og bekreftet.
  **Rullet ut live 2026-07-19**, bruker bekreftet eksplisitt: ingen
  migrasjon, ingen ny Caddy-endring, `docker compose up -d --build
  teecup_api teecup_frontend`, begge containere boot-et rent. Verifisert
  grundig etterpå: `/health`/`dashboard` → 200, `teeoff.no` upåvirket, OG et
  ekte `wss://`-håndtrykk mot den NYE `/live`-ruten over produksjons-https
  (ukjent turnering-id, ingen ekte data berørt) ga korrekt 404 fra selve
  applikasjonslaget.

- **Fire brukerrapporterte UI-/UX-hull, DIAGNOSTISERT OG NOTERT, IKKE fikset
  (2026-07-19):** brukeren rapporterte fire ting fra faktisk bruk av
  `teecup.teeoff.no` rett før PWA-runden startet. Root cause funnet ved
  kodegjennomgang for tre av fire (ikke gjettet). Full detalj i
  FEATURE_BACKLOG.md sin nye seksjon "Rapporterte UI-/UX-hull (2026-07-19)".
  Kort:
  1. Dashboard-turneringskortet viser "Ingen datoer satt" alltid — leser
     `tournament.start_date`/`end_date` (eget felt, ADR-015), som INGEN
     UI-skjema noensinne skriver til. Skal enten få et faktisk skjemafelt,
     eller kortet bør heller utlede datoen fra øktenes `scheduled_at`.
  2. **Reell, bekreftet rewrite-bug:** `/orgs/{id}/members` gir en rå
     FastAPI-404 (`{"detail":"Not Found"}`) i stedet for medlemssiden.
     `next.config.mjs` sin `rewrites()` returnerer en plain array (implisitt
     "afterFiles") — DYNAMISKE Next.js-sider sjekkes ETTER rewrites, så
     `/orgs/:path*`-proxy-regelen (ADR-016) fanger kallet FØR
     `app/orgs/[id]/members/page.tsx` noensinne nås. Dette er den FØRSTE
     frontend-siden som er nestet direkte under et allerede proxyet prefiks
     — ingen tidligere skjerm har truffet dette. Selve siden/komponenten er
     riktig bygget, kun ruten dit er blokkert.
  3. Ingen UI-vei til å opprette en ANDRE organisasjon når man allerede har
     én — `CreateOrganizationState` i `dashboard.tsx` vises kun ved null
     org-er. Backend støtter det fullt ut allerede (ADR-021).
  4. Ingen sammendrag/indikator noe sted for "alle runder har fått dato" —
     må sjekkes manuelt per øktkort på program-skjermen.
  **Ingen av de fire fikset i denne runden** — kun dokumentert på brukerens
  eksplisitte instruks, PWA-runden prioriteres først.

- **PWA: installasjon + full offline scoreregistrering, BYGGET, IKKE ENNÅ
  RULLET UT (2026-07-19, ADR-028):** bruker valgte det mest ambisiøse
  omfanget (installerbar app OG offline scoreregistrering, ikke bare
  installasjon), og valgte å generere enkle ikoner nå fremfor å vente på
  ekte design (med eksplisitt beskjed om at de er midlertidige).
  **Ikoner:** ingen `PIL`/`rsvg-convert`/`imagemagick` tilgjengelig i miljøet
  — løst med et scratch npm-prosjekt (`sharp@0.33.5`, node18-kompatibel
  versjon; nyeste `sharp` krever node ≥20 og feilet først) som genererte et
  enkelt grønt golf-flagg-ikonsett (`public/icons/icon-192.png`,
  `icon-512.png`, `icon-maskable-512.png`) + erstattet den gamle
  `public/apple-icon.png` (var v0.app sin generiske plassholderlogo, ikke
  TeeCup-merkevare i det hele tatt).
  **Bygget:** `app/manifest.ts` (Next.js sin innebygde manifest-generator,
  ikke en statisk `manifest.json`), `appleWebApp`-metadata i `layout.tsx`
  (iOS leser ikke manifest.json for hjemskjerm-oppførsel),
  `components/sw-register.tsx` (stille no-op uten SW-støtte),
  hånd­skrevet `public/sw.js` (ingen next-pwa/workbox-avhengighet — nettverk
  først/cache-fallback for navigasjon + `/orgs/*`-GET-er, BEVISST ikke
  stale-while-revalidate, se ADR-028 for hvorfor), `public/offline.html`.
  **Offline scoreregistrering:** ny `lib/offline-queue.ts` (IndexedDB-kø,
  ren klientkode — ikke i SW-en), koblet inn i `session-scorecard.tsx` sin
  `submitStroke`/`submitHoleResult`: sjekker `navigator.onLine` først, køer
  kun ved en EKTE nettverksfeil (ikke ved et avvist HTTP-svar som "matchen
  er avgjort" — det vises fortsatt som vanlig feiltekst). Lokalt overlay
  (`pendingStrokes`/`pendingResults`) viser køede verdier umiddelbart,
  merket "Lagret lokalt · venter på synk". Auto-synk ved `window`s
  `online`-event PLUSS en manuell "Synkroniser nå"-knapp (bevisst IKKE
  Background Sync API — iOS Safari støtter den ikke). Et definitivt avvist
  synk-forsøk (f.eks. matchen ble avgjort på en annen enhet mens denne var
  offline) fjernes fra køen og vises som feilmelding, henger aldri for
  alltid.
  **Verifisert:** ekte typesjekket produksjonsbuild (samme `Dockerfile` som
  deployes) kjørt og bekreftet — alle 16 ruter listet inkl.
  `/manifest.webmanifest`. Kort container-boot + `curl` bekreftet manifest/
  service worker/ikoner/offline.html alle svarer riktig (200, riktig
  innhold).
  **IKKE gjort denne runden, viktig å være ærlig om:** ingen faktisk
  nettleser-basert offline-test (Chrome DevTools sin Offline-bryter,
  faktisk "Legg til på hjemskjerm") — intet nettleserverktøy tilgjengelig i
  denne økten. Kun kodegjennomgang + build-verifisering. **Brukeren bør selv
  teste scorekort-siden med DevTools Offline-modus før tillit i skarp
  bruk.**
  **Rullet ut live 2026-07-19**, bruker bekreftet eksplisitt: `docker
  compose up -d --build teecup_frontend`. Compose gjenskapte OGSÅ
  `teecup_api` som en bivirkning (avhengighets-oppløsning i `up --build`)
  — ingen backend-kode rørt, ren uendret gjenoppbygging, begge containere
  boot-et rent (`Application startup complete` / Next.js `Ready`).
  Verifisert: `/health`/`dashboard` → 200, `/manifest.webmanifest`/`sw.js`/
  `icons/icon-512.png` alle 200 over ekte https, `teeoff.no` upåvirket.

- **Fire nye hull rapportert fra faktisk testing av blind draw + scorekort
  (foursome), DIAGNOSTISERT OG NOTERT, IKKE fikset (2026-07-19):** rett
  etter PWA-runden. Full detalj i FEATURE_BACKLOG.md sin nye seksjon
  "Rapporterte hull, blind draw + scorekort (2026-07-19)". Kort:
  1. **Bekreftet root cause:** valgt spiller forsvinner ikke fra
     nedtrekkslisten i `AddSlotForm` (`session-blind-draw.tsx`) — den
     merkes kun `disabled` på `<option>`-nivå, som HTML fortsatt viser
     (bare gråtonet). Skal FILTRERES bort, ikke deaktiveres.
  2. **Bekreftet, større enn antatt:** tee-valg (Dame/Herre) bør følges av
     spillerens registrerte kjønn automatisk. Krever en backend-utvidelse
     først — `RosterEntry`/`list_roster` (`tournaments.py`) mangler
     `player.gender` helt i responsen, selv om feltet finnes i skjemaet og
     alt eksponeres via `GET /orgs/{id}/players`. Åpne spørsmål om låst vs.
     forhåndsutfylt valg, og fallback ved ukjent kjønn/manglende
     matchende tee, før bygging.
  3. Ren frontend-UX: tallvelger (1–9 + utvidbar "10 eller flere") i stedet
     for pluss/minus-steppere for slagregistrering. Ingen backend-endring.
  4. **HCP "ikke hensyntatt" i foursome-test — IKKE bekreftet som bug.** Ett
     definitivt, bekreftet hull uavhengig av alt annet: det beregnede
     `course_handicap`/`playing_handicap` eksponeres ALDRI noe sted i
     API-et eller UI-et (sjekket `matches.py`, `scoring.py`, begge
     frontend-skjermene) — usynlig selv når beregningen er korrekt. I
     TILLEGG en kjent, tidligere dokumentert begrensning som kan ha slått
     inn: foursome/greensome/scramble sin side-handicap beregnes kun når
     BEGGE deltakere har en matchende `tee_rating`, og `tee_rating`-rader
     lages i dag ALLTID kun med `full_18`-omfang — en `front_9`/`back_9`-
     testøkt ville derfor ALDRI fått handicap beregnet i det hele tatt.
     **Trenger avklaring:** var testøktens `hole_config` `full_18`, og
     hadde begge sider alle sine deltakere+tee lagt til før scoring?
  **Ingen av de fire fikset i denne runden** — kun dokumentert på brukerens
  eksplisitte instruks.

- **Tre av fire hull FIKSET OG SCRATCH-VERIFISERT (2026-07-19), samme dag:**
  bruker ba eksplisitt om punkt 1 og 3, og presiserte punkt 2 (se under)
  samt bekreftet den nøyaktige handicap-formelen for punkt 4.
  1. **Spillerliste-fiks:** `AddSlotForm` (`session-blind-draw.tsx`)
     filtrerer nå allerede-valgte roster-rader helt bort i stedet for å
     bare `disabled`-merke `<option>`-en (som HTML uansett viser gråtonet).
  2. **Tee-valg — OMDEFINERT etter brukerens presisering, IKKE bygget
     ennå:** min opprinnelige antakelse ("lås tee til spillerens kjønn")
     var feil i premisset — en golfbane har ikke fysisk kjønnsdelte
     utslag, kun eventuelt kjønnsdelt RATING av samme utslag (noen klubber
     sloper bevisst ikke ett utslag for ett kjønn). Bekreftet mot ekte
     Tjøme-data: hvert fysisk utslag ligger i dag som TO `tee`-rader med
     samme navn (én per kjønn) — nøyaktig konflateringen brukeren pekte
     på. Riktig fiks er å flytte `gender` fra `tee` til `tee_rating`
     (skjemaendring + datamigrering + import-/handicap-/remap-kode).
     Betydelig større enn antatt — se FEATURE_BACKLOG.md for full
     analyse og de tre åpne designspørsmålene som trengs FØR bygging.
  3. **Tallvelger:** ny `StrokePicker`-komponent
     (`session-scorecard.tsx`) — 1-9 direkte, "10+"-knapp åpner 10-19,
     med en "tilbake"-lenke. Erstatter ±-stepperen og all dens døde kode
     helt.
  4. **HCP-bug, BEKREFTET og FIKSET:** brukeren beskrev selv riktig
     formel (kombinert hcp/2 justert for prosent, laveste side til 0
     mottatte slag ved matchplay-hcp, resten fordelt fra stroke index 1) —
     lest direkte mot `handicap_engine.py` og bekreftet at koden allerede
     implementerer NØYAKTIG dette. Bugen lå ikke i formelen, men i at den
     ALDRI kjørte for front_9/back_9-økter: `compute_and_store_side_
     handicaps` (`app/handicap.py`) joinet `tee_rating` på øktens
     `hole_config` som rating-scope, men slike rader lages i praksis kun
     med `scope='full_18'` (matcher ADR-008 sin allerede etablerte
     design — full_18-ratingen skal alltid brukes, front/back-9-
     fordelingen skjer senere ved selve slagtildelingen). Bekreftet
     direkte mot EKTE `teecup_db` (read-only): brukerens rapporterte
     testøkt (`front_9`+`foursome`) hadde `course_handicap`/
     `playing_handicap = NULL` på alle fire deltakere. Påvirket ALLE
     formater på front_9/back_9-økter, ikke bare foursome. Fikset: scope
     hardkodet til `full_18`, `hole_config`-parameteren fjernet helt fra
     funksjonen og alle tre kallstedene (var død etter fiksen).
     **Scratch-verifisert presist:** samme scenario gjenskapt (foursome+
     front_9, hcp 10/20 mot 5/15) — course/playing handicap kom ut nøyaktig
     som beregnet for hånd (10/21 vs. 5/16, kombinert 16/10), og et hull
     med IDENTISK bruttoscore (5-5) på begge sider ga et IKKE-delt
     resultat ("a" vant) — direkte bevis på at hcp nå faktisk brukes.
     **Ny, urelatert bug funnet under samme scratch-test, IKKE fikset:**
     stroke-modus-innsending på en bane uten registrerte hull krasjer rått
     (500 `IndexError` i `allocate_over_played_holes`) i stedet for en ren
     `VALIDATION_FAILED` — samme klasse feil som en tidligere fikset
     manglende-handicap-krasj. Notert i FEATURE_BACKLOG.md, ikke bygget.
  **Scratch-infrastruktur:** isolert `teecup_scratch`-database +
  `teecup_app_scratch`-rolle + isolert scratch-MinIO + engangs API-
  container (`python:3.12-slim`, `app/` og `handicap_engine.py` montert
  read-only), alt ryddet opp etter verifisering. Typesjekket
  produksjonsbuild kjørt for frontend-fiksene (1+3), alle 16 ruter listet.
  **Rullet ut live 2026-07-19**, bruker bekreftet eksplisitt, se eget
  punkt lenger ned for punkt 2 (som ble bygget og rullet ut sammen med
  disse tre i én utrulling).

- **Punkt 2 (tee/kjønn) BYGGET OG SCRATCH-VERIFISERT (2026-07-19, ADR-029),
  samme dag, rett etter designavklaringen:** bruker bekreftet begge
  anbefalte alternativer (helautomatisk tee-valg, "feil høyt" ved
  manglende kjønn/rating). Ny migrasjon `014_tee_gender_to_rating.sql`:
  flytter `gender` fra `tee` til `tee_rating` (unikhet
  `(tee_id, scope)` → `(tee_id, scope, gender)`), slår sammen
  eksisterende kjønns-par-tee-rader til én fysisk tee-rad per (bane,
  navn) — velger laveste id som "beholder", flytter `tee_rating`- og
  `match_participant.tee_id`-referanser dit, sletter duplikatene.
  **Reell bug funnet OG fikset UNDER selve migrasjonsskrivingen** (ikke i
  produksjon): første versjon prøvde å droppe den GAMLE
  `(tee_id, scope)`-unikheten ETTER sammenslåingen i stedet for FØR —
  kolliderte da midlertidig med beholder-tee-ens egen eksisterende rad
  for samme scope. Rettet ved å bytte rekkefølge (drop gammel unikhet FØR
  sammenslåing, legg til ny kjønnsbevisst unikhet ETTER).
  **Kodeendringer:** `app/handicap.py` sin `compute_and_store_side_
  handicaps` joiner nå også på `player.gender` (i tillegg til forrige
  rundes full_18-fiks). `app/routers/matches.py` sin `add_participant`
  validerer FØR innsetting: spiller har registrert kjønn, OG valgt utslag
  har en matchende rating — begge avvist med klar `VALIDATION_FAILED`.
  `app/routers/tournaments.py` sin `_remap_course` (bane-bytte) matcher nå
  på tee-navn OG bekrefter matchende kjønnsrating for hver berørte
  spiller. `app/routers/courses.py`: `TeeCreate` redesignet fra ett flatt
  kjønn+rating-sett til en `ratings`-liste (1-2 elementer, distinkte
  kjønn); ADR-019 sin `import_official_course` lager nå ÉN tee-rad per
  fysisk teeoff-utslag (før: to, én per kjønn) med inntil to
  `tee_rating`-rader under. `session-blind-draw.tsx` forenklet — ingen
  "H"/"D"-suffiks, ingen kjønnslogikk i det hele tatt lenger (serveren
  løser det).
  **Verifisert grundig, flere separate scratch-runder:**
  1. Selve fletting-migrasjonen kjørt mot SYNTETISK data som gjenskaper
     Tjøme-mønsteret nøyaktig (to par + én enslig utslag, pluss en
     `match_participant`-rad som bevisst pekte til DUPLIKATEN, ikke
     beholderen) — bekreftet: to rader ble til én, `tee_rating.gender`
     riktig fylt inn for begge, `match_participant.tee_id` korrekt
     reparert til beholderens id, det enslige utslaget urørt.
  2. Full API-runde (18 automatiserte sjekker via et Python/urllib-
     testskript — httpx var ikke tilgjengelig i vertsmiljøet, løst med
     stdlib `http.cookiejar`/`urllib` i stedet): manuell tee-opprettelse
     (to ratinger, kun én rating, duplikat kjønn avvist), `GET tees`
     viser riktig sammenslått struktur, kvinne+dame-rating lykkes,
     mann+kun-dame-rating avvist tydelig, spiller uten kjønn avvist
     tydelig, full kjønnsblandet singel-match scoret korrekt.
  3. Offisiell import kjørt mot EKTE `teeoff_api` (Borregaard Golfklubb,
     samme mønster som ADR-019 sin opprinnelige verifisering) — bekreftet
     4 fysiske utslag importert med begge kjønnsratinger hver, ikke 8
     doble rader.
  4. `_remap_course`: bane-bytte til en bane UTEN matchende kjønnsrating
     avvist tydelig, bane-bytte til en bane MED matchende rating lykket.
  Ekte typesjekket produksjonsbuild av frontend kjørt på nytt og
  bekreftet etter blind draw-forenklingen.
  **Rullet ut live 2026-07-19**, bruker bekreftet eksplisitt: migrasjon
  014 kjørt mot ekte `teecup_db` FØRST (Tjømes 8 tee-rader slått sammen
  til 4 — bekreftet 0 brutte `match_participant.tee_id`-referanser
  etterpå med en direkte spørring), deretter `docker compose up -d
  --build teecup_api teecup_frontend` sammen med punkt 1/3/4 i samme
  utrulling. Begge containere boot-et rent, `/health`/`dashboard` → 200,
  `teeoff.no` upåvirket.

- **Dashboard-dato-fiks (ADR-030) + rediger spiller, BYGGET OG SCRATCH-
  VERIFISERT (2026-07-19/20):** brukeren viste et faktisk skjermbilde av
  det tidligere dokumenterte datovisning-hullet (økt planlagt til "11.
  juli" på Program-fanen, men dashbord-kortet viste fortsatt "Ingen
  datoer satt") og ba samtidig om å kunne redigere spilleres HCP.
  **Dato-fiks:** `list_tournaments` (`app/routers/tournaments.py`) utleder
  nå datospennet fra øktenes `scheduled_at` (`COALESCE` med et evt.
  eksplisitt satt `tournament.start_date`/`end_date`, som fortsatt vinner
  om det noensinne settes — ingen UI gjør det i dag). Kun denne ene
  spørringen endret, `_TOURNAMENT_COLUMNS` (brukt av opprett/PATCH sine
  `RETURNING`-klausuler) urørt. Se ADR-030.
  **Rediger spiller:** ny `PATCH /orgs/{id}/players/{id}`
  (`app/routers/players.py`, vanlig `exclude_unset`-mønster, dekker alle
  spillerfelt) + ny "Rediger spiller"-handling i rosterradens meny
  (`tournament-detail.tsx`). **Bevisst grense, forklart i selve UI-et:**
  endrer spillerpoolen, IKKE et lags allerede frosne
  `handicap_index_snapshot` (ADR-007) — reproduserbarhet for allerede
  opprettede lag er et bevisst, tidligere designvalg, ikke noe denne
  fiksen skulle endre. Skjemaet sier dette rett ut i stedet for å late som
  endringen slår inn overalt.
  **Scratch-verifisert, 9 sjekker:** spiller-PATCH (hcp-endring, delvis
  PATCH lar andre felt stå urørt, tomt PATCH avvist, ukjent id gir 404),
  DEN KRITISKE sjekken (en spillers allerede frosne roster-snapshot for et
  eksisterende lag forble UENDRET etter en påfølgende spiller-PATCH —
  bekrefter ADR-007 fortsatt holder), dato-utledning (ingen økter → null,
  to økter 11./12. juli → riktig utledet spenn, eksplisitt satt dato
  vinner over utledet). Ekte typesjekket produksjonsbuild kjørt og
  bekreftet.
  **Rullet ut live 2026-07-20**, bruker bekreftet eksplisitt: `docker
  compose up -d --build teecup_api teecup_frontend`, ingen migrasjon.
  Begge containere boot-et rent, `/health`/`dashboard` → 200, `teeoff.no`
  upåvirket. Verifisert mot EKTE data (ikke bare scratch): "De Gamle er
  Eldst" viser nå korrekt 11. juli 2026 i stedet for "Ingen datoer satt".

- **To nye punkter reist 2026-07-20, GJENNOMTENKT OG FORESLÅTT, IKKE
  bygget:** brukeren ba eksplisitt om at punkt 1 tenkes grundig gjennom
  og legges frem som et forslag FØR bygging (ikke kode med en gang), og
  markerte det eksplisitt som prioritet over punkt 2.
  1. **Personlig landingsside for enhver registrert bruker (PRIORITERT).**
     Bekreftet reelt hull ved kodegjennomgang: `app/page.tsx` sender
     enhver innlogget bruker til `/dashboard`, som viser "opprett
     organisasjon" så snart `organizations.length === 0` — også for en
     bruker som KUN er spiller (koblet via `player.user_id`,
     ADR-017 B), aldri organisator. Fullt forslag skrevet i
     FEATURE_BACKLOG.md: ett samlet dashboard (ikke to atskilte ruter),
     ny "Mine runder"-seksjon (tverr-org, krever en ny SECURITY
     DEFINER-bro `player_organizations_for_user()` + utvidelse av
     `/auth/me`, samme mønster som `public_tournament_org()` m.fl.),
     organisasjonsseksjonen uendret under. Venter på brukerens
     bekreftelse på retningen før bygging starter.
  2. **Midlertidige spillere + automatisk etter-runde-e-post (lavere
     prioritet, likevel dokumentert grundig).** Presisert ved
     kodegjennomgang: det meste av "midlertidig spiller"-behovet
     dekkes ALLEREDE av eksisterende `POST /orgs/{id}/players`
     (krever aldri en konto). Det som faktisk mangler er en PROAKTIV
     e-post-utsending etter runden (scorekort + innloggingslenke) —
     foreslått som en eksplisitt organisator-knapp per økt (ikke en
     automatisk bakgrunnsjobb, for å unngå uventede e-poster fra en
     gjettet "runden er ferdig"-deteksjon). Tre åpne spørsmål notert i
     FEATURE_BACKLOG.md (økt- vs. turnering-nivå, dobbel-utsending-
     sperre, locale).
  **Ingen kode skrevet for noen av de to ennå** — dette var bevisst en
  tenke-og-foreslå-runde, ikke en byggerunde.

- **Punkt 1 BYGGET OG SCRATCH-VERIFISERT (2026-07-20), samme dag, rett etter
  forslaget over:** bruker svarte "Gjør punkt 1" med et utvidet omfang —
  inkluder også opprettelse/redigering/sletting av personlig informasjon
  (profilbilde, fornavn, etternavn, fødselsdato, kjønn, HCP, hjemmeklubb).
  **Ny migrasjon `015_user_profile.sql`:** `app_user` får de sju nye
  profilfeltene — ETT sett PER KONTO, bevisst IKKE slått sammen med de
  org-scopede `player`-radene (se ADR-031 Beslutning B for full
  begrunnelse — to reelt atskilte konsepter). Ny
  `player_organizations_for_user()`-bro (femte instans av samme
  SECURITY DEFINER-mønster som `public_tournament_org()` m.fl.).
  **Backend:** `/auth/me` utvidet med profilfeltene + `avatar_url` +
  `my_tournaments` (turneringer brukeren er ROSTRET i, tverr-org, samme
  N+1-org_connection()-mønster som organisasjonslisten). Ny
  `PATCH /auth/profile` (vanlig exclude_unset), `POST`/
  `DELETE /auth/profile/avatar` (samme ekte multipart→AVIF-mønster som
  turnering-hero-bilder).
  **Reelt sikkerhetshull funnet UNDER bygging, ikke antatt på forhånd:**
  testet "Mine runder" mot en EKTE ren spiller (rostret, ingen
  org-medlemskap) og oppdaget at `check_visibility()` (ADR-018) kun ga
  deltaker-tilgang for `visibility='participants'` — IKKE for `'org'`
  (DEFAULT for enhver ny turnering). En ren spiller ville altså vært
  stengt ute fra sin EGEN, helt vanlige turnering — nøyaktig
  brukergruppen "Mine runder" er bygget for. Fikset: deltaker-sjekken
  gjelder nå begge ikke-offentlige tier, med eksplisitt begrunnelse om
  at visibility styrer eksponering mot UTENFORSTÅENDE, aldri mot faktiske
  deltakere. Verifisert presist at dette er en REN UTVIDELSE, ingen
  innstramming: samme scratch-test bekreftet at en helt ubeslektet
  FREMMED (innlogget, ikke deltaker) og en ANONYM leser fortsatt begge
  avvises identisk som før (403 NOT_VISIBLE).
  **Frontend:** `account-settings.tsx` fikk en ny "Personlig profil"-
  seksjon (avatar-opplasting/fjerning, fornavn/etternavn/fødselsdato/
  kjønn/HCP/hjemmeklubb-skjema). `dashboard.tsx` fikk en ny
  `MyToursSection` («Mine runder», øverst, lenker til den offentlige
  turnering-siden) + en mykere, sekundær utgave av "opprett organisasjon"-
  tomtilstanden når brukeren allerede har spiller-data å vise.
  **Bevisst UTENFOR omfang, klart flagget, IKKE en del av denne rundens
  leveranse:** "Mine runder" lenker IKKE til lag-chat/scorekort ennå — de
  krever fortsatt ekte organisasjonsmedlemskap (`get_authorized_org`), en
  strengere, bredt brukt sperre som ikke ble endret denne runden (egen,
  større og mer risikofylt endring, se ADR-031).
  **Scratch-verifisert, 15 sjekker:** full profil-CRUD (alle felt satt,
  delvis PATCH lar andre felt stå urørt, eksplisitt `null` sletter et
  felt, tomt PATCH avvist, avatar lastet opp med ekte AVIF-URL og
  slettet igjen, ugyldig filtype avvist), "Mine runder" for en EKTE ren
  spiller uten org-medlemskap, OG den kritiske sikkerhetssjekken over.
  Ekte typesjekket produksjonsbuild kjørt og bekreftet.
  **Rullet ut live 2026-07-20**, bruker bekreftet eksplisitt: migrasjon
  015 kjørt mot ekte `teecup_db` (bekreftet nye kolonner + funksjon
  finnes), deretter `docker compose up -d --build teecup_api
  teecup_frontend`. Begge containere boot-et rent, `/health`/`/dashboard`/
  `/account` → 200, `teeoff.no` upåvirket.

- **Oppfølging samme dag: e-post + mobil, BYGGET OG SCRATCH-VERIFISERT
  (ADR-032):** brukeren påpekte rett etter forrige runde at "identifikatoren"
  (e-post) manglet i profilen, og etterspurte mobil med landsnummer.
  Spurte samtidig hvorfor V0 ikke brukes til det visuelle her — svarte at
  jeg ikke har V0 som et verktøy jeg selv kan kalle (all V0-bruk i
  prosjektet har vært brukeren som designer i v0.app og sender meg
  zip-eksporter), og at disse siste tilføyelsene er små, inkrementelle
  skjemafelt i eksisterende komponenter (gjenbruker allerede etablerte
  Tailwind/shadcn-mønstre) der en full V0-runde (design→eksport→diff→
  sammenslåing) ville vært en unødvendig omvei.
  **Mobil:** `mobile_country_code`+`mobile_number` (to separate felt, ikke
  én sammensatt streng), lagt til i den EKSISTERENDE `PATCH /auth/profile`
  — ren tilføyelse, ingen ny sikkerhetsvurdering nødvendig.
  **E-post — bevisst IKKE en enkel PATCH:** e-post er innloggings-
  identifikatoren (magic-link-mål) — en vanlig PATCH ville latt en
  skrivefeil eller en kapret sesjon stjele kontoen for godt. Bygget som et
  ekte to-stegs bekreftelsesløp i stedet, samme `token_hash`+
  `expires_at`+`consumed_at`-mønster som `magic_link_token` (migrasjon
  004): ny `email_change_token`-tabell (migrasjon `016_profile_
  contact.sql`). `POST /auth/profile/email` (krever sesjon, sender
  bekreftelseslenke til den NYE adressen -- ikke den gamle, beviser
  eierskap av MÅLET). `POST /auth/profile/email/confirm` (ingen sesjon
  påkrevd, samme mønster som selve magic-link-verifiseringen -- lenken
  kan åpnes på en annen enhet enn den som ba om byttet). E-posten endres
  ALDRI før lenken faktisk åpnes. Duplikat-sjekk kjøres TO GANGER (ved
  forespørsel og rett før selve byttet, i tilfelle adressen ble tatt i
  mellomtiden), pluss den eksisterende unike indeksen som siste
  bakstopper. Ny `/verify-email`-side (samme mønster som `/verify`).
  **Scratch-verifisert, 10 sjekker:** mobil satt via vanlig PATCH; vanlig
  profil-PATCH rører aldri e-post; bytte til allerede brukt adresse
  avvist (409); e-post uendret helt til bekreftelse; ugyldig kode avvist;
  gyldig kode fullfører byttet; SAMME kode kan ikke gjenbrukes; en helt ny
  innlogging med den GAMLE adressen oppretter en fersk, tom konto (beviser
  byttet er reelt og fullstendig). Ekte typesjekket produksjonsbuild kjørt
  og bekreftet (ny `/verify-email`-rute listet).
  **Rullet ut live 2026-07-20**, bruker bekreftet eksplisitt (spurte
  samtidig og bekreftet at `teecup.teeoff.no/dashboard` nå er DEN samme
  adressen for enhver innlogget bruker uansett rolle — nettopp poenget
  med ADR-031/032): migrasjon 016 kjørt mot ekte `teecup_db` (bekreftet
  nye kolonner + `email_change_token`-tabell finnes), deretter `docker
  compose up -d --build teecup_api teecup_frontend`. Begge containere
  boot-et rent, `/health`/`/dashboard`/`/account`/`/verify-email` → 200,
  `teeoff.no` upåvirket.

- **Medlemsside-ruten FIKSET OG LIVE (2026-07-20):** brukeren ba eksplisitt
  om å ta fatt på dette (det mest presserende av de fire UI-hullene notert
  2026-07-19 — siden var helt utilgjengelig). Root cause var allerede
  presist diagnostisert: `next.config.mjs` sin `rewrites()` (plain array,
  implisitt "afterFiles") fanger `/orgs/:path*` FØR Next.js sine egne
  DYNAMISKE sider sjekkes, så `app/orgs/[id]/members/page.tsx` ble aldri
  nådd — kallet gikk til FastAPI i stedet, som ga en rå 404.
  **Fikset:** siden flyttet til `app/organizations/[id]/members/page.tsx`
  (utenfor `/orgs/*`-prefikset), eneste lenke (`dashboard.tsx`) oppdatert.
  Lagt til en forklarende kommentar i `next.config.mjs` sin `rewrites()`
  for å forhindre samme feil ved en fremtidig ny side.
  **Verifisert med ekte produksjonsbuild + container-boot** (ikke bare
  typesjekk): den nye ruten (`/organizations/{id}/members`) rendrer
  faktisk `OrgMembers`-komponenten med riktig `organizationId`/`orgName`
  i RSC-payloaden, IKKE en 404 eller innloggingssiden.
  **Rullet ut live**, ren frontend-endring, ingen migrasjon, `teeoff.no`
  upåvirket.

- **De to siste UI-/UX-hullene fra 2026-07-19 FIKSET OG LIVE (2026-07-21):**
  alle fire punkter i den runden er dermed fikset.
  1. **«Ny organisasjon»:** ny `NewOrganizationControl` i `dashboard.tsx`
     (identisk inline-ekspanderende-form-mønster som `NewTournamentControl`),
     lagt til i `OrganizationView` sin header ved siden av
     «Medlemmer»/«Ny turnering» — synlig uansett hvor mange org-er brukeren
     allerede har. Ingen backend-endring (`POST /orgs` hadde aldri en
     grense).
  2. **Dato-sammendrag:** ny `DateCoverageSummary` i `tournament-
     program.tsx`, vist øverst i øktlisten når minst én økt finnes: «X av Y
     runder har fått dato og klokkeslett» (uthevet når alle er satt). Ren
     klientside-telling av allerede lastet `scheduled_at`, ingen
     backend-endring.
  **Verifisert:** ekte typesjekket produksjonsbuild (samme `Dockerfile` som
  deployes) kjørt og bekreftet, alle 16 ruter listet. **Rullet ut live**,
  bruker bekreftet eksplisitt: `docker compose up -d --build
  teecup_frontend` (gjenskapte også `teecup_api` som compose sin vanlige
  avhengighets-bivirkning, ingen backend-kode rørt). Begge containere
  boot-et rent, `/health`/`/dashboard` → 200, `teeoff.no` upåvirket.

- **Dashboard/konto-runde (2026-07-21): to store punkter reist samtidig av
  brukeren.** (1) "Alt relatert til dashboard/account/brukerkontoer" —
  scopet sammen med brukeren via spørsmål: tom-tilstand-redesignet ble
  PAUSERT (bruker ba om "juster retningen" og reiste et dypere spørsmål om
  hvorvidt organisasjon fortsatt bør være "det som meldes først" — se eget
  punkt i FEATURE_BACKLOG.md, min vurdering: nei, bør bli ett likestilt
  valg blant flere). (2) Et helt nytt, stort forslag om frittstående
  rundeføring + detaljert statistikk (putter/chip/bunkerslag/straffeslag/
  førsteputt-lengde) UTEN turnering/organisasjon — grundig notert i
  FEATURE_BACKLOG.md med en eksplisitt arkitektur-advarsel: dette
  UTFORDRER tenant-invarianten (`organization_id` på alle domenetabeller)
  direkte og trenger en egen ADR, ikke bygget denne runden.
  **Deltaker-tilgang til lag-chat/scorekort — ✅ BYGGET OG LIVE
  2026-07-21** (én av tre konkrete følgepunkter brukeren bekreftet i samme
  runde, de to andre — sekundær e-post, HCP-historikk — tas fortløpende
  etterpå): fjernet den blanke `get_authorized_org`-sperren fra ni
  endepunkter på tvers av `messaging.py`/`scoring.py`/`matches.py`/
  `tournaments.py`/`courses.py`, erstattet med de ALLEREDE eksisterende
  domene-sjekkene (`user_is_rostered_on_team`/`user_is_match_participant`/
  `user_is_team_captain`) som viste seg å støtte ikke-org-medlemmer helt
  fint fra før — de var bare aldri nåbare. To nye delte hjelpefunksjoner i
  `team_authz.py` (`is_org_member`, `user_is_tournament_participant` —
  sistnevnte FLYTTET dit fra `registration.py` for å unngå sirkulær
  import) dekker de endepunktene som IKKE hadde noen finkornet sjekk fra
  før (ren fjerning der ville åpnet dem for enhver innlogget bruker).
  `/auth/me` sin `my_tournaments` fikk `my_session_id`/`my_match_id`;
  "Mine runder"-kortet fikk "Lag-chat"/"Scorekort"-lenker.
  **Scratch-verifisert grundig, 43 sjekker** (isolert scratch-rolle+MinIO+
  engangs API-container): rostret ikke-medlem fikk korrekt tilgang
  overalt (inkl. faktisk sendt chat-melding og hull-resultat), fortsatt
  avvist fra det ANDRE lagets chat, en helt fremmed bruker avvist overalt,
  org-eier beholder alt UNNTATT lag-chat (uendret, med vilje), kryss-org-
  isolasjon bekreftet. **Reelt funn UNDER selve scratch-testingen:** en
  rostret-men-ikke-kaptein spiller ble først uventet GODTATT til walkover
  — viste seg å være en allerede tiltenkt, dokumentert fallback
  (`user_is_team_captain`: "ingen kaptein utpekt ennå = enhver rostret
  spiller godtas"), ikke en bug — testen ble rettet (la til en faktisk
  kaptein) og bekreftet deretter riktig avvisning. `test_isolation.sql`
  12/12 uendret (ingen skjemaendring). Ekte typesjekket produksjonsbuild
  kjørt og bekreftet.
  **Rullet ut live 2026-07-21**, bruker bekreftet eksplisitt: ingen
  migrasjon, `docker compose up -d --build teecup_api teecup_frontend`,
  begge containere boot-et rent, `/health`/`/dashboard` → 200, `teeoff.no`
  upåvirket.

- **Sekundær e-postadresse (del 1, det enkle tilfellet) — ✅ BYGGET OG LIVE
  2026-07-21**, samme dag, rett etter deltaker-tilgang-runden. Ny
  migrasjon `017_secondary_email.sql` (`secondary_email_token` +
  `user_secondary_email`, samme token-hash-og-utløp-mønster som ADR-032s
  `email_change_token`). Nye endepunkter `POST /auth/secondary-email`,
  `POST /auth/secondary-email/confirm`, `DELETE /auth/secondary-email/{id}`.
  **Kjernestykket:** `verify_magic_link`/`login_with_password` slår nå opp
  `user_secondary_email` FØR sitt vanlige `app_user.email`-oppslag — en
  innlogging på en verifisert sekundæradresse løses til EIERENS
  eksisterende konto i stedet for å opprette en ny, separat en (nøyaktig
  det hullet som gjorde funksjonen nødvendig i utgangspunktet). Lagt i
  `/account` (ikke dashbordet som opprinnelig bedt om — bevisst avvik,
  flagget eksplisitt: dette er kun del 1, dashbord-plassering er trolig
  riktigere når/hvis del 2 (kontosammenslåing) bygges).
  **Scratch-verifisert, 20 sjekker:** adresse ikke lagt til før bekreftet,
  token ikke gjenbrukbart, dupliserte adresser (som andres primær- ELLER
  sekundæradresse) avvist tydelig, innlogging via sekundæradresse (magic-
  link OG passord) bekreftet å resolve til SAMME eksisterende konto,
  fremmed kan ikke slette andres adresse, fjernet adresse oppretter en
  genuint NY konto ved neste innlogging (beviser fjerning er reell).
  `test_isolation.sql` 12/12. Ekte typesjekket produksjonsbuild kjørt og
  bekreftet.
  **Rullet ut live 2026-07-21**, bruker bekreftet eksplisitt: migrasjon
  017 kjørt mot ekte `teecup_db` (begge tabeller bekreftet, `test_
  isolation.sql` fortsatt 12/12), deretter `docker compose up -d --build
  teecup_api teecup_frontend`. Begge containere boot-et rent,
  `/health`/`/dashboard`/`/account`/`/verify-email` → 200, `teeoff.no`
  upåvirket. Del 2 (ekte kontosammenslåing) fortsatt IKKE designet, egen
  fremtidig runde, se FEATURE_BACKLOG.md.

- **HCP-historikk over tid — ✅ BYGGET OG LIVE 2026-07-21**, samme dag,
  siste av de tre bekreftede punktene fra dashboard/konto-runden. Ny
  migrasjon `018_handicap_history.sql` (append-only `handicap_history` —
  kun for personlig profil sin `app_user.handicap_index`, IKKE de org-
  scopede `player`/`team_roster`-radene, som har sitt eget uendrede
  reproduserbarhets-prinsipp fra ADR-007). `PATCH /auth/profile` logger nå
  en ny rad KUN ved en FAKTISK endring til en tallverdi — leser gjeldende
  verdi FØR overskriving for å unngå duplikater ved gjentatt lagring av
  samme verdi, og logger bevisst IKKE ved nullstilling. Ny
  `GET /auth/profile/handicap-history`. Frontend: «Vis HCP-historikk»-
  lenke i `/account` sin profilseksjon.
  **Scratch-verifisert, 18 sjekker:** ingen duplikat ved uendret
  gjenlagring, korrekt logging ved reell endring, ingen logg ved
  nullstilling, ny logg ved gjeninnsetting etter nullstilling,
  kronologisk rekkefølge riktig, full isolasjon mellom to brukeres
  historikk. `test_isolation.sql` 12/12. Ekte typesjekket
  produksjonsbuild kjørt og bekreftet.
  **Rullet ut live 2026-07-21**, bruker bekreftet eksplisitt: migrasjon
  018 kjørt mot ekte `teecup_db` (tabell bekreftet, `test_isolation.sql`
  fortsatt 12/12), deretter `docker compose up -d --build teecup_api
  teecup_frontend`. Begge containere boot-et rent,
  `/health`/`/dashboard`/`/account` → 200, `teeoff.no` upåvirket.
  **Dermed er alle tre bekreftede punktene fra dashboard/konto-runden
  (2026-07-21) ferdig bygget** (deltaker-tilgang, sekundær e-post del 1,
  HCP-historikk).

- **Obligatorisk profil-fullføring ved innlogging LIVE (2026-07-22):**
  svar på det pauserte "dashbordets tom-tilstand"-spørsmålet over —
  brukeren avklarte at det ALLER første en innlogget bruker med en
  ufullstendig profil skal se, er en fokusert «Fullfør profilen din»-
  visning, ikke dashbordet. Ny migrasjon `019_profile_country_bio.sql`
  (`app_user.country`, `app_user.bio` — samme nullable-kolonne-mønster
  som resten av profilen, "obligatorisk" håndheves i app-laget).
  `/auth/me` fikk et nytt beregnet felt `profile_complete` (sant når
  fornavn/etternavn/fødselsdato/kjønn/HCP/hjemmeklubb/land ALLE er
  utfylt — bilde og beskrivelse er bevisst unntatt, valgfrie).
  **HCP-grensetilfelle avklart med bruker FØR bygging** (nybegynnere har
  sjelden en offisiell HCP ennå): WHS-maksimum 54 brukes som
  forhåndsutfylt standardverdi i skjemaet (ikke en DB-default), og
  `ProfileUpdate.handicap_index` fikk en hard `le=54`-grense (kan aldri
  registreres høyere) — løser grensetilfellet uten en egen "har ikke
  HCP ennå"-avkrysning.
  `AccountSettings` (`/account`) grener nå: er profilen ufullstendig,
  vises KUN et nytt, fokusert `ProfileOnboarding`-skjema (de obligatoriske
  feltene + valgfri beskrivelse, «Logg ut» tilgjengelig, INGEN tilgang
  til resten av kontosidene) — er den komplett, vises den vanlige
  innstillingssiden som før (nå med land+beskrivelse lagt til i det
  vanlige profilskjemaet, for redigering i etterkant). `app/page.tsx`
  (rot-siden) og `Dashboard`-komponenten sender en innlogget bruker til
  `/account` i stedet for `/dashboard` når profilen er ufullstendig —
  dekker alle innloggingsveier (magic-link/passord/2FA lander alle på
  `/dashboard`, som selv gjør sjekken ved mount).
  **Bevisst avgrenset:** gaten håndheves kun ved disse to naturlige
  inngangspunktene, ikke ved dypere direktelenker til andre autentiserte
  sider — samme skope-disiplin som tidligere runder.
  **Scratch-verifisert, 16 backend-sjekker** (isolert scratch-rolle+
  MinIO+engangs API-container): fersk konto starter `profile_complete:
  false`, delvis utfylling forblir ufullstendig, HCP>54 avvist (422),
  full utfylling gir `true`, beskrivelse er reelt valgfri, å nullstille
  et obligatorisk felt i etterkant slår `profile_complete` tilbake til
  `false`, full isolasjon mellom to kontoer. `test_isolation.sql` 12/12
  uendret. Ekte typesjekket produksjonsbuild + et ekte HTTP-nivå-bevis
  mot en kjørende produksjonscontainer (anonym mot `/` → 200 innloggings-
  skjema, en ekte innlogget-men-ufullstendig sesjonscookie mot `/` →
  `307 → /account`).
  **Rullet ut live 2026-07-22**, bruker bekreftet eksplisitt: migrasjon
  019 kjørt mot ekte `teecup_db` (kolonner bekreftet, `test_isolation.sql`
  fortsatt 12/12), deretter `docker compose up -d --build teecup_api
  teecup_frontend`. Begge containere boot-et rent, `/health`/`/dashboard`/
  `/account`/`/` (anonym) → 200, `teeoff.no` upåvirket. **Merk:** BEGGE
  brukerens egne kontoer (`erol.haagenrud@envide.no` — eier av «Tjøme
  Gents» — og `hei@erol.no`) mangler i dag alle disse feltene og vil
  derfor begge se profil-fullførings-skjemaet ved neste innlogging —
  bekreftet tilsiktet, ikke en bug.
- **Sju punkter fra faktisk bruk av scorekort-skjermen, BYGGET OG LIVE
  2026-07-24:** starthull-bug fikset (`currentHole` respekterte aldri
  `round.start_hole` — `1` er truthy i JS, så `prev || start_hole` var en
  no-op — forklarer trolig også det samtidig rapporterte GIR-avviket,
  siden formelen selv var korrekt), kølle-bag på profilen (28 faste
  typer, maks 14), nytt statistikkfelt «Anywayslag», valgfritt
  statistikknivå per deltaker (default kun slag — ny kolonne
  `round_participant.stat_level`), putt-avstand endret fra fritekst til
  seks faste bøtter, «Hullet er spilt»-avkrysningen fjernet (overflødig
  — spilt settes allerede automatisk ved slagtall). Ny migrasjon
  `022_round_stats_and_bag.sql`. Numpad-layout/retningskors-ikoner for
  tallvelgerne (brukerens punkt 6) er BEVISST holdt utenfor — egen
  V0-prompt utarbeidet i stedet, ikke bygget selv. Full detalj i
  ADR-033. 18 scratch-sjekker, `test_isolation.sql` 12/12, rullet ut mot
  ekte `teecup_db`/`teecup_api`/`teecup_frontend`, `teeoff.no` upåvirket.
- **V0-prompten for numpad/retningskors/sveip-vurdering (punkt 6) BYGGET
  OG LIVE, samme dag:** bruker kjørte prompten, sendte zip 13. V0 valgte
  trykk-baserte Score/Statistikk-faner fremfor sveip (godt begrunnet —
  unngår en tredje sveiperetning på en skjerm som allerede har to).
  Flettet inn i EKSISTERENDE, allerede fungerende datalag (statLevel-
  gating, kølle-bag, anywayslag, putt-bøtter, merge-før-PATCH,
  starthull-fiks, `/my-rounds`-lenker) — ikke en ren erstatning, siden
  V0 ikke kjente til den runden. Full detalj i ADR-033. Typesjekket
  build kompilerte rent, rullet ut (kun `teecup_frontend`), `teeoff.no`
  upåvirket.
- **Enda en runde brukerpunkter, ALLE BYGGET OG LIVE, samme dag:**
  utslagstidspunkt + automatisk tidsbruk-visning (gjenbruker eksisterende
  "Fullfør runde" som "Ferdig", ny `round.started_at`-kolonne, migrasjon
  023), "Idx" → "Hcp", "par"-merking på slag-tastaturet, ni-hulls-
  navigasjonsbug fikset (respekterte aldri `holes_planned`, hoppet feil
  ved "Forrige"), tak på putter/chip/bunker/straffeslag/anywayslag (kan
  ikke overstige antall slag), "Slett runde"-knapp (backend fantes,
  manglet UI), og en ny `PATCH /rounds/{id}` for å rette bane/utslag/
  antall hull MIDT i runden uten å røre allerede registrerte slag —
  sperret etter fullføring. 22+8 scratch-sjekker, `test_isolation.sql`
  12/12, ren build. Full detalj i ADR-033.
- **To til punkter, BYGGET OG LIVE samme dag:** starthull kan nå endres
  uansett (ren metadata), utslagstid justeres når som helst, og
  fullført-tidspunkt kan korrigeres i etterkant — men KUN på en allerede
  fullført runde (løser "glemte å trykke Fullfør runde i flere timer").
  Pluss en ny "Nærmest deg"-liste i bane-søket ved ny runde (Haversine-
  avstand mot alle 174 teeoff-anlegg, geolokasjon i nettleseren, feiler
  stille hvis avslått). 14 nye scratch-sjekker inkl. et ekte nearby-kall
  mot teeoff. Full detalj i ADR-033.
- **Reell UX-bug fikset + "Så langt i runden"-oversikt bygget, samme
  dag (2026-07-25), klar for utrulling:** brukeren rapporterte at "All
  statistikk" ikke viste noe utover slag/putter -- bekreftet (kun
  lesing) mot ekte `teecup_db` at `stat_level='full'` FAKTISK var
  lagret riktig, så feilen var presentasjonen: alle detaljfeltene lå
  bak en "Score"/"Statistikk"-fane fra forrige V0-runde som brukeren
  aldri oppdaget. Fikset ved å fjerne faneløsningen helt -- alt vises nå
  alltid samlet. Samtidig bygget en ny "Så langt"-oversikt
  (`ScoreSoFar`-komponent: kompakt linje + utvidbar full-oversikt-
  tabell med netto per hull), med et nytt backend-felt
  `strokes_received` (`allocate_strokes_by_index()`, ingen ny
  algoritme). 11 nye scratch-sjekker (inkl. et presist tall-eksempel på
  slagfordelingen), ren build. Full detalj i ADR-033.
  **Rullet ut live 2026-07-25**, bruker bekreftet eksplisitt: kun
  `teecup_api`+`teecup_frontend` redeployet, ingen migrasjon,
  `/health`/`/dashboard` → 200, `teeoff.no` upåvirket.
- **Reell produksjonsregresjon rapportert av bruker rett etter utrullingen
  over, funnet og fikset umiddelbart samme dag (2026-07-25):**
  "Ingenting er klikkbart i den avanserte statistikken." Root cause var
  IKKE frontend (all onClick-kabling var korrekt) -- funnet ved å faktisk
  gjenskape brukerens klikk-sekvens mot en fersk scratch-container:
  `update_hole` (hull-PATCH) manglet fortsatt det nye påkrevde
  `strokes_received`-feltet i responsen sin (lagt til i GET-endepunktet i
  runden rett over, glemt i PATCH) -- ga en 500 (Pydantic-valideringsfeil)
  på HVER hull-lagring, ikke bare de avanserte feltene. Frontend svelger
  feilresponsen stille, så symptomet så ut som "ingenting skjer" for
  ALT, ikke bare avansert statistikk (brukeren merket det trolig først
  der siden Slag/Putter fra tidligere runder allerede hadde lagrede
  verdier som så riktige ut). Fikset: `update_hole` beregner nå
  `strokes_received` for hullet som oppdateres, samme algoritme som
  `list_holes`. 14 scratch-sjekker som gjenskaper eksakt klikk-
  rekkefølgen, alle bestått. **Rullet ut live 2026-07-25**, bruker
  bekreftet eksplisitt: kun `teecup_api` redeployet, `/health`/
  `/dashboard` → 200, `teeoff.no` upåvirket.
- **Rediger/Fullfør/Slett tonet ned + flyttet til toppen, auto-scroll ved
  hull-bytte, LIVE samme dag (2026-07-25):** brukeren rapporterte at
  "Fullfør runde"/"Slett runde" var for lette å trykke på ved et uhell
  (lå rett under "Neste hull"). Flyttet alle tre handlingene til en
  nedtonet rad øverst -- må nå aktivt scrolles til. Samtidig: "Neste
  hull"/"Forrige" scroller nå automatisk opp til toppen av hull-panelet
  (også ved direkte hull-valg), så det nye hullets Slag-felt alltid er
  synlig med en gang. Ren frontend-endring, ingen backend/migrasjon.
  Rullet ut, `teeoff.no` upåvirket.
- **"Så langt i runden" utvidet med netto/stableford-sum, putt-/kølle-
  statistikk-totaler og grafisk fairway-/innspill-fordeling, LIVE samme
  dag (2026-07-25):** etterspurt av bruker. Ny `StatPill`-rutenett
  (Slag/Til par/Netto/Stableford/Putt/Chip/Bunker/Straffeslag/
  Anywayslag), Stableford-kolonne i hull-tabellen, og to nye
  `DistributionBar`-seksjoner (Fairwaytreff/Innspill, N-kategori-variant
  av `SegmentedBar`-mønsteret fra tournament-leaderboard.tsx) +
  gjennomsnittlig brutto score-til-par (to desimaler, fortegn) splittet
  på treff-vs-bom for både fairway og innspill. Ingen backend-endring --
  alt beregnes klientside fra data `GET .../holes` allerede returnerer.
  Stableford beregnes alltid ut fra netto score når mulig (appen har
  ingen egen "spilleform"-innstilling). Logikk verifisert manuelt mot et
  regnet eksempel før utrulling. Ren frontend-endring, ingen migrasjon,
  rullet ut, `teeoff.no` upåvirket.
- **"Avstand første putt" flyttet rett under "Putter", LIVE samme dag
  (2026-07-25):** lå tidligere lenger ned i "full"-statistikk-blokken
  (etter kølle/retning/chip-gruppen) -- flyttet til å bli første felt i
  den blokken, rett under Putter-NumberPickeren (som ligger utenfor
  "full"-gaten). Ren omrokkering, ingen ny logikk. Ekte typesjekket
  build, rullet ut, `teeoff.no` upåvirket.
- **V0-prompt for en rikere rundestatistikk-skjerm skrevet, IKKE bygget
  ennå (2026-07-25):** brukeren lastet opp en skjermopptaksvideo
  (`screen-20260724-133013-1784892586987.mp4`, 26 sek, av en KONKURRENT-
  apps statistikkskjerm) og ba om et V0-prompt inspirert av innholdet,
  eksplisitt IKKE et plagiat. Video analysert bilde for bilde (ffmpeg i
  en engangs Docker-container, ikke installert på verten). Innholdet
  identifisert dekkes i stor grad av data vi ALLEREDE sporer
  (fairwaytreff/innspill-retning/putts/chip/bunker/straffeslag/putt-
  lengde-bøtte) -- ingen backend-endring skulle trengtes for de fleste
  målene. Prompt skrevet til bruker i chatten (ikke lagret som egen
  fil) -- beskriver mål/informasjonsarkitektur/tilgjengelighetskrav
  abstrakt (donut med sentertall, gauge-stolper for avvik fra par,
  retnings-diagram for bom-retning) UTEN å kopiere konkurrentens
  eksakte fargevalg/layout/ordlyd, og ber eksplisitt om TeeCups egen
  merkevareidentitet (grønn/oransje) + en egen visuell vri.
  **Én bevisst forskjell fra videoen, valgt for å unngå plagiat OG fordi
  det matcher vårt eget datamodell:** videoens puttlengde-bøtter
  (<1m/1-2/2-4/4-8/+) er ANDRE enn TeeCups allerede lagrede seks bøtter
  (<1m/<2m/<3m/<5m/<8m/8m+, ADR-033) -- promptet ber om TeeCups egne
  bøtter, ikke videoens. "Lengste drive" (krever GPS/avstandsmåling vi
  ikke har) bevisst utelatt fra promptet.
  **Bygget og rullet ut live 2026-07-25, samme dag:** zip 14 mottatt.
  Diffet mot live-treet FØR noe ble tatt inn (samme rutine som alltid) --
  kun to reelt nye filer (`components/round-stats.tsx`,
  `app/rounds/[id]/stats/page.tsx`), resten var V0s vanlige uvitende
  reverts (bl.a. sin egen `/rounds/[id]`-ruteversjon fra FØR
  `/my-rounds`-omdøpingen ADR-033 gjorde 2026-07-23 -- korrekt hoppet
  over). Ruten lagt inn som `app/my-rounds/[id]/stats/page.tsx` i stedet
  (samme kollisjon-unngåelse). `globals.css` sin nye `--chart-1..6`
  data-viz-fargeskala slått sammen inn (V0 sine egne, mer omtrentlige
  `--primary`/`--ring`/`--brand-orange`-verdier IKKE tatt inn -- beholdt
  de presise OKLCH-verdiene fra ADR-016).
  **Datalag skrevet fullstendig om fra mock:** henter `GET /rounds/{id}`
  + `GET .../participants/{id}/holes` (samme endepunkter round-detail.tsx
  allerede bruker) -- ingen ny backend. Ny `computeStats()`-funksjon
  regner ut ALT fra rå hull-data ved lesing (score-kategorier,
  snitt-til-par totalt/per hulltype, fairway-fordeling + score-splitt,
  GIR totalt/per hulltype/kryss-fairway + score-splitt, bom-retning på
  green, putt-fordeling 1/2/3-putt + snitt per hulltype + med/uten GIR,
  én-putt% per TeeCups egne seks puttlengde-bøtter + lengdefordeling
  hit/miss, chip-fordeling, scrambling%, sand save%, bunker/straffeslag
  per runde + score-splitt). Hver seksjon skjules helt når det ikke
  finnes nok data (samme "vis kun det som faktisk finnes"-prinsipp som
  "Så langt i runden"). Ny enkel spillervelger (pill-rad) lagt til når
  runden har flere deltakere -- default til eieren.
  **"Se full rundestatistikk"-lenke** lagt inn i `CompletedBanner` i
  round-detail.tsx (V0s egen versjon hadde denne, men i sin ellers
  fullstendig reverterte fil -- portert manuelt inn i vår LIVE versjon
  i stedet for å ta hele filen).
  **Matematikken verifisert FØR utrulling:** `computeStats()`-logikken
  portert til et frittstående Node-script og kjørt mot et
  hånd-etterregnet 6-hulls syntetisk datasett (blandet par 3/4/5,
  fairwaytreff/-bom, GIR-treff/-bom, bunkerslag) -- alle 15+ utledede
  tall stemte eksakt med manuell utregning. Ekte typesjekket
  produksjonsbuild kjørt og bekreftet (`/my-rounds/[id]/stats` listet
  som ny rute).
  **Rullet ut live 2026-07-25**, ren frontend-endring, ingen migrasjon,
  `docker compose up -d --build teecup_frontend`, `/health`/`/my-rounds`
  → 200, `teeoff.no` upåvirket.
- **Rundeliste + scorekort-redesign, LIVE samme dag (2026-07-25):**
  brukeren delte en ny skjermopptaksvideo av "Egne runder"-listen (som
  manglet ALL score-informasjon) og av scorekort-registreringen (rapportert
  som "veldig dårlig designet" -- for mange ulike knapp-typer stablet
  oppå hverandre) + "Runde fullført"-siden (rapportert som "veldig mye
  dobbel informasjon"). Reflektert over problemstillingen (kort, per
  brukerens ønske) før to V0-prompter ble skrevet.
  **Fikset direkte, uten V0:** "Runde fullført"-duplikatet -- `ScoreSoFar`
  ("Så langt i runden") skjules nå helt når runden er fullført, siden
  den nye rundestatistikk-siden dekker akkurat det samme, langt
  grundigere. Ny backend-beregning i `_load_round_out`
  (`app/routers/rounds.py`): `owner_holes_played`/`owner_total_score`/
  `owner_score_to_par`, en enkel aggregatspørring mot `round_hole` for
  eierens egen deltaker-rad -- verifisert med 10 scratch-sjekker
  (inkl. at en gjests score IKKE påvirker eierens aggregat).
  **Zip 15 og 16 mottatt** (samme v0.app-prosjekt, kontinuerlig --
  `round-card.tsx`/`own-rounds.tsx` identiske i begge, zip 16s
  `round-detail.tsx` var den nyeste med selve scorekort-redesignet; zip
  15 brukt kun for å bekrefte at zip 16 var det riktige, endelige
  eksportet).
  `round-card.tsx` fikk en ny `ScoreTile` -- prominent resultat+til-par
  for fullførte runder, hull-fremdrift-bar ("6/18 hull spilt") for
  runder som pågår, pluss en HCP-differensial-chip når runden telte.
  Datalag i `own-rounds.tsx` skrevet om fra mock til ekte fetch, kobler
  de nye `owner_*`-feltene fra backend + eierens `score_differential`
  (kun vist når `counts_for_handicap`).
  `round-detail.tsx` fikk en ny kollapsbar "Flere detaljer"-seksjon
  (lukket som default) som nå rommer kølle/utslag-retning/innspill-
  retning/chip-bunker-straffeslag/anywayslag -- Slag/Putter/Avstand
  første putt forblir alltid synlig over. Datalag/statLevel-gating/
  bucket-basert puttlengde/maxValue-capping (alt bygget tidligere denne
  økten) bevisst IKKE revertert til V0s eldre mock-baseline, kun selve
  kollaps-mekanismen og plasseringen ble hentet derfra. Lagt til en kort
  kode-kommentar (ikke noe bygget UI ennå) som reserverer plass ved
  siden av hull-headeren til en fremtidig avstandsmåling-indikator,
  bekreftet av bruker at dette kommer senere.
  Ekte typesjekket produksjonsbuild kjørt og bekreftet (alle 19 ruter).
  **Rullet ut live 2026-07-25**, ren frontend-endring (+ den lille
  backend-tilføyelsen over), ingen migrasjon, `/health`/`/my-rounds` →
  200, `teeoff.no` upåvirket.
- **Reelt hull funnet og fikset SAMME dag, rapportert av bruker rett
  etter forrige punkt ("Hvor er scorekortet?"):** da "Så langt i runden"
  ble skjult for fullførte runder (se over), forsvant OGSÅ den eneste
  plassen den rå hull-for-hull-tabellen (Hull/Par/Score/Netto/Sum) fantes
  -- `round-stats.tsx` (den nye dedikerte statistikk-siden) hadde KUN
  utledet/aggregert statistikk (donuter, stolper), ingen tabell med de
  faktiske tallene per hull. Fikset ved å legge til en ny "Scorekort"-
  seksjon FØRST på statistikk-siden (samme tabell-mønster som "Så
  langt" hadde -- Hull/Par/Score/Netto/Stableford/Sum), åpen som
  default. La til `start_hole` i `round-stats.tsx` sin `ApiRound`-type
  og `strokes_received` i `ApiHole`-typen (sistnevnte kom allerede fra
  backend, bare ikke lest av denne siden ennå) for å kunne vise hullene
  i rundens FAKTISKE rekkefølge (samme sirkulære start_hole-logikk som
  round-detail.tsx) i stedet for bare rå hullnummer 1-18. Ekte
  typesjekket build kjørt og bekreftet. Rullet ut, ren frontend-endring,
  ingen backend/migrasjon, `teeoff.no` upåvirket.
- **Ny scorekort-presentasjonsregel + V0-prompt skrevet, IKKE bygget
  ennå (2026-07-25):** brukeren delte et referansebilde av et
  tradisjonelt horisontalt golf-scorekort og formulerte en generell
  regel: hull listet HORISONTALT (som kolonner) → sum TIL HØYRE; hull
  listet VERTIKALT (som rader) → sum UNDER. Dagens "Scorekort"-tabell
  (bygget rett over samme dag) er vertikal med sum som løpende KOLONNE
  -- ikke i tråd med regelen. V0-prompt skrevet (horisontalt scorekort,
  hull 1-9/10-18 som kolonner, Ut/Inn-sum til høyre for hver halvdel,
  Hcp/Par/Score/Netto/Stableford-rader, håndterer både 9- og 18-hulls
  runder med vilkårlig start_hole), bevisst IKKE et plagiat av
  referansebildet (egne farger, egen "Hcp"-term i stedet for bildets
  "Slope", ingen kopiert spiller-header). Full detalj i
  ARCHITECTURE_DECISIONS.md. **Presisert samme dag, før noe ble sendt:**
  brukeren spurte om et mykt "scroll hvis nødvendig"-unntak fanget opp
  målet om ALDRI å måtte scrolle -- svart nei (reell breddekonflikt med
  "lesbar uten briller"-kravet, ikke bare ordlyd) og skrevet om til et
  hardt "ingen scroll"-krav som eksplisitt forteller V0 HVORDAN det
  oppnås (kompakte fete høykontrast-siffer i selve rutenettet, smale
  forkortede rad-labels i en trang gutter -- "lesbar uten briller"
  avgrenset til labels/knapper, ikke enkeltsifre). Full detalj i
  ARCHITECTURE_DECISIONS.md.
  **Zip 17 mottatt og BYGGET/LIVE samme dag:** en ekte HTML `<table>` med
  `<colgroup>` faste kolonnebredder -- ingen scroll-container i det hele
  tatt, løst med kompakte celler i stedet. Score-cellene bruker FORM
  (sirkel=under par, firkant=over par) + fylt/ufylt (2+ slag av) for å
  aldri stole på farge alene, pluss en egen symbolforklaring. Egen,
  NY dedikert side `/my-rounds/[id]/scorecard`
  (`components/round-scorecard.tsx`) -- ikke slått sammen med
  `round-stats.tsx`, siden V0 designet den med egen side-chrome (header,
  rundesammendrag). Datalag skrevet om fra mock til ekte fetch; V0s egen
  `strokesReceived()`-formel (generisk modulo) BEVISST forkastet til
  fordel for backend sin allerede beregnede `strokes_received` (samme
  `allocate_strokes_by_index()` som resten av appen -- unngår to ulike
  HCP-slagfordelings-implementasjoner). Samme sirkulære
  start_hole-rekkefølge som resten av rundeskjermene. Den gamle
  vertikale "Scorekort"-tabellen i `round-stats.tsx` FJERNET (erstattet
  med en lenke til den nye siden) -- `round-stats.tsx` er nå rendyrket
  aggregert statistikk, det rå scorekortet bor kun ett sted. V0 la selv
  til en "Se scorekort"-knapp i `CompletedBanner` (round-detail.tsx) ved
  siden av den eksisterende "Se full rundestatistikk" -- tatt inn.
  **Samtidig, rapportert av bruker:** Anywayslag manglet helt fra
  rundestatistikk-siden sin "Chip, bunker og straffeslag"-seksjon.
  **Feilrettet rett etterpå, samme dag:** min første fiks slo feilaktig
  sammen Anywayslag-tallet i DEN eksisterende seksjonen og omdøpte hele
  seksjonen til "Annet" -- brukeren påpekte at "Chip, bunker og
  straffeslag" skulle beholde navn+innhold uendret, og at "Annet" skulle
  være en EGEN, ny seksjon RETT ETTER med kun anywayslag-tall (total per
  runde + andel hull med anywayslag). Rettet umiddelbart. Notert at et
  fritekst-notatfelt trolig havner i "Annet" senere. Ekte typesjekket
  build kjørt og bekreftet (ny rute `/my-rounds/[id]/scorecard` listet).
  Rullet ut (to runder), ren frontend-endring, ingen backend/migrasjon,
  `teeoff.no` upåvirket.
- **Rundestatistikk-seksjonene starter nå kollapset, LIVE samme dag
  (2026-07-25):** brukeren ba om at "trekkspillet" (StatCard-seksjonene
  på `/my-rounds/[id]/stats`) skal vises sammenslått -- må klikkes for å
  se innholdet. `StatCard` sin `defaultOpen` endret fra `true` til
  `false` (ingen kallsted overstyrte den, så én linje dekket alle
  seksjonene). Ekte typesjekket build, rullet ut, `teeoff.no` upåvirket.
- **Notert i FEATURE_BACKLOG.md, IKKE bygget:** brukeren ba om et notat
  om et femte fremtidig turneringsformat, "Flaggturnering" (utover de
  fire fra 2026-07-19-runden) -- krever en visning av GJENSTÅENDE slag
  for spilleren, oppdatert etter hvert hull, pluss en fremtidig idé om
  å bruke GPS (når/hvis integrert) til å markere hvor langt spilleren
  faktisk kom. Lagt til i samme seksjon som de fire andre formatene.

- **Tre punkter fra brukeren, ALLE BYGGET, SCRATCH-VERIFISERT OG LIVE
  2026-07-25:** (1) enkeltbane-anlegg (f.eks. Tjøme Golfklubb) dropper nå
  det overflødige banenavnet ved import/runde-opprettelse — kun "Tjøme
  Golfklubb", ikke "Tjøme Golfklubb – Hovedbanen" (flerbane-anlegg som
  Ålesund beholder uendret "Anlegg – Bane"-navn). (2) Runder kan nå
  navngis (`round.name`, migrasjon `024_round_name.sql`, valgfritt,
  redigerbart i etterkant) — vises på tvers av rundeliste/rundeside/
  scorekort/statistikk, faller tilbake til banenavn når ikke satt. (3)
  Profilens "Land"-felt er nå en nedtrekksliste (kun "Norge" foreløpig,
  klargjort for flere), plassert FØR "Hjemmeklubb", som selv ble
  omgjort til en søkbar liste mot teeoffs klubbregister (gjenbruker
  eksisterende `/rounds/official-search`, ingen ny backend-kode). Full
  detalj i ARCHITECTURE_DECISIONS.md. Bruker bekreftet eksplisitt:
  migrasjon 024 kjørt mot ekte `teecup_db`, `test_isolation.sql` fortsatt
  12/12, begge containere redeployet, `/health`/`/dashboard`/`/my-rounds`/
  `/account` → 200, `teeoff.no` upåvirket.

- **Refleksjonsrunde 2026-07-25: hvorfor organisasjon? + venner/deling —
  DESIGNET, IKKE bygget.** Brukeren spurte hvorfor organisasjon i det
  hele tatt trengs, gitt at ADR-033 nå gjør en enkelt bruker fullt
  selvstendig. Veide A (bruker-eide turneringer, som runder) mot B
  (organisasjon beholdt, men opprettelsen gjøres usynlig/automatisk) —
  A avvist (ville krevd duplisering av HELE turnering-apparatet som er
  bygget rundt RLS/`organization_id`, og er ikke reversibelt i noen
  retning), B valgt (rører verken skjema eller de ni eksisterende
  routerne, kun frontend-orkestrering — `POST /orgs` krever allerede kun
  `name`). Skrevet som **ADR-035** (organisasjon-B-beslutningen + et
  konkret 7-blokks dashbord-forslag: Hurtighandlinger/Kommende runder/
  Kommende turneringer/Statistikk/Spilte baner/Venner/Organisasjoner —
  sistnevnte nedtonet, kun synlig ved reelt flere org-er) og **ADR-036**
  (nytt vennekonsept — gjensidig forespørsel/aksept, privat
  kategorisering i faste grupper som Make/Nær familie/Golfvenner/osv.,
  ny rundevisibilitet `public`/`private`/`friends` med eksplisitt
  gruppevalg, og et tiered personsøk — venner→samme klubb→samme
  land→globalt, navnerekkefølge-uavhengig — delt mellom "finn venn" og
  en fremtidig "legg til ekte medspiller"-utvidelse av
  `round_participant.user_id`, som allerede lå ubrukt i skjemaet som en
  eksplisitt notert "v1-avgrensning" i ADR-033). V0-prompt for det nye
  dashbordet skrevet (i FEATURE_BACKLOG.md), IKKE sendt til V0 ennå.
  **Ingen kode skrevet** — bevisst en design-/dokumentasjonsrunde, ikke
  en byggerunde, på brukerens eksplisitte instruks. Full detalj i
  ARCHITECTURE_DECISIONS.md (ADR-035/036) og FEATURE_BACKLOG.md (åpne
  spørsmål, foreslått 3-fase byggerekkefølge for venner-delen).
- **Oppfølging samme dag:** bruker bekreftet at en lagt-til ekte
  medspiller SKAL se runden i sin egen "Egne runder"-liste (ADR-036 fase
  3, tidligere bevisst uavklart). Presiserte samtidig en ny teknisk
  konsekvens i ARCHITECTURE_DECISIONS.md: `RoundOut` sine
  `owner_*`-statistikkfelt må bli viewer-relative, ikke alltid eierens,
  og et NYTT åpent spørsmål dukket opp — skal medspilleren også kunne
  SKRIVE egne hull-tall, ikke bare lese? Ikke avgjort. Fortsatt ingen
  kode skrevet.

- **Dashbord-redesign (ADR-035) BYGGET, IKKE ENNÅ RULLET UT (2026-07-25):**
  zip 18 mottatt og integrert — kun `dashboard.tsx` var reelt nytt (samme
  full-reeksport-mønster som alltid), pluss en genuin MERGE (ikke revert)
  i `tournament-card.tsx`: V0s nye `organizer`-merkelapp lagt til SIDE OM
  SIDE med den eksisterende `orgId`-baserte lenkelogikken (offentlig vs.
  innlogget kontekst) som V0 ikke kjente til. Datalag skrevet fra bunnen:
  "Kommende turneringer" slår sammen deltaker- (`me.my_tournaments`) og
  arrangør-turneringer (hentet per org, alle organisasjoner brukeren er
  medlem i) til ÉN tidssortert liste, filtrert til `draft`/`active`-status.
  "Statistikk"/"Spilte baner" er REN klientside-utledning fra eksisterende
  `GET /rounds` + `GET /auth/profile/handicap-history` — ingen nye
  endepunkter trengt. "Ny turnering"-hurtighandlingen implementerer selve
  ADR-035-mekanismen: oppretter/gjenbruker organisasjon USYNLIG først
  (kun ved faktisk innsending, ikke når skjemaet åpnes — unngår en
  foreldreløs org ved avbrutt skjema), deretter turneringen, deretter
  navigerer rett inn i den. "Bli med med kode" gjenbruker samme
  `by-code`-oppslag som `login-form.tsx` sin `JoinByCode`, nå som en
  dashbord-lokal variant. "Venner"-seksjonen vises med en ærlig
  tom-tilstand (ADR-036 er ikke bygget ennå) — CTA-en er bevisst uten
  href/onClick, ikke en lenke til noe som ikke finnes. "Spilte baner"
  fikk sine listeelementer gjort om til ren visning (ikke lenker) siden
  API-et ikke eksponerer noen stabil bane-id å lenke til per runde.
  Ekte typesjekket produksjonsbuild kompilerte rent, alle 21 ruter
  listet. **Rullet ut live 2026-07-25**, bruker bekreftet eksplisitt:
  `docker compose up -d --build teecup_frontend` (gjenskapte også
  `teecup_api` som vanlig bivirkning, ingen backend-kode rørt). Begge
  containere boot-et rent, `/health`/`/dashboard`/`/my-rounds` → 200,
  `teeoff.no` upåvirket.
- **Oppfølging samme runde, avklart med bruker:** medspillere skal kunne
  registrere score for HELE flighten (ikke bare egen rad) når ADR-036
  fase 3 bygges — oppdatert i ARCHITECTURE_DECISIONS.md/FEATURE_BACKLOG.md.
  To nye notater lagt i FEATURE_BACKLOG.md (ingen design/bygging ennå,
  kun fanget opp): (1) turneringsoppsett mangler en vei til å FLYTTE en
  rostret spiller til et annet lag (kun fjerning finnes i dag), (2) et
  reelt modelleringsspørsmål om flere flighter i én frittstående runde
  (f.eks. "min flight + vennenes flight bak oss samme dag") — to
  prinsipielt ulike retninger skissert, ingen valgt.

- **ADR-036 fase 1 (venner-kjernen) BYGGET OG SCRATCH-VERIFISERT, IKKE
  ENNÅ RULLET UT (2026-07-25):** ny migrasjon `025_friends.sql`
  (`friendship` + `friend_categorization`, ingen RLS — samme
  `plain_connection()`-mønster som runder) og nytt `app/routers/
  friends.py`: `GET /people/search` (tiered venn→klubb→land→globalt,
  navnerekkefølge-uavhengig token-matching, min. 2 tegn før noe
  returneres), `POST /friends`/`POST /friends/{id}/accept`/
  `DELETE /friends/{id}` (forespørsel/aksept/avslå-kanseller-avvenn — én
  DELETE dekker alle tre), `GET /friends`, `PUT /friends/{friend_user_id}/
  categories` (erstatter hele settet, krever akseptert vennskap). Router
  registrert i `main.py`, `/people`+`/friends`-rewrites lagt til i
  `next.config.mjs` (ny frontend-rute vil hete `/my-friends`, IKKE
  `/friends` — unngår samme kollisjonsfelle som `/rounds` fra før).
  **Scratch-verifisert grundig** (isolert rolle+MinIO+engangs API-
  container, 5 syntetiske brukere): 31 sjekker, inkl. presist bevist
  tiered rangering for 4 distinkte brukere samtidig, og at
  kategorisering er EKTE PRIVAT (bekreftet: B ser aldri kategoriene A
  satte B i). `test_isolation.sql` fortsatt 12/12. Ekte typesjekket
  produksjonsbuild kompilerte rent. **Rullet ut live 2026-07-25**, bruker
  bekreftet eksplisitt: migrasjon 025 kjørt mot ekte `teecup_db` (begge
  tabeller bekreftet, `test_isolation.sql` fortsatt 12/12), deretter
  `docker compose up -d --build teecup_api teecup_frontend`. Begge
  containere boot-et rent, `/health`/`/dashboard` → 200, `teeoff.no`
  upåvirket. Verifisert presist at ruten faktisk når FastAPI (ikke bare
  at Next.js svarte): anonymt `GET /people/search`/`GET /friends` over
  ekte https ga korrekt `401 NOT_AUTHENTICATED`, ikke en rå 404. Frontend
  bevisst IKKE hånd-kodet denne gangen (V0-prompt skrevet i
  FEATURE_BACKLOG.md i stedet, matcher etablert mønster/tidligere
  korrigering) — venter på at brukeren kjører den i v0.app.

- **ADR-036 fase 1 FRONTEND BYGGET, IKKE ENNÅ RULLET UT (2026-07-25):**
  zip 19 mottatt og integrert — kun `components/friends.tsx` og
  `app/friends/page.tsx` var reelt nye fra V0 (samme full-reeksport-
  mønster som alltid, resten forventede reverts av allerede tilpassede
  filer, hoppet over). **V0s egen rute (`/friends`) BEVISST IKKE brukt**
  — flyttet til `/my-friends`, siden `/friends` nå er API-prefikset
  (samme kollisjonsklasse som `/rounds` → `/my-rounds` tidligere, unngått
  fra start denne gangen i stedet for oppdaget i produksjon).
  Datalag skrevet fullstendig om fra V0s mock til ekte fetch mot
  `/people/search`+`/friends`-endepunktene — TS-typene speiler Pydantic-
  modellene i `app/routers/friends.py` felt-for-felt. Kategori-koder
  (`spouse`, `golf_friends`, osv.) mappet mot V0s norske visningsnavn via
  en delt `CATEGORY_OPTIONS`-liste i SAMME rekkefølge som backend sin
  `Category`-type. Søkefeltet håndhever samme 2-tegns-minimum som
  backend (viser en forklarende tekst i stedet for å bare returnere
  tomt). "Send forespørsel"/"Godta"/"Avslå"/"Kanseller"/"Fjern venn"
  trigger alle en full refetch av `GET /friends` etterpå (samme
  refetch-etter-mutasjon-mønster som resten av appen) — kun kategori-
  avkrysning er lokalt optimistisk (matcher PUT-endepunktets
  erstatt-hele-settet-kontrakt).
  **Dashbordets "Venner"-blokk koblet til ekte data i samme runde:**
  root-komponenten henter nå `GET /friends`, viser ekte avatar-initialer
  + antall venner + ventende forespørsler (samme visuelle design som
  opprinnelig i zip 18, som ble bevisst forenklet til en inert tom-
  tilstand forrige runde siden backend ikke fantes ennå) — begge
  knappene ("Se venner"/"Søk etter venner") lenker nå til `/my-friends`.
  Ekte typesjekket produksjonsbuild kompilerte rent, `/my-friends` listet
  blant 22 ruter. **Rullet ut live 2026-07-25**, bruker bekreftet
  eksplisitt: `docker compose up -d --build teecup_frontend` (gjenskapte
  også `teecup_api` som vanlig bivirkning, ingen backend-kode rørt).
  Begge containere boot-et rent, `/health`/`/dashboard`/`/my-friends` →
  200, `teeoff.no` upåvirket. **ADR-036 fase 1 (venner-kjernen) er
  dermed helt ferdig, backend + frontend, live.**

- **Notat 2026-07-25: scramble-statistikk (utslag brukt per spiller) —
  IKKE bygget, kun fanget opp.** Brukeren ba om at scramble-turneringer
  skal føre statistikk over hvor mange ganger hver spillers utslag ble
  valgt av laget. Dette er reelt NY datamodell — dagens `hole_score`/
  `match_hole_result` for scramble er en delt rad per side, ingen
  kobling til HVILKEN spiller sitt utslag ble brukt. Trolig samme
  problemstilling for greensome. Krysset mot det allerede eksisterende
  "Scramble-grensesnitt"-punktet i ARCHITECTURE_DECISIONS.md sin "Åpne
  spørsmål"-seksjon, full detalj i FEATURE_BACKLOG.md.

- **Bug fikset: `display_name` synkroniserte aldri med for-/etternavn
  (2026-07-25), rapportert av bruker med skjermbilde av dashbordet.**
  `app_user.display_name` settes i dag KUN fra e-postens lokaldel ved
  kontoopprettelse (`verify_magic_link`) — ADR-031s profil-fullføring la
  til atskilte `first_name`/`last_name`-felt, men rørte aldri
  `display_name`. Konsekvens: en bruker med fullstendig utfylt profil
  viste fortsatt e-post-avledet plassholdernavn overalt `display_name`
  brukes (org-medlemslister, invitasjons-e-post, dashbord-hilsen — ikke
  bare dashbordet). **Fikset** i `app/routers/auth.py` sin
  `update_profile`: synkroniserer nå `display_name` automatisk til
  `"{first_name} {last_name}"` hver gang et av de to feltene endres via
  `PATCH /auth/profile` — KUN når begge er satt etterpå (unngår et
  halvferdig navn ved delvis utfylling). Scratch-verifisert (7/7 sjekker:
  fersk konto får fortsatt e-post-plassholder, delvis utfylling (kun
  fornavn) rører IKKE `display_name` ennå, komplett for-/etternavn
  synkroniserer korrekt, urelaterte PATCH-er (f.eks. HCP) lar
  `display_name` stå urørt, en SENERE navneendring re-synkroniserer på
  nytt).
  **Rullet ut mot ekte systemer 2026-07-25**, bruker bekreftet
  eksplisitt (valgte "kjør begge deler"): `teecup_api` redeployet, samt
  en engangs data-rettelse kjørt direkte mot ekte `teecup_db`
  (`UPDATE app_user SET display_name = ... WHERE first_name/last_name
  utfylt OG display_name avvek`) for å rette allerede-utfylte kontoer
  som ikke ville blitt rettet av seg selv (krever en NY navneendring for
  å trigge synk-koden). Bekreftet FØR kjøring med en dry-run `SELECT`
  (2 kontoer berørt: `erolhaagenrud@gmail.com` → "Tore Morell",
  `hei@erol.no` → "Erol Haagenrud"), kjørt med `RETURNING` for å
  bekrefte nøyaktig hvilke rader som ble endret, `test_isolation.sql`
  fortsatt 12/12 etterpå. Ingen migrasjon (ren datarettelse + kodefiks).

- **Varsler (push til telefon + in-app varslingssenter) — DESIGNET
  2026-07-25, IKKE bygget.** Brukeren spurte om dagens PWA kan varsle
  telefonens eget system (f.eks. ny venneforespørsel), og ba om en
  in-app-fallback (bjelle-indikator + uleste-side) med et V0-prompt klart
  "i tilfelle". Svar: ekte push er teknisk mulig (ADR-028s PWA-fundament),
  men iOS Safari krever PWA-en installert til hjemskjermen for at Web
  Push skal fungere i det hele tatt, pluss ny infrastruktur (VAPID,
  `push_subscription`-tabell, `pywebpush`-utsending, eksplisitt
  tillatelse) — anbefalt som EGEN, senere runde, ikke første steg.
  Anbefalte i stedet et in-app varslingssenter først (ny
  `notification`-tabell, triggerpunkter ved venneforespørsel sendt/
  akseptert, ny `/my-notifications`-rute — ikke `/notifications`, samme
  kollisjonsklasse unngått som `/rounds`/`/friends`). V0-prompt skrevet
  i FEATURE_BACKLOG.md, ikke sendt ennå. Ingen kode skrevet — ren
  design-/dokumentasjonsrunde.

- **Oppfølging samme dag: e-post-fallback for varsler + PWA-
  installasjon vurdert, IKKE bygget.** Varsel-V0-prompten sendt til
  bruker. Bruker foreslo en betinget e-post-fallback ved venneforespørsel
  (kun hvis mottaker har samtykket til e-post fra TeeCup) — sjekket at
  INGEN generell kommunikasjons-samtykke-flagg finnes i dag (kun
  ADR-017s turnering-registrerings-samtykke, noe annet), foreslo nytt
  opt-in `app_user.notification_emails_enabled` + en sjette
  `send_friend_request_email()`-funksjon i `app/email.py` (samme mønster
  som de fem eksisterende). Bruker spurte også hvordan få brukere til å
  installere PWA-en "nærmest umiddelbart" — vurdert grundig: Android kan
  fange `beforeinstallprompt` og vise egen timing, iOS Safari har INGEN
  programmatisk installasjonsvei (kun instruksjonsoverlegg mulig, hard
  Apple-begrensning) — anbefalte å vise oppfordringen rett etter
  obligatorisk profil-fullføring (universelt sjekkpunkt alle nye brukere
  allerede går gjennom) fremfor bokstavelig "umiddelbart". Begge kun
  vurdert/skissert i FEATURE_BACKLOG.md, ingen kode skrevet, intet
  V0-prompt for PWA-delen ennå.

- **To nye drøftingspunkter, IKKE besluttet eller bygget (2026-07-25):**
  bruker lastet opp to skjermbilder av Golf GameBooks leaderboard-løsning
  (egen "Leaderboards"-fane, rangert liste, trykk-ut til fullt
  scorekort) og spurte om (1) et tilsvarende leaderboard for
  runder/turneringer, usikker på plassering, og (2) om TeeCup burde få
  1-2 nye designfarger. Drøftet grundig i FEATURE_BACKLOG.md, ikke
  konkludert: fant at "runder" kan få dette NÅ (flere-deltakere-støtte
  finnes allerede, ingen ADR-036-avhengighet) mens "turneringer" sitt
  EKSISTERENDE leaderboard er lag-poeng (Ryder Cup-matchplay), strukturelt
  noe annet enn Golf GameBooks individuelle rangering — åpent
  avklaringsspørsmål. For fargespørsmålet: fant at en blåtone ALLEREDE
  finnes i `--chart-3` (bare ikke løftet til en kjerne-designtoken) —
  anbefalte å gjenbruke DEN i stedet for å finne på en helt ny, og
  anbefalte mot flere enn én ekstra farge. Ingen kode skrevet, ingen
  V0-prompt — ren refleksjonsrunde på brukerens eksplisitte instruks.

- **In-app varslingssenter + rundeleaderboard-backend BYGGET OG SCRATCH-
  VERIFISERT (2026-07-26), IKKE ENNÅ RULLET UT:** to ting i samme runde.
  (1) Brukeren lastet opp zip 20 — resultatet av varsel-V0-prompten fra
  2026-07-25 (bjelle-ikon i dashbord-header, egen varslingsside). Bygget
  matchende backend: migrasjon `026_notifications.sql` (tabell
  `notification`, `plain_connection()`-mønster som resten av bruker-eid
  data), `app/routers/notifications.py` (fire endepunkter + delt
  `create_notification()`-hjelpefunksjon), to trigger-punkter i
  `friends.py` (venneforespørsel sendt/akseptert — de eneste hendelsene
  som faktisk finnes i dag). Frontend integrert kirurgisk (kun de nye
  filene + et uttrekk fra V0s dashbord-eksport, ikke en full revert):
  `components/notifications.tsx` skrevet om fra V0s mock-scenario til
  ekte fetch, ny rute `/my-notifications` (IKKE `/notifications` — samme
  kollisjonsklasse unngått fra start som `/rounds`/`/friends`),
  bjelle-komponenten portert inn i den LIVE `dashboard.tsx` sin header,
  koblet til et ekte `GET /notifications/unread-count`-kall.
  (2) Brukeren ba samtidig om et leaderboard for frittstående runder
  (opptil 13+ spillere mulig, flere flighter). Bygget ny
  `GET /rounds/{round_id}/leaderboard` i `app/routers/rounds.py` — brutto
  OG netto score-til-par + "thru"-antall PER deltaker, sortert stigende
  på brutto. Netto bruker samme `allocate_strokes_by_index`-algoritme som
  resten av appen (`strokes_received` i `list_holes`), denne gangen
  summert over KUN de faktisk spilte hullene.
  **Scratch-verifisert grundig, 39/39 sjekker i to testløp** (isolert
  `teecup_app_scratch`-rolle + isolert scratch-MinIO + engangs API-
  container, samme mønster som hele prosjektet): full varsel-syklus begge
  retninger + `mark-all-read` + kryss-bruker-isolasjon (bruker B kan ikke
  markere bruker A sitt varsel som lest via id-gjetting), full
  leaderboard-runde (3 deltakere, ulik fremdrift/score, riktig rangering/
  thru/to-par for alle), kryss-bruker-autorisasjon (403), ukjent
  runde-id (404) — OG en dedikert netto-kryssjekk der resultatet ble
  sammenlignet mot en HELT UAVHENGIG beregning via
  `handicap_engine.allocate_strokes_by_index` kalt direkte fra
  testskriptet (ikke bare "endepunktet svarte 200") — stemte eksakt,
  inkl. et bevisst vekslende stroke-index-mønster og kun 9 av 18 hull
  spilt, for å teste allokeringen over et REELT delvis spilt sett, ikke
  et trivielt sammenfallende tilfelle. `test_isolation.sql` fortsatt
  12/12. Ekte typesjekket produksjonsbuild av frontend kompilerte rent,
  `/my-notifications` listet blant rutene.
  **V0-prompt for selve leaderboard-VISNINGEN skrevet og sendt til
  bruker** (se FEATURE_BACKLOG.md for hele prompten) — rangering med
  delt plassering, brutto/netto-veksling, "thru X"/"Ferdig"-tilstander,
  kompakt mini-variant til rundens detaljside, alltid form+farge for
  over/under par. Ikke kjørt i v0.app ennå — leaderboardets FRONTEND
  kommer i en senere runde.
  **Rullet ut live 2026-07-26**, bruker bekreftet eksplisitt: migrasjon
  026 kjørt mot ekte `teecup_db` (tabell `notification` bekreftet,
  `test_isolation.sql` fortsatt 12/12), deretter `docker compose up -d
  --build teecup_api teecup_frontend`. Begge containere boot-et rent,
  `/health`/`/dashboard`/`/my-notifications` → 200, `teeoff.no`
  upåvirket. Verifisert presist at `/notifications`-ruten faktisk når
  FastAPI (ikke bare at Next.js svarte): anonymt `GET /notifications`
  over ekte https ga korrekt `401 NOT_AUTHENTICATED`, ikke en rå 404.

- **Navneformat-regel + turnering-scope avklart, IKKE bygget (2026-07-26):**
  brukeren instruerte at direkte adressering (hilsener, e-post/varsler
  rettet til mottakeren) alltid skal bruke KUN fornavn, mens vanlige
  visninger (lister, roster, chat) fortsatt bruker fullt navn/initialer —
  lagt til som ny stående regel (se egen seksjon over). Kjent brudd
  notert: dashbord-hilsenen bruker i dag fullt navn, ikke rettet ennå.
  Deretter bedt om analyse av .md-filene for prioritering — landet på å
  avklare turnering-leaderboard-spørsmålet fra 2026-07-25 først. Svaret
  avdekket et vesentlig STØRRE ønske enn antatt: TeeCup skal etter hvert
  støtte ekte INDIVIDUELLE turneringer (ikke bare lag), disse skal kunne
  gå over flere runder, og det skal være mulig med et Order of Merit
  (sesong-sammenlagt på tvers av flere arrangementer, brukerens eksempel:
  "klubbdager" gjennom en sesong). Grundig notert i FEATURE_BACKLOG.md og
  ARCHITECTURE_DECISIONS.md (ADR-011s eget notat + ny "Åpne spørsmål"-
  post 6) — inkl. en reell strukturell kollisjon identifisert: en
  flerrunde-individuell-turnering vil kollidere med ADR-033 sitt bevisst
  org-UAVHENGIGE frittstående rundesystem, må avklares eksplisitt før
  bygging. **Ren notat-runde, ingen ADR skrevet, ingen kode** — brukeren
  ba eksplisitt kun om at dette dokumenteres nå.
- **Flere flighter i én frittstående runde — presisert videre, fortsatt
  IKKE besluttet (2026-07-26):** oppfølgende avklaring samme runde.
  Brukeren presiserte: oppsett av flere flighter er ÉN handling utført av
  én person (samme gjest-mønster som i dag, bare flere flight-grupper),
  scoreregistrering per flight er et SENERE, separat ansvar (forventet
  løst av ekte medspillere, ADR-036 fase 3) — og viktigst: leaderboardet
  skal KUN dekke flightene som ble satt opp SAMMEN i én handling, ikke
  "alle som spilte samme bane samme dag". Det siste peker sterkt mot
  retning 1 (løs gruppering av separate `round`-rader) fra forrige
  runde, men er ikke formelt bekreftet som byggeretning. Brukeren
  påpekte selv at dette ligger i grenselandet mot "individuelle
  turneringer"-punktet rett over — notert eksplisitt som en mulig
  forening av de to, ikke to separate systemer. Se FEATURE_BACKLOG.md
  for full detalj. Ren notat-runde, ingen kode, ingen ADR.

- **ADR-037 skrevet: grunnstruktur for individuelle/flerrunde-turneringer
  (2026-07-26), samme dag som de to foregående notat-rundene.** Bruker ba
  om å starte ADR-runden på strukturspørsmålet direkte (ikke bare
  notere). Fire load-bærende beslutninger avklart eksplisitt
  (AskUserQuestion), i rekkefølge: (1) ny, PARALLELL org-scopet
  datamodell for individuelle turneringer — IKKE en utvidelse av
  ADR-033s frittstående `round`-tabeller, bevisst for å unngå hybrid/
  betinget RLS (samme risikoklasse som den tidligere RLS-tomstreng-
  bugen) og for å bevare ADR-033 Beslutning A urørt; (2) SAMME
  `tournament`-tabell med en ny `format_type`-diskriminator
  (`'team'`/`'individual'`), ikke en helt ny toppnivå-entitet —
  gjenbruker synlighet/join-kode/status (ADR-018/020) uendret; (3)
  flerrunde-støtte fra START via en ny `tournament_round`-tabell
  (økt-lignende), sammenlagt resultat summert ved lesing på ekte
  deltaker-id (samme prinsipp som dagens lag-leaderboard); (4) rå
  brutto slagtall lagres OG et ferdig utregnet poengtall CACHES per
  scoringsmetode — samme etablerte mønster som `match.status_text`/
  `points_side_a/b` — nye formater (Københavner m.fl.) blir dermed i
  hovedsak én ny motorfunksjon + én ny CHECK-verdi, ikke en
  skjemaendring.
  **Viktig presisering som oppsto underveis, endrer forrige rundes
  antakelse:** "flight" i en formell org-turnering er KUN en
  tee-tid-gruppering — leaderboardet spenner alltid HELE feltet.
  Dette er strukturelt ULIKT den ad hoc "flere flighter i en
  frittstående runde"-ideen (der leaderboardet bevisst avgrenses til
  det man selv satte opp) — de to holdes derfor bevisst ADSKILT, ikke
  forent slik forrige runde antydet. Begge berørte FEATURE_BACKLOG.md-
  seksjoner oppdatert med denne presiseringen.
  **Fortsatt IKKE avgjort:** de fem konkrete formatenes egne poengregler
  (Københavner m.fl., egne mindre design-runder oppå denne strukturen),
  og Order of Merit (sesong-sammenlagt, bekreftet som naturlig SISTE
  steg). **Ingen migrasjon eller kode skrevet** — ADR-037 er ren
  struktur-beslutning; neste steg er et konkret migrasjonsutkast
  (nye tabeller + `tournament.format_type`) lagt frem til gjennomgang
  før noe kjøres.

- **"Fiks alle kjente små bugs"-runde, BEGGE FIKSET OG SCRATCH-VERIFISERT
  (2026-07-26), samme dag som ADR-037:** brukeren ba eksplisitt om å
  rydde opp i alle dokumenterte, fortsatt åpne små bugs. Systematisk
  gjennomgang av CLAUDE.md/FEATURE_BACKLOG.md (søk på "IKKE fikset"/
  "urelatert bug" m.fl.) fant at nesten alt tidligere flagget som
  "ikke fikset" faktisk ble fikset i en SENERE runde lenger ned i loggen
  (stale seksjonsoverskrifter, ikke reelt åpne bugs) — kun to genuint
  fortsatt åpne:
  1. **Dashbord-hilsen brukte fullt navn** (nettopp etablert
     navneformat-regel, se egen seksjon over) — `me.first_name ??
     me.display_name` i stedet for `me.display_name` alene.
     `/auth/me` eksponerte allerede `first_name`, ingen backend-endring.
  2. **Stroke-modus-scoreinnsending på en bane UTEN registrerte hull
     krasjet rått (500 IndexError)** i stedet for en ren
     `VALIDATION_FAILED` — `scoring.py` sin `_compute_hole_results`
     kalte `allocate_over_played_holes` med en TOM stroke-indeks-liste
     når `hole`-tabellen var tom for banen (f.eks. en egendefinert bane
     der noen glemte å legge til de 18 hullene). Fikset med en eksplisitt
     `len(all_18_si) != 18`-sjekk RETT FØR beregningen — samme mønster
     som den allerede kjente/fikset manglende-handicap-indeks-krasjen
     fra blind draw-runden (2026-07-18).
  **Scratch-verifisert grundig (5/5 sjekker)** for backend-fiksen
  (isolert `teecup_app_scratch`-rolle + isolert scratch-MinIO + engangs
  API-container, samme mønster som ellers i prosjektet): en bane UTEN
  hull ga korrekt `400 VALIDATION_FAILED` ved scoreinnsending (ikke
  500), OG en egen regresjonssjekk bekreftet at en NORMAL bane (alle 18
  hull) fortsatt scorer helt uendret (begge sider, full
  scorekort-henting via `GET .../scorecard`). `test_isolation.sql`
  12/12 uendret — ren Python-logikk-fiks, ingen migrasjon. Ekte
  typesjekket produksjonsbuild av frontend kompilerte rent (dashbord-
  fiksen). To stale FEATURE_BACKLOG.md-seksjonsoverskrifter rettet
  samtidig ("Rapporterte UI-/UX-hull" og selve bug-notatet), siden de
  fortsatt sa "IKKE fikset" lenge etter at innholdet faktisk var
  fikset.
  **Rullet ut live 2026-07-26**, bruker bekreftet eksplisitt: ingen
  migrasjon, `docker compose up -d --build teecup_api teecup_frontend`,
  begge containere boot-et rent (`Application startup complete`, Next.js
  `Ready`), `/health`/`/dashboard` → 200, `teeoff.no` upåvirket.

- **ADR-036 fase 3 (delvis): søk+legg til ekte medspiller på en
  frittstående runde, BYGGET OG SCRATCH-VERIFISERT (2026-07-26), IKKE
  ENNÅ RULLET UT:** brukeren rapporterte at "+ Gjest"-skjemaet ikke
  søkte etter spillere når man skrev et navn — bekreftet reelt (rent
  tekstfelt, `/people/search` var aldri koblet på). Spurte om
  omfang før bygging: brukeren ville ha "full tilgang nå" (medspilleren
  kan selv registrere score), ikke bare rask utfylling — et bevisst
  større valg enn det anbefalte minimum.
  **Backend:** `POST /rounds/{id}/participants` tar nå ENTEN `user_id`
  (funnet via tiered `/people/search`, samme algoritme som vennesøket)
  ELLER `guest_name` (uendret) — kjønn/HCP hentes automatisk fra den
  valgte personens egen profil. Ny migrasjon `027_round_participant_
  user_unique.sql` (partiell unik indeks). Ny `_get_accessible_round_
  or_404` (eier ELLER lenket medspiller) for lesing/hull-scoring/
  fullføring — `_get_owned_round_or_404` (strengt eier-only) beholdt
  for rediger/slett/legg til/fjern/endre stat_level. `RoundOut` sine
  `owner_*`-felt omdøpt til `my_*` og gjort VIEWER-relative (regnes nå
  fra den spørrende brukerens egen deltaker-rad).
  **Reell latent bug funnet OG fikset i SAMME runde, før den nådde
  produksjon:** leaderboard-endepunktet (bygget tidligere samme dag,
  se over) ville vist et TOMT navn for enhver lenket medspiller, siden
  dets `display_name`-utledning kun sjekket `is_owner`, ikke om
  `user_id` var satt i det hele tatt. Fanget under scratch-testing av
  DENNE runden, fikset før utrulling av noen av delene.
  **Frontend:** "+ Gjest" omdøpt til "+ Medspiller" i `round-detail.tsx`,
  nytt søk-som-du-skriver-felt (avatar-initialer, hjemmeklubb) med
  "Legg til uten konto"-fallback til det gamle tekstfeltet. Viewer-
  relativ "Deg"-visning (ny `/auth/me`-bruk for viewerId) — samme fiks
  portert til `round-stats.tsx`/`round-scorecard.tsx`, som hadde
  identisk latent bug (ville vist eieren som "Deg" for en medspiller
  som så på). Rediger/slett/legg-til/fjern-knappene skjules nå for en
  ikke-eier-viewer.
  **Scratch-verifisert grundig, 39/39 sjekker i to testløp:** søk-og-
  legg-til med auto-utfylt kjønn/HCP, avvist duplikat/selv-tillegg/
  ukjent bruker/ufullstendig profil, lenket medspiller kan lese runden
  + registrere score for BÅDE egen OG andres rad (whole-flight-
  regelen bekreftet), men nektes å forvalte runden (alle
  forvaltningskall 403), lenket medspiller KAN fullføre runden,
  `/rounds`-listen viser nå runden for en lenket medspiller med DERES
  EGEN fremdrift (ikke eierens), urelatert bruker fortsatt 403/ikke i
  listen, leaderboard-navn stemmer for alle tre deltakertyper.
  `test_isolation.sql` 12/12 uendret. Ekte typesjekket produksjonsbuild
  kompilerte rent.
  **Rullet ut live 2026-07-26**, bruker bekreftet eksplisitt: migrasjon
  027 kjørt mot ekte `teecup_db` (unik indeks bekreftet,
  `test_isolation.sql` fortsatt 12/12), deretter `docker compose up -d
  --build teecup_api teecup_frontend`. Begge containere boot-et rent,
  `/health`/`/dashboard`/`/my-rounds` → 200, `teeoff.no` upåvirket.

- **Sanntid for frittstående runder, BYGGET OG SCRATCH-VERIFISERT
  (2026-07-26), samme dag som medspiller-søket over:** brukeren spurte om
  spillere ser i sanntid at en annen har registrert en score — svaret var
  nei (kun engangs-henting ved lasting), og brukeren ba om at det bygges,
  gjenbruk av det etablerte "noe endret seg, hent på nytt"-WebSocket-
  mønsteret fra ADR-027 ("Følg live" for turneringer).
  `app/realtime.py` utvidet (fortsatt rutefri, se moduldoc) med en andre,
  parallell kringkastings-registry for runder (`live_sockets_for_round`/
  `broadcast_round_update`, delt `_broadcast()`-hjelpefunksjon for å unngå
  duplisert kringkastingslogikk). Nytt `@router.websocket("/ws/rounds/
  {round_id}/live")` i `rounds.py` — ALDRI anonym tilgang (ulikt
  turnering-live), krever eier ELLER lenket medspiller
  (`_get_accessible_round_or_404`, samme sjekk som resten av
  medspiller-utvidelsen). Kringkasting lagt inn i `update_hole`,
  `complete_round`, `add_participant`, `remove_guest_participant`,
  `update_round` og `delete_round` — alt som endrer noe de andre på
  skjermen bør få vite om. Ingen ny Caddy-endring nødvendig (`/ws/*` er
  allerede en wildcard-rute fra ADR-025).
  **Reelt funn under scratch-testing, ikke en bug, men verdt å dokumentere:**
  Starlette avviser en WebSocket FØR `.accept()` alltid som en bar HTTP
  403 under selve håndtrykket — de tre distinkte lukkekodene (4401/4403/
  4404) jeg satte når til `websocket.close()` server-side, men skiller seg
  IKKE fra hverandre i klientens håndtrykk-avvisning (alle tre ga HTTP 403
  i en ekte WS-klienttest, ikke bare curl). Selve sikkerheten (tilkobling
  korrekt avvist i alle tre tilfeller) er upåvirket — samme underliggende
  Starlette-oppførsel gjelder trolig også den eksisterende turnering-live-
  ruten (ADR-027), bare ikke tidligere testet med en ekte WS-klient på
  dette presisjonsnivået.
  **Frontend:** `round-detail.tsx` åpner en WebSocket ved montering,
  refetcher runden ved signal og henter aktiv spillers hull DIREKTE på
  nytt (ingen mellomsteg med tom stat som ville blinket for spilleren som
  selv nettopp registrerte et slag) — andre spilleres hull-cache droppes
  i stedet, hentes friskt ved neste fanebytte. Bruker en ref for å unngå
  at socket-en kobles til/fra ved hvert fanebytte. `round-stats.tsx`/
  `round-scorecard.tsx` (rene lesevisninger) fikk en enklere
  `refreshKey`-basert variant, samme mønster som `public-live.tsx` fra
  ADR-027.
  **Scratch-verifisert grundig, 10/10 sjekker, ekte WebSocket-klient (ikke
  bare REST):** ekte kringkasting bekreftet begge veier — eierens åpne
  socket mottok et signal da medspilleren registrerte et slag via REST,
  OG medspillerens åpne socket mottok et signal da eieren fullførte runden
  — ikke bare at REST-svarene så riktige ut. Alle tre avvisningstilfellene
  (uautentisert, urelatert fremmed, ukjent runde-id) korrekt avvist.
  `test_isolation.sql` 12/12 uendret (ingen migrasjon). Ekte typesjekket
  produksjonsbuild kompilerte rent.
  **Rullet ut live 2026-07-26**, bruker bekreftet eksplisitt: ingen
  migrasjon, `docker compose up -d --build teecup_api teecup_frontend`.
  Begge containere boot-et rent, `/health`/`/dashboard` → 200, `teeoff.no`
  upåvirket. Verifisert presist at `/ws/rounds/*`-ruten faktisk når
  FastAPI: et ekte WS-håndtrykk-forsøk mot en ukjent runde-id over
  produksjons-https ga FastAPI sin egen JSON-`{"detail":"Not Found"}`,
  ikke Next.js sin HTML-404 — samme verifiseringsmønster som ADR-027s
  tournament-live-rute.
- **HCP i medspiller-søk + rediger utslag/HCP per deltaker, BYGGET OG
  SCRATCH-VERIFISERT (2026-07-26), IKKE ENNÅ RULLET UT:** brukeren viste et
  skjermbilde av "+ Medspiller"-søket og påpekte at spillerens HCP burde
  vises der (kun navn+klubb vistes), og ba samtidig om å kunne endre
  utslagssted og HCP for medspillere -- "det er ikke sikkert de spiller fra
  samme utslagssted som meg, og det er ikke sikkert HCP er riktig", eksplisitt
  presisert som en endring KUN for denne runden/turneringen, ikke spillerens
  faktiske profil.
  **Reelt hull bekreftet ved kodegjennomgang FØR bygging:** ALLE deltakere
  på en runde har i dag brukt SAMME `round.tee_name_snapshot` -- ingen
  per-deltaker-tee har noensinne eksistert (rating-tallene har vært per
  deltaker siden migrasjon 021, men selve utslags-NAVNET var aldri
  eksplisitt per rad).
  **Bygget:** `PersonMatch` (`app/routers/friends.py`, delt av vennesøk OG
  medspiller-søk) fikk `handicap_index: float | None`. Ny migrasjon
  `028_round_participant_tee.sql` -- `round_participant.tee_name_snapshot`,
  backfylt fra rundens eksisterende tee for alle eksisterende rader. `_create_
  participant` skriver nå tee-navnet eksplisitt; `ParticipantCreate` (add_
  participant) fikk et valgfritt `tee_name` som faller tilbake til rundens
  tee hvis utelatt. Ny `GET /rounds/{id}/tee-options` (gjenbruker
  `_ResolvedCourse` sin rating-dict via en ny `tee_options()`-metode) --
  brukt av "rediger spiller"-panelet til å liste banens faktiske utslag.
  `ParticipantUpdate` skrevet om til vanlig `exclude_unset`-PATCH-semantikk
  (var tidligere kun `stat_level`, alltid påkrevd) -- nye valgfrie
  `tee_name`/`handicap_index`-felt trigger en full re-beregning av
  rating-snapshottene + `course_handicap_snapshot` for AKKURAT den
  deltakeren, uten å røre spillerens egen `app_user.handicap_index`.
  Eksplisitt `null` på `handicap_index` fjerner HCP-sporing for denne
  deltakeren i denne runden (samme mønster som profil-PATCH). **Bevisst
  avvist etter at runden er fullført** (409 `ALREADY_COMPLETED`, samme
  presedens som `RoundUpdate` sitt bane-bytte -- differensialen er da
  allerede beregnet fra det gamle grunnlaget); `stat_level` alene er
  fortsatt tillatt uansett fullført-status. `RoundUpdate` sitt eksisterende
  bane-bytte (ADR-033-oppfølging 2026-07-24) nullstiller nå eksplisitt ALLE
  deltakeres `tee_name_snapshot` til rundens nye utslag (et bane-bytte gjør
  individuelle tee-valg fra den gamle banen meningsløse).
  **Frontend (`round-detail.tsx`):** søkeresultatene i "+ Medspiller" viser
  nå HCP ved siden av hjemmeklubb. Ny "Utslag: X · HCP: Y"-rad under
  statistikknivå-velgeren for aktiv spiller, med en "Rediger for denne
  runden"-lenke (kun eier, kun før fullført) som åpner en ny
  `EditParticipantPanel` -- utslagssted som en `<select>` fylt fra det nye
  tee-options-endepunktet (filtrert på spillerens kjønn), HCP som fritekst,
  forklarende "endrer ikke profilen"-tekst. Gjelder likt for eierens egen
  rad som for medspillere (ingen spesialtilfelle).
  **Scratch-verifisert, 27/27 sjekker** (isolert `teecup_app_scratch`-
  rolle + isolert scratch-MinIO + engangs API-container): HCP i søk, legg
  til medspiller med eksplisitt AVVIKENDE utslag fra eieren, gjest uten
  eksplisitt tee faller korrekt tilbake til rundens tee, utslag uten rating
  for kjønn avvist (400) både ved tilføyelse og redigering, tee-options
  lister riktige utslag, rediger tee+HCP for medspiller lykkes og
  course_handicap regnes om, **medspillerens egen profil-HCP forblir
  UENDRET** (den kritiske sjekken -- bekrefter runde-scoping), delvis PATCH
  (kun stat_level) lar tee/HCP stå urørt, eksplisitt `null` fjerner HCP
  round-scoped, lenket medspiller (ikke eier) nektes å redigere deltakere
  (403, forvaltning fortsatt eier-only), tom PATCH avvist (400), redigering
  blokkert etter fullføring (409) mens stat_level fortsatt tillates. Full
  regresjonskjøring av forrige rundes 35-punkts medspiller-søk-testsuite
  (`test_round_coplayer.py`) mot samme friske scratch-database, alle 35
  fortsatt grønne. `test_isolation.sql` 12/12. Ekte typesjekket
  produksjonsbuild kompilerte rent.
  **Rullet ut mot ekte systemer 2026-07-26**, bruker bekreftet eksplisitt:
  migrasjon 028 kjørt mot ekte `teecup_db` (kolonne bekreftet `NOT NULL`,
  2 eksisterende rader backfylt korrekt, `test_isolation.sql` fortsatt
  12/12), deretter `docker compose up -d --build teecup_api
  teecup_frontend`. Begge containere boot-et rent (`Application startup
  complete`, Next.js `Ready`), `/health`/`/dashboard` → 200, `teeoff.no`
  upåvirket.
- **V0-prompt for rundeleaderboardet rettet (2026-07-26), FØR den ble
  kjørt i v0.app:** samme runde som over, brukeren ba eksplisitt om å få
  leaderboardet for frittstående runder på plass. Backend
  (`GET /rounds/{id}/leaderboard`) var allerede live siden tidligere samme
  dag; V0-prompten (skrevet samme dag, se FEATURE_BACKLOG.md) hadde
  derimot en utdatert antakelse -- den ba om et "Deg"-merke basert på at
  kun eieren noensinne ser sin egen runde, som ikke lenger stemmer etter
  ADR-036 fase 3 (medspillere kan nå også se runden). Rettet til to
  uavhengige merker: "Eier" (fra API-ets `is_owner`) og "Deg" (fra en
  `participant_id`-prop komponenten mottar utenfra, ikke fra selve
  leaderboard-dataen). Prompten er ikke sendt til v0.app ennå.
- **Mottatte slag i hull-headeren + gjeste-e-post/kjønn/navn redigerbart,
  BYGGET OG SCRATCH-VERIFISERT (2026-07-26), IKKE ENNÅ RULLET UT:** brukeren
  viste et skjermbilde av det nettopp rullede "Rediger for denne runden"-
  tillegget og ba om to ting: (1) hvor mange slag aktiv spiller MOTTAR på
  det aktive hullet vist i selve hull-headeren (eksempel "Hull 7 - Par 4 -
  Hcp 5 - -1"), og (2) for en midlertidig spiller (gjest) skal Navn/Kjønn/
  E-post også være redigerbart, ikke bare utslag/HCP. Ba samtidig om et
  V0-prompt for å designe om selve spillerlisten (utslag/HCP/rediger inn i
  selve spillerknappen, listet vertikalt i stedet for dagens horisontale
  scroll-rad).
  **Punkt 1 bygget direkte** (triviell, ren frontend, ingen backend-endring
  -- `strokes_received` var allerede hentet fra `GET .../holes` fra før,
  bare aldri vist FØR scoring): `round-detail.tsx` sin hull-header viser nå
  `· −N` (ekte minustegn, golfvis fortegn) når aktiv spiller mottar minst
  ett slag på hullet, ellers uendret.
  **Punkt 2 krevde ny backend:** ny migrasjon `029_round_participant_
  guest_email.sql` (`round_participant.guest_email`, nullable). `Participant
  Create` fikk et valgfritt `guest_email: EmailStr | None` (avvist sammen
  med `user_id`). `ParticipantUpdate` fikk `guest_name`/`gender`/
  `guest_email` -- KUN gyldig for en gjest (`user_id IS NULL`), avvist
  (400) på en lenket deltaker. `gender`-endring inngår nå i samme "rating_
  changed"-bunt som utslag/HCP (påvirker gyldig rating), avvist etter
  fullføring (409, samme presedens); `guest_name` alene har ingen rating-
  implikasjon og forblir redigerbar selv etter fullføring (ren metadata).
  **Frontend for punkt 2 IKKE bygget ennå** -- overlatt til V0-prompten
  (se FEATURE_BACKLOG.md), siden brukeren eksplisitt ba om det og den
  eksisterende hånd-bygde `EditParticipantPanel` uansett skal erstattes av
  den nye vertikale spillerlisten.
  **Scratch-verifisert, 22/22 nye sjekker** (gjest med e-post ved
  opprettelse, avvist sammen med user_id, navn+kjønn+e-post-redigering
  lykkes og rating regnes om for nytt kjønn, eksplisitt null fjerner
  e-post, kjønnsendring til urepresentert rating avvist med full rollback,
  alle tre gjeste-feltene avvist på en LENKET deltaker mens utslag/HCP
  fortsatt fungerer uendret der, kjønn/utslag/HCP-endring blokkert etter
  fullføring mens navneendring fortsatt tillates). Full regresjonskjøring
  av samme dags 27+35-punkts testsuiter mot samme friske scratch-database,
  alle 62 fortsatt grønne. `test_isolation.sql` 12/12. Ekte typesjekket
  produksjonsbuild kompilerte rent (inkl. punkt 1).
  **Rullet ut mot ekte systemer 2026-07-26**, bruker bekreftet eksplisitt:
  migrasjon 029 kjørt mot ekte `teecup_db` (kolonne bekreftet,
  `test_isolation.sql` fortsatt 12/12), deretter `docker compose up -d
  --build teecup_api teecup_frontend`. Begge containere boot-et rent,
  `/health`/`/dashboard` → 200, `teeoff.no` upåvirket.
- **Spillerliste-redesign HÅNDKODET (2026-07-26), IKKE ENNÅ RULLET UT:**
  brukeren gikk tom for V0-credits rett etter at prompten over ble sendt.
  Spurt eksplisitt (AskUserQuestion): bygg direkte, eller vent på fornyede
  credits — svar: bygg direkte. Bygget nøyaktig etter samme prompt/data-
  kontrakt som allerede var skrevet (se FEATURE_BACKLOG.md for full
  detalj), i samme Tailwind/shadcn-stil som resten av `round-detail.tsx`.
  Ny `PlayerList` (erstatter `PlayerTabs`) — vertikal liste av spillerkort,
  hvert kort en stor "velg som aktiv spiller"-knapp + separate Rediger-/
  fjern-knapper (unngår nestede interaktive elementer), "Deg"/"Eier" som
  `Badge`-komponenter. `EditParticipantPanel` utvidet med statistikknivå
  (den frittstående `StatLevelPicker` er nå død kode, fjernet) og — kun
  for gjester — Navn/Kjønn/E-post, med reaktivt utslagsfilter ved
  kjønnsendring. "+ Medspiller"-flyten flyttet inn i selve `PlayerList`.
  **Verifisert:** ekte typesjekket produksjonsbuild kompilerte rent, pluss
  en engangs `next dev`-container mot scratch-backend (ekte runde med en
  gjest med avvikende utslag/kjønn/e-post) — siden ga 200, ingen Next.js-
  feilside. **Ærlig begrensning:** siden er en klient-komponent (data
  hentes etter hydrering), så server-HTML-en viser kun last-skjelettet —
  INGEN ekte nettleser-interaksjonstest utført (intet nettleserverktøy
  tilgjengelig).
  **Rullet ut mot ekte systemer 2026-07-26**, bruker bekreftet eksplisitt:
  ingen ny migrasjon, `docker compose up -d --build teecup_api
  teecup_frontend`. Begge containere boot-et rent, `/health`/`/dashboard`
  → 200, `teeoff.no` upåvirket. **Bruker bør selv klikke gjennom flyten**
  (spesielt gjeste-kjønnsendringens reaktive utslagsfilter og "velg vs.
  rediger"-trykkflatene) før full tillit.
- **Tildelte slag + jevn korthøyde + rundeleaderboard, HÅNDKODET, IKKE ENNÅ
  RULLET UT (2026-07-26):** to oppfølgingspunkter samme dag, full detalj i
  FEATURE_BACKLOG.md. (1) Spillerkortet manglet "tildelte slag" (course
  handicap for runden) og hadde variabel høyde — rettet: `Player` fikk
  `courseHandicap`, kortet fikk fast `min-h-[68px]` med begge tekstlinjer
  trunkert til én linje (ikke wrap), alle kort like høye uansett innhold.
  (2) Brukeren spurte om jeg "med designerbrillene på" trodde jeg kunne få
  rundeleaderboardet til å se like profesjonelt ut som V0 — svarte ja
  (gjenbruk av etablerte mønstre, ikke fri utforskning) og bygget det: ny
  `components/round-leaderboard.tsx` + rute `/my-rounds/[id]/leaderboard`,
  gjenbruker `ScoreMark`s "form + farge"-språk fra `round-scorecard.tsx`
  (som `ToParMark`), samme WS-sanntid-mønster som `round-stats.tsx`, delt
  plassering ("T-N"), brutto/netto-veksling, mini-variant på rundens egen
  side. Rangeringslogikken VERIFISERT UAVHENGIG i et frittstående
  Node-script (19/19, inkl. tie-håndtering og uspilte spillere), pluss en
  fersk scratch-runde med ekte API-kall som bekreftet leaderboard-JSON-en
  stemte. Ekte typesjekket produksjonsbuild kompilerte rent. Samme ærlige
  begrensning som over: ingen ekte nettleser-interaksjonstest.
  **Rullet ut mot ekte systemer 2026-07-26**, bruker bekreftet eksplisitt:
  ingen migrasjon, `docker compose up -d --build teecup_api
  teecup_frontend`. Begge containere boot-et rent, `/health`/`/dashboard`
  → 200, `teeoff.no` upåvirket.
- **Hullscorer i leaderboardet + lenke fra rundelisten, BYGGET, IKKE ENNÅ
  RULLET UT (2026-07-26):** brukeren presiserte rett etter forrige rulling
  tre krav: leaderboardet skal ha en egen visning (allerede tilfellet, se
  over), med lenke fra scoreføringssiden (allerede der, `RoundLeaderboardMini`)
  OG fra rundelisten (`/my-rounds`, manglet), og skal vise hullscorer
  (manglet helt -- kun aggregerte tall fantes).
  **Backend:** `LeaderboardEntryOut` (`GET /rounds/{id}/leaderboard`) fikk
  et nytt `holes: list[LeaderboardHoleOut]`-felt (hole_number/par/
  stroke_index/played/score) -- data var ALLEREDE hentet per deltaker for
  å beregne total_score/net_score_to_par, bare aldri eksponert rått før nå.
  Ren tilføyelse, ingen migrasjon.
  **Frontend:** `round-leaderboard.tsx` sine rader er nå klikkbare
  (utvider/kollapser, default kollapset -- samme "trekkspill starter
  lukket"-konvensjon som `round-stats.tsx`) og viser en horisontal strip
  med per-hull-merker (`HoleMark`/`HoleStrip`, egen lokal variant av
  `ScoreMark`s "form + farge"-språk fra `round-scorecard.tsx`, tilpasset en
  kompakt flerspiller-liste i stedet for én tabell). `round-card.tsx`
  (brukt av BÅDE `/my-rounds`-listen og dashbordets "Kommende runder") fikk
  en ny "Se leaderboard"-lenke for runder med mer enn én deltaker --
  krevde å gjøre om kortets ytre element fra selve lenken til en `<div>`
  med lenken som ETT av to barn (unngår nestet `<a>`, samme feilklasse som
  tidligere nestet-form-/knapp-feller i prosjektet).
  **Verifisert:** backend-endringen bekreftet mot en fersk scratch-runde
  (ekte API-kall, `holes`-arrayet inneholder riktige 18 rader per deltaker
  inkl. korrekt `played`/`score` for både spilte og uspilte hull), full
  regresjon av forrige rundes 35-punkts co-player-testsuite fortsatt grønn,
  `test_isolation.sql` 12/12 (uendret, ingen migrasjon). Ekte typesjekket
  produksjonsbuild kompilerte rent (ingen nye ruter, kun endrede
  komponenter). Samme engangs `next dev`-container-sjekk som tidligere --
  `/my-rounds`, `/my-rounds/[id]` og `/my-rounds/[id]/leaderboard` ga alle
  200, ingen Next.js-feilside.
  **Samme ærlige begrensning som tidligere håndkodede runder:** ingen ekte
  nettleser-interaksjonstest (klikk for å utvide en rad, se hull-stripen,
  se "Se leaderboard"-lenken i rundelisten) er utført.
  **Rullet ut mot ekte systemer 2026-07-26**, bruker bekreftet eksplisitt:
  ingen migrasjon, `docker compose up -d --build teecup_api
  teecup_frontend`. Begge containere boot-et rent, `/health`/`/dashboard`
  → 200, `teeoff.no` upåvirket.
- **Leaderboard-oppfølging: poeng-modus + minimalistiske rader, BYGGET, IKKE
  ENNÅ RULLET UT (2026-07-26):** brukeren påpekte at brutto/netto ble
  presentert forskjellig (bryteren byttet BÅDE hvilket tall som vises OG
  hele rangeringsrekkefølgen -- forvirrende hopp), og spurte om et eget
  stableford-alternativ burde vært med. Foreslo og fikk bekreftet: gi alle
  tre modiene (nå: Brutto/Netto/**Poeng**) IDENTISK radform (rangering,
  navn, ETT tall, ferdig) i stedet for å prøve å vise flere tall samtidig.
  Samtidig ba brukeren om å fjerne alt fra den kollapsede raden utover
  navn+tall (Deg/Eier/pokal/hull-spilt-tekst) og fjerne selve
  "kort"-følelsen -- radene skal flyte sømløst sammen, kun ekspandere ved
  klikk.
  **Backend:** `LeaderboardHoleOut` fikk `strokes_received` (samme
  allerede-beregnede allokering som `net_score_to_par`, nå eksponert per
  hull også). `LeaderboardEntryOut` fikk `total_points` (stableford-total,
  samme formel/betingelse som `net_score_to_par` -- null uten HCP). Ingen
  migrasjon.
  **Frontend (`round-leaderboard.tsx`):** `Mode` utvidet til tre verdier,
  poeng rangeres SYNKENDE (motsatt av til-par). Ny `PointsMark`/`ValueMark`
  (poeng har ingen retning, kun fylt/uthevet for lederen). Listen er nå ÉN
  sammenhengende `<ul>` (`divide-y`, kun ytterkanten avrundet/rammet) i
  stedet for separate kort med mellomrom mellom hver rad -- ingen
  per-rad-bakgrunn utenom en svak tone på en UTVIDET rad. Kollapset rad:
  kun rangering+navn+tall+pil. Deg/Eier/pokal/fremdrift FLYTTET (ikke
  fjernet) inn i den utvidbare seksjonen sammen med hull-stripen.
  **Verifisert:** rangeringslogikken for poeng-modus (synkende sortering,
  delt plassering, uten-HCP sortert nederst) UAVHENGIG testet i Node
  (10/10). Selve stableford-formelen verifisert mot en fersk scratch-runde
  med HÅNDREGNET forventet resultat (course handicap 9 over 18 hull →
  slag KUN på de 9 laveste stroke-index-hullene, ikke jevnt fordelt --
  fanget en feilaktig antakelse i testens FØRSTE versjon, rettet før
  den ble rapportert som bestått) -- 11/11, inkl. kryssjekk av
  `total_points`/`net_score_to_par` mot uavhengig rekalkulering fra de
  samme rå hull-dataene API-et returnerte. Full regresjon (35-punkts
  co-player-testsuite) fortsatt grønn, `test_isolation.sql` 12/12. Ekte
  typesjekket produksjonsbuild kompilerte rent. Samme engangs `next
  dev`-container-sjekk som tidligere -- alle tre rutene ga 200.
  **Samme ærlige begrensning:** ingen ekte nettleser-interaksjonstest av
  det faktiske "sømløse rader"-uttrykket eller poeng-modusen.
  **Rullet ut mot ekte systemer 2026-07-26**, bruker bekreftet eksplisitt:
  ingen migrasjon, `docker compose up -d --build teecup_api
  teecup_frontend`. Begge containere boot-et rent, `/health`/`/dashboard`
  → 200, `teeoff.no` upåvirket.
- **Hullscorer i leaderboardet: netto/poeng under brutto, BYGGET, IKKE ENNÅ
  RULLET UT (2026-07-26):** brukeren viste to referansebilder fra en
  konkurrentapp (Golf GameBook) sin leaderboard-visning -- brutto fremhevet
  (fylt/farget merke) på én rad, netto/stableford i vanlig tekst RETT under,
  eksplisitt presisert at det skal se likt STRUKTURELT ut men IKKE være en
  kopi visuelt. Ren frontend-endring, ingen backend-endring (all data --
  `strokes_received` per hull -- var allerede lagt til forrige runde samme
  dag).
  **`HoleMark`** (`round-leaderboard.tsx`) fikk en tredje, umerket tekstlinje
  RETT under det fremhevede brutto-merket, som viser netto eller
  stableford-poeng for AKKURAT det hullet -- kun i netto-/poeng-modus (ingen
  ny linje i brutto-modus, ingenting nytt å vise der). Nye lokale
  `netForHole()`/`pointsForHole()`-hjelpefunksjoner (samme formel som
  backend sin `total_points`, men per hull -- bruker `strokes_received`
  direkte fra API-et, regner ALDRI ut egen slagfordeling). `HoleStrip` fikk
  en liten "Slag · Netto"/"Slag · Poeng"-bildetekst over stripen når en
  sekundærrad faktisk vises.
  **Bevisst IKKE en kopi:** beholder TeeCups egne farger/former (sirkel/
  firkant, grønn/oransje) fra `ScoreMark`-språket som allerede var etablert
  -- endret ikke fargevalg for å etterligne referansebildets blåtoner, kun
  gjenskapte det STRUKTURELLE prinsippet (fremhevet brutto øverst, rolig
  sekundærtall under).
  **Verifisert:** netto/poeng-per-hull-formelen testet UAVHENGIG i Node
  (9/9, inkl. et gulv-på-0-tilfelle og manglende-HCP/uspilt-hull), samme
  tall som det håndregnede scratch-scenarioet fra forrige runde samme dag
  (hull med slag: netto 3/poeng 3, hull uten slag: netto 5/poeng 1). Ekte
  typesjekket produksjonsbuild kompilerte rent. Samme engangs `next
  dev`-container-sjekk som tidligere -- leaderboard-ruten ga 200.
  **Samme ærlige begrensning som resten av de håndkodede rundene:** ingen
  ekte nettleser-interaksjonstest av selve det visuelle uttrykket.
  **Rullet ut mot ekte systemer 2026-07-26**, bruker bekreftet eksplisitt:
  ingen migrasjon, `docker compose up -d --build teecup_api
  teecup_frontend`. Begge containere boot-et rent, `/health`/`/dashboard`
  → 200, `teeoff.no` upåvirket.
- **Scoringsflyt: samlebånd-fremdrift + golf-term-taltastatur, BYGGET, IKKE
  ENNÅ RULLET UT (2026-07-26), inspirert av en konkurrentapp (Golf
  GameBook):** brukeren delte en skjermopptaksvideo av GameBooks
  score-registrering og spurte om jeg forstod HVORFOR den flyten fungerer
  bedre enn TeeCups, og om jeg kunne bygge det selv (ingen V0-credits
  igjen). Video analysert bilde for bilde (ffmpeg i en engangs Docker-
  container, samme mønster som en tidligere videoanalyse i prosjektet) --
  identifiserte presist samlebånd-mønsteret: taltastatur med kontekstuelle
  golf-termer per tall (Eagle/Birdie/Par/Bogey ut fra hullets par, ikke
  bare "par"-knappen merket), og at fullført registrering for én spiller
  automatisk åpner NESTE spillers registrering for samme hull -- uten å
  måtte navigere manuelt tilbake til en spillerliste.
  **Bevisst IKKE en full skjermovertakende steg-for-steg-modal** (GameBooks
  egen løsning) -- vurdert som unødvendig risikofylt å bygge korrekt uten
  visuell testing. I stedet: samme etablerte inline-side beholdt, men to
  konkrete forbedringer lagt til:
  1. `NumberPicker` sin Slag-instans fikk en ny `showGolfTerms`-modus --
     HVERT synlig tall viser nå Albatross/Eagle/Birdie/Par/Bogey/Dobbel
     bogey relativt til hullets par (ikke bare selve par-knappen som før).
     Ny lokal `golfTermForScore()`-hjelpefunksjon.
  2. Ny `isEntryComplete()`-sjekk (krever kun det `stat_level` faktisk gjør
     obligatorisk -- slag alene, eller slag+putter; "full"-nivåets ekstra
     detaljer forblir valgfrie og blokkerer ALDRI fremdrift) + ny
     `advanceToNextPlayerOrHole()`. Bunnknappraden "Forrige/Neste hull"
     endret til "Forrige hull" (uendret) + en kontekstsensitiv primærknapp
     som enten viser "Neste: {navn på neste spiller}" (bytter aktiv
     spiller på SAMME hull) eller "Neste hull" (er aktiv spiller den
     siste, går videre til neste hull OG starter på spiller 1 igjen) --
     disabled med forklarende hjelpetekst til de påkrevde feltene er fylt.
  **Verifisert:** golf-term-tabellen og fullført-sjekken UAVHENGIG testet
  i Node (matcher videoens egne eksempler nøyaktig, f.eks. par 4 + slag
  6 = "Dobbel bogey"), samt selve samlebånds-syklusen simulert for 3
  spillere over flere hull-grenser OG for en solo-runde (ingen spillerbytte,
  kun hull-fremgang) -- 21/21 sjekker. Full regresjon (35-punkts
  co-player-testsuite) fortsatt grønn, `test_isolation.sql` 12/12 (ingen
  backend-endring denne runden). Ekte typesjekket produksjonsbuild
  kompilerte rent, samme engangs `next dev`-container-sjekk som tidligere
  ga 200.
  **Samme ærlige begrensning som resten av de håndkodede rundene:** ingen
  ekte nettleser-interaksjonstest av selve fremdrifts-følelsen (kun logikk
  + server-render bekreftet).
  **Rullet ut mot ekte systemer 2026-07-26**, bruker bekreftet eksplisitt:
  ingen migrasjon, `docker compose up -d --build teecup_api
  teecup_frontend`. Begge containere boot-et rent, `/health`/`/dashboard`
  → 200, `teeoff.no` upåvirket.
- **Scoringsflyt v2: full skjermovertagende veiviser, BYGGET, IKKE ENNÅ
  RULLET UT (2026-07-26) -- ERSTATTER forrige rundes forsøk.** Brukeren
  testet forrige rundes "auto-fremdrift-knapp"-versjon live og var tydelig:
  "ingen forbedring i det hele tatt", "visuelt like overveldende og
  rotete" -- den inline-baserte tilnærmingen var IKKE nok, en ekte
  skjermovertagende veiviser (som opprinnelig vurdert og lagt til side pga.
  risiko uten visuell testing) var det som faktisk kreves. Bygget nå for
  ekte, pluss et eksplisitt nytt krav: akkumulert score-så-langt for RUNDEN
  synlig for HVER spiller samtidig (ikke bare aktiv), matchende
  konkurrentappens vedvarende "E"/"+1"-visning ved siden av hvert navn.
  **Datalasting endret** (nødvendig for punktet over): laster nå hull for
  ALLE deltakere med det samme rundén lastes (ikke lenger lat lasting kun
  for aktiv spiller), og sanntid-signalet (WS) henter nå alles hull på
  nytt, ikke bare énes.
  **Ny `ScoringWizard`-komponent** (fullskjerm, `fixed inset-0 z-50`, egen
  stack utenfor `<main>`): tre steg maks, drevet av `stat_level` --
  "strokes_only" (kun Slag), "strokes_and_putts" (+ Putter/avstand første
  putt), "full" (+ ett samlet detalj-steg: kølle/utslag/innspill/chip/
  bunker/straffeslag/anywayslag). Bevisst FÆRRE, grovere steg enn
  konkurrentens egne 5-6 skjermer (risikoreduksjon uten visuell testing,
  og TeeCups stat_level-modell gjør en så fin oppdeling mindre naturlig).
  Alle spillerne vises som en fast, ikke-trykkbar kontekst-rad øverst i
  veiviseren (aktiv fremhevet) -- speiler konkurrentappens "mist aldri
  oversikten"-prinsipp. "Forrige"/"Neste" beveger seg gjennom stegene;
  siste steg for siste spiller blir "Ferdig" (lukker + går til neste hull,
  starter på spiller 1 igjen), ellers "Neste: {navn}" (bytter spiller i
  SAMME veiviser, nullstiller til steg 1).
  **Hovedsiden forenklet radikalt:** den gamle Slag/Putter/"flere
  detaljer"-inline-blokken er FJERNET -- erstattet med én kompakt liste,
  ett kort per spiller: navn, "HCP X · {til-par så langt} ({N} hull)", og
  en stor rund knapp som viser gjeldende hulls slagtall (eller "–") og
  åpner veiviseren ved trykk. `NumberPicker`s `showGolfTerms`-funksjon fra
  forrige runde gjenbrukes uendret inni veiviserens Slag-steg (det arbeidet
  var ikke bortkastet).
  **Verifisert:** stegmaskinen (steg-antall per stat_level, fremover/
  bakover-navigasjon, disabled-gating per steg, "avbryt på steg 1 lukker",
  "siste steg for siste spiller fullfører") og akkumulert-score-
  beregningen UAVHENGIG simulert i Node (16/16). Et ekte API-rundtur-
  script som sender NØYAKTIG samme felt-kombinasjon som veiviseren ville
  sendt (fullt detalj-steg for en "full"-spiller, kun slag for en
  "strokes_only"-gjest) bekreftet begge lagres korrekt. Full regresjon
  (35-punkts co-player-testsuite) fortsatt grønn, `test_isolation.sql`
  12/12 (ingen migrasjon). Ekte typesjekket produksjonsbuild kompilerte
  rent, samme engangs `next dev`-container-sjekk ga 200.
  **Samme ærlige begrensning som alle håndkodede runder denne uken:** ingen
  ekte nettleser-interaksjonstest -- gitt at FORRIGE runde ble avvist
  nettopp fordi den så gal ut i praksis til tross for at logikken var
  korrekt, er dette IKKE en ubetydelig forbehold denne gangen. Bruker bør
  teste grundig før tillit.
  **Rullet ut mot ekte systemer 2026-07-26**, bruker bekreftet eksplisitt:
  ingen migrasjon, `docker compose up -d --build teecup_api
  teecup_frontend`. Begge containere boot-et rent, `/health`/`/dashboard`
  → 200, `teeoff.no` upåvirket.
- **Scoringsflyt v3: administrasjon og scoring adskilt i to faner, BYGGET,
  IKKE ENNÅ RULLET UT (2026-07-26) -- direkte svar på at bruker fortsatt
  fant siden "bråkete og lite intuitiv" etter v2.** Brukeren viste et NYTT
  sidestilt skjermbilde-par (samme mønster som første gang) og påpekte at
  TeeCup fortsatt hadde mye synlig FØR selve scoringslisten (leaderboard-
  forhåndsvisning, Rediger/Fullfør/Slett, hele spillerlisten med Rediger-
  ikoner, "+Medspiller") -- nøyaktig det jeg selv identifiserte som GameBooks
  kjerneprinsipp i den aller første analysen ("administrasjon og scoring er
  ADSKILTE tabs"), men aldri fullt ut gjennomførte i v2 (kun `ScoreSoFar`
  ble flyttet forrige runde, resten av det administrative innholdet ble
  stående igjen øverst).
  **Fikset denne gangen for ekte:** ny `pageTab`-state (`"score" | "manage"`,
  default `"score"`), en enkel fanevelger rett under feilmeldingen. "Score"
  (default) inneholder nå KUN: fullført-banner (hvis relevant), hull-
  navigasjon, og selve hull-panelet (header + scoringslisten fra v2 +
  Forrige/Neste hull) -- ingenting annet. "Spillere og runde" samler
  leaderboard-forhåndsvisning, Rediger/Fullfør/Slett, hele spillerlisten
  (`PlayerList`), OG `ScoreSoFar` (flyttet HIT fra forrige rundes
  "under scoringslisten"-plassering, siden den er detaljert stats-innsyn,
  ikke selve registreringsoppgaven).
  **Verifisert:** ekte typesjekket produksjonsbuild kompilerte rent, samme
  engangs `next dev`-container-sjekk ga 200, full regresjon (35-punkts
  co-player-testsuite) fortsatt grønn, `test_isolation.sql` 12/12 (ren
  frontend-omrokkering, ingen migrasjon).
  **Samme ærlige begrensning som v1/v2:** ingen ekte nettleser-
  interaksjonstest av selve fane-følelsen.
  **Rullet ut mot ekte systemer 2026-07-26**, bruker bekreftet eksplisitt:
  ingen migrasjon, `docker compose up -d --build teecup_frontend`
  (gjenskapte også `teecup_api` som vanlig bivirkning). Begge containere
  boot-et rent, `/health`/`/dashboard` → 200, `teeoff.no` upåvirket.
- **`DESIGN_SYSTEM.md` opprettet (2026-07-27):** brukeren ba om en ny fil
  som viser designsystemet arbeidet tar utgangspunkt i. Skrevet fra bunnen,
  DESKRIPTIVT (hva som ER i koden, ikke et mål) — grunnet direkte i
  `globals.css`/`components/ui/*.tsx` og etablerte tvers-fil-mønstre:
  fargetoken (inkl. OKLCH-opprinnelsen til `primary`/`brand-orange` fra
  ADR-009/016), typografi, avstand/hjørner/lag (inkl. "én sammenhengende
  liste med `divide-y`, ikke separate kort"-regelen fra 2026-07-26s
  leaderboard-fiks), lokale komponentmønstre (NumberPicker/Stepper/
  ChoiceRow/DirectionCross — bevisst per-fil, ikke delte importer),
  golfscore-språket (`ScoreMark`/`ToParMark`/`PointsMark`/`HoleMark`),
  ikonografi, tilbakemelding/tilstander, og navneformat (pekt til CLAUDE.md).
- **`teecup-scorekort-og-entry-spec.md` lest og evaluert, delvis BYGGET SOM
  COMPLIANCE-PASS SAMME DAG (2026-07-27):** brukeren lastet opp et
  PRESKRIPTIVT motstykke til DESIGN_SYSTEM.md (5-app-sammenligning: Golf
  GameBook/Golf Pad/Golfshot/Hole 19/18Birdies) og spurte om det ga mening
  og kunne forbedre TeeCup. Vurdert som reelt verdifullt — sylskarpeste nye
  innsikt: "grønt-på-grønt"-diagnosen (§0.2) forklarer noe av "fortsatt
  rotete"-følelsen fra v1-v3-rundene bedre enn tetthet alene: `primary`
  (grønn) var brukt om hverandre for BÅDE "aktiv tilstand" og "generisk
  fylt/positiv", uten at begge betydde det samme sted. Foreslo (og
  brukeren bekreftet) å fikse spec-dokumentets §3 "Compliance-pass" FØR den
  større strukturelle §1-omleggingen (scorekort som grid) vurderes som egen,
  senere runde.
  **To av sjekklistens fem punkter var KONKRETE, VERIFISERBARE bugs, bekreftet
  direkte i koden (ikke antatt fra spec-teksten alene) FØR de ble fikset:**
  1. **"Deg Deg"-duplikat:** `playerLabel()` (`round-detail.tsx`) erstattet
     tidligere selve navnet med "Deg" for viewer-relativ egen rad, OG en
     separat `<Badge>Deg</Badge>` sto ved siden av samme sted (spillerkort,
     scoringslisten) — bekreftet duplikat, matchet et tidligere skjermbilde
     brukeren delte. **Fikset:** `playerLabel()` returnerer nå alltid det
     faktiske `display_name` (aldri "Deg") — Badge-en er nå ENESTE
     selv-indikator. Dette retter samtidig et videre, ikke tidligere flagget
     avvik: spec-dokumentet krever eksplisitt "roster-kontekst → fullt navn"
     for BÅDE scorekort-gridet og score-entry-headeren — veiviserens header/
     kontekst-rad/"Neste: {navn}"/fullført-banneret viste tidligere "Deg" i
     stedet for et fullt navn der også, uten noen badge til å disambiguere
     (reelt forvirrende på en delt telefon som sendes rundt en flight).
     Det nå overflødige `rawName`-feltet (var identisk med `name` etter
     fiksen) fjernet, tre kallsteder oppdatert.
  2. **Score-knappen fulgte ikke `§Golfscore-språket`:** den store runde
     knappen i den kompakte scoringslisten (`round-detail.tsx`, bygget i
     v2-runden) var `rounded-full`+grønn UANSETT om resultatet var under,
     over eller på par — bogey og eagle så identiske ut. **Fikset:** ny
     `scoreMarkClasses(diff)`-hjelpefunksjon som gjenbruker EKSAKT samme
     `primary`/`brand-orange`-fargespråk og fylt-vs-border+10%-tint-omfangs-
     regel som `ScoreMark` i `round-scorecard.tsx` (bekreftet ved å lese
     `ScoreMark` sin kildekode direkte, ikke gjettet) — sirkel under par,
     nøytral sirkel på par, `rounded-2xl` (bevisst mildere enn scorekortets
     `rounded-[4px]`, for å matche denne skjermens øvrige 56px-trykkflate-
     avrunding) over par, fylt ved 2+ slag fra par.
  **Resten av sjekklisten (44px-trykkgulv, `tabular-nums`) auditert
  systematisk mot AKKURAT denne filen** (samme fil brukerens skjermbilder
  viste) — 2 manglende `tabular-nums` (HCP/tildelte slag i spillerkortet)
  og 11 knapper/lenker under 44px (fane-bryteren `min-h-10`→`min-h-11`,
  `EditRoundPanel`s lukk-ikon `size-8`→`size-11`, feilside-tilbakelenken,
  og åtte knapper i bane-bytte-/legg-til-medspiller-skjemaene) rettet.
  **Bevisst UTENFOR omfang denne runden:** spec-dokumentets §1 (scorekort
  som fullt grid, celle åpner veiviseren) — en STØRRE strukturell endring
  som fortjener et eget, bevisst ja fra brukeren, ikke bygget stille inn i
  en "fiks kjente bugs"-runde.
  **Verifisert:** ekte typesjekket produksjonsbuild (samme `Dockerfile` som
  deployes) kompilerte rent, alle 24 ruter listet. **Samme ærlige
  begrensning som ALLE håndkodede runder denne uken:** ingen ekte
  nettleser-interaksjonstest av det faktiske visuelle resultatet (kun kode-
  lesing + build-verifisering + bevisst gjenbruk av en allerede lest,
  eksisterende komponents fargespråk for å holde risikoen lav).
  **Rullet ut live 2026-07-27**, bruker bekreftet eksplisitt: ingen
  migrasjon, `docker compose up -d --build teecup_frontend` (gjenskapte
  også `teecup_api` som vanlig bivirkning, ingen backend-kode rørt). Begge
  containere boot-et rent, `/health`/`/dashboard` → 200, `teeoff.no`
  upåvirket.
- **Spec-dokumentets §1 (scorekort som fullt grid) BYGGET OG LIVE
  (2026-07-27), samme dag rett etter compliance-passet:** brukeren
  bekreftet eksplisitt "JA" på at grid-redesignet er en egen, bevisst
  runde, egen informasjonsarkitektur enn ett-hull-om-gangen-listen
  bygget dagen før. `round-detail.tsx` sin "Score"-fane fikk hull-strip
  + ett-hull-panel ERSTATTET av en ny `ScorecardGrid`: spillere som rader
  (sticky venstre navnekolonne, navn+HCP, samme tap-target åpner
  veiviseren for gjeldende hull), hull som horisontalt scrollbare
  kolonner, `Hcp`/`Par`-referanserader over spillerradene (samme
  konvensjon som den allerede shippede `round-scorecard.tsx`), sticky
  `Ut`/`Inn`/`Sum` til høyre (Ut/Inn gruppert på FYSISK hullnummer 1-9/
  10-18, uavhengig av øktens starthull — riktig konvensjon uansett
  spillerekkefølge; kun vist for 18-hulls runder, 9-hulls runder får
  én samlet Sum). Ny `ScorecardCell` gjenbruker EKSAKT samme klassifisering
  og Tailwind-klasser som `ScoreMark`/`classify` i `round-scorecard.tsx`
  (lest direkte, ikke gjettet) — ulikt compliance-passets softere
  `rounded-2xl`-knapp-variant (fortsatt riktig der, egen visuell kontekst),
  siden dette er en LITEN tabellcelle som spec eksplisitt ber om å følge
  språket "UBRYTELIG".
  **Interaksjon:** tapp en score-celle ELLER spillerens navnecelle ELLER
  en hull-kolonneoverskrift åpner `ScoringWizard` (uendret komponent fra
  v2-runden) for akkurat den (spiller, hull)-kombinasjonen — kolonne-
  overskrift alene (uten å tappe en celle) setter kun "gjeldende hull"
  uten å åpne veiviseren, samme jobb som den fjernede `HoleNav` gjorde.
  Beholdt en kompakt "Forrige/Neste hull"-knapperad under gridet for
  rask sekvensiell registrering uten bred scrolling.
  **Dødt kode fjernet i samme runde:** `HoleNav`, `holeIsPlayed`,
  GIR-merket/`showGir` (ga ikke lenger mening i en multi-hull-visning),
  og OGSÅ compliance-passets `scoreMarkClasses`-hjelpefunksjon (var kun
  brukt av den nå fjernede ett-hull-listens store runde knapp).
  **Verifisert:** ekte typesjekket produksjonsbuild (samme `Dockerfile`
  som deployes) kompilerte rent, alle 24 ruter listet. I TILLEGG en
  engangs full runner-image bygget og kjørt i en isolert container (ikke
  bare `--target builder`) — `/my-rounds/[id]` for en ukjent runde-id
  ga 200, ingen React-feilgrense/krasj-markup i responsen. **Samme
  ærlige begrensning som ALT håndkodet arbeid denne uken, men STØRRE
  konsekvens denne gangen siden dette er en vesentlig strukturell endring
  (ny informasjonsarkitektur), ikke en liten fiks:** ingen ekte
  nettleser-interaksjonstest (scrolling, tapping av celler/hull-
  overskrifter/navnerad, faktisk visuelt resultat av sticky-kolonnene)
  er utført — flagget eksplisitt til bruker FØR utrulling, bruker bør
  selv klikke seg grundig gjennom før full tillit.
  **Rullet ut live 2026-07-27**, bruker bekreftet eksplisitt: ingen
  migrasjon, `docker compose up -d --build teecup_frontend` (gjenskapte
  også `teecup_api` som vanlig bivirkning, ingen backend-kode rørt). Begge
  containere boot-et rent, `/health`/`/dashboard`/`/my-rounds` → 200,
  `teeoff.no` upåvirket.
- **Reell produksjonsbug funnet OG fikset SAMME DAG via ekte nettleser-
  testing (2026-07-27) — FØRSTE gang denne økten en Chrome DevTools MCP
  har vært tilgjengelig.** Brukeren ba meg selv åpne gridet
  (`localhost:3000/my-rounds/{id}`), logget meg inn (passord feilet først
  — kontoen mangler passord/miljøet pekte annerledes; løst med en ekte
  magic-link brukeren limte inn), og jeg tok et ekte skjermbilde av det
  nettopp bygde scorekort-gridet på en mobil viewport (390×844) mot ekte
  produksjonsdata (runden `c5db2e31-...`, 2 spillere, 4/18 hull spilt).
  **Fant umiddelbart en alvorlig, reell rendering-bug** som ALDRI ble
  fanget av typesjekking/container-boot-verifisering: `position: sticky`
  på `<td>`/`<th>` inni en `<table>` med `border-collapse` rendret
  fullstendig ødelagt i Chrome — de sticky `Ut`/`Inn`/`Sum`-kolonnene
  overlappet/utvisket hull-kolonnene bak seg (synlige sammenblandede
  siffer, f.eks. "436"/"472" der Par-radens tall lå oppå hverandre).
  Nøyaktig den typen feil den gjentatte "ingen ekte nettleser-test
  utført"-forbeholdet advarte mot hele uken.
  **Første fiks-forsøk (kun `border-collapse` → `border-separate
  border-spacing-0`) løste IKKE problemet** — re-skjermbilde etter
  redeploy viste samme overlapp. **Rot-årsaken var strukturell, ikke
  syntaktisk:** å kombinere en sticky VENSTRE-kolonne MED sticky HØYRE-
  kolonner i en tabell som er mye bredere enn viewporten er i seg selv
  et ustabilt mønster — ved scroll-posisjon 0 blir de sticky høyre-
  kolonnene umiddelbart trukket til synlig høyre kant, og alt som
  "egentlig" befinner seg der i normal dokument-flyt (hull 3+) blir
  liggende RETT BAK dem, delvis synlig gjennom `bg-muted/60`s
  delvise gjennomsiktighet. **Fikset ved å fjerne sticky-posisjonering
  fra `Ut`/`Inn`/`Sum`-kolonnene helt** (de scroller nå med resten av
  hullene i normal flyt, samme velprøvde, veletablerte mønster som den
  gjenværende sticky VENSTRE navnekolonnen, som fungerte korrekt hele
  tiden) — droppet også `/60`-gjennomsiktigheten til fordel for en helt
  opak `bg-muted`.
  **Verifisert presist, ekte, etter fiksen** (ikke bare "ser bedre ut"):
  nytt skjermbilde ved scroll-posisjon 0 viste alle tall rene og lesbare
  (Hcp/Par-radene, begge spilleres scoringsceller, korrekt sirkel/firkant-
  form for bogey/dobbel bogey/par), OG et script som scrollet gridet helt
  til høyre (`scrollLeft = scrollWidth`) bekreftet `Ut`/`Inn`/`Sum` også
  rene der (`Ut 36/Inn 36/Sum 72` på Par-raden — stemmer eksakt med en
  18-hulls par-72-bane), med navnekolonnen fortsatt korrekt pinnet til
  venstre gjennom hele scrollingen. Tilgjengelighetstreet (`take_snapshot`)
  bekreftet også at aria-labels med golftermer ("Bogey", "Dobbel bogey",
  "Par") faktisk leses ut korrekt — `§Golfscore-språket`s "aldri farge
  alene"-regel holder i praksis, ikke bare i teorien.
  **Rullet ut live 2026-07-27**, samme dag: `docker compose up -d --build
  teecup_frontend` kjørt to ganger (én for det mislykkede første forsøket,
  én for den faktiske fiksen), `/health` 200 begge ganger, `teeoff.no`
  upåvirket.
  **Lærdom:** Chrome DevTools MCP-tilgangen endrer risikobildet for alt
  fremtidig håndkodet frontend-arbeid denne økten — bruk den til å
  FAKTISK se resultatet før noe rapporteres som ferdig, i stedet for kun
  typesjekk+container-boot+`curl`-baserte proxyer for "det virker".
- **Full nettleser-gjennomgang av ALLE 22 skjermer, 2026-07-27 —
  systematisk browsersjekk av alt som IKKE var reelt nettleser-testet
  tidligere.** Brukeren spurte først hvilke visninger som faktisk finnes
  (svart med en gruppert oversikt over `frontend/app/`s 22 `page.tsx`-
  ruter), deretter ba om at ALLE de ikke-browsersjekkede skjermene faktisk
  ble sjekket. Logget inn som `hei@erol.no` (spiller-konto, egne runder)
  og — etter en egen runde med å spore opp riktig konto (magic-link fra
  brukeren landet først på feil konto to ganger: `erol.haagenrud@gmail.com`
  og kontoen manglet 2FA — satt opp TOTP for ekte ved å hente ut den rå
  base32-secreten fra oppsett-skjermen og regne ut en gyldig 6-sifret kode
  selv med et frittstående RFC 6238-script, ingen autentisator-app
  involvert) — som `erol.haagenrud@envide.no` (org-eier for «Tjøme
  Gents») for de org-/turnering-scopede skjermene. Gikk gjennom alle 22
  ruter med ekte skjermbilder + konsoll-feil-sjekk (`list_console_
  messages`) på hver.
  **To reelle funn:**
  1. Scorekort-gridet (§1, bygget dagen før) hadde EN NY sticky-kolonne-
     overlapp-bug som IKKE fantes i utgangspunktet -- se eget punkt over,
     fikset samme økt.
  2. **Ny, ekte bug funnet i `round-scorecard.tsx`** (post-runde-
     scorekortet, bygget i en tidligere økt) -- "til par" i BÅDE
     header-hero-tallet og bunn-"TIL PAR"-brikken regnet
     `totalGross - totalPar` der `totalPar` var summen av ALLE 18 hulls
     par, ikke bare de faktisk spilte -- ga en absurd "−53 til par" for
     en runde med 19 slag på kun 4 hull (skulle vært "+2"). Bekreftet
     ved at `/my-rounds/[id]/stats` (en ANNEN komponent) viste riktig
     "+2,00 til par" for SAMME runde, som isolerte feilen presist til
     `round-scorecard.tsx`. Fikset med en ny `playedPar`-variabel
     (paret for KUN spilte hull) brukt i de to til-par-utregningene --
     "Par"-brikken nederst beholdt bevisst `totalPar` (hele rundens
     par, riktig som statisk referanse). Bunn-"Par"/øvre "Hcp"/"Par"-
     referanseradene i `ScoreBlock` ble sjekket og bekreftet IKKE
     rammet (brukes kun til den statiske referansen, aldri til en
     til-par-utregning).
  **For å nå de org-/turnering-scopede skjermene: satt org «Tjøme
  Gents» sin `public_profile`/`slug` MIDLERTIDIG (bekreftet med bruker
  FØR endring) for å teste `/clubs/[slug]`, deretter revertert
  eksplisitt til nøyaktig opprinnelig tilstand (`slug=null`,
  `public_profile=false`) — bekreftet med en direkte databasespørring
  etterpå at reverten var eksakt.
  **Alle 22 skjermer bekreftet uten krasj/konsoll-feil** (utenom
  forventede 401/403 på steder som SKAL avvise — feil passord-forsøk,
  privat lagchat, ugyldig verify-token). Full liste med status i
  chat-loggen denne runden.
  **Rullet ut live 2026-07-27**, ingen migrasjon for til-par-fiksen,
  `docker compose up -d --build teecup_frontend`, verifisert direkte i
  nettleseren mot den samme runden som viste bugen (nå "+2 til par",
  korrekt).
- **Dashboard-runde: bane-navn-fiks, to nye designfarger, bane-detaljvisning
  og aggregert statistikk — BYGGET, SCRATCH-/BROWSERVERIFISERT OG LIVE
  (2026-07-28):** fem punkter reist av brukeren i samme runde, alle
  bekreftet eksplisitt før bygging (AskUserQuestion) unntatt fargevalget,
  der brukeren ba om at jeg selv "tok på designerbrillene" og foreslo.
  1. **"Kommende runder" → "Runder"** på dashbordet (`dashboard.tsx`,
     `UpcomingRounds`) — ren tekstendring, ingen annen forekomst i kodebasen.
  2. **Tjøme-bane-duplikatet rettet i ekte `teecup_db`:** presist
     diagnostisert FØR noe ble kjørt — alle tre av `hei@erol.no` sine
     runder pekte til nøyaktig samme `teeoff_facility_slug`/
     `teeoff_course_id` (`tjome-golfklubb`/140), kun `round.
     course_name_snapshot`-TEKSTEN differerte (én runde fra FØR
     enkeltbane-navnefiksen 25.07 hadde "Tjøme Golfklubb – Hovedbanen").
     Ingen delt banetabell å slå sammen — frittstående runder har (bevisst,
     ADR-033 Beslutning C) ingen egen `course`-rad, kun et navn-snapshot per
     runde. Fiksen var én presist scopet `UPDATE round SET
     course_name_snapshot = 'Tjøme Golfklubb' WHERE id = 'fa6e528f-...'`
     (1 rad), kjørt etter eksplisitt bekreftelse, verifisert med en
     read-only spørring rett etterpå.
  3. **To nye kjernefarger** — brukeren ba eksplisitt om minst én, "kanskje
     to", etter først å ha fått presentert (og avvist "kun én") en
     tidligere anbefaling fra 25.07 om å løfte den allerede eksisterende
     `--chart-3`-blåtonen. Løftet BEGGE allerede validerte statistikk-
     fargene i stedet for å finne opp nye OKLCH-verdier: `--info`
     (fra `--chart-3`, blå) og `--gold` (fra `--chart-4`, gul/gull) —
     nye tokens i `globals.css` (`:root`/`.dark`/media-dark-blokken, alle
     tre synkronisert som vanlig). Konkret, begrunnet førstebruk for
     begge, ikke bare dekorativt: `--info` på et nytt "Hcp spilt til
     X"-merke (før: ren grå tekst) på rundekort (`round-card.tsx`),
     `--gold` på et nytt "Personlig rekord"-merke (`Medal`-ikon) som vises
     når en fullført runde er brukerens laveste til-par blant MINST to
     fullførte runder (unngår at den eneste fullførte runden feilaktig
     kalles en "rekord"). Beregnet i `dashboard.tsx`/`own-rounds.tsx`/
     `course-rounds.tsx` sine respektive `findPersonalBestRoundId()`.
  4. **Bane-detaljvisning:** "Spilte baner" på dashbordet er nå klikkbar
     (`PlayedCourses`, `dashboard.tsx`) — ny rute
     `/my-rounds/course/[name]` (`components/course-rounds.tsx`), gjenbruker
     eksisterende `GET /rounds` (ingen nytt backend-endepunkt), filtrerer
     client-side på nøyaktig samme `course_name_snapshot`-nøkkel dashbordets
     egen gruppering allerede bruker. "Personlig rekord" regnes likevel over
     HELE rundelisten, ikke bare denne banens, for at merket skal bety det
     samme uansett hvor et rundekort vises.
     **Reell bug funnet OG fikset UNDER browserverifisering, ikke antatt
     riktig fra kildekoden alene:** første versjon leste `params.name` rått
     uten `decodeURIComponent` (matchet et eksisterende mønster i
     `/clubs/[slug]/page.tsx` som aldri hadde blitt testet med et navn som
     inneholder mellomrom/æøå) — et ekte skjermbilde viste tittelen som
     `Tj%C3%B8me%20G...` og "0 runder funnet", siden matchen skjedde mot den
     RÅ URL-kodede strengen. Rettet med et eksplisitt `decodeURIComponent`,
     bekreftet med et nytt skjermbilde: riktig tittel og alle tre Tjøme-
     rundene listet, inkl. både `--info`- og `--gold`-merkene rendret
     korrekt.
  5. **Aggregert statistikk, klikkbar fra dashbordet:** ny
     `GET /rounds/stats/summary` (`app/routers/rounds.py`), ny side
     `/my-rounds/stats` (`components/rounds-stats-summary.tsx`), lenket
     fra dashbordets "Statistikk"-seksjon ("Se full statistikk"). Bruker
     valgte det BREDESTE av tre foreslåtte omfang (utover kun runder/snitt-
     til-par/putt: fairwaytreff, GIR, én-putt, scrambling, sand save,
     snitt chip/bunker/straffeslag/anywayslag per runde) — portert fra de
     allerede R&A/manuelt verifiserte formlene i `round-stats.tsx` sin
     `computeStats()` for ÉN runde, generalisert til å pole alle kvalifiserte
     hull på tvers av ALLE fullførte runder (ikke gjennomsnitt av per-runde-
     prosenter, som ville vektet små utvalg feil).
     **Putt/18-hull-regelen** (brukerens eksplisitte instruks, presist
     bekreftet tolkning FØR bygging via AskUserQuestion): `round_hole` har
     alltid nøyaktig 18 rader per deltaker uansett `holes_planned` (9 eller
     18) — verifisert i `_create_participant`. For hver fullført runde der
     puttsporing faktisk var på (`stat_level != 'strokes_only'`) telles
     derfor alle 18 lagrede rader, et hull uten registrert putt-verdi
     (uspilt, eller utenfor et 9-hulls spilleomfang) telles som 2 putter —
     runder UTEN puttsporing holdes helt utenfor tallet (ellers ville alle
     18 hull feilaktig blitt padded). Kun putt-tallet padder — alle andre
     andelstall bruker KUN faktisk registrerte hull, som instruert.
     **Verifisert i to lag:** (a) en frittstående Python-simulering av
     nøyaktig samme aggregeringslogikk mot et hånd-konstruert 3-runde-
     datasett (én `strokes_only`-runde padding-ekskludert, én
     `strokes_and_putts`-runde med 9 av 18 hull padded) — alle hånd-regnede
     forventninger stemte eksakt, inkl. det kritiske tilfellet (padded runde
     ga nøyaktig 36 putt/18, strokes_only-runden talte 0 mot totalen); (b)
     ekte typesjekket produksjonsbuild + import-sjekk av hele FastAPI-appen
     i det faktiske prod-imaget (ikke bare syntaks) + et ekte browserbesøk
     som viste reelle, korrekt utregnede tall for `hei@erol.no` sine 2
     fullførte runder.
  **Rullet ut live 2026-07-28**, bruker bekreftet eksplisitt for
  databaseskrivingen (punkt 2) og fargevalget (punkt 3, "to farger i stedet"
  for anbefalt én); resten bygget direkte på brukerens egen presise
  instruks. Ingen migrasjon. `docker compose up -d --build teecup_api
  teecup_frontend` (kjørt to ganger — én gang for hovedleveransen, én gang
  for `decodeURIComponent`-fiksen over). `/health`/`/dashboard`/
  `/my-rounds/stats`/`/my-rounds/course/...` alle bekreftet 200 og
  konsoll-feilfrie i en ekte innlogget nettleser-sesjon, `teeoff.no`
  upåvirket.
- **Statistikk-siden utvidet: miss-retning, tidsvindu + forrige-periode-
  sammenligning — BYGGET, TESTET OG LIVE (2026-07-28), samme dag, rett
  etter forrige punkt:** brukeren reiste tre ting samtidig — ønsket
  miss-RETNING (ikke bare treff%), trender, og et presist spørsmål om
  hvorvidt GIR-fra-score-og-putt-inferens faktisk var forstått/utnyttet.
  **Siste punkt avklart, ikke en bug:** bekreftet at `isGir = score - putts
  <= par - 2` (allerede i `round-stats.tsx`, portert uendret til det nye
  aggregerte endepunktet dagen før) ER akkurat denne generelle inferensen —
  fungerer for ALLE score/putt/par-kombinasjoner, ikke bare brukerens
  eksempel. Eneste reelle begrensning (forklart, ikke fikset): krever
  putt-tall, så `strokes_only`-runder får aldri en GIR-verdi — score alene
  er nesten aldri nok til å BEVISE GIR (en scrambling-birdie fra utenfor
  green gir identisk score som en ekte GIR+1-putt).
  **Miss-retning bygget:** `_summarize_rounds` i `app/routers/rounds.py`
  utvidet med `fairway_left_pct`/`fairway_right_pct` (samme
  `fairway_tracked`-pool som treff%) og `green_miss_long/short/left/
  right_pct` (egen pool — hull der `approach_result` er registrert og ≠
  "hit", UAVHENGIG av om putt er kjent, samme adskilte spor som
  `round-stats.tsx` sin `missedGreen`/`missDir`). Ny `MissBar`-komponent i
  `rounds-stats-summary.tsx` (fordelingsbar, samme visuelle idé som
  `SegmentedBar`/`DistributionBar` andre steder i appen).
  **Tidsvindu + forrige-periode bygget:** ny `StatsWindow`-type (`Literal`)
  og `_resolve_stats_window()` — brukeren ba eksplisitt om BÅDE en full
  velger (Siste runde/5/10/Denne måneden/I år/Siste år/Alltid) OG
  sammenligningspiler mot forrige periode (utover det opprinnelig
  anbefalte "kun siste 5 vs. alltid, ingen piler"). Én ENSARTET regel for
  "forrige periode" på tvers av alle vindutyper — samme LENGDE (antall
  runder for rullerende antall-vinduer, antall DAGER for dato-vinduer)
  rett før gjeldende vindus start — i stedet for å måtte spesialdefinere
  "forrige måned"/"forrige år" ulikt for hver kalenderbasert type.
  `GET /rounds/stats/summary?window=...` returnerer nå `{window, current,
  previous}` (`RoundStatsWindowSummary`) — samme `_summarize_rounds()`-
  funksjon kalt to ganger på to ulike round_id-mengder, ingen duplisert
  aggregeringslogikk. Frontend fikk en ny `Delta`-komponent (pil + farge,
  farget etter en eksplisitt `goodDirection`-per-tall — lavere er bedre
  for til-par/putt/chip/bunker/straffeslag/anywayslag, høyere er bedre for
  treff-/rednings-prosentene, INGEN farge på de rene miss-retnings-tallene
  siden venstre/høyre ikke er "bedre/verre").
  **Verifisert i to lag:** (a) en frittstående Python-simulering av
  `_resolve_stats_window()` mot syntetiske datasett — rullerende antalls-
  vindu (riktig current/previous-splitt, riktig tomt `previous` når for få
  runder finnes), dato-vindu (kalender-til-dato + rullerende forrige
  periode), og en isolert miss-retning-poolingstest (`None`-verdier
  korrekt ekskludert fra nevneren); (b) ekte typesjekket produksjonsbuild
  (måtte rette en TypeScript-nullbarhets-feil underveis — `current`/
  `previous` pakket ut via en IIFE inni JSX for at TS skulle smalne begge
  riktig), full import-sjekk av hele FastAPI-appen i prod-imaget, OG et
  ekte browserbesøk som viste reelle tall (fairway-miss 36/43/21,
  green-miss-retning 0/75/13/13) + bekreftet vindu-velgeren fungerer
  (klikket "Siste 10", pillen ble grønn, tallene oppdaterte seg) + et
  direkte `fetch()`-kall fra siden selv som bekreftet `{window, current,
  previous}`-formen (2 runder i `current`, korrekt tomt `previous` siden
  brukeren kun har 2 fullførte runder totalt).
  **Rullet ut live 2026-07-28**, ingen migrasjon, `docker compose up -d
  --build teecup_api teecup_frontend`. Begge containere boot-et rent,
  `/health` → 200, anonymt `GET /rounds/stats/summary?window=last_5` → 401
  (bekrefter query-parameteren ruter riktig gjennom Caddy/rewrites),
  `teeoff.no` upåvirket.
- **Statistikk-siden: visuell v2 (kompass-diagram + donuter), HÅNDKODET og
  BROWSERVERIFISERT MED EKTE ITERASJON, LIVE (2026-07-28), samme dag:**
  brukeren delte et referansebilde av en konkurrent-app sin statistikk-
  skjerm (donuter med sentertall, kompass for miss-retning) og ba om noe
  tilsvarende. Skrev først et fullt V0-prompt (data-kontrakt, komponent-
  for-komponent) — brukeren var tom for V0-credits og spurte eksplisitt om
  jeg kunne "gi promptet til meg selv" og bygge det direkte, siden Chrome
  DevTools MCP nå gjør det mulig å faktisk SE resultatet underveis (ulikt
  tidligere håndkodede runder denne uken som kun var typesjekket).
  **Backend:** tre nye felt i `RoundStatsSummary`/`_summarize_rounds`
  (`app/routers/rounds.py`) — `putt_dist_one_pct`/`two_pct`/
  `three_plus_pct`, EGNE eksakte bøtter (`putts==1`/`==2`/`>=3`, samme som
  `round-stats.tsx` sin `puttCategories`), bevisst forskjellig fra det
  allerede eksisterende `one_putt_pct` (som bruker `<=1` — en annen,
  allerede etablert rate, ikke en distribusjon).
  **Frontend, `rounds-stats-summary.tsx` skrevet om betydelig:** ny
  `GirCompass` — greentreff-prosenten i midten (grønn fremheving), fire
  retningsceller rundt (Langt=topp, Kort=bunn, Venstre=venstre,
  Høyre=høyre), samme visuelle språk som den allerede etablerte
  `DirectionCross`/`DirButton` fra `round-detail.tsx` (plusstegn-rutenett,
  `min-h-16 rounded-2xl border`-celler) — bevisst IKKE fargekodet
  grønn/oransje på retningscellene (retning er beskrivende, ikke god/
  dårlig), kun sentercellen. Ny gjenbrukbar `Donut`-komponent
  (conic-gradient, sentertall + valgfri forklaringsliste via
  `showLegend`) brukt til BÅDE puttfordelingen (3 segmenter: 1-putt/
  2-putt/3-putt+) og to enkle rednings-gauger (scrambling/sand save, ett
  segment). Bevisst IKKE et flyt-/beslutningstre-diagram for scrambling/
  sand save (som referansebildet hadde) — det er to uavhengige prosenter i
  datamodellen, ikke en forgrening, et flytdiagram ville antydet en
  struktur som ikke finnes. Bevisst INGEN trendlinje (referansebildets
  fjerde element) — for lite rundehistorikk til å vise noe meningsfullt
  ennå, samme vurdering som tidligere samme dag.
  **Reelt funn UNDER selve visuell iterasjon, ikke bare kodegjennomgang:**
  første versjon av "Redning"-kortet viste samme tall TO GANGER per gauge
  (`Donut` sin egen auto-genererte forklaringsliste "● Scrambling 9 %" RETT
  OVER en egen, manuelt lagt til "Scrambling"-bildetekst) — sett direkte i
  et ekte skjermbilde, ikke antatt. Fikset ved å legge til en
  `showLegend`-prop på `Donut` og slå den av for de to gaugene, beholdt kun
  min egen kompakte bildetekst+delta under ringen.
  **Verifisert:** ekte typesjekket produksjonsbuild (to runder — én for
  hovedversjonen, én for legend-fiksen), full backend-import-sjekk i
  prod-imaget, OG ekte skjermbilder tatt FØR og ETTER legend-fiksen i en
  innlogget nettleser-sesjon (samme mønster som sticky-kolonne-bug-fiksen
  tidligere denne uken) — kompasset viser reelle tall (39 % greentreff,
  75 % kort, 13/13 % venstre/høyre, 0 % langt for `hei@erol.no` sine 2
  runder), puttfordelings-donuten viser korrekt fargede segmenter (17/61/
  22 %), vindu-velgeren fungerer fortsatt uendret (klikket "Siste 5" etter
  redesignet, ingen konsoll-feil). Ingen migrasjon.
  **Rullet ut live 2026-07-28**, `docker compose up -d --build teecup_api
  teecup_frontend` (kjørt to ganger). `/health` → 200 begge ganger,
  `teeoff.no` upåvirket.
  **Oppfølging, samme dag:** brukeren ba om at fairway-baren sin venstre/
  høyre-bom bruker SAMME farge (i stedet for to ulike chart-farger) --
  begge er tross alt bare "bom", ingen grunn til å skille dem visuelt.
  Byttet begge til `--brand-orange` (appens etablerte "bom/over par"-farge),
  beholdt grønn kun for selve fairwaytreffet. Verifisert med et nytt
  skjermbilde. Rullet ut, ingen migrasjon.
- **"Til par: med vs. uten"-splitt, BYGGET, TESTET OG LIVE (2026-07-28),
  samme dag:** brukeren ba eksplisitt om snitt-til-par splittet på om en
  hull-hendelse inntraff eller ikke -- greentreff, fairwaytreff, bunker,
  OG anywayslag (eksplisitt fremhevet). Fire nye par felt i
  `RoundStatsSummary`/`_summarize_rounds` (`app/routers/rounds.py`):
  `avg_to_par_with/without_gir`, `_fairway_hit/miss`, `_with/without_bunker`,
  `_with/without_anyway` -- pooler ENKELTHULL på tvers av alle runder i
  perioden (ikke per-runde-snitt, siden dette er hull-nivå-betingelser),
  samme `diff()`-formel som `round-stats.tsx` sin `avgToParWithGir`/
  `avgToParFairwayHit`/`avgToParWithBunker` bruker for én runde (portert
  uendret) -- anywayslag-splitten er en ny, konsekvent utvidelse av
  akkurat samme mønster (fantes ikke fra før for enkeltrunder heller).
  Ny `CompareToPar`-komponent i `rounds-stats-summary.tsx`: to bokser side
  om side, den med FAKTISK lavest til-par denne perioden fremheves grønn
  -- ingen hardkodet antakelse om hvilken side som "skal" vinne (bekreftet
  reelt i data: "Med anywayslag" var faktisk verre enn "Uten anywayslag"
  som forventet, men "I bunker" var marginalt BEDRE enn "Ikke i bunker"
  for denne brukerens 2 runder -- fremhevingen fulgte automatisk det
  virkelige tallet, ikke en antakelse).
  **Verifisert:** en frittstående Python-simulering av alle fire splittene
  mot et hånd-konstruert 5-hulls datasett (eksakte forventede gjennomsnitt
  regnet ut for hånd og sammenlignet), full backend-import-sjekk i
  prod-imaget, ekte typesjekket build, OG et ekte skjermbilde i innlogget
  nettleser som viste reelle, korrekt utregnede og korrekt fargede tall
  for alle fire kategoriene. Ingen migrasjon.
  **Rullet ut live 2026-07-28**, `docker compose up -d --build teecup_api
  teecup_frontend`, `/health` → 200, `teeoff.no` upåvirket.

- **Gjennomgang av frittstående runder (ADR-033) + det viktigste hullet
  lukket: faktisk (beregnet) HCP, BYGGET, SCRATCH-/BROWSERVERIFISERT OG
  LIVE (2026-07-28, ADR-038):** brukeren ba om en vurdering av om alt var
  tenkt gjennom for single-runder. Fant ved grep at hele WHS-indeksmotoren
  (`handicap_index_from_differentials`/`low_handicap_index`/
  `apply_index_caps` i `handicap_engine.py`, 41/41 testet siden ADR-033)
  ALDRI ble kalt fra noe API-endepunkt — `round_participant.
  score_differential` ble regnet og lagret per runde, men `app_user.
  handicap_index` endret seg kun manuelt. Bekreftet eksplisitt i
  `rounds.py` sin egen moduldoc ("skjer IKKE automatisk her -- eksplisitt
  uavklart punkt i ADR-033"). Sekundære, mindre hull notert samtidig
  (offline-kø kun for turnering-scorekortet, ikke frittstående runder;
  ingen Stableford; ingen rundedeling/visibility) — brukeren valgte å ta
  tak i HCP-hullet.
  **To load-bærende design-avklaringer** (AskUserQuestion, se ADR-038):
  (1) hver INNLOGGET deltaker (ikke bare eieren) styrer sin egen
  eksklusjon fra faktisk HCP; (2) faktisk HCP designes NÅ for å kunne
  inkludere begge kilder (frittstående runder OG en fremtidig turnering-
  kilde), men v1 bygger kun runder-delen — løst med ett bevisst tynt,
  navngitt skjøtepunkt (`_gather_qualifying_differentials`), IKKE en ny
  generell "scoring record"-tabell (for tidlig abstraksjon).
  **Ny migrasjon `030_actual_handicap_index.sql`:** `app_user.
  computed_handicap_index`/`computed_handicap_index_updated_at` (den
  faktiske, beregnede WHS-indeksen — ALDRI direkte redigerbar, kun
  avledet), `round_participant.exclude_from_handicap` (manuell opt-out,
  uavhengig av den automatiske `counts_for_handicap`-kvalifiseringen),
  `round.play_format` (`stroke`/`match`, selvdeklarert — ingen egen
  match-motor for frittstående runder), `handicap_history.source`
  (`manual`/`computed` — gjenbruker EKSISTERENDE tabell fra ADR-031-
  oppfølgingen i stedet for en parallell historikk-tabell, siden Low
  Handicap Index/cap (Rule 5.7/5.8) trenger nøyaktig samme
  dato+indeks-form som allerede fantes der).
  **WHS-kilde lest og lagt til grunn** (`WHS_Rules_of_Handicapping_2024.
  pdf`, Rule 3.3): matchspill-scorer ER teknisk et gyldig HCP-grunnlag
  under WHS, MEN et konsedert/ikke-utspilt hull krever en subjektiv "most
  likely score" TeeCups rene slagregistrering ikke har noen vei til å
  representere presist — begrunner "spør (med anbefalt eksklusjon), ikke
  tving"-designet i stedet for et hardkodet forbud mot matchspill i
  HCP-grunnlaget.
  **Backend (`app/routers/rounds.py`):** ny `_recompute_computed_
  handicap_index(conn, user_id)` — henter de ≤20 nyeste kvalifiserende
  differensialene, kaller den allerede-testede motoren, henter tidligere
  `computed`-historikk for Low HI-cap (hopper bevisst over capping ved
  FØRSTE beregning noensinne — Low HI er udefinert før en indeks er
  etablert). Kalt fra `complete_round` (alle deltakere med `user_id`),
  `update_participant` (eksklusjon endret på en ALLEREDE fullført runde),
  `remove_guest_participant` (dekker faktisk enhver ikke-eier-fjerning,
  til tross for navnet) og `delete_round` (fanger berørte brukere FØR
  kaskade-slettingen fjerner radene). `update_participant` sin
  autorisasjon utvidet presist: en ikke-eier kan KUN sende
  `exclude_from_handicap`, KUN på sin egen rad (`_OWNER_ONLY_
  PARTICIPANT_FIELDS`-sjekk + eksplisitt eier-eller-selv-gate) — alle
  andre felt forblir strengt eier-only, uendret.
  **Backend (`app/routers/auth.py`):** `Me` fikk `computed_handicap_
  index`/`computed_handicap_index_updated_at`. Ny `POST /auth/profile/
  handicap/apply-computed` — kopierer gjeldende beregnet verdi inn i det
  manuelt satte HCP-et (samme skrivevei/historikk-logging som en vanlig
  manuell PATCH, kun `source='manual'`). `GET /auth/profile/handicap-
  history` eksponerer nå `source` også.
  **Frontend:** `/my-rounds/new` fikk en "Spilleform"-bryter
  (Slagspill/Matchspill) — velges Matchspill, forhåndsutfylles (ikke
  tvinges) en eksklusjons-avkrysning med forklarende tekst.
  `round-detail.tsx` fikk en "Matchspill"-badge i headeren, en
  spilleform-bryter i `EditRoundPanel` (ren metadata, redigerbar uansett
  fullført-status), og `EditParticipantPanel` fikk en ny `restricted`-
  modus: en ikke-eier som redigerer SIN EGEN rad, ELLER EIEREN etter at
  runden er fullført, ser KUN eksklusjons-toggelen (ikke tee/HCP/navn/
  statistikk) — `PlayerList` sin "Rediger"-knapp vises nå også for en
  ikke-eiers egen rad, ikke bare for eieren. `/account` fikk et nytt
  "Faktisk HCP (beregnet)"-kort (verdi + sist-beregnet-dato +
  "Bruk som mitt HCP →"-knapp), og HCP-historikk-listen viser nå
  "beregnet"/"manuelt" per rad.
  **Scratch-verifisert grundig, 111/111 sjekker** (isolert
  `teecup_app_scratch`-rolle + isolert scratch-MinIO + engangs API-
  container via ekte HTTP, samme mønster som hele prosjektet):
  hånd-utregnet WHS-matte bekreftet PRESIST (tre runder med kjente
  differensialer [10.0, 12.0, 14.0] ga nøyaktig 8.0 — beste-1-av-3 med
  -2.0-justering fra Rule 5.2a-tabellen), <3 tellende runder gir fortsatt
  `null` (ikke en feil), sletting av en tellende runde regner faktisk HCP
  på nytt (tilbake til `null` under 3), matchspill-runde eksplisitt
  ekskludert ved opprettelse telles korrekt IKKE med, "Bruk som mitt
  HCP"-overføring bekreftet (+ `handicap_history` bærer nå begge kilder),
  og hele autorisasjonsmatrisen for eksklusjons-feltet (medspiller nektes
  andre felt og eierens rad, men kan endre EGEN eksklusjon; eieren kan
  fortsatt overstyre medspillerens). `test_isolation.sql` 12/12 uendret.
  **Reelt funn UNDER selve scratch-oppsettet, ikke i produksjon:** første
  forsøk på en engangs API-container monterte kildekoden til feil sti
  (`/app/app` i stedet for `/srv/app`, som er `Dockerfile` sin faktiske
  `WORKDIR`) — containeren boot-et rent, men kjørte stille det GAMLE,
  innbakte imagekoden uendret. Fanget FØR noe ble stolt på, ved at
  `/auth/me` manglet det nye feltet helt i et faktisk API-svar — rettet
  ved å montere til riktig `/srv`-sti, deretter bekreftet på nytt.
  **Ekte nettleser-verifisert** (Chrome DevTools MCP, engangs `next dev`-
  container mot scratch-backend — samme "sett resultatet, ikke bare
  typesjekk det"-arbeidsmåte som resten av uken): logget inn via ekte
  magic-link, opprettet en matchspill-runde → bekreftet
  forhåndsutfylt-men-overstyrbar eksklusjonsavkrysning i skjemaet,
  "Matchspill"-badge i rundens header, fullførte runden → bekreftet
  `EditParticipantPanel` automatisk bytter til restriktert modus (kun
  eksklusjons-toggel, ingen av de andre feltene), lagret en endring →
  bekreftet ekte `PATCH .../participants/{id}` 200 i nettverksfanen.
  Ekte typesjekket produksjonsbuild (alle 24 ruter) kjørt og bekreftet.
  **Rullet ut live 2026-07-28**, bruker bekreftet eksplisitt: migrasjon
  030 kjørt mot ekte `teecup_db` (alle fire nye kolonnesettene bekreftet,
  `test_isolation.sql` fortsatt 12/12 mot ekte database), deretter
  `docker compose up -d --build teecup_api teecup_frontend`. Begge
  containere boot-et rent, `/health`/`/dashboard` → 200, `teeoff.no`
  upåvirket. Verifisert presist at den nye ruten faktisk når FastAPI:
  anonymt `POST /auth/profile/handicap/apply-computed` over ekte https ga
  korrekt `401 NOT_AUTHENTICATED`, ikke en rå 404.
  **Bevisst utenfor omfang, notert i ADR-038:** turnering-/organisasjons-
  scoring teller fortsatt ikke mot faktisk HCP (venter på videre
  ADR-037-arbeid), ingen egen "aging"-bakgrunnsjobb utover at spørringen
  alltid henter kun de 20 nyeste differensialene.

- **Ekte spillformer for frittstående runder (match/skins/fourball/
  foursome/greensome/scramble), BACKEND BYGGET OG SCRATCH-VERIFISERT,
  IKKE ENNÅ RULLET UT MOT EKTE SYSTEMER (2026-07-28, ADR-039):** reist av
  brukeren rett etter ADR-038: "Er dette en slagspillsrunde, en match
  mellom to spillere, skins, eller en par- eller lag-konkurranse.
  Avhengig av svaret så må hcp beregnes forskjellig, og også scorekortet
  vil se annerledes ut." Fire load-bærende avklaringer (AskUserQuestion,
  to runder) FØR bygging — bruker valgte det bredeste omfanget i alle
  runder: to sider (Beslutning A), ALLE fire par-/lag-underformater fra
  start inkl. de to delt-ball-krevende (Beslutning B), skins med BEGGE
  akser konfigurerbare av oppsetteren (netto/brutto OG rullerer/deles,
  Beslutning D), og gå rett til migrasjon+motor samme økt (ikke bare
  dokumentere).
  **Kjerneinnsikt som gjorde dette trygt å bygge fort:** hele match-play-
  motoren (`handicap_engine.py` sin `Format`/`AllowanceStrategy`-familie/
  `match_play_strokes`/`compute_match_state`) og hele "delt-ball vs.
  individuell"-mønsteret (`hole_score.match_participant_id` NULLABLE,
  delt-ball-rader identifisert av `team_side` alene) fantes ALLEREDE,
  bygget og produksjonskjørt for org-scopede turnering-matcher. Denne
  runden PORTERER dette mønsteret til frittstående runder (nye
  `round_side`/`round_participant.round_side_id`/`round_participant.
  playing_handicap`/`round_hole.round_side_id`) i stedet for å finne opp
  noe nytt — kun skins (ingen turnering-motstykke) fikk EKTE ny
  motorkode (`compute_skins`, 7 nye tester, 50/50 i `test_handicap_
  engine.py`). `app/handicap.py` sin `_SIDE_IS_UNIT` omdøpt til
  `SIDE_IS_UNIT` (gjort delt for gjenbruk, samme "fjern understrek når
  et andre bruksted dukker opp"-mønster som tidligere runder).
  **Skjema, migrasjon `031_round_play_formats.sql`:** `round.play_format`
  utvidet til 8 verdier, nye `round.skins_scoring`/`skins_tie_handling`,
  ny `round_side`-tabell (nøyaktig to per runde, håndhevet i app-laget
  som ADR-011s to-lags-grense), `round_participant.round_side_id`/
  `playing_handicap` (sistnevnte ALDRI det samme som det eksisterende
  `course_handicap_snapshot` — den absolutte WHS-verdien rørt av INGEN
  av denne rundens kode), `round_hole.round_participant_id` gjort
  NULLABLE + ny `round_hole.round_side_id` + XOR-CHECK + to partielle
  unike indekser (samme mønster som org-scopet `hole_score`, migrasjon
  001).
  **Reelt, bekreftet funn UNDER selve designet (ikke antatt), avklart
  eksplisitt med bruker FØR bygging:** foursome/greensome/scramble har
  ÉN kombinert score per SIDE per hull -- INGEN individuell score
  finnes i det hele tatt å bygge en Score Differential fra. Løst
  (Beslutning E, bekreftet av bruker): disse deltakerne får
  `counts_for_handicap` ALDRI sann for disse rundene -- og viste seg,
  presist verifisert i scratch, å følge HELT AUTOMATISK av den
  eksisterende `complete_round`-logikken uten noen kodeendring i det
  hele tatt (en delt-ball-deltaker har null individuelle `round_hole`-
  rader, så `played_count` blir alltid 0, som `round_counts_for_
  handicap` allerede tolker som "teller ikke" for både 9- og
  18-hulls-intensjon).
  **API (`app/routers/rounds.py`):** `POST/DELETE .../sides` (eier-only,
  maks to, avvist for slagspill/skins), `ParticipantCreate`/
  `ParticipantUpdate` fikk `round_side_id` (eier-only reassignment,
  validerer siden hører til samme runde), `_recompute_side_handicaps`
  (porterer `compute_and_store_side_handicaps` — venter på at siden når
  forventet spillerantall FØR den skriver noe, samme
  "ikke komplett ennå = ikke skriv"-filosofi som originalen),
  `_relative_strokes_for_round` (porterer `relative_strokes_for_match`),
  nye `GET/PATCH .../sides/{id}/holes/{n}` (delt-ball-scoring, kun
  slagtall — ingen av de andre detalj-feltene gir mening for en delt
  ball), og et nytt lese-endepunkt `GET .../format-result` som regner
  løpende matchstatus (gjenbruker `compute_match_state`/`HoleResult`
  uendret) for de to-sidede formatene, eller en skins-tavle
  (`compute_skins`) for skins — aldri lagret, alltid avledet ved lesing.
  **To reelle bugs funnet OG fikset UNDER scratch-testing, ingen nådde
  produksjon:** (1) side-tildelings-recompute kjørte FØR responsen ble
  hentet i stedet for ETTER — testen fanget dette presist (forventet
  `playing_handicap` i responsen, fikk `null` fra FØR omregningen); (2)
  individuell-ball-gren i format-result-spørringen nøkkel-forvekslet
  "enhet" (satte `round_side_id` som nøkkel i stedet for
  `round_participant_id`, mens `side_net()`-oppslaget forventet
  deltaker-id) — ga et tomt `hole_results` til tross for gyldige
  registrerte scorer, fanget da `match_holes_played` kom ut som 0 i
  stedet for det forventede 3.
  **Scratch-verifisert grundig, 96/96 sjekker** (isolert
  `teecup_app_scratch`-rolle + isolert scratch-MinIO + engangs API-
  container via ekte HTTP, samme mønster som hele prosjektet): en
  hånd-utregnet 3-hulls singles-match (hcp 5 vs. 10, riktig slagmottak
  på de fem vanskeligste hullene) ga eksakt `lead=0`/"AS"/riktig
  hole-for-hole-mønster; fourball bekreftet INDIVIDUELL (ikke kombinert)
  90 %-beregning per spiller, korrekt "ikke komplett ennå" før andre
  spiller på siden var tildelt; foursome bekreftet 18 round_hole-rader
  opprettet på SIDEN ved side-opprettelse (før noen deltaker lagt til),
  korrekt kombinert 50 %-Playing-Handicap først når begge var tildelt,
  ekte delt-ball-scoring via det nye sub-endepunktet, OG at
  `counts_for_handicap` ble `False` for begge etter fullføring; skins
  (netto+carry) ga eksakt `{sk3: 2.0}` for et 2-hulls scenario med et
  bevisst konstruert uavgjort-så-carry-så-outright-vinn-mønster, OG
  bekreftet skins teller NORMALT mot faktisk HCP etter full fullføring
  (ulikt match). `test_isolation.sql` 12/12 uendret (additiv migrasjon).
  Alle 50 handicap_engine-tester (43 eksisterende + 7 nye skins) grønne.
  **IKKE bygget i denne runden, bevisst utsatt (Beslutning F):**
  frontend — ingen skjerm for å opprette sider, tildele deltakere,
  konfigurere skins, eller vise løpende matchstatus/skins-tavle. Backend
  er fullt funksjonelt og testet, men ubrukelig fra selve appen inntil
  frontend bygges i en egen, senere runde (samme lagdelings-mønster som
  ADR-038: motor/skjema/API FØR frontend).
  **Rullet ut mot ekte systemer 2026-07-28**, bruker bekreftet
  eksplisitt: migrasjon 031 kjørt mot ekte `teecup_db` (nye kolonner/
  `round_side`-tabell bekreftet, `test_isolation.sql` fortsatt 12/12),
  deretter `docker compose up -d --build teecup_api`. Ren boot,
  `/health`/`/dashboard` → 200, ny rute bekreftet nåbar (anonymt
  `POST .../sides` → 401, ikke en rå 404), `teeoff.no` upåvirket.

- **Oppfølging samme dag: manglende minimums-spiller-håndhevelse fanget
  og fikset, BYGGET OG SCRATCH-VERIFISERT, RULLET UT LIVE (2026-07-28):**
  brukeren påpekte presist et hull ADR-039 selv ikke fanget opp: "Er det
  match-spill, skins eller lagspill så MÅ det jo være flere spillere.
  Dette fanges ikke opp." Riktig — ingenting hindret å fullføre en
  "match" med kun eieren, eller la flere spillere enn formatet tillater
  havne på samme side. Bekreftet med bruker (AskUserQuestion): skins
  krever minst 3 spillere (2 gjør skins i praksis identisk med en vanlig
  match — 3+ er der en oppsamlet, uavgjort pott faktisk gir mening).
  **Bygget, ren Python-logikk, INGEN migrasjon:** ny
  `_format_setup_status()` — slagspill alltid klar; skins krever minst
  3 deltakere; to-sidede formater (match/fourball/foursome/greensome/
  scramble) krever NØYAKTIG to sider, INGEN uassignerte deltakere, og
  hver side nøyaktig riktig spillerantall for formatet
  (`_SIDE_PLAYER_COUNT`, allerede definert). Ny `setup_complete`/
  `setup_message` på `RoundOut` (alltid synlig, uansett format/status).
  `complete_round` avviser nå (409 `SETUP_INCOMPLETE`) hvis oppsettet
  ikke er komplett — FØR noe regnes ut. Ny `_check_side_capacity()`
  avviser (409 `SIDE_FULL`) proaktivt ved SELVE tildelingen (både
  `POST .../participants` med `round_side_id` og `PATCH .../
  participants/{id}`), i stedet for å først oppdage overtallet ved
  fullføring — med eksplisitt unntak for en no-op-reassignment til
  samme side (en deltaker teller ikke seg selv ut av plassen sin egen
  side har).
  **Scratch-verifisert grundig, 122/122 sjekker** (samme isolerte
  scratch-oppsett som resten av runden — full regresjon av alle
  tidligere 96 sjekker PLUSS 26 nye): 3. spiller avvist på en full
  match-/foursome-side (409 SIDE_FULL), `setup_complete` korrekt False
  ved kun 1 av 2 sider / uassignerte deltakere / for få skins-spillere,
  fullføring korrekt avvist (409 SETUP_INCOMPLETE) i alle disse
  tilstandene, og korrekt True (+ vellykket fullføring) først når
  oppsettet faktisk er komplett for formatet. `test_isolation.sql`
  uendret (ingen skjemaendring).
  **Rullet ut live 2026-07-28**, ingen migrasjon, kun
  `docker compose up -d --build teecup_api`. Ren boot, `/health`/
  `/dashboard` → 200, `teeoff.no` upåvirket.
- **Frontend for ADR-039 (sider/skins/delt-ball-scoring) BYGGET, BROWSER-
  VERIFISERT OG LIVE (2026-07-28), samme dag:** ingen backend-endring i
  denne runden (alt allerede live) — ren frontend-jobb, testet reelt i
  nettleser mot en isolert scratch-backend (Chrome DevTools), ikke bare
  typesjekk.
  **`new-round.tsx`:** spilleform-velgeren utvidet fra to (Slagspill/
  Match) til alle åtte format (Skins/Fourball/Foursome/Greensome/
  Scramble 2/4 lagt til), med en ny skins-konfigurasjonsseksjon (netto/
  brutto, rullerer/deles) som kun vises for `play_format="skins"` og et
  forklarende "du setter opp sidene inni runden etterpå"-notat for de
  to-sidede formatene (ADR-039 Beslutning A -- sider kan ikke opprettes
  før deltakerne finnes).
  **`round-detail.tsx` (hoveddelen):** ny `SidesPanel` (manage-fanen) --
  opprett/slett de to sidene, tildel/fjern deltakere (kompakte
  "→ Side"-hurtigknapper, deaktivert når siden er full), viser
  `playing_handicap` per side. Ny `FormatResultPanel` -- henter
  `GET .../format-result`, viser løpende matchstatus (oversetter
  motorens bokstavelige "(A)"/"(B)" til faktiske side-navn via
  `round.sides[0]/[1]`, samme sorteringsrekkefølge som backend) eller en
  skins-tavle (sortert synkende). `setup_complete`/`setup_message`
  gater nå "Fullfør runde"-knappen klientside også (server er fortsatt
  autoritativ). For delt-ball-formatene (foursome/greensome/scramble):
  ny `SideScorecardGrid` (rader = sider, ikke spillere) + ny, forenklet
  `SideScoreWizard` (kun slagtall, ingen putt/detalj-steg) mot de
  eksisterende `GET/PATCH .../sides/{id}/holes/{n}`-endepunktene.
  **To reelle stale-state-bugs funnet UNDER selve browserverifiseringen
  (ikke i kodegjennomgang), begge fikset før utrulling:**
  1. `SidesPanel` sin `assign()` oppdaterte kun deltaker-listen lokalt
     (via `onPatchParticipant`) -- `setup_complete`/`setup_message`
     (server-beregnet) ble stående utdatert etter en vellykket
     side-tildeling ("ikke tildelt en side" fortsatte å vises til tross
     for at begge var tildelt). Fikset: `assign()` kaller nå
     `onSidesChanged()` (full runde-refetch) etter en vellykket PATCH.
  2. `FormatResultPanel` sin refetch var kun koblet til hull-registrering
     og WebSocket-signaler, ikke til side-/deltaker-tildeling --
     matchstatus ble stående på "venter..." selv etter at oppsettet var
     komplett og "Fullfør runde" allerede var aktivert. Fikset ved å
     bumpe `formatResultRefreshTick` ved HVER vellykket `loadRound()`
     (enklere og mer robust enn å spore hvert enkelt kallsted som kan
     påvirke handicap-beregningen).
  **Verifisert grundig i en isolert scratch-nettleserøkt** (fersk
  `teecup_scratch`-database, isolert scratch-MinIO, engangs API-
  container, ekte `next dev` mot scratch-backend, Chrome DevTools MCP --
  ekte innlogging via magic-link, ekte profil-fullføring): tre komplette
  runder bygget og spilt gjennom UI-et alene, ende-til-ende:
  - **Match:** opprettet med eksklusjons-avkrysning forhåndshuket,
    opprettet to sider, tildelte eier+gjest, bekreftet `playing_handicap`
    (60/20) vist riktig, scoret hull 1 (4 mot 6) via `ScoringWizard`
    (ubrørt komponent), bekreftet `FormatResultPanel` viste "1 UP
    (Erol)" + riktig fargede hull-merker -- kryssjekket med
    `aria-label`-attributtet direkte via `evaluate_script` for å bekrefte
    semantisk korrekt side-navn bak den rå A/B-bokstaven.
  - **Skins:** konfigurasjons-UI-et (netto/brutto, rullerer/deles) bekreftet
    visuelt, opprettet med kun 1 spiller (satte-message "krever minst 3"),
    la til to gjester til (meldingen forsvant idet den tredje ble lagt til,
    "Fullfør runde" aktivert), scoret hull 1 for alle tre (via direkte
    API-kall for hastighet, samme kontrakt som UI-et bruker), bekreftet
    skins-tavlen -- **hånd-regnet og kryssjekket eksakt**: netto 1/4/3 for
    de tre spillerne (course handicap 60/12/6, alle mottar 1 slag på
    hull 1 unntatt eieren som mottar 4) ga korrekt "1 skin" til laveste
    netto.
  - **Foursome:** bekreftet "Opprett begge sidene..."-meldingen i Score-
    fanen FØR sidene fantes (ingen krasj), opprettet to sider, la til tre
    gjester, scoret hull 1 via `SideScorecardGrid`/`SideScoreWizard`
    (5 mot 5 -- observerte LIVE at gridet oppdaterte seg bak selve
    veiviseren), fant OG fikset de to stale-state-bugene over midt i
    denne runden (glemte først å tildele spillerne til sider -- avdekket
    nettopp fordi UI-et da IKKE viste feil tilstand, men en ekte utdatert
    en), bekreftet til slutt `playing_handicap` kombinert riktig per side
    (38/38 og 17/17) og at `FormatResultPanel` viste "1 UP (Rødt lag)"
    -- kryssjekket for hånd at Rødt lag (høyere kombinert CH) mottar
    slag på det vanskeligste hullet og derfor vinner nettoduellen 5 mot 5.
  Ekte typesjekket + full produksjonsbuild kjørt på nytt ETTER
  bug-fiksene (ikke bare før), alle 24 ruter listet.
  **Rullet ut live 2026-07-28**, bruker bekreftet eksplisitt: ingen
  migrasjon (ren frontend), `docker compose up -d --build
  teecup_frontend` (gjenskapte også `teecup_api` som vanlig bivirkning,
  ingen backend-kode rørt). Begge containere boot-et rent, `/health`/
  `/dashboard` → 200, `teeoff.no` upåvirket. **ADR-039 er dermed
  fullstendig ferdig, backend og frontend, live.**

Neste steg:
0a. **Spillerliste-redesign — nå FAKTISK nettleser-bekreftet
   (2026-07-27, full 22-skjerms gjennomgang):** rendrer korrekt, ingen
   konsoll-feil. Ikke hvert enkelt interaksjonsdetalj (f.eks. gjeste-
   kjønnsendringens reaktive utslagsfilter) klikket gjennom stykke for
   stykke, men grunnleggende rendring/lasting er bevist, ikke lenger
   bare typesjekket.
0b. **Rundeleaderboard — nå FAKTISK nettleser-bekreftet (2026-07-27):**
   brutto/netto/poeng-veksling testet direkte i nettleseren, viste
   korrekte tall og riktig form/farge-språk.
1. **Ferdig, kun for historikk:** dashbord-redesign (ADR-035) og
   venner/kategorisert deling fase 1 (ADR-036) — begge designet
   2026-07-25 og siden BYGGET, SCRATCH-VERIFISERT OG RULLET UT LIVE
   samme dag (se status over). Venner fase 2 (rundevisibilitet) og
   fase 3 (ekte medspillere) er fortsatt ikke bygget.
3. **Frittstående rundeføring + detaljert statistikk — ADR-033 skrevet
   2026-07-22, IKKE bygget.** Brukeren avklarte 2026-07-22 at dette skal
   bli appens HOVEDFOKUS (turneringsoppsett skal bli ekstremt enkelt
   ETTER dette er på plass) — den største enkeltbeslutningen i prosjektet
   siden ADR-001. Fire load-bærende delbeslutninger avklart eksplisitt
   (AskUserQuestion): nytt parallelt eierskapsmønster keyet på `user_id`
   (gjenbruker det allerede beviste `plain_connection()`-mønsteret fra
   personlig profil/HCP-historikk/sekundær e-post — IKKE en skjult
   personlig organisasjon), fast sett navngitte statistikk-felt per hull
   (ikke fri slag-for-slag-logg), full WHS HCP-indeksberegning bygges NÅ
   (ikke utsatt), shotgun-start blir egen separat ADR-034. De tre
   HCP-PDF-ene lest i sin helhet — Score Differential/Course
   Handicap/Net Double Bogey-formlene er hentet derfra (kilde, ikke
   hukommelse).
   **Oppdatert samme dag:** brukeren bekreftet banedata-spørsmålet (LIVE
   oppslag mot teeoff, ikke import — Beslutning C) og lastet opp en
   FJERDE PDF, den offisielle "WHS Rules of Handicapping 2024"
   (USGA/R&A) — lest i sin helhet, løste presist det som manglet: 9-
   hulls-minimumsregelen (Rule 2.2, IKKE bare "minst 9 hull" — en
   9-hulls-runde krever ALLE 9 av et faktisk ratet sett, en 18-hulls-
   runde krever minst 10 av 18), full HCP-indeks-pipeline (Score
   Differential, Net Double Bogey, expected-score for uspilte hull, beste
   8-av-20, Low Handicap Index, soft/hard cap), OG en ny, presis
   9-hulls-Course-Handicap-formel som HALVERER indeksen først (Rule
   6.1b) — bevisst holdt atskilt fra det eksisterende front_9/back_9-
   øktoppsettet i turnering-flyten (ADR-008), som løser et annet problem
   av andre grunner. ADR-033 er dermed fullt kildebelagt, ingen store
   åpne HCP-regelspørsmål gjenstår.
   **Bygging påbegynt samme dag:** brukeren instruerte at "Expected
   Score" (Rule 3.2b, upublisert WHS-formel) erstattes gjennomgående av
   WHS sin egen "Net Par"-term for uspilte hull — løser samtidig hele
   9-hulls-runde-spørsmålet uten en egen separat formel (Rule 5.1b droppet
   bevisst). Hele HCP-indeks-motor-komponenten (Net Double Bogey/Net Par,
   Adjusted Gross Score, Score Differential, Handicap Index fra beste-
   8-av-20 m/opptrappingstabell for <20 runder, Low Handicap Index, soft/
   hard cap, 9-hulls Course Handicap) er BYGGET og TESTET i
   `handicap_engine.py` — 41/41 tester (`test_handicap_engine.py`, kjørt
   uten pytest da det ikke er installert i miljøet), flere verifisert mot
   regelbokens egne tallregneeksempler (Rule 5.2a, Rule 5.1c, Diagram 5.8,
   Diagram 3.1b). Ren Python, ingen DB/API/frontend rørt ennå — matcher
   ADR-005s "test i isolasjon FØR resten".
   **Deretter, samme dag:** full databasemigrasjon skrevet
   (`020_personal_rounds.sql`, sju nye tabeller: `round`/
   `round_participant`/`round_hole` + fire for en global egendefinert-
   bane-katalog) og scratch-verifisert (9 sjekker som
   `teecup_app_scratch`, ikke superbruker — CHECK-constraints, XOR
   user_id/guest_name, kaskade-sletting, GIR-derivering bekreftet mot
   ekte data). INGEN RLS på disse tabellene (Beslutning A). `test_
   isolation.sql` fortsatt 12/12.
   **Rullet ut mot ekte `teecup_db` 2026-07-22,** bruker bekreftet
   eksplisitt: alle sju tabeller bekreftet opprettet, `test_isolation.sql`
   fortsatt 12/12 mot ekte database.
   **Deretter, samme dag: fullt API-lag bygget** (`app/routers/
   rounds.py` — opprett/liste/hent/slett runde, legg til/fjern gjest-
   deltaker, PATCH hull-for-hull-stats, fullfør-runde som kjører hele
   Adjusted-Gross-Score→Score-Differential-kjeden). Fant og fikset et
   reelt hull underveis: `round_participant` manglet rating-tall-
   kolonner (kun tee-NAVN var snapshotet, ikke selve Course/Slope/Par) —
   ny migrasjon `021_round_participant_rating_snapshot.sql`. 26 scratch-
   sjekker + en egen, ekte teeoff-live-oppslag-test (Beslutning C
   bekreftet: ingen `course`-rad skrives noe sted). Rullet ut mot ekte
   `teecup_db`/`teecup_api` 2026-07-22, `/health`/`/dashboard` → 200,
   `teeoff.no` upåvirket. `frontend/next.config.mjs` fikk `/rounds`/
   `/personal-courses` lagt til i `rewrites()` proaktivt (ikke deployet
   ennå, ingen frontend bruker den før neste runde).
   **Notat fra bruker, IKKE designet:** planer om å måle lengde på slag +
   opplyse avstand til ulike punkter på banen (golf-GPS/rangefinder-type
   funksjonalitet) — krever geografiske/GPS-data ingen kilde har i dag
   (verken teeoff eller `personal_course`). Se FEATURE_BACKLOG.md for
   full detalj.
   **Frontend bygget og rullet ut 2026-07-23, samme rekkefølge-prinsipp
   (engine → skjema → API → frontend) fullført:** tre nye,
   organisasjonsuavhengige endepunkter lagt til i `rounds.py`
   (`GET /rounds/official-search`/`{slug}` — samme mønster som
   `courses.py` sitt org-scopede søk, men uten org-kontekst, siden
   frittstående runder ikke har noen; `GET /personal-courses/{id}` —
   detalj med utslag+kjønn, manglet fra søk-runden) og en fjerde,
   nødvendig tilføyelse oppdaget UNDER frontend-designet: `RoundOut` bar
   aldri hull-nivå-data i det hele tatt — ny
   `GET .../participants/{id}/holes`. Hull-PATCH-endepunktet endret til å
   returnere hele den oppdaterte raden i stedet for `{"ok": true}`.
   **Reelt kontraktsfunn, bekreftet i scratch FØR frontend stolte på det:**
   hull-PATCH er IKKE et ekte delvis-PATCH — den skriver ALLE felt ved
   hvert kall, så et utelatt felt (f.eks. putts) nullstilles stille hvis
   frontend ikke sender det. Løst ved at `round-detail.tsx` alltid slår
   sammen med gjeldende hull-data før hver PATCH, aldri sender et isolert
   feltnavn alene — verifisert eksplisitt med en egen scratch-test som
   FØRST beviste nullstillings-oppførselen, DERETTER beviste at
   merge-mønsteret unngår den.
   Nye sider: `/rounds` (liste), `/rounds/new` (bane-kilde teeoff/egen,
   søk-før-opprett for egen bane samme idé som org-banene, utslag filtrert
   på brukerens registrerte kjønn, dato/starthull/hull-antall), `/rounds/
   [id]` (deltaker-faner, hull-navigasjon fra starthull, slag/putt-
   tallvelgere i samme stil som `session-scorecard.tsx` sin `StrokePicker`,
   kølle/retning/innspill/chip/bunker/straffeslag bak en «flere detaljer»-
   utvidelse, GIR utledet og vist klientside — aldri lagret, kun beregnet
   fra `approach_result`+slag+putt ved lesing, fullfør-runde med HCP-
   differensial-sammendrag). Lenket fra dashbordet som «Egne runder»
   (bevisst adskilt navn fra det eksisterende «Mine runder», som gjelder
   turnering-deltakelse — samme ord, to ulike konsepter).
   **Scratch-verifisert grundig** (isolert `teecup_app_scratch`-rolle +
   isolert scratch-MinIO + engangs API-container, samme mønster som hele
   økten ellers): 22 sjekker som dekker egendefinert-bane-opprettelse med
   to utslag/kjønn, søk, detalj, PATCH-kontrakten (inkl. det bevisste
   nullstillings-beviset over), GIR-derivering, gjest-fjerning,
   kryss-bruker-autorisasjon (403), og full fullføring med differensial
   — PLUSS en egen, separat test av hele teeoff-baserte opprettelsesløpet
   mot den ekte kjørende `teeoff_api`-containeren (Borregaard Golfklubb),
   som bekreftet course_handicap ble beregnet riktig. Ekte typesjekket
   PRODUKSJONSBUILD (`docker build --target builder`, samme steg som
   `Dockerfile` faktisk bruker) kjørt og bekreftet — alle nye ruter listet.
   **Rullet ut live 2026-07-23**, bruker bekreftet eksplisitt: ingen
   migrasjon, `docker compose up -d --build teecup_api teecup_frontend`,
   begge containere boot-et rent, `/health`/`/dashboard`/`/rounds` → 200,
   `teeoff.no` upåvirket. **Frittstående rundeføring har dermed backend
   OG frontend live** — se ADR-033 i ARCHITECTURE_DECISIONS.md for full
   detalj om alle fire lagene (engine/skjema/API/frontend).
   **Frontend ERSTATTET med V0-designet versjon, samme dag:** brukeren
   påpekte berettiget at de tre skjermene over var hånd-kodet av meg i
   stedet for designet i V0, som er prosjektets etablerte mønster for
   ALL øvrig frontend. Bekreftet arbeidsmåten uendret (jeg skriver
   V0-prompten, brukeren kjører den og sender koden tilbake, jeg
   integrerer). Tre prompter skrevet (liste/opprett/hull-registrering,
   inkl. eksplisitt tilgjengelighetskrav i hver), tre zip-eksporter
   mottatt og diffet mot levende tre (samme "full re-eksport"-mønster som
   alltid — kun `round-card.tsx`/`own-rounds.tsx`/`new-round.tsx`/
   `round-detail.tsx` + rutene var reelt nye). Samme kjente V0-feil dukket
   opp igjen og ble hoppet over (`app/clubs/[id]/page.tsx`, feilnavngitt
   slug-parameter — identisk feil som ble rettet under ADR-018). Mine
   hånd-bygde komponenter ERSTATTET (ikke supplert), datalag skrevet om
   fra V0s mock til ekte fetch — samme mønster som enhver annen skjerm.
   Full detalj (inkl. de fire reelle tilpasningene utover ren om-kabling)
   i ADR-033. Ekte typesjekket produksjonsbuild kjørt og bekreftet, ingen
   ny interaktiv nettleser-test (intet slikt verktøy tilgjengelig,
   flagget eksplisitt). **Rullet ut live 2026-07-23**, bruker bekreftet
   eksplisitt: `docker compose up -d --build teecup_frontend` (gjenskapte
   også `teecup_api` som vanlig bivirkning), begge containere boot-et
   rent, `/health`/`/dashboard`/`/rounds`/`/rounds/new` → 200, `teeoff.no`
   upåvirket. V0-zip-ene slettet fra prosjektroten.
   **Reell produksjonsbug rapportert av bruker (2 skjermbilder) og
   FIKSET samme dag:** `/rounds` var samtidig frontend-listesidens sti OG
   backend-APIets ressursprefiks — en verre, begge-veier-variant av
   ADR-016s medlemsside-felle. Statisk side vant over rewrite for det
   eksakte `/rounds`-treffet (klientens `fetch("/rounds")`/`POST /rounds`
   traff aldri backend, fikk Next sin egen HTML tilbake — derav "Klarte
   ikke å hente rundene dine"/"Klarte ikke å opprette runden"), mens
   rewriten vant over den DYNAMISKE `/rounds/[id]`-siden i motsatt
   retning (selve rundedetalj-siden var dermed fullstendig uoppnåelig,
   bekreftet direkte med `curl` før fiksen). Skjermbildets andre detalj —
   utslagsnavn "55/50/44/32" — ble sjekket direkte mot ekte `teeoff_api`
   og bekreftet Å IKKE VÆRE EN BUG (Tjøme Golfklubb sine faktiske
   utslagsnavn, lengde i hundremeter). Fikset ved å flytte alle tre
   frontend-rutene til et nytt, ikke-overlappende prefiks `/my-rounds/*`
   — API-et uendret på `/rounds`. `next.config.mjs` sin advarsel utvidet
   med denne nye varianten. Verifisert med `curl` mot ekte produksjon
   BÅDE før og etter (anonymt `GET /rounds` → nå korrekt backend-JSON,
   anonymt `GET /my-rounds/<uuid>` → nå korrekt `text/html`, altså
   endelig oppnåelig). Rullet ut live 2026-07-23, bruker bekreftet
   eksplisitt, kun `teecup_frontend` (+ vanlig `teecup_api`-bivirkning),
   `teeoff.no` upåvirket. Full detalj i ADR-033.
4. **Del 1 (fri, ukrevd sekundær-e-post) er nå BYGGET OG LIVE** (2026-07-21,
   se status over). **Del 2 (ekte konto-sammenslåing) fortsatt IKKE
   designet:** hva skjer hvis den ønskede adressen ALLEREDE tilhører en
   annen, eksisterende konto (i dag avvist tydelig med 409 DUPLICATE i
   stedet for gjettet på)? Trenger egen, separat designrunde — se
   FEATURE_BACKLOG.md for full analyse av hvorfor dette er vesentlig
   vanskeligere enn del 1.
5. **Deltaker-tilgang til lag-chat/scorekort OG HCP-historikk er nå BEGGE
   BYGGET OG LIVE** (2026-07-21, se status over) — ADR-031s tidligere
   noterte "naturlig neste steg"-punkter er dermed alle tettet, unntatt
   notifikasjons-/aktivitetsfeed og "Mine runder" for rene påmeldinger
   (begge fortsatt IKKE bygget, se FEATURE_BACKLOG.md).
6. Oppfølgingspunkt fra PWA-runden, eksplisitt notert på brukerens
   forespørsel: offline-scoreregistrering er ALDRI browser-testet i
   praksis (kun kodegjennomgang + build-verifisering, se ADR-028). Bruker
   bør selv åpne et scorekort, skru på Chrome DevTools sin Offline-bryter,
   registrere et par slag, skru nettet på igjen, og bekrefte at de faktisk
   synkes — først da er flyten reelt bevist.
7. Fortsatt åpne beslutninger fra FEATURE_BACKLOG.md: kode-regenerering for
   ADR-020, korrigering-godkjenning fra motpart, video/1-til-1-meldinger
   (bevisst utsatt i ADR-025).
8. Flere turneringsformater utover Ryder Cup (Københavner/High-low-high/
   Robbins/Try all, notert 2026-07-19) — ingen ADR-runde startet ennå.
9. Ved fremtidige nye V0-skjermer/-design i V0 (fortsett i samme prosjekt),
   FORVENT en full re-eksport hver gang — diff mot live-treet i et
   scratch-område før noe pakkes ut over eksisterende filer, og sjekk om
   V0-skjermen bygger inn handlinger backend ikke støtter ennå FØR
   integrering.
10. **Resterende hull fra 2026-07-28-gjennomgangen av frittstående runder,
    fortsatt IKKE bygget** (det viktigste — faktisk HCP — er tettet, se
    ADR-038 over): (a) offline-kø (ADR-028) er kun koblet til turnering-
    scorekortet (`session-scorecard.tsx`), IKKE frittstående runder
    (`round-detail.tsx`/`ScoringWizard`) — nettopp der man oftest står
    alene ute på banen uten dekning; (b) ingen Stableford-poengberegning
    for frittstående runder (kun rå slag/differensial), inkl. en uløst
    "plukket opp ballen"-tilstand; (c) rundedeling/visibility (ADR-036
    fase 2, public/private/friends) fortsatt ikke bygget; (d) flere
    flighter i én frittstående runde fortsatt kun drøftet (se
    FEATURE_BACKLOG.md); (e) varsler koblet til venneforespørsler, ikke
    til rundehendelser ennå.
11. **Ferdig, kun for historikk:** ekte spillformer (match/skins/fourball/
    foursome/greensome/scramble) for frittstående runder — backend
    (ADR-039 + minimums-spiller-håndhevelse) OG frontend (sideoppsett,
    skins-konfig i `/my-rounds/new`, matchstatus-/skins-tavle-visning,
    delt-ball-scorekort/-veiviser, `setup_complete`-gating) er nå BEGGE
    bygget, browserverifisert og live (se status 2026-07-28). Mulig
    fremtidig finpuss (ikke bedt om ennå): redigere et sidenavn i
    etterkant (kun opprett/slett finnes i dag), en tydeligere
    skins-poeng-forklaring i UI-et.