Files

T

davideandClaude Opus 5 822180bffc Riscrive AGENTS.md e riallinea la documentazione allo stato reale.

I riferimenti ai documenti in AGENTS.md erano rotti: una venticinquina di link
nella forma docs/[README.md](http://README.md), che spezzavano il nome del file
a meta e puntavano a domini inesistenti. Ora sono percorsi relativi verificati,
con CHANGELOG.md e DESIGN_DECISIONS.md sotto docs/ e PROJECT_STATE.md in root.

Tolte da AGENTS.md le sezioni Architettura, Documentazione e Struttura della
documentazione: duplicavano ARCHITECTURE.md e docs/README.md con uno stack ormai
parziale, contro la regola "ogni informazione ha una sola casa" che docs/README.md
stesso impone. Aggiunti invece i comandi, bun e la guardia minimumReleaseAge:
Codex e Cursor leggono solo AGENTS.md e non avevano modo di sapere come si
verifica una modifica. Scritta la checklist "Fine lavoro" che CLAUDE.md citava
senza che esistesse.

Nuova regola: chi aggiunge o modifica una funzione scrive o aggiorna il test nello
stesso lavoro, i test devono essere verdi e la doc del modulo va aggiornata se il
comportamento cambia (DD-020). Serve perche con main come branch di lavoro non
c'e piu un ambiente di prova tra il codice e i giocatori.

Il flusso git documentato non descriveva piu la realta: main e arrivato a 43
commit di vantaggio su develop, rimasto fermo. DD-003 e ora sostituita da DD-019:
il branch dei commit lo decide l'utente, l'assistente al massimo consiglia un
branch dedicato e non committa, non pusha e non apre PR di propria iniziativa.

Allineati di conseguenza ARCHITECTURE.md (sezione branch), README.md (flusso,
install con bun, comandi di test e lint), ROADMAP.md e TODO.md (le voci spuntate
sono in produzione, non su develop) e PROJECT_STATE.md (auth e profilo giocatore
in produzione, 20 migration fino a M9, passaggi 1-3 e 5 fatti).

Corretti poi sei disallineamenti tra documentazione e codice, ognuno verificato
sul sorgente:

- badge.md e obiettivi-squadra.md dicevano che le serie sono inerti e che
  serieAllenamenti e sempre 0, quindi badge e obiettivo "Continuita di squadra"
  non sbloccabili. Falso da 7237e8f: presenze.ts:48 le calcola e rosa.ts:64-67 le
  attacca al Giocatore. Il limite che resta e un altro, ora scritto: risposto_il
  non e ricostruibile prima di m9, quindi sulle risposte vecchie serieConferme e
  un'approssimazione.
- TODO.md e PROJECT_STATE.md davano il tracciamento tesseramento CSI come da
  fare, mentre ROADMAP, CHANGELOG e DATABASE lo davano per fatto. Lo e:
  admin.tsx:264-278 registra numero e data, :472 mostra Tesserato/Da tesserare,
  :676 il contatore.
- collegamento-csi.md indicava il check di parsing in src/lib/csi-core.test.ts;
  sta in test/unit/csi-core.test.ts, in src/lib non esiste nessun .test.ts.
- profilo-giocatore.md annunciava cinque aree del profilo e ne elencava sette.
- "Segnala un bug" e "Suggerisci una nuova funzionalita" (profilo.tsx:259-276,
  commit 72a9864) non erano documentati da nessuna parte, contro DD-002: ora
  stanno in profilo-giocatore.md e nel CHANGELOG.

npm run test: 28/28 file ok. npm run lint: 12 problemi, identici a prima di
questa modifica e tutti in src/, non toccato qui.

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>

2026-09-04 23:24:22 +02:00

6.6 KiB

Raw Blame History

Project State

Ultimo aggiornamento: 04/09/2026

Stato generale

Fase corrente:

Backend migrato al nuovo Supabase proprietario. Autenticazione Google, dashboard amministratore e Profilo Giocatore (lato giocatore e lato admin) sono in produzione su main. Foto profilo (M6) e Scout Live (M7) non dipendono più da localStorage: entrambi ora sincronizzano tra dispositivi tramite Supabase. Le serie di presenze sono calcolate sui dati reali (M9).

Infrastruttura

Si lavora direttamente su main (DD-019): develop esiste ma è fermo indietro, quindi la sua preview Vercel non rappresenta lo stato attuale
Cursor e Claude Code come ambienti di sviluppo
Vercel configurato; Environment Variables aggiornate al nuovo Supabase (Preview e Production)
Supabase proprietario attivo — Project Ref: kfkcldwncxqaixetsjes
20 migration in supabase/migrations/, fino a m9_risposte_presenze_risposto_il
Sviluppo locale verificato con il nuovo Supabase

Backend

Backend operativo: Supabase proprietario (kfkcldwncxqaixetsjes)
Lovable Cloud: non più backend operativo di CrAPP
Vecchio Project Ref hetycilxgkdmccelwerq: deprecato, non utilizzare

Database

Schema v1.0 e migration da M1 a M9 applicate al nuovo Supabase
public.giocatori_squadra: rosa iniziale di 17 giocatori (migration m5_email_giocatori_squadra) più quelli aggiunti da /admin a stagione in corso; da settembre 2026 tutti i giocatori attivi hanno l'email registrata (colonna email, DD-018), impostabile da /admin senza bisogno di una migration
public.giocatori_squadra è ora la source of truth della rosa letta dall'app (DD-015, 03/09/2026): «Aggiungi giocatore» e «Disattiva giocatore» della dashboard admin si riflettono su Squadra, Presenze, Pagelle, Badge e Scout. src/lib/crapp-data.ts resta solo come seed storico, fallback offline e sorgente della data di nascita (colonna non ancora presente su giocatori_squadra)
Migration m6_avatar_giocatori: bucket pubblico avatar-giocatori per le foto profilo, al posto di localStorage (una per giocatore, letto da src/lib/avatar-store.ts)
Migration m7_scout_partite: nuova tabella scout_partite per l'archivio delle partite scoutate concluse, e collegamento della tabella scout_sessioni (già presente nello schema ma mai usata) al blocco condiviso dello Scout Live — prima entrambi vivevano solo in localStorage, quindi visibili a un solo dispositivo

Moduli completati

Squadra
Presenze
Badge
Scout Live (blocco e archivio partite sincronizzati tra dispositivi, migration m7_scout_partite)
Pagelle
MVP
Notifiche
Profilo Giocatore (specifica in docs/modules/profilo-giocatore.md)
Serie di presenze (specifica in docs/modules/serie-presenze.md)

Autenticazione e dashboard amministratore

In produzione su main. Il login è l'unica via d'accesso (31/08/2026): la selezione libera del giocatore non esiste più, senza sessione Google si resta su /benvenuto, e i permessi di amministrazione arrivano solo da user_roles.

Attenzione all'ordine: finché il provider Google è spento in Supabase, «Accedi con Google» risponde

{"code":400,"error_code":"validation_failed","msg":"Unsupported provider: provider is not enabled"}

e nessuno entra nell'app. Vale ancora per chi allestisce un ambiente nuovo (per esempio lo stack Supabase locale): il passo 1 qui sotto va fatto per primo.

Passaggi in ordine, nessuno dei quali è reversibile a metà. Stato al 04/09/2026: fatti i passaggi 1, 2, 3 e 5 (M4 applicata); il passaggio 4 è un processo continuo (7 dei 16 giocatori attivi hanno già fatto il primo accesso).

Provider Google in Supabase — Google Cloud Console: consent screen External (scope email e profile, non sensibili: nessuna verifica richiesta, e la modalità Testing regge fino a 100 utenti, più che sufficiente per la squadra), credenziale Web application con redirect URI https://kfkcldwncxqaixetsjes.supabase.co/auth/v1/callback. Client ID e secret in Authentication → Providers → Google. In URL Configuration: Site URL di produzione, più localhost:8080 e il wildcard delle preview Vercel tra i Redirect URLs. Per provare sullo stack locale invece che sul cloud servono anche enabled = true in [auth.external.google] di supabase/config.toml, le due variabili SUPABASE_AUTH_GOOGLE_* in .env e una credenziale con redirect URI http://127.0.0.1:54321/auth/v1/callback.
Migration M2 (supabase db push). È un CREATE puro: si può applicare in produzione senza toccare il comportamento attuale.
Primo admin, dopo il primo login (l'ID esiste solo da quel momento): INSERT INTO public.user_roles (user_id, role) SELECT id, 'admin' FROM auth.users WHERE email = '<mail>';
Collegamento degli account: ciascuno accede con Google e viene collegato in automatico al proprio giocatore per email (DD-018) — nessuna scelta manuale. Finché l'email di un giocatore non è impostata, il suo accesso mostra un errore; da /admin si imposta l'email di un giocatore (nuovo o esistente) senza bisogno di una migration. Da settembre 2026 tutti i giocatori attivi hanno l'email registrata, ma il collegamento vero e proprio (auth_user_id) avviene solo al primo login di ciascuno, quindi resta un processo continuo che si ripete a ogni nuovo giocatore aggiunto a stagione in corso. Uno slot già collegato può essere liberato solo da un admin.
Solo a squadra collegata: migration m4_solo_autenticati, che toglie al ruolo anon l'accesso alle tabelle v1.0. Da lì in poi i dati sono raggiungibili solo con una sessione; le route in src/routes/api/public/ usano la service role e continuano a funzionare. Applicata in produzione il 03/09/2026 — non è più necessario aspettare che l'intera rosa abbia già fatto login: il login era già l'unica via d'accesso lato app, quindi i giocatori non ancora collegati non erano comunque impattati; M4 chiudeva solo un residuo di accesso diretto al database bypassando l'app.

Attenzione: dev e produzione condividono lo stesso progetto Supabase. Un account di prova che collega uno slot lo occupa anche in produzione, e va liberato da un admin.

Prossimo sviluppo

Niente di assegnato: la v1.1 è completa, tesseramento CSI incluso (numero e data di tessera registrabili da /admin, migration m8_tesseramento_csi). Le voci ancora aperte stanno in docs/ROADMAP.md.

Note

Il progetto segue una metodologia document-first.

Ogni nuova funzionalità viene progettata nella cartella docs/modules/ prima di essere implementata.

6.6 KiB Raw Blame History