Documenta dashboard admin, profili e ambiente locale

Checklist "Fine lavoro" di AGENTS.md per il lavoro dei due commit precedenti.

- DATABASE.md: profili_giocatore creata, user_roles come fonte dei permessi, e
  la nuova sezione Storage per il bucket privato.
- ARCHITECTURE.md: autenticazione e ruoli tra i punti fermi, comandi dello stack
  Supabase locale; gli stessi comandi in CLAUDE.md.
- CHANGELOG.md: la voce è marcata come presente su develop e non ancora in
  produzione.
- PROJECT_STATE.md: i cinque passaggi per attivare login e dashboard in
  produzione, in ordine, con il redirect URI di Google e la query per il primo
  admin. Segnalato che dev e produzione condividono lo stesso database.
- TODO.md: la dashboard esce dal backlog; entra il profilo lato giocatore, senza
  il quale la dashboard resterebbe senza dati.
- modules/profilo-giocatore.md: registrate due scelte fatte in corso d'opera —
  solo Google al posto di "Google oppure Email", e "Visualizza profilo" come
  scheda in linea invece di una schermata separata.

ROADMAP.md resta con la casella non spuntata: la funzionalità è su develop, non
ancora rilasciata.

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

CLAUDE.md

@@ -16,6 +16,11 @@ npm run build     # build di produzione (nitro)
 npm run lint      # eslint (include prettier come regola)
 npm run format    # prettier --write .
 npm run test      # suite di test (test/); npm run test:all per quella completa
+
+npx supabase start    # database locale in Docker (migration applicate + seed)
+npx supabase stop     # spegne i container
+npx supabase db reset # ricrea il database locale da zero
+npx supabase db push  # applica le migration al progetto cloud
 ```
 
 Verifica minima prima di consegnare: `npm run lint` + `npm run test`.

PROJECT_STATE.md

@@ -6,7 +6,9 @@ Ultimo aggiornamento: 30/08/2026
 
 Fase corrente:
 
-Backend migrato al nuovo Supabase proprietario. M1 completata. Profilo Giocatore da implementare (M2).
+Backend migrato al nuovo Supabase proprietario. M1 completata. M2 e M3 scritte e da applicare.
+Autenticazione Google e dashboard amministratore implementate su `develop`, da attivare in
+produzione seguendo i passaggi più sotto. Profilo Giocatore lato giocatore ancora da fare.
 
 ---
 
@@ -56,9 +58,35 @@ Profilo Giocatore (specifica in `docs/modules/profilo-giocatore.md`)
 
 ---
 
+## Autenticazione e dashboard amministratore
+
+Implementate su `develop`, **non ancora attive in produzione**. Il codice è additivo: finché
+i passaggi qui sotto non sono fatti, l'app si comporta esattamente come prima.
+
+Passaggi in ordine, nessuno dei quali è reversibile a metà:
+
+1. **Provider Google in Supabase** — Google Cloud Console: consent screen *External* (scope
+   `email` e `profile`, nessuna verifica richiesta), 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.
+2. **Migration M2 e M3** (`supabase db push`). Sono `CREATE` puri: si possono applicare in
+   produzione senza toccare il comportamento attuale.
+3. **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>';`
+4. **Collegamento dei 17 account**: ciascuno accede con Google e sceglie il proprio nome una
+   volta sola. Uno slot già collegato può essere liberato solo da un admin.
+5. **Solo a squadra collegata**: `VITE_AUTH_OBBLIGATORIA=true` su Vercel (fa sparire la
+   selezione libera del giocatore), poi la migration che rimuove le policy `anon` dalle
+   tabelle v1.0. È l'unico passo che cambia il comportamento per tutti.
+
+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
 
-**M2** — `profili_giocatore` + Supabase Storage privato + RLS
+Profilo giocatore lato giocatore (caricamento di documento, certificato e foto tessera):
+finché non esiste, la dashboard amministratore mostra profili vuoti.
 
 ---
 

docs/ARCHITECTURE.md

@@ -44,7 +44,12 @@ docs/           documentazione ufficiale
   server functions, `attachSupabaseAuth`).
 - **Supabase**: `src/integrations/supabase/client.ts` (browser/SSR, chiave publishable — file
   generato) e `client.server.ts` (`supabaseAdmin`, solo server). `types.ts` è generato dallo
-  schema.
+  schema; finché non viene rigenerato, le tabelle introdotte da M1/M2 si usano tramite
+  `client-nuove-tabelle.ts`, con i tipi di riga dichiarati nei moduli di `src/lib/`.
+- **Autenticazione**: login Google via Supabase Auth (`src/lib/auth.ts`, DD-011); i permessi
+  di amministrazione arrivano da `user_roles` (`src/lib/ruoli.ts`). La variabile
+  `VITE_AUTH_OBBLIGATORIA` decide se `/benvenuto` accetta ancora la selezione libera del
+  giocatore: finché è spenta, login e vecchio accesso convivono.
 
 ## Livello dati
 
@@ -95,6 +100,19 @@ npm run test:e2e          # percorsi sull'app servita
 npm run test:all          # tutto
 ```
 
+Database di sviluppo in locale (Docker), alternativo al progetto Supabase cloud:
+
+```bash
+npx supabase start   # avvia lo stack locale e applica tutte le migration
+npx supabase stop    # spegne i container
+npx supabase db reset # ricrea il database da zero: migration + supabase/seed.sql
+npx supabase db push  # applica le migration al progetto cloud
+```
+
+`supabase/seed.sql` popola qualche profilo di prova e gira **solo in locale**. Serve perché
+il progetto cloud è uno solo, condiviso tra sviluppo e produzione: lo stack locale è il posto
+dove provare le migration distruttive senza toccare i dati veri.
+
 ## Branch e flusso di sviluppo
 
 - `main` → produzione, deploy automatico su Vercel.

docs/CHANGELOG.md

@@ -6,6 +6,19 @@ qui: sta in [ROADMAP.md](ROADMAP.md).
 
 ## Versione attuale — agosto 2026
 
+### Autenticazione e dashboard amministratore (su `develop`, non ancora in produzione)
+
+- Login con Google tramite Supabase Auth (DD-011). Al primo accesso l'account si collega a
+  un giocatore di `giocatori_squadra`, e il collegamento non è più modificabile dal
+  giocatore stesso (DD-016 regola 2).
+- I permessi di amministrazione arrivano da `user_roles` (`src/lib/ruoli.ts`) e non più
+  dalla lista di nomi in `crapp-data.ts`, che resta solo come ponte finché
+  `VITE_AUTH_OBBLIGATORIA` non viene acceso.
+- Nuova schermata `/admin`: stato dei profili della squadra, download di documento,
+  certificato e foto tessera, export CSV per il tesseramento CSI.
+- Migration `m2_profili_giocatore` (tabella dei profili) e `m3_bucket_profili` (bucket
+  privato), entrambe additive.
+
 ### Test
 
 - Suite di test in `test/` (unit, integration, end-to-end) eseguita con bun,

docs/DATABASE.md

@@ -11,11 +11,17 @@ non in questo file.
 |---|---|---|
 | `giocatori_squadra` | Anagrafica operativa della squadra, con ID testuali (`g1`…`gN`), dati gestiti dagli admin (nome, cognome, numero, ruolo) e collegamento all'account (`auth_user_id`). | Introdotta dalla migration `m1_giocatori_squadra`, già popolata (17 giocatori) ma **non ancora letta dal codice**: la rosa arriva tuttora da `src/lib/crapp-data.ts`, che resta il fallback anche dopo il passaggio. Destinata a diventare la source of truth. Vedi DD-015 e DD-016. |
 | `giocatori` | Anagrafica giocatori con UUID. | Presente ma **non usata** dal codice attuale: la convergenza è rinviata (DD-012, DD-014). |
-| `profili_giocatore` | Dati personali, metadati del documento d'identità, certificato medico e path dei file, in relazione 1:1 con `giocatori_squadra`. | **Prevista** per la v1.1 (DD-016), non ancora creata. |
+| `profili_giocatore` | Dati personali, metadati del documento d'identità, certificato medico e path dei file, in relazione 1:1 con `giocatori_squadra`. | Creata dalla migration `m2_profili_giocatore` (DD-016). Letta da `src/lib/profili.ts`; le policy mostrano al giocatore solo il proprio profilo e all'admin tutti. I file non stanno qui: la tabella conserva i path nel bucket. |
-| `user_roles` | Ruoli applicativi (es. amministratore, giocatore). | |
+| `user_roles` | Ruoli applicativi (es. amministratore, giocatore). | Fonte dei permessi di amministrazione, letta da `src/lib/ruoli.ts` (DD-011). Il primo admin va inserito a mano; vedi [PROJECT_STATE.md](../PROJECT_STATE.md). |
 
 `giocatori_squadra` / `giocatori` sono usate da: Squadra, Profili, Presenze, Scout, Badge, Pagelle.
 
+## Storage
+
+| Bucket | Scopo | Note |
+|---|---|---|
+| `profili-giocatore` | Documento d'identità, certificato medico e foto tessera, in cartelle per giocatore (`<giocatore_id>/<sezione>.<est>`). | **Privato** e destinato a restare tale: contiene documenti e dati sanitari, che non devono mai avere URL pubblici (DD-016 regola 4). Il giocatore gestisce solo la propria cartella, l'admin può scaricare tutto tramite signed URL a scadenza breve. Creato dalla migration `m3_bucket_profili`. |
+
 ## Eventi e presenze
 
 | Tabella | Scopo | Note |

docs/TODO.md

@@ -6,9 +6,16 @@ Solo il lavoro in corso o imminente. L'elenco completo delle funzionalità previ
 ## In corso
 
 - Documentazione tecnica del progetto.
+- Autenticazione Google e dashboard amministratore: implementate su `develop`. Restano da
+  fare, in quest'ordine: configurazione del provider Google in Supabase, applicazione delle
+  migration M2/M3, inserimento del primo admin in `user_roles`, collegamento dei 17 account,
+  e solo alla fine `VITE_AUTH_OBBLIGATORIA=true` + rimozione delle policy `anon`.
+  Stato di dettaglio in [PROJECT_STATE.md](../PROJECT_STATE.md).
 
 ## Prossimo
 
+- Profilo giocatore lato giocatore: senza le schermate di caricamento di documento,
+  certificato e foto, la dashboard amministratore resta a zero dati.
 - Certificati medici (roadmap v1.1).
 - Gestione tesseramenti CSI (roadmap v1.1).
 
@@ -31,5 +38,4 @@ Non documentate nemmeno le route API pubbliche in `src/routes/api/public/` (`csi
 ## Backlog
 
 - AI Allenamenti (roadmap v1.2).
-- Dashboard amministratore (roadmap v1.1).
 - Backup automatici (roadmap, idee future).

docs/modules/profilo-giocatore.md

@@ -31,7 +31,9 @@ Può:
 
 ### Primo accesso
 
-1. Login tramite Google oppure Email.
+1. Login tramite Google oppure Email. *Implementato con il solo Google: la squadra ha tutti
+   un account Google, e un secondo metodo è additivo (un bottone in più sulla stessa
+   schermata) il giorno che serve.*
 2. Selezione del proprio giocatore.
 3. Accesso alla Home.
 
@@ -134,7 +136,8 @@ Contiene.
 
 ## Dashboard amministratore
 
-Gli amministratori dispongono di una schermata dedicata.
+Gli amministratori dispongono di una schermata dedicata (`/admin`, raggiungibile da
+Profilo → Impostazioni).
 
 Per ogni giocatore vengono mostrati.
 
@@ -145,7 +148,7 @@ Per ogni giocatore vengono mostrati.
 
 Azioni disponibili.
 
-- Visualizza profilo
+- Visualizza profilo (la scheda si apre in linea nell'elenco: nessuna schermata separata)
 - Scarica certificato
 - Scarica documento
 - Scarica foto tessera

supabase/.branches/_current_branch

@@ -0,0 +1 @@
+main