Erol Haagenrud
d395f86753
Skrive migrasjon 052 (guest_first_name/guest_last_name + backfill) Bygge backend: splitt navn i ParticipantCreate/Update, auto-synk guest_name Bygge backend: GET known-guest-oppslag (e-post-basert, scoped til egen bruker) Bygge backend: retroaktiv e-post-kobling ved innlogging (auth.py) Bygge backend: HTML-e-post-støtte i email.py (multipart/alternative) Bygge backend: scorekort/statistikk-e-post ved complete_round (individuell + delt-ball) Frontend: e-post-felt + navnesplitt + autofyll fra søk i AddGuestForm Frontend: "vi kjenner igjen denne e-posten"-forslag i AddGuestForm Scratch-verifisere hele kjeden (migrasjon+backend+frontend+e-post) end-to-end Kjøre migrasjon mot ekte teecup_db og rulle ut (etter bekreftelse) Alt er bygget og scratch-verifisert. Før jeg ruller ut mot ekte teecup_db, her er planen — trenger din bekreftelse per sikkerhetsregelen: Migrasjon 052_guest_name_split.sql (rent additiv, ingen sletting): ALTER TABLE round_participant ADD COLUMN guest_first_name text; + guest_last_name text Backfiller eksisterende guest_name-rader ved samme "første ord/resten"-heuristikk som frontend bruker til autofyll Deretter: docker compose up -d --build teecup_api teecup_frontend Hva som er bygget: E-post som valgfritt felt i "Legg til uten konto (gjest)" (fantes i backend fra før, manglet i selve skjemaet) Navn splittet i for-/etternavn (etternavn valgfritt) Retroaktiv kobling: spiller runder som gjest før du har konto → runden dukker opp i "Egne runder" når du logger inn med samme e-post, men teller ikke automatisk mot faktisk HCP (må bekreftes selv — unngår at en fremmed kan påvirke HCP-en din uten samtykke) E-post med scorekort + statistikk + invitasjon sendes automatisk når runden fullføres, til enhver gjest med registrert e-post — første HTML-e-post i appen Autofyll fra søkefeltet inn i gjesteskjemaet "Vi kjenner igjen denne e-posten"-forslag, scoped til dine egne tidligere gjester (ikke globalt — unngår en personvernlekkasje)
117 lines
6.9 KiB
Markdown
117 lines
6.9 KiB
Markdown
# 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…). Fasit.
|
|
- `FEATURE_BACKLOG.md` — hva som gjenstår, hva som er utsatt, hva som mangler.
|
|
- `CHANGELOG.md` — kronologisk arbeidslogg (hva som er bygget, når, hvordan
|
|
det ble verifisert, kjente fallgruver funnet underveis). IKKE noe å lese
|
|
i sin helhet hver økt — les den ved regresjon-feilsøking, eller når du
|
|
trenger å vite hvordan/hvorfor noe konkret ble bygget som det ble (grep
|
|
etter filnavn/ADR-nummer/feature-navn). Se filens egen header for full
|
|
bruksanvisning.
|
|
- Endres en beslutning: legg til en ny ADR, ikke slett historikk. Hold
|
|
disse 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
|
|
CHANGELOG.md 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 og neste steg
|
|
Den detaljerte, kronologiske statusloggen (hva som er ferdig, verifisert
|
|
og rullet ut, runde for runde) flyttet til `CHANGELOG.md` 2026-08-02 —
|
|
denne filen ble for stor til å injiseres i sin helhet hver økt uten å
|
|
fortrenge de faktiske reglene over. `CHANGELOG.md` sin egen "Neste
|
|
steg"-seksjon nederst har den ferskeste, mest detaljerte punktlisten over
|
|
åpne tråder; `FEATURE_BACKLOG.md` har det bredere, mindre ferske bildet
|
|
av hva som gjenstår/er utsatt. Oppdater `CHANGELOG.md` (ikke denne filen)
|
|
når noe bygges, verifiseres og rulles ut — samme format og disiplin som
|
|
før: dato, hva som ble gjort, hvordan det ble verifisert, hva som ble
|
|
rullet ut og hvordan.
|
|
|