No description
Flytte is_participant-logikk til team_authz.py (unngå sirkulær import)
Widen scoring.py: get_scorecard/submit_hole_score/submit_hole_result/concede_match
Widen matches.py: list_matches/add_participant/remove_participant/lock_lineup
Widen tournaments.py: list_sessions/list_teams/concede_tournament
Widen courses.py: list_holes
Widen messaging.py: team chat REST-endepunkter (list/send/delete)
Legge til my_session_id/my_match_id i /auth/me sin my_tournaments
Frontend: legge til lenker til lag-chat/scorekort fra «Mine runder»
Scratch-verifisere hele deltaker-tilgang-runden (positive + negative kontroller)
Ekte typesjekket frontend-produksjonsbuild + backend py_compile på nytt før deploy-forslag
Presentere plan, deploye og oppdatere .md-filer for deltaker-tilgang-runden
Bygge og scratch-verifisere sekundær e-postadresse (migrasjon 017)
Bygge HCP-historikk over tid
Sekundær e-postadresse (det enkle tilfellet) er bygget og scratch-verifisert (20/20 sjekker), test_isolation.sql fortsatt 12/12.
Hva er bygget:
Migrasjon 017_secondary_email.sql — to nye tabeller (secondary_email_token, user_secondary_email), samme bevis-eierskap-token-mønster som ADR-032.
Backend: POST /auth/secondary-email (send bekreftelseslenke), POST /auth/secondary-email/confirm (bekreft, ingen sesjon påkrevd), DELETE /auth/secondary-email/{id}. Viktigst: verify_magic_link og login_with_password løser nå en sekundær adresse til den eksisterende eierens konto i stedet for å opprette en ny, separat konto — dette er selve poenget med funksjonen.
Frontend: ny seksjon "Andre e-postadresser" i /account (ikke dashbordet — se merknad under), /verify-email håndterer nå både e-postbytte og ny-sekundær-adresse via en ?kind=secondary-parameter.
Én bevisst plasseringsavgjørelse jeg tok uten å spørre: du sa opprinnelig at hele multi-e-post-flyten burde skje "fra dashboard-siden". Jeg la likevel dette i /account, fordi jeg her kun bygger det enkle tilfellet (fri adresse) — konsistent med hvor e-postbytte (ADR-032) allerede ligger. Når/hvis den harde saken (ekte konto-sammenslåing, der data faktisk "dukker opp") bygges senere, er dashbordet trolig riktigere siden gevinsten vises der. Si fra hvis du vil at den skal flyttes allerede nå.
Verifisert grundig: ny sekundær-adresse legges IKKE til før bekreftet; token kan ikke gjenbrukes; adresse som allerede er en annens hovedadresse ELLER en annens sekundæradresse avvises tydelig; innlogging (magic-link OG passord) via sekundæradressen løses korrekt til samme, eksisterende konto; en fremmed kan ikke slette andres sekundæradresse; og — kritisk — etter sletting oppretter en ny innlogging på den adressen en helt ny, separat konto (beviser fjerningen er reell).
Ingen migrasjon kjørt mot ekte teecup_db ennå.
|
||
|---|---|---|
| .claude | ||
| __pycache__ | ||
| app | ||
| frontend | ||
| .dockerignore | ||
| .gitignore | ||
| 001_initial_schema.sql | ||
| 002_roles_and_grants.sql | ||
| 003_scoring_and_blinddraw.sql | ||
| 004_auth.sql | ||
| 005_rls_null_guard.sql | ||
| 006_scheduling_and_locale.sql | ||
| 007_registration_and_player_fields.sql | ||
| 008_link_player_by_email.sql | ||
| 009_landing_pages_and_visibility.sql | ||
| 010_official_course_unique_ref.sql | ||
| 011_join_code_and_leading_side.sql | ||
| 012_password_2fa_and_org_invitations.sql | ||
| 013_messaging.sql | ||
| 014_tee_gender_to_rating.sql | ||
| 015_user_profile.sql | ||
| 016_profile_contact.sql | ||
| 017_secondary_email.sql | ||
| ARCHITECTURE_DECISIONS.md | ||
| CLAUDE.md | ||
| docker-compose.yml | ||
| Dockerfile | ||
| FEATURE_BACKLOG.md | ||
| handicap_engine.py | ||
| Live Tourney _ A Guide to Handicap Scoring in Golf for Tournaments.pdf | ||
| SCGA Club Digest.pdf | ||
| spilletyper-og-spilleformer-2023.pdf | ||
| TeeOff-logo-Retina-1.avif | ||
| test_handicap_engine.py | ||
| test_isolation.sql | ||