Scheda di dettaglio per gli eventi extra-campo, senza infortunato tra le risposte

Gli eventi generici (es. cena di squadra) avevano solo il conteggio presenze in
card, senza modo di vedere chi ha risposto. Aggiunta la route /evento/$id sul
modello di allenamento/partita, con RosaPresenze per l'elenco nominativo.

Lo stato "infortunato" non è una risposta pertinente per questi eventi: escluso
da badge, gruppi e bottoni di risposta sia in RosaPresenze che in EventoCard,
tramite la funzione condivisa includeInfortunato() in presenze.ts.

Documentazione dei moduli (calendario, presenze, palloni, badge) allineata.

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

.gitignore

@@ -40,4 +40,12 @@ dist-ssr
 # Optional
 .vercel
 # Supabase CLI local state
-supabase/.temp/
+supabase/.temp/
+
+# Backup locali del database (contengono dati reali degli utenti):
+# ignora tutto il contenuto generato, ma tieni in git lo script e il README.
+backups/*
+!backups/backup.sh
+!backups/download-storage.mjs
+!backups/storage-core.ts
+!backups/README.md

.lovable/plan/obiettivi-di-squadra-sezione-in-squadra-widget-in-home-2026-08-03.md

@@ -1,38 +0,0 @@
-# Obiettivi di squadra: sezione in Squadra + widget in home
-
-## Stato attuale
-
-Al momento c'è un solo "obiettivo di squadra" ed è hardcoded nella home (`src/routes/index.tsx`, riga 136): **"90% di presenze ad agosto"** con una barra finta all'82%. Non esiste uno schema dati né una sezione dedicata, e non è collegato a calendario, presenze o statistiche. Le voci "obiettivi" nelle descrizioni di Squadra e Profilo si riferiscono ai badge individuali, non a obiettivi di squadra.
-
-## Cosa faccio
-
-1. **Modello dati locale** in `src/lib/crapp-data.ts`
-
-- Nuovo tipo `ObiettivoSquadra`: id, titolo, descrizione, target, valore attuale, unità, scadenza (opzionale), icona.
-- Array `obiettiviSquadra` con gli obiettivi demo della stagione.
-
-2. **Sezione "Obiettivi di squadra" dentro la scheda Squadra** (`src/routes/squadra.tsx`)
-
-- Nuova sezione con la lista completa degli obiettivi: barra di progresso, percentuale, stato (in corso / completato).
-- Ordinati con gli obiettivi in corso in cima e i completati in fondo.
-- Nessuna nuova rotta e nessuna modifica al bottom nav.
-
-3. **Widget home dinamico** (`src/routes/index.tsx`)
-
-- Sostituisce l'obiettivo hardcoded: mostra sempre il primo obiettivo in corso preso dalla lista.
-- Progresso calcolato dai dati reali dove possibile (es. presenze derivate dagli eventi).
-
-4. **Obiettivi demo iniziali**
-
-- 90% di presenze ad agosto (collegato agli eventi di agosto).
-- 70% di risposte entro 24h nel prossimo mese.
-- Prima vittoria del campionato (collegato allo storico match).
-- 5 vittorie in campionato (collegato allo storico match).
-- 10 vittorie in campionato (collegato allo storico match).
-- 1 evento di squadra al mese (pizzata, ecc.).
-
-## Cosa non cambia
-
-- Resta un prototipo offline: i dati restano in `src/lib/crapp-data.ts`.
-- I badge individuali restano come sono in `src/lib/badges.ts` e nella rosa di `src/routes/squadra.tsx`.
-- Bottom nav e rotte invariate.

.lovable/plan/rendere-crapp-operativa-migrazione-dal-prototipo-al-cloud-2026-07-31.md

@@ -1,58 +0,0 @@
-# Rendere CrAPP operativa: migrazione dal prototipo al Cloud
-
-## Stato attuale
-
-L'app è un prototipo UI con alcune funzioni già collegate a Lovable Cloud:
-
-- Già sul Cloud: voti MVP (`mvp_voti`), iscrizioni push (`push_subscriptions`), sessioni scout (`scout_sessioni`), turni palloni (`turni_palloni`).
-- Ancora in locale come dati demo: rosa giocatori, calendario eventi, storico partite, classifica CSI, statistiche individuali, presenze/assenze, badge.
-
-## Cosa serve per renderla operativa
-
-1. **Rosa e profili giocatori sul database**
-   - Creare tabella `profiles` (o `giocatori`) con nome, numero maglia, ruolo, data di nascita, foto profilo.
-   - Collegare ogni riga all'utente autenticato corrispondente.
-   - Rimuovere la rosa statica da `src/lib/crapp-data.ts` e caricarla dal backend.
-
-2. **Autenticazione reale**
-   - Sostituire la semplice selezione "Chi sei?" in `localStorage` con login email/password o OAuth (Google).
-   - Ogni giocatore accede con le proprie credenziali e vede solo i propri dati modificabili.
-   - Necessaria per garantire che uno scout o un voto MVP provenga davvero da quel giocatore.
-
-3. **Calendario eventi persistente**
-   - Tabella `eventi` con tipo, titolo, data, ora, luogo, avversario, casa/fuori.
-   - Tabella `presenze` (evento_id, giocatore_id, stato, aggiornato_il).
-   - I compleanni possono restare derivati dalla data di nascita dei giocatori.
-
-4. **Statistiche e badge dinamici**
-   - Tabella `statistiche` o `azioni_scout` (evento_id, giocatore_id, tipo azione, valore, creato_il).
-   - I badge vengono calcolati in tempo reale dalle statistiche accumulate, senza valori fissi in `crapp-data.ts`.
-
-5. **Scout live collegato ai dati reali**
-   - Le azioni registrate in `scout.tsx` devono scrivere sulle tabelle eventi/statistiche.
-   - Mantenere il lock di modifica singolo e l'attivazione solo il giorno della partita.
-
-6. **Classifica CSI**
-   - Tabella `classifica` aggiornata manualmente da un admin o importata dal sito CSI quando disponibile.
-   - Per ora nessuna API CSI ufficiale: si inserisce a mano o si copia/incolla.
-
-7. **Notifiche push definitive**
-   - Verificare che i cron job inviino correttamente i promemoria palloni.
-   - Aggiungere notifiche per conferma eventi, promemoria presenze, MVP votabile.
-
-8. **Ruoli e permessi**
-   - Definire chi può creare/modificare eventi (capitano/admin).
-   - Chi può fare scout (designato per partita).
-   - Chi può modificare i turni palloni (tutti, come da tua richiesta).
-
-## Cosa resta salvato nel Cloud
-
-Sì: tutto ciò che viene scritto sulle tabelle Lovable Cloud/Supabase resta salvato online e condiviso tra tutti i dispositivi.
-
-I dati demo in `src/lib/crapp-data.ts` invece no: sono file statici, quindi ogni aggiornamento dell'app li sovrascrive e ogni telefono li vede identici.
-
-## Decisioni da prendere insieme
-
-- Vuoi abilitare login email/password per ogni giocatore, o preferisci mantenere la selezione "Chi sei?" senza password per semplicità?
-- Chi gestirà inserimento eventi e aggiornamento classifica: solo alcuni o tutta la squadra?
-- Vuoi procedere per fasi (prima rosa + calendario + presenze, poi statistiche) o tutto insieme?

.lovable/plan/ridimensionamento-badge-nella-lista-squadra-2026-07-31.md

@@ -1,25 +0,0 @@
-# Ridimensionamento badge nella lista squadra
-
-## Obiettivo
-
-Rendere i badge accanto al nome del giocatore nella lista squadra più compatti e meno invasivi, mantenendo lo stile stilizzato (icone Lucide colorate per grado) e lasciando la scheda espansa con una dimensione leggibile.
-
-## Modifiche previste
-
-1. **Lista squadra (`src/routes/squadra.tsx`)**
-   - Ridurre le icone badge sbloccati mostrate accanto al nome da `h-4 w-4` (16px) a `h-3 w-3` (12px).
-   - Mantenere il massimo di 3 badge visibili e il contatore `+N` con testo ridotto a `text-[9px]` per armonizzare.
-   - Lasciare invariati avatar, nome, ruolo ed età.
-
-2. **Scheda giocatore espansa (`src/routes/squadra.tsx`)**
-   - Portare le icone badge dalla dimensione attuale a `h-4 w-4` (16px), leggibili ma non troppo grandi.
-   - Mantenere card, colori per grado (bronzo/argento/oro) e testi descrittivi.
-
-3. **Verifica**
-   - Controllare la preview su `/squadra` per confermare che i badge in lista siano discreti e la scheda espansa rimanga leggibile.
-   - Eseguire build per assicurarsi che non ci siano errori di tipo o stile.
-
-## Cosa non cambia
-
-- Colori dei gradi, soglie badge, logica di sblocco e votazione MVP.
-- Layout generale della pagina e bottom navigation.

.lovable/plan/rimuovere-placeholder-livello-7-dal-profilo-2026-08-05.md

@@ -1,14 +0,0 @@
-# Rimuovere placeholder "Livello 7" dal Profilo
-
-## Obiettivo
-
-Eliminare il testo statico "Livello 7" dalla scheda profilo, dato che non è collegato a nessun calcolo reale e l'utente preferisce toglierlo per ora.
-
-## Modifica
-
-- `src/routes/profilo.tsx`: rimuovere il paragrafo `<p className="font-display text-2xl leading-none">Livello 7</p>` (riga 116) e, se necessario, riallineare il layout circostante per evitare spazi vuoti strani.
-
-## Verifica
-
-- Build senza errori.
-- Preview della pagina Profilo: nessun riferimento a "Livello" visibile.

.lovable/plan/selezione-giocatore-al-primo-avvio-2026-07-31.md

@@ -1,34 +0,0 @@
-# Selezione giocatore al primo avvio
-
-Aggiungere un flusso di onboarding che chiede "Chi sei?" la prima volta che l'app viene aperta, memorizzando la scelta in `localStorage`. Il profilo e la home si aggiorneranno automaticamente in base al giocatore selezionato.
-
-## Cosa cambia
-
-1. **Nuovo store `src/lib/user-store.ts`**
-   - Persiste in `localStorage` l'`id` del giocatore scelto.
-   - Espone `useGiocatoreCorrente()` che restituisce il giocatore selezionato o `null`.
-   - Espone `impostaGiocatore(id)` e `resetGiocatore()`.
-
-2. **Nuova route `/benvenuto`**
-   - Schermata full-screen con logo, titolo "Benvenuto in CrAPP" e lista scrollabile della rosa.
-   - Ogni riga mostra iniziali, nome, ruolo e numero maglia.
-   - Al tap su un giocatore, lo store viene aggiornato e l'utente viene portato a `/`.
-   - Non mostra la bottom navigation.
-
-3. **Reindirizzamento condizionato in `__root.tsx`**
-   - Se non è ancora stato selezionato un giocatore, qualunque route apre `/benvenuto`.
-   - Dopo la scelta, l'app funziona normalmente.
-
-4. **Sostituzione di `giocatoreCorrente` con `useGiocatoreCorrente()`**
-   - Aggiornare `src/routes/index.tsx` per salutare il giocatore selezionato e mostrarne le statistiche rapide.
-   - Aggiornare `src/routes/profilo.tsx` per renderlo il profilo personale del giocatore scelto.
-
-5. **Cambio utente dalle impostazioni**
-   - In `src/routes/profilo.tsx`, aggiungere una voce "Cambia giocatore" che resetta la selezione e porta a `/benvenuto`.
-
-## Note tecniche
-
-- `localStorage` viene letto solo lato client, usando `useSyncExternalStore` per evitare mismatch di hydration.
-- La rosa reale è già presente in `src/lib/crapp-data.ts` (`giocatori`).
-- La costante esportata `giocatoreCorrente` verrà rimossa; i componenti consumeranno il nuovo hook.
-- Nessun backend richiesto: resta un prototipo locale.

.lovable/plan/turno-palloni-nel-calendario-promemoria-2026-07-31.md

@@ -1,45 +0,0 @@
-# Turno palloni nel calendario + promemoria
-
-Aggiungere a ogni allenamento/partita un incaricato dei palloni, condiviso tra tutti, con rotazione automatica proposta dall'app e promemoria (in-app e push).
-
-## Cosa vedrà la squadra
-
-- **Riga "Palloni" su ogni evento** (allenamento e partita) nella card del calendario e in Home: avatar + nome dell'incaricato, oppure "Da assegnare".
-- **Chiunque può cambiarlo**: tocco sulla riga, si apre la lista della rosa, si sceglie il nome. La modifica è immediata e visibile a tutti.
-- **Proposta automatica a rotazione**: l'app suggerisce chi non ha ancora fatto il turno di recente (o è stato meno volte incaricato). Il suggerimento è solo una proposta: resta sempre modificabile.
-- **Storico turni** nella scheda squadra/giocatore: quante volte ciascuno ha portato i palloni.
-- **Due promemoria per l'incaricato**:
-  1. il giorno stesso dell'evento in cui li deve **prendere** a fine allenamento/partita;
-  2. il giorno dell'evento successivo, per ricordargli di **riportarli**.
-- I promemoria arrivano come banner ben visibile in Home e, per chi attiva le notifiche, come notifica push sul telefono.
-
-## Impostazione tecnica
-
-**Backend (Lovable Cloud)**
-
-- Attivazione di Lovable Cloud.
-- Tabella `eventi` (spostando i dati demo attuali su database) o, in alternativa minima, tabella `turni_palloni` con `evento_id`, `giocatore_id`, `aggiornato_da`, `aggiornato_il`. Scelgo la seconda per limitare il refactor: gli eventi restano in `crapp-data.ts` finché non si passa a calendario dinamico.
-- Tabella `push_subscriptions` (giocatore_id, endpoint, chiavi) per le notifiche.
-- Grant espliciti + RLS: lettura e scrittura aperte a tutti gli utenti dell'app (nessun login previsto oggi → policy per `anon` limitate a queste tabelle, nessun dato personale sensibile).
-- Server functions in `src/lib/palloni.functions.ts`: `getTurni`, `setTurno`, `suggerisciTurno`.
-
-**Frontend**
-
-- Nuovo componente `TurnoPalloni` usato in `EventoCard` e in Home.
-- Lettura via TanStack Query (`ensureQueryData` nel loader, `useSuspenseQuery` nel componente), invalidazione dopo la modifica.
-- Banner promemoria in Home basato su data odierna + evento successivo, mostrato solo al giocatore selezionato in `user-store`.
-
-**Notifiche push**
-
-- Service worker dedicato al messaging (separato dalla PWA esistente), chiavi VAPID salvate come secret.
-- Schermata in Profilo: "Attiva notifiche palloni" con richiesta di permesso.
-- Invio schedulato tramite un endpoint `src/routes/api/public/promemoria-palloni.ts` protetto da secret, richiamato una volta al giorno da un job pianificato (pg_cron).
-- Nota: su iPhone le notifiche push funzionano solo se l'app è installata dalla schermata Home.
-
-## Ordine di lavoro
-
-1. Attivare Lovable Cloud e creare tabelle + policy.
-2. Server functions + UI del turno palloni (assegnazione manuale condivisa).
-3. Rotazione automatica suggerita + storico turni.
-4. Banner promemoria in-app.
-5. Notifiche push + job giornaliero.

.lovable/project.json

@@ -1,5 +0,0 @@
-{
-  "schemaVersion": 1,
-  "template": "tanstack_start_ts_current",
-  "revision": "tanstack_start_ts_current-9e5645c506e5"
-}

AGENTS.md

@@ -5,8 +5,8 @@ su questo repository. Valgono integralmente; `CLAUDE.md` le richiama e non le ri
 
 CrAPP è una PWA per la gestione di una squadra di pallavolo. Deve ridurre il lavoro degli
 amministratori, aumentare il coinvolgimento dei giocatori, centralizzare le informazioni della
-squadra e usare l'AI solo quando porta un beneficio reale. Il perché sta in
-[docs/VISION.md](docs/VISION.md).
+squadra e usare l'AI solo quando porta un beneficio reale. Deve restare semplice, veloce e
+usabile dallo smartphone anche da chi non è pratico.
 
 ## Prima di modificare il codice
 
@@ -30,6 +30,7 @@ Le dipendenze si installano con **bun** (`bun.lock`). `bunfig.toml` impone
 npm run dev       # vite dev su http://localhost:8080
 npm run build     # build di produzione (nitro)
 npm run lint      # eslint (include prettier come regola)
+npm run typecheck # controllo dei tipi TypeScript (tsc, senza generare file)
 npm run format    # prettier --write .
 npm run test      # suite di test (test/); npm run test:all per quella completa
 
@@ -59,7 +60,7 @@ copre più il comportamento nuovo va aggiornata nello stesso lavoro.
 Prima di dire che hai finito:
 
 1. i test delle funzioni aggiunte o modificate esistono e sono verdi;
-2. `npm run lint` e `npm run test` passano (`test:all` se hai toccato database o flussi e2e);
+2. `npm run lint`, `npm run typecheck` e `npm run test` passano (`test:all` se hai toccato database o flussi e2e);
 3. la documentazione toccata dalla modifica è aggiornata (vedi Test e Tracciabilità);
 4. hai detto all'utente cosa hai cambiato, cosa hai lasciato fuori e quali rischi vedi.
 
@@ -83,8 +84,7 @@ conversazioni: commit con messaggio descrittivo, più il documento giusto tra
 [docs/CHANGELOG.md](docs/CHANGELOG.md) (cosa è stato rilasciato e quando),
 [PROJECT_STATE.md](PROJECT_STATE.md) (stato generale del progetto),
 [docs/DESIGN_DECISIONS.md](docs/DESIGN_DECISIONS.md) (decisioni architetturali, voci `DD-XXX`),
-[docs/ROADMAP.md](docs/ROADMAP.md), [docs/TODO.md](docs/TODO.md),
-[docs/DATABASE.md](docs/DATABASE.md) (se cambia lo schema).
+[docs/ROADMAP.md](docs/ROADMAP.md), [docs/DATABASE.md](docs/DATABASE.md) (se cambia lo schema).
 
 Quali contenuti vanno in quale file, e le convenzioni di scrittura, stanno nelle regole di
 manutenzione di [docs/README.md](docs/README.md): ogni informazione ha una sola casa, non

PROJECT_STATE.md

@@ -1,6 +1,6 @@
 # Project State
 
-Ultimo aggiornamento: 04/09/2026
+Ultimo aggiornamento: 27/09/2026
 
 ## Stato generale
 
@@ -10,7 +10,10 @@ 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).
+reali (M9). Prima versione pre-release rilasciata (0.9.0); la prima versione stabile, 1.0.0
+con il ruolo allenatore, è pronta ma non ancora pubblicata (vedi `docs/CHANGELOG.md`).
+Cancellare un evento pulisce ora a cascata tutte le tabelle collegate (M14) e le righe orfane
+da cancellazioni precedenti a M14 sono state bonificate una tantum (M15/M16).
 
 ---
 
@@ -21,7 +24,8 @@ reali (M9).
 - 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`
+- 32 migration in `supabase/migrations/`, fino a `m21_ruolo_allenatore` (24/09/2026), tutte
+  applicate in produzione (verificato con `npx supabase migration list` il 24/09/2026)
 - Sviluppo locale verificato con il nuovo Supabase
 
 ---
@@ -36,7 +40,30 @@ reali (M9).
 
 ## Database
 
-- Schema v1.0 e migration da M1 a M9 applicate al nuovo Supabase
+- Schema v1.0 e migration da M1 a M16 applicate al nuovo Supabase
+  (`m16_funzione_bonifica_dati_evento_orfani` in produzione dal 09/09/2026, verificata con
+  `npx supabase migration list`)
+- Migration `m17_notifiche_utente` (15/09/2026, DD-030): nuova tabella `notifiche_utente`
+  per il centro notifiche in-app — **in produzione** dal 15/09/2026 (è additiva: non tocca
+  schema o comportamento esistenti, vedi DD-030). Il codice che la usa (centro notifiche,
+  route aggiornate) non è ancora deployato: la tabella si riempie già in background
+- Migration `m18_nascita_pubblica_giocatori_squadra` (15/09/2026, DD-031): nuova colonna
+  `giocatori_squadra.nascita`, sincronizzata da `profili_giocatore.data_nascita` — corregge
+  l'"Invalid Date" in Squadra per chi inserisce la propria nascita dal Profilo invece del
+  seed storico. **In produzione** dal 15/09/2026, ma il backfill copriva solo il seed
+  storico: chi aveva già un profilo compilato prima di M18 è rimasto scoperto
+- Migration `m19_backfill_nascita_da_profili_esistenti` (15/09/2026, DD-031): completa il
+  backfill di M18 per tutti i profili già esistenti — **in produzione** (risulta applicata
+  in `npx supabase migration list` del 24/09/2026)
+- Migration `m20_ruolo_allenatore_enum` e `m21_ruolo_allenatore` (24/09/2026, DD-034): ruolo
+  allenatore (colonna `giocatori_squadra.tipo`, valore `allenatore` di `app_role`, policy e
+  trigger) — verificate in locale con `npx supabase db reset` e `npm run test:all`, **in
+  produzione** dal 24/09/2026 (`supabase db push`). Compatibili con la 0.9.2: senza allenatori
+  registrati non cambiano nulla. Il codice che le usa non è ancora deployato
+- Slot `g18` «Beta Tester» impostato come allenatore in produzione il 24/09/2026 (colonna
+  `tipo`, ruolo assegnato dal trigger di M21). Numero 99 e ruolo «Palleggiatore»
+  lasciati apposta finché gira la 0.9.2, che lo mostra ancora come giocatore: da svuotare
+  da `/admin` dopo il deploy del codice nuovo
 - `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
@@ -48,10 +75,31 @@ reali (M9).
   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 `m10_azzera_turni_palloni_allenamenti`: toglie i turni palloni salvati sugli
+  allenamenti, che non ricevono più una proposta automatica (vedi
+  [docs/modules/palloni.md](docs/modules/palloni.md))
+- Migration `m11_scritture_per_ruolo`: le policy di scrittura rispecchiano i permessi
+  dell'interfaccia (DD-023). Fino a M10 un qualsiasi utente autenticato poteva svuotare il
+  calendario o riscrivere il voto di un altro parlando direttamente con PostgREST; la tabella
+  dei permessi sta in [docs/DATABASE.md](docs/DATABASE.md) ed è verificata da
+  `test/integration/permessi.test.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
+- Migration `m13_convocati_e_pagelle_chiuse`: le RLS di `mvp_voti`/`pagelle_voti`/
+  `badge_social_voti` richiedono che votante e votato siano convocati all'evento (e per le
+  pagelle anche `pagelle_chiuse = false`)
+- Migration `m14_pulizia_dati_evento_cancellato` (DD-029): cancellare un evento pulisce a
+  cascata, tramite trigger, tutte le tabelle collegate (`risposte_presenze`,
+  `cacche_partita`, `mvp_voti`, `pagelle_voti`, `badge_social_voti`, `turni_palloni`,
+  `scout_sessioni`, `scout_live`, `scout_partite`)
+- Migration `m15_bonifica_dati_evento_orfani`: bonifica una tantum delle righe orfane da
+  cancellazioni di eventi precedenti a M14, senza toccare i vecchi voti MVP/pagelle/badge
+  social legati a id Scout o CSI
+- Migration `m16_funzione_bonifica_dati_evento_orfani`: la stessa logica di bonifica di M15
+  resta richiamabile come funzione `bonifica_dati_evento_orfani()` (riservata al service
+  role), se mai servisse di nuovo
 
 ---
 
@@ -59,13 +107,18 @@ reali (M9).
 
 - Squadra
 - Presenze
-- Badge
+- Badge (incluso badge social)
 - Scout Live (blocco e archivio partite sincronizzati tra dispositivi, migration `m7_scout_partite`)
 - Pagelle
 - MVP
+- Obiettivi di squadra
+- Turno palloni (specifica in `docs/modules/palloni.md`)
+- Infortuni, in forma minima (specifica in `docs/modules/infortuni.md`)
 - Notifiche
 - Profilo Giocatore (specifica in `docs/modules/profilo-giocatore.md`)
 - Serie di presenze (specifica in `docs/modules/serie-presenze.md`)
+- Collegamento CSI: classifica campionato e Coppa, storico e dettaglio partita — formazioni,
+  scontri diretti (specifica in `docs/modules/collegamento-csi.md`)
 
 ---
 
@@ -125,9 +178,9 @@ 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](docs/ROADMAP.md).
+Niente di assegnato: l'avviso certificati in scadenza (DD-035) è implementato e versione
+1.1.0 (vedi `docs/CHANGELOG.md`). Le voci ancora aperte stanno in
+[docs/ROADMAP.md](docs/ROADMAP.md), sotto «Prossimo».
 
 ---
 

README.md

@@ -34,6 +34,7 @@ npm run dev     # http://localhost:8080
 ```bash
 npm run build   # build di produzione
 npm run lint    # eslint (include prettier)
+npm run typecheck  # controllo dei tipi TypeScript
 npm run test    # test unit; npm run test:all per la suite completa
 ```
 

backups/README.md

@@ -0,0 +1,132 @@
+# Backup di disaster recovery
+
+Script per scaricare su questo host un backup completo del progetto Supabase:
+schema DB, dati, utenti auth e file storage. Serve per poter ripartire in fretta
+se il progetto Supabase (o Vercel) venisse perso.
+
+## Preparazione, passo per passo
+
+Da fare una volta sola per host (poi il backup si rilancia semplicemente con
+`./backups/backup.sh`).
+
+1. **Installa/aggiorna la CLI Supabase** (via `npx`, non serve installarla a parte):
+   ```bash
+   npx supabase --version
+   ```
+2. **Accedi con il tuo account Supabase**:
+   ```bash
+   npx supabase login
+   ```
+   Si apre il browser per l'OAuth; il token resta salvato in locale.
+3. **Collega il repo al progetto Supabase** (il `project_id` è già in
+   `supabase/config.toml`, quindi in genere basta):
+   ```bash
+   npx supabase link --project-ref <project_id>
+   ```
+   Verifica che sia andato a buon fine con `npx supabase projects list`
+   (il progetto deve comparire con `"linked":true`).
+4. **Crea/controlla il file `.env`** nella root del repo (accanto a
+   `package.json`, non dentro `backups/`) con almeno queste due chiavi:
+   ```
+   VITE_SUPABASE_URL="https://<project_id>.supabase.co"
+   SUPABASE_SERVICE_ROLE_KEY="<service role key>"
+   ```
+   Le trovi su [supabase.com/dashboard](https://supabase.com/dashboard) → progetto →
+   Project Settings → API. La **service role key** è quella con permessi pieni
+   (bypassa le RLS): serve solo per scaricare i file dai bucket, non va mai
+   esposta lato client né committata.
+5. **Verifica che gpg sia installato** (serve per cifrare, di default):
+   ```bash
+   gpg --version
+   ```
+   Su Debian/Ubuntu: `sudo apt install gnupg` se manca.
+
+A questo punto sei pronto per lanciare il backup vero e proprio (vedi sotto).
+
+## Uso
+
+```bash
+./backups/backup.sh              # crea backups/YYYYMMDD_HHMM/, poi comprime e cifra
+                                  # in backups/YYYYMMDD_HHMM.tar.gz.gpg (chiede una
+                                  # passphrase a te scelta) e cancella cartella+tar.gz
+                                  # in chiaro
+./backups/backup.sh --no-encrypt # come sopra ma lascia solo il tar.gz in chiaro
+                                  # (nessuna passphrase richiesta)
+```
+
+La passphrase non è salvata da nessuna parte: la scegli tu al momento (gpg la
+chiede due volte, per conferma) e ti serve identica per decifrare in seguito —
+se la perdi, il backup cifrato è irrecuperabile. Tienila in un password manager.
+
+Ogni esecuzione crea una cartella/archivio nuovo con timestamp: non sovrascrive
+backup precedenti. Non c'è pulizia automatica dei vecchi backup — cancellali a
+mano quando non servono più.
+
+Se un passaggio fallisce (un dump o anche un solo file dello storage non scaricato),
+lo script si ferma con un errore e **non** stampa «Backup completato»: un backup
+incompleto non va considerato valido, rilancialo.
+
+Il backup contiene:
+
+| File/cartella       | Contenuto                                                                                                  |
+| ------------------- | ---------------------------------------------------------------------------------------------------------- |
+| `schema_public.sql` | schema delle tabelle applicative (tabelle, funzioni, RLS)                                                  |
+| `data_public.sql`   | dati delle tabelle applicative                                                                             |
+| `schema_auth.sql`   | schema utenti Supabase Auth                                                                                |
+| `data_auth.sql`     | utenti reali, incluso l'hash della password                                                                |
+| `storage/`          | tutti i file dei bucket (`avatar-giocatori`, `profili-giocatore`: foto, documenti d'identità, certificati) |
+
+## Decomprimere
+
+Archivio cifrato (caso di default), chiede la passphrase scelta al momento
+del backup:
+
+```bash
+gpg -d backups/AAAAMMGG_hhmm.tar.gz.gpg | tar xz -C backups/
+```
+
+Ricrea `backups/AAAAMMGG_hhmm/` con dentro i file elencati sopra.
+
+Archivio non cifrato (generato con `--no-encrypt`):
+
+```bash
+tar xzf backups/AAAAMMGG_hhmm.tar.gz -C backups/
+```
+
+## Ripristino
+
+1. Nuovo progetto Supabase (o `supabase start` in locale via Docker).
+2. Importa nell'ordine: `schema_public.sql` → `schema_auth.sql` →
+   `data_auth.sql` → `data_public.sql` (gli utenti auth prima dei dati
+   pubblici, perché `giocatori.auth_user_id` referenzia `auth.users.id`).
+3. Ricrea i bucket `avatar-giocatori` e `profili-giocatore` e ricarica il
+   contenuto di `storage/`.
+4. Reimposta le variabili d'ambiente su Vercel/locale (non incluse in questo
+   backup — vedi sotto).
+5. Redeploy dal repo git (il codice non serve backupparlo qui, è già su
+   GitHub e Gitea).
+
+## Cosa NON è incluso
+
+- **Variabili d'ambiente Vercel**: richiede `vercel login` interattivo, non
+  automatizzabile da questo script. Esportale a mano con `vercel env pull`.
+- **Codice applicativo**: vive nel repo git, non nel database.
+
+## Sicurezza
+
+Questi backup contengono password hash, documenti d'identità e altri dati
+personali reali. Per questo:
+
+- la cartella `backups/` è in `.gitignore` (tranne questo README e gli script:
+  quelli sì restano in git) — **non committare mai i dati generati**;
+- se sposti un backup fuori da questo host, usa l'archivio cifrato (default)
+  invece del tar.gz in chiaro generato con `--no-encrypt`;
+- cancella i backup in chiaro quando non ti servono più.
+
+## File di questa cartella
+
+| File                   | Ruolo                                                                                            |
+| ---------------------- | ------------------------------------------------------------------------------------------------ |
+| `backup.sh`            | Punto di ingresso: esegue dump e download in ordine                                              |
+| `download-storage.mjs` | Scarica i file dei bucket (usa la service role key del `.env`)                                   |
+| `storage-core.ts`      | Logica pura (lettura del `.env`, elenco dei file), coperta da `test/unit/backup-storage.test.ts` |

backups/backup.sh

@@ -0,0 +1,50 @@
+#!/usr/bin/env bash
+# Backup completo di disaster recovery: schema + dati DB, utenti auth, file storage.
+# Uso:
+#   ./backups/backup.sh              crea backups/YYYYMMDD_HHMM/, comprime e cifra con gpg (chiede una passphrase)
+#   ./backups/backup.sh --no-encrypt come sopra ma lascia solo il tar.gz in chiaro
+#
+# Richiede: essere già collegati al progetto Supabase (supabase login + link, già fatto
+# in questo repo), avere .env con VITE_SUPABASE_URL e SUPABASE_SERVICE_ROLE_KEY, e bun
+# installato (esegue download-storage.mjs, che importa un modulo .ts).
+
+set -euo pipefail
+
+SCRIPT_DIR="$(cd "$(dirname "${BASH_SOURCE[0]}")" && pwd)"
+STAMP="$(date +%Y%m%d_%H%M)"
+RUN_DIR="$SCRIPT_DIR/$STAMP"
+
+mkdir -p "$RUN_DIR"
+echo "==> Backup in $RUN_DIR"
+
+echo "==> Dump schema pubblico"
+npx supabase db dump --linked -f "$RUN_DIR/schema_public.sql"
+
+echo "==> Dump dati pubblici"
+npx supabase db dump --linked --data-only -f "$RUN_DIR/data_public.sql"
+
+echo "==> Dump schema auth"
+npx supabase db dump --linked --schema auth -f "$RUN_DIR/schema_auth.sql"
+
+echo "==> Dump dati auth (utenti)"
+npx supabase db dump --linked --schema auth --data-only -f "$RUN_DIR/data_auth.sql"
+
+echo "==> Download file storage (bucket)"
+bun "$SCRIPT_DIR/download-storage.mjs" "$RUN_DIR/storage"
+
+echo "==> Backup completato: $RUN_DIR"
+
+TARBALL="$RUN_DIR.tar.gz"
+echo "==> Comprimo in $TARBALL"
+tar -C "$SCRIPT_DIR" -czf "$TARBALL" "$STAMP"
+
+if [[ "${1:-}" == "--no-encrypt" ]]; then
+  echo "==> Archivio pronto: $TARBALL"
+else
+  ARCHIVE="$TARBALL.gpg"
+  echo "==> Cifro in $ARCHIVE (verrà chiesta una passphrase)"
+  gpg --symmetric --cipher-algo AES256 -o "$ARCHIVE" "$TARBALL"
+  rm -rf "$RUN_DIR" "$TARBALL"
+  echo "==> Archivio cifrato pronto: $ARCHIVE"
+  echo "    Per estrarlo: gpg -d $ARCHIVE | tar xz"
+fi

backups/download-storage.mjs

@@ -0,0 +1,45 @@
+// Scarica tutti i file dei bucket Supabase Storage per il backup di disaster recovery.
+// Uso: node backups/download-storage.mjs [cartella-output]
+import { createClient } from "@supabase/supabase-js";
+import { mkdir, writeFile, readFile } from "node:fs/promises";
+import { dirname, join } from "node:path";
+import { elencaFile, leggiEnv } from "./storage-core.ts";
+
+const env = leggiEnv(await readFile(new URL("../.env", import.meta.url), "utf8"));
+for (const [chiave, valore] of Object.entries(env)) process.env[chiave] ??= valore;
+
+const BUCKETS = ["avatar-giocatori", "profili-giocatore"];
+const OUT_DIR = process.argv[2] ?? new URL("./storage/", import.meta.url).pathname;
+
+const supabase = createClient(process.env.VITE_SUPABASE_URL, process.env.SUPABASE_SERVICE_ROLE_KEY);
+
+const elencaCartella = (bucket) => async (prefisso) => {
+  const { data, error } = await supabase.storage.from(bucket).list(prefisso, { limit: 1000 });
+  if (error) throw error;
+  return data;
+};
+
+const falliti = [];
+
+for (const bucket of BUCKETS) {
+  console.log(`Bucket: ${bucket}`);
+  const files = await elencaFile(elencaCartella(bucket));
+  console.log(`  ${files.length} file trovati`);
+  for (const path of files) {
+    const { data, error } = await supabase.storage.from(bucket).download(path);
+    if (error) {
+      console.error(`  ERRORE ${path}:`, error.message);
+      falliti.push(`${bucket}/${path}`);
+      continue;
+    }
+    const destPath = join(OUT_DIR, bucket, path);
+    await mkdir(dirname(destPath), { recursive: true });
+    await writeFile(destPath, Buffer.from(await data.arrayBuffer()));
+    console.log(`  scaricato: ${bucket}/${path}`);
+  }
+}
+if (falliti.length) {
+  console.error(`${falliti.length} file non scaricati: il backup storage è incompleto.`);
+  process.exit(1);
+}
+console.log("Fatto.");

backups/storage-core.ts

@@ -0,0 +1,30 @@
+/** Logica pura del backup storage, separata dalla rete per poterla testare. */
+
+/** Righe `CHIAVE=valore` di un file `.env`; toglie le virgolette solo se aprono e chiudono. */
+export function leggiEnv(testo: string): Record<string, string> {
+  const env: Record<string, string> = {};
+  for (const riga of testo.split("\n")) {
+    const match = /^([\w.]+)=(.*)$/.exec(riga.trim());
+    if (!match) continue;
+    const [, chiave, grezzo] = match as unknown as [string, string, string];
+    const tra = /^(["'])(.*)\1$/.exec(grezzo);
+    env[chiave] = tra ? tra[2]! : grezzo;
+  }
+  return env;
+}
+
+export type Voce = { name: string; id: string | null };
+
+/** Tutti i percorsi dei file sotto `prefisso`; Supabase segnala le cartelle con `id: null`. */
+export async function elencaFile(
+  lista: (prefisso: string) => Promise<Voce[]>,
+  prefisso = "",
+): Promise<string[]> {
+  const file: string[] = [];
+  for (const voce of await lista(prefisso)) {
+    const percorso = prefisso ? `${prefisso}/${voce.name}` : voce.name;
+    if (voce.id === null) file.push(...(await elencaFile(lista, percorso)));
+    else file.push(percorso);
+  }
+  return file;
+}

bun.lock

@@ -3,9 +3,8 @@
   "configVersion": 1,
   "workspaces": {
     "": {
-      "name": "tanstack_start_ts",
+      "name": "crapp",
       "dependencies": {
-        "@lovable.dev/cloud-auth-js": "^1.1.2",
         "@supabase/supabase-js": "^2.111.0",
         "@tailwindcss/vite": "^4.2.1",
         "@tanstack/react-query": "^5.101.1",
@@ -27,7 +26,7 @@
       },
       "devDependencies": {
         "@eslint/js": "^9.32.0",
-        "@lovable.dev/vite-tanstack-config": "2.8.5",
+        "@tanstack/devtools-vite": "^0.8.3",
         "@types/canvas-confetti": "^1.9.0",
         "@types/node": "^22.16.5",
         "@types/react": "^19.2.0",
@@ -130,14 +129,6 @@
 
     "@jridgewell/trace-mapping": ["@jridgewell/trace-mapping@0.3.31", "", { "dependencies": { "@jridgewell/resolve-uri": "^3.1.0", "@jridgewell/sourcemap-codec": "^1.4.14" } }, "sha512-zzNR+SdQSDJzc8joaeP8QQoCQr8NuYx2dIIytl1QeBEZHJ9uW6hebsrYgbz8hJwUQao3TWCMtmfV8Nu1twOLAw=="],
 
-    "@lovable.dev/cloud-auth-js": ["@lovable.dev/cloud-auth-js@1.1.2", "https://europe-west4-npm.pkg.dev/lovable-core-prod/sandbox-npm-cache/@lovable.dev/cloud-auth-js/-/cloud-auth-js-1.1.2.tgz", {}, "sha512-xz8ocewsgwkp8giau272/eWWU3XrchCg5uba4yQPPYtevHTXaVU3sD+fO1JjyPBHacVcOcwhmgUiU9TKHt63cg=="],
-
-    "@lovable.dev/vite-plugin-dev-server-bridge": ["@lovable.dev/vite-plugin-dev-server-bridge@1.2.1", "", { "peerDependencies": { "vite": ">=5.0.0 <9.0.0" } }, "sha512-JdADRwpEJA5t0ggXbd96dND23Wsp69Af9lVSV5m7MnMGxJZlPgqAqz7HUKcfJESfI5M5yFZOl9e0x76JMMDOAg=="],
-
-    "@lovable.dev/vite-plugin-hmr-gate": ["@lovable.dev/vite-plugin-hmr-gate@1.3.5", "https://europe-west1-npm.pkg.dev/lovable-core-prod/sandbox-npm-cache/@lovable.dev/vite-plugin-hmr-gate/-/vite-plugin-hmr-gate-1.3.5.tgz", { "peerDependencies": { "vite": ">=5.0.0 <9.0.0" } }, "sha512-LxCj6JIbYRQ6peMm2aVn/bhHLkwZ5eZ4Cn6gmh7LfjaplqZHlA24nhCowgt6ZLfbckc4d8tSy0He7H8EiFEXag=="],
-
-    "@lovable.dev/vite-tanstack-config": ["@lovable.dev/vite-tanstack-config@2.8.5", "https://europe-west1-npm.pkg.dev/lovable-core-prod/sandbox-npm-cache/@lovable.dev/vite-tanstack-config/-/vite-tanstack-config-2.8.5.tgz", { "dependencies": { "@lovable.dev/vite-plugin-dev-server-bridge": "^1.2.1", "@lovable.dev/vite-plugin-hmr-gate": "^1.3.4", "@tanstack/devtools-vite": "^0.8.1", "lightningcss": "^1.30.0" }, "peerDependencies": { "@tailwindcss/vite": ">=4.0.0", "@tanstack/react-start": ">=1.100.0", "@vitejs/plugin-react": ">=4.0.0", "nitro": ">=3.0.260603-beta", "vite": ">=5.0.0 <9.0.0", "vite-tsconfig-paths": ">=6.0.0" }, "optionalPeers": ["nitro"] }, "sha512-qPNxEXjvRsrbJHKgHxuLWpRW/gu2nIM+62qjTUCbCno5nRPMKyJQNsgjh48qjAkS6T0MRIkY/3BENNXeGsi5hw=="],
-
     "@napi-rs/wasm-runtime": ["@napi-rs/wasm-runtime@1.2.0", "", { "dependencies": { "@tybys/wasm-util": "^0.10.3" }, "peerDependencies": { "@emnapi/core": "^2.0.0-alpha.3", "@emnapi/runtime": "^2.0.0-alpha.3" } }, "sha512-kDoONqMa+VnZ4vvvu/ZUurpJ4gkZU57e7g69qpNgWhYcZFPUHZM2CEMKm+cG6ufDVALbjMvfmMjFVqaK7uEMnA=="],
 
     "@oozcitak/dom": ["@oozcitak/dom@2.0.2", "", { "dependencies": { "@oozcitak/infra": "^2.0.2", "@oozcitak/url": "^3.0.0", "@oozcitak/util": "^10.0.0" } }, "sha512-GjpKhkSYC3Mj4+lfwEyI1dqnsKTgwGy48ytZEhm4A/xnH/8z9M3ZVXKr/YGQi3uCLs1AEBS+x5T2JPiueEDW8w=="],
@@ -424,7 +415,7 @@
 
     "canvas-confetti": ["canvas-confetti@1.9.4", "https://europe-west1-npm.pkg.dev/lovable-core-prod/sandbox-npm-cache/canvas-confetti/-/canvas-confetti-1.9.4.tgz", {}, "sha512-yxQbJkAVrFXWNbTUjPqjF7G+g6pDotOUHGbkZq2NELZUMDpiJ85rIEazVb8GTaAptNW2miJAXbs1BtioA251Pw=="],
 
-    "chalk": ["chalk@4.1.2", "", { "dependencies": { "ansi-styles": "^4.1.0", "supports-color": "^7.1.0" } }, "sha512-oKnbhFyRIXpUuez8iBMmyEa4nbj4IOQyuhc/wy9kY7/WVPcwIO9VA668Pu8RkO7+0G76SLROeyw9CpQ061i4mA=="],
+    "chalk": ["chalk@5.6.2", "", {}, "sha512-7NzBL0rN6fMUW+f7A6Io4h40qQlG+xGmtMxfbnH/K7TAtt8JQWVQK+6g0UXKMeVJoyV5EkkNsErQ8pVD3bLHbA=="],
 
     "chokidar": ["chokidar@5.0.0", "", { "dependencies": { "readdirp": "^5.0.0" } }, "sha512-TQMmc3w+5AxjpL8iIiwebF73dRDF4fBIieAqGn9RGCWaEVwQ6Fb2cGe31Yns0RRIzii5goJ1Y7xbMwo1TxMplw=="],
 
@@ -800,10 +791,6 @@
 
     "@tailwindcss/oxide-wasm32-wasi/tslib": ["tslib@2.8.1", "", { "bundled": true }, "sha512-oJFu94HQb+KVduSUQL7wnpmqnfmLsOA/nAh6b6EH0wCEoK0/mPeXU6c3wKDV83MkOuHPRHtSXKKU99IBazS/2w=="],
 
-    "@tanstack/devtools-bundler-core/chalk": ["chalk@5.6.2", "", {}, "sha512-7NzBL0rN6fMUW+f7A6Io4h40qQlG+xGmtMxfbnH/K7TAtt8JQWVQK+6g0UXKMeVJoyV5EkkNsErQ8pVD3bLHbA=="],
-
-    "@tanstack/devtools-vite/chalk": ["chalk@5.6.2", "", {}, "sha512-7NzBL0rN6fMUW+f7A6Io4h40qQlG+xGmtMxfbnH/K7TAtt8JQWVQK+6g0UXKMeVJoyV5EkkNsErQ8pVD3bLHbA=="],
-
     "@tanstack/router-generator/zod": ["zod@4.4.3", "", {}, "sha512-ytENFjIJFl2UwYglde2jchW2Hwm4GJFLDiSXWdTrJQBIN9Fcyp7n4DhxJEiWNAJMV1/BqWfW/kkg71UDcHJyTQ=="],
 
     "@tanstack/router-plugin/zod": ["zod@4.4.3", "", {}, "sha512-ytENFjIJFl2UwYglde2jchW2Hwm4GJFLDiSXWdTrJQBIN9Fcyp7n4DhxJEiWNAJMV1/BqWfW/kkg71UDcHJyTQ=="],
@@ -820,6 +807,8 @@
 
     "@typescript-eslint/visitor-keys/eslint-visitor-keys": ["eslint-visitor-keys@5.0.1", "", {}, "sha512-tD40eHxA35h0PEIZNeIjkHoDR4YjjJp34biM0mDvplBe//mB+IHCqHDGV7pxF+7MklTvighcCPPZC7ynWyjdTA=="],
 
+    "eslint/chalk": ["chalk@4.1.2", "", { "dependencies": { "ansi-styles": "^4.1.0", "supports-color": "^7.1.0" } }, "sha512-oKnbhFyRIXpUuez8iBMmyEa4nbj4IOQyuhc/wy9kY7/WVPcwIO9VA668Pu8RkO7+0G76SLROeyw9CpQ061i4mA=="],
+
     "h3/srvx": ["srvx@0.12.4", "", { "bin": { "srvx": "bin/srvx.mjs" } }, "sha512-RixzFlMn3dvzDTpKIAXhXrqL4cy6vScNCP0VVwgVbUBU94o+DiXLsFnAZetbyKAEnK6Ox3hzHXWGsyv/Iibv7g=="],
 
     "h3-v2/rou3": ["rou3@0.8.1", "", {}, "sha512-ePa+XGk00/3HuCqrEnK3LxJW7I0SdNg6EFzKUJG73hMAdDcOUC/i/aSz7LSDwLrGr33kal/rqOGydzwl6U7zBA=="],

bunfig.toml

@@ -4,4 +4,4 @@ saveTextLockfile = true
 minimumReleaseAge = 86400
 # Each entry bypasses the 24h guard for one package — confirm with the user
 # before adding any.
-minimumReleaseAgeExcludes = ["@lovable.dev/vite-tanstack-config", "@lovable.dev/mcp-js", "@lovable.dev/vite-plugin-dev-server-bridge", "@lovable.dev/vite-plugin-hmr-gate", "@lovable.dev/email-js", "@lovable.dev/webhooks-js"]
+minimumReleaseAgeExcludes = []

docs/ARCHITECTURE.md

@@ -60,8 +60,9 @@ ricorrente:
   `src/router.tsx` (`staleTime` 5 min, `gcTime` 30 min, `refetchOnWindowFocus/Mount/Reconnect`
   disattivati, `retry: 1`);
 - dopo una mutazione la cache si aggiorna con `setQueryData`, **non** con
-  `invalidateQueries`: invalidare provoca una rilettura e costa una query in più (unica
-  eccezione oggi: `scout-live.ts`);
+  `invalidateQueries`: invalidare provoca una rilettura e costa una query in più. Unica
+  eccezione: `scout-live.ts`, dove il lock può essere stato preso da un altro dispositivo,
+  quindi quello che abbiamo scritto non è detto sia quello che vale;
 - le funzioni pure di calcolo sono separate dagli hook (es. `palloni-core.ts` vs
   `palloni.ts`, `mediePagelle()` vs `usePagelle()`);
 - `src/lib/rosa.ts` è l'aggregatore: compone tutti gli hook e restituisce la rosa completa
@@ -107,6 +108,7 @@ lanciato, così swipe come quello del calendario atterrano dove il gesto stava a
 npm run dev       # vite dev su http://localhost:8080
 npm run build     # build di produzione (nitro)
 npm run lint      # eslint (include prettier come regola)
+npm run typecheck # controllo dei tipi TypeScript (tsc, senza generare file)
 npm run format    # prettier --write .
 npm run test      # test unit (veloci, senza rete né database)
 npm run test:integration  # route server vere

docs/CHANGELOG.md

@@ -1,209 +1,174 @@
 # Changelog
 
-Tutte le modifiche significative del progetto vengono registrate in questo documento, in
-ordine dalla più recente. L'elenco delle funzionalità disponibili e previste non si ripete
-qui: sta in [ROADMAP.md](ROADMAP.md).
+Le modifiche rilevanti di CrAPP sono documentate qui, in ordine di rilascio. Il formato
+segue [Keep a Changelog](https://keepachangelog.com/it/1.1.0/): ogni versione ha una data
+e le voci sono divise per categoria (Aggiunto, Modificato, Sicurezza...). L'elenco
+completo delle funzionalità, fatte e previste, sta in [ROADMAP.md](ROADMAP.md); qui si
+registra solo _quando_ una voce è stata rilasciata e con quale versione.
 
-## Versione attuale — agosto 2026
+Le versioni sono sempre a tre cifre (`x.y.z`, mai `x.y`). Dalla `1.0.0` si segue il
+[versionamento semantico](https://semver.org/lang/it/): `x` cresce con i cambi non
+compatibili all'indietro, `y` con le funzionalità nuove, `z` con le sole correzioni. Le
+versioni `0.y.z` erano pre-release.
 
-### Le notifiche push arrivano anche ad app chiusa
+## [Non rilasciato]
 
-- Il testo della notifica viaggia ora cifrato **dentro** la push (`aes128gcm`, RFC 8291)
-  invece di essere recuperato dal service worker con una fetch al risveglio: era quella fetch
-  a non arrivare mai in tempo a telefono bloccato, e la notifica non compariva affatto
-  (DD-026).
-- Spariscono la route `/api/public/push-messaggio`, la coda `promemoria_push` e
-  `messaggioPalloniOggi()`: esistevano solo per rimediare al payload vuoto.
+## [1.1.1] - 2026-09-28
 
-### Lo Scout Live si apre dalla pagina della partita
+### Aggiunto
 
-- Tolto dalla home, era rimasto senza nessun link: `/scout` si raggiungeva solo scrivendo
-  l'URL. Ora la card `ScoutEntry` sta in `/partita/$id`, sezione «Scout live».
-- Si accende solo se la partita aperta è quella di oggi (nuova prop `eventoId`), altrimenti
-  resta grigia con «Si attiva il giorno della partita». Lock di sessione invariato.
-- Non è più riservato agli admin: può scoutare chiunque sia autenticato, uno per volta grazie
-  al lock. Sparisce il messaggio «Scout riservato».
+- **Keepalive giornaliero** — un Vercel Cron Job chiama `/api/public/keepalive` una volta
+  al giorno con una lettura minima, per evitare che il progetto Supabase free tier vada in
+  pausa dopo 7 giorni senza richieste API.
+- **Scheda evento** — gli eventi extra-campo (es. cena di squadra) hanno ora una pagina di
+  dettaglio propria, come allenamenti e partite, con l'elenco nominativo di chi ha risposto
+  presente/assente/forse invece del solo conteggio in card. "Infortunato" non compare più
+  tra le opzioni né nei badge/riepiloghi per questi eventi, dato che non è una risposta
+  pertinente.
 
-### Il sondaggio pre-partita apre alle 8:00 del giorno della partita
+### Modificato
 
-- Prima era sempre votabile, anche settimane prima: ora la card resta chiusa con l'avviso di
-  apertura e si sblocca alle 8:00 del giorno stesso.
-- Quando è aperto, gli amministratori hanno nella card il pulsante «Avvisa tutti del
-  sondaggio» (`POST /api/public/apri-sondaggio`), che manda la push a tutti i dispositivi
-  iscritti — stesso meccanismo del sollecito presenze. Nessun cron: l'invio è manuale.
+- **Backup completo** — la cifratura (gpg, `tar.gz.gpg`) è ora il comportamento di default
+  invece che opt-in con `--encrypt`, dato che i dump contengono dati sensibili (hash
+  password, documenti d'identità); si disattiva con `--no-encrypt`. Aggiunte le istruzioni
+  di decompressione nel README.
 
-### Le note dell'evento si leggono aprendolo
+### Corretto
 
-- Il campo Note del form eventi si poteva scrivere ma non lo vedeva nessuno: ora compare
-  nella scheda di `/allenamento/$id` e `/partita/$id`, sotto orario e luogo, con gli a capo
-  mantenuti. Se è vuoto non compare niente.
+- **Squadra** — la card dell'allenatore nella Rosa è collassata come quella dei giocatori
+  (nome e ruolo in riga chiusa, data di nascita solo aprendo il dettaglio) invece di
+  mostrare subito tutto.
+- **Squadra** — uno scroll verticale veloce nella tab Stats non fa più scattare per errore
+  il cambio tab verso Obiettivi.
+- **Turno palloni** — gli eventi generici (es. cena di squadra) non entrano più nel turno
+  palloni: niente più proposta automatica, promemoria push o conteggio per eventi che non
+  sono allenamenti o partite.
 
-### Form eventi: data e ora non sfondano più la card su iOS
+## [1.1.0] - 2026-09-27
 
-- Lo stesso difetto già corretto sul tesseramento: `Campo` e le classi degli input erano
-  ricopiati identici in tre file, quindi il `min-w-0` aggiunto in `ProfiloAmministrativo`
-  non arrivava né al form «Nuovo evento» né alla dashboard admin. Ora `Campo` e
-  `classiInput` stanno una volta sola in `ui-bits`.
-- La regola CSS che rende ridimensionabili i controlli nativi copre anche
-  `input[type="time"]`, che nel form eventi sta affiancato alla data in `grid-cols-2`.
+### Aggiunto
 
-### Profilo: tab Documenti e Opzioni, barra senza scroll
+- **Avviso certificati in scadenza** — in Home, giallo nei 7 giorni prima e nero dopo la
+  scadenza del certificato medico. Gli admin vedono i nomi di tutta la rosa (non
+  cliccabile); il giocatore interessato vede solo il proprio e il tap apre
+  `/profilo?tab=documenti`. Calcolato al volo da `certificato_scadenza`: nessuna migration,
+  nessuna push (DD-035).
 
-- L'etichetta nominava lo scopo (il tesseramento CSI) invece del contenuto: dentro ci sono
-  dati personali, documento, certificato medico e foto tessera. Cambia anche la rotta
-  (`/profilo?tab=documenti`): i vecchi link `?tab=tesseramento` aprono la tab Stagione.
-- «Impostazioni» diventa «Opzioni»: con le quattro etichette accorciate la barra delle
-  sottosezioni ci sta in uno schermo da telefono. Le voci ora si dividono la riga in parti
-  uguali (`grow basis-0`) e tornano a scorrere solo se non ci stanno, quindi vale anche per
-  le barre di Squadra e Classifica.
+## [1.0.0] - 2026-09-24
 
-### Palloni: allenamenti senza proposta automatica
+Prima versione stabile. Oltre al ruolo allenatore riunisce il lavoro fatto dalla 0.9.2:
+centro notifiche in-app, messaggi dell'admin e la nuova Gestione eventi a calendario.
 
-- `completaTurni` non assegna più gli allenamenti: restano «da assegnare» finché non si
-  sceglie a mano. Le partite tengono la rotazione. Migration M10 cancella eventuali turni
-  salvati su allenamenti da oggi in poi.
+### Aggiunto
 
-### Profilo: etichetta notifiche allineata al comportamento
+- **Ruolo allenatore** — l'admin registra un allenatore da `/admin` (tipo «Allenatore», con
+  l'email Gmail) e lui si collega al primo accesso come i giocatori. Gestisce gli eventi e
+  sollecita le presenze; ha un profilo ridotto (dati personali e foto, senza stagione e
+  badge), compare in Squadra con la dicitura «Allenatore» e non vede badge né cacche.
+  Migration `m20_ruolo_allenatore_enum` e `m21_ruolo_allenatore` (DD-034).
+- **Centro notifiche in-app** — lo storico delle notifiche dentro l'app, indipendente dalla
+  push: messaggi dell'admin, promemoria automatici 24 ore e 3 ore prima di un evento, turno
+  palloni e sollecito presenze. Ogni notifica si toglie con uno swipe o con la ×. Migration
+  `m17_notifiche_utente` (DD-030).
+- **Messaggi dell'admin** — dalla tab Notifiche della dashboard l'admin manda un messaggio
+  libero a tutta la squadra o a un solo giocatore; la tab elenca anche chi non ha le
+  notifiche attive.
+- **Gestione eventi a calendario** — `/eventi` è una griglia mensile: si tocca un giorno per
+  vederne gli eventi e crearne, modificarne o eliminarne uno. Prima di salvare la modifica
+  di un evento esistente compare una conferma, come per l'eliminazione.
+- **Backup completo** — uno script scarica schema e dati del database e i file dello
+  storage, per poter ripartire se si perde Supabase o Vercel (vedi `PORTABILITA.md`).
 
-- L’interruttore in Impostazioni non è più «Notifiche turno palloni»: iscrive il dispositivo
-  a tutte le push (palloni, solleciti) e alle smart in app. Testo e docs aggiornati.
-- Il widget Home «Completa il tuo profilo» apre direttamente la tab Tesseramento
-  (`/profilo?tab=tesseramento`).
+### Modificato
 
-### Revisione dell'interfaccia: accessibilità, movimento, peso
+- **Notifiche in-app** — il numero delle non lette è un pallino rosso sull'avatar del
+  profilo, al posto della campanella in alto a destra. Toccando il pallino si apre l'elenco
+  (leggi ed elimina), toccando l'avatar si va al profilo come prima.
+- **Campionato** — l'header riporta la stagione delle gare CSI (es. «Stagione 2025/26») e lo
+  storico partite è diviso per stagione.
+- **Gestione eventi** — tolta la lista "Eventi in calendario": resta solo il calendario
+  mensile, che si scorre anche con lo swipe come quello della squadra.
+- **Gestione eventi** — nel form il giorno toccato sul calendario è già fissato: resta da
+  scegliere solo l'ora («Cambia» per spostare l'evento in un altro giorno). Il campo
+  «Luogo» di un nuovo evento parte vuoto invece che con «Palestra Comunale».
 
-- **Contrasto**: `--success`, `--info` e `--training` erano tra 3.3:1 e 3.5:1 con il testo
-  bianco sopra (chip «Presente», «Allenamento», celle del calendario): ora sono sotto la
-  soglia di luminosità che garantisce 4.5:1. I gradi dei badge usavano `text-oro` e
-  `text-argento` su bianco, cioè 1.9:1 e 2.5:1 — praticamente invisibili: nascono i token
-  `--oro-testo`, `--argento-testo`, `--bronzo-testo` per il testo, mentre le versioni chiare
-  restano su sfondi e bordi.
-- **PWA**: mancava `viewport-fit=cover`, quindi `env(safe-area-inset-bottom)` valeva sempre 0
-  e su iPhone la BottomNav finiva sotto la home bar. `theme-color` e `background_color` erano
-  `#111111` su un'app chiara: barra di stato nera e splash nero prima di una UI bianca.
-- **`lang="it"`** al posto di `lang="en"`, su un'app interamente in italiano; 404 e schermata
-  d'errore tradotte; anteprima social ripulita dall'immagine Lovable scaduta e da
-  `twitter:site` che puntava a `@Lovable`.
-- **Tocco e tastiera**: nessun `:focus-visible` era definito (ora c'è una regola globale);
-  chip presenza, filtri e bottoni icona portati a 44px; `aria-current` sulla navigazione,
-  `aria-pressed` sui controlli a stato, `aria-controls` sulle sezioni a tendina, `aria-busy`
-  sui caricamenti. Il testo sotto i 12px è sparito (108 occorrenze).
-- **Movimento** (DD-021): molle interrompibili di `motion` al posto delle `@keyframes` a
-  durata fissa. `Reveal` compare quando entra davvero nel viewport (prima consumava
-  l'animazione a vuoto sotto la piega); `Barra` anima `scaleX` invece di `width`; `Numero`
-  cambia rotta se il dato cambia a metà conteggio. Il calendario si cambia mese anche con lo
-  swipe, con il punto d'arrivo scelto proiettando la velocità di rilascio.
-- **Meno dipendenze** (DD-021): rimossi 43 componenti `src/components/ui/` non importati da
-  nessuna parte e ~45 dipendenze (tutti i `@radix-ui/*`, `recharts`, `react-hook-form`,
-  `date-fns`, `embla`, `cmdk`; `zod` resta perché lo usano le route API). Restano `drawer` e
-  `sonner`. Il bundle **non** cala per questo — quel codice era già escluso dal
-  tree-shaking — ma cala la superficie da aggiornare e da controllare: 50 dipendenze dirette
-  diventano 21. Il bundle client cresce di ~42 KB gzip per `motion` (267 → 308 KB).
-- **Primitiva `Card`**: `rounded-3xl bg-card p-4 shadow-card` era ricopiato a mano 22 volte.
-- **Tema scuro rimosso** (DD-022): esisteva un blocco `.dark` mai applicato e incoerente.
-- Tolte le quattro switch di notifica in `/profilo` che erano `defaultChecked` e non facevano
-  niente, e la conferma nativa prima di _cambiare_ la foto profilo (resta su quella che la
-  rimuove, che è irreversibile).
-- Le celle del calendario con più tipi di evento non usano più un gradiente a fette con
-  un'ombra bianca sul numero per restare leggibili: fondo neutro e un puntino per tipo.
+### Corretto
 
-### Serie di presenze calcolate sui dati reali
+- **Squadra** — la data di nascita inserita dal proprio Profilo compare a tutta la squadra
+  (e nei compleanni del Calendario) invece di «Invalid Date»; allineati anche i profili
+  compilati prima della correzione. Migration `m18_nascita_pubblica_giocatori_squadra` e
+  `m19_backfill_nascita_da_profili_esistenti` (DD-031).
+- **Squadra** — la rosa non si ricalcola più a ogni render mentre i voti MVP si caricano.
 
-- `serieConsecutiva()` (`src/lib/presenze.ts`) deriva le serie da eventi passati e
-  `risposte_presenze`: prima erano `0` fisso in `useRosa()` e la sezione «Serie di presenze»
-  del profilo era di fatto inerte, insieme ai badge e all'obiettivo «Continuità di squadra»
-  che ne dipendono.
-- Migration `m9_risposte_presenze_risposto_il`: nuova colonna `risposto_il` con l'istante
-  della **prima** risposta, resa immutabile da un trigger (`aggiornato_il` registrava solo
-  l'ultima modifica, quindi chi rispondeva subito e cambiava idea dopo risultava lento).
-  Confrontata con `eventi_app.creato_il` sblocca finalmente la serie "Conferme 24h" e i badge
-  "Risposta lampo" e "Mai un forfait". Il dato non è ricostruibile all'indietro: vale da qui
-  in avanti (vedi [modules/serie-presenze.md](modules/serie-presenze.md)).
-- La barra di progresso di una serie ora misura l'avanzamento fra il traguardo raggiunto e il
-  successivo: prima usava `valore/prossimo` e tornava indietro a ogni traguardo (2/3 = 67%,
-  poi 3/6 = 50%).
+## [0.9.2] - 2026-09-10
 
-### Segnalazioni dal profilo
+### Aggiunto
 
-- «Segnala un bug» e «Suggerisci una nuova funzionalità» in `/profilo` → Impostazioni: due
-  link che aprono una issue GitHub sul template giusto
-  (`.github/ISSUE_TEMPLATE/bug_report.yml`, `feature_request.yml`). Nessuna tabella e nessuna
-  schermata di gestione: la segnalazione vive su GitHub
-  (vedi [modules/profilo-giocatore.md](modules/profilo-giocatore.md)).
+- **Dashboard amministratore** — nuova tab "Notifiche" che mostra quanti giocatori hanno
+  le notifiche push attive e chi sono.
 
-### Autenticazione e dashboard amministratore (in produzione)
+### Modificato
 
-- 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).
-- La selezione libera del giocatore è stata rimossa: `/benvenuto` offre solo l'accesso con
-  Google e senza sessione non si entra in nessuna schermata. Sparita anche la variabile
-  `VITE_AUTH_OBBLIGATORIA` (non serve più) e il pulsante «Cambia giocatore» in `/profilo`.
-- I permessi di amministrazione arrivano solo da `user_roles` (`src/lib/ruoli.ts`): la lista
-  di nomi in `crapp-data.ts` è stata eliminata, altrimenti bastava scegliere il nome giusto
-  per amministrare.
-- Migration `m4_solo_autenticati`: toglie al ruolo `anon` l'accesso alle tabelle v1.0.
-  Applicata in produzione il 03/09/2026, dopo aver impostato l'email di tutta la rosa
-  attiva — il login era già l'unica via d'accesso lato app, quindi il collegamento dei
-  singoli account (che resta un processo continuo a ogni login) non era comunque
-  condizionato da questa migration.
-- Collegamento automatico al proprio giocatore per email (DD-018, migration
-  `m5_email_giocatori_squadra`): niente più scelta manuale da un elenco, `/benvenuto`
-  confronta l'email dell'account Google con `giocatori_squadra.email` e collega da solo.
-  Senza corrispondenza compare solo un messaggio d'errore, con un pulsante per uscire e
-  riprovare con un altro account.
-- Dashboard admin: nuove azioni "Aggiungi giocatore" (con email opzionale per il
-  collegamento automatico) e "Disattiva/Riattiva giocatore" per chi lascia la squadra — la
-  riga non viene mai eliminata, così presenze, voti, pagelle e badge della stagione restano
-  agganciati al suo id. L'email è anche modificabile dal pannello "Dati squadra" di ogni
-  giocatore già in rosa.
-- Tracciamento tesseramento CSI (migration `m8_tesseramento_csi`): numero e data di tessera
-  in `giocatori_squadra`, come gli altri campi che gestisce solo l'admin (DD-016/DD-018). La
-  dashboard mostra chi è già tesserato (badge sulla scheda, contatore in "Squadra") e un
-  pannello per registrare numero e data una volta arrivata la tessera dal CSI.
-- Profilo giocatore: da `/profilo` ognuno compila i propri dati anagrafici e carica
-  documento, certificato medico e foto tessera con le relative scadenze
-  ([modules/profilo-giocatore.md](modules/profilo-giocatore.md)).
-- 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 bucket privato), additiva.
-- Dalla dashboard l'amministratore modifica i dati squadra (nome, cognome, numero, ruolo),
-  compila i dati personali al posto di un giocatore e scollega un account da un profilo
-  (DD-017). I file restano esclusi: li carica solo il giocatore. Nessuna migration: le
-  policy di M1 e M2 lo consentivano già.
-- Foto profilo sincronizzate tra dispositivi: da `/profilo` la foto caricata finisce nel
-  bucket pubblico `avatar-giocatori` (migration `m6_avatar_giocatori`) invece che in
-  `localStorage`, così compare per tutta la squadra e non solo su chi l'ha caricata.
-  L'Avatar mostra numero/iniziali finché la foto non è presente.
-- Scout Live sincronizzato tra dispositivi: il blocco "chi sta scoutando" ora passa dalla
-  tabella `scout_sessioni` invece che da `localStorage`, quindi due telefoni non possono più
-  prendere il controllo insieme sovrascrivendosi a vicenda. Le partite scoutate concluse
-  vengono archiviate nella nuova tabella `scout_partite` (migration `m7_scout_partite`):
-  prima restavano visibili solo sul telefono di chi aveva chiuso la partita.
+- **Dashboard amministratore** — le sezioni impilate diventano un menu di tab scorrevole a
+  pillole (come Squadra e Campionato); nell'elenco Profili resta aperta una sola scheda
+  alla volta.
+- **Profilo** — testi dei campi amministrativi semplificati (label email, rimossa la nota
+  su chi vede quei dati).
 
-### Test
+### Rimosso
 
-- Suite di test in `test/` (unit, integration, end-to-end) eseguita con bun,
-  senza nuove dipendenze: `npm run test` e `npm run test:all`.
-- Corretto un difetto emerso dai test: una sessione Scout Live con timestamp
-  illeggibile restava bloccata per sempre invece di scadere.
+- Le dipendenze e il codice legati all'editor Lovable (login social e reporting errori
+  verso l'editor): l'app non ci gira più.
 
-### Collegamento CSI
+## [0.9.1] - 2026-09-10
 
-- Classifica e risultati ufficiali letti dal portale Livescore CSI Bologna
-  (stagione 2025/26, Campionato Open Misto Eccellenza, Girone B).
-- La pagina Campionato non usa più dati dimostrativi.
-- Dettagli e limiti in [modules/collegamento-csi.md](modules/collegamento-csi.md).
+### Modificato
 
-### Infrastruttura
+- **Storico partite** — ogni scheda mostra il logo accanto al nome di entrambe le squadre
+  (CRAP e avversario), risultato e parziali in ordine casa–ospite (verde/rosso restano
+  vittoria/sconfitta CRAP) e un chevron a destra per chiarire che la riga apre il dettaglio.
 
-- Migrazione completa da Lovable a sviluppo locale.
-- Configurazione Git.
-- Repository GitHub indipendente.
-- Deploy automatico tramite Vercel.
-- Branch main e develop.
+## [0.9.0] - 2026-09-09
 
-## Versione 1.0 — luglio 2026
+Prima versione pre-release: lo sviluppo precedente non era versionato a parte, quindi
+questa release riunisce tutto ciò che l'app fa oggi in produzione.
 
-Prima versione usata dalla squadra. Funzionalità incluse: vedi
-[ROADMAP.md § Versione 1.0](ROADMAP.md#versione-10--rilasciata).
+### Aggiunto
+
+- **Gestione squadra** — rosa dei giocatori con ruoli e dati anagrafici di base.
+- **Profilo Giocatore** — dati personali e amministrativi, documento d'identità,
+  certificato medico (caricamento, scadenza, stato, download) e foto tessera in
+  un'unica schermata, sia lato giocatore sia lato amministratore; lo storico dei
+  certificati resta un'estensione futura.
+- **Gestione tesseramenti CSI** — raccolta dei dati richiesti dal CSI, tracciamento di chi
+  è già tesserato (numero e data tessera) ed export CSV per il tesseramento.
+- **Calendario** — eventi di allenamento e partita, con schermata di dettaglio dedicata.
+- **Presenze** — conferma o rifiuto della partecipazione a un evento, visibile a tutta la
+  squadra al posto di chat e fogli condivisi.
+- **Serie di presenze** — tre serie (presenze, conferme, allenamenti) calcolate sui dati
+  reali della rosa.
+- **Scout Live** — un solo referente alla volta registra in tempo reale le azioni di gioco
+  durante la partita.
+- **Badge** — gamification con gradi bronzo/argento/oro, badge segreti e badge social
+  votati tra compagni.
+- **Pagelle** — voto tra compagni (1-10) a fine partita, con media personale e di squadra.
+- **Votazione MVP** — elezione del migliore in campo della partita tramite voto tra
+  compagni, un voto a testa.
+- **Obiettivi di squadra** — traguardi collettivi che avanzano con presenze, risposte alle
+  convocazioni, pagelle e risultati di campionato.
+- **Turno palloni** — rotazione condivisa e promemoria di chi porta e riporta i palloni ad
+  allenamenti e partite.
+- **Notifiche push** — promemoria intelligenti su un unico opt-in per dispositivo.
+- **Dashboard amministratore** — vista aggregata su tesseramenti, certificati, presenze e
+  dati della rosa, con download CSV.
+- **Collegamento CSI** — classifica di campionato e Coppa, storico partite e dettaglio di
+  ogni gara (formazioni, storico scontri diretti, probabilità di vittoria calcolata dal
+  CSI) letti in tempo reale dal portale ufficiale Livescore CSI Bologna, senza inserimento
+  manuale da parte degli amministratori.
+- **Infortuni** — conteggio degli eventi saltati per infortunio, riusando lo stato di
+  presenza già registrato per le convocazioni.
+
+### Sicurezza
+
+- Autenticazione tramite Google via Supabase Auth, unico metodo di accesso; permessi
+  differenziati per ruolo (giocatore/amministratore) su tabelle e route.

docs/DATABASE.md

@@ -7,31 +7,33 @@ non in questo file.
 
 ## Permessi di scrittura
 
-Chi può scrivere cosa, dopo la migration `m11_scritture_per_ruolo` (DD-023). La **lettura**
+Chi può scrivere cosa, dopo la migration `m11_scritture_per_ruolo` (DD-023) e il ruolo
+allenatore di `m21_ruolo_allenatore` (DD-034). La **lettura**
 resta aperta a tutti gli autenticati su ogni tabella di questo elenco; `anon` non arriva a
 nessuna di esse da M4 (DD-011).
 
-| Tabella                                                          | Chi può scrivere                                                    |
-| ---------------------------------------------------------------- | ------------------------------------------------------------------- |
-| `eventi_app`                                                     | solo admin (nell'app li gestisce la rotta `/eventi`, già riservata) |
-| `risposte_presenze`, `cacche_partita`                            | il giocatore sulla propria riga (`giocatore_id`), più gli admin     |
-| `pagelle_voti`, `mvp_voti`, `badge_social_voti`                  | il votante sui propri voti (`votante_id`), più gli admin            |
-| `turni_palloni`, `scout_sessioni`, `scout_live`, `scout_partite` | qualsiasi autenticato: nell'interfaccia non hanno gate              |
-| `profili_giocatore`                                              | il giocatore sul proprio profilo, admin su tutti (DD-016, DD-017)   |
-| `giocatori_squadra`                                              | admin; il giocatore può solo reclamare uno slot libero (DD-016)     |
-| `user_roles`                                                     | solo admin                                                          |
+| Tabella                                                          | Chi può scrivere                                                                                                                                                                                                               |
+| ---------------------------------------------------------------- | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------ |
+| `eventi_app`                                                     | admin e allenatori (nell'app li gestisce la rotta `/eventi`, riservata a loro)                                                                                                                                                 |
+| `risposte_presenze`, `cacche_partita`                            | il giocatore sulla propria riga (`giocatore_id`), mai l'allenatore (M21), più gli admin                                                                                                                                        |
+| `pagelle_voti`, `mvp_voti`, `badge_social_voti`                  | il votante sui propri voti (`votante_id`), se votante e votato sono convocati all'evento (`m13`) e nessuno dei due è un allenatore (`m21`); solo per le pagelle anche `pagelle_chiuse = false`; gli admin senza questi vincoli |
+| `turni_palloni`, `scout_sessioni`, `scout_live`, `scout_partite` | qualsiasi autenticato: nell'interfaccia non hanno gate                                                                                                                                                                         |
+| `notifiche_utente`                                               | nessuno scrive da client: le righe nascono da trigger/funzioni `SECURITY DEFINER` o dalla service role (M17); il giocatore può solo segnare come lette le proprie                                                              |
+| `profili_giocatore`                                              | il giocatore sul proprio profilo, admin su tutti (DD-016, DD-017)                                                                                                                                                              |
+| `giocatori_squadra`                                              | admin; il giocatore può solo reclamare uno slot libero (DD-016); l'allenatore anche cambiare nome e cognome del proprio slot (M21)                                                                                             |
+| `user_roles`                                                     | solo admin; la riga `allenatore` la scrive il trigger `sincronizza_ruolo_allenatore` (M21)                                                                                                                                     |
 
 L'identità del giocatore è lo slot di `giocatori_squadra` con `auth_user_id = auth.uid()`.
 La tabella è verificata da `test/integration/permessi.test.ts` contro il database locale.
 
 ## Anagrafica e utenti
 
-| Tabella             | Scopo                                                                                                                                                                                              | Note                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                           |
-| ------------------- | -------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | ---------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- |
-| `giocatori_squadra` | Anagrafica operativa della squadra, con ID testuali (`g1`…`gN`), dati gestiti dagli admin (nome, cognome, numero, ruolo), collegamento all'account (`auth_user_id`) ed email registrata (`email`). | Introdotta dalla migration `m1_giocatori_squadra`, source of truth della rosa (DD-015): `useRosa()` e gli altri punti che elencano i giocatori la leggono tramite `useGiocatoriSquadra()` (client) o `leggiGiocatoriSquadra()` (server), filtrando `attivo`. `src/lib/crapp-data.ts` resta solo come seed storico e fallback (`rosaFallback()`) quando il database non risponde, e come sorgente della data di nascita (non ancora una colonna di questa tabella). Vedi DD-015 e DD-016. La colonna `email` (migration `m5_email_giocatori_squadra`, impostabile anche da `/admin`) è la chiave del collegamento automatico account↔giocatore al primo accesso (DD-018): NULL finché non nota, oggi impostata per tutta la rosa attiva. Le colonne `numero_tessera`/`data_tessera` (migration `m8_tesseramento_csi`) tracciano chi è già tesserato al CSI; come `numero`/`ruolo` le scrive solo un admin, il trigger di M1/M5 le include tra i campi bloccati per chi reclama il proprio slot. |
-| `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`.                                                                   | 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).                                                                                                                                                 | 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).                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                  |
+| Tabella             | Scopo                                                                                                                                                                                              | Note                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                    |
+| ------------------- | -------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- |
+| `giocatori_squadra` | Anagrafica operativa della squadra, con ID testuali (`g1`…`gN`), dati gestiti dagli admin (nome, cognome, numero, ruolo), collegamento all'account (`auth_user_id`) ed email registrata (`email`). | Introdotta dalla migration `m1_giocatori_squadra`, source of truth della rosa (DD-015): `useRosa()` e gli altri punti che elencano i giocatori la leggono tramite `useGiocatoriSquadra()` (client) o `leggiGiocatoriSquadra()` (server), filtrando `attivo`. `src/lib/crapp-data.ts` resta solo come seed storico e fallback (`rosaFallback()`) quando il database non risponde. Vedi DD-015 e DD-016. La colonna `email` (migration `m5_email_giocatori_squadra`, impostabile anche da `/admin`) è la chiave del collegamento automatico account↔giocatore al primo accesso (DD-018): NULL finché non nota, oggi impostata per tutta la rosa attiva. Le colonne `numero_tessera`/`data_tessera` (migration `m8_tesseramento_csi`) tracciano chi è già tesserato al CSI; come `numero`/`ruolo` le scrive solo un admin, il trigger di M1/M5 le include tra i campi bloccati per chi reclama il proprio slot. La colonna `nascita` (migration `m18_nascita_pubblica_giocatori_squadra`, DD-031) è pubblica a tutta la rosa attiva (stessa policy di lettura delle altre colonne): non si scrive mai da qui, un trigger su `profili_giocatore` (`sincronizza_nascita_pubblica`) la tiene allineata a `data_nascita` — impostata, aggiornata o azzerata dallo stesso form Profilo che scrive quella colonna. Il trigger copre solo le scritture successive a M18: `m19_backfill_nascita_da_profili_esistenti` ha allineato una tantum anche chi aveva già compilato il profilo prima di quella migration. La colonna `tipo` (migration `m21_ruolo_allenatore`, DD-034) distingue `giocatore` da `allenatore`: l'allenatore ha uno slot per collegarsi e per i dati personali, ma è fuori dalla rosa di gioco (`inRosa()` nel codice), non ha numero di maglia (`numero` è NULL, ammesso solo per lui dal vincolo `giocatori_squadra_numero_giocatori`) e ha `ruolo` vuoto. `tipo` lo scrive solo un admin. |
+| `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`.                                                                   | 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).                                                                                                                                                 | 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). Il valore `allenatore` di `app_role` (migration `m20_ruolo_allenatore_enum`) non si inserisce a mano: lo aggiunge e lo toglie il trigger `sincronizza_ruolo_allenatore` quando uno slot con `tipo = 'allenatore'` viene collegato, scollegato, disattivato o cambia tipo (DD-034).                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                        |
 
 `giocatori_squadra` / `giocatori` sono usate da: Squadra, Profili, Presenze, Scout, Badge, Pagelle.
 
@@ -44,12 +46,12 @@ La tabella è verificata da `test/integration/permessi.test.ts` contro il databa
 
 ## Eventi e presenze
 
-| Tabella             | Scopo                                                            | Note                                                                                                                                                                                                                                                                                                                                                |
-| ------------------- | ---------------------------------------------------------------- | --------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- |
-| `eventi_app`        | Eventi gestionali utilizzati dall'app.                           | Modello in uso dal codice attuale.                                                                                                                                                                                                                                                                                                                  |
-| `risposte_presenze` | Risposte dei giocatori agli eventi.                              | Modello in uso dal codice attuale. `risposto_il` è l'istante della **prima** risposta (migration `m9_risposte_presenze_risposto_il`): confrontato con `eventi_app.creato_il` dà la serie "Conferme 24h". Un trigger lo rende immutabile, così un ripensamento non fa risultare rapida una risposta lenta — `aggiornato_il` resta l'ultima modifica. |
-| `eventi`            | Calendario generale: allenamenti, partite, eventi della squadra. | Modello "nuovo" con autenticazione e vincoli, non ancora adottato (DD-014).                                                                                                                                                                                                                                                                         |
-| `presenze`          | Presenze agli eventi.                                            | Come sopra (DD-014).                                                                                                                                                                                                                                                                                                                                |
+| Tabella             | Scopo                                                            | Note                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                       |
+| ------------------- | ---------------------------------------------------------------- | ---------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- |
+| `eventi_app`        | Eventi gestionali utilizzati dall'app.                           | Modello in uso dal codice attuale. Cancellare un evento pulisce a cascata, tramite trigger, tutte le tabelle collegate elencate in questa pagina (`risposte_presenze`, `cacche_partita`, `mvp_voti`, `pagelle_voti`, `badge_social_voti`, `turni_palloni`, `scout_sessioni`, `scout_live`, `scout_partite`) — migration `m14_pulizia_dati_evento_cancellato`, DD-029. Le righe orfane da cancellazioni precedenti sono state bonificate una tantum da `m15_bonifica_dati_evento_orfani`, senza toccare i vecchi voti MVP/pagelle/badge social legati a id Scout o CSI; la stessa logica resta richiamabile come funzione `bonifica_dati_evento_orfani()` (`m16_funzione_bonifica_dati_evento_orfani`, riservata al service role) se mai servisse di nuovo. |
+| `risposte_presenze` | Risposte dei giocatori agli eventi.                              | Modello in uso dal codice attuale. `risposto_il` è l'istante della **prima** risposta (migration `m9_risposte_presenze_risposto_il`): confrontato con `eventi_app.creato_il` dà la serie "Conferme 24h". Un trigger lo rende immutabile, così un ripensamento non fa risultare rapida una risposta lenta — `aggiornato_il` resta l'ultima modifica.                                                                                                                                                                                                                                                                                                                                                                                                        |
+| `eventi`            | Calendario generale: allenamenti, partite, eventi della squadra. | Modello "nuovo" con autenticazione e vincoli, non ancora adottato (DD-014).                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                |
+| `presenze`          | Presenze agli eventi.                                            | Come sopra (DD-014).                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                       |
 
 ## Scout
 
@@ -61,19 +63,20 @@ La tabella è verificata da `test/integration/permessi.test.ts` contro il databa
 
 ## Votazioni
 
-| Tabella             | Scopo                                | Note                     |
-| ------------------- | ------------------------------------ | ------------------------ |
-| `mvp_voti`          | Voti MVP assegnati a fine partita.   |                          |
-| `pagelle_voti`      | Voti anonimi assegnati ai giocatori. | Usati per il voto medio. |
-| `badge_social_voti` | Voti social per i badge.             |                          |
+| Tabella             | Scopo                                | Note                                                                                                                                                                                                            |
+| ------------------- | ------------------------------------ | --------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- |
+| `mvp_voti`          | Voti MVP assegnati a fine partita.   | Un voto per votante e partita; auto-voto rifiutato (`mvp_no_autovoto`, migration `m12_niente_autovoto`); votante e votato devono essere convocati all'evento (RLS, `m13_convocati_e_pagelle_chiuse`).           |
+| `pagelle_voti`      | Voti anonimi assegnati ai giocatori. | Usati per il voto medio. Voto 1-10 e auto-voto rifiutato dai vincoli originari della tabella; votante/votato convocati e `pagelle_chiuse = false` richiesti dalla RLS di `m13_convocati_e_pagelle_chiuse`.      |
+| `badge_social_voti` | Voti social per i badge.             | Un voto per categoria, votante e partita; auto-voto rifiutato (`badge_social_no_autovoto`, `m12_niente_autovoto`); votante e votato devono essere convocati all'evento (RLS, `m13_convocati_e_pagelle_chiuse`). |
 
 ## Turni e notifiche
 
-| Tabella              | Scopo                                         | Note                                                                                                                                                                           |
-| -------------------- | --------------------------------------------- | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------ |
-| `turni_palloni`      | Gestione dei turni palloni.                   | Solo turni **confermati**. Gli allenamenti non ricevono proposta automatica (vedi [palloni.md](modules/palloni.md)); M10 azzera i turni salvati su allenamenti da oggi in poi. |
-| `push_subscriptions` | Dispositivi registrati per le notifiche Push. |                                                                                                                                                                                |
-| `promemoria_push`    | Non più usata.                                | Serviva da coda del testo quando la push partiva vuota; dal payload cifrato non la scrive né la legge nessuno. Tabella ancora presente, da eliminare con una migrazione.       |
+| Tabella              | Scopo                                                                        | Note                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                            |
+| -------------------- | ---------------------------------------------------------------------------- | ----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- |
+| `turni_palloni`      | Gestione dei turni palloni.                                                  | Solo turni **confermati**. Gli allenamenti non ricevono proposta automatica (vedi [palloni.md](modules/palloni.md)); M10 azzera i turni salvati su allenamenti da oggi in poi.                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                  |
+| `push_subscriptions` | Dispositivi registrati per le notifiche Push.                                |                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                 |
+| `promemoria_push`    | Non più usata.                                                               | Serviva da coda del testo quando la push partiva vuota; dal payload cifrato non la scrive né la legge nessuno. Tabella ancora presente, da eliminare con una migrazione.                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                        |
+| `notifiche_utente`   | Centro notifiche in-app, con stato letto/non letto, sull'avatar del profilo. | Introdotta dalla migration `m17_notifiche_utente`. Quattro sorgenti, tutte in parallelo alla push esistente: messaggio libero dell'admin (`notifica-personalizzata.ts`), un promemoria automatico prima di un evento — 24h e 3h prima, due `cron.schedule` (estensione `pg_cron`, abilitata il 31/07/2026 ma usata per la prima volta qui) — il turno palloni (`promemoria-palloni.ts`) e il sollecito presenze (`sollecita-presenze.ts`), questi ultimi due avviati a mano da un admin (il sollecito anche da un allenatore, DD-034). Volutamente non c'è una notifica sulla sola creazione di un evento: conta l'avvicinarsi della data, non il momento in cui è stato messo in calendario. I destinatari di un evento seguono la stessa convenzione di `convocatiEvento()`/`evento_permette_voto()` (M13): `convocati` vuoto = tutta la rosa attiva. Gli allenatori attivi sono sempre tra i destinatari dei promemoria evento, convocati o no (`giocatori_destinatari_evento()` riscritta da M21, DD-034); il sollecito presenze (avviato da admin o allenatore) e il turno palloni non arrivano mai a loro. Letta/segnata come letta dal client con `useNotificheMie()`/`useSegnaLette()` (`src/lib/notifiche-utente.ts`), RLS-only, nessuna route API dedicata per queste due operazioni. |
 
 ## Funzioni speciali
 

docs/DESIGN_DECISIONS.md

@@ -16,32 +16,41 @@ Serve a rispondere a domande del tipo:
 
 **Accettate**
 
-| ID                                                                                | Titolo                                |
-| --------------------------------------------------------------------------------- | ------------------------------------- |
-| [DD-001](#dd-001--crapp-deve-restare-indipendente-da-lovable)                     | Indipendenza da Lovable               |
-| [DD-002](#dd-002--sviluppo-document-first)                                        | Sviluppo document-first               |
-| [DD-004](#dd-004--ogni-versione-aggiunge-non-riscrive)                            | Ogni versione aggiunge, non riscrive  |
-| [DD-005](#dd-005--mobile-first-pochi-click-pochi-schermi)                         | Mobile-first                          |
-| [DD-006](#dd-006--intelligenza-artificiale-solo-se-porta-beneficio-reale)         | AI solo se utile                      |
-| [DD-007](#dd-007--badge-calcolati-dallapp-non-salvati-nel-database)               | Badge calcolati, non in DB            |
-| [DD-008](#dd-008--gamification-equa-tra-ruoli)                                    | Gamification equa tra ruoli           |
-| [DD-009](#dd-009--tesseramento-csi-manuale-in-v11-integrazione-api-in-v20)        | CSI manuale v1.1, API v2.0            |
-| [DD-010](#dd-010--profilo-giocatore-niente-storico-certificati-in-v1)             | Niente storico certificati v1         |
-| [DD-011](#dd-011--autenticazione-reale-prima-del-profilo-amministrativo-completo) | Auth reale prima del profilo          |
-| [DD-012](#dd-012--non-migrare-gli-id-giocatore-in-v11)                            | Non migrare ID in v1.1                |
-| [DD-013](#dd-013--portabilità-lapp-non-deve-dipendere-da-servizi-esclusivi)       | Portabilità dello stack               |
-| [DD-015](#dd-015--rosa-anagrafica-da-codice-hardcoded-a-database)                 | Rosa da hardcoded a DB                |
-| [DD-016](#dd-016--schema-dati-profilo-giocatore-v11-f0)                           | Schema dati Profilo Giocatore v1.1    |
-| [DD-017](#dd-017--lamministratore-può-compilare-i-dati-al-posto-del-giocatore)    | L'admin scrive al posto del giocatore |
-| [DD-018](#dd-018--collegamento-automatico-giocatoreaccount-per-email)             | Collegamento automatico per email     |
-| [DD-019](#dd-019--il-branch-dei-commit-lo-decide-lutente)                         | Il branch lo decide l'utente          |
-| [DD-020](#dd-020--una-funzione-modificata-senza-test-non-è-finita)                | Test obbligatori e verdi              |
-| [DD-021](#dd-021--molle-interrompibili-al-posto-delle-animazioni-a-durata-fissa)  | Molle interrompibili con motion       |
-| [DD-022](#dd-022--lapp-è-solo-chiara)                                             | App solo chiara                       |
-| [DD-023](#dd-023--ogni-scrittura-è-limitata-a-chi-la-fa)                          | Scritture limitate per ruolo          |
-| [DD-024](#dd-024--le-route-che-avvisano-la-squadra-chiedono-le-credenziali)       | Route di notifica autenticate         |
-| [DD-025](#dd-025--il-promemoria-palloni-lo-manda-ladmin-per-un-evento)            | Promemoria palloni manuale            |
-| [DD-026](#dd-026--il-testo-della-notifica-viaggia-dentro-la-push)                 | Payload push cifrato                  |
+| ID                                                                                               | Titolo                                |
+| ------------------------------------------------------------------------------------------------ | ------------------------------------- |
+| [DD-001](#dd-001--crapp-deve-restare-indipendente-da-lovable)                                    | Indipendenza da Lovable               |
+| [DD-002](#dd-002--sviluppo-document-first)                                                       | Sviluppo document-first               |
+| [DD-004](#dd-004--ogni-versione-aggiunge-non-riscrive)                                           | Ogni versione aggiunge, non riscrive  |
+| [DD-005](#dd-005--mobile-first-pochi-click-pochi-schermi)                                        | Mobile-first                          |
+| [DD-006](#dd-006--intelligenza-artificiale-solo-se-porta-beneficio-reale)                        | AI solo se utile                      |
+| [DD-007](#dd-007--badge-calcolati-dallapp-non-salvati-nel-database)                              | Badge calcolati, non in DB            |
+| [DD-008](#dd-008--gamification-equa-tra-ruoli)                                                   | Gamification equa tra ruoli           |
+| [DD-009](#dd-009--tesseramento-csi-manuale-integrazione-api-in-una-fase-successiva)              | CSI manuale, poi integrazione API     |
+| [DD-010](#dd-010--profilo-giocatore-niente-storico-certificati)                                  | Niente storico certificati            |
+| [DD-011](#dd-011--autenticazione-reale-prima-del-profilo-amministrativo-completo)                | Auth reale prima del profilo          |
+| [DD-012](#dd-012--rimandare-la-migrazione-degli-id-giocatore)                                    | Rimandare la migrazione ID            |
+| [DD-013](#dd-013--portabilità-lapp-non-deve-dipendere-da-servizi-esclusivi)                      | Portabilità dello stack               |
+| [DD-015](#dd-015--rosa-anagrafica-da-codice-hardcoded-a-database)                                | Rosa da hardcoded a DB                |
+| [DD-016](#dd-016--schema-dati-profilo-giocatore-f0)                                              | Schema dati Profilo Giocatore         |
+| [DD-017](#dd-017--lamministratore-può-compilare-i-dati-al-posto-del-giocatore)                   | L'admin scrive al posto del giocatore |
+| [DD-018](#dd-018--collegamento-automatico-giocatoreaccount-per-email)                            | Collegamento automatico per email     |
+| [DD-019](#dd-019--il-branch-dei-commit-lo-decide-lutente)                                        | Il branch lo decide l'utente          |
+| [DD-020](#dd-020--una-funzione-modificata-senza-test-non-è-finita)                               | Test obbligatori e verdi              |
+| [DD-021](#dd-021--molle-interrompibili-al-posto-delle-animazioni-a-durata-fissa)                 | Molle interrompibili con motion       |
+| [DD-022](#dd-022--lapp-è-solo-chiara)                                                            | App solo chiara                       |
+| [DD-023](#dd-023--ogni-scrittura-è-limitata-a-chi-la-fa)                                         | Scritture limitate per ruolo          |
+| [DD-024](#dd-024--le-route-che-avvisano-la-squadra-chiedono-le-credenziali)                      | Route di notifica autenticate         |
+| [DD-025](#dd-025--il-promemoria-palloni-lo-manda-ladmin-per-un-evento)                           | Promemoria palloni manuale            |
+| [DD-026](#dd-026--il-testo-della-notifica-viaggia-dentro-la-push)                                | Payload push cifrato                  |
+| [DD-027](#dd-027--chi-vota-deve-essere-convocato-non-solo-autenticato-come-sé-stesso)            | Voto limitato ai convocati            |
+| [DD-028](#dd-028--soglia-minima-di-campione-per-media-voto-e-mvp-in-home)                        | Soglia minima Media voto e MVP        |
+| [DD-029](#dd-029--cancellare-un-evento-pulisce-a-cascata-i-dati-collegati)                       | Pulizia a cascata evento cancellato   |
+| [DD-030](#dd-030--centro-notifiche-in-app-storico-separato-dalla-push-letto-solo-con-rls)        | Centro notifiche in-app               |
+| [DD-031](#dd-031--data-di-nascita-pubblica-una-colonna-sincronizzata-non-una-seconda-rls-aperta) | Nascita pubblica sincronizzata        |
+| [DD-032](#dd-032--la-stagione-csi-si-ricava-dalle-date-delle-gare)                               | Stagione CSI dalle date delle gare    |
+| [DD-033](#dd-033--gestione-eventi-solo-calendario-giorno-fissato-dal-tocco)                      | Gestione eventi solo da calendario    |
+| [DD-034](#dd-034--lallenatore-è-uno-slot-della-squadra-con-tipo-diverso-non-un-giocatore)        | Ruolo allenatore                      |
+| [DD-035](#dd-035--avviso-certificati-calcolato-in-home-visibile-solo-al-titolare-e-agli-admin)   | Avviso certificati in Home            |
 
 **In valutazione**
 
@@ -141,7 +150,7 @@ Ogni nuova funzionalità significativa viene prima **progettata e documentata**
 **Conseguenze**
 
 - Rallenta leggermente l’avvio di nuove feature, ma riduce rework e discussioni infinite.
-- I moduli v1.0 vanno retro-documentati quando possibile.
+- I moduli preesistenti vanno retro-documentati quando possibile.
 - Nessuna feature non documentata entra in produzione.
 
 **Riesame**  
@@ -184,7 +193,7 @@ indietro. Vedi DD-019.
 **Stato:** Accettata
 
 **Contesto**  
-CrAPP v1.0 è già usata dalla squadra per presenze, calendario, scout, badge e notifiche. Rischiare regressioni su moduli funzionanti vanifica la fiducia degli utenti.
+CrAPP è già usata dalla squadra per presenze, calendario, scout, badge e notifiche. Rischiare regressioni su moduli funzionanti vanifica la fiducia degli utenti.
 
 **Decisione**  
 Le nuove versioni **introducono** funzionalità. Non si riscrive un modulo già operativo salvo richiesta esplicita e pianificata.
@@ -246,7 +255,7 @@ Usare l’AI solo quando riduce lavoro agli admin o migliora concretamente l’e
 
 **Conseguenze**
 
-- “AI Allenamenti” è in roadmap v1.2, non v1.1.
+- “AI Allenamenti” è tra le voci ancora da fare in roadmap.
 - Ogni proposta AI va valutata con la domanda: _chi risparmia tempo e quanto?_
 
 **Riesame**  
@@ -305,34 +314,34 @@ Se la squadra chiede esplicitamente classifiche tecniche per ruolo.
 
 ---
 
-### DD-009 — Tesseramento CSI manuale in v1.1, integrazione API in v2.0
+### DD-009 — Tesseramento CSI manuale, integrazione API in una fase successiva
 
 **Data:** agosto 2026  
 **Stato:** Accettata
 
 **Contesto**  
-La v1.1 deve aiutare gli admin a raccogliere documenti e dati per il tesseramento CSI. Un collegamento automatico al sistema CSI è complesso e non urgente.
+Il modulo Profilo Giocatore deve aiutare gli admin a raccogliere documenti e dati per il tesseramento CSI. Un collegamento automatico al sistema CSI è complesso e non urgente.
 
 **Decisione**
 
-- **v1.1:** profilo completo, dashboard admin, download documenti, export CSV con i campi richiesti dal CSI.
-- **v2.0:** eventuale collegamento automatico a CSI (calendario, risultati, classifica ufficiale).
+- **Prima fase:** profilo completo, dashboard admin, download documenti, export CSV con i campi richiesti dal CSI.
+- **Fase successiva:** eventuale collegamento automatico a CSI (calendario, risultati, classifica ufficiale).
 
 **Alternative scartate**
 
-- Integrazione CSI già in v1.1 → scope troppo ampio, dipendenza da API esterne non controllate.
+- Integrazione CSI già nella prima fase → scope troppo ampio, dipendenza da API esterne non controllate.
 
 **Conseguenze**
 
 - Gli admin guadagnano subito tempo (niente più Excel e chat per i documenti).
-- L’export CSV deve essere affidabile e completo: è il deliverable chiave della v1.1.
+- L’export CSV deve essere affidabile e completo: è il deliverable chiave di questa prima fase.
 
 **Riesame**  
 Quando il CSI mette a disposizione API stabili o quando il volume di tesseramenti giustifica l’automazione.
 
 ---
 
-### DD-010 — Profilo giocatore: niente storico certificati in v1
+### DD-010 — Profilo giocatore: niente storico certificati
 
 **Data:** agosto 2026  
 **Stato:** Accettata
@@ -341,7 +350,7 @@ Quando il CSI mette a disposizione API stabili o quando il volume di tesserament
 Il certificato medico va aggiornato ogni stagione. Tenere lo storico di tutte le versioni complica upload, storage e privacy.
 
 **Decisione**  
-In v1 il giocatore può **sovrascrivere** certificato e data di scadenza. Lo storico delle versioni precedenti non viene conservato.
+Il giocatore può **sovrascrivere** certificato e data di scadenza. Lo storico delle versioni precedenti non viene conservato.
 
 **Alternative scartate**
 
@@ -367,7 +376,7 @@ Se il CSI o il regolamento interno richiedono conservazione storica.
 Oggi l’app identifica l’utente con la selezione del giocatore da una lista, senza login. Documenti, certificati e dati personali richiedono sapere _chi_ sta operando e impedire accessi non autorizzati.
 
 **Decisione**  
-Prima di completare il modulo Profilo Giocatore (v1.1), introdurre **login con Google o email** tramite Supabase Auth — non tramite Lovable Auth. Dopo il login, il giocatore associa il proprio profilo squadra.
+Prima di completare il modulo Profilo Giocatore, introdurre **login con Google o email** tramite Supabase Auth — non tramite Lovable Auth. Dopo il login, il giocatore associa il proprio profilo squadra.
 
 **Alternative scartate**
 
@@ -385,7 +394,7 @@ Dopo il rollout auth, se emergono problemi di adozione (giocatori poco digitali)
 
 ---
 
-### DD-012 — Non migrare gli ID giocatore in v1.1
+### DD-012 — Rimandare la migrazione degli ID giocatore
 
 **Data:** agosto 2026  
 **Stato:** Accettata
@@ -394,11 +403,11 @@ Dopo il rollout auth, se emergono problemi di adozione (giocatori poco digitali)
 L’app usa identificativi semplici (`g1`, `g2`, …) collegati a presenze, voti, palloni e altre funzioni già in uso. Nel database esiste anche una tabella `giocatori` con UUID, non collegata al codice attuale.
 
 **Decisione**  
-Per la v1.1 **non** unificare gli ID. I nuovi dati del profilo si agganciano agli identificativi già in uso. La migrazione verso UUID resta un lavoro separato, pianificato e testato.
+Per ora **non** unificare gli ID. I nuovi dati del profilo si agganciano agli identificativi già in uso. La migrazione verso UUID resta un lavoro separato, pianificato e testato.
 
 **Alternative scartate**
 
-- Migrare tutto a UUID in v1.1 → rischio alto di rompere presenze, voti, scout e notifiche.
+- Migrare subito tutto a UUID → rischio alto di rompere presenze, voti, scout e notifiche.
 
 **Conseguenze**
 
@@ -406,7 +415,7 @@ Per la v1.1 **non** unificare gli ID. I nuovi dati del profilo si agganciano agl
 - `DATABASE.md` va tenuto aggiornato su cosa è “attivo” e cosa è “futuro”.
 
 **Riesame**  
-Quando la v1.1 è stabile e c’è tempo per una migration con checklist regressioni completa.
+Quando il modulo Profilo Giocatore è stabile e c’è tempo per una migration con checklist regressioni completa.
 
 ---
 
@@ -435,16 +444,16 @@ Se si adotta un servizio che viola questa regola.
 
 ---
 
-### DD-016 — Schema dati Profilo Giocatore v1.1 (F0)
+### DD-016 — Schema dati Profilo Giocatore (F0)
 
 **Data:** agosto 2026  
 **Stato:** Accettata
 
 **Contesto**  
-La progettazione F0 del modulo Profilo Giocatore ha definito come persistere dati personali, documenti e certificati, in coesistenza con l’anagrafica attuale (`g1`…`g17` nel codice) e con la tabella `giocatori` UUID già presente ma non usata. Serviva una scelta chiara su dove salvare i dati, come collegare l’autenticazione e come proteggere documenti sensibili — senza toccare le tabelle v1.0 già operative.
+La progettazione F0 del modulo Profilo Giocatore ha definito come persistere dati personali, documenti e certificati, in coesistenza con l’anagrafica attuale (`g1`…`g17` nel codice) e con la tabella `giocatori` UUID già presente ma non usata. Serviva una scelta chiara su dove salvare i dati, come collegare l’autenticazione e come proteggere documenti sensibili — senza toccare le tabelle preesistenti già operative.
 
 **Decisione**  
-Per la v1.1 si introducono **due nuove tabelle additive**:
+Si introducono **due nuove tabelle additive**:
 
 - **`giocatori_squadra`** — anagrafica squadra con ID testuali (`g1`…`g17`), dati gestiti dagli admin (nome, cognome, numero, ruolo) e collegamento account (`auth_user_id`).
 - **`profili_giocatore`** — dati personali, metadati documento identità, certificato medico e path dei file, in relazione 1:1 con `giocatori_squadra`.
@@ -455,8 +464,8 @@ Regole vincolanti:
 2. L’associazione **`auth_user_id` ↔ giocatore** è un’operazione **controllata e atomica** (es. al primo accesso da `/benvenuto`, con `UPDATE … WHERE auth_user_id IS NULL`). Il giocatore **non può modificare liberamente** `auth_user_id`; solo un admin può resettarlo in casi eccezionali.
 3. I file (documento identità, certificato, foto tessera) vivono nel bucket Storage **`profili-giocatore`**, configurato come **privato**.
 4. Documenti personali e sanitari **non devono mai essere esposti tramite URL pubblici**. Accesso solo tramite client autenticato con policy RLS, o signed URL a scadenza breve per download admin.
-5. Le **tabelle v1.0 esistenti non vengono modificate** (`eventi_app`, `risposte_presenze`, voti, palloni, scout, push, ecc.). Il profilo si aggancia agli ID `g1`…`g17` già in uso, senza migrare verso UUID in v1.1 (coerente con DD-012).
-6. La tabella `giocatori` (UUID) resta **invariata e non usata** dal modulo profilo in v1.1.
+5. Le **tabelle preesistenti non vengono modificate** (`eventi_app`, `risposte_presenze`, voti, palloni, scout, push, ecc.). Il profilo si aggancia agli ID `g1`…`g17` già in uso, senza migrare verso UUID per ora (coerente con DD-012).
+6. La tabella `giocatori` (UUID) resta **invariata e non usata** dal modulo profilo.
 
 **Alternative scartate**
 
@@ -464,21 +473,21 @@ Regole vincolanti:
 - Salvare file come base64 nel database → ingestibile, difficile da gestire e da scaricare.
 - Bucket pubblico con URL permanenti → inaccettabile per dati sanitari e documenti d’identità.
 - Permettere al giocatore di cambiare `auth_user_id` liberamente → rischio di impersonazione e race condition.
-- Modificare tabelle v1.0 per aggiungere FK verso il profilo → viola DD-004 e DD-012.
+- Modificare le tabelle preesistenti per aggiungere FK verso il profilo → viola DD-004 e DD-012.
 
 **Conseguenze**
 
 - Coesistono temporaneamente tre rappresentazioni dell’anagrafica: `crapp-data.ts` (fallback), `giocatori_squadra` (target), `giocatori` UUID (dormiente).
 - `src/lib/rosa.ts` legge dal database e ricade su `crapp-data.ts` in caso di errore o assenza dati (DD-015).
 - Il completamento profilo (30/30/30/10) si calcola in app, non si persiste nel database.
-- Lo storico certificati non viene conservato in v1 (coerente con DD-010).
+- Lo storico certificati non viene conservato (coerente con DD-010).
 - Le migration M1–M2 (tabelle, RLS, bucket) restano **additive**: solo `CREATE`, nessun `ALTER`/`DROP` su schema esistente.
 - Raffina e attua quanto proposto in DD-015 per la rosa anagrafica, senza sostituire formalmente quella voce.
 
 **Riesame**
 
 - Quando `giocatori_squadra` è stabile in produzione e il fallback `crapp-data.ts` non serve più.
-- Quando si pianifica la convergenza verso UUID (DD-012, post v1.1).
+- Quando si pianifica la convergenza verso UUID (DD-012, dopo che il profilo sarà stabile).
 - Se il CSI o il regolamento richiedono conservazione storica documenti o consensi privacy dedicati.
 
 ---
@@ -570,7 +579,7 @@ Unificare gradualmente sul modello autenticato, dopo auth e profilo stabili.
 Rischio regressioni su calendario e presenze, moduli più usati della squadra.
 
 **Riesame previsto**  
-Post v1.1, con migration e test dedicati.
+Dopo che il modulo Profilo Giocatore sarà stabile, con migration e test dedicati.
 
 ---
 
@@ -759,7 +768,7 @@ spesso da rendere il tema scuro una funzione e non un vezzo.
 **Stato:** Accettata
 
 **Contesto**  
-Le tabelle della v1.0 sono nate con policy `USING (true)` per `anon, authenticated`. M4
+Le tabelle preesistenti sono nate con policy `USING (true)` per `anon, authenticated`. M4
 (DD-011) ha tolto il GRANT ad `anon`, e la cosa è stata letta come «ora è chiuso». Non lo
 era: per gli autenticati non c'era rimasto nessun limite. Verificato sul database locale con
 un utente appena creato, senza ruolo e senza slot nella rosa: `POST /rest/v1/eventi_app` →
@@ -887,7 +896,7 @@ come «da verificare lato hosting»: nei fatti quel promemoria non è mai partit
 funziona e che nessuno chiama.
 
 Nel frattempo l'app aveva già il precedente giusto: `apri-sondaggio` è manuale fin dall'inizio
-(«Nessun cron: l'invio è manuale», CHANGELOG v1.0.6).
+(«Nessun cron: l'invio è manuale», CHANGELOG).
 
 **Decisione**  
 Il promemoria lo fa partire un amministratore dal pulsante «Avvisa chi è di turno», dentro il
@@ -970,3 +979,534 @@ prima di inviare.
 **Riesame**  
 Se servisse mandare payload più grandi del limite del protocollo, o se un servizio push
 smettesse di accettare corpi cifrati (nessuno lo fa: è lo standard).
+
+### DD-027 — Chi vota deve essere convocato, non solo autenticato come sé stesso
+
+**Stato:** accettata · **Data:** 8 settembre 2026
+
+**Contesto**  
+Un audit del modulo Badge (`docs/modules/badge.md`) ha trovato due filtri rimasti solo
+applicativi dopo DD-023: la policy di M11 garantisce che `votante_id` sia lo slot collegato
+all'account di chi scrive, ma non controlla che **votante e votato fossero convocati**
+all'evento — un utente che scrive direttamente su PostgREST (bypassando l'interfaccia) poteva
+votare o essere votato in una partita a cui non aveva partecipato, gonfiando `mediaVoto`,
+`mvp` o un badge social a piacere. Allo stesso modo, `eventi_app.pagelle_chiuse` nascondeva
+solo i bottoni in UI: un voto pagella "fuori tempo" restava tecnicamente possibile.
+
+**Decisione**  
+La policy "Ognuno gestisce i propri voti ..." di `pagelle_voti`, `mvp_voti` e
+`badge_social_voti` (M11) guadagna un controllo aggiuntivo tramite la funzione
+`evento_permette_voto()` (migration `m13_convocati_e_pagelle_chiuse`): verifica che sia
+`votante_id` sia `votato_id` compaiano in `eventi_app.convocati` per quel `match_id`
+(`convocati` vuoto = tutta la rosa, la stessa convenzione di `convocatiEvento()` in
+`eventi.ts`), e — solo per le pagelle — che `pagelle_chiuse` sia falso. Le policy admin
+restano invariate e permissive: un amministratore deve poter correggere un voto anche fuori
+convocazione o dopo la chiusura.
+
+Il controllo si ferma alla **convocazione**, non alla **presenza reale**: per l'MVP, ad
+esempio, l'interfaccia limita già il voto ai soli presenti/in ritardo
+(`usePresenzeEvento`), un filtro più stretto che resta solo applicativo — un convocato ma
+assente passa ancora a livello database. Stringere fino a quel punto avrebbe richiesto
+leggere `risposte_presenze` dentro la policy, un salto di complessità non giustificato
+dall'audit che ha originato questa decisione.
+
+**Alternative scartate**
+
+- Un trigger `BEFORE INSERT/UPDATE` invece di RLS → si applicherebbe anche alla service key
+  e agli admin, bloccando correzioni legittime fuori convocazione; la RLS, applicata solo
+  alla policy non-admin, li esclude naturalmente.
+- Controllare anche la presenza reale (`risposte_presenze`), non solo la convocazione →
+  scope maggiore del gap trovato in audit, e specifico dell'MVP (pagelle e badge social non
+  hanno un concetto di "presente" distinto da "convocato" nell'interfaccia attuale).
+
+**Conseguenze**
+
+- Un evento senza `convocati` esplicito (lista vuota, il caso più comune oggi) non cambia
+  comportamento: tutta la rosa resta votabile, come prima.
+- I test di `test/integration/permessi.test.ts` sono la definizione eseguibile anche di
+  questa parte della tabella dei permessi (voti non convocati rifiutati, `pagelle_chiuse`
+  rifiutata a database, controlli positivi che provano che un voto legittimo passa ancora).
+- Resta un gap conosciuto e documentato (non quello risolto qui): che il votante fosse
+  davvero presente, non solo convocato, per MVP/pagelle/badge social.
+
+**Riesame**  
+Se un giorno servisse bloccare anche il voto di un convocato-ma-assente a livello database,
+non solo in UI.
+
+### DD-028 — Soglia minima di campione per Media voto e MVP in home
+
+**Data:** 9 settembre 2026  
+**Stato:** Accettata
+
+**Contesto**  
+Un audit della sezione «Colpo d'occhio» in home (`index.tsx`, StatTile Presenze/Media
+voto/MVP) ha trovato che due delle tre statistiche non avevano nessun minimo campionario:
+`mediePagelle()` calcola una media aritmetica pura, così un giocatore con un solo voto da 10
+mostrava "10" in home, più alto di un titolare con 40 voti e media 7.2 — lo stesso problema
+che il badge Pagellone già risolve con `VOTI_MINIMI_PAGELLA` (badge.md), ma applicato solo al
+badge, non alla StatTile home. Allo stesso modo `mvpVintiPerGiocatore()`/`vincitoriMvp()`
+assegnavano un MVP di partita anche con un solo voto totale: bastava che un solo giocatore
+votasse perché il votato "vincesse" nettamente, senza nessun quorum di partecipazione.
+
+**Decisione**
+
+- **Media voto** in home usa la stessa soglia del badge Pagellone: sotto `VOTI_MINIMI_PAGELLA`
+  (5) voti ricevuti, la StatTile mostra `—` invece della media, tramite la funzione pura
+  `mediaVotoColpoDOcchio()` (`pagelle.ts`), estratta dalla route per restare testabile (DD-020).
+  La funzione `mediePagelle()` non cambia: il filtro resta lato chiamante, come già faceva il
+  badge.
+- **MVP**: `conteggioPartita`'s aggregazione, tramite `vincitoriMvp()` e
+  `mvpVintiPerGiocatore()`, richiede ora un quorum minimo di voti totali sulla partita
+  (`VOTI_MINIMI_MVP = 2`, `mvp-voti.ts`) prima di assegnare un vincitore, oltre alla regola già
+  esistente del margine netto tra primo e secondo. Un solo voto non basta più a incoronare
+  nessuno, nemmeno in assenza di concorrenza.
+
+**Alternative scartate**
+
+- Alzare la soglia MVP oltre 2 (es. metà dei convocati) → serve conoscere i convocati
+  dell'evento dentro una funzione che oggi lavora solo sui voti; complessità non giustificata
+  per il gap trovato in audit.
+- Lasciare l'MVP senza quorum e limitarsi al fix della Media voto → il problema di fondo
+  (un numero esiguo di voti che decide una statistica mostrata come solida) resterebbe aperto
+  per l'MVP.
+
+**Conseguenze**
+
+- Alcuni MVP di partita già assegnati con un solo voto totale non contano più nel conteggio
+  `mvp` del giocatore: è una modifica retroattiva al dato mostrato, non solo al calcolo futuro,
+  perché `mvpVintiPerGiocatore()` deriva sempre il conteggio dai voti grezzi, senza storico
+  persistito a parte.
+- `mediePagelle()` resta invariata: chi la chiama altrove (profilo, squadra) senza applicare la
+  soglia continua a mostrare la media grezza — non tocca questa decisione, resta il limite già
+  noto in [pagelle.md](modules/pagelle.md).
+
+**Riesame**  
+Se la squadra segnala che il quorum di 2 voti per l'MVP è troppo permissivo o troppo severo, o
+se si vuole applicare la stessa soglia di Media voto anche alle StatTile di profilo e squadra.
+
+### DD-029 — Cancellare un evento pulisce a cascata i dati collegati
+
+**Data:** 9 settembre 2026  
+**Stato:** Accettata
+
+**Contesto**  
+Un audit del modulo Obiettivi ha verificato che gli obiettivi in sé non hanno bisogno di
+nessuna pulizia quando un evento viene cancellato: sono ricalcolati a runtime sull'elenco
+eventi corrente (`obiettivi.ts`), quindi un evento sparito da `eventi_app` semplicemente
+smette di contare. Il problema è un livello sotto: `useEliminaEvento()`
+(`src/lib/eventi.ts`) cancella solo la riga in `eventi_app`. Nessuna delle otto tabelle
+collegate (`risposte_presenze`, `cacche_partita`, `mvp_voti`, `pagelle_voti`,
+`badge_social_voti`, `turni_palloni`, `scout_sessioni`, `scout_live`, `scout_partite`) ha mai
+avuto una foreign key verso `eventi_app(id)`: le loro righe restavano orfane a database.
+
+Oggi è innocuo per le statistiche, perché nessun calcolo legge quelle tabelle se non partendo
+dall'elenco eventi corrente. Ma è un rischio latente: un id evento futuro identico a uno
+passato (generato come `"e" + timestamp`, collisione improbabile ma non impossibile)
+erediterebbe dati vecchi non suoi; e un calcolo futuro che iterasse direttamente una di quelle
+tabelle, invece di partire da `eventi_app`, conterebbe anche le righe orfane.
+
+**Decisione**  
+Migration `m14_pulizia_dati_evento_cancellato`: un trigger `AFTER DELETE ON eventi_app`
+cancella a cascata le righe corrispondenti (`evento_id`/`match_id = id evento cancellato`)
+nelle otto tabelle collegate, tramite una funzione `SECURITY DEFINER`. Agisce a database, non
+in `useEliminaEvento()`: protegge anche chi cancella un evento scrivendo direttamente su
+PostgREST, non solo chi passa dal bottone dell'app.
+
+**Alternative scartate**
+
+- Foreign key con `ON DELETE CASCADE` verso `eventi_app(id)` → non applicabile subito:
+  `mvp.md` documenta che storicamente `match_id` in `mvp_voti`/`pagelle_voti`/
+  `badge_social_voti` a volte conteneva l'id di una sessione Scout o di una partita CSI, non
+  l'id evento CrAPP. Un vincolo FK avrebbe rifiutato la migration alla prima riga storica
+  disallineata; il trigger non valida i dati esistenti, solo le cancellazioni da qui in avanti.
+- Cancellazione manuale nelle otto tabelle dentro `useEliminaEvento()` → fragile: va tenuta
+  aggiornata a mano ogni volta che un nuovo modulo aggiunge una tabella con `evento_id`, e non
+  protegge chi scrive/cancella direttamente su PostgREST.
+- Bonificare anche le righe orfane già esistenti nella stessa migration → rimandato: tocca dati
+  reali già scritti, è un intervento più delicato che merita una migration a sé, non urgente
+  perché quelle righe sono già invisibili a ogni calcolo attuale.
+
+**Conseguenze**
+
+- Da questa migration in poi, cancellare un evento (da qualunque punto, app o REST diretto)
+  ripulisce automaticamente tutte le tabelle collegate.
+- Le righe orfane generate da cancellazioni **precedenti** a questa migration restano nel
+  database: il trigger previene il problema da qui in avanti, non ripulisce lo storico.
+- `test/integration/pulizia-evento.test.ts` è la definizione eseguibile del comportamento:
+  scrive una riga in ciascuna delle otto tabelle, cancella l'evento e verifica che spariscano
+  tutte.
+
+**Aggiornamento (9 settembre 2026, stesso giorno)** — la bonifica dello storico prevista sopra
+come "riesame" è stata fatta subito dopo, migration `m15_bonifica_dati_evento_orfani`: righe
+orfane in `risposte_presenze`, `cacche_partita`, `turni_palloni`, `scout_sessioni`,
+`scout_live`, `scout_partite` identificate confrontando `evento_id` con `eventi_app`. Per
+`mvp_voti`/`pagelle_voti`/`badge_social_voti` il confronto si applica **solo** ai `match_id`
+nel formato id evento CrAPP (`^e[0-9a-z]+$`, quello di `nuovoIdEvento()`): i vecchi voti su id
+Scout (prefisso `s` + timestamp decimale) o CSI (numerico o `data-squadra-squadra`) non sono
+orfani, sono dati storici legittimi mai collegati a un evento CrAPP (vedi contesto sopra), e la
+migration non li tocca. Verificato manualmente sul database locale prima di applicarla: un voto
+di test su id Scout è sopravvissuto alla bonifica, un voto di test su id evento CrAPP orfano è
+stato rimosso.
+
+**Aggiornamento (9 settembre 2026)** — la verifica manuale di M15 non lasciava nessuna rete di
+sicurezza automatica per il futuro, a differenza del resto del progetto (DD-020). Migration
+`m16_funzione_bonifica_dati_evento_orfani` rende lo stesso corpo una funzione
+`bonifica_dati_evento_orfani()` (riservata al `service_role`, non richiamabile dall'app),
+coperta da `test/integration/bonifica-evento.test.ts`: inserisce una riga orfana e una storica
+su id Scout/CSI, richiama la funzione via RPC e verifica che tocchi solo la prima. Non serve
+richiamarla di nuovo ora (M15 ha già ripulito lo storico): resta pronta come intervento di
+manutenzione se in futuro il trigger di M14 smettesse di funzionare o emergesse un altro batch
+di orfani.
+
+**Riesame**  
+Se una nuova tabella collegata a un evento non viene aggiunta al trigger quando creata (va
+aggiornata a mano, non c'è un meccanismo che lo forzi).
+
+### DD-030 — Centro notifiche in-app: storico separato dalla push, letto solo con RLS
+
+**Data:** 15 settembre 2026  
+**Stato:** Accettata
+
+**Contesto**  
+Le notifiche esistenti (`docs/modules/notifiche.md`) sono solo push OS/browser: arrivano se
+il dispositivo ha attivato l'interruttore in Profilo, sono effimere (nessuno storico) e non
+hanno uno stato letto/non letto — chi non attiva le push, o cambia dispositivo, semplicemente
+non le vede mai. Serviva un canale visibile sempre, dentro l'app, con un badge accanto al
+profilo che segnali quante cose non lette ci sono.
+
+**Decisione**  
+Nuova tabella `notifiche_utente` (migration `m17_notifiche_utente`), popolata da quattro
+sorgenti lato database — mai dal client:
+
+1. messaggio libero dell'admin (`notifica-personalizzata.ts`, in parallelo alla push);
+2. promemoria automatico prima di un evento, 24h e 3h prima, due `cron.schedule`
+   (estensione `pg_cron`, abilitata dal 31/07/2026 e usata per la prima volta qui);
+3. turno palloni (`promemoria-palloni.ts`), in parallelo alla push;
+4. sollecito presenze (`sollecita-presenze.ts`), in parallelo alla push.
+
+Lettura e scrittura (segna come letta, elimina) passano dal client Supabase autenticato con
+RLS (`useNotificheMie()`/`useSegnaLette()`/`useEliminaNotifica()` in
+`src/lib/notifiche-utente.ts`), senza una route API dedicata — stesso pattern di
+`useSalvaEvento()` in `eventi.ts`. Nessuna policy INSERT per `authenticated`: le righe nascono
+solo da funzioni `SECURITY DEFINER` o dalla service role, mai da un client.
+
+Pallino con il conteggio sull'avatar del profilo (`PallinoNotifiche`,
+`src/components/crapp/ui-bits.tsx`; in origine una campanella separata, tolta per liberare
+l'header: il tap sull'avatar resta l'accesso al profilo, quello sul pallino apre il
+pannello), pannello a comparsa costruito a mano (nel progetto non c'è una libreria dropdown). Ogni riga si elimina
+con uno swipe o una ×: non c'è pulizia automatica delle notifiche vecchie, quindi è l'unico
+modo per un giocatore di toglierle di torno per sempre.
+
+**Alternative scartate**
+
+- Notificare anche sulla sola creazione di un evento, non solo sull'avvicinarsi della data →
+  scartata su richiesta esplicita: conta quando l'evento sta per succedere, non il momento in
+  cui è stato messo in calendario. La prima versione aveva un trigger `AFTER INSERT ON
+eventi_app` per questo, rimosso prima del rilascio.
+- Una route API dedicata per leggere/segnare come lette (come le route push esistenti) →
+  scartata: qui non serve la service role (niente da nascondere al giocatore stesso), quindi
+  la RLS basta ed evita di duplicare la logica di lettura già scritta lato client per gli
+  eventi.
+- Pulizia automatica delle notifiche vecchie con un cron di retention (es. elimina le lette
+  dopo 30 giorni) → scartata per ora a favore dello swipe manuale: più diretto da capire per
+  chi usa l'app, e la tabella resta comunque piccola per una sola squadra. Resta un'estensione
+  naturale se in futuro servisse.
+- Semplice `INSERT` invece di `upsert` per turno palloni e sollecito presenze → scartata: un
+  admin che preme due volte lo stesso pulsante per lo stesso evento avrebbe urtato contro il
+  vincolo `UNIQUE (giocatore_id, evento_id, tipo)`. L'upsert aggiorna la riga esistente
+  (testo e `creato_il` freschi, `letta` di nuovo `false`), così ripremere il pulsante si
+  comporta come un rinvio vero, non un errore silenzioso.
+
+**Conseguenze**
+
+- Il pallino sull'avatar riflette solo ciò che sta in `notifiche_utente`: un dispositivo senza
+  push attive vede comunque tutto, perché il canale è del tutto indipendente.
+- `eventi_app.ora` è testo libero e non validato dal form (`<input type="time">` si può
+  svuotare): la funzione `genera_promemoria_eventi()` usa `ora_evento_a_time()`, che assorbe
+  l'errore di cast riga per riga invece di far fallire l'intera generazione dei promemoria per
+  tutti gli eventi quando uno solo ha l'ora scritta male.
+- `test/integration/notifiche-utente.test.ts` è la definizione eseguibile del comportamento:
+  promemoria 24h/3h e deduplica, tolleranza a un'ora malformata, RLS su lettura/segna
+  letta/elimina, e le tre route (`notifica-personalizzata`, `promemoria-palloni`,
+  `sollecita-presenze`) che scrivono lo storico in-app.
+
+**Riesame**  
+Se la tabella crescesse in modo sensibile (squadre molto più numerose, o giocatori che non
+fanno mai swipe), va aggiunta la pulizia automatica scartata sopra.
+
+### DD-031 — Data di nascita pubblica: una colonna sincronizzata, non una seconda RLS aperta
+
+**Data:** 15 settembre 2026  
+**Stato:** Accettata
+
+**Contesto**  
+In "Squadra" la data di nascita mostrava **"Invalid Date"** per chi l'aveva inserita da
+solo dal proprio Profilo. Causa: due fonti mai collegate. I 17 giocatori del seed storico
+hanno la nascita in `nascitaPerId`, una mappa statica pubblica bundlata nel client
+(`src/lib/crapp-data.ts`) — il commento sulla riga la descriveva esplicitamente come
+stopgap: _"`giocatori_squadra` non ha ancora questa colonna (DD-015 follow-up)"_. Un
+giocatore aggiunto dopo la migrazione DD-015 inserisce invece la nascita dal form Profilo,
+che scrive su `profili_giocatore.data_nascita` — tabella con RLS "solo il proprio profilo o
+admin" (M2), mai letta da `useRosa()`/`useAnagraficaRosa()` (`src/lib/rosa.ts`), e comunque
+non visibile ai compagni per via della RLS. Per quel giocatore `nascitaPerId[g.id]` era
+`undefined` → `""` → `formatData("")` in `src/routes/squadra.tsx` produceva `Invalid Date`.
+
+**Decisione**  
+Migration `m18_nascita_pubblica_giocatori_squadra`: nuova colonna `giocatori_squadra.nascita`
+(quella prevista da DD-015), pubblica a tutta la rosa attiva con la stessa policy di lettura
+già in vigore per le altre colonne. Un trigger `SECURITY DEFINER` su `profili_giocatore`
+(`sincronizza_nascita_pubblica`, AFTER INSERT/UPDATE/DELETE) la tiene allineata a
+`data_nascita`: un solo input nel form Profilo (`CampiProfilo`), due destinazioni — quella
+amministrativa esistente (RLS invariata: sé stesso o admin) e questo specchio pubblico.
+`profili_giocatore` resta l'unica tabella che il client scrive per la nascita; il client non
+tocca mai `giocatori_squadra.nascita` direttamente.
+
+Essendo `SECURITY DEFINER` di proprietà dell'owner della tabella, la scrittura del trigger
+bypassa la RLS di `giocatori_squadra` automaticamente — nessuna nuova policy lì. Serve però
+un nuovo ramo in `enforce_giocatori_squadra_update()` (il trigger `BEFORE UPDATE` che oggi
+rifiuta qualunque modifica a uno slot già collegato da parte di chi non è admin): accetta un
+update dove cambia **solo** `nascita` e il chiamante è il proprietario dello slot
+(`OLD.auth_user_id = auth.uid()`). Senza quel ramo l'update annidato del trigger di sync
+fallirebbe con l'eccezione già in vigore.
+
+Backfill una tantum dei 17 storici con gli stessi valori di `nascitaPerId`, poi rimozione di
+quell'export (`crapp-data.ts`): era descritto fin dall'inizio come temporaneo, in attesa
+esattamente di questa colonna.
+
+**Alternative scartate**
+
+- Allentare la RLS di `profili_giocatore` per rendere `data_nascita` leggibile a tutta la
+  squadra → scartata: quella tabella porta anche indirizzo, telefono, documento d'identità
+  nello stesso record — aprirne la lettura avrebbe esposto molto più della sola nascita.
+- Un secondo campo "data di nascita pubblica" nel form Profilo, distinto da quello
+  amministrativo → scartata: due campi per lo stesso dato reale avrebbero richiesto
+  spiegare all'utente perché ne esistono due, con rischio di disallineamento se ne compila
+  uno solo.
+- Far scrivere `giocatori_squadra.nascita` direttamente dal client (nuova RLS policy per il
+  proprietario dello slot) invece di sincronizzarla da `profili_giocatore` → scartata: la
+  RLS di update per un non-admin resta `USING (auth_user_id IS NULL)` (solo reclamare uno
+  slot libero); aprirla anche a righe già collegate avrebbe ampliato la superficie scrivibile
+  dal client su una tabella con un trigger di sicurezza già delicato (DD-016/DD-023), per un
+  guadagno che il trigger di sync ottiene comunque senza toccare la RLS.
+
+**Conseguenze**
+
+- Chiunque compili la propria data di nascita dal Profilo la vede comparire in Squadra (e
+  nei compleanni del Calendario) esattamente come i 17 storici — non più un dato "di serie
+  B".
+- Cancellare il profilo (da sé o da un admin) azzera anche la nascita pubblica: non resta un
+  valore pubblico orfano di un profilo che non esiste più.
+- Un giocatore senza nascita nota (profilo mai compilato) non genera più "Invalid Date":
+  `squadra.tsx` mostra la riga della data di nascita solo se `g.nascita` è valorizzata,
+  stesso criterio già usato da `compleanniEventi()` per escludere chi non ha ancora un dato.
+- `test/integration/nascita-pubblica.test.ts` è la definizione eseguibile del comportamento:
+  sync alla scrittura, visibilità a un giocatore terzo (non solo l'interessato o l'admin),
+  azzeramento alla cancellazione, blocco della scrittura diretta dal client.
+
+**Riesame**  
+Se in futuro serve differenziare "chi può vedere la nascita" (es. solo squadra, non
+pubblico) va rivista insieme alla policy di lettura generale di `giocatori_squadra`, non solo
+per questa colonna.
+
+**Aggiornamento (15 settembre 2026, stesso giorno)** — dopo aver applicato M18 in produzione
+(`supabase db push`), la nascita in Squadra compariva solo per i 17 giocatori storici, non
+per chi aveva già compilato il proprio profilo prima della migration: il trigger di sync
+copre solo le scritture _future_ su `profili_giocatore`, non retroattivamente, e M18
+backfillava a mano solo il seed storico. Migration `m19_backfill_nascita_da_profili_esistenti`
+allinea una tantum `giocatori_squadra.nascita` a `profili_giocatore.data_nascita` per tutti i
+profili già esistenti, con la stessa disattivazione temporanea del trigger di sicurezza usata
+in M18. Da qui in poi il gap non si può ripresentare: ogni scrittura successiva passa dal
+trigger di sync, questo backfill serve solo per lo storico antecedente a M18.
+
+A differenza della bonifica eventi orfani (DD-029, M15→M16), qui il backfill non è stato
+reso una funzione richiamabile: resta SQL diretto nella migration. La copertura di test
+(`test/integration/backfill-nascita-esistenti.test.ts`) verifica comunque lo stesso
+comportamento eseguendo lo stesso pattern SQL via `psql` nel container Postgres locale —
+scelta necessaria perché senza una funzione RPC, PostgREST non espone un update
+multi-tabella come questo.
+
+### DD-032 — La stagione CSI si ricava dalle date delle gare
+
+**Data:** 24 settembre 2026  
+**Stato:** Accettata
+
+**Contesto**  
+La pagina Campionato (`/classifica`) non diceva a quale stagione si riferissero classifica e
+storico partite. Il portale CSI non espone il nome della stagione da nessuna parte:
+`project-sheets.php`, `league_details.php`, `team-main.php` e il feed
+`getEventsByTeamId.php` riportano solo il nome della competizione (verificato il
+24/09/2026). Il `project_id` cambia a ogni stagione ed è aggiornato a mano in
+`csi-core.ts`.
+
+**Decisione**  
+`stagioneDi()` in `src/lib/csi-core.ts` ricava la stagione ("2025/26") dalla data di una
+gara, con l'anno che cambia ad agosto; `stagioneDaPartite()` usa la prima gara del
+campionato letto (tutte le gare, non solo quelle giocate, così a inizio stagione basta il
+calendario). L'header di `/classifica` mostra quella stagione, e lo storico partite è
+diviso per stagione con `raggruppaPerStagione()`: le gare dello Scout Live locale, usate
+quando il CSI non ne ha, possono essere di stagioni diverse.
+
+**Alternative scartate**
+
+- Una costante `CSI_STAGIONE` accanto a `CSI_PROJECT_ID` → un secondo valore da ricordarsi
+  di aggiornare a ogni stagione, che può divergere dal `project_id`; ricavata dai dati
+  segue da sola.
+- Usare la stagione "in corso" per la squadra (la data di oggi) → sbaglierebbe proprio nel
+  periodo di passaggio: a settembre 2026 il CSI mostra ancora i dati 2025/26.
+
+**Conseguenze**
+
+- Oggi Campionato mostra «Stagione 2025/26» mentre Squadra e Calendario, che hanno la
+  stagione scritta nel codice, mostrano «Stagione 2026/27»: il CSI non ha ancora creato le
+  pagine della nuova stagione. È voluto — Campionato riporta la stagione dei dati che
+  mostra (dettagli in [collegamento-csi.md](modules/collegamento-csi.md)).
+- Quando si aggiornano i `project_id` l'etichetta si aggiorna senza toccare altro codice.
+
+**Riesame**  
+Se il CSI iniziasse a esporre il nome della stagione, leggerlo da lì; se una stagione CSI
+dovesse iniziare prima di agosto, spostare la soglia in `stagioneDi()`.
+
+### DD-033 — Gestione eventi: solo calendario, giorno fissato dal tocco
+
+**Data:** 24 settembre 2026  
+**Stato:** Accettata
+
+**Contesto**  
+`/eventi` mostrava sotto la griglia mensile anche la lista cronologica di tutti gli eventi
+("Eventi in calendario"). La lista non aveva azioni proprie (toccare una riga apriva lo
+stesso drawer del giorno) e allungava la pagina con informazioni già nel calendario. Nel
+form, poi, il campo «Data» era già precompilato con il giorno toccato ma sembrava da
+compilare: l'amministratore doveva scegliere solo l'ora.
+
+**Decisione**  
+La pagina mostra solo il calendario, che si scorre di mese in mese con le frecce o con lo
+swipe (stessa fisica a molla di `/calendario`, disattivata con `useMotoRidotto()`). Nel form
+il giorno compare come testo fisso e resta da scegliere l'ora; il campo data compare solo
+toccando «Cambia», per spostare un evento in un altro giorno.
+
+**Alternative scartate**
+
+- Togliere del tutto il campo data → non si potrebbe più spostare un evento esistente, una
+  funzione che oggi c'è (regola anti-regressione).
+- Tenere la lista ma più corta (solo i prossimi eventi) → i prossimi eventi sono già in home
+  e in `/calendario`; qui sarebbe stata un doppione.
+
+**Conseguenze**
+
+- Per trovare un evento lontano bisogna scorrere fino al suo mese; il totale degli eventi
+  resta nel sottotitolo dell'header.
+- Caricamento ed errore di `useEventi()` compaiono dentro la card del calendario, dove prima
+  stava la lista.
+
+**Riesame**  
+Se gli eventi crescono tanto da rendere scomodo lo scorrere dei mesi, valutare una ricerca
+per titolo invece di reintrodurre la lista completa.
+
+### DD-034 — L'allenatore è uno slot della squadra con tipo diverso, non un giocatore
+
+**Data:** 24 settembre 2026  
+**Stato:** Accettata (implementata con le migration M20 e M21)
+
+**Contesto**  
+Serve un account per l'allenatore: deve gestire gli eventi (oggi solo admin, `m11`) ma non è
+un giocatore. Non ha statistiche, badge né stagione, non vota e non viene votato. L'admin
+vuole registrarlo come i giocatori, inserendo la sua email Gmail. Specifica completa in
+[modules/allenatore.md](modules/allenatore.md).
+
+**Decisione**  
+L'allenatore è una riga di `giocatori_squadra` con una nuova colonna `tipo = 'allenatore'`
+(default `'giocatore'`). Così riusa senza cambiarli il collegamento per email (DD-018),
+`profili_giocatore` per i dati personali, il bucket avatar e il compleanno sincronizzato
+(DD-031). Il permesso di gestire gli eventi arriva da un nuovo valore `allenatore` di
+`app_role` in `user_roles` (DD-011), scritto da una funzione `SECURITY DEFINER` quando si
+collega uno slot di tipo allenatore: è quindi l'admin a concederlo, registrando lo slot.
+"Rosa" diventa `attivo e tipo = 'giocatore'` ovunque.
+
+**Alternative scartate**
+
+- Una tabella `staff` separata → isola l'allenatore da voti e rosa senza toccare i filtri, ma
+  duplica collegamento per email, profilo, avatar e form admin. Resta l'alternativa se i
+  filtri sulla rosa si rivelano troppi o fragili.
+- Registrare l'allenatore come admin → gli darebbe dati personali e documenti di tutta la
+  squadra (DD-017), molto più del necessario.
+- Distinguere l'allenatore dal campo `ruolo` (ruolo in campo) → mescola due concetti e il
+  campo è testo libero.
+
+**Conseguenze**
+
+- Ogni lettura della rosa (client, server, SQL di voto e promemoria) va filtrata per `tipo`:
+  un punto dimenticato rende l'allenatore votabile o lo conta tra i convocati. L'elenco sta
+  nella specifica e va coperto dai test di `permessi.test.ts`.
+- Il trigger sugli slot cambia: `tipo` lo scrive solo l'admin; nome e cognome li scrive anche
+  l'allenatore sul proprio slot.
+- `numero` diventa nullabile a database, ma solo per gli allenatori (vincolo di M21); nell'app
+  resta un numero, 0 per l'allenatore, per non toccare i tipi di tutta la rosa.
+- Due fonti distinte, ciascuna per il suo scopo: i permessi (eventi, sollecito) da
+  `user_roles`, la visibilità (badge, cacche, stagione) dal tipo del proprio slot, che è
+  immediato e non aspetta la query dei ruoli.
+- L'allenatore non vede le tab Stagione e Badge del Profilo, né Obiettivi e Badge di Squadra.
+- In Squadra compare nella tab Rosa con «Allenatore» al posto del ruolo, ricavato da `tipo`;
+  riceve i promemoria degli eventi e può sollecitare le presenze, non il turno palloni.
+- Non vede badge né classifiche o sondaggi sulle cacche, in nessuna schermata.
+
+**Riesame**  
+Se arriva un secondo tipo di staff (dirigente, segreteria) o se i filtri sulla rosa diventano
+fonte di bug, passare alla tabella `staff` separata.
+
+### DD-035 — Avviso certificati: calcolato in Home, visibile solo al titolare e agli admin
+
+**Data:** 24 settembre 2026  
+**Stato:** Accettata (implementata, versione 1.1.0)
+
+**Contesto**  
+Il certificato medico ha una data di scadenza (`profili_giocatore.certificato_scadenza`), ma
+oggi ci si accorge che è scaduto solo aprendo la tab Profili di `/admin`: spesso quando il
+giocatore è già fuori regola. La richiesta è un avviso in Home, giallo nei 7 giorni prima
+della scadenza e nero dopo, con i nomi dei giocatori, che sparisca da solo quando il
+certificato viene rinnovato. Specifica completa in
+[modules/profilo-giocatore.md](modules/profilo-giocatore.md#avviso-certificati).
+
+**Decisione**
+
+1. L'avviso si **calcola al volo** dalla data già salvata, con una funzione pura in
+   `profili-core.ts`: nessuna tabella, nessuno stato «avvisato», nessuna migration.
+2. Lo vedono **solo gli admin**, con i nomi di tutta la rosa, e **il giocatore interessato**,
+   riferito solo a sé. L'allenatore e i compagni non lo vedono.
+3. L'avviso dello staff **non è cliccabile**; quello personale apre
+   `/profilo?tab=documenti`.
+4. Soglia fissa di **7 giorni** in una costante; il giorno della scadenza il certificato vale
+   ancora (come `statoScadenza()`).
+5. **Niente push**: l'avviso vive solo in Home.
+
+**Alternative scartate**
+
+- Mostrarlo anche all'allenatore → il certificato è un dato sanitario che oggi l'allenatore
+  non vede (DD-034); servirebbe una funzione `SECURITY DEFINER` apposta per un'informazione
+  che all'allenatore non serve ad agire.
+- Salvare gli avvisi in una tabella o nel centro notifiche (DD-030) → uno stato da tenere
+  allineato alla data, che si disallinea appena il giocatore corregge la scadenza; calcolarlo
+  è gratis e sempre giusto.
+- Avviso dello staff cliccabile verso `/admin?tab=profili` → l'admin non può caricare il file
+  al posto del giocatore (DD-017), quindi il tocco non gli farebbe fare nulla in più, e
+  richiederebbe di aggiungere a `/admin` la lettura della tab dall'URL.
+- Mostrare al massimo alcuni nomi e un «e altri N» → a inizio stagione ne scadono molti
+  insieme ed è proprio lì che l'elenco completo serve.
+- Push quotidiana a chi ha il certificato in scadenza → servirebbe un cron, che oggi non
+  esiste per nessuna push (DD-025), e le push vanno riservate agli eventi importanti
+  ([EFFICIENZA_CLOUD.md](EFFICIENZA_CLOUD.md)).
+- Includere i certificati mancanti → è un problema diverso (profilo incompleto), già coperto
+  dal widget «Completa il tuo profilo» e dalla tab Profili.
+
+**Conseguenze**
+
+- Nessuna query nuova: si riusa `useProfili()`, già in cache per Profilo e `/admin`, e le RLS
+  esistenti decidono quanti profili arrivano (tutti all'admin, il proprio al giocatore).
+- Il rinnovo non richiede nessuna azione di chiusura: cambiata la data, l'avviso si aggiorna
+  da solo.
+- Chi non apre l'app non viene avvisato: l'avviso raggiunge solo chi entra in Home.
+- Un admin che è anche giocatore vede solo l'avviso dello staff, dove compare il suo nome.
+
+**Riesame**  
+Se gli avvisi in Home non bastano (certificati che scadono comunque senza essere rinnovati),
+valutare una push, legata a un cron o a un invio manuale dell'admin come per i palloni. Se 7
+giorni si rivelano pochi per prenotare una visita, alzare la costante o renderla regolabile.

docs/EFFICIENZA_CLOUD.md

@@ -11,8 +11,9 @@ Query, traffico e invocazioni vanno tenuti al minimo **per costruzione**, non ot
    (`staleTime` 5 min, `gcTime` 30 min, `refetchOnWindowFocus/Mount/Reconnect` disattivati,
    `retry: 1`). Non alzare la frequenza di refetch modulo per modulo.
 3. **Dopo una mutazione si aggiorna la cache con `setQueryData`**, non con
-   `invalidateQueries`: invalidare costa una rilettura. Unica eccezione oggi:
-   `src/lib/scout-live.ts`.
+   `invalidateQueries`: invalidare costa una rilettura. Unica eccezione:
+   `src/lib/scout-live.ts`, dove il lock di sessione può essere stato preso da un altro
+   dispositivo e la riga scritta non basta a sapere chi ha vinto.
 4. **Scout Live**: scrive solo chi sta segnando; gli altri leggono dati già salvati.
 5. **Write once, read many**: statistiche, badge e classifiche si calcolano una volta e non
    si ricalcolano a ogni apertura di pagina. I badge restano calcolati a runtime dai dati già

docs/PORTABILITA.md

@@ -13,7 +13,6 @@ senza dipendere da servizi esclusivi di Lovable Cloud.
 | Client dati (`@supabase/supabase-js`)             | Sì         | Supabase è open source e self-hostable; in alternativa si sostituisce il solo livello dati (`src/lib/*.ts`). |
 | Web Push (`src/lib/webpush.server.ts`)            | Sì         | VAPID implementato con Web Crypto, disponibile in Node 18+.                                                  |
 | Auth                                              | Sì         | GoTrue self-hosted oppure qualsiasi provider OIDC.                                                           |
-| `src/integrations/lovable/*`                      | Opzionale  | Login social gestito da Lovable: **non importato da nessuna schermata**, rimovibile senza impatti.           |
 | `@lovable.dev/vite-tanstack-config`               | Solo build | Preset Vite; sostituibile con una config Vite/TanStack esplicita.                                            |
 
 ## Regole da rispettare nelle prossime modifiche
@@ -28,6 +27,15 @@ senza dipendere da servizi esclusivi di Lovable Cloud.
 5. Job pianificati richiamabili via semplice HTTP POST (es. `/api/public/promemoria-palloni`),
    così funzionano con cron di sistema, pg_cron o qualsiasi scheduler.
 
+## Backup e disaster recovery
+
+Lo script [`backups/backup.sh`](../backups/backup.sh) scarica su un host locale schema e
+dati del database (`public` e `auth`), utenti Supabase Auth e file dei bucket storage, in
+modo da poter ripartire in fretta se il progetto Supabase (o Vercel) venisse perso.
+Uso, contenuto del backup e procedura di ripristino sono descritti in
+[`backups/README.md`](../backups/README.md). Non ancora automatizzato: l'export delle
+variabili d'ambiente Vercel (richiede login interattivo).
+
 ## Migrazione su server proprio (sintesi)
 
 1. `bun run build` (o `npm run build`) → avvio del server Node generato.

docs/README.md

@@ -6,35 +6,34 @@ ancora e va **prima documentata** (vedi [DD-002](DESIGN_DECISIONS.md#dd-002--svi
 
 ## Dove sta cosa
 
-| Documento                                  | Risponde a                                                                   |
-| ------------------------------------------ | ---------------------------------------------------------------------------- |
-| [VISION.md](VISION.md)                     | Perché esiste CrAPP, quali principi deve rispettare una funzionalità         |
-| [ROADMAP.md](ROADMAP.md)                   | Cosa è fatto e cosa è previsto, versione per versione                        |
-| [ARCHITECTURE.md](ARCHITECTURE.md)         | Com'è fatta l'app: stack, struttura del codice, flusso di sviluppo           |
-| [DATABASE.md](DATABASE.md)                 | Quali tabelle esistono, a cosa servono, chi le usa                           |
-| [DESIGN_DECISIONS.md](DESIGN_DECISIONS.md) | Perché abbiamo scelto così, cosa abbiamo escluso e quando riaprire la scelta |
-| [PORTABILITA.md](PORTABILITA.md)           | Cosa lega l'app a un fornitore e cosa no, come spostarla su server proprio   |
-| [EFFICIENZA_CLOUD.md](EFFICIENZA_CLOUD.md) | Come tenere basso il consumo cloud: cache, query, push                       |
-| [TODO.md](TODO.md)                         | A cosa si sta lavorando adesso                                               |
-| [CHANGELOG.md](CHANGELOG.md)               | Cosa è cambiato e quando                                                     |
-| [modules/](modules/)                       | Specifica funzionale di ogni modulo, una per file                            |
+| Documento                                  | Risponde a                                                                                                    |
+| ------------------------------------------ | ------------------------------------------------------------------------------------------------------------- |
+| [ROADMAP.md](ROADMAP.md)                   | Cosa è fatto, cosa è previsto, cosa resta un'idea                                                             |
+| [ARCHITECTURE.md](ARCHITECTURE.md)         | Com'è fatta l'app: stack, struttura del codice, flusso di sviluppo                                            |
+| [DATABASE.md](DATABASE.md)                 | Quali tabelle esistono, a cosa servono, chi le usa                                                            |
+| [DESIGN_DECISIONS.md](DESIGN_DECISIONS.md) | Perché abbiamo scelto così, cosa abbiamo escluso e quando riaprire la scelta                                  |
+| [PORTABILITA.md](PORTABILITA.md)           | Cosa lega l'app a un fornitore e cosa no, come spostarla su server proprio (backup/disaster recovery incluso) |
+| [EFFICIENZA_CLOUD.md](EFFICIENZA_CLOUD.md) | Come tenere basso il consumo cloud: cache, query, push                                                        |
+| [CHANGELOG.md](CHANGELOG.md)               | Cosa è cambiato e quando                                                                                      |
+| [modules/](modules/)                       | Specifica funzionale di ogni modulo, una per file                                                             |
 
 Le regole vincolanti per gli assistenti AI stanno in [AGENTS.md](../AGENTS.md);
 lo stato corrente del lavoro in [PROJECT_STATE.md](../PROJECT_STATE.md).
 
 ## Ordine di lettura
 
-Prima di modificare il codice, nell'ordine: questo indice → `VISION.md` → `ROADMAP.md` →
-`ARCHITECTURE.md` → `DATABASE.md` → `DESIGN_DECISIONS.md` → `TODO.md` → il documento del
-modulo interessato in `modules/`.
+Prima di modificare il codice, nell'ordine: questo indice → `ROADMAP.md` → `ARCHITECTURE.md`
+→ `DATABASE.md` → `DESIGN_DECISIONS.md` → il documento del modulo interessato in `modules/`.
 
 ## Regole di manutenzione
 
 Ogni informazione ha **una sola casa**, per evitare che le copie divergano:
 
 - l'elenco delle funzionalità (fatte e previste) sta solo in `ROADMAP.md`;
-- `CHANGELOG.md` registra _quando_ qualcosa è stato rilasciato, non ripete l'elenco;
-- `TODO.md` contiene solo il lavoro in corso o imminente, e rimanda alla roadmap;
+- `CHANGELOG.md` registra _quando_ qualcosa è stato rilasciato, non ripete l'elenco: segue
+  il formato Keep a Changelog, con il lavoro non ancora rilasciato sotto `[Non rilasciato]`
+  e le voci divise per categoria (Aggiunto, Modificato, Sicurezza…);
+- il lavoro in corso sta solo in `PROJECT_STATE.md`, che rimanda alla roadmap per il resto;
 - lo schema del database sta solo in `DATABASE.md`, allineato alle migration in
   `supabase/migrations/`: una tabella nuova si documenta nella stessa modifica che la crea;
 - le motivazioni stanno solo in `DESIGN_DECISIONS.md`, in voci `DD-XXX`; per aggiungerne

docs/ROADMAP.md

@@ -1,10 +1,12 @@
 # Roadmap
 
 Elenco unico delle funzionalità di CrAPP, fatte e previste. È la fonte di riferimento per
-il _cosa_: `CHANGELOG.md` registra _quando_ una voce è stata rilasciata, `TODO.md` cosa si
-sta facendo adesso.
+il _cosa_: `CHANGELOG.md` registra _quando_ una voce è stata rilasciata e con quale versione,
+[PROJECT_STATE.md](../PROJECT_STATE.md) cosa si sta facendo adesso.
 
-## Versione 1.0 — rilasciata
+## Fatto
+
+Tutto quello che è rilasciato, fino alla versione 1.0.0 (vedi `CHANGELOG.md`).
 
 - [x] Gestione squadra
 - [x] Calendario
@@ -14,35 +16,40 @@ sta facendo adesso.
 - [x] Badge
 - [x] Badge social
 - [x] Pagelle
+- [x] Votazione MVP
 - [x] Obiettivi di squadra
+- [x] Turno palloni
+- [x] Infortuni — conteggio eventi saltati, in forma minima
 - [x] Notifiche Push (promemoria intelligenti)
-
-## Versione 1.1
-
-Le voci spuntate sono in produzione su `main`. I passaggi di attivazione ancora aperti (per
-esempio il collegamento dei singoli account) stanno in [PROJECT_STATE.md](../PROJECT_STATE.md).
-
-- [x] Certificati medici — caricamento, scadenza, stato e download; lo storico dei
-      certificati resta un'estensione futura
-- [x] Gestione tesseramenti CSI — raccolta dati, export CSV e tracciamento di chi è già
-      tesserato (numero e data di tessera)
+- [x] Centro notifiche in-app — pallino con il numero delle non lette sull'avatar del
+      profilo (il tap sul pallino apre l'elenco), indipendente dalla push (messaggi admin, promemoria evento, turno palloni,
+      sollecito presenze)
 - [x] Dashboard amministratore
 - [x] Download CSV dati
+- [x] Profilo Giocatore — dati personali, documento d'identità, certificato medico
+      (caricamento, scadenza, stato, download) e foto tessera; lo storico dei certificati
+      resta un'estensione futura
+- [x] Gestione tesseramenti CSI — raccolta dati, export CSV e tracciamento di chi è già
+      tesserato (numero e data di tessera)
+- [x] Collegamento CSI (stagione 2025/26)
+- [x] Classifica automatica (campionato e Coppa)
+- [x] Risultati campionato
+- [x] Dettaglio partita — formazioni, storico scontri diretti e probabilità di vittoria
+      calcolata dal CSI
+- [x] Ruolo allenatore — gestisce gli eventi e sollecita le presenze, profilo ridotto senza
+      stagione e badge ([specifica](modules/allenatore.md), DD-034)
+- [x] Avviso certificati in scadenza — in Home, giallo nei 7 giorni prima e nero dopo la
+      scadenza: agli admin con i nomi dei giocatori, al giocatore solo per il proprio
+      ([specifica](modules/profilo-giocatore.md#avviso-certificati), DD-035)
 
-## Versione 1.2
+## Prossimo
 
+- [ ] Calendario ufficiale — i dati delle gare future arrivano già dal feed CSI, la pagina
+      Campionato usa solo quelle giocate
 - [ ] Database esercizi
 - [ ] AI Allenamenti
 - [ ] Archivio allenamenti
 
-## Versione 2.0
-
-- [x] Collegamento CSI (stagione 2025/26)
-- [x] Classifica automatica
-- [x] Risultati campionato
-- [ ] Calendario ufficiale — i dati delle gare future arrivano già dal feed CSI, la pagina
-      Campionato usa solo quelle giocate
-
 ## Idee future
 
 - [ ] Gestione quote

docs/TODO.md

@@ -1,40 +0,0 @@
-# TODO
-
-Solo il lavoro in corso o imminente. L'elenco completo delle funzionalità previste sta in
-[ROADMAP.md](ROADMAP.md); le idee non ancora valutate pure.
-
-## In corso
-
-- Correzione push Android pronta in locale: aggiornamento del worker nelle sessioni della
-  webapp e test del canale cifrato verificati. Resta la verifica su Motorola installato,
-  ad app chiusa e schermo bloccato; procedura e limiti in [Notifiche](modules/notifiche.md).
-- Documentazione tecnica del progetto.
-- Autenticazione Google e dashboard amministratore: il codice è in produzione su `main` e il
-  login è l'unica via d'accesso. La migration M4, che chiude gli accessi `anon` alle
-  tabelle v1.0, è stata applicata in produzione (03/09/2026). Resta il collegamento dei
-  singoli account: ogni giocatore si aggancia al proprio profilo al primo login (DD-018), un
-  processo continuo — vale anche per chi viene aggiunto a stagione in corso da `/admin`.
-  Stato di dettaglio in [PROJECT_STATE.md](../PROJECT_STATE.md).
-
-## Prossimo
-
-- Niente di assegnato. Le voci ancora aperte in [ROADMAP.md](ROADMAP.md) sono «Calendario
-  ufficiale» (v2.0, i dati delle gare future arrivano già dal feed CSI) e la v1.2.
-
-La gestione tesseramenti CSI della v1.1 è completa: raccolta dati, export CSV e tracciamento
-di chi è già tesserato (numero e data di tessera, migration `m8_tesseramento_csi`, registrabili
-da `/admin`).
-
-Il profilo giocatore lato giocatore e i certificati medici sono fatti: `ProfiloAmministrativo`
-in `src/routes/profilo.tsx` carica documento, certificato e foto con le date di scadenza, e
-la dashboard amministratore legge quei dati.
-
-## Manutenzione ricorrente
-
-- Collegamento CSI: aggiornare `project_id` e `team_id` a inizio stagione 2026/27
-  (vedi [modules/collegamento-csi.md](modules/collegamento-csi.md)).
-
-## Backlog
-
-- AI Allenamenti (roadmap v1.2).
-- Backup automatici (roadmap, idee future).

docs/VISION.md

@@ -1,32 +0,0 @@
-# Visione del progetto
-
-## Missione
-
-CrAPP nasce con un obiettivo semplice:
-
-Digitalizzare completamente la gestione di una squadra di pallavolo, eliminando il maggior numero possibile di attività manuali e aumentando il coinvolgimento dei giocatori attraverso strumenti moderni e intuitivi.
-
-## Principi del progetto
-
-Ogni funzionalità sviluppata deve rispettare almeno uno di questi principi:
-
-- Ridurre il lavoro amministrativo.
-- Migliorare il coinvolgimento della squadra.
-- Centralizzare tutte le informazioni in un'unica piattaforma.
-- Automatizzare le attività ripetitive.
-- Sfruttare l'intelligenza artificiale solo quando porta un reale beneficio.
-
-## Filosofia
-
-CrAPP deve essere:
-
-- Semplice
-- Veloce
-- Divertente
-- Intuitiva
-- Accessibile da smartphone
-- Utilizzabile anche da persone poco esperte
-
-## Obiettivo finale
-
-Diventare il punto di riferimento per la gestione quotidiana della squadra, sostituendo chat, fogli Excel e strumenti separati con un'unica applicazione.

docs/archive/migrations/20260830120000_m2_profili_giocatore.sql

@@ -1,5 +1,5 @@
 -- M2 — Profilo Giocatore: dati personali, documento d'identità, certificato medico (DD-016)
--- Migration additiva: solo CREATE, nessuna modifica alle tabelle v1.0 esistenti.
+-- Migration additiva: solo CREATE, nessuna modifica alle tabelle preesistenti.
 -- I file non stanno qui: la tabella conserva solo i path dentro il bucket privato
 -- `profili-giocatore` creato dalla migration M3.
 

docs/modules/allenatore.md

@@ -0,0 +1,192 @@
+# Modulo — Ruolo Allenatore
+
+**Stato:** implementato
+**Decisione:** [DD-034](../DESIGN_DECISIONS.md#dd-034--lallenatore-è-uno-slot-della-squadra-con-tipo-diverso-non-un-giocatore)
+**Migration:** `m20_ruolo_allenatore_enum`, `m21_ruolo_allenatore`
+**File principali:** `src/lib/giocatori-squadra.ts` (`tipo`, `inRosa`, `isAllenatore`,
+`ruoloVisibile`), `src/lib/ruoli.ts`, `src/lib/user-store.ts` (`useSonoAllenatore`,
+`useGiocatoreInCampo`), `src/lib/auth-route.server.ts`, `src/routes/profilo.tsx`,
+`src/routes/admin.tsx`, `src/routes/squadra.tsx`, `src/routes/index.tsx`
+**Test:** `test/unit/giocatori-squadra.test.ts`, `test/unit/profili-core.test.ts`,
+`test/unit/presenze.test.ts`, `test/integration/permessi-allenatore.test.ts`,
+`test/integration/permessi-route.test.ts`
+
+## Obiettivo
+
+Dare accesso all'app all'allenatore, con permessi diversi da quelli di un giocatore: gestisce
+gli eventi (allenamenti, partite, amichevoli) e sollecita le presenze, ma non gioca: compare
+in Squadra come membro con la dicitura «Allenatore», però non è convocabile, non vota, non
+riceve voti e non ha statistiche, badge o stagione.
+
+## Registrazione
+
+Stesso flusso dei giocatori (DD-018), senza passaggi in più:
+
+1. L'admin, da `/admin` → **Aggiungi**, sceglie il tipo **Allenatore** invece di Giocatore e
+   inserisce nome, cognome ed email Gmail. Numero di maglia e ruolo in campo non si chiedono.
+2. L'allenatore accede con Google; l'email corrisponde allo slot e il collegamento è
+   automatico. Se l'email non corrisponde, stesso messaggio di errore dei giocatori.
+3. Entra in Home.
+
+Il permesso nasce dalla registrazione fatta dall'admin: l'allenatore non può
+auto-promuoversi, perché il tipo dello slot lo scrive solo un admin (come oggi numero e ruolo).
+
+## Profilo
+
+Il profilo dell'allenatore ha solo due tab (quelle del giocatore sono quattro):
+
+| Tab          | Giocatore | Allenatore                                     |
+| ------------ | --------- | ---------------------------------------------- |
+| Stagione     | sì        | **no**                                         |
+| Badge        | sì        | **no**                                         |
+| Documenti    | sì        | sì, ridotta (vedi sotto); tab iniziale         |
+| Impostazioni | sì        | sì, identica (logout, notifiche, segnalazioni) |
+
+Un link diretto a `/profilo?tab=stagione` o `?tab=badge` apre Documenti.
+
+### Dati modificabili dall'allenatore
+
+| Campo            | Dove sta oggi                     | Nota                                                                                           |
+| ---------------- | --------------------------------- | ---------------------------------------------------------------------------------------------- |
+| Nome, cognome    | `giocatori_squadra`               | per un giocatore li scrive solo l'admin; per l'allenatore anche lui sul proprio slot           |
+| Email (contatto) | `profili_giocatore.email`         | non è l'email di login, che resta quella registrata dall'admin                                 |
+| Data di nascita  | `profili_giocatore.data_nascita`  | sincronizzata in `giocatori_squadra.nascita` come per tutti (DD-031): compleanno in Calendario |
+| Luogo di nascita | `profili_giocatore.luogo_nascita` |                                                                                                |
+| Telefono         | `profili_giocatore.telefono`      |                                                                                                |
+| Foto profilo     | bucket `avatar-giocatori`         | stesso cerchio avatar e stesso upload dei giocatori                                            |
+
+**Non** si mostrano: indirizzo di residenza, documento d'identità, certificato medico, foto
+tessera, tesseramento CSI.
+
+### Completamento profilo
+
+Per l'allenatore il completamento conta solo data e luogo di nascita, telefono ed email, 25%
+ciascuno (`completamentoAllenatore()`). Il widget in Home segue la stessa regola: sparisce
+quando quei campi sono compilati.
+
+## Home
+
+La Home dell'allenatore tiene ciò che riguarda la squadra e toglie ciò che riguarda il
+giocatore: restano classifica e bilancio, prossimo impegno e ultima partita; spariscono lo
+streak personale, il promemoria palloni, «Da confermare», l'obiettivo di squadra e il
+«Colpo d'occhio» con le statistiche personali. Non compare nemmeno l'avviso certificati: lo
+vedono solo gli admin e il giocatore interessato (DD-035).
+
+## Squadra
+
+L'allenatore compare nella tab **Rosa** insieme ai giocatori, con foto, nome e cognome. Dove
+per un giocatore c'è il ruolo in campo (palleggiatore, schiacciatore…) per lui c'è scritto
+**Allenatore**, ricavato da `tipo` e non dal campo `ruolo`. Non ha numero di maglia né
+statistiche, e non compare nella tab Stats né nelle classifiche.
+
+Da allenatore, in `/squadra` vede solo **Rosa** e **Stats**: le tab **Obiettivi** e **Badge**
+non compaiono.
+
+| Tab       | Giocatore | Allenatore |
+| --------- | --------- | ---------- |
+| Rosa      | sì        | sì         |
+| Stats     | sì        | sì         |
+| Obiettivi | sì        | **no**     |
+| Badge     | sì        | **no**     |
+
+## Badge e cacche nascosti
+
+L'allenatore non vede **nessun badge** e **nessuna classifica o dato sulle cacche**, in
+nessuna schermata:
+
+| Dove                                | Cosa si nasconde all'allenatore                                                  |
+| ----------------------------------- | -------------------------------------------------------------------------------- |
+| `/squadra` → Stats                  | il criterio di ordinamento «Cacche» (`cacchePartita`)                            |
+| `/squadra` → Rosa, scheda giocatore | la riga «Cacche/partita 💩»                                                      |
+| `/partita/$id`                      | la sezione «Badge votati dai compagni» e il sondaggio cacche (`SondaggioCacche`) |
+| push «Sondaggio pre-partita aperto» | non parte verso i dispositivi degli allenatori (`apri-sondaggio.ts`)             |
+| `/profilo`, `/squadra`              | le tab Badge (già escluse sopra)                                                 |
+
+Presenze, media voto, MVP e palloni restano visibili.
+
+## Gestione eventi
+
+L'allenatore ha su `/eventi` gli stessi poteri dell'admin: crea, modifica, sposta ed elimina
+eventi e sceglie i convocati (l'elenco dei convocati contiene solo giocatori). Nel database
+la policy di scrittura su `eventi_app` è "admin o allenatore" (M21); la cancellazione a
+cascata (DD-029) resta invariata. Il bottone «Gestisci eventi» del Calendario compare anche
+a lui (`usePuoGestireEventi()`).
+
+Può anche **sollecitare le presenze** di un evento, come l'admin: la route
+`sollecita-presenze.ts` accetta admin o allenatore (`richiediGestoreEventi()`), e il
+sollecito arriva solo ai giocatori che non hanno risposto, mai all'allenatore stesso.
+
+**Restano solo admin:** dashboard `/admin`, dati e documenti dei giocatori, export CSI,
+notifica personalizzata, promemoria palloni, apertura sondaggio cacche, correzione delle
+risposte presenze altrui, gestione dei ruoli.
+
+## Notifiche
+
+L'allenatore riceve i promemoria automatici degli eventi (24h e 3h prima, centro notifiche
+in-app di M17) come i giocatori, anche se non è convocato: `giocatori_destinatari_evento()`
+lo include sempre. Riceve anche i messaggi dell'admin, e può attivare le push dal proprio
+Profilo. Non riceve il sollecito presenze, il turno palloni né il sondaggio cacche, che
+riguardano chi gioca.
+
+## Esclusione dalla rosa
+
+L'allenatore ha uno slot in `giocatori_squadra` (DD-034), quindi ogni lettura della "rosa di
+gioco" lo esclude con `inRosa()` (`attivo` e `tipo = giocatore`) al posto del vecchio filtro
+su `attivo`. Fanno eccezione la tab Rosa di Squadra, i compleanni del Calendario
+(`useAnagraficaRosa({ conAllenatori: true })`), i destinatari dei promemoria evento e dei
+messaggi admin, che lo includono.
+
+| Livello  | Dove si esclude l'allenatore                                                                                                                                                     |
+| -------- | -------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- |
+| client   | `useRosa()`, `useAnagraficaRosa()`, `useTurniPalloni()`, `usePresenzeUltimoMeseTutti()`, form convocati di `/eventi`, `EventoCard`, `TurnoPalloni`, `VotazioneMvp`, `VotoSocial` |
+| identità | `useGiocatoreInCampo()` è `null` per l'allenatore: niente risposta presenze, voti, pagelle, cacche, promemoria palloni                                                           |
+| server   | `destinatariSollecito()`, `promemoria-palloni.ts`, `apri-sondaggio.ts`                                                                                                           |
+| database | policy presenze e cacche «la propria riga» solo per `tipo = giocatore`; `evento_permette_voto()` rifiuta votante o votato allenatore                                             |
+| admin    | tab Squadra (conteggi, export CSI) e Profili (allenatori in un gruppo a parte, senza documenti né tesseramento)                                                                  |
+
+Il compleanno dell'allenatore resta visibile in Calendario (è un membro della squadra, non un
+giocatore).
+
+## Permessi (riepilogo)
+
+| Azione                                          | Giocatore  | Allenatore         | Admin              |
+| ----------------------------------------------- | ---------- | ------------------ | ------------------ |
+| Modificare nome e cognome                       | no         | sì, i propri       | tutti              |
+| Dati personali e foto profilo                   | i propri   | i propri (ridotti) | tutti (non i file) |
+| Documento, certificato, foto tessera            | i propri   | —                  | lettura/download   |
+| Avviso certificati in Home                      | il proprio | no                 | tutta la rosa      |
+| Creare/modificare/eliminare eventi, convocati   | no         | sì                 | sì                 |
+| Sollecitare le presenze                         | no         | sì                 | sì                 |
+| Promemoria palloni, notifica personalizzata     | no         | no                 | sì                 |
+| Rispondere alle presenze, votare, essere votato | sì         | no                 | sì (se giocatore)  |
+| Tab Stagione e Badge del profilo                | sì         | no                 | sì                 |
+| Tab Obiettivi e Badge di Squadra                | sì         | no                 | sì                 |
+| Badge e classifiche/dati sulle cacche           | sì         | no                 | sì                 |
+| Dashboard `/admin`                              | no         | no                 | sì                 |
+
+## Implementazione
+
+- **Migration M20** aggiunge `allenatore` all'enum `app_role`: sta da sola perché Postgres non
+  lascia usare un valore di enum nella transazione che lo crea.
+- **Migration M21**: colonna `giocatori_squadra.tipo`; `numero` nullabile solo per gli
+  allenatori (vincolo `giocatori_squadra_numero_giocatori`); trigger
+  `enforce_giocatori_squadra_update` con `tipo` bloccato e nome/cognome liberi solo sullo slot
+  del proprio allenatore; policy «L'allenatore aggiorna il proprio slot»; trigger
+  `sincronizza_ruolo_allenatore` che aggiunge o toglie la riga `allenatore` in `user_roles` al
+  collegamento, scollegamento, disattivazione o cambio di tipo; policy `eventi_app` admin o
+  allenatore; presenze, cacche e voti chiusi all'allenatore; promemoria evento aperti.
+- **Client**: nell'app `numero` resta un `number` (0 per l'allenatore, NULL a database). I
+  permessi (eventi, sollecito) leggono `user_roles` con `usePuoGestireEventi()`; cosa si vede
+  dipende dal tipo del proprio slot (`useSonoAllenatore()`), che è immediato.
+- **Admin**: «Aggiungi giocatore o allenatore» con il campo Tipo; per l'allenatore il form non
+  chiede numero e ruolo. Il tipo si sceglie solo alla creazione.
+
+## Scelte confermate
+
+- Riceve i promemoria degli eventi: sì.
+- Sollecita le presenze: sì. Promemoria palloni: no.
+- Badge e cacche: mai visibili all'allenatore, né classifiche né sondaggio.
+- In Squadra: nessuna sezione Staff; compare in Rosa come gli altri, con «Allenatore» al
+  posto del ruolo.
+- Vede le risposte presenze e le pagelle dei giocatori: sì, la lettura è già aperta a tutti
+  gli autenticati.

docs/modules/badge.md

@@ -1,6 +1,6 @@
 # Modulo — Badge
 
-**Stato:** implementato (v1.0), coerente con DD-007 e DD-008
+**Stato:** implementato, coerente con DD-007 e DD-008
 **File principali:** `src/lib/badges.ts`, `src/lib/badge-social.ts`,
 `src/components/crapp/CollezioneBadge.tsx`, `src/components/crapp/BadgeDrawer.tsx`,
 `src/components/crapp/CelebrazioneBadge.tsx`, `src/components/crapp/VotoSocial.tsx`
@@ -26,16 +26,45 @@ badge assegnati per voto dai compagni.
 ## Implementazione
 
 - `badgeDefs`/`badgeSegreti` (`badges.ts`) definiscono ogni badge con una funzione
-  `valore(g)` e soglie bronzo/argento/oro. Le fonti dato sono solo statistiche indipendenti
-  dal ruolo in campo: MVP, media pagelle, turni palloni, presenze, serie, infortuni,
-  ritardi, cacche — **mai** punti/ace/muri dello Scout Live, coerentemente con DD-008.
-- I badge segreti restano nascosti (icona lucchetto) finché non sbloccati.
+  `valore(g)` e tre soglie bronzo/argento/oro (elenco completo con fonte e soglie di ognuno in
+  "Elenco badge" sotto). Il grado è calcolato da `gradoRaggiunto()`/`statoBadge()`: soglie
+  inclusive, vince l'ultima raggiunta o superata. Per la maggior parte dei badge il valore è
+  già pronto: `Giocatore` arriva da `useRosa()` con presenze, palloni, serie, infortuni,
+  ritardi, cacche e media pagelle già calcolati da altri moduli — `badges.ts` si limita a
+  confrontarli con le soglie. Fanno eccezione, con logica propria descritta sotto, il
+  Pagellone, lo Sherpa dei palloni, l'MVP e i badge social.
+- **Badge Sherpa dei palloni** (`palloni`, in `badgeDefs`): `g.palloni` non è un contatore
+  incrementato a ogni evento, ma ricalcolato da `conteggioTurni()` (`palloni-core.ts`) su
+  `Giocatore.palloni` (`rosa.ts`) — meccanismo di turni/rotazione descritto per intero in
+  [palloni.md](palloni.md), non ripetuto qui. `rosa.ts` passa a `conteggioTurni()` **solo i
+  turni confermati** (`turniSalvati` da `useTurniPalloni()`), non l'output di
+  `completaTurni()`: le proposte automatiche di rotazione (usate altrove, per la UI di
+  `TurnoPalloni.tsx`) non contano per il badge, che premia solo chi ha davvero confermato di
+  aver portato i palloni. Conta solo per eventi già trascorsi (`e.data < oggi`, stesso
+  criterio delle presenze).
+- **Badge Pagellone** (`pagella`, in `badgeDefs`): a differenza degli altri badge da
+  contatore, richiede un numero minimo di voti (`VOTI_MINIMI_PAGELLA = 5`, `badges.ts`) prima
+  che `g.mediaVoto` conti — sotto soglia `valore(g)` è forzato a `0` (badge bloccato), anche
+  con una media altissima. Aggiunto perché senza minimo un singolo voto poteva
+  sbloccare/far sparire il badge senza nessuna significatività statistica (vedi
+  [pagelle.md](pagelle.md) per la pipeline voto → media, qui non ripetuta). Il numero di voti
+  ricevuti arriva in `Giocatore.votiPagella` (`rosa.ts`), popolato insieme a `mediaVoto` dalla
+  stessa `mediePagelle()`.
 - **Badge social** (`badge-social.ts`, tabella `badge_social_voti`): 5 categorie fisse per
   partita ("Compagno affidabile", "Miglior spirito di squadra", "Fair play", "Meme della
   partita", "Cuore del gruppo"), votabili una volta a testa per categoria/partita
-  (modificabile), con **auto-voto escluso sia in UI sia in logica** (`VotoSocial.tsx`). A
+  (modificabile), con **auto-voto escluso in interfaccia** (`VotoSocial.tsx`) e rifiutato dal
+  database (vincolo `badge_social_no_autovoto`, migration `m12_niente_autovoto`). A
   differenza delle [Pagelle](pagelle.md), qui non c'è alcun tentativo di anonimato:
   `votante_id`/`votato_id` sono entrambi visibili.
+- **Badge MVP** (`mvp`, in `badgeDefs`): l'unico badge normale la cui fonte non è un contatore
+  già pronto ma il risultato della votazione MVP tra compagni — meccanismo di voto (chi vota
+  chi, apertura, autovoto, RLS) descritto per intero in [mvp.md](mvp.md), non ripetuto qui.
+  Quello che serve per capire il badge: `mvpVintiPerGiocatore()` (`mvp-voti.ts`) conta, per
+  ogni giocatore, quante partite ha vinto con un **vantaggio netto** sul secondo (non il
+  totale dei voti ricevuti; in caso di parità la partita non conta per nessuno). `rosa.ts`
+  (`useRosa()`) scrive quel numero in `Giocatore.mvp`, che `badgeDefs` legge con
+  `valore: (g) => g.mvp` e confronta con le soglie 1/3/5 (bronzo/argento/oro).
 - `CollezioneBadge.tsx` mostra sbloccati, in progresso, badge social vinti e un contatore di
   badge segreti ancora da scoprire; `BadgeDrawer.tsx` il dettaglio di un singolo badge;
   `CelebrazioneBadge.tsx` l'overlay celebrativo alla prima visualizzazione di un badge nuovo.
@@ -45,6 +74,61 @@ badge assegnati per voto dai compagni.
 
 ---
 
+## Elenco badge
+
+Riferimento completo per chi lavora sul codice. **In app i 5 badge segreti restano nascosti
+finché non sbloccati** (fanno parte della sorpresa per i giocatori): elencarli qui, con le
+condizioni esatte, è una scelta deliberata per la documentazione tecnica, non una fuga di
+informazioni verso l'interfaccia.
+
+### Badge normali (gradi bronzo/argento/oro)
+
+Tutti calcolati come `valore(g)` confrontato con tre soglie crescenti; il grado è l'ultima
+soglia raggiunta o superata (soglie inclusive), oltre l'oro resta oro.
+
+| id                  | nome               | come si guadagna                                                                                                                     | soglie B/A/O    |
+| ------------------- | ------------------ | ------------------------------------------------------------------------------------------------------------------------------------ | --------------- |
+| `mvp`               | MVP                | partite vinte nettamente al voto MVP dei compagni (`g.mvp`, vedi pipeline sopra)                                                     | 1 / 3 / 5       |
+| `pagella`           | Pagellone          | media dei voti pagella ricevuti dai compagni a fine partita (`g.mediaVoto`), solo se ne ha ricevuti almeno `VOTI_MINIMI_PAGELLA` (5) | 6.5 / 7.5 / 8.5 |
+| `palloni`           | Sherpa dei palloni | quante volte hai confermato il turno palloni (`g.palloni`) — le proposte automatiche non ancora confermate non contano               | 3 / 6 / 10      |
+| `presenze`          | Presenza fissa     | totale presenze (presente o ritardo) a eventi/partite di sempre, non solo della stagione in corso (`g.presenze`)                     | 5 / 15 / 30     |
+| `serie-allenamenti` | Sempre in palestra | allenamenti consecutivi presenti (`g.serieAllenamenti`); un infortunio non spezza la serie, un'assenza sì                            | 3 / 6 / 10      |
+| `serie-conferme`    | Risposta lampo     | conferme di presenza consecutive date entro 24h dalla convocazione (`g.serieConferme`)                                               | 3 / 8 / 15      |
+
+### Badge segreti (booleani, nascosti finché non sbloccati)
+
+Stesso motore dei normali ma con soglie `{bronzo:1, argento:1, oro:1}`: `valore(g)` è 0 o 1,
+quindi il badge è "trovato o no", mai graduato. In UI compaiono con icona lucchetto finché non
+sbloccati. Attenzione se si tocca `gradoRaggiunto()`: con le tre soglie tutte uguali a 1, il
+grado effettivo che risulta una volta sbloccato è sempre **`"oro"`** (l'ultimo che il ciclo
+`for` sovrascrive), mai `"bronzo"` — l'unica cosa che conta davvero per questi badge è
+`grado !== null`, non il suo valore, ed è così che li legge `badgeSegretiSbloccati()`.
+
+| id              | nome                        | condizione esatta                                                                                                                                            |
+| --------------- | --------------------------- | ------------------------------------------------------------------------------------------------------------------------------------------------------------ |
+| `s-tiebreak`    | Uomo tie-break              | almeno 2 MVP **e** media pagella ≥ 8, sopra la soglia minima di voti di Pagellone (`g.mvp >= 2 && g.votiPagella >= VOTI_MINIMI_PAGELLA && g.mediaVoto >= 8`) |
+| `s-mai-forfait` | Mai un forfait              | almeno 10 conferme rapide consecutive **e** almeno 15 presenze (`g.serieConferme >= 10 && g.presenze >= 15`)                                                 |
+| `s-infermeria`  | Cliente VIP dell'Infermeria | almeno 3 eventi saltati per infortunio (`g.infortuni >= 3`)                                                                                                  |
+| `s-ritardi`     | Aspettate, arrivo!          | almeno 5 ritardi a eventi (`g.ritardi >= 5`)                                                                                                                 |
+| `s-cacche`      | Trono di ferro              | almeno 3 partite (campionato o amichevole) con 3 o più cacche pre-gara dichiarate (`g.cacche >= 3`)                                                          |
+
+### Badge social (votati dai compagni, 5 categorie per partita)
+
+Non hanno gradi: si "vince" o non si vince una categoria in una partita. `vincitoreCategoria()`
+richiede un vantaggio netto sul secondo classificato, in parità nessun vincitore.
+`badgeSocialVinti()` conta quante partite ha vinto ciascun giocatore in ogni categoria (non i
+voti ricevuti).
+
+| id           | nome                       | cosa premia                                      |
+| ------------ | -------------------------- | ------------------------------------------------ |
+| `affidabile` | Compagno affidabile        | sempre presente, sempre sul pezzo                |
+| `spirito`    | Miglior spirito di squadra | carica il gruppo dal primo all'ultimo punto      |
+| `fairplay`   | Fair play                  | rispetto per compagni, avversari e arbitro       |
+| `meme`       | Meme della partita         | la scena più memorabile della partita            |
+| `cuore`      | Cuore del gruppo           | chi tiene unita la squadra anche fuori dal campo |
+
+---
+
 ## Regole rispettate
 
 - **DD-007**: nessuna tabella `badge_sbloccati`, tutto calcolato a runtime dai dati
@@ -54,6 +138,285 @@ badge assegnati per voto dai compagni.
 
 ---
 
+## Copertura test
+
+Verifica badge per badge (fatta rileggendo codice e test riga per riga, non solo per
+categoria). Due bug trovati in una sessione di audit dedicata su tutti i 16 badge (dettagli
+nelle sezioni sotto e in "Problemi noti"): `s-tiebreak` non applicava la soglia minima di voti
+di Pagellone (**corretto**), `s-cacche` prometteva "partite di campionato" senza che il codice
+lo verificasse mai (**la descrizione è stata corretta**, il comportamento — qualunque partita
+conta — era già quello voluto). Tutti e 16 i badge hanno ora copertura unit **e** integration
+end-to-end completa.
+
+**Badge normali** — `badges.ts` testa la propria funzione pura (soglia → grado,
+`badges.test.ts`) sull'output di altri moduli:
+
+- `mvp`: soglie inclusive verificate (1→bronzo, 3→argento, 99→resta oro,
+  `badges.test.ts:44-48`), progresso a metà (`:52-56`).
+- `pagella`: caso critico delle soglie decimali senza arrotondamento per eccesso — 6.4 →
+  nessun grado, 6.5 → bronzo (`badges.test.ts:65-67`); un vero 6.49 non diventa "quasi
+  bronzo". Più la soglia minima di voti (vedi sotto).
+- `palloni`: soglie 3/6/10 testate esplicitamente (bronzo/argento/oro, confine incluso e
+  oltre l'oro resta oro, `badges.test.ts:94-104`), oltre a un caso di progresso non tondo
+  (5/6 → 83%). Pipeline end-to-end sotto, come `mvp`/`pagella`.
+- `presenze`: soglie 5/15/30 testate esplicitamente (confine incluso, oltre l'oro resta oro,
+  `badges.test.ts:108-116`). Pipeline end-to-end sotto, come `mvp`/`pagella`/`palloni`.
+- `serie-allenamenti`: soglie 3/6/10 testate esplicitamente (confine incluso, oltre l'oro
+  resta oro, `badges.test.ts:118-126`). Pipeline end-to-end sotto, come gli altri badge da
+  tabella.
+- `serie-conferme`: soglie 3/8/15 testate esplicitamente (confine incluso, oltre l'oro resta
+  oro, `badges.test.ts:128-136`), oltre agli invarianti generali e a
+  `collezioneBadge`/`prossimoTraguardo` con valori al massimo. Pipeline end-to-end sotto, come
+  gli altri badge da tabella.
+
+`mvp`, `pagella`, `palloni`, `presenze`, `serie-allenamenti` e `serie-conferme` sono le
+eccezioni con integration dedicato (sotto) perché la loro fonte passa da una tabella di
+voto/turni/presenze
+letta e ricalcolata dal vivo, non da un contatore già pronto altrove.
+
+**Badge segreti** — ognuno testato con la propria condizione esatta e il confine appena sotto:
+`s-tiebreak` (mvp:1 non basta, mediaVoto 7.9 non basta, sotto `VOTI_MINIMI_PAGELLA` voti non
+basta nemmeno con media alta — vedi il bug fix sotto), `s-mai-forfait` (ogni soglia isolata al
+confine, non solo "entrambe servono"), `s-infermeria` (2 infortuni non bastano), `s-ritardi` (4
+ritardi non bastano — gap colmato in questa sessione), `s-cacche` (2 cacche non bastano).
+Copertura unit completa **e** integration dedicato per tutti e 5 (aggiunto in questa sessione,
+vedi sotto): i dati sorgente hanno già i propri test di integrazione nei rispettivi moduli, ma
+nessuno prima arrivava fino a `statoBadge()` sul segreto stesso con dati scritti a database.
+
+**Badge MVP — pipeline end-to-end** (aggiunta in una sessione dedicata a completare la
+copertura di questo badge):
+
+- Unit: `badges.test.ts` (soglie/gradi) + `mvp-voti.test.ts` (conteggio partita, vincitore con
+  vantaggio netto, parità che non assegna, apertura voto 2h dopo il fischio d'inizio).
+- Integration (`npx supabase start` richiesto):
+  - `scritture.test.ts` — semantica dell'`upsert` di `mvp_voti` (un voto per
+    partita/votante, l'ultimo sostituisce) e rifiuto dell'autovoto a database
+    (`mvp_no_autovoto`).
+  - `permessi.test.ts` — RLS di `m11`: il proprio voto MVP si registra (caso positivo), non
+    si può votare a nome di un altro (caso negativo); RLS di `m13` (sotto): un votante o un
+    votato non convocati vengono rifiutati.
+  - `mvp-badge.test.ts` — end-to-end reale: scrive voti su `mvp_voti`, rilegge via REST come
+    fa `useVotiMvp()`, calcola `mvpVintiPerGiocatore()` e verifica che `statoBadge()` assegni
+    il grado corretto (bronzo a 1-2 vittorie nette, argento a 3), incluso un pareggio che non
+    deve contare come vittoria.
+
+**Badge Pagellone — pipeline end-to-end e soglia minima di voti** (stessa sessione di sopra,
+dopo l'analisi che ha trovato il gap "un voto solo sblocca il badge"):
+
+- Unit: `badges.test.ts:69-88` — sotto `VOTI_MINIMI_PAGELLA` (5) il badge resta bloccato anche
+  con `mediaVoto: 10`; esattamente a 5 la media torna a contare; sopra soglia valgono le
+  normali soglie di grado (`mediaVoto: 6.5` con 5 voti → bronzo, non oro).
+- Integration (`npx supabase start` richiesto):
+  - `scritture.test.ts` — semantica dell'`upsert` di `pagelle_voti` e rifiuto dell'autovoto
+    (`pagelle_no_autovoto`), già presente prima di questa sessione.
+  - `permessi.test.ts` — RLS di `m13`: un votante o un votato non convocati vengono rifiutati
+    (per tutte e tre le tabelle di voto, non solo le pagelle), e un voto pagella dopo
+    `pagelle_chiuse` viene rifiutato anche a database, non solo nascosto in UI.
+  - `pagella-badge.test.ts` (nuovo) — end-to-end reale: scrive voti su `pagelle_voti`, rilegge
+    via REST come fa `usePagelle()`, calcola `mediePagelle()` e verifica che `statoBadge()`
+    tenga il badge bloccato sotto soglia, lo sblocchi al voto minimo con il grado giusto, e
+    applichi le soglie normali sopra soglia.
+
+**Badge Sherpa dei palloni — pipeline end-to-end, ora senza contare le proposte non
+confermate** (analisi dedicata: trovato e sistemato il gap "le proposte contano", che
+gonfiava il badge di turni mai confermati da nessuno — vedi "Problemi noti da sistemare"):
+
+- Unit: `badges.test.ts:93-104` — soglie 3/6/10 (confine incluso, oltre l'oro resta oro) +
+  `palloni-core.test.ts`, già completo prima di questa sessione (`completaTurni()`,
+  `conteggioTurni()`, rotazione bilanciata su un giro completo di partite, allenamenti mai
+  proposti in automatico, turno di un giocatore non più in rosa che non rompe il conteggio).
+- Integration (`npx supabase start` richiesto):
+  - `scritture.test.ts` — un turno resta uno per evento (l'upsert sostituisce, non aggiunge).
+  - `palloni-badge.test.ts` — end-to-end reale: scrive eventi e turni **solo parzialmente
+    confermati** su `eventi_app`/`turni_palloni`, rilegge via REST come fa `fetchTurni()`/
+    `daRiga()` e passa `turniSalvati` (solo confermati, mai l'output di `completaTurni()`) a
+    `conteggioTurni()` fino a `statoBadge()`: dimostra che un evento passato senza turno
+    confermato **non conta per nessuno**, anche se un algoritmo di rotazione (usato altrove
+    per la UI) lo proporrebbe automaticamente; verifica anche che un evento futuro non conti,
+    pur avendo già una conferma.
+
+**Badge Presenza fissa — pipeline end-to-end** (analisi dedicata: nessun bug trovato; a
+differenza di MVP/pagelle/badge social, per questo badge **non serve** l'estensione RLS di
+M13 — vedi sotto):
+
+- Unit: `badges.test.ts:108-116` — soglie 5/15/30 (confine incluso, oltre l'oro resta oro) +
+  `presenze.test.ts`, già molto completo prima di questa sessione (`contaPresenzeGiocatore()`
+  con ritardo che conta come presenza, denominatore uguale per tutti, eventi futuri esclusi,
+  filtro sui convocati, solo partite/allenamenti).
+- Integration (`npx supabase start` richiesto):
+  - `obiettivi.test.ts` — copre già `contaPresenzeGiocatore()` end-to-end per l'obiettivo
+    "250 presenze complessive" (o3), la stessa funzione usata dal badge.
+  - `presenze-badge.test.ts` (nuovo) — end-to-end reale sul badge: scrive eventi e risposte
+    su `eventi_app`/`risposte_presenze`, rilegge via REST come fa `fetchPresenze()`/`daRiga()`
+    e verifica che `statoBadge()` attraversi le tre soglie con dati veri (incluso un ritardo
+    che conta come presenza e un'assenza che non conta). Dimostra anche che una risposta
+    scritta per un evento senza convocazione **non conta comunque**, perché
+    `contaPresenzeGiocatore()` filtra già per `convocati` lato applicazione — a differenza di
+    MVP/pagelle/badge social, qui non serve una policy RLS aggiuntiva: il filtro è nella
+    funzione pura che il badge consuma, non solo in UI.
+
+**Badge Sempre in palestra — pipeline end-to-end** (analisi dedicata: nessun bug trovato).
+Stessa fonte dati di `presenze` (`risposte_presenze`) ma logica diversa: non un totale, una
+**serie consecutiva** che un buco azzera e un infortunio congela. Anche qui, come per
+`presenze`, non serve nessuna estensione RLS: il filtro sui convocati è già nella funzione
+pura.
+
+- Unit: `badges.test.ts:118-126` — soglie 3/6/10 (confine incluso, oltre l'oro resta oro) +
+  `presenze.test.ts`, già completo prima di questa sessione su `serieConsecutiva()` (buco che
+  azzera, infortunio che congela invece di azzerare, nessuna risposta vale come buco,
+  convocati che non spezzano la serie di chi non era coinvolto).
+- Integration (`npx supabase start` richiesto):
+  - `serie-allenamenti-badge.test.ts` (nuovo) — end-to-end reale: scrive allenamenti e
+    risposte su `eventi_app`/`risposte_presenze`, rilegge via REST e verifica che
+    `statoBadge()` attraversi bronzo/argento/oro con presenze consecutive vere, che
+    un'assenza dopo 10 presenze di fila azzeri tutto (torna a nessun grado), e — separatamente
+    — che un infortunio **non** azzeri la serie ma la lasci congelata (3 presenze vere,
+    un infortunio nel mezzo saltato dal conteggio, poi ancora presente: la serie resta a 3,
+    non riparte da 1).
+
+**Badge Risposta lampo — pipeline end-to-end** (analisi dedicata: nessun bug trovato nella
+logica di calcolo; l'unico limite è quello già noto e documentato sui dati pre-`m9`, vedi
+"Limiti noti"). Il badge dipende da `serieConferme()`, che passa da due colonne facili da
+confondere fra loro (`creato_il`/`risposto_il`, vedi [serie-presenze.md](serie-presenze.md)):
+un integration test aggiunto per verificare che la mappatura verso `creatoIl`/`tempi` regga con
+dati reali, non solo con timestamp scelti a mano — cosa che i test unitari, che non toccano il
+database, non possono garantire.
+
+- Unit: `badges.test.ts:128-136` — soglie 3/8/15 (confine incluso, oltre l'oro resta oro) +
+  `presenze.test.ts`, esteso in questa sessione su `serieConferme()`: oltre al buco che azzera
+  e all'evento senza `creatoIl` che viene saltato (già presenti), ora anche un evento convocato
+  solo per un altro giocatore che non spezza la serie, partite e allenamenti sommati nella
+  stessa serie, il confronto inclusivo esattamente a 24h (dentro conta, un secondo oltre
+  azzera), e un evento futuro che non entra ancora nel calcolo.
+- Integration (`npx supabase start` richiesto):
+  - `serie-conferme-badge.test.ts` (nuovo) — end-to-end reale: scrive eventi con `creato_il`
+    esplicito e risposte con `risposto_il` esplicito su `eventi_app`/`risposte_presenze`,
+    rilegge via REST come fa `daRiga()`/`fetchPresenze()` e verifica che `statoBadge()`
+    attraversi bronzo/argento/oro con conferme rapide vere, che una risposta arrivata oltre le
+    24h azzeri tutto anche dopo 15 conferme di fila, e — separatamente — che partite e
+    allenamenti si sommino nella stessa serie senza bisogno di un filtro per tipo.
+
+**Badge Cliente VIP dell'Infermeria e Aspettate, arrivo! — pipeline end-to-end** (analisi
+dedicata: nessun bug trovato). Stessa fonte (`contaInfortuni()`/`contaRitardi()` in
+`src/lib/infortuni.ts`, entrambe sopra la stessa `contaStato()` privata) e stessa struttura di
+`serie-allenamenti`/`serie-conferme`, ma senza serie: un contatore semplice di eventi passati.
+
+- Unit: `badges.test.ts` (soglie 3 e 5, confine appena sotto) + `infortuni.test.ts`, esteso in
+  questa sessione con un giocatore che ha **sia** un infortunio **sia** un ritardo (su eventi
+  diversi): i due conteggi restano indipendenti, nessuno "ruba" voci all'altro.
+- Integration (`npx supabase start` richiesto):
+  - `s-infermeria-badge.test.ts` / `s-ritardi-badge.test.ts` (nuovi) — end-to-end reali: scrivono
+    eventi e risposte "infortunato"/"ritardo" su `eventi_app`/`risposte_presenze`, rileggono via
+    REST e verificano che il segreto resti bloccato appena sotto soglia e si sblocchi
+    esattamente al confine (3 infortuni, 5 ritardi).
+
+**Badge Trono di ferro — pipeline end-to-end, descrizione corretta** (analisi dedicata: trovato
+un disallineamento fra descrizione e codice, **risolto aggiornando il testo**, non la logica —
+vedi "Problemi noti" più sotto per il perché). `statisticheCacche()` (`src/lib/cacche.ts`) non
+ha mai distinto partite di campionato da amichevoli: contava (e conta ancora) qualunque partita
+con 3+ cacche dichiarate. La vecchia descrizione del badge prometteva "partite di campionato",
+cosa che il codice non ha mai verificato — corretta in "partite (campionato o amichevole)".
+
+- Unit: `badges.test.ts` (soglia 3, confine appena sotto — gap colmato in questa sessione) +
+  `cacche.test.ts` (già completo su `giornateTop`).
+- Integration (`npx supabase start` richiesto):
+  - `s-cacche-badge.test.ts` (nuovo) — end-to-end reale: scrive 2 giornate da record su partite
+    di campionato e una su un'amichevole, dimostrando con dati veri che l'amichevole conta
+    esattamente come le altre — pin del comportamento attuale, così chi in futuro reintroduce un
+    filtro sul campionato deve accorgersene qui, non scoprirlo in produzione.
+
+**Badge Uomo tie-break — pipeline end-to-end, bug corretto** (analisi dedicata: trovato e
+sistemato il gap "un voto pagella solo sblocca il segreto insieme a 2 MVP"). Il segreto usa
+`g.mediaVoto`, lo stesso campo del badge normale `pagella` — che però lo azzera sotto
+`VOTI_MINIMI_PAGELLA` (5) voti ricevuti, proprio per evitare che un singolo voto sblocchi/tolga
+il badge senza significatività statistica. `s-tiebreak` non applicava lo stesso filtro: ora sì
+(`g.mvp >= 2 && g.votiPagella >= VOTI_MINIMI_PAGELLA && g.mediaVoto >= 8`).
+
+- Unit: `badges.test.ts` — sotto la soglia minima di voti il segreto resta bloccato anche con
+  media 8 e 2 MVP; un solo MVP non basta (isolato dal resto).
+- Integration (`npx supabase start` richiesto):
+  - `s-tiebreak-badge.test.ts` (nuovo) — end-to-end reale: scrive voti MVP e pagella veri,
+    dimostra che un solo voto pagella (media alta, 2 MVP) NON sblocca il segreto, e che il quinto
+    voto lo sblocca — il fix verificato con la stessa pipeline `mvp_voti`/`pagelle_voti` → REST →
+    `mvpVintiPerGiocatore()`/`mediePagelle()` → `statoBadge()` che userebbe l'app.
+
+**Badge Mai un forfait — pipeline end-to-end** (analisi dedicata: nessun bug trovato). Unico
+segreto a combinare due statistiche indipendenti (`serieConferme()` e
+`contaPresenzeGiocatore()`), entrambe già testate a fondo nei rispettivi moduli.
+
+- Unit: `badges.test.ts`, esteso in questa sessione con ogni soglia isolata al confine
+  (`serieConferme` appena sotto con `presenze` abbondanti, e viceversa), non solo "insieme non
+  bastano".
+- Integration (`npx supabase start` richiesto):
+  - `s-mai-forfait-badge.test.ts` (nuovo) — end-to-end reale: scrive eventi con `creato_il` e
+    risposte con `risposto_il` veri, verifica che il segreto resti bloccato a 9/9 e si sblocchi a
+    15/15, e che una risposta lenta azzeri la serie di conferme **senza** azzerare le presenze
+    già accumulate (le due statistiche restano indipendenti anche a database).
+
+**Badge social** — nessuna delle 5 categorie ha logica _propria_ nel codice: l'id è solo una
+chiave di raggruppamento, `conteggioCategoria`/`vincitoreCategoria`/`badgeSocialVinti` sono
+identici per tutte (`badge-social.ts:107-158`). Testare a fondo 2-3 categorie copre l'intero
+meccanismo:
+
+- Unit (`badge-social.test.ts`): conteggio isolato per match+categoria (`:29-32`), vantaggio
+  netto/parità → nessun vincitore (`:38-41`), vittorie multi-partita (`badgeSocialVinti`, g2
+  vince in `m1` e `m2` → `{affidabile: 2}`, `:48`), zero voti → zero badge (`:51`). Estesi in
+  questa sessione: un voto totale solo basta a vincere, una parità a 3 candidati (i primi due
+  pari, il terzo staccato) resta senza vincitore, categorie diverse nella stessa partita non si
+  mischiano in `badgeSocialVinti()`.
+- Integration: upsert/sostituzione voto per categoria (`scritture.test.ts:170-202`), autovoto
+  rifiutato — doppia barriera UI + database (`scritture.test.ts:124-148`), RLS `m11` — un
+  giocatore firma solo il proprio voto (`permessi.test.ts:344-369`).
+  - `badge-social.test.ts` (nuovo, in `test/integration/`) — end-to-end reale sulle **5
+    categorie effettive** di `categorieSocial` (non più solo 2-3, e non più le categorie
+    inventate di `scritture.test.ts`): scrive voti veri su `badge_social_voti`, dimostra che
+    tutte e 5 si contano e si vincono allo stesso modo, e che una parità su una categoria non
+    tocca il conteggio delle altre 4 nella stessa partita.
+
+### Riepilogo per badge
+
+| #   | id                  | tipo    | test unit                             | test integration                              |
+| --- | ------------------- | ------- | ------------------------------------- | --------------------------------------------- |
+| 1   | `mvp`               | normale | ✅                                    | ✅ (`scritture`, `permessi`, `mvp-badge`)     |
+| 2   | `pagella`           | normale | ✅ (incl. soglia minima voti)         | ✅ (`scritture`, `permessi`, `pagella-badge`) |
+| 3   | `palloni`           | normale | ✅                                    | ✅ (`scritture`, `palloni-badge`)             |
+| 4   | `presenze`          | normale | ✅                                    | ✅ (`obiettivi`, `presenze-badge`)            |
+| 5   | `serie-allenamenti` | normale | ✅                                    | ✅ (`serie-allenamenti-badge`)                |
+| 6   | `serie-conferme`    | normale | ✅ (limite noto sotto)                | ✅ (`serie-conferme-badge`)                   |
+| 7   | `s-tiebreak`        | segreto | ✅ (bug corretto, vedi sotto)         | ✅ (`s-tiebreak-badge`)                       |
+| 8   | `s-mai-forfait`     | segreto | ✅                                    | ✅ (`s-mai-forfait-badge`)                    |
+| 9   | `s-infermeria`      | segreto | ✅                                    | ✅ (`s-infermeria-badge`)                     |
+| 10  | `s-ritardi`         | segreto | ✅                                    | ✅ (`s-ritardi-badge`)                        |
+| 11  | `s-cacche`          | segreto | ✅ (descrizione corretta, vedi sotto) | ✅ (`s-cacche-badge`)                         |
+| 12  | `affidabile`        | social  | ✅                                    | ✅ (`scritture`, `permessi`, `badge-social`)  |
+| 13  | `spirito`           | social  | ✅ (meccanismo generico)              | ✅ (meccanismo generico, `badge-social`)      |
+| 14  | `fairplay`          | social  | ✅ (meccanismo generico)              | ✅ (meccanismo generico, `badge-social`)      |
+| 15  | `meme`              | social  | ✅                                    | ✅ (`badge-social`)                           |
+| 16  | `cuore`             | social  | ✅                                    | ✅ (autovoto, `badge-social`)                 |
+
+---
+
+## Problemi noti da sistemare
+
+- **`badgeSbloccati()` morta** (`badges.ts:283-285`): duplica esattamente
+  `collezioneBadge(g).sbloccati`. Zero riferimenti fuori dalla propria definizione, né in
+  `src/` né nei test. Da rimuovere o documentare perché esiste (es. uso futuro/esterno).
+- **`categoria` senza vincolo DB** in `badge_social_voti`: la colonna è `text NOT NULL` senza
+  CHECK o FK verso i 5 id di `categorieSocial`
+  (`supabase/migrations/20260803140647_affa1c11-fa92-450f-9f00-02d87195a6d9.sql:4`). I test
+  stessi lo dimostrano scrivendo categorie inesistenti (`"sorriso"`/`"urlo"`,
+  `scritture.test.ts`). Non sfruttabile da un utente normale (l'app manda solo le 5 categorie
+  valide), stesso tipo di gap "solo applicativo, non a DB" del punto sotto sul votato/convocato.
+- **`conteggioTurni()` non filtra per tipo evento** (`palloni-core.ts:70-82`), a differenza di
+  `eventiPalloni()` che include solo partite e allenamenti. Un turno registrato per errore su
+  un evento fuori dal dominio "richiede i palloni" conterebbe comunque per il badge Sherpa dei
+  palloni. Rischio teorico basso — l'UI non offre questa combinazione, dato che
+  `TurnoPalloni`/`completaTurni()`/i promemoria ora si fermano a `eventiPalloni()` — comportamento
+  pinnato da un test dedicato in `palloni-core.test.ts` così che un domani, se serve stringere,
+  non lo si scopra rompendo un test esistente ma leggendo perché quel test lo dimostrava apposta.
+
+---
+
 ## Limiti noti
 
 - **Dipendenza dal modulo [Serie](serie-presenze.md)**: i badge "Sempre in palestra",
@@ -63,11 +426,39 @@ badge assegnati per voto dai compagni.
   risposte precedenti a `m9`: su quelle righe la serie è un'approssimazione.
 - Nessuno storico dei badge sbloccati: se cambiano le soglie o i dati sorgente, un badge già
   "ottenuto" può sparire o apparire retroattivamente.
-- RLS permissiva su `badge_social_voti` (stesso schema di `mvp_voti`): nessun controllo
-  server-side che `votante_id` coincida con l'utente autenticato.
 - Notifiche "nuovo badge" solo locali al dispositivo (localStorage), si ripetono cambiando
   browser o dispositivo.
 
+**Risolto (analisi del badge Sherpa dei palloni)**: prima `g.palloni` (`rosa.ts`) includeva
+anche i turni che `completaTurni()` propone in automatico per un evento passato senza
+assegnazione esplicita, non solo quelli confermati in `turni_palloni` — un giocatore poteva
+vedere avanzare il badge senza aver mai confermato nulla, semplicemente perché l'algoritmo di
+rotazione l'aveva proposto. Ora `rosa.ts` passa a `conteggioTurni()` solo `turniSalvati` (i
+turni confermati), non l'output di `completaTurni()`: quest'ultimo resta in uso solo per la
+UI di rotazione (`TurnoPalloni.tsx`, `PromemoriaPalloni.tsx`), mai per il conteggio del badge.
+Dimostrato con dati veri in `palloni-badge.test.ts`. [palloni.md](palloni.md) aggiornato di
+conseguenza.
+
+**Risolto (audit completo dei 16 badge)**: `s-tiebreak` (`badges.ts:139`) usava `g.mediaVoto`
+senza applicare `VOTI_MINIMI_PAGELLA`, a differenza del badge normale `pagella` che usa lo
+stesso campo — un giocatore con un solo voto pagella altissimo e 2 MVP poteva sbloccare il
+segreto senza che la media fosse statisticamente significativa. Ora `s-tiebreak` richiede anche
+`g.votiPagella >= VOTI_MINIMI_PAGELLA`, dimostrato con dati reali in `s-tiebreak-badge.test.ts`.
+Il badge `s-cacche` prometteva invece "partite di **campionato**" nella descrizione senza che
+nessuna funzione della pipeline lo verificasse mai (`statisticheCacche()` conta qualunque
+partita) — qui si è scelto di correggere la descrizione, non il codice: il comportamento
+"qualunque partita conta" resta quello voluto, pinnato in `s-cacche-badge.test.ts`.
+
+**Risolto (M13, `20260908120000_m13_convocati_e_pagelle_chiuse.sql`)**: prima la policy di M11
+garantiva solo che il voto fosse firmato con il proprio `votante_id`, non che il votato (né il
+votante) fossero convocati per quella partita — filtro solo applicativo, aggirabile scrivendo
+direttamente su PostgREST. Ora `evento_permette_voto()` lo verifica anche a database per
+`pagelle_voti`, `mvp_voti` e `badge_social_voti` (convocati vuoto = tutta la rosa, stessa
+convenzione di `convocatiEvento()`), e per le sole pagelle verifica anche che
+`eventi_app.pagelle_chiuse` sia falso — prima un voto "fuori tempo" restava tecnicamente
+possibile bypassando l'interfaccia. Le policy admin restano permissive: un amministratore può
+ancora correggere un voto anche fuori convocazione o dopo la chiusura.
+
 ---
 
 ## Evoluzioni possibili
@@ -75,3 +466,7 @@ badge assegnati per voto dai compagni.
 - Sincronizzare lo stato "visto" su Supabase invece che solo in localStorage.
 - Verificare sui dati di stagione che i tre badge legati alle serie si sblocchino davvero,
   ora che le serie sono calcolate.
+- Rimuovere `badgeSbloccati()` (codice morto) o documentarne lo scopo.
+- Aggiungere un vincolo (CHECK o FK) sulla colonna `categoria` di `badge_social_voti`.
+- Se un domani serve restringere `conteggioTurni()` per tipo evento (vedi "Problemi noti"),
+  aggiornare anche il test che oggi ne pinna il comportamento permissivo.

docs/modules/calendario.md

@@ -0,0 +1,80 @@
+# Modulo — Calendario ed Eventi
+
+**Stato:** implementato
+**File principali:** `src/lib/eventi.ts`, `src/lib/eventi.server.ts`, `src/lib/calendario.ts`
+(griglia mensile condivisa), `src/routes/calendario.tsx` (vista mensile, tutti),
+`src/routes/eventi.tsx` (creazione/modifica, admin e allenatori), `src/components/crapp/EventoCard.tsx`
+(card condivisa), `src/routes/allenamento.$id.tsx`, `src/routes/partita.$id.tsx`,
+`src/routes/evento.$id.tsx` (schede di dettaglio, una per tipo)
+**Test:** `test/unit/eventi.test.ts`, `test/unit/calendario.test.ts`
+
+---
+
+## Obiettivo
+
+Un unico calendario condiviso per allenamenti, partite, amichevoli ed eventi extra
+(riunioni, cene di squadra...), al posto di messaggi sparsi in chat. Ogni evento in
+`eventi_app` diventa il punto a cui si agganciano presenze, convocazioni, MVP, pagelle,
+scout e turno palloni — la maggior parte degli altri moduli dipende da un `evento.id`.
+
+## Due schermate, due pubblici
+
+- **`/calendario`** — vista mensile per tutta la squadra, sola lettura. Mostra allenamenti,
+  partite, eventi ed **eventi virtuali** per i compleanni della rosa (`compleanniEventi()`
+  in `eventi.ts`, generati a runtime dall'anagrafica di `useAnagraficaRosa({ conAllenatori:
+true })` — ci sono anche gli allenatori, DD-034 — non righe
+  vere di `eventi_app`): la spunta della vista `giorniIT`/`mesiIT` colora la cella per tipo
+  di evento, i giorni con più eventi si dividono lo spazio.
+- **`/eventi`** — "Gestione eventi", riservata ad amministratori e allenatori
+  (`usePuoGestireEventi()`, [DD-034](../DESIGN_DECISIONS.md#dd-034--lallenatore-è-uno-slot-della-squadra-con-tipo-diverso-non-un-giocatore)):
+  crea, modifica ed elimina un evento, sceglie i convocati tra i soli giocatori
+  (`convocatiEvento()`, vuoto = tutta la rosa). Da qui si distingue "partita" da "amichevole" tramite il flag `campionato`
+  (`categoriaEvento()`/`daCategoria()` in `eventi.ts` convertono tra la categoria mostrata
+  in interfaccia e la coppia `{ tipo, campionato }` salvata nel database). La pagina mostra
+  solo una griglia mensile (stessa logica di `/calendario`, tramite le funzioni condivise di
+  `src/lib/calendario.ts`), che si scorre di mese in mese con le frecce o con lo swipe, con
+  la stessa fisica a molla di `/calendario`. Ogni giorno è cliccabile, anche senza eventi, e
+  apre un drawer con gli eventi di quel giorno (modifica/elimina) e un bottone "Nuovo evento
+  in questo giorno" che apre il form con la data già precompilata: creare, modificare ed
+  eliminare passano solo da lì. Nel form il giorno si legge come testo fisso e resta da
+  scegliere solo l'ora; il campo data compare solo toccando «Cambia», per spostare l'evento. Fino a 0.9.2 sotto la griglia c'era anche la lista
+  cronologica di tutti gli eventi, tolta perché ripeteva il calendario
+  ([DD-033](../DESIGN_DECISIONS.md#dd-033--gestione-eventi-solo-calendario-giorno-fissato-dal-tocco)).
+
+Entrambe leggono la stessa cache (`useEventi()`, `EVENTI_KEY`, `staleTime` 10 minuti: il
+calendario cambia raramente). `EventoCard.tsx` è la card riusata da entrambe le schermate;
+`linkPerEvento()` decide dove porta il click — `/partita/$id` per una partita (con
+`/partita-csi/$id` come alternativa "solo CSI" quando non c'è un evento collegato, vedi
+`collegamento-csi.md`), `/allenamento/$id` per un allenamento, `/evento/$id` per un evento
+extra-campo, nessun link per gli eventi virtuali (compleanni), che non hanno una riga in
+`eventi_app`.
+
+Le tre schede di dettaglio (`allenamento.$id.tsx`, `partita.$id.tsx`, `evento.$id.tsx`)
+condividono la stessa struttura — intestazione, note, conferme, `RosaPresenze` per l'elenco
+nominativo di chi ha risposto — con `TurnoPalloni` in più per allenamenti e partite (vedi
+`palloni.md`, non pertinente per gli eventi extra-campo) e lo stato `infortunato` escluso
+dalle risposte solo sulla scheda evento (vedi `presenze.md`).
+
+## Lettura lato server
+
+`src/lib/eventi.server.ts` (`leggiEventi()`) è la stessa conversione riga→modello di
+`eventi.ts`, ma con `supabaseAdmin` per le route API che girano senza sessione utente (es.
+`sollecita-presenze.ts`, `promemoria-palloni.ts` — vedi `presenze.md` e `palloni.md`) e per
+`notifiche-smart.ts`, che decide i promemoria da mandare in base agli eventi del giorno.
+
+---
+
+## Limiti noti
+
+1. **Cancellare un evento è distruttivo per tutto ciò che vi era agganciato.** Un trigger
+   (`m14_pulizia_dati_evento_cancellato`,
+   [DD-029](../DESIGN_DECISIONS.md#dd-029--cancellare-un-evento-pulisce-a-cascata-i-dati-collegati))
+   pulisce a cascata presenze, cacche, voti MVP/pagelle/badge social, turni palloni e scout
+   di quell'evento: non è recuperabile con un annulla, e prima di M14 quelle righe restavano
+   orfane nel database (bonificate una tantum da M15/M16, vedi `PROJECT_STATE.md`).
+2. **Nessuna creazione automatica degli eventi partita dal calendario CSI.** Le gare
+   ufficiali arrivano già come dati (`getEventsByTeamId.php`, vedi `collegamento-csi.md`),
+   ma un amministratore deve comunque creare a mano l'evento corrispondente in `/eventi`
+   perché esistano convocazioni, presenze, MVP e pagelle per quella partita — altrimenti la
+   gara resta visibile solo nello storico CSI, con un dettaglio "solo CSI" più povero
+   (`/partita-csi/$id` invece di `/partita/$id`). In `docs/ROADMAP.md` sotto "Prossimo".

docs/modules/collegamento-csi.md

@@ -1,7 +1,8 @@
 # Modulo — Collegamento CSI
 
 **Stato:** implementato (stagione 2025/26)
-**Route interessata:** `/classifica`
+**Route interessate:** `/classifica` (classifica e storico), `/partita/$id` e `/partita-csi/$id`
+(dettaglio di una gara: formazioni e scontri diretti)
 
 ---
 
@@ -21,26 +22,134 @@ Il portale **non espone un'API pubblica documentata**. Vengono usati gli stessi
 che il sito chiama internamente via ajax: sono raggiungibili senza autenticazione e senza
 API key, ma **non offrono alcuna garanzia di stabilità**.
 
-| Endpoint                                         | Formato | Uso                                                                            |
-| ------------------------------------------------ | ------- | ------------------------------------------------------------------------------ |
-| `components/project-sheets.php?project_id=767`   | HTML    | Classifica completa dei due gironi                                             |
-| `assets/json/getEventsByTeamId.php?team_id=3359` | JSON    | Tutte le gare della squadra: data, ora, avversario, campo, risultato, parziali |
-
-Altri endpoint disponibili ma non usati: `getEventsByProjectIdHierarchical.php` (tutte le
-gare del campionato), `project-chart-rankings.php` (solo punti), `project-next_matches.php`,
-`project-last_results.php`, `team-roster.php`, `team-results.php`.
+Le pagine "umane" (`league_details.php`, `team_details.php`) sono gusci lato server: non
+contengono dati, li caricano dopo via JS dagli stessi endpoint `components/*.php` —
+verificato leggendo `assets/js/project.js` e `assets/js/team.js`, referenziati in fondo
+alle due pagine. Servono solo per la consultazione manuale nel browser (es. per ritrovare
+un `project_id`), nessun codice le chiama direttamente.
 
 ### Identificativi (stagione 2025/26)
 
-| Cosa                | Valore                                 |
-| ------------------- | -------------------------------------- |
-| Campionato          | PVM - Campionato Open Misto Eccellenza |
-| `project_id`        | `767`                                  |
-| Squadra sul portale | `C.R.A.P. Volley` (con i punti)        |
-| `team_id`           | `3359`                                 |
-| Girone              | B                                      |
+| Cosa                  | Valore                                 |
+| ---------------------- | ---------------------------------------- |
+| Campionato             | PVM - Campionato Open Misto Eccellenza |
+| `project_id` (girone)  | `767`                                  |
+| Coppa                  | PVM Coppa CSI Misto Silver             |
+| `project_id` (coppa)   | `848`                                  |
+| Squadra sul portale    | `C.R.A.P. Volley` (con i punti)        |
+| `team_id`              | `3359`                                 |
+| Girone                 | B                                      |
 
-Gli identificativi sono costanti in `src/lib/csi-core.ts`.
+`project_id` (767), `CSI_COPPA_PROJECT_ID` (848) e `team_id` (3359) sono costanti in
+`src/lib/csi-core.ts`.
+
+**Stagione 2026/27 non ancora sul portale (verificato il 24/09/2026).** Il CSI non ha ancora
+creato le pagine di campionato e Coppa 2026/27: le uniche competizioni della squadra sono
+ancora `767` e `848`, con gare da novembre 2025 a maggio 2026. Per questo `/classifica`
+mostra «Stagione 2025/26» mentre Squadra e Calendario, che hanno la stagione scritta nel
+codice, mostrano già «Stagione 2026/27». È voluto: la pagina Campionato riporta la stagione
+dei dati CSI che sta mostrando, non quella in corso per la squadra. Quando il CSI pubblica
+la nuova stagione si aggiornano i due `project_id` (vedi sotto) e l'etichetta passa da sola
+a 2026/27 ([DD-032](../DESIGN_DECISIONS.md#dd-032--la-stagione-csi-si-ricava-dalle-date-delle-gare)).
+
+Per ritrovare questi id a ogni cambio stagione: `components/team-main.php?team_id=3359`
+(dietro `team_details.php`) contiene una sezione "Campionati" con un link
+`league_details.php?project_id=…` per ogni competizione a cui la squadra è iscritta —
+verificato chiamando l'endpoint direttamente, che oggi restituisce sia
+`project_id=848` (Coppa) sia `project_id=767` (Campionato). Non serve aprire
+`team_details.php` nel browser, questo componente basta.
+
+### Endpoint usati dall'app
+
+| Endpoint                                          | Formato | Uso                                | Pagina "umana" corrispondente     |
+| -------------------------------------------------- | ------- | ------------------------------------ | ------------------------------------ |
+| `components/project-sheets.php?project_id=767`    | HTML    | Classifica completa dei due gironi di campionato | `league_details.php?project_id=767` (tab "Classifica") |
+| `components/project-sheets.php?project_id=848`    | HTML    | Classifica del girone di Coppa (solo fase a gironi, vedi limite 4) | `league_details.php?project_id=848` (tab "Classifica") |
+| `assets/json/getEventsByTeamId.php?team_id=3359`  | JSON    | Tutte le gare della squadra        | `team_details.php?team_id=3359` (tab "Calendario", `team-calendar.php`) |
+
+**Formato di `project-sheets.php`** — tabella HTML per girone (una per `<table>`,
+`parseClassifica()` in `csi-core.ts` prende quella che contiene il nome della squadra).
+Colonne per `<td>` (0-indicizzate): `0` Pos · `1` Squadra (nome + logo + link a
+`team_details.php?team_id=…`) · `2` Punti · `3` Partite giocate · `4` Vinte · `5` Perse ·
+`6`-`7` Tie-break vinti/persi (non lette) · `8` Set fatti · `9` Set subiti · poi punti
+fatti/subiti, quoziente, ultime cinque (non lette). Stessa struttura per `project_id=767`
+(campionato) e `project_id=848` (fase a gironi della Coppa): `parseClassifica()` è
+condivisa, nessun parser dedicato per la Coppa.
+
+**Formato di `getEventsByTeamId.php`** — array JSON, un oggetto per gara (girone **e**
+Coppa insieme, vedi limite 4), con: `id`, `start` (`"2025-11-12T22:00:00"`, data+ora
+locale), `team1`/`team2` (nomi squadre), `result` (`"3 - 1"`, stringa libera), `partials`
+(`"25 - 23</br>23 - 25</br>..."`, HTML nei separatori), `field` (impianto), `project`
+(nome campionato, es. `"PVM - Coppa CSI Misto Silver"` — usato per distinguere le
+competizioni, vedi limite 4), `league`, `group` (es. `"Girone B"`), `match_number`. Letto
+da `partiteDaEventi()` in `csi-core.ts`, che estrae punteggio/parziali con le regex
+`punteggio()`/`parziali()` — vedi limite 5 sui rischi di questo parsing.
+
+**Campi leggeri aggiuntivi letti dallo stesso JSON** (nessuna fetch in più, solo campi in
+più letti dallo stesso `evento`): `team1_logo`/`team2_logo` (URL del logo, quello
+dell'avversario finisce in `PartitaCsi.logoAvversario`), `group` (girone, es. `"Girone
+B"`), `match_number` (n° gara, es. `"5/XEB"`), `referees` (arbitro, spesso vuoto), `link`
+(URL del referto ufficiale, `match_details.php?id=…`).
+
+Altri endpoint disponibili ma non usati: `getEventsByProjectIdHierarchical.php` (tutte le
+gare del campionato), `project-chart-rankings.php` (solo punti), `project-next_matches.php`,
+`project-last_results.php`, `project-sheets-scorers.php`/`-results.php`/`-measures.php`
+(sotto-tab di `project-sheets`: marcatori, risultati per giornata, provvedimenti
+disciplinari), `team-roster.php` (rosa), `team-staff.php`, `team-results.php`,
+`team-scorers.php`.
+
+### Dettaglio di una singola gara (formazioni e scontri diretti)
+
+Il referto di ogni gara sul portale (`match_details.php?id=<matchId>`, dove `matchId` è lo
+stesso `id` restituito da `getEventsByTeamId.php`) carica a sua volta tre componenti via
+`assets/js/match.js`:
+
+| Endpoint                                      | Formato | Uso                                                    |
+| ----------------------------------------------- | ------- | --------------------------------------------------------- |
+| `components/match-main.php?match_id=<id>`     | HTML    | Giornata e una nota libera sotto l'impianto            |
+| `components/match-players.php?match_id=<id>`  | HTML    | Formazioni: titolari, panchina, staff di entrambe le squadre |
+| `components/match-stats.php?match_id=<id>`    | HTML    | Storico scontri diretti e probabilità di vittoria calcolata dal CSI |
+
+Altri due componenti della stessa pagina non sono usati: `match-live.php` (diretta testuale
+punto-per-punto, utile solo a gara in corso) e la lista dettagliata dei precedenti dentro
+`historyModal` in `match-stats.php` (un elenco partita-per-partita meno affidabile del
+riepilogo aggregato — vedi sotto).
+
+**`match-main.php`** — `parseInfoPartita()` (`csi-core.ts`) legge: la giornata (es. `"2ª
+Giornata"`, assente per gare fuori dal girone come la finale di Coppa) e una nota libera
+sotto l'impianto (`nota`). Quella nota **non ha un formato fisso**: a volte è `"Pubblico
+non ammesso"`, a volte il nome della palestra, a volte altro — va mostrata così com'è, non
+interpretata come un flag booleano.
+
+**`match-players.php`** — `parseFormazioni()` legge due blocchi `<div class="col-12
+col-md-6 mt-4">`, separati nel markup dal commento `<!-- SQUADRA OSPITE -->`, ciascuno con
+una `<ul class="list-group">` di giocatori in ordine titolari → divisore "A DISPOSIZIONE"
+→ panchina → divisore "STAFF" → staff (numero maglia, nome, ruolo; lo staff ha la stessa
+struttura ma senza numero). Quale dei due blocchi sia "noi" si riconosce con
+`isNostraSquadra()`, non assumendo un ordine fisso casa/ospite — verificato che l'ordine
+nel markup è sempre "squadra casa" prima e "squadra ospite" dopo, ma il codice non si fida
+di questo per evitare sorprese. `null` se nessuno dei due nomi è la nostra squadra
+(referto non ancora compilato o formato cambiato).
+
+**`match-stats.php`** — `parsePrecedenti()` legge il blocco di riepilogo in fondo alla
+pagina (non la lista `historyModal` partita-per-partita, che in un caso osservato conteneva
+gare di **altre squadre** senza relazione con la gara corrente — dato non affidabile da
+interpretare): numero di precedenti, vittorie totali/in casa/fuori di entrambe, probabilità
+di vittoria calcolata dal CSI. **Attenzione a un'insidia verificata sui dati reali**: le
+due barre di probabilità sono colorate per chi è favorito (verde = più alta, rosso = più
+bassa), **non** per casa/ospite — un parser ingenuo che associasse il verde alla squadra
+casa sbaglierebbe metà delle volte. Il parser usa invece l'ordine di apparizione nel
+markup (prima barra = squadra casa, seconda = ospite), coerente con l'ordine dei blocchi
+"Squadra casa"/"Squadra ospite" più sopra nella stessa pagina. Con "0 precedenti" il CSI
+omette del tutto le righe vittorie/in-casa/fuori (restano a `0`) ma la probabilità resta
+comunque presente: `parsePrecedenti()` distingue quindi "0 precedenti" (oggetto valido con
+`totale: 0`) da "formato non riconosciuto" (`null`, solo se nessuno dei due nomi squadra è
+identificabile).
+
+**Formato di `DettaglioPartitaCsi`** (il JSON che compongono insieme):
+`{ giornata, nota, formazioni: { noi, avversario } | null, precedenti: PrecedentiCsi | null
+}`, dove ogni `FormazioneSquadra` è `{ squadra, titolari: GiocatoreFormazione[], panchina,
+staff: StaffFormazione[] }` e `GiocatoreFormazione` è `{ numero, nome, ruolo }`.
 
 ---
 
@@ -49,29 +158,84 @@ Gli identificativi sono costanti in `src/lib/csi-core.ts`.
 ```
 CSI (portale)
       ↓  fetch server-side, cache 6 ore
-/api/public/csi          → src/routes/api/public/csi.ts
-      ↓  JSON { classifica, partite, girone, aggiornato }
-useCsi()                 → src/lib/csi.ts (React Query, staleTime 6h)
+/api/public/csi              → src/routes/api/public/csi.ts
+      ↓  JSON { classifica, classificaCoppa, partite, girone, aggiornato }
+useCsi()                     → src/lib/csi.ts (React Query, staleTime 6h)
       ↓
-/classifica              → src/routes/classifica.tsx
+/classifica                  → src/routes/classifica.tsx (tab "Classifica": Coppa sopra, Girone
+                                sotto; tab "Storico partite": ogni squadra col proprio logo,
+                                chevron di dettaglio sulle gare cliccabili, gare divise
+                                per stagione; stagione anche nel sottotitolo dell'header)
+
+CSI (portale, 3 endpoint)
+      ↓  fetch server-side on-demand, cache per-partita 6 ore
+/api/public/csi-partita/$id  → src/routes/api/public/csi-partita.$id.ts
+      ↓  JSON DettaglioPartitaCsi { giornata, nota, formazioni, precedenti }
+useCsiPartita()              → src/lib/csi-partita.ts (React Query, staleTime 6h)
+      ↓
+DettaglioCsiEsteso           → src/components/crapp/DettaglioCsi.tsx (formazioni + scontri diretti)
+      ↓
+/partita/$id (evento CrAPP collegato) o /partita-csi/$id (nessun evento collegato)
 ```
 
-- **`src/lib/csi-core.ts`** — costanti, tipi e funzioni pure: `parseClassifica()` (HTML → righe),
-  `partiteDaEventi()` (JSON → partite), `isNostraSquadra()`, `partiteGiocate()`.
-- **`src/routes/api/public/csi.ts`** — unica route che contatta il CSI. Cache in memoria di
-  6 ore; in caso di errore restituisce l'ultimo dato buono (`503` solo se non ne esiste uno).
-- **`src/lib/csi.ts`** — hook client, una lettura per sessione.
+- **`src/lib/csi-core.ts`** — costanti, tipi e funzioni pure: `parseClassifica()` (HTML → righe,
+  usata sia per `classifica` sia per `classificaCoppa`), `partiteDaEventi()` (JSON → partite),
+  `isNostraSquadra()`, `partiteGiocate()`, `matchDaPartitaCsi()` (porta i campi leggeri —
+  logo, girone, n° gara, arbitro, link — nella forma usata dalle liste), `parseInfoPartita()`,
+  `parseFormazioni()`, `parsePrecedenti()` (vedi sezione precedente).
+- **`src/routes/api/public/csi.ts`** — unica route che contatta il CSI per classifica e
+  partite: tre fetch in parallelo (classifica girone, classifica Coppa, partite). Cache in
+  memoria di 6 ore; in caso di errore restituisce l'ultimo dato buono (`503` solo se non ne
+  esiste uno). Se solo la Coppa fallisce (`scarica(...).catch(() => "")`) la risposta resta
+  comunque `200` con `classificaCoppa: []`: è un dato supplementare, non blocca la classifica
+  del girone.
+- **`src/routes/api/public/csi-partita.$id.ts`** — route separata per il dettaglio di una
+  singola gara: tre fetch in parallelo (`match-main`/`match-players`/`match-stats.php`). Cache
+  in memoria **per `matchId`** (una `Map`, non un singolo valore come `csi.ts`), stessa
+  finestra di 6 ore. A differenza di `/api/public/csi`, qui un fallimento del fetch è fatale
+  (`503`, nessun fallback "meglio un dato vecchio"): non c'è ancora una cache da riusare la
+  prima volta che qualcuno apre una gara, e un errore upstream reale (verificato: CSI risponde
+  `500` su `match-stats.php` per un `match_id` inventato) va distinto da "gara senza
+  formazioni ancora pubblicate" (quell'endpoint risponde `200` con markup vuoto, gestito da
+  `parseFormazioni()`/`parsePrecedenti()` restituendo `null`, non da un errore HTTP).
+- **`src/lib/csi.ts`** / **`src/lib/csi-partita.ts`** — hook client React Query, stessa
+  `staleTime` di 6h. `useCsiPartita(matchId)` è `enabled` solo quando `matchId` è definito:
+  va montato solo nel dettaglio di una gara, mai in una lista (altrimenti sarebbe una fetch
+  per riga, vedi "Regole rispettate" sotto).
+- **`src/components/crapp/DettaglioCsi.tsx`** — UI condivisa tra `/partita/$id` e
+  `/partita-csi/$id`: `LogoSquadra` (logo con hotlink diretto al portale CSI, si nasconde da
+  sola se l'immagine non carica invece di mostrare un'icona rotta), `MetaPartitaCsi` (girone,
+  n° gara, arbitro, link al referto — campi leggeri, zero fetch aggiuntive), `DettaglioCsiEsteso`
+  (formazioni + scontri diretti, monta `useCsiPartita()`).
+- **`src/routes/partita-csi.$id.tsx`** — dettaglio "solo CSI" per le gare **senza** un evento
+  CrAPP collegato (l'app non crea ancora eventi automaticamente dal calendario CSI, vedi
+  "Evoluzioni possibili"): nessuna convocazione/presenza/MVP/scout, solo risultato, parziali
+  e i dati CSI di questa sezione. `id` è l'`id` della gara sul portale CSI
+  (`PartitaCsi.id`), non un evento CrAPP.
+- **`src/routes/partita.$id.tsx`** — per le gare **con** un evento CrAPP collegato, mostra le
+  stesse informazioni CSI (logo, metadati, formazioni, scontri diretti) in più rispetto a
+  prima, quando `csiMatch` esiste per quella data.
 - **`test/unit/csi-core.test.ts`** — check del parsing: `bun test/unit/csi-core.test.ts`.
-  Con `CSI_LIVE=1` verifica anche gli endpoint reali.
+  Con `CSI_LIVE=1` verifica anche gli endpoint reali, incluse formazioni e precedenti di una
+  gara giocata.
 
 ### Regole rispettate
 
-- **Nessuna chiamata dal browser**: il portale viene contattato solo lato server, al massimo
-  4 volte al giorno, indipendentemente da quanti giocatori aprono l'app (regola anti-consumo).
-- **Nessuna dipendenza nuova**: parsing con espressioni regolari sulla struttura della tabella.
+- **Nessuna chiamata dal browser per classifica/partite**: il portale viene contattato solo
+  lato server, al massimo 4 volte al giorno per `/api/public/csi`, indipendentemente da
+  quanti giocatori aprono l'app (regola anti-consumo). **`/api/public/csi-partita/$id` è
+  diverso di proposito**: è on-demand, chiamato solo quando un giocatore apre il dettaglio
+  di una gara specifica (mai precaricato in una lista, vedi `useCsiPartita()` sopra) — non
+  rientra nel limite delle 4 chiamate/giorno perché non è un dato mostrato a tutti a ogni
+  apertura dell'app, ma cache comunque 6 ore per evitare rifetch ripetuti sulla stessa gara.
+- **Nessuna dipendenza nuova**: parsing con espressioni regolari sulla struttura della
+  tabella/lista, sia per classifica/partite sia per formazioni/precedenti.
 - **Fallback**: se il CSI non risponde, l'endpoint `/api/public/csi` restituisce l'ultimo
   dato buono in cache; se non ne ha ancora uno, la classifica resta vuota e i risultati
   ricadono sulle partite dello Scout Live locale (`useScoutMatches()`).
+  `/api/public/csi-partita/$id` non ha questo fallback sulla prima chiamata per una gara mai
+  vista (vedi sopra): fallisce con `503`, e la UI (`DettaglioCsiEsteso`) semplicemente non
+  mostra la sezione formazioni/scontri diretti, senza rompere il resto della pagina.
 - **Portabilità (DD-013)**: endpoint HTTP standard, nessun servizio esclusivo.
 
 ---
@@ -83,18 +247,103 @@ useCsi()                 → src/lib/csi.ts (React Query, staleTime 6h)
    ancora disponibile" (o l'ultimo dato buono in cache, se ce n'è uno) e i risultati ricadono
    sulle partite dello Scout Live locale, non su dati demo — non esistono più in `crapp-data.ts`.
    Il check con `CSI_LIVE=1` serve a scoprire il problema di parsing.
-2. **`project_id` è legato alla stagione.** Per il 2026/27 servirà un nuovo id, ricavabile da
-   `team_details.php?team_id=3359`, che elenca i campionati della squadra. Oggi va aggiornato
-   a mano in `csi-core.ts`.
+2. **`project_id` è legato alla stagione.** Per il 2026/27 servirà un nuovo id (vedi
+   "Sorgente dati" sopra per come ritrovarlo). Oggi va aggiornato a mano in `csi-core.ts`.
+   L'etichetta «Stagione 2025/26» di `/classifica` invece non va toccata: il portale non
+   espone il nome della stagione, quindi `stagioneDi()`/`stagioneDaPartite()` la ricavano
+   dalla data delle gare (l'anno cambia ad agosto) e segue da sola il nuovo `project_id`.
 3. **La cache vive nel processo del server.** Si perde a ogni cold start e non è condivisa tra
-   istanze. Sufficiente per una squadra; se serve di più, spostare i dati in una tabella
-   Supabase riempita da un job cron (stesso pattern di `promemoria-palloni`).
-4. **I risultati includono anche la Coppa**, non solo il girone di campionato.
+   istanze — vale sia per `/api/public/csi` sia per la `Map` per-partita di
+   `/api/public/csi-partita/$id`. Sufficiente per una squadra; se serve di più, spostare i
+   dati in una tabella Supabase riempita da un job cron (stesso pattern di
+   `promemoria-palloni`).
+4. **Le partite includono sia il girone di campionato sia la Coppa, mescolate.**
+   `getEventsByTeamId.php?team_id=3359` è per squadra, non per competizione (vedi tabella
+   endpoint sopra): risponde con tutte le gare di `C.R.A.P. Volley`. Il campo `project`
+   distingue le due nel JSON grezzo, ma `partiteDaEventi()` (`csi-core.ts`) oggi non lo usa
+   per filtrare: tutte le gare finiscono in `DatiCsi.partite` senza distinzione (`storico
+   partite` in `/classifica` le mostra tutte insieme). Se in futuro servisse separarle, il
+   filtro va aggiunto su `evento.project` in `partiteDaEventi()`.
+   **La classifica della Coppa, invece, è mostrata** (sopra quella del girone in
+   `/classifica`): `project-sheets.php?project_id=848` (`CSI_COPPA_PROJECT_ID`) ha la stessa
+   struttura a tabella-per-girone di `project_id=767`, quindi `parseClassifica()` funziona
+   invariata — nessun parser dedicato. Resta un limite: quella pagina copre **solo la fase a
+   gironi**. La Coppa (PVM Coppa CSI Misto Silver) prevede due gironi da 4 squadre sola
+   andata seguiti da una finale secca tra le due vincenti, disputata in un `project_id`
+   figlio separato generato a fine fase a gironi (verificato con `curl` diretto:
+   `project-main.php?project_id=848` descrive il regolamento — "due gironi sola andata, le
+   due vincenti in finale, gare 3 set su 5" — e `project-sheets.php?project_id=848` mostra
+   sia le due classifiche a girone sia, in un'altra sezione della stessa risposta, il
+   tabellone a eliminazione con quel `project_id` figlio). Se la squadra arrivasse in
+   finale, `/classifica` continuerebbe a mostrare la classifica (ormai chiusa) del proprio
+   girone di Coppa, non l'esito della finale: non c'è codice che segua quel `project_id`
+   figlio, che oltretutto cambia a ogni edizione della Coppa e non è noto in anticipo.
+5. **Le partite si leggono da JSON, con parsing fragile su campi testuali.** `result` e
+   `partials` in `getEventsByTeamId.php` sono stringhe libere tipo `"3-1"`, lette con
+   un'espressione regolare (`punteggio()`/`parziali()` in `csi-core.ts`). Se il portale CSI
+   cambiasse formato (es. `"3:1"`, o un punteggio come oggetto invece che stringa), la regex
+   non troverebbe corrispondenza e la partita risulterebbe "non ancora giocata"
+   (`setNostri`/`setLoro` a `null`) — silenziosamente, senza errori. Se invece la risposta
+   cambiasse forma radicalmente (non più un array), `partiteDaEventi()` torna `[]`.
+   **Conseguenza sugli obiettivi di squadra**: le "vittorie in campionato" (`obiettivi.ts`,
+   obiettivi o3/o4/o5) dipendono da `partiteGiocate(csi.partite)` — se il parsing delle partite
+   si rompe così, questi tre obiettivi restano bloccati a 0% anche a fronte di vittorie reali.
+   **Il fallback della route non se ne accorgerebbe da solo**: `/api/public/csi` lancia un
+   errore solo se *sia* la classifica *sia* le partite sono vuote insieme
+   (`classifica.length === 0 && partite.length === 0`); se si rompe solo il parsing delle
+   partite mentre la classifica HTML continua a funzionare, la route risponde comunque `200`
+   con `partite: []`. Per questo `leggiCsi()` confronta il JSON grezzo con il risultato di
+   `partiteDaEventi()` tramite `partiteFormatoSospetto()` (`csi-core.ts`): se ci sono eventi
+   grezzi ma nessuno è stato riconosciuto come nostra partita, logga un `console.error` —
+   distingue così un vero "formato cambiato" da un legittimo "nessuna gara ancora in
+   programma" (dove gli eventi grezzi stessi sono vuoti). Il flag `formatoSospetto` viaggia
+   anche nella risposta JSON (`DatiCsi.formatoSospetto`) fino a `/classifica`
+   (`src/routes/classifica.tsx`), dove mostra un badge discreto ("Il portale CSI potrebbe aver
+   cambiato formato: dati da verificare.") al posto della normale riga "Dati CSI aggiornati
+   alle...": un log server passa inosservato per settimane, un badge visibile a chi apre la
+   pagina campionato molto meno. Il fix, quando succede, è isolato a
+   `partiteDaEventi()`/`punteggio()`/`parziali()` in `csi-core.ts` (gli endpoint stessi
+   cambiano solo se cambia il dominio o serve autenticazione, nel qual caso va toccata anche
+   `src/routes/api/public/csi.ts`); va poi aggiornato anche `test/unit/csi-core.test.ts` con
+   fixture nel nuovo formato.
+6. **Il portale può essere del tutto irraggiungibile, non solo cambiare formato.** Scenario
+   diverso dal punto 5 (lì il JSON è valido ma non riconosciuto, qui la risposta non è
+   nemmeno JSON): l'8 settembre 2026 `getEventsByTeamId.php` ha risposto con `200` ma un
+   errore SQL del loro backend in chiaro al posto del JSON
+   (`Query non valida (getProjectTeams): Table 'uqc2os2x_livescore.seasons' doesn't exist`,
+   verificato con `curl` diretto sul loro dominio). `leggiCsi()` (`src/routes/api/public/
+   csi.ts`) intercetta l'eccezione di `JSON.parse` nel `try/catch` della route e risponde
+   `503 "CSI non raggiungibile"` (o serve la cache se ce n'è una) — nessun crash, ma nessun
+   dato nuovo finché il portale non torna. **Effetto sulla suite test**: i test di
+   `test/integration/api.test.ts` che leggono il CSI reale sondano `/api/public/csi` una
+   volta prima di partire; se risponde con errore li salta (`salta()`, non `prova()`) invece
+   di farli fallire, loggando il motivo — la suite resta verde durante un'indisponibilità
+   temporanea del portale, senza che quei 5 test vengano cancellati o disattivati in modo
+   permanente: tornano a girare da soli non appena il CSI risponde di nuovo con `200`.
+7. **I loghi delle squadre sono "hotlinked" direttamente dal browser al portale CSI**
+   (`LogoSquadra` in `DettaglioCsi.tsx` punta a `logoAvversario`, un URL
+   `livescore.csibologna.it/images/...`). È un'eccezione consapevole alla regola "nessuna
+   chiamata dal browser al CSI": un'immagine, a differenza dei dati, non ha bisogno di
+   passare dalla cache server per restare aggiornata, e proxarla/cacherla lato server per
+   ogni squadra avversaria (potenzialmente decine a stagione) sarebbe uno sforzo sproporzionato
+   al beneficio. Se un logo non carica (URL cambiato, squadra senza foto),
+   `LogoSquadra` si nasconde da sola (`onError` → `null`) invece di mostrare un'icona rotta.
+8. **L'ordine "titolari"/"A disposizione" in `parseFormazioni()` è quello del referto CSI,
+   non necessariamente il sestetto che è sceso davvero in campo al fischio d'inizio.** Il
+   CSI non separa esplicitamente "chi ha giocato titolare" da "chi era comunque convocato e
+   in lista gara": il divisore "A DISPOSIZIONE" nella pagina sembra riflettere l'ordine di
+   inserimento nel referto più che le sostituzioni reali. Va quindi presentato come "referto
+   del CSI", non come cronaca esatta di chi ha giocato quanto.
 
 ---
 
 ## Evoluzioni possibili
 
 - Prossima partita ufficiale nella home e nel calendario (i dati sono già disponibili).
-- Creazione automatica degli eventi partita da calendario CSI.
+- Creazione automatica degli eventi partita da calendario CSI — risolverebbe anche il
+  limite 4 di sopra: ogni gara avrebbe un evento CrAPP e andrebbe sempre su `/partita/$id`,
+  senza più bisogno di `/partita-csi/$id` per le gare "orfane".
 - Confronto tra i parziali ufficiali e quelli dello Scout Live.
+- Tabellone a eliminazione della fase finale di Coppa (limite 4): oggi non tracciato, il
+  `project_id` figlio (es. `905`) andrebbe scoperto a runtime leggendo il link dentro
+  `project-sheets.php?project_id=848` invece di essere una costante.

docs/modules/infortuni.md

@@ -27,6 +27,12 @@ volte compare lo stato `infortunato` nella mappa presenze già in cache (nessuna
 aggiuntiva). Lo stesso meccanismo, con `contaRitardi()`, conta i ritardi. Il risultato
 alimenta il campo `infortuni` del `Giocatore` in `useRosa()`.
 
+Un evento con data futura o odierna non viene contato, anche se la risposta è già registrata
+(l'UI permette di segnarsi infortunato o in ritardo su un evento non ancora passato): il
+conteggio filtra su `data < oggi`, come già fa `eventiContanoPresenze()` in
+[presenze.md](presenze.md), e cresce da solo con l'avanzare della data reale senza bisogno di
+altro codice.
+
 Visibile in UI solo indirettamente, tramite il [badge](badge.md) segreto "Cliente VIP
 dell'Infermeria" (sbloccato con almeno 3 infortuni): non esiste uno StatTile dedicato nel
 profilo che mostri il numero di infortuni come statistica di superficie.
@@ -38,7 +44,8 @@ profilo che mostri il numero di infortuni come statistica di superficie.
 - Nessuna durata o periodo tracciato: è solo un conteggio di eventi con quello stato, non un
   inizio/fine infortunio.
 - Il conteggio dipende dal fatto che qualcuno imposti correttamente lo stato "infortunato"
-  invece di "assente": nessuna validazione o promemoria lo garantisce.
+  invece di "assente": nessuna validazione o promemoria lo garantisce. Sulle card degli
+  eventi extra-campo (`tipo: "evento"`) l'opzione non è proposta in UI.
 - Poco visibile per valori bassi (1-2), perché emerge solo tramite un badge a soglia 3.
 - `conInfortuni()`, una funzione di merge alternativa nello stesso file, non risulta usata da
   nessuna parte del codice attuale — probabile residuo non collegato.

docs/modules/mvp.md

@@ -1,6 +1,6 @@
 # Modulo — Votazione MVP
 
-**Stato:** implementato (v1.0)
+**Stato:** implementato
 **File principali:** `src/lib/mvp-voti.ts`, `src/components/crapp/VotazioneMvp.tsx`
 
 ---
@@ -17,16 +17,29 @@ calcolato a runtime.
 Tabella `mvp_voti`, vincolo `UNIQUE (match_id, votante_id)` — un solo voto per giocatore per
 partita, sovrascrivibile.
 
+`match_id` è l'**id dell'evento CrAPP**, non quello del referto CSI né dello Scout: la
+votazione non dipende più da nessuna delle due fonti (i voti scritti prima con l'id scout/CSI
+restano nel database ma non vengono più letti da nessuna schermata).
+
 ---
 
 ## Implementazione
 
-- Il pannello compare in `partita.$id.tsx` solo se esiste un risultato (Scout Live salvato)
-  per la partita, altrimenti mostra "la partita non è ancora stata disputata".
+- Il pannello sta in `partita.$id.tsx` in una sezione sua, sempre presente: `votoMvpAperto()`
+  lo apre `ORE_ATTESA_MVP` (2) ore dopo `data`+`ora` dell'evento, prima di allora mostra solo
+  quando aprirà. Nessun legame con il risultato caricato.
+- Votano e sono votabili solo i **presenti** di quell'evento (`presente` o `ritardo` in
+  `usePresenzeEvento`): chi non c'era ha il bottone disabilitato e non compare nell'elenco.
 - `useVotaMvp()` fa upsert `onConflict: match_id, votante_id`: il voto è modificabile senza
   limiti, senza storico.
+- Nessuno vota sé stesso: `VotazioneMvp.tsx` toglie il votante dall'elenco e il vincolo
+  `mvp_no_autovoto` (migration `m12_niente_autovoto`) rifiuta la riga anche a chi scrive
+  direttamente su PostgREST, come già faceva `pagelle_no_autovoto` per le pagelle.
 - `conteggioPartita()`/`vincitoriMvp()` richiedono un margine netto: in caso di parità,
   nessun vincitore viene assegnato per quella partita finché non arrivano altri voti.
+- `vincitoriMvp()`/`mvpVintiPerGiocatore()` richiedono anche un quorum minimo di voti totali
+  sulla partita (`VOTI_MINIMI_MVP = 2`, `mvp-voti.ts`, DD-028): un solo voto non basta a
+  incoronare nessuno, nemmeno senza concorrenza.
 - `mvpVintiPerGiocatore()` conta una vittoria per ogni partita "vinta" con margine netto; il
   risultato alimenta il campo `mvp` del `Giocatore` in `useRosa()`, mostrato come StatTile
   nel profilo e in home.
@@ -35,18 +48,23 @@ partita, sovrascrivibile.
 
 ## Limiti noti
 
-- **Nessun controllo che impedisca di votare se stessi** — a differenza dei
-  [Badge social](badge.md), che escludono esplicitamente l'auto-voto. È una lacuna, non un
-  limite di design dichiarato altrove.
-- Nessuna scadenza o chiusura della votazione: resta aperta indefinitamente.
-- RLS permissiva: `votante_id`/`votato_id` sono testo libero inviato dal client (l'id
-  giocatore proviene da `localStorage`, non da un claim di sessione verificato server-side);
-  nessun trigger lega il voto all'utente autenticato.
-- In caso di parità, nessun MVP viene assegnato per quella partita.
+- Nessuna scadenza o chiusura della votazione: una volta aperta resta aperta indefinitamente.
+- Il voto è legato a chi lo scrive: da `m11_scritture_per_ruolo` la policy impone che
+  `votante_id` sia lo slot collegato all'account (DD-023). Su chi viene votato l'unico
+  vincolo diretto è che non sia il votante stesso (`mvp_no_autovoto`).
+  Da `m13_convocati_e_pagelle_chiuse` la stessa policy verifica anche che **sia il votante sia
+  il votato** siano tra i **convocati** dell'evento (`evento_permette_voto()`, convocati vuoto
+  = tutta la rosa): prima era un filtro solo applicativo, ora un giocatore non convocato non
+  può più votare né essere votato scrivendo direttamente su PostgREST. Restano invece solo
+  applicativi, non controllati da nessuna policy: che votante e votato fossero **presenti**
+  (non solo convocati: `presente`/`ritardo` in `usePresenzeEvento`, un controllo più stretto
+  della sola convocazione) a quella partita, e le due ore d'attesa dall'inizio evento
+  (`votoMvpAperto()`) — un amministratore, o chiunque scriva su PostgREST, passa comunque.
+- In caso di parità, o sotto il quorum minimo di voti, nessun MVP viene assegnato per quella
+  partita.
 
 ---
 
 ## Evoluzioni possibili
 
-- Impedire l'auto-voto come già avviene nei Badge social.
 - Introdurre una scadenza (es. la votazione si chiude N giorni dopo la partita).

docs/modules/notifiche.md

@@ -1,9 +1,11 @@
 # Modulo — Notifiche
 
-**Stato:** implementato — un unico opt-in dispositivo abilita tutto il canale push
-**File principali:** `src/lib/notifiche-smart.ts`, `src/lib/push-client.ts`,
-`src/lib/webpush.server.ts`, `src/routes/api/public/push-config.ts`,
-`src/routes/api/public/push-subscribe.ts`, `public/push-sw.js`
+**Stato:** implementato — un unico opt-in dispositivo abilita tutto il canale push, più un
+centro notifiche in-app indipendente, con un pallino sull'avatar del profilo
+**File principali:** `src/lib/notifiche-smart.ts`, `src/lib/notifiche-utente.ts`,
+`src/lib/push-client.ts`, `src/lib/webpush.server.ts`, `src/routes/api/public/push-config.ts`,
+`src/routes/api/public/push-subscribe.ts`, `public/push-sw.js`,
+`src/components/crapp/ui-bits.tsx` (`LinkProfilo`, `PallinoNotifiche`)
 
 ---
 
@@ -16,6 +18,11 @@ indipendenti:
 - **Notifiche smart** — notifiche locali mostrate solo ad app aperta, generate da badge,
   serie e obiettivi appena raggiunti; non è un canale push separato.
 
+Gli avvisi fissi in Home (turno palloni, certificati in scadenza) non passano da nessuno dei
+due: sono card calcolate dai dati, che spariscono da sole quando la condizione finisce. In
+particolare il certificato in scadenza **non** genera push né voci nel centro notifiche
+(DD-035, specifica in [profilo-giocatore.md](profilo-giocatore.md#avviso-certificati)).
+
 ---
 
 ## Dati
@@ -81,10 +88,24 @@ route. Tutte e tre partono da un gesto di un amministratore dentro l'app, quindi
 è uno solo (`richiediAdmin` in `src/lib/auth-route.server.ts`) e non serve configurare nessuna
 variabile d'ambiente.
 
-| Route                                                        | Controllo                                                                          | Chi la chiama                                                   |
-| ------------------------------------------------------------ | ---------------------------------------------------------------------------------- | --------------------------------------------------------------- |
-| `apri-sondaggio`, `sollecita-presenze`, `promemoria-palloni` | `richiediAdmin` — token della sessione Supabase, poi ruolo `admin` in `user_roles` | l'app, da un pulsante riservato agli admin                      |
-| `csi`, `push-config`, `push-subscribe`                       | nessuno                                                                            | il browser prima del login, che una sessione non ce l'ha ancora |
+| Route                                                                                                       | Controllo                                                                          | Chi la chiama                                                   |
+| ----------------------------------------------------------------------------------------------------------- | ---------------------------------------------------------------------------------- | --------------------------------------------------------------- |
+| `apri-sondaggio`, `sollecita-presenze`, `promemoria-palloni`, `notifiche-attive`, `notifica-personalizzata` | `richiediAdmin` — token della sessione Supabase, poi ruolo `admin` in `user_roles` | l'app, da un pulsante o una vista riservati agli admin          |
+| `csi`, `push-config`, `push-subscribe`                                                                      | nessuno                                                                            | il browser prima del login, che una sessione non ce l'ha ancora |
+
+`notifiche-attive` è a sola lettura: non manda push, restituisce gli id giocatore con almeno
+un dispositivo iscritto in `push_subscriptions` (deduplicati). Alimenta la tab "Notifiche"
+della dashboard admin (vedi [Profilo giocatore](profilo-giocatore.md)), non l'invio effettivo.
+La tab elenca tutti i giocatori attivi della squadra, non solo chi ha le notifiche abilitate:
+l'icona (campana piena/barrata) distingue chi ha almeno un dispositivo iscritto da chi non
+l'ha ancora attivata.
+
+`notifica-personalizzata` manda un messaggio libero scritto dall'admin: senza `giocatoreId`
+lo manda a tutti i dispositivi iscritti in `push_subscriptions`, con `giocatoreId` solo a
+quelli di quel giocatore. Titolo fisso ("Messaggio dallo staff"), corpo il testo scritto
+dall'admin (max 300 caratteri). Stessa logica di pulizia delle altre route: una sottoscrizione
+che risponde 404/410 viene cancellata dalla tabella. Nella tab "Notifiche" della dashboard
+admin c'è un bottone "Invia messaggio a tutti" sopra l'elenco e un bottone per riga giocatore.
 
 ---
 
@@ -98,6 +119,51 @@ ripetersi — deduplica puramente locale al dispositivo, non sincronizzata.
 
 ---
 
+## Centro notifiche in-app (M17)
+
+Pallino sull'angolo dell'avatar del profilo in alto a destra (`PallinoNotifiche` dentro
+`LinkProfilo`, `src/components/crapp/ui-bits.tsx`): rosso con il numero delle non lette; se
+sono tutte lette resta neutro con il totale, così le lette restano raggiungibili per
+eliminarle; senza notifiche non compare. Il tap sull'avatar porta sempre a `/profilo`, solo il
+tap sul pallino apre il pannello (logica in `pallinoNotifiche()`). Fino a 0.9.2 era una
+campanella separata accanto all'avatar. Indipendente dal canale push sopra:
+non richiede che il dispositivo abbia attivato «Notifiche», ha uno storico persistente in
+`notifiche_utente` (vedi [DATABASE.md](../DATABASE.md)) con stato letto/non letto, e non è la
+stessa cosa delle notifiche smart (quelle restano locali, non salvate a database).
+
+Quattro sorgenti scrivono in `notifiche_utente`, mai il client:
+
+1. **Messaggio admin** — `notifica-personalizzata.ts` inserisce una riga per destinatario
+   in parallelo all'invio push esistente (a tutta la rosa attiva se `giocatoreId` è omesso).
+2. **Promemoria evento** — due job `pg_cron` (ogni ora per la finestra delle 24h, ogni 15
+   minuti per quella delle 3h) generano una notifica per evento imminente, per i convocati
+   (o tutta la rosa attiva se l'evento non ne specifica), deduplicata da un vincolo
+   `UNIQUE (giocatore_id, evento_id, tipo)` così un cron che gira più volte non manda
+   doppioni. Volutamente non c'è una notifica sulla sola creazione dell'evento: conta
+   l'avvicinarsi della data, non il momento in cui è stato messo in calendario.
+3. **Turno palloni** — `promemoria-palloni.ts` (bottone riservato agli admin sulla pagina
+   evento, vedi [Turno palloni](palloni.md)) inserisce una riga per ciascun avviso calcolato
+   da `avvisiPalloniEvento()`, in parallelo alla push.
+4. **Sollecito presenze** — `sollecita-presenze.ts` (stesso innesco manuale) inserisce una
+   riga per ciascun giocatore che non ha ancora risposto, in parallelo alla push.
+
+Turno palloni e sollecito presenze usano un `upsert` su `(giocatore_id, evento_id, tipo)`
+invece di un semplice insert: se l'admin preme di nuovo il pulsante per lo stesso evento, la
+notifica esistente viene aggiornata (testo e `creato_il` freschi, `letta` riportata a false)
+invece di duplicarsi o fallire per il vincolo `UNIQUE`.
+
+Lettura, "segna come letta" ed eliminazione passano dal client Supabase autenticato con RLS
+(`useNotificheMie()`/`useSegnaLette()`/`useEliminaNotifica()`), senza una route API dedicata
+— stesso pattern di `useSalvaEvento()` in `src/lib/eventi.ts`. Aprire il pannello segna tutte
+le notifiche del giocatore selezionato come lette; non c'è un pulsante "segna singola"
+separato.
+
+**Non c'è pulizia automatica delle notifiche vecchie** (DD-030): l'unico modo per farle
+sparire per sempre è eliminarle una per una, con uno swipe verso sinistra sulla riga
+(`RigaNotifica` in `ui-bits.tsx`, stessa fisica a molla dello swipe del calendario) o con la
+× che compare sopra ogni riga per chi non è su touch. Chi non tocca mai una notifica se la
+ritrova per sempre nell'elenco, solo segnata come letta.
+
 ## Limiti noti
 
 - Non ci sono preferenze granulari (solo palloni / solo presenze / solo smart): un dispositivo

docs/modules/obiettivi-squadra.md

@@ -1,6 +1,7 @@
 # Modulo — Obiettivi di squadra
 
-**Stato:** implementato (v1.0), con costanti stagionali da aggiornare a mano
+**Stato:** implementato — mesi/scadenze dinamici, target stagionali fissi da rivedere a mano,
+copertura test completa (unit + integration) su tutti e 10 gli obiettivi.
 **File principali:** `src/lib/obiettivi.ts`, `src/lib/rosa.ts` (`useObiettivi()`)
 
 ---
@@ -15,47 +16,159 @@ comportamenti di squadra oltre alla singola prestazione.
 
 ## Dati
 
-Nessuna tabella dedicata: ogni obiettivo è una funzione pura in `obiettivi.ts` che legge dati
-già aggregati altrove (`risposte_presenze`, `pagelle_voti`, i risultati ufficiali CSI, le
-serie).
+Nessuna tabella dedicata: ogni obiettivo è una funzione pura in `obiettivi.ts`
+(`obiettiviSquadra()`) che legge dati già aggregati altrove (`risposte_presenze`,
+`pagelle_voti`, i risultati ufficiali CSI, le serie di presenza). `obiettiviOrdinati()` li
+ordina mettendo i completati in coda e gli altri per progresso decrescente.
+
+Non c'è nessuno stato da tenere sincronizzato quando un evento viene cancellato: gli obiettivi
+sono ricalcolati da zero a ogni render partendo dall'elenco eventi corrente, quindi un evento
+sparito da `eventi_app` smette semplicemente di contare, senza bisogno di nessuna pulizia
+esplicita. Il problema che *sembrava* riguardare gli obiettivi era in realtà nelle tabelle
+collegate a un evento (presenze, pagelle, MVP, ecc.), che restavano orfane a database dopo la
+cancellazione: risolto a livello database con un trigger (migration
+`m14_pulizia_dati_evento_cancellato`, DD-029), non nel modulo Obiettivi.
+
+`obiettiviSquadra(rosa, ctx, oggi)` accetta un terzo parametro opzionale `oggi: Date` (default
+`new Date()`) per iniettare una data deterministica nei test — usato dai due obiettivi con mese
+corrente dinamico (vedi sotto).
 
 ---
 
 ## Obiettivi definiti
 
-| Obiettivo                          | Calcolo                                         | Target | Fonte                                          |
-| ---------------------------------- | ----------------------------------------------- | ------ | ---------------------------------------------- |
-| 90% presenze ad agosto             | risposte presente/ritardo sugli eventi del mese | 90%    | `risposte_presenze`                            |
-| Tutti rispondono alle convocazioni | risposte totali / eventi possibili              | 90%    | `risposte_presenze`                            |
-| 250 presenze complessive           | somma presenze di tutta la rosa                 | 250    | aggregato da `useRosa()`                       |
-| Media pagelle da 7.5               | media di squadra                                | 7.5    | `pagelle_voti`                                 |
-| 200 pagelle compilate              | conteggio voti                                  | 200    | `pagelle_voti`                                 |
-| Continuità di squadra              | giocatori con ≥3 allenamenti consecutivi        | 12     | `serieAllenamenti`                             |
-| 1 / 5 / 10 vittorie in campionato  | partite vinte da dati CSI ufficiali             | 1/5/10 | modulo [Collegamento CSI](collegamento-csi.md) |
-| 1 evento di squadra al mese        | eventi di tipo "evento" nel mese                | 1      | `eventi_app`                                   |
+| id    | Obiettivo                          | Calcolo                                              | Target                 | Fonte                                     |
+| ----- | ----------------------------------- | ----------------------------------------------------- | ----------------------- | ------------------------------------------ |
+| `o1`  | 90% presenze del mese               | risposte presente/ritardo su partite+allenamenti del mese corrente (dinamico) | 90% | `risposte_presenze` |
+| `o2`  | Tutti rispondono alle convocazioni  | risposte totali / eventi possibili (esclusi i compleanni) | 90%                  | `risposte_presenze`                        |
+| `o7`  | 250 presenze complessive            | somma presenze di tutta la rosa, stagione intera       | 250                     | aggregato da `useRosa()`                   |
+| `o12` | Media pagelle da 7.5                | media di tutti i voti, arrotondata a una cifra decimale | 7.5                   | `pagelle_voti`                             |
+| `o13` | 200 pagelle compilate               | conteggio voti                                         | 200                     | `pagelle_voti`                             |
+| `o11` | Continuità di squadra               | giocatori con ≥3 allenamenti consecutivi               | 12 (min. per un 6vs6)   | `serieAllenamenti`                         |
+| `o3`  | Prima vittoria del campionato       | `min(vittorie, 1)`                                     | 1                       | JSON partite CSI (vedi sotto)              |
+| `o4`  | 5 vittorie in campionato            | `min(vittorie, 5)`                                     | 5                       | JSON partite CSI                           |
+| `o5`  | 10 vittorie in campionato           | `min(vittorie, 10)`                                    | 10                      | JSON partite CSI                           |
+| `o6`  | 1 evento di squadra al mese         | eventi di tipo "evento" nel mese corrente (dinamico)   | 1                       | `eventi_app`                               |
 
 Mostrati in `squadra.tsx` (elenco completo con barra di progresso) e in `index.tsx` (home: il
 primo obiettivo non completato). Un obiettivo che supera il 90% genera anche una notifica
-smart (`notifiche-smart.ts`).
+smart (`notifiche-smart.ts`). I target fissi (250 presenze, 200 pagelle, 7.5 di media, 1/5/10
+vittorie) sono scelte editoriali da rivedere a mano a ogni stagione — nessuna configurazione o
+UI per farlo, si cambia il numero in `obiettivi.ts`. Fa eccezione "Continuità di squadra"
+(vedi sotto): il suo target ha un significato specifico, non va scalato come gli altri.
 
 ---
 
-## Limiti noti
+## Obiettivi mensili — mese dinamico
 
-- "Continuità di squadra" dipende da `serieAllenamenti` (vedi
-  [Serie di presenze](serie-presenze.md)), calcolato sui dati reali: un evento passato senza
-  risposta vale come assenza e azzera la serie, quindi l'obiettivo misura anche quanto la
-  squadra risponde alle convocazioni, non solo la presenza.
-- **Il mese di riferimento è una costante fissa nel codice** (agosto 2026): gli obiettivi
-  legati al mese corrente vanno aggiornati manualmente a ogni cambio di mese o stagione, oggi
-  sono "congelati" su un mese già passato.
-- Le vittorie di campionato dipendono dal parsing HTML del portale CSI: se quel parsing si
-  rompe, questi tre obiettivi restano a 0% anche a fronte di vittorie reali.
-- I target (250 presenze, 200 pagelle, ecc.) sono costanti fisse, da rivedere manualmente a
-  ogni stagione.
+`o1` ("90% presenze del mese") e `o6` ("1 evento di squadra al mese") si azzerano
+automaticamente a ogni cambio mese: il mese di riferimento è calcolato dalla data corrente
+(fuso Europe/Rome, `meseCorrente(oggi)`), non più una costante fissa. Per `o1`, titolo
+("90% di presenze ad agosto" / "a settembre" / ...) e scadenza (ultimo giorno del mese)
+seguono di conseguenza.
+
+`o2` ("Tutti rispondono alle convocazioni") non si azzera — aggrega su tutti gli eventi in
+programma, non solo quelli del mese corrente — ma la sua `scadenza` mostrata in interfaccia è
+anch'essa l'ultimo giorno del mese corrente (`fineMese(oggi)`), non più una data fissa.
 
 ---
 
-## Evoluzioni possibili
+## Continuità di squadra — il target 12 è il minimo per un 6vs6
 
-- Calcolare il mese di riferimento dinamicamente invece di una costante hardcoded.
+Il target di 12 giocatori con almeno 3 allenamenti consecutivi (`o11`) **non è arbitrario**: è
+il numero minimo di giocatori per schierare due sestetti (6 contro 6) in allenamento. A
+differenza degli altri target fissi, non va scalato in proporzione alla rosa se questa cambia
+dimensione — resta 12 finché l'obiettivo è "riuscire ad allenarsi in modo completo".
+
+Dipende da `serieAllenamenti` (vedi [Serie di presenze](serie-presenze.md)), calcolato sui dati
+reali: un evento passato senza risposta vale come assenza e azzera la serie, quindi l'obiettivo
+misura anche quanto la squadra risponde alle convocazioni, non solo la presenza fisica.
+
+---
+
+## Vittorie in campionato (o3/o4/o5) — dipendenza dal portale CSI
+
+Le vittorie (`ctx.vittorie`) arrivano dal **JSON** delle partite del portale CSI Bologna
+(`getEventsByTeamId.php`, non la pagina HTML della classifica), tramite
+`partiteGiocate(csi.partite).filter(p => p.setNostri > p.setLoro)` calcolato in
+`src/lib/rosa.ts` (`useObiettivi()`). `o3`/`o4`/`o5` sono lo stesso numero di vittorie letto a
+tre soglie diverse (1/5/10), ciascuna cappata con `Math.min` — nessuna delle tre supera mai il
+proprio target, nemmeno con più vittorie di quante ne servano.
+
+### Il limite: il parsing del JSON può rompersi in silenzio
+
+`result` e `partials` nella risposta di `getEventsByTeamId.php` sono stringhe libere tipo
+`"3-1"`, lette con un'espressione regolare (`punteggio()`/`parziali()` in `csi-core.ts`). Se il
+portale CSI cambiasse formato (es. `"3:1"`, o un punteggio come oggetto invece che stringa), la
+regex non troverebbe corrispondenza e la partita risulterebbe "non ancora giocata" — **senza
+errori**. Se la risposta cambiasse forma radicalmente (non più un array), `partiteDaEventi()`
+torna `[]`. In entrambi i casi `o3`/`o4`/`o5` restano bloccati a 0% anche a fronte di vittorie
+reali, e il fallback della route (`/api/public/csi`) non se ne accorgerebbe da solo: lancia un
+errore solo se *sia* la classifica *sia* le partite sono vuote insieme, quindi se si rompe solo
+il JSON delle partite mentre la classifica HTML continua a funzionare, la route risponde
+comunque `200` con `partite: []`.
+
+### Come è mitigato oggi
+
+- **`partiteFormatoSospetto()`** (`csi-core.ts`) confronta gli eventi grezzi ricevuti con il
+  risultato di `partiteDaEventi()`: se ci sono eventi ma nessuno è stato riconosciuto come
+  nostra partita, il formato è quasi certamente cambiato (distingue così un vero "formato
+  rotto" da un legittimo "nessuna gara ancora in programma", dove gli eventi grezzi sono vuoti
+  anche loro).
+- La route (`src/routes/api/public/csi.ts`) logga un `console.error` quando succede.
+- Il flag viaggia anche nella risposta JSON (`DatiCsi.formatoSospetto`) fino a `/classifica`
+  (`src/routes/classifica.tsx`), dove sostituisce la riga "Dati CSI aggiornati alle..." con un
+  badge discreto color warning ("Il portale CSI potrebbe aver cambiato formato: dati da
+  verificare.") — visibile a chi apre la pagina campionato, non solo nei log del server.
+
+### Come fixarlo, se succede
+
+1. **Vedere il nuovo formato**: guardare la risposta reale dell'endpoint, o lanciare
+   `CSI_LIVE=1 bun test/unit/csi-core.test.ts` (interroga il portale vero).
+2. **Aggiornare il parsing** in `src/lib/csi-core.ts`: quasi sempre basta toccare
+   `punteggio()`/`parziali()` (le regex sul formato del punteggio) o i nomi dei campi letti in
+   `partiteDaEventi()`. Il resto dell'app consuma solo i tipi già puliti che questo file
+   produce (`DatiCsi`, `PartitaCsi[]`), quindi il fix resta isolato.
+3. Serve toccare anche `src/routes/api/public/csi.ts` solo se cambiano gli **URL/endpoint**
+   stessi o serve autenticazione — non per un semplice cambio di formato dei dati.
+4. **Aggiornare i test**: `test/unit/csi-core.test.ts` con fixture nel nuovo formato, altrimenti
+   restano verdi contro un formato che non esiste più.
+
+Dettagli completi (endpoint, identificativi di stagione, altri limiti del collegamento CSI) in
+[Collegamento CSI](collegamento-csi.md).
+
+---
+
+## Copertura test
+
+Tutti e 10 gli obiettivi hanno unit test **e** integration test end-to-end (dati scritti/letti
+da un backend reale, non solo funzione pura con contesto costruito a mano).
+
+| Obiettivi   | Unit test                     | Integration test                                         |
+| ------------ | -------------------------------- | ------------------------------------------------------------ |
+| o1, o2, o6   | `test/unit/obiettivi.test.ts`    | `test/integration/obiettivi.test.ts` (Supabase locale)       |
+| o7           | `test/unit/obiettivi.test.ts`    | `test/integration/obiettivi.test.ts` (Supabase locale)       |
+| o11          | `test/unit/obiettivi.test.ts`    | `test/integration/obiettivi.test.ts` (Supabase locale)       |
+| o12, o13     | `test/unit/obiettivi.test.ts`    | `test/integration/obiettivi.test.ts` (Supabase locale)       |
+| o3, o4, o5   | `test/unit/obiettivi.test.ts`    | `test/integration/api.test.ts` (CSI reale in produzione)     |
+
+- **o1/o2/o6** (Supabase locale): scrive eventi e risposte veri su `eventi_app`/
+  `risposte_presenze`, li rilegge con `leggiEventi()` (la stessa funzione server dell'app) e una
+  query REST equivalente a `fetchPresenze()`. Copre: contesto vuoto, aggregazione su più eventi,
+  filtro sui tipi (partite/allenamenti contano, eventi sociali/compleanni no), il mese dinamico
+  (evento dentro/fuori mese), scadenza dinamica.
+- **o7** (Supabase locale): scrive eventi/presenze reali, calcola `contaPresenzeGiocatore()` (la
+  stessa funzione pura usata da `useRosa()` in produzione) sui dati riletti, verifica la somma.
+- **o11** (Supabase locale): scrive tre allenamenti e presenze reali, calcola
+  `serieConsecutiva()` sui dati riletti, verifica che solo chi resta in serie venga contato.
+- **o12/o13** (Supabase locale): scrive voti veri su `pagelle_voti` rispettando i vincoli reali
+  della tabella (`pagelle_no_autovoto`, `pagelle_voto_range`), li rilegge, verifica media
+  arrotondata e conteggio.
+- **o3/o4/o5** (CSI reale, non Supabase — le vittorie non toccano il database): estende
+  `test/integration/api.test.ts`, che già chiama `/api/public/csi` dal vivo. Legge le vittorie
+  vere del giorno con la stessa logica di `useObiettivi()`, le passa a `obiettiviSquadra()` e
+  verifica cap e target su dati reali.
+
+Per rilanciare tutto: `npm run test` (unit, nessuna rete) e `npm run test:integration`
+(richiede `npx supabase start` per o1/o2/o6/o7/o11/o12/o13, e rete verso CSI Bologna per
+o3/o4/o5 — quest'ultimo gira comunque anche senza stack Supabase locale).

docs/modules/pagelle.md

@@ -1,6 +1,6 @@
 # Modulo — Pagelle
 
-**Stato:** implementato (v1.0)
+**Stato:** implementato
 **File principali:** `src/lib/pagelle.ts`, `src/components/crapp/Pagelle.tsx`
 
 ---
@@ -29,9 +29,19 @@ UI), `UNIQUE (match_id, votante_id, votato_id)`.
 - `useVotaPagella()` fa un upsert su `(match_id, votante_id, votato_id)`: si può votare più
   volte, l'ultimo voto sovrascrive il precedente.
 - `mediePagelle()` calcola la media aritmetica (arrotondata a un decimale) per giocatore su
-  tutti i voti della stagione; `pagellePartita()` la calcola per singola partita;
-  `mediaSquadra()` su tutti i voti di tutti — mostrata come StatTile in `squadra.tsx`.
-- `useRosa()` inietta la media stagionale nel campo `mediaVoto` di ogni giocatore.
+  **tutti i voti mai ricevuti** — l'app non ha un concetto di stagione/reset, quindi non è
+  "la media di questa stagione" ma lo storico completo; `pagellePartita()` la calcola per
+  singola partita; `mediaSquadra()` su tutti i voti di tutti — mostrata come StatTile in
+  `squadra.tsx`.
+- `useRosa()` inietta questa media storica nel campo `mediaVoto` di ogni giocatore, insieme al
+  numero di voti ricevuti (`votiPagella`) — usato dal badge Pagellone (vedi
+  [badge.md](badge.md)) per richiedere un minimo di voti prima che la media conti, e mostrato
+  come StatTile nel profilo e in home (sezione «Colpo d'occhio», `index.tsx`).
+- La StatTile **home** applica la stessa soglia del badge Pagellone (DD-028) tramite la
+  funzione pura `mediaVotoColpoDOcchio()`: sotto `VOTI_MINIMI_PAGELLA` voti ricevuti mostra
+  `—` invece della media, non solo quando i voti sono zero. È stata estratta come funzione
+  testabile (coerente con DD-020) invece di restare una condizione inline nella route. Le
+  StatTile di **profilo** e **squadra** non applicano questa soglia (vedi "Limiti noti").
 
 ---
 
@@ -39,25 +49,28 @@ UI), `UNIQUE (match_id, votante_id, votato_id)`.
 
 - Anti auto-voto imposto anche a livello database (constraint, non solo filtro UI).
 - L'admin può marcare un evento come `pagelleChiuse` (`eventi.ts`), che nasconde i bottoni di
-  voto in UI.
+  voto in UI **e**, da M13, rifiuta anche a database un voto scritto dopo la chiusura (RLS
+  `evento_permette_voto()`, `pagelle_voti`).
+- Da M13 anche il votante e il votato devono essere convocati all'evento: verificato a
+  database, non solo in UI (stessa RLS di sopra).
 
 ---
 
 ## Limiti noti
 
-- **`pagelleChiuse` è solo un flag UI**: nessuna policy RLS lo controlla, quindi un voto
-  "fuori tempo" resta tecnicamente possibile bypassando l'interfaccia.
 - **L'anonimato è solo applicativo, non tecnico**: la riga salvata contiene sia `votante_id`
   sia `votato_id`, leggibili da chiunque sia autenticato (policy SELECT aperta). La UI non
   mostra mai il votante, ma il dato non è né aggregato né mascherato lato server.
-- Nessun controllo a livello database che il votante sia realmente un convocato della
-  partita: solo filtro applicativo.
-- La media non richiede un numero minimo di voti: con un solo voto ricevuto, la media
-  coincide con quel voto.
+- La media mostrata nel **profilo** e in **squadra** non richiede un numero minimo di voti:
+  con un solo voto ricevuto, la media coincide con quel voto. Il badge Pagellone (`badge.md`)
+  e la StatTile **home** (DD-028) applicano invece la stessa soglia minima prima di
+  considerarla — profilo e squadra no.
+- Le due regole di M13 (convocazione, `pagelle_chiuse`) valgono solo per la policy "Ognuno
+  gestisce i propri voti pagella": un amministratore può ancora correggere un voto fuori
+  convocazione o dopo la chiusura, di proposito (deve poter sistemare un errore).
 
 ---
 
 ## Evoluzioni possibili
 
 - Una RPC o vista che nasconda `votante_id` per un anonimato garantito anche lato dati.
-- Far rispettare `pagelleChiuse` anche via RLS.

docs/modules/palloni.md

@@ -1,6 +1,6 @@
 # Modulo — Palloni
 
-**Stato:** implementato (v1.0)
+**Stato:** implementato
 **File principali:** `src/lib/palloni.ts`, `src/lib/palloni-core.ts`,
 `src/components/crapp/TurnoPalloni.tsx`, `src/components/crapp/PromemoriaPalloni.tsx`,
 `src/routes/api/public/promemoria-palloni.ts`
@@ -11,7 +11,8 @@
 
 Gestire un turno a rotazione condiviso per chi porta e riporta i palloni ad allenamenti e
 partite, con proposta automatica, possibilità di modifica manuale e promemoria push il
-giorno stesso.
+giorno stesso. Gli eventi extra-campo (`tipo === "evento"`, es. cena di squadra) e i
+compleanni non c'entrano: non richiedono palloni.
 
 ---
 
@@ -25,16 +26,28 @@ compaiono.
 
 ## Implementazione
 
-- `completaTurni()` (`palloni-core.ts`) propone, per ogni **partita** o evento extra senza
-  turno già salvato, il candidato con meno turni fatti, poi quello che non lo fa da più
-  tempo, poi per ordine alfabetico — un algoritmo greedy, non un ordine fisso né solo per
-  data. Gli **allenamenti** non ricevono proposta automatica: restano «da assegnare» finché
-  qualcuno non sceglie un incaricato in `TurnoPalloni` (scelta della squadra).
+- `eventiPalloni()` (`palloni-core.ts`) è il filtro comune a tutta la pipeline (proposte,
+  conteggi, serie, promemoria): include solo `tipo === "partita"` e `tipo === "allenamento"`,
+  scarta eventi extra-campo e compleanni.
+- `completaTurni()` (`palloni-core.ts`) propone, per ogni **partita** senza turno già salvato,
+  il candidato con meno turni fatti, poi quello che non lo fa da più tempo, poi per ordine
+  alfabetico — un algoritmo greedy, non un ordine fisso né solo per data. Gli **allenamenti**
+  non ricevono proposta automatica: restano «da assegnare» finché qualcuno non sceglie un
+  incaricato in `TurnoPalloni` (scelta della squadra).
 - `useAssegnaTurno()` (`palloni.ts`) conferma una proposta o riassegna manualmente, con
   upsert su `evento_id`.
 - Il conteggio "quante volte hai portato i palloni" mostrato nel profilo e nei badge è
-  ricalcolato a runtime da `conteggioTurni()` su turni salvati **più proposte non ancora
-  confermate** (partite/eventi) — non è uno storico in tabella dedicata.
+  ricalcolato a runtime da `conteggioTurni()` sui **soli turni confermati** (`turniSalvati`
+  in `rosa.ts`) — non è uno storico in tabella dedicata, ma non include le proposte
+  automatiche di `completaTurni()` (quelle restano solo per la UI di rotazione,
+  `TurnoPalloni.tsx`/`PromemoriaPalloni.tsx`). Conta solo gli eventi già passati (`e.data <
+oggi`, stesso criterio delle presenze): un turno assegnato in anticipo per un allenamento
+  futuro non è ancora "portato", quindi non sale finché quel giorno non arriva.
+- `serieConsecutivaPalloni()` (`palloni-core.ts`) calcola le volte **consecutive** in cui il
+  giocatore ha portato i palloni (`Giocatore.seriePalloni` in `rosa.ts`), mostrate nel
+  sottotitolo della classifica interna di Squadra quando si ordina per Palloni. Stesso
+  criterio "solo eventi già passati" di `conteggioTurni()`; un evento passato senza turno
+  confermato non spezza la serie di nessuno (viene saltato, non conta come "non portati").
 - `TurnoPalloni.tsx` mostra/assegna il turno sulla card di un evento; `PromemoriaPalloni.tsx`
   è il banner in Home per il giocatore di turno.
 
@@ -59,10 +72,15 @@ nessuna chiamata di rete. Stesso meccanismo di `apri-sondaggio` (vedi
 - **L'invio è manuale**: nessun cron manda il promemoria da solo, se l'admin non preme il
   pulsante non parte niente (DD-025). `destinatariPromemoriaPalloni()` — la versione "chi è di
   turno oggi" — resta in `palloni-core.ts` ma non la chiama più nessuno.
-- Il conteggio dei turni include anche le proposte non confermate: badge e statistiche
-  possono contare turni mai effettivamente convalidati da nessuno.
 - La rotazione non considera le assenze dichiarate: può proporre il turno a chi ha risposto
   "assente" o "infortunato" per quell'evento.
+- **`conteggioTurni()` non filtra per tipo evento** (a differenza di `eventiPalloni()`, che
+  include solo partite e allenamenti): guarda solo `e.data < oggi`. Un turno registrato per
+  errore su un evento fuori dal dominio "richiede i palloni" conterebbe comunque per il badge
+  Sherpa dei palloni (`badge.md` § Problemi noti). Rischio basso — l'UI non offre questa
+  combinazione, dato che né `TurnoPalloni` né i promemoria automatici propongono più un turno
+  per eventi extra-campo o compleanni — ma il comportamento attuale è pinnato da un test
+  dedicato in `palloni-core.test.ts`.
 
 ---
 

docs/modules/presenze.md

@@ -1,8 +1,8 @@
 # Modulo — Presenze
 
-**Stato:** implementato (v1.0)
+**Stato:** implementato
 **File principali:** `src/lib/presenze.ts`, `src/lib/presenze-mese.ts`, `src/components/crapp/RosaPresenze.tsx`,
-`src/routes/api/public/sollecita-presenze.ts`
+`src/components/crapp/EventoCard.tsx`, `src/routes/api/public/sollecita-presenze.ts`
 
 ---
 
@@ -24,7 +24,11 @@ attuale.
 Stati possibili (`Stato` in `src/lib/crapp-data.ts`): `presente`, `assente`, `forse`,
 `ritardo`, `infortunato`. Solo `presente` e `ritardo` contano come presenza effettiva nelle
 statistiche. L'assenza di una riga per `(evento, giocatore)` equivale a "non ha ancora
-risposto".
+risposto". Lo stato `infortunato` è offerto solo per partite e allenamenti: sugli eventi
+extra-campo (`tipo === "evento"`, es. cena di squadra) non è pertinente e resta escluso
+ovunque — badge di riepilogo, gruppi elenco e bottoni di risposta — sia nella card
+(`EventoCard`, tramite `includeInfortunato()` in `presenze.ts`) sia nella scheda di dettaglio
+(`RosaPresenze`, prop `tipo`).
 
 ---
 
@@ -40,20 +44,33 @@ risposte_presenze (Supabase)
 useRispostePresenze()     → src/lib/presenze.ts   (1 query per sessione, staleTime 5 min,
       ↓                                             legge tutta la tabella)
 RosaPresenze               → src/components/crapp/RosaPresenze.tsx
-      ↑ montato da           (riepilogo, bottoni di risposta, gruppi per stato)
-allenamento.$id.tsx / partita.$id.tsx
+      ↑ montato da           (riepilogo, bottoni di risposta, gruppi per stato;
+allenamento.$id.tsx /          prop `tipo` esclude "infortunato" per gli eventi extra-campo)
+partita.$id.tsx / evento.$id.tsx
+
+EventoCard                 → src/components/crapp/EventoCard.tsx
+      ↑ home / calendario    (riga compatta di stati; senza `infortunato` se tipo `evento`)
 
 --- statistiche ---
 contaPresenzeGiocatore() / totaliEventiGiocatore()  → src/lib/presenze.ts
 usePresenzeUltimoMese()                             → src/lib/presenze-mese.ts
                                                        (percentuale ultimi 30gg, da cache già in memoria)
 
+contaPresenzeGiocatore() alimenta il campo `presenze` del `Giocatore` in `useRosa()`, mostrato
+come StatTile nel profilo e in home (sezione «Colpo d'occhio», `index.tsx`).
+
+contaPartiteGiocate() è contaPresenzeGiocatore() ristretto alle sole partite (non
+allenamenti): alimenta `Giocatore.partiteGiocate`, usato nel sottotitolo della classifica
+interna di Squadra quando si ordina per MVP — un conteggio di eventi generico (allenamenti
+compresi) sarebbe fuorviante lì, perché l'MVP si vota solo alle partite.
+
 --- sollecito (solo admin) ---
 Bottone "Sollecita" (RosaPresenze.tsx) → POST /api/public/sollecita-presenze
       ↓
 src/routes/api/public/sollecita-presenze.ts
       ├─ legge l'evento (eventi_app) e le risposte già date
-      ├─ calcola i destinatari: giocatori attivi senza risposta o con "forse"
+      ├─ destinatariSollecito()  → src/lib/presenze.ts
+      │  (attivi senza risposta o con "forse"; funzione pura, testata in unit)
       ├─ per ciascuno invia una push col testo cifrato nel payload
       │  (src/lib/webpush.server.ts)
       └─ elimina le iscrizioni push scadute (404/410)
@@ -70,24 +87,25 @@ vale per tutta la rosa) — `eventiContanoPresenze()` in `presenze.ts`.
 - Aggiornamento ottimistico della cache locale dopo ogni salvataggio: nessuna rilettura dal
   server, la UI risponde subito.
 - Il sollecito è **manuale**: nessun cron nel repository lo richiama automaticamente, parte
-  solo dal bottone admin.
+  solo dal bottone admin, e la route verifica il ruolo lato server con `richiediAdmin`
+  (DD-024).
+- Ognuno risponde **solo per sé**, e non è più una regola della sola interfaccia: dalla
+  migration `m11_scritture_per_ruolo` la policy di `risposte_presenze` lega la riga allo slot
+  `giocatori_squadra` collegato all'account, con gli amministratori come sola deroga
+  (DD-023). Verificato da `test/integration/permessi.test.ts`.
 
 ---
 
 ## Limiti noti
 
 - Nessuna finestra temporale per rispondere: si può cambiare risposta anche a evento passato.
-- Il controllo "solo il giocatore risponde per sé" è solo lato UI: le policy RLS di
-  `risposte_presenze` permettono a qualunque utente autenticato di scrivere qualunque riga
-  (`USING(true) WITH CHECK(true)`).
+- La risposta di un evento passato resta modificabile: `risposte_presenze` non ha una
+  finestra di chiusura, né in UI né in RLS.
 - `useRispostePresenze()` legge sempre l'intera tabella, non filtrata per evento: adeguato per
   una singola squadra, da rivedere se il volume cresce molto.
-- La route `/api/public/sollecita-presenze` non verifica lato server che il chiamante sia
-  admin: la protezione è solo nell'interfaccia (bottone visibile solo se `useIsAdmin()`).
 
 ---
 
 ## Evoluzioni possibili
 
-- Restringere anche lato RLS/route chi può scrivere una risposta o chiamare il sollecito.
 - Filtrare la lettura delle presenze per evento invece di caricare tutta la tabella.

docs/modules/profilo-giocatore.md

@@ -1,5 +1,11 @@
 # Modulo — Profilo Giocatore
 
+**Stato:** implementato
+**File principali:** `src/lib/profili.ts`, `src/lib/profili-core.ts`, `src/routes/profilo.tsx`,
+`src/routes/admin.tsx`
+
+---
+
 ## Obiettivo
 
 Il modulo "Profilo Giocatore" raccoglie tutte le informazioni personali, amministrative e documentali di ciascun membro della squadra.
@@ -8,6 +14,9 @@ L'obiettivo è centralizzare in un'unica schermata tutti i dati necessari sia al
 
 ## Utenti
 
+L'allenatore ha un profilo ridotto (solo Docs con i dati personali essenziali e Opzioni):
+la specifica sta in [allenatore.md](allenatore.md).
+
 ### Giocatore
 
 Può:
@@ -29,7 +38,8 @@ Può:
 - modificare i dati squadra di qualsiasi giocatore (nome, cognome, numero, ruolo, email)
 - compilare e correggere i dati personali e del documento al posto di un giocatore (DD-017)
 - scollegare un account da un profilo, liberando lo slot
-- aggiungere un nuovo giocatore alla rosa (id, nome, cognome, numero, ruolo, email opzionale)
+- aggiungere un nuovo giocatore alla rosa (id, nome, cognome, numero, ruolo, email opzionale),
+  oppure un allenatore (tipo «Allenatore»: niente numero né ruolo, DD-034)
 - disattivare un giocatore che ha lasciato la squadra, e riattivarlo in caso di errore: la
   riga non viene eliminata, così presenze, voti, pagelle e badge della stagione restano
   agganciati al suo id
@@ -54,7 +64,7 @@ Se il profilo non è completo compare automaticamente un widget di completamento
 
 ## Home
 
-Il giocatore visualizza un widget dedicato.
+Il giocatore visualizza un widget dedicato e, quando serve, l'avviso sul certificato medico.
 
 ### Completa il tuo profilo
 
@@ -70,6 +80,128 @@ Quando tutte le sezioni sono complete il widget scompare automaticamente.
 Il tap apre Profilo sulla sottosezione **Documenti** (`/profilo?tab=documenti`), non
 sulla tab Stagione.
 
+### Avviso certificati
+
+**Stato:** implementato (DD-035).
+
+Un avviso in Home segnala i certificati medici in scadenza o scaduti, così nessuno se ne
+accorge quando il giocatore è già fuori regola. Si calcola al volo dalla data di scadenza
+già salvata: niente tabella, niente migration, niente push.
+
+#### Chi lo vede
+
+| Utente                      | Cosa vede                                                       | Al tocco                      |
+| --------------------------- | --------------------------------------------------------------- | ----------------------------- |
+| Admin                       | l'avviso **dello staff**: i nomi di tutti i giocatori coinvolti | niente, non è cliccabile      |
+| Giocatore interessato       | l'avviso **personale**: solo il proprio certificato             | apre `/profilo?tab=documenti` |
+| Admin che è anche giocatore | solo l'avviso dello staff, dove compare già il suo nome         | niente                        |
+| Altri giocatori             | niente                                                          | —                             |
+| Allenatore                  | niente: non vede i certificati altrui e non ne ha uno (DD-034)  | —                             |
+
+L'avviso dello staff non è cliccabile, come quello dei palloni: l'admin non può caricare il
+certificato al posto del giocatore (DD-017), quindi può solo sollecitarlo, e il giocatore
+riceve già il proprio avviso. Quello personale porta invece dove si carica il certificato
+nuovo, come il widget «Completa il tuo profilo».
+
+I certificati sono dati sanitari: fuori da `/admin` li legge solo il titolare (DD-016).
+Nessuna policy cambia, perché `useProfili()` restituisce già tutti i profili a un admin e il
+solo proprio a un giocatore.
+
+#### Quando compare
+
+`giorni` è la differenza in giorni di calendario tra la scadenza e oggi (ora locale), soglia
+`GIORNI_AVVISO_CERTIFICATO = 7`.
+
+| Condizione           | Stato       | Avviso             |
+| -------------------- | ----------- | ------------------ |
+| `giorni > 7`         | valido      | nessuno            |
+| `0 ≤ giorni ≤ 7`     | in scadenza | giallo (`warning`) |
+| `giorni < 0`         | scaduto     | nero (`primary`)   |
+| data o file mancanti | mancante    | nessuno            |
+
+- Il giorno della scadenza il certificato vale ancora, coerente con `statoScadenza()`: il
+  giocatore compare nel giallo con «scade oggi» e passa al nero dal giorno dopo.
+- L'avviso nero resta finché il giocatore non aggiorna la data: non c'è un limite di tempo.
+- Il certificato **mancante** non genera avviso: è un problema diverso, già visibile nella
+  tab Profili di `/admin` e nel widget di completamento del giocatore.
+- Sono esclusi i giocatori disattivati e gli allenatori: conta solo la rosa (`inRosa()`,
+  cioè `attivo` e `tipo = 'giocatore'`).
+
+#### Testi
+
+| Avviso            | Titolo (staff / personale) | Riga                                                                     |
+| ----------------- | -------------------------- | ------------------------------------------------------------------------ |
+| Giallo, staff     | «Certificati in scadenza»  | «Mario Rossi — scade tra 5 giorni», «… — scade domani», «… — scade oggi» |
+| Nero, staff       | «Certificati scaduti»      | «Mario Rossi — scaduto il 12/09/2026»                                    |
+| Giallo, personale | «Certificato in scadenza»  | «Il tuo certificato medico scade tra 5 giorni» / «domani» / «oggi»       |
+| Nero, personale   | «Certificato scaduto»      | «Il tuo certificato medico è scaduto il 12/09/2026: caricane uno nuovo»  |
+
+Il numero di giorni scende da solo ogni giorno (7, 6, 5… domani, oggi): l'avviso non
+conserva niente, rilegge la data a ogni apertura della Home.
+
+#### Più giocatori
+
+- Più giocatori nello stesso stato stanno in un **unico avviso**, una riga ciascuno, e
+  compaiono **tutti**: nessun limite al numero di nomi, anche a inizio stagione quando ne
+  scadono molti insieme.
+- Se ci sono sia certificati in scadenza sia scaduti compaiono **due avvisi**: prima quello
+  nero, poi quello giallo.
+- Ordine delle righe: dalla scadenza più vicina nel giallo, dal certificato scaduto da più
+  tempo nel nero; a parità di data, alfabetico per cognome e poi per nome. L'ordine è
+  stabile, quindi l'elenco non si rimescola tra un'apertura e l'altra.
+
+#### Aspetto e posizione
+
+- Stessa forma del banner palloni (`PromemoriaPalloni`): card arrotondata a tutta larghezza
+  con icona e titolo in `font-display` maiuscolo, righe in testo piccolo sotto.
+- Giallo: sfondo `bg-warning`, testo `text-warning-foreground`. Nero: sfondo `bg-primary`,
+  testo `text-primary-foreground`. L'app è solo chiara (DD-022), quindi il nero non rischia
+  di confondersi con lo sfondo.
+- In Home sta subito **sotto il banner palloni** e sopra «Completa il tuo profilo»: prima
+  ciò che scade oggi, poi ciò che manca.
+
+#### Rinnovo
+
+Il giocatore rinnova dal proprio profilo, sottosezione Documenti: carica il file nuovo e
+aggiorna la data. Il salvataggio aggiorna la cache dei profili (`setQueryData`), quindi il
+suo avviso personale sparisce subito. Nell'avviso dello staff il nome sparisce alla lettura
+successiva dei profili da parte dell'admin (cache di 30 minuti, `useProfili()`), senza
+nessuna azione da parte sua. Quando non resta nessuno, l'avviso non compare più.
+
+Basta aggiornare la data: l'avviso guarda solo quella (e la presenza di un file). Che il
+file caricato sia davvero quello nuovo resta un controllo dell'admin, come oggi. Anche l'admin
+può correggere la data dalla scheda del giocatore (DD-017, non il file): l'avviso segue la
+data, chiunque l'abbia scritta.
+
+#### Caricamento
+
+Finché ruoli e profili non sono arrivati, l'avviso non compare: così un admin che è anche
+giocatore non vede per un attimo l'avviso personale prima di quello dello staff. Se la
+lettura dei profili fallisce l'avviso semplicemente non compare, senza messaggio d'errore:
+la Home non deve rompersi per un dato accessorio.
+
+#### Implementazione
+
+| Pezzo                                           | Ruolo                                                                                                                                       |
+| ----------------------------------------------- | ------------------------------------------------------------------------------------------------------------------------------------------- |
+| `GIORNI_AVVISO_CERTIFICATO` (`profili-core.ts`) | la soglia, 7                                                                                                                                |
+| `giorniAllaScadenza(scadenza, oggi)`            | differenza in giorni di calendario tra due date `AAAA-MM-GG`, negativa se scaduto                                                           |
+| `avvisiCertificati(rosa, profili, oggi)`        | funzione pura: restituisce `{ scaduti, inScadenza }`, ognuno una lista ordinata di `{ giocatoreId, nome, cognome, scadenza, giorni }`       |
+| `testoScadenza(giorni)`                         | «scade oggi» / «scade domani» / «scade tra N giorni»                                                                                        |
+| `src/components/crapp/AvvisoCertificati.tsx`    | legge `useGiocatoriSquadra()`, `useProfili()`, `useIsAdmin()` e l'utente corrente; sceglie avviso dello staff o personale e disegna le card |
+| `src/routes/index.tsx`                          | monta `<AvvisoCertificati />` subito dopo `<PromemoriaPalloni />`                                                                           |
+
+- "Oggi" viene da `oggiISO()` (`palloni-core.ts`), in ora locale. Non da
+  `new Date().toISOString()`, che è in UTC e tra mezzanotte e le 2 darebbe il giorno prima.
+- Nessuna query nuova: `useProfili()` ha la stessa chiave di cache usata da Profilo e
+  `/admin`, quindi al massimo una lettura di `profili_giocatore` per sessione (vedi
+  [EFFICIENZA_CLOUD.md](../EFFICIENZA_CLOUD.md)). Per l'allenatore il componente non legge
+  i profili.
+- Test in `test/unit/profili-core.test.ts`: soglia (8 giorni no, 7 sì, 0 sì, −1 scaduto),
+  certificato senza file o senza data escluso, giocatore disattivato e allenatore esclusi,
+  ordinamento (per data, poi alfabetico), testi al singolare e al plurale, cambio di mese e
+  di anno nel calcolo dei giorni.
+
 ## Profilo
 
 Il profilo viene suddiviso in sette aree.
@@ -85,7 +217,11 @@ Il profilo viene suddiviso in sette aree.
 
 **Dati personali** — modificabili dal giocatore.
 
-- Data di nascita
+- Data di nascita — oltre a `profili_giocatore.data_nascita`, un trigger la sincronizza in
+  `giocatori_squadra.nascita` (DD-031): a differenza degli altri campi di questa sezione,
+  visibile a **tutta la squadra**, non solo al giocatore stesso o all'admin (alimenta
+  Squadra e i compleanni nel Calendario, vedi `squadra.md`). Cancellare il profilo azzera
+  anche quel valore pubblico.
 - Luogo di nascita
 - Indirizzo di residenza
 - Telefono
@@ -118,6 +254,10 @@ Upload.
 
 Il giocatore può aggiornare liberamente sia la data sia il file.
 
+Quando mancano 7 giorni o meno alla scadenza, o il certificato è scaduto, il giocatore
+riceve un avviso nella propria Home e compare in quello degli admin (vedi
+[Avviso certificati](#avviso-certificati)).
+
 Lo storico non viene mantenuto nella prima versione.
 
 ### Foto tessera
@@ -159,9 +299,20 @@ Contiene.
 ## Dashboard amministratore
 
 Gli amministratori dispongono di una schermata dedicata (`/admin`, raggiungibile da
-Profilo → Opzioni).
+Profilo → Opzioni), organizzata in tab scorrevoli a pillole (`BarraSottosezioni`, stesso
+componente di [Squadra](squadra.md) e Campionato): Squadra, Profili, Disattivati (solo se
+c'è almeno un giocatore disattivato) e Notifiche.
 
-Per ogni giocatore vengono mostrati.
+La tab **Notifiche** mostra quanti giocatori attivi hanno almeno un dispositivo iscritto
+alle notifiche push e i loro nomi, leggendo `GET /api/public/notifiche-attive` (vedi
+[Notifiche](notifiche.md)). È solo consultiva: l'attivazione resta un gesto che ogni
+giocatore deve fare dal proprio dispositivo (Profilo), l'admin non può attivarla per conto
+di altri.
+
+Gli allenatori stanno nella stessa tab in un gruppo «Allenatori» a parte, senza documenti né
+tesseramento, e non entrano nei conteggi della tab Squadra né nell'export CSI (DD-034).
+
+Per ogni giocatore, nella tab Profili, vengono mostrati.
 
 - Stato del profilo
 - Certificato medico
@@ -230,6 +381,9 @@ Quando tutte le sezioni risultano complete il profilo raggiunge il 100%.
 dati, modificare dati squadra e dati personali di chiunque e scollegare un account (DD-017).
 Non carica file al posto di altri.
 
+**Avviso certificati** — il giocatore vede solo il proprio, l'admin i nomi di tutta la rosa,
+nessun altro ne vede (vedi [Avviso certificati](#avviso-certificati)).
+
 ## Versione 1
 
 - Profilo giocatore
@@ -244,6 +398,7 @@ Non carica file al posto di altri.
 ## Versioni future
 
 - Storico certificati medici
+- Avviso certificati anche via push, o con una soglia regolabile dall'admin (DD-035, Riesame)
 - Gestione documenti aggiuntivi
 - Consensi privacy
 - Firma digitale

docs/modules/scout-live.md

@@ -1,6 +1,6 @@
 # Modulo — Scout Live
 
-**Stato:** implementato (v1.0, fix M7 per la persistenza condivisa)
+**Stato:** implementato (fix M7 per la persistenza condivisa)
 **File principali:** `src/lib/scout-live.ts`, `src/lib/scout-stato.ts`, `src/lib/scout-store.ts`,
 `src/lib/scout-export.ts`, `src/lib/cacche.ts`, `src/components/crapp/ScoutEntry.tsx`,
 `src/components/crapp/SondaggioCacche.tsx`, `src/routes/scout.tsx`, `src/routes/partita.$id.tsx`

docs/modules/serie-presenze.md

@@ -4,7 +4,9 @@
 **File principali:** `src/lib/serie.ts`, `src/lib/presenze.ts`, `src/lib/rosa.ts`,
 `src/components/crapp/SerieCard.tsx`
 **Migration collegata:** `m9_risposte_presenze_risposto_il`
-**Test:** `test/unit/serie.test.ts`, `test/unit/presenze.test.ts`
+**Test:** `test/unit/serie.test.ts`, `test/unit/presenze.test.ts`,
+`test/integration/scritture.test.ts` (il trigger che congela `risposto_il`),
+`test/integration/serie-allenamenti-badge.test.ts`, `test/integration/serie-conferme-badge.test.ts`
 
 ---
 
@@ -58,6 +60,18 @@ UPDATE: senza, un giocatore che risponde subito e cambia idea una settimana dopo
 lento. `aggiornato_il` continua a registrare l'ultima modifica ed è un'altra cosa: non usarlo
 per le conferme.
 
+Le due colonne si confondono facilmente, e sbagliarle non rompe niente di visibile: la serie
+comincia solo a raccontare il falso. Per questo il confine è verificato in
+`test/integration/scritture.test.ts` («la risposta di presenza si aggiorna senza far ripartire
+il cronometro»), che riscrive la risposta provando a riscrivere anche `risposto_il` e controlla
+che il database abbia tenuto la prima: se qualcuno togliesse il trigger, quel test diventa
+rosso. Il test precedente guardava `aggiornato_il` e passava anche senza trigger.
+
+| Colonna         | Cosa registra         | Chi la usa              |
+| --------------- | --------------------- | ----------------------- |
+| `risposto_il`   | la **prima** risposta | la serie "Conferme 24h" |
+| `aggiornato_il` | l'**ultima** modifica | nessuna statistica      |
+
 Cancellare la risposta (`stato: null` → DELETE) elimina anche `risposto_il`: se il giocatore
 risponde di nuovo, riparte il cronometro. È voluto — ha ritirato la risposta.
 
@@ -102,8 +116,11 @@ ordine:
    - solo eventi a cui il giocatore era convocato. **`convocati` vuoto significa "tutta la
      rosa"**, non "nessuno": chi non è nell'elenco di una convocazione ristretta non vede
      quell'evento e la sua serie non si spezza.
-2. **Scarta il futuro** (`e.data <= oggi`). Gli eventi di oggi contano già: se serve un
-   confronto diverso, il parametro `oggi` è iniettabile (i test lo fissano a una data).
+2. **Tiene solo gli eventi già passati** (`e.data < oggi`, dentro `eventiContanoPresenze()`).
+   Il confronto è **stretto**: l'evento di oggi non conta ancora, perché nessuno ha potuto
+   presentarsi e conterebbe come assenza, azzerando la serie di tutta la squadra la mattina
+   della partita. Entra in gioco dal giorno dopo. Il parametro `oggi` è iniettabile — di
+   default `dataOggi()` — e i test lo fissano a una data per non dipendere dall'orologio.
 3. **Ordina per data crescente** (`localeCompare` su `YYYY-MM-DD`).
 4. **Riduce** applicando `aggiornaSerie(serie, onorato(e))` a ogni evento: `+1` se onorato,
    `0` altrimenti. La serie finale è quella che risulta **dopo l'ultimo evento passato**.
@@ -121,9 +138,10 @@ Onorato = lo stato salvato è `presente` **o** `ritardo`. Gli stati possibili so
 
 Conseguenze da conoscere prima di cambiare qualcosa:
 
-- **`infortunato` azzera la serie**, esattamente come `assente`. Coerente con il conteggio
-  presenze, ma è una scelta da rivedere se si vuole "congelare" la serie di chi è fermo per
-  infortunio.
+- **`infortunato` congela la serie**: l'evento è escluso a monte (filtrato prima di
+  `serieSu()`), quindi non conta né come presenza né come buco — la serie resta al valore
+  di prima. Diverso da `contaPresenzeGiocatore()`, che continua a non contarlo come
+  presenza (stesso criterio `presente`/`ritardo` di prima, invariato).
 - **Nessuna risposta azzera la serie.** Un evento passato per cui il giocatore non ha mai
   toccato l'app equivale a un'assenza. È voluto (la serie premia anche il rispondere), ma
   significa che eventi storici importati senza presenze schiacciano a zero le serie di tutti.
@@ -265,9 +283,10 @@ il costo diventerebbe per-render e andrebbe stabilizzata a monte.
 
 - **Cambiare i traguardi di una serie** → l'array `traguardi` in `serieDefs`. Devono restare
   crescenti (un test lo verifica) e non serve altro: progresso e messaggi si adeguano.
-- **Cambiare la regola di presenza** (per esempio non azzerare su `infortunato`) → il
-  predicato dentro `serieConsecutiva()`. Valutare se allineare anche
-  `contaPresenzeGiocatore()`, che oggi usa lo stesso criterio.
+- **Cambiare la regola di presenza** → il predicato dentro `serieConsecutiva()`.
+  `infortunato` è già escluso a monte (congela la serie, non la azzera); valutare se
+  allineare anche `contaPresenzeGiocatore()`, che oggi conta ancora `infortunato` come
+  assenza ai fini statistici.
 - **Non azzerare quando manca la risposta** → sempre in quel predicato: distinguere
   `stato === undefined` e restituire la serie invariata invece di `false`. Richiede di
   cambiare `serieSu()`, che oggi conosce solo "onorato sì/no".
@@ -298,8 +317,14 @@ nell'ordine in cui arrivano dalla query (`.order("data")`), quindi non determini
 loro. Irrilevante finché un buco e una presenza nello stesso giorno danno lo stesso
 risultato finale, ma va sistemato se un giorno serve l'ordine esatto.
 
-**Il fuso è quello del client.** `oggi` nasce da `new Date().toISOString()`, cioè UTC: nelle
-prime ore della giornata italiana un evento di oggi può risultare "non ancora passato".
+**`oggi` è sempre in fuso Italia.** `dataOggi()` (`src/lib/scout-live.ts`) usa
+`Intl.DateTimeFormat` con `timeZone: "Europe/Rome"`, non i getter locali di `Date` né
+`toISOString()`: il cambio ora legale/solare lo gestisce il database IANA dei fusi, non un
+offset scritto a mano. È lo stesso `oggi` di `serieConsecutiva()`, `serieConferme()` e del
+conteggio presenze — prima `serieConsecutiva()`/`serieConferme()` calcolavano `oggi` con
+`toISOString()` (sempre UTC) mentre il conteggio presenze usava i getter locali di `Date`
+(corretti solo se il processo gira già in fuso italiano): nelle prime ore della giornata
+italiana potevano non essere d'accordo su cosa fosse "oggi".
 
 ---
 

docs/modules/squadra.md

@@ -0,0 +1,98 @@
+# Modulo — Squadra
+
+**Stato:** implementato
+**File principali:** `src/lib/giocatori-squadra.ts`, `src/lib/giocatori-squadra.server.ts`,
+`src/lib/rosa.ts`, `src/routes/squadra.tsx`, `src/routes/admin.tsx` (sezione rosa)
+**Test:** `test/unit/giocatori-squadra.test.ts`, `test/unit/rosa.test.ts`
+
+---
+
+## Obiettivo
+
+Tenere l'anagrafica della rosa (nome, numero di maglia, ruolo, chi è collegato a quale
+account) in un unico posto — `giocatori_squadra` — e farla usare a tutte le schermate che
+hanno bisogno di sapere "chi c'è in squadra", invece di ciascuna avere la propria copia.
+Prima di [DD-015](../DESIGN_DECISIONS.md#dd-015--rosa-anagrafica-da-codice-hardcoded-a-database)
+la lista viveva hardcoded in `src/lib/crapp-data.ts`: aggiungere o disattivare un
+giocatore dalla dashboard admin non aveva alcun effetto sul resto dell'app.
+
+---
+
+## Due letture diverse, per non pagare due volte lo stesso costo
+
+- **`useAnagraficaRosa()`** (`rosa.ts`) — solo id, nome, ruolo, numero, data di nascita dei
+  giocatori `attivo`. Serve dove basta sapere chi c'è, es. i compleanni nel Calendario o le
+  liste presenze: non monta gli hook di MVP/pagelle/palloni/infortuni. La data di nascita
+  viene da `giocatori_squadra.nascita` (migration `m18_nascita_pubblica_giocatori_squadra`,
+  DD-031): pubblica a tutta la rosa, sincronizzata automaticamente da un trigger quando il
+  giocatore (o un admin per lui) la salva dal Profilo — vedi `profilo-giocatore.md`. `null`
+  finché non è stata inserita da nessuno.
+- **`useRosa()`** (`rosa.ts`) — la stessa anagrafica arricchita con tutte le statistiche
+  personali calcolate a runtime: presenze, partite giocate, serie (presenze, allenamenti,
+  partite, conferme, palloni), MVP vinti, media voto pagelle, palloni, cacche, infortuni,
+  ritardi. Non fa query aggiuntive: combina in un `useMemo` le cache già in memoria di
+  `mvp-voti.ts`, `pagelle.ts`, `cacche.ts`, `palloni.ts`, `infortuni.ts`, `presenze.ts`,
+  `eventi.ts` — la spec di ciascuna di queste statistiche sta nel modulo relativo
+  (`mvp.md`, `pagelle.md`, `palloni.md`, `infortuni.md`, `presenze.md`). `useRosa()` è anche
+  la base di `useIo()` (il giocatore sul dispositivo corrente) e `useObiettivi()`
+  (`obiettivi-squadra.md`).
+
+Entrambe filtrano solo i giocatori `attivo`: chi ha lasciato la squadra resta nel database
+(presenze, voti, pagelle e badge della stagione restano agganciati al suo id) ma sparisce
+dagli elenchi correnti. Il filtro è `inRosa()` (`giocatori-squadra.ts`), che esclude anche
+gli allenatori (`tipo = 'allenatore'`, DD-034): hanno uno slot ma non giocano.
+`useAnagraficaRosa({ conAllenatori: true })` li include, per i compleanni.
+
+## Allenatori in Squadra
+
+Nella tab Rosa gli allenatori attivi compaiono in cima, con foto, nome e la dicitura
+«Allenatore» dove i giocatori hanno il ruolo in campo (`ruoloVisibile()`); niente numero,
+statistiche né badge, e niente posto nella tab Stats. Chi usa l'app da allenatore vede solo
+Rosa e Stats, senza badge e senza cacche (criterio «Cacche» e riga «Cacche/partita»). La
+specifica completa sta in [allenatore.md](allenatore.md).
+
+## Gestione dati squadra (solo amministratore)
+
+Da `/admin` un amministratore può ([DD-017](../DESIGN_DECISIONS.md#dd-017--lamministratore-può-compilare-i-dati-al-posto-del-giocatore)):
+
+| Azione                         | Hook                     | Effetto                                                                                                                                                                          |
+| ------------------------------ | ------------------------ | -------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- |
+| Modificare dati squadra        | `useSalvaDatiSquadra()`  | Nome, cognome, numero, ruolo, email (usata per il collegamento automatico, non il dato personale del profilo)                                                                    |
+| Aggiungere un giocatore        | `useAggiungiGiocatore()` | Nuova riga con id progressivo `g<N>` (`prossimoIdGiocatore()`), non generato dal database; con tipo «Allenatore» senza numero né ruolo (DD-034)                                  |
+| Attivare/disattivare           | `useImpostaAttivo()`     | Non elimina la riga: la storia della stagione resta intatta                                                                                                                      |
+| Scollegare un account          | `useScollegaAccount()`   | Libera uno slot collegato per errore ([DD-016](../DESIGN_DECISIONS.md#dd-016--schema-dati-profilo-giocatore-f0) regola 2); il giocatore si ricollega al primo accesso successivo |
+| Registrare il tesseramento CSI | `useSalvaTesseramento()` | Numero e data tessera, note solo dopo il tesseramento effettivo (vedi `profilo-giocatore.md`)                                                                                    |
+
+Il collegamento giocatore↔account, invece, non è manuale: avviene in automatico al primo
+accesso con Google, per corrispondenza email
+([DD-018](../DESIGN_DECISIONS.md#dd-018--collegamento-automatico-giocatoreaccount-per-email)).
+`useCollegaGiocatore()` esiste per completare quel flusso, non per una scelta libera
+dell'admin.
+
+Le regole di validazione (`validaDatiSquadra()`, `numeroGiaUsato()`) rispecchiano i vincoli
+della tabella (numero maglia univoco tra gli attivi, campi obbligatori): l'obiettivo è
+mostrare un messaggio leggibile invece di far arrivare un errore Postgres grezzo
+all'amministratore.
+
+## Classifica interna di Squadra
+
+La tab "Stats" di `/squadra` mostra una classifica interna ordinabile per 5 criteri
+(`CriterioClassifica` in `rosa.ts`): presenze, media voto, MVP, palloni, cacche/partita.
+`classificaRank()` calcola un "dense rank" (a parità di valore stessa posizione, il
+successivo non salta — 1, 1, 2, non 1, 1, 3); `dettaglioClassifica()` sceglie quale
+sottostatistica mostrare sotto il nome, coerente col criterio selezionato (es. "voti
+pagella" per il criterio media voto, non sempre "presenze consecutive").
+
+Le altre tab di `/squadra` (Rosa, Obiettivi, Badge) sono viste diverse sugli stessi dati di
+`useRosa()`/`useObiettivi()`/`badges.ts`: non introducono altra logica di dominio, solo
+presentazione — le rispettive specifiche stanno in `badge.md` e `obiettivi-squadra.md`.
+
+---
+
+## Limiti noti
+
+1. **`src/lib/crapp-data.ts` resta come fallback**, non più come fonte viva: se il database
+   non risponde o non è ancora popolato, `rosaFallback()` genera una rosa di riserva dai
+   dati statici storici. Un ambiente nuovo senza dati in `giocatori_squadra` mostra quindi
+   comunque una squadra, non una schermata vuota — ma è la rosa 2025/26 hardcoded, non
+   quella reale.

package.json

@@ -1,6 +1,6 @@
 {
-  "name": "tanstack_start_ts",
-  "version": "0.1.0",
+  "name": "crapp",
+  "version": "1.1.1",
   "private": true,
   "sideEffects": false,
   "type": "module",
@@ -10,6 +10,7 @@
     "build:dev": "vite build --mode development",
     "preview": "vite preview",
     "lint": "eslint .",
+    "typecheck": "tsc --noEmit",
     "format": "prettier --write .",
     "test": "bun test/run.ts",
     "test:integration": "bun test/run.ts integration",
@@ -17,7 +18,6 @@
     "test:all": "bun test/run.ts all"
   },
   "dependencies": {
-    "@lovable.dev/cloud-auth-js": "^1.1.2",
     "@supabase/supabase-js": "^2.111.0",
     "@tailwindcss/vite": "^4.2.1",
     "@tanstack/react-query": "^5.101.1",
@@ -39,7 +39,7 @@
   },
   "devDependencies": {
     "@eslint/js": "^9.32.0",
-    "@lovable.dev/vite-tanstack-config": "2.8.5",
+    "@tanstack/devtools-vite": "^0.8.3",
     "@types/canvas-confetti": "^1.9.0",
     "@types/node": "^22.16.5",
     "@types/react": "^19.2.0",

src/components/crapp/AvvisoCertificati.tsx

@@ -0,0 +1,113 @@
+import { AlertCircle } from "lucide-react";
+import { Link } from "@tanstack/react-router";
+import { useProfili } from "@/lib/profili";
+import {
+  avvisiCertificati,
+  formatDataBreve,
+  testoScadenza,
+  type AvvisoCertificato,
+} from "@/lib/profili-core";
+import { useGiocatoriSquadra } from "@/lib/giocatori-squadra";
+import { oggiISO } from "@/lib/palloni-core";
+import { useIsAdmin, useRuoliPronti } from "@/lib/ruoli";
+import { useGiocatoreBase } from "@/lib/user-store";
+
+function Card({
+  colore,
+  titolo,
+  righe,
+  cliccabile,
+}: {
+  colore: "warning" | "primary";
+  titolo: string;
+  righe: string[];
+  cliccabile?: boolean;
+}) {
+  const classi = `mx-5 mt-4 block rounded-3xl p-4 shadow-pop ${
+    colore === "warning"
+      ? "bg-warning text-warning-foreground"
+      : "bg-primary text-primary-foreground"
+  } ${cliccabile ? "premi" : ""}`;
+  const contenuto = (
+    <>
+      <p className="flex items-center gap-2 font-display text-lg uppercase leading-none">
+        <AlertCircle className="h-5 w-5" /> {titolo}
+      </p>
+      {righe.map((r) => (
+        <p key={r} className="mt-2 text-xs leading-snug opacity-90">
+          {r}
+        </p>
+      ))}
+    </>
+  );
+  return cliccabile ? (
+    <Link to="/profilo" search={{ tab: "documenti" }} className={classi}>
+      {contenuto}
+    </Link>
+  ) : (
+    <div className={classi}>{contenuto}</div>
+  );
+}
+
+/** Avviso certificati in scadenza/scaduti (DD-035): calcolato al volo, niente push. */
+export function AvvisoCertificati() {
+  const admin = useIsAdmin();
+  const ruoliPronti = useRuoliPronti();
+  const base = useGiocatoreBase();
+  const { righe: rosa } = useGiocatoriSquadra();
+  const { profili, isPending } = useProfili();
+
+  if (!ruoliPronti || isPending) return null;
+
+  const oggi = oggiISO();
+
+  if (admin) {
+    const { scaduti, inScadenza } = avvisiCertificati(rosa, profili, oggi);
+    if (scaduti.length === 0 && inScadenza.length === 0) return null;
+    return (
+      <>
+        {scaduti.length > 0 ? (
+          <Card
+            colore="primary"
+            titolo="Certificati scaduti"
+            righe={scaduti.map((a) => rigaStaff(a, `scaduto il ${formatDataBreve(a.scadenza)}`))}
+          />
+        ) : null}
+        {inScadenza.length > 0 ? (
+          <Card
+            colore="warning"
+            titolo="Certificati in scadenza"
+            righe={inScadenza.map((a) => rigaStaff(a, testoScadenza(a.giorni)))}
+          />
+        ) : null}
+      </>
+    );
+  }
+
+  if (!base) return null;
+  const { scaduti, inScadenza } = avvisiCertificati([base], profili, oggi);
+  const mio = scaduti[0] ?? inScadenza[0];
+  if (!mio) return null;
+
+  return mio.giorni < 0 ? (
+    <Card
+      colore="primary"
+      titolo="Certificato scaduto"
+      cliccabile
+      righe={[
+        `Il tuo certificato medico è scaduto il ${formatDataBreve(mio.scadenza)}: caricane uno nuovo`,
+      ]}
+    />
+  ) : (
+    <Card
+      colore="warning"
+      titolo="Certificato in scadenza"
+      cliccabile
+      righe={[`Il tuo certificato medico ${testoScadenza(mio.giorni)}`]}
+    />
+  );
+}
+
+function rigaStaff(a: AvvisoCertificato, dettaglio: string): string {
+  return `${a.nome} ${a.cognome} — ${dettaglio}`;
+}

src/components/crapp/BarraSottosezioni.tsx

@@ -1,46 +1,60 @@
 import { useEffect, useRef, useState, type ReactNode } from "react";
-import { motion, useReducedMotion } from "motion/react";
+import { motion, type Transition } from "motion/react";
 import { cn } from "@/lib/utils";
 import { proietta } from "@/lib/molla";
+import { useMotoRidotto } from "@/lib/motion";
 
 export type VoceSottosezione = {
   id: string;
   label: string;
   contenuto: ReactNode;
+  /** Se true, il pannello è a tutta larghezza (niente padding), es. barra filtri Classifica. */
+  aTuttoLarghezza?: boolean;
 };
 
 /** Tween breve: evita molle + exit che tengono due pannelli in DOM insieme. */
-const transizioneTab = { type: "tween" as const, duration: 0.16, ease: [0.25, 0.1, 0.25, 1] };
+const transizioneTab: Transition = { type: "tween", duration: 0.16, ease: [0.25, 0.1, 0.25, 1] };
 
 /**
- * Barra di sottosezioni in un'unica fila scorrevole (swipe orizzontale) e
- * pannello che mostra una sola sezione alla volta, cambiabile anche con
- * swipe sul contenuto.
+ * Barra di sottosezioni in un'unica fila e pannello che mostra una sola sezione
+ * alla volta, cambiabile anche con swipe sul contenuto.
  *
- * Il pannello precedente si smonta subito (niente AnimatePresence/exit):
- * al cambio tab resta un solo albero da animare in ingresso.
+ * `variante="sottolineatura"`: pillola piena sulla tab attiva (Squadra e Classifica CSI);
+ * su mobile la sola barra tab scorre in orizzontale senza allargare la pagina.
+ * Default `pillole`: tab a larghezza uguale (basata sulla etichetta più lunga); se non
+ * entrano nella viewport la barra scorre in orizzontale (Profilo). Il titolo ripetuto sotto
+ * la barra non viene mai mostrato: l’etichetta è già nella tab.
  */
 export function BarraSottosezioni({
   voci,
   defaultId,
+  variante = "pillole",
+  riempiLarghezza = false,
 }: {
   voci: VoceSottosezione[];
   defaultId?: string;
+  variante?: "pillole" | "sottolineatura";
+  /** Tab a larghezza uguale che riempiono la barra (es. Campionato, Squadra). */
+  riempiLarghezza?: boolean;
 }) {
   const [attiva, setAttiva] = useState(defaultId ?? voci[0]?.id ?? "");
   const direzione = useRef(0);
   const tabRefs = useRef<Record<string, HTMLButtonElement | null>>({});
-  const ridotto = useReducedMotion();
+  // `useMotoRidotto` copre anche i device deboli (RAM bassa), non solo
+  // `prefers-reduced-motion`: qui disattiva sia lo swipe orizzontale sia il
+  // blur della barra tab, i due costi maggiori all'ingresso in una pagina con
+  // sottosezioni (Squadra, Campionato, Profilo).
+  const ridotto = useMotoRidotto();
   const indice = Math.max(
     0,
     voci.findIndex((v) => v.id === attiva),
   );
   const voce = voci[indice] ?? voci[0];
+  const sottolineatura = variante === "sottolineatura";
 
   useEffect(() => {
-    // `auto`: lo smooth competerebbe col tween del pannello sul main thread.
     tabRefs.current[attiva]?.scrollIntoView({
-      behavior: "auto",
+      behavior: "smooth",
       inline: "center",
       block: "nearest",
     });
@@ -57,55 +71,92 @@ export function BarraSottosezioni({
   if (!voce) return null;
 
   return (
-    <div>
-      <div className="border-b border-border bg-background/80 pt-3 backdrop-blur-md">
+    <div className="min-w-0 max-w-full">
+      <div
+        className={cn(
+          "min-w-0 max-w-full border-b border-border bg-background",
+          !sottolineatura &&
+            (ridotto ? "bg-background pt-3" : "bg-background/80 pt-3 backdrop-blur-md"),
+        )}
+      >
+        {/* Solo la barra tab può scrollare in orizzontale: non allarga il layout pagina. */}
         <div
-          role="tablist"
-          aria-label="Sottosezioni"
-          className="-mx-0 flex snap-x snap-mandatory gap-1.5 overflow-x-auto px-5 pb-3 [scrollbar-width:none] [&::-webkit-scrollbar]:hidden"
+          className={cn(
+            "w-full max-w-full min-w-0 overflow-x-auto overflow-y-hidden [-webkit-overflow-scrolling:touch] [scrollbar-width:none] [&::-webkit-scrollbar]:hidden",
+            !sottolineatura && "pb-3",
+          )}
         >
-          {voci.map((v) => {
-            const selezionata = v.id === attiva;
-            return (
-              <button
-                key={v.id}
-                ref={(el) => {
-                  tabRefs.current[v.id] = el;
-                }}
-                type="button"
-                role="tab"
-                aria-selected={selezionata}
-                onClick={() => {
-                  const i = voci.findIndex((x) => x.id === v.id);
-                  vaiA(i);
-                }}
-                className={cn(
-                  // grow+basis-0: se le voci ci stanno riempiono la riga in parti uguali,
-                  // altrimenti shrink-0 le tiene leggibili e la barra torna a scorrere.
-                  "snap-center shrink-0 grow basis-0 rounded-full px-3.5 py-2 text-xs font-bold uppercase tracking-wide transition-colors",
-                  "min-h-11 touch-manipulation whitespace-nowrap",
-                  selezionata
-                    ? "bg-accent text-accent-foreground shadow-pop"
-                    : "bg-secondary text-muted-foreground",
-                )}
-              >
-                {v.label}
-              </button>
-            );
-          })}
+          <div
+            role="tablist"
+            aria-label="Sottosezioni"
+            className={cn(
+              riempiLarghezza
+                ? "flex w-full flex-nowrap"
+                : sottolineatura
+                  ? "flex w-max min-w-full flex-nowrap"
+                  : // Pillole: colonne uguali alla voce più lunga; overflow → scroll sul wrapper.
+                    "grid w-max min-w-full grid-flow-col auto-cols-[1fr]",
+              sottolineatura ? "gap-1 px-2 py-1.5" : "gap-1.5 px-5",
+            )}
+          >
+            {voci.map((v) => {
+              const selezionata = v.id === attiva;
+              return (
+                <button
+                  key={v.id}
+                  ref={(el) => {
+                    tabRefs.current[v.id] = el;
+                  }}
+                  type="button"
+                  role="tab"
+                  aria-selected={selezionata}
+                  onClick={() => {
+                    const i = voci.findIndex((x) => x.id === v.id);
+                    vaiA(i);
+                  }}
+                  className={cn(
+                    "min-h-11 touch-manipulation whitespace-nowrap text-sm font-bold uppercase tracking-wide transition-colors",
+                    riempiLarghezza ? "min-w-0 flex-1" : sottolineatura ? "shrink-0" : "w-full",
+                    sottolineatura
+                      ? cn(
+                          "rounded-xl px-1 py-2.5 text-center",
+                          selezionata
+                            ? "bg-accent text-accent-foreground shadow-pop"
+                            : "text-muted-foreground",
+                        )
+                      : cn(
+                          "rounded-full py-2 text-center",
+                          riempiLarghezza ? "px-2" : "px-3.5",
+                          selezionata
+                            ? "bg-accent text-accent-foreground shadow-pop"
+                            : "bg-secondary text-muted-foreground",
+                        ),
+                  )}
+                >
+                  {v.label}
+                </button>
+              );
+            })}
+          </div>
         </div>
       </div>
 
-      <div className="relative overflow-hidden">
+      <div className="relative min-w-0 overflow-hidden">
         <motion.div
           key={voce.id}
           role="tabpanel"
           aria-label={voce.label}
-          drag="x"
+          // Sui device deboli lo swipe orizzontale (pointer listener + hit-testing
+          // ad ogni frame) resta disattivato: si cambia tab solo toccando la barra.
+          drag={ridotto ? false : "x"}
           dragConstraints={{ left: 0, right: 0 }}
           dragElastic={0.12}
           dragMomentum={false}
           onDragEnd={(_, info) => {
+            // Uno scroll verticale (anche veloce) ha sempre offset.y ben maggiore di
+            // offset.x: la velocity.x, invece, può essere rumorosa su gesti rapidi e da
+            // sola non basta a distinguere uno swipe reale da un semplice scroll in giù.
+            if (Math.abs(info.offset.x) <= Math.abs(info.offset.y)) return;
             const arrivo = info.offset.x + proietta(info.velocity.x);
             if (arrivo < -60) vaiA(indice + 1);
             else if (arrivo > 60) vaiA(indice - 1);
@@ -113,9 +164,8 @@ export function BarraSottosezioni({
           initial={ridotto ? { opacity: 0 } : { opacity: 0, x: direzione.current * 20 }}
           animate={{ opacity: 1, x: 0 }}
           transition={ridotto ? { duration: 0.1 } : transizioneTab}
-          className="touch-pan-y px-5 py-4"
+          className={cn("touch-pan-y", voce.aTuttoLarghezza ? "px-0 pt-0 pb-4" : "px-5 py-4")}
         >
-          <h2 className="mb-3 font-display-sm text-lg uppercase">{voce.label}</h2>
           {voce.contenuto}
         </motion.div>
       </div>

src/components/crapp/BottomNav.tsx

@@ -1,7 +1,8 @@
 import { Link } from "@tanstack/react-router";
 import { CalendarDays, Home, Trophy, Users } from "lucide-react";
-import { motion, useReducedMotion } from "motion/react";
+import { motion } from "motion/react";
 import { molla } from "@/lib/molla";
+import { useMotoRidotto } from "@/lib/motion";
 
 // Quattro voci e non cinque: il profilo sta in alto a destra
 // nell'intestazione di ogni pagina, dove lo cerca chi arriva da iOS.
@@ -9,11 +10,14 @@ const items = [
   { to: "/", label: "Home", icon: Home },
   { to: "/calendario", label: "Calendario", icon: CalendarDays },
   { to: "/squadra", label: "Squadra", icon: Users },
-  { to: "/classifica", label: "Classifica", icon: Trophy },
+  { to: "/classifica", label: "Campionato", icon: Trophy },
 ] as const;
 
 export function BottomNav() {
-  const ridotto = useReducedMotion();
+  // `useMotoRidotto` copre anche i device deboli (RAM bassa), non solo
+  // `prefers-reduced-motion`: qui disattiva sia la molla della capsula sia il
+  // vetro sfocato, i due costi maggiori ad ogni cambio di rotta.
+  const ridotto = useMotoRidotto();
 
   return (
     <nav
@@ -62,11 +66,21 @@ export function BottomNav() {
       */}
       {/* `vetro` porta con sé le proprie ombre, quindi niente `shadow-chrome`:
           sarebbero due `box-shadow` sullo stesso elemento e una vincerebbe. */}
-      <div className="vetro pointer-events-auto mx-auto grid h-[var(--altezza-nav)] max-w-md grid-cols-4 rounded-full border border-white/40 p-1.5">
+      <div
+        className="vetro pointer-events-auto mx-auto grid h-[var(--altezza-nav)] max-w-md grid-cols-4 rounded-full border border-white/40 p-1.5"
+        // Su device deboli il backdrop-filter con feTurbulence/feDisplacementMap
+        // (solo Blink, cioè Android) e la molla della capsula sotto sono i due
+        // costi maggiori ad ogni cambio di rotta: `data-leggero` li disattiva.
+        {...(ridotto ? { "data-leggero": "" } : {})}
+      >
         {items.map(({ to, label, icon: Icon }) => (
           <Link
             key={to}
             to={to}
+            // Il chunk della pagina parte già al tocco (touchstart), non al tap completo:
+            // le 4 rotte sono piccole (8-12KB), nessun costo aggiuntivo di query (nessuna
+            // rotta usa `loader`, quindi non prefetcha dati, solo codice).
+            preload="intent"
             activeOptions={{ exact: to === "/" }}
             activeProps={{ "aria-current": "page" }}
             // Lo stato attivo non è solo colore: è la capsula piena sotto la

src/components/crapp/DettaglioCsi.tsx

@@ -0,0 +1,283 @@
+import { useState } from "react";
+import { ExternalLink, ShieldAlert, Users2 } from "lucide-react";
+import { cn } from "@/lib/utils";
+import { Card } from "@/components/crapp/ui-bits";
+import { useCsiPartita } from "@/lib/csi-partita";
+import type { FormazioneSquadra, PrecedentiCsi } from "@/lib/csi-core";
+
+/** Logo squadra dal portale CSI: nascosto invece che rotto se l'immagine non carica. */
+export function LogoSquadra({
+  src,
+  alt,
+  className,
+}: {
+  src: string;
+  alt: string;
+  className?: string;
+}) {
+  const [errore, setErrore] = useState(false);
+  if (!src || errore) return null;
+  return (
+    <img
+      src={src}
+      alt={alt}
+      loading="lazy"
+      onError={() => setErrore(true)}
+      className={cn("shrink-0 rounded-lg object-contain", className)}
+    />
+  );
+}
+
+/** Metadati leggeri sempre disponibili (nessuna fetch aggiuntiva): girone, n° gara, arbitro, referto. */
+export function MetaPartitaCsi({
+  girone,
+  numeroGara,
+  arbitro,
+  link,
+}: {
+  girone: string;
+  numeroGara: string;
+  arbitro: string;
+  link: string;
+}) {
+  const voci = [
+    girone,
+    numeroGara ? `N° gara ${numeroGara}` : "",
+    arbitro ? `Arbitro: ${arbitro}` : "",
+  ]
+    .filter(Boolean)
+    .join(" · ");
+  if (!voci && !link) return null;
+  return (
+    <div className="mt-3 flex flex-wrap items-center gap-2 text-xs text-muted-foreground">
+      {voci ? <span>{voci}</span> : null}
+      {link ? (
+        <a
+          href={link}
+          target="_blank"
+          rel="noreferrer"
+          className="inline-flex items-center gap-1 font-semibold text-accent"
+        >
+          Referto ufficiale CSI <ExternalLink className="h-3 w-3" />
+        </a>
+      ) : null}
+    </div>
+  );
+}
+
+function ListaFormazione({ squadra }: { squadra: FormazioneSquadra }) {
+  return (
+    <div>
+      <p className="text-xs font-bold uppercase tracking-wide text-muted-foreground">
+        {squadra.squadra}
+      </p>
+      <div className="mt-2 space-y-1">
+        {squadra.titolari.map((g, i) => (
+          <div key={i} className="flex items-center gap-2 text-sm">
+            <span className="w-6 shrink-0 text-center font-display text-xs text-accent">
+              {g.numero}
+            </span>
+            <span className="min-w-0 flex-1 truncate">{g.nome}</span>
+            {g.ruolo ? <span className="text-xs text-muted-foreground">{g.ruolo}</span> : null}
+          </div>
+        ))}
+      </div>
+      {squadra.panchina.length > 0 ? (
+        <>
+          <p className="mt-3 text-[11px] font-bold uppercase text-muted-foreground/70">
+            A disposizione
+          </p>
+          <div className="mt-1 space-y-1">
+            {squadra.panchina.map((g, i) => (
+              <div key={i} className="flex items-center gap-2 text-xs text-muted-foreground">
+                <span className="w-6 shrink-0 text-center">{g.numero}</span>
+                <span className="min-w-0 flex-1 truncate">{g.nome}</span>
+              </div>
+            ))}
+          </div>
+        </>
+      ) : null}
+      {squadra.staff.length > 0 ? (
+        <div className="mt-3 space-y-0.5 text-xs text-muted-foreground">
+          {squadra.staff.map((s, i) => (
+            <div key={i}>
+              {s.nome} · {s.ruolo}
+            </div>
+          ))}
+        </div>
+      ) : null}
+    </div>
+  );
+}
+
+function BarraPrecedenti({
+  label,
+  noi,
+  avversario,
+}: {
+  label: string;
+  noi: number;
+  avversario: number;
+}) {
+  const totale = noi + avversario || 1;
+  return (
+    <div className="text-xs">
+      <div className="flex items-center justify-between text-muted-foreground">
+        <span className="font-bold text-foreground">{noi}</span>
+        <span>{label}</span>
+        <span className="font-bold text-foreground">{avversario}</span>
+      </div>
+      <div className="mt-1 flex h-1.5 overflow-hidden rounded-full bg-secondary">
+        <div className="bg-accent" style={{ width: `${(noi / totale) * 100}%` }} />
+      </div>
+    </div>
+  );
+}
+
+const NOME_NOI = "CRAP Volley";
+
+/** Intestazione con i nomi delle due squadre, per non dover ripeterli su ogni barra sotto. */
+function TestataSquadre({ avversario }: { avversario: string }) {
+  return (
+    <div className="flex items-center justify-between text-xs font-bold">
+      <span className="truncate text-accent">{NOME_NOI}</span>
+      <span className="truncate text-right text-muted-foreground">{avversario}</span>
+    </div>
+  );
+}
+
+function BarraProbabilita({
+  avversario,
+  noi,
+  avversarioPct,
+}: {
+  avversario: string;
+  noi: number;
+  avversarioPct: number;
+}) {
+  const favoritaNoi = noi >= avversarioPct;
+  return (
+    <div>
+      <p className="mb-2 text-xs text-muted-foreground">
+        Probabilità di vittoria (calcolo CSI):{" "}
+        <span className="font-bold text-foreground">{favoritaNoi ? NOME_NOI : avversario}</span>{" "}
+        favorita al {Math.max(noi, avversarioPct).toFixed(0)}%.
+      </p>
+      <div className="mb-1 flex items-center justify-between text-[11px] font-bold">
+        <span className={favoritaNoi ? "text-success" : "text-muted-foreground"}>{NOME_NOI}</span>
+        <span className={!favoritaNoi ? "text-success" : "text-muted-foreground"}>
+          {avversario}
+        </span>
+      </div>
+      <div className="flex h-7 overflow-hidden rounded-full">
+        <div
+          className="flex items-center justify-center bg-success text-xs font-bold text-success-foreground"
+          style={{ width: `${noi}%` }}
+        >
+          {noi.toFixed(0)}%
+        </div>
+        <div
+          className="flex items-center justify-center bg-destructive text-xs font-bold text-destructive-foreground"
+          style={{ width: `${avversarioPct}%` }}
+        >
+          {avversarioPct.toFixed(0)}%
+        </div>
+      </div>
+    </div>
+  );
+}
+
+function BloccoPrecedenti({
+  precedenti,
+  avversario,
+}: {
+  precedenti: PrecedentiCsi;
+  avversario: string;
+}) {
+  return (
+    <div className="space-y-3">
+      <TestataSquadre avversario={avversario} />
+      <p className="text-xs text-muted-foreground">
+        {precedenti.totale > 0
+          ? `${precedenti.totale} precedenti in archivio sul portale CSI.`
+          : "Nessun precedente in archivio sul portale CSI: primo confronto tra le due squadre."}
+      </p>
+      {precedenti.totale > 0 ? (
+        <>
+          <BarraPrecedenti
+            label="vittorie"
+            noi={precedenti.vinteNoi}
+            avversario={precedenti.vinteAvversario}
+          />
+          <BarraPrecedenti
+            label="in casa"
+            noi={precedenti.casaNoi}
+            avversario={precedenti.casaAvversario}
+          />
+          <BarraPrecedenti
+            label="fuori"
+            noi={precedenti.fuoriNoi}
+            avversario={precedenti.fuoriAvversario}
+          />
+        </>
+      ) : null}
+      {precedenti.probabilitaNoi !== null && precedenti.probabilitaAvversario !== null ? (
+        <BarraProbabilita
+          avversario={avversario}
+          noi={precedenti.probabilitaNoi}
+          avversarioPct={precedenti.probabilitaAvversario}
+        />
+      ) : null}
+    </div>
+  );
+}
+
+/**
+ * Formazioni e storico scontri diretti per una gara CSI: una fetch in più (cache 6h lato
+ * server), quindi va montato solo quando l'utente apre il dettaglio della gara, mai in una
+ * lista. `matchId` è l'id della gara sul portale CSI (`PartitaCsi.id`). `avversario` serve
+ * solo a etichettare le barre di "Scontri diretti" (nome squadra, non un dato dal CSI).
+ */
+export function DettaglioCsiEsteso({
+  matchId,
+  avversario,
+}: {
+  matchId: string;
+  avversario: string;
+}) {
+  const { data, isLoading } = useCsiPartita(matchId);
+
+  if (isLoading) {
+    return <p className="px-1 text-center text-xs text-muted-foreground">Carico i dati dal CSI…</p>;
+  }
+  if (!data || (!data.formazioni && !data.precedenti)) return null;
+
+  return (
+    <div className="space-y-4">
+      {data.giornata || data.nota ? (
+        <p className="text-xs text-muted-foreground">
+          {[data.giornata, data.nota].filter(Boolean).join(" · ")}
+        </p>
+      ) : null}
+      {data.formazioni ? (
+        <Card>
+          <div className="mb-3 flex items-center gap-2 text-sm font-bold">
+            <Users2 className="h-4 w-4 text-accent" /> Formazioni
+          </div>
+          <div className="grid grid-cols-1 gap-4 sm:grid-cols-2">
+            <ListaFormazione squadra={data.formazioni.noi} />
+            <ListaFormazione squadra={data.formazioni.avversario} />
+          </div>
+        </Card>
+      ) : null}
+      {data.precedenti ? (
+        <Card>
+          <div className="mb-3 flex items-center gap-2 text-sm font-bold">
+            <ShieldAlert className="h-4 w-4 text-accent" /> Scontri diretti
+          </div>
+          <BloccoPrecedenti precedenti={data.precedenti} avversario={avversario} />
+        </Card>
+      ) : null}
+    </div>
+  );
+}

src/components/crapp/EventoCard.tsx

@@ -1,34 +1,66 @@
-import { MapPin, Clock, Users, Cake, ArrowRight } from "lucide-react";
+import {
+  MapPin,
+  Clock,
+  Users,
+  Cake,
+  ChevronRight,
+  Check,
+  HelpCircle,
+  X,
+  Bandage,
+} from "lucide-react";
 import { Link } from "@tanstack/react-router";
 import { cn } from "@/lib/utils";
 import { Card } from "@/components/crapp/ui-bits";
 import { formatData, statoMeta, type Stato } from "@/lib/crapp-data";
 import type { Evento } from "@/lib/eventi";
-import { Barra } from "@/components/motion/Barra";
-import { useGiocatoriSquadra } from "@/lib/giocatori-squadra";
-import { usePresenzeEvento, useSalvaPresenza } from "@/lib/presenze";
-import { useGiocatoreCorrente } from "@/lib/user-store";
+import { inRosa, useGiocatoriSquadra } from "@/lib/giocatori-squadra";
+import { includeInfortunato, usePresenzeEvento, useSalvaPresenza } from "@/lib/presenze";
+import { useGiocatoreInCampo } from "@/lib/user-store";
 import { dataOggi } from "@/lib/scout-live";
 
 const tipoMeta = {
   partita: { label: "Partita", className: "bg-accent text-accent-foreground" },
   allenamento: { label: "Allenamento", className: "bg-training text-training-foreground" },
-  evento: { label: "Eventi", className: "bg-warning text-warning-foreground" },
+  evento: { label: "Evento", className: "bg-warning text-warning-foreground" },
   compleanno: { label: "Compleanno", className: "bg-success text-success-foreground" },
 } as const;
 
-const stati: Stato[] = ["presente", "forse", "ritardo", "assente", "infortunato"];
+const statiBase: Stato[] = ["presente", "forse", "ritardo", "assente"];
+
+/** Icone compatte per la riga unica dei controlli presenza (mockup). */
+const iconeStato: Record<Stato, typeof Check> = {
+  presente: Check,
+  forse: HelpCircle,
+  ritardo: Clock,
+  assente: X,
+  /** Cerotto singolo: leggibile a 16px e allineato all'emoji 🩹. */
+  infortunato: Bandage,
+};
 
 export function linkPerEvento(e: Evento) {
   if (e.tipo === "partita") {
-    return { to: "/partita/$id", params: { id: e.id }, label: "Apri partita" };
+    return { to: "/partita/$id" as const, params: { id: e.id }, label: "Dettaglio partita" };
   }
   if (e.tipo === "allenamento") {
-    return { to: "/allenamento/$id", params: { id: e.id }, label: "Apri allenamento" };
+    return {
+      to: "/allenamento/$id" as const,
+      params: { id: e.id },
+      label: "Dettaglio allenamento",
+    };
+  }
+  if (e.tipo === "evento") {
+    return { to: "/evento/$id" as const, params: { id: e.id }, label: "Dettaglio evento" };
   }
   return undefined;
 }
 
+function etichettaData(iso: string) {
+  const giorno = iso.slice(8, 10);
+  const mese = formatData(iso).split(" ")[2]?.slice(0, 3)?.toUpperCase() ?? "";
+  return `${giorno} ${mese}`;
+}
+
 export function EventoCard({
   evento,
   linkTo,
@@ -38,9 +70,12 @@ export function EventoCard({
 }) {
   const { risposte } = usePresenzeEvento(evento.id);
   const salva = useSalvaPresenza();
-  const io = useGiocatoreCorrente();
+  // Solo `io.id` serve qui (per leggere/scrivere la propria risposta, `null` per l'allenatore
+  // che non risponde, DD-034): `useGiocatoreInCampo` legge la sola anagrafica, non le statistiche di tutta la rosa di `useGiocatoreCorrente`.
+  // Rilevante perché ogni card monta questo hook: il Calendario ne rende diverse insieme.
+  const io = useGiocatoreInCampo();
   const { righe: squadra } = useGiocatoriSquadra();
-  const rosa = squadra.filter((g) => g.attivo);
+  const rosa = squadra.filter(inRosa);
   const stato = io ? risposte[io.id] : undefined;
   const presentiVeri = rosa.filter(
     (g) => risposte[g.id] === "presente" || risposte[g.id] === "ritardo",
@@ -50,9 +85,14 @@ export function EventoCard({
       ? { label: "Amichevole", className: "bg-accent/70 text-accent-foreground" }
       : tipoMeta[evento.tipo];
   const totale = rosa.length;
-  const perc = totale ? Math.round((presentiVeri / totale) * 100) : 0;
   const isCompleanno = evento.tipo === "compleanno";
   const passato = evento.data < dataOggi();
+  const cliccabile = Boolean(linkTo);
+  /** Anteprima delle note anche in card per gli eventi extra-campo (oltre al dettaglio). */
+  const noteCard = evento.tipo === "evento" ? evento.note.trim() : "";
+  const stati = includeInfortunato(evento.tipo, stato)
+    ? [...statiBase, "infortunato" as const]
+    : statiBase;
 
   if (isCompleanno) {
     return (
@@ -64,20 +104,39 @@ export function EventoCard({
           <h3 className="truncate text-sm font-bold leading-tight">{evento.titolo}</h3>
           <p className="text-xs text-muted-foreground">{evento.luogo}</p>
         </div>
-        <div className="shrink-0 rounded-2xl bg-secondary px-3 py-2 text-center">
-          <p className="font-display text-xl leading-none">{evento.data.slice(8, 10)}</p>
-          <p className="text-xs font-semibold uppercase text-muted-foreground">
-            {formatData(evento.data).split(" ")[2]?.slice(0, 3)}
-          </p>
+        <div className="shrink-0 text-right text-xs font-bold uppercase tracking-wide text-muted-foreground">
+          {etichettaData(evento.data)}
         </div>
       </Card>
     );
   }
 
+  const sottotitoloPartita =
+    evento.tipo === "partita"
+      ? `${evento.casa ? "Casa" : "Trasferta"}${evento.campionato ? " · Campionato" : " · Amichevole"}`
+      : null;
+  const metaStato = stato ? statoMeta[stato] : null;
+
   return (
-    <Card>
-      <div className="flex items-start justify-between gap-3">
-        <div className="min-w-0">
+    <Card
+      as="article"
+      className={cn(
+        "relative overflow-hidden p-0",
+        cliccabile && "transition-transform active:scale-[0.99]",
+      )}
+    >
+      {/* Link a tutta card: i controlli sopra (z-10) restano indipendenti. */}
+      {linkTo ? (
+        <Link
+          to={linkTo.to}
+          params={linkTo.params}
+          aria-label={linkTo.label}
+          className="absolute inset-0 z-0 rounded-3xl focus-visible:outline-none focus-visible:ring-2 focus-visible:ring-ring focus-visible:ring-offset-2"
+        />
+      ) : null}
+
+      <div className={cn("relative z-10 p-4", linkTo && "pointer-events-none")}>
+        <div className="flex items-start justify-between gap-3">
           <span
             className={cn(
               "inline-block rounded-full px-2.5 py-0.5 text-xs font-bold uppercase tracking-wide",
@@ -86,76 +145,89 @@ export function EventoCard({
           >
             {tipo.label}
           </span>
-          <h3 className="mt-2 text-base font-bold leading-tight">{evento.titolo}</h3>
+          <span className="inline-flex shrink-0 items-center gap-0.5 text-sm font-bold uppercase tracking-wide text-muted-foreground">
+            {etichettaData(evento.data)}
+            {linkTo ? <ChevronRight className="h-4 w-4" aria-hidden /> : null}
+          </span>
         </div>
-        <div className="shrink-0 rounded-2xl bg-secondary px-3 py-2 text-center">
-          <p className="font-display text-xl leading-none">{evento.data.slice(8, 10)}</p>
-          <p className="text-xs font-semibold uppercase text-muted-foreground">
-            {formatData(evento.data).split(" ")[2]?.slice(0, 3)}
-          </p>
-        </div>
-      </div>
 
-      {linkTo && (
-        <div className="mt-2 flex justify-end">
-          <Link
-            to={linkTo.to}
-            params={linkTo.params}
-            className="inline-flex min-h-11 items-center gap-1 rounded-full bg-primary px-4 text-xs font-bold uppercase tracking-wide text-primary-foreground transition-transform active:scale-95"
+        <h3 className="mt-2 text-base font-bold leading-tight">{evento.titolo}</h3>
+        {sottotitoloPartita ? (
+          <p className="mt-0.5 text-xs text-muted-foreground">{sottotitoloPartita}</p>
+        ) : null}
+
+        <div className="mt-2.5 flex flex-wrap gap-x-3 gap-y-1 text-[13px] text-muted-foreground">
+          <span className="inline-flex items-center gap-1">
+            <Clock className="h-3.5 w-3.5 shrink-0" aria-hidden />
+            <span>{evento.ora}</span>
+          </span>
+          <span className="inline-flex min-w-0 items-center gap-1">
+            <MapPin className="h-3.5 w-3.5 shrink-0" aria-hidden />
+            <span className="truncate">{evento.luogo}</span>
+          </span>
+          <span className="inline-flex items-center gap-1">
+            <Users className="h-3.5 w-3.5 shrink-0" aria-hidden />
+            <span>
+              {presentiVeri}/{totale}
+            </span>
+          </span>
+        </div>
+
+        {noteCard ? (
+          <p className="mt-2.5 line-clamp-2 text-xs text-muted-foreground">📝 {noteCard}</p>
+        ) : null}
+
+        {metaStato ? (
+          <p
+            className="mt-3 flex items-center gap-1.5 border-t border-border pt-2.5 text-left text-xs font-semibold text-muted-foreground"
+            aria-live="polite"
           >
-            {linkTo.label} <ArrowRight className="h-3 w-3" />
-          </Link>
-        </div>
-      )}
+            <span aria-hidden>{metaStato.emoji}</span>
+            <span>{metaStato.label}</span>
+          </p>
+        ) : null}
 
-      <div className="mt-3 flex flex-wrap gap-x-4 gap-y-1 text-xs text-muted-foreground">
-        <span className="inline-flex items-center gap-1">
-          <Clock className="h-3.5 w-3.5" /> {evento.ora}
-        </span>
-        <span className="inline-flex min-w-0 items-center gap-1">
-          <MapPin className="h-3.5 w-3.5 shrink-0" />
-          <span className="truncate">{evento.luogo}</span>
-        </span>
-        <span className="inline-flex items-center gap-1">
-          <Users className="h-3.5 w-3.5" /> {presentiVeri}/{totale}
-        </span>
+        {io ? (
+          <div
+            className={cn("pointer-events-auto flex w-full gap-1", metaStato ? "mt-2.5" : "mt-3")}
+            role="group"
+            aria-label="La tua presenza"
+          >
+            {stati.map((s) => {
+              const meta = statoMeta[s];
+              const Icon = iconeStato[s];
+              const attivo = stato === s;
+              return (
+                <button
+                  key={s}
+                  type="button"
+                  disabled={salva.isPending || passato}
+                  onClick={(e) => {
+                    e.preventDefault();
+                    e.stopPropagation();
+                    salva.mutate({
+                      eventoId: evento.id,
+                      giocatoreId: io.id,
+                      stato: attivo ? null : s,
+                    });
+                  }}
+                  aria-pressed={attivo}
+                  aria-label={meta.label}
+                  title={meta.label}
+                  className={cn(
+                    "inline-flex min-h-11 min-w-0 flex-1 items-center justify-center rounded-xl px-1 transition-all active:scale-95 disabled:opacity-50",
+                    attivo
+                      ? cn(meta.className, "shadow-card")
+                      : "bg-secondary text-muted-foreground",
+                  )}
+                >
+                  <Icon className="h-4 w-4 shrink-0" aria-hidden />
+                </button>
+              );
+            })}
+          </div>
+        ) : null}
       </div>
-
-      <Barra percentuale={perc} altezza="h-1.5" trackClassName="mt-3" />
-
-      {io ? (
-        <div className="mt-4 flex flex-wrap gap-2">
-          {stati.map((s) => {
-            const meta = statoMeta[s];
-            const attivo = stato === s;
-            return (
-              <button
-                key={s}
-                type="button"
-                disabled={salva.isPending || passato}
-                onClick={() =>
-                  salva.mutate({
-                    eventoId: evento.id,
-                    giocatoreId: io.id,
-                    stato: attivo ? null : s,
-                  })
-                }
-                aria-pressed={attivo}
-                className={cn(
-                  // min-h-11: sono i controlli più toccati dell'app, sotto i
-                  // 44px si sbaglia bersaglio.
-                  "min-h-11 rounded-full border border-border px-3 text-xs font-semibold transition-all active:scale-95 disabled:opacity-50",
-                  attivo
-                    ? cn(meta.className, "border-transparent shadow-card")
-                    : "bg-background text-muted-foreground",
-                )}
-              >
-                {meta.label}
-              </button>
-            );
-          })}
-        </div>
-      ) : null}
     </Card>
   );
 }

src/components/crapp/Pagelle.tsx

@@ -5,7 +5,7 @@ import { cn } from "@/lib/utils";
 import { Card } from "@/components/crapp/ui-bits";
 import { Avatar } from "@/components/crapp/Avatar";
 import type { Giocatore } from "@/lib/crapp-data";
-import { useGiocatoreCorrente } from "@/lib/user-store";
+import { useGiocatoreInCampo } from "@/lib/user-store";
 import { mieiVoti, pagellePartita, usePagelle, useVotaPagella } from "@/lib/pagelle";
 
 const voti = [1, 2, 3, 4, 5, 6, 7, 8, 9, 10];
@@ -20,7 +20,8 @@ export function Pagelle({
   convocati: Giocatore[];
   chiuse?: boolean;
 }) {
-  const io = useGiocatoreCorrente();
+  // Solo `.id` serve qui, niente statistiche; `null` per l'allenatore, che non gioca (DD-034).
+  const io = useGiocatoreInCampo();
   const { voti: tutti, isPending } = usePagelle();
   const vota = useVotaPagella();
   const [apertoPer, setApertoPer] = useState<string | null>(null);

src/components/crapp/ProfiloAmministrativo.tsx

@@ -12,8 +12,10 @@ import {
   useSalvaProfilo,
   type SezioneFile,
 } from "@/lib/profili";
+import { useSalvaNomeAllenatore, type GiocatoreSquadra } from "@/lib/giocatori-squadra";
 import {
   completamento,
+  completamentoAllenatore,
   profiloVuoto,
   sezioniComplete,
   type Profilo,
@@ -244,6 +246,138 @@ export function CampiProfilo({
   );
 }
 
+/**
+ * I dati personali dell'allenatore (DD-034): gli stessi campi di `profili_giocatore`, meno
+ * indirizzo, documento, certificato e foto tessera. Condivisi tra Profilo e dashboard admin.
+ */
+export function CampiAllenatore({
+  corrente,
+  aggiorna,
+}: {
+  corrente: Profilo;
+  aggiorna: (patch: Partial<Profilo>) => void;
+}) {
+  return (
+    <>
+      <div className="grid grid-cols-2 gap-3">
+        <Campo label="Data di nascita">
+          <input
+            type="date"
+            value={corrente.dataNascita ?? ""}
+            onChange={(e) => aggiorna({ dataNascita: e.target.value })}
+            className={classiInput}
+          />
+        </Campo>
+        <Campo label="Luogo di nascita">
+          <input
+            value={corrente.luogoNascita ?? ""}
+            maxLength={80}
+            onChange={(e) => aggiorna({ luogoNascita: e.target.value })}
+            className={classiInput}
+          />
+        </Campo>
+      </div>
+      <div className="grid grid-cols-2 gap-3">
+        <Campo label="Telefono">
+          <input
+            type="tel"
+            value={corrente.telefono ?? ""}
+            maxLength={20}
+            onChange={(e) => aggiorna({ telefono: e.target.value })}
+            className={classiInput}
+          />
+        </Campo>
+        <Campo label="Email">
+          <input
+            type="email"
+            value={corrente.email ?? ""}
+            maxLength={120}
+            onChange={(e) => aggiorna({ email: e.target.value })}
+            className={classiInput}
+          />
+        </Campo>
+      </div>
+    </>
+  );
+}
+
+/**
+ * Tab Docs dell'allenatore: nome e cognome (sul proprio slot, M21) più i dati personali
+ * ridotti. Un solo pulsante salva entrambi.
+ */
+export function ProfiloAllenatore({ g }: { g: GiocatoreSquadra }) {
+  const { profili } = useProfili();
+  const salvaProfilo = useSalvaProfilo();
+  const salvaNome = useSalvaNomeAllenatore();
+  const [bozza, setBozza] = useState<Profilo | null>(null);
+  const [nome, setNome] = useState<{ nome: string; cognome: string } | null>(null);
+
+  const corrente = bozza ?? profili[g.id] ?? profiloVuoto(g.id);
+  const nomeCorrente = nome ?? { nome: g.nome, cognome: g.cognome };
+  const sporco = bozza !== null || nome !== null;
+  const inCorso = salvaProfilo.isPending || salvaNome.isPending;
+  const perc = completamentoAllenatore(corrente);
+
+  async function salva() {
+    try {
+      if (nome) await salvaNome.mutateAsync({ giocatoreId: g.id, ...nome });
+      if (bozza) await salvaProfilo.mutateAsync(bozza);
+      setNome(null);
+      setBozza(null);
+      toast.success("Profilo aggiornato");
+    } catch (errore) {
+      toast.error(errore instanceof Error ? errore.message : "Salvataggio non riuscito");
+    }
+  }
+
+  return (
+    <div className="space-y-3 rounded-3xl bg-card p-4 shadow-card">
+      <div className="flex items-center justify-between gap-2">
+        <div className="h-1.5 min-w-0 flex-1 overflow-hidden rounded-full bg-secondary">
+          <div
+            className="h-full rounded-full bg-accent-grad transition-all"
+            style={{ width: `${perc}%` }}
+          />
+        </div>
+        <span className="shrink-0 text-xs font-bold tabular-nums text-muted-foreground">
+          {perc}%
+        </span>
+      </div>
+
+      <Intestazione titolo="Dati personali" completa={perc === 100} />
+      <div className="grid grid-cols-2 gap-3">
+        <Campo label="Nome">
+          <input
+            value={nomeCorrente.nome}
+            maxLength={40}
+            onChange={(e) => setNome({ ...nomeCorrente, nome: e.target.value })}
+            className={classiInput}
+          />
+        </Campo>
+        <Campo label="Cognome">
+          <input
+            value={nomeCorrente.cognome}
+            maxLength={40}
+            onChange={(e) => setNome({ ...nomeCorrente, cognome: e.target.value })}
+            className={classiInput}
+          />
+        </Campo>
+      </div>
+      <CampiAllenatore corrente={corrente} aggiorna={(p) => setBozza({ ...corrente, ...p })} />
+
+      <button
+        type="button"
+        onClick={() => void salva()}
+        disabled={!sporco || inCorso}
+        className="premi flex w-full items-center justify-center gap-2 rounded-2xl bg-accent-grad py-3 text-sm font-bold uppercase text-accent-foreground shadow-pop disabled:opacity-50"
+      >
+        {inCorso ? <Loader2 className="h-4 w-4 animate-spin" /> : null}
+        {sporco ? "Salva" : "Salvato"}
+      </button>
+    </div>
+  );
+}
+
 /**
  * Dati amministrativi del giocatore: quello che la dashboard amministratore poi legge.
  * Ogni giocatore scrive solo la propria riga — è la RLS a garantirlo, non questo componente.
@@ -304,10 +438,6 @@ export function ProfiloAmministrativo({
         </span>
       </div>
 
-      <p className="text-xs text-muted-foreground">
-        Servono agli amministratori per il tesseramento CSI. Li vedi solo tu e loro.
-      </p>
-
       <CampiProfilo
         corrente={corrente}
         aggiorna={aggiorna}
@@ -384,13 +514,18 @@ export function ProfiloAmministrativo({
  */
 export function CompletaProfilo({
   giocatoreId,
+  allenatore = false,
   indice = 0,
 }: {
   giocatoreId: string;
+  /** L'allenatore ha solo i dati personali ridotti (DD-034). */
+  allenatore?: boolean;
   indice?: number;
 }) {
   const { profili, isPending } = useProfili();
-  const perc = completamento(profili[giocatoreId]);
+  const perc = allenatore
+    ? completamentoAllenatore(profili[giocatoreId])
+    : completamento(profili[giocatoreId]);
   if (isPending || perc === 100) return null;
 
   return (
@@ -401,10 +536,10 @@ export function CompletaProfilo({
         className="premi block rounded-3xl bg-card p-4 shadow-card"
       >
         <div className="flex items-center justify-between gap-3">
-          <span className="font-display text-sm uppercase tracking-wide">
+          <span className="font-display text-[15px] uppercase tracking-wide">
             Completa il tuo profilo
           </span>
-          <span className="text-xs font-bold tabular-nums text-muted-foreground">{perc}%</span>
+          <span className="text-[13px] font-bold tabular-nums text-muted-foreground">{perc}%</span>
         </div>
         <div className="mt-2 h-1.5 overflow-hidden rounded-full bg-secondary">
           <div
@@ -412,8 +547,10 @@ export function CompletaProfilo({
             style={{ width: `${perc}%` }}
           />
         </div>
-        <p className="mt-2 text-xs text-muted-foreground">
-          Documento, certificato medico e foto tessera servono per il tesseramento CSI.
+        <p className="mt-2 text-[13px] text-muted-foreground">
+          {allenatore
+            ? "Data e luogo di nascita, telefono ed email."
+            : "Documento, certificato medico e foto tessera servono per il tesseramento CSI."}
         </p>
       </Link>
     </Reveal>

src/components/crapp/PromemoriaPalloni.tsx

@@ -3,11 +3,12 @@ import { formatData } from "@/lib/crapp-data";
 import { eventiPalloni, eventoPrecedente, eventoSuccessivo, oggiISO } from "@/lib/palloni-core";
 import { useTurniPalloni } from "@/lib/palloni";
 import { useEventi } from "@/lib/eventi";
-import { useGiocatoreCorrente } from "@/lib/user-store";
+import { useGiocatoreInCampo } from "@/lib/user-store";
 
 /** Avvisi per chi è di turno: prendere i palloni oggi, o riportarli oggi. */
 export function PromemoriaPalloni() {
-  const io = useGiocatoreCorrente();
+  // Solo `.id` serve qui, niente statistiche; `null` per l'allenatore, che non gioca (DD-034). Montato in Home.
+  const io = useGiocatoreInCampo();
   const { turni } = useTurniPalloni();
   const { eventi } = useEventi();
   if (!io) return null;

src/components/crapp/RosaPresenze.tsx

@@ -6,21 +6,35 @@ import { Card } from "@/components/crapp/ui-bits";
 import { Avatar } from "@/components/crapp/Avatar";
 import { Barra } from "@/components/motion/Barra";
 import { statoMeta, type Giocatore, type Stato } from "@/lib/crapp-data";
+import type { EventoTipo } from "@/lib/eventi";
 import { usePresenzeEvento, useSalvaPresenza } from "@/lib/presenze";
-import { useRosa } from "@/lib/rosa";
-import { useGiocatoreCorrente } from "@/lib/user-store";
+import { useAnagraficaRosa } from "@/lib/rosa";
+import { useGiocatoreBase, useGiocatoreInCampo } from "@/lib/user-store";
 import { intestazioniAutenticate } from "@/lib/auth";
-import { useIsAdmin } from "@/lib/ruoli";
+import { usePuoGestireEventi } from "@/lib/ruoli";
 import { dataOggi } from "@/lib/scout-live";
 
 const ordine: Stato[] = ["presente", "ritardo", "forse", "infortunato", "assente"];
 
-export function RosaPresenze({ eventoId, data }: { eventoId: string; data: string }) {
+export function RosaPresenze({
+  eventoId,
+  data,
+  tipo = "allenamento",
+}: {
+  eventoId: string;
+  data: string;
+  /** Negli eventi extra-campo "infortunato" non è pertinente: niente badge né opzione. */
+  tipo?: EventoTipo;
+}) {
   const { risposte, isPending } = usePresenzeEvento(eventoId);
   const salva = useSalvaPresenza();
-  const io = useGiocatoreCorrente();
-  const admin = useIsAdmin();
-  const rosa = useRosa();
+  // Solo `.id`/`.nome` servono qui: `useGiocatoreBase`/`useAnagraficaRosa` bastano,
+  // niente statistiche di squadra.
+  const io = useGiocatoreInCampo();
+  // Il nome di chi sollecita: admin o allenatore, che non ha una risposta propria (DD-034).
+  const mittente = useGiocatoreBase();
+  const puoSollecitare = usePuoGestireEventi();
+  const rosa = useAnagraficaRosa();
   const [sollecito, setSollecito] = useState(false);
   const passato = data < dataOggi();
 
@@ -28,6 +42,7 @@ export function RosaPresenze({ eventoId, data }: { eventoId: string; data: strin
   const risposteN = rosa.length - mancanti.length;
   const perc = rosa.length ? Math.round((risposteN / rosa.length) * 100) : 0;
   const daSollecitare = mancanti.length + rosa.filter((g) => risposte[g.id] === "forse").length;
+  const ordineVisibile = tipo === "evento" ? ordine.filter((s) => s !== "infortunato") : ordine;
 
   async function sollecita() {
     setSollecito(true);
@@ -35,7 +50,7 @@ export function RosaPresenze({ eventoId, data }: { eventoId: string; data: strin
       const res = await fetch("/api/public/sollecita-presenze", {
         method: "POST",
         headers: { "Content-Type": "application/json", ...(await intestazioniAutenticate()) },
-        body: JSON.stringify({ eventoId, da: io?.nome }),
+        body: JSON.stringify({ eventoId, da: mittente?.nome }),
       });
       if (!res.ok) throw new Error();
       const dati = (await res.json()) as { inviate: number; destinatari: number };
@@ -63,7 +78,7 @@ export function RosaPresenze({ eventoId, data }: { eventoId: string; data: strin
         <Barra percentuale={perc} altezza="h-1.5" trackClassName="mt-2" />
 
         <div className="mt-3 flex flex-wrap gap-1.5">
-          {ordine.map((s) => {
+          {ordineVisibile.map((s) => {
             const n = rosa.filter((g) => risposte[g.id] === s).length;
             return (
               <span
@@ -88,7 +103,7 @@ export function RosaPresenze({ eventoId, data }: { eventoId: string; data: strin
               La tua risposta
             </p>
             <div className="mt-2 flex flex-wrap gap-1.5">
-              {ordine.map((s) => {
+              {ordineVisibile.map((s) => {
                 const attivo = risposte[io.id] === s;
                 return (
                   <button
@@ -113,7 +128,7 @@ export function RosaPresenze({ eventoId, data }: { eventoId: string; data: strin
           </div>
         ) : null}
 
-        {admin ? (
+        {puoSollecitare ? (
           <button
             type="button"
             onClick={sollecita}
@@ -136,7 +151,7 @@ export function RosaPresenze({ eventoId, data }: { eventoId: string; data: strin
         </p>
       ) : null}
 
-      {ordine.map((s) => {
+      {ordineVisibile.map((s) => {
         const lista = rosa.filter((g) => risposte[g.id] === s);
         if (lista.length === 0) return null;
         return (
@@ -169,7 +184,7 @@ function Gruppo({
 }: {
   titolo: string;
   n: number;
-  lista: Giocatore[];
+  lista: Array<Pick<Giocatore, "id" | "nome" | "ruolo" | "numero">>;
   attenzione?: boolean;
 }) {
   return (

src/components/crapp/ScoutEntry.tsx

@@ -2,7 +2,7 @@ import { Link } from "@tanstack/react-router";
 import { ChevronRight, Lock, Radio } from "lucide-react";
 import { cn } from "@/lib/utils";
 import { sessioneScaduta, usePartitaDiOggi, useSessioneScout } from "@/lib/scout-live";
-import { useGiocatoreCorrente } from "@/lib/user-store";
+import { useGiocatoreBase } from "@/lib/user-store";
 
 /**
  * Accesso allo scout live: attivo solo il giorno della partita e se nessun altro lo sta usando.
@@ -17,7 +17,8 @@ export function ScoutEntry({
 }) {
   const { pronto, partita: diOggi } = usePartitaDiOggi();
   const partita = eventoId && diOggi?.id !== eventoId ? null : diOggi;
-  const io = useGiocatoreCorrente();
+  // Solo `.id` serve qui: `useGiocatoreBase` basta, niente statistiche.
+  const io = useGiocatoreBase();
   const { data: sessione } = useSessioneScout(partita?.id ?? null);
 
   const attiva = sessione && !sessioneScaduta(sessione) ? sessione : null;

src/components/crapp/SondaggioCacche.tsx

@@ -4,10 +4,16 @@ import { toast } from "sonner";
 import { cn } from "@/lib/utils";
 import { Card } from "@/components/crapp/ui-bits";
 import { nomeCompleto, useGiocatoriSquadra } from "@/lib/giocatori-squadra";
-import { useGiocatoreCorrente } from "@/lib/user-store";
+import { useGiocatoreInCampo } from "@/lib/user-store";
 import { intestazioniAutenticate } from "@/lib/auth";
 import { useIsAdmin } from "@/lib/ruoli";
-import { mediaPartita, sondaggioAperto, useCacche, useSalvaCacche } from "@/lib/cacche";
+import {
+  mediaPartita,
+  sondaggioAperto,
+  sondaggioTerminato,
+  useCacche,
+  useSalvaCacche,
+} from "@/lib/cacche";
 
 const opzioni = [0, 1, 2, 3, 4, 5];
 
@@ -15,11 +21,14 @@ const opzioni = [0, 1, 2, 3, 4, 5];
 export function SondaggioCacche({
   eventoId,
   dataEvento,
+  oraEvento,
 }: {
   eventoId: string;
   dataEvento: string;
+  oraEvento: string;
 }) {
-  const io = useGiocatoreCorrente();
+  // Solo `.id` serve qui, niente statistiche; `null` per l'allenatore, che non gioca (DD-034).
+  const io = useGiocatoreInCampo();
   const { righe } = useCacche();
   const salva = useSalvaCacche();
   const { righe: squadra } = useGiocatoriSquadra();
@@ -69,14 +78,16 @@ export function SondaggioCacche({
     }
   }
 
-  if (!sondaggioAperto(dataEvento)) {
+  if (!sondaggioAperto(dataEvento, oraEvento)) {
     return (
       <Card>
         <p className="text-xs font-bold uppercase tracking-wide text-muted-foreground">
           💩 Sondaggio pre-partita
         </p>
         <p className="mt-1 text-xs text-muted-foreground">
-          Apre alle 8:00 del giorno della partita: riceverai una notifica.
+          {sondaggioTerminato(dataEvento, oraEvento)
+            ? "Sondaggio chiuso: era aperto fino al fischio d'inizio."
+            : "Apre alle 8:00 del giorno della partita: riceverai una notifica."}
         </p>
       </Card>
     );

src/components/crapp/TurnoPalloni.tsx

@@ -4,20 +4,21 @@ import { toast } from "sonner";
 import { cn } from "@/lib/utils";
 import { Avatar } from "@/components/crapp/Avatar";
 import { intestazioniAutenticate } from "@/lib/auth";
-import { nomeCompleto, useGiocatoriSquadra } from "@/lib/giocatori-squadra";
+import { inRosa, nomeCompleto, useGiocatoriSquadra } from "@/lib/giocatori-squadra";
 import { useAssegnaTurno, useTurniPalloni } from "@/lib/palloni";
 import { useIsAdmin } from "@/lib/ruoli";
-import { useGiocatoreCorrente } from "@/lib/user-store";
+import { useGiocatoreBase } from "@/lib/user-store";
 
 export function TurnoPalloni({ eventoId }: { eventoId: string }) {
   const [aperto, setAperto] = useState(false);
   const [avviso, setAvviso] = useState(false);
   const { salvati, turni, isPending } = useTurniPalloni();
   const assegna = useAssegnaTurno();
-  const io = useGiocatoreCorrente();
+  // Solo `.nome` serve qui: `useGiocatoreBase` basta, niente statistiche.
+  const io = useGiocatoreBase();
   const admin = useIsAdmin();
   const { righe: squadra } = useGiocatoriSquadra();
-  const rosa = squadra.filter((g) => g.attivo);
+  const rosa = squadra.filter(inRosa);
 
   const id = turni[eventoId];
   const proposto = !salvati[eventoId];

src/components/crapp/VotazioneMvp.tsx

@@ -2,17 +2,37 @@ import { useState } from "react";
 import { Crown, Vote } from "lucide-react";
 import { toast } from "sonner";
 import { cn } from "@/lib/utils";
-import { nomeCompleto, useGiocatoriSquadra } from "@/lib/giocatori-squadra";
-import { useGiocatoreCorrente } from "@/lib/user-store";
-import { conteggioPartita, mioVoto, useVotaMvp, useVotiMvp, type VotoMvp } from "@/lib/mvp-voti";
+import { inRosa, nomeCompleto, useGiocatoriSquadra } from "@/lib/giocatori-squadra";
+import { useGiocatoreInCampo } from "@/lib/user-store";
+import { usePresenzeEvento } from "@/lib/presenze";
+import type { Evento } from "@/lib/eventi";
+import {
+  conteggioPartita,
+  mioVoto,
+  ORE_ATTESA_MVP,
+  useVotaMvp,
+  useVotiMvp,
+  votoMvpAperto,
+  type VotoMvp,
+} from "@/lib/mvp-voti";
 
-/** Pannello di votazione MVP di una partita: un voto a testa, modificabile. */
-export function VotazioneMvp({ matchId }: { matchId: string }) {
-  const io = useGiocatoreCorrente();
+/**
+ * Pannello di votazione MVP di una partita: un voto a testa, modificabile.
+ *
+ * I voti sono legati all'evento CrAPP, non al referto CSI né allo scout: si vota anche
+ * senza risultato caricato, dalle due ore dopo il fischio d'inizio. Votano e sono votabili
+ * solo i presenti (o in ritardo) di quell'evento.
+ */
+export function VotazioneMvp({ evento }: { evento: Evento }) {
+  const matchId = evento.id;
+  // Solo `.id` serve qui, niente statistiche; `null` per l'allenatore, che non gioca (DD-034).
+  const io = useGiocatoreInCampo();
   const voti = useVotiMvp();
   const vota = useVotaMvp();
   const { righe: squadra } = useGiocatoriSquadra();
-  const rosa = squadra.filter((g) => g.attivo);
+  const { risposte } = usePresenzeEvento(evento.id);
+  const presente = (id: string) => risposte[id] === "presente" || risposte[id] === "ritardo";
+  const rosa = squadra.filter((g) => inRosa(g) && presente(g.id));
   const [aperto, setAperto] = useState(false);
 
   const tutti: VotoMvp[] = voti.data ?? [];
@@ -21,6 +41,20 @@ export function VotazioneMvp({ matchId }: { matchId: string }) {
   const totale = conteggio.reduce((s, c) => s + c.voti, 0);
   const testa = conteggio[0];
   const pareggio = conteggio.length > 1 && conteggio[1]!.voti === testa?.voti;
+  const puoVotare = !!io && presente(io.id);
+
+  if (!votoMvpAperto(evento.data, evento.ora)) {
+    return (
+      <div className="mt-3 rounded-2xl bg-secondary/60 p-3">
+        <p className="inline-flex items-center gap-1.5 text-xs font-bold uppercase tracking-wide text-muted-foreground">
+          <Vote className="h-3.5 w-3.5" /> Voto MVP
+        </p>
+        <p className="mt-1 text-xs text-muted-foreground">
+          Apre {ORE_ATTESA_MVP} ore dopo l'inizio della partita.
+        </p>
+      </div>
+    );
+  }
 
   async function invia(id: string, nome: string) {
     if (!io) return;
@@ -47,7 +81,7 @@ export function VotazioneMvp({ matchId }: { matchId: string }) {
         <button
           type="button"
           onClick={() => setAperto((v) => !v)}
-          disabled={!io}
+          disabled={!puoVotare}
           className="rounded-full bg-accent px-3 py-1 text-xs font-bold uppercase text-accent-foreground disabled:opacity-50"
         >
           {mio ? "Cambia voto" : "Vota"}
@@ -67,26 +101,34 @@ export function VotazioneMvp({ matchId }: { matchId: string }) {
       </p>
       {mio ? (
         <p className="mt-1 text-xs text-muted-foreground">Hai votato {mio.votato_nome}</p>
+      ) : !puoVotare ? (
+        <p className="mt-1 text-xs text-muted-foreground">
+          Vota chi era presente a questa partita.
+        </p>
       ) : null}
 
       {aperto ? (
         <div className="mt-3 grid max-h-60 grid-cols-2 gap-1.5 overflow-y-auto">
-          {rosa.map((g) => (
-            <button
-              key={g.id}
-              type="button"
-              disabled={vota.isPending}
-              onClick={() => invia(g.id, nomeCompleto(g))}
-              className={cn(
-                "truncate rounded-xl px-2.5 py-2 text-left text-xs font-semibold transition-colors",
-                mio?.votato_id === g.id
-                  ? "bg-accent text-accent-foreground"
-                  : "bg-card text-foreground",
-              )}
-            >
-              {nomeCompleto(g)}
-            </button>
-          ))}
+          {/* Sé stessi fuori dall'elenco, come nei badge social: l'auto-voto è vietato
+              anche dal vincolo `mvp_no_autovoto` (M12). */}
+          {rosa
+            .filter((g) => g.id !== io?.id)
+            .map((g) => (
+              <button
+                key={g.id}
+                type="button"
+                disabled={vota.isPending}
+                onClick={() => invia(g.id, nomeCompleto(g))}
+                className={cn(
+                  "truncate rounded-xl px-2.5 py-2 text-left text-xs font-semibold transition-colors",
+                  mio?.votato_id === g.id
+                    ? "bg-accent text-accent-foreground"
+                    : "bg-card text-foreground",
+                )}
+              >
+                {nomeCompleto(g)}
+              </button>
+            ))}
         </div>
       ) : conteggio.length > 0 ? (
         <div className="mt-2 flex flex-wrap gap-1.5">

src/components/crapp/VotoSocial.tsx

@@ -2,8 +2,8 @@ import { useState } from "react";
 import { Check, Crown, Sparkles } from "lucide-react";
 import { toast } from "sonner";
 import { cn } from "@/lib/utils";
-import { nomeCompleto, useGiocatoriSquadra } from "@/lib/giocatori-squadra";
-import { useGiocatoreCorrente } from "@/lib/user-store";
+import { inRosa, nomeCompleto, useGiocatoriSquadra } from "@/lib/giocatori-squadra";
+import { useGiocatoreInCampo } from "@/lib/user-store";
 import {
   categorieSocial,
   conteggioCategoria,
@@ -15,11 +15,12 @@ import {
 
 /** Voto social post-partita: un compagno per categoria, veloce da mobile. */
 export function VotoSocial({ matchId }: { matchId: string }) {
-  const io = useGiocatoreCorrente();
+  // Solo `.id` serve qui, niente statistiche; `null` per l'allenatore, che non gioca (DD-034).
+  const io = useGiocatoreInCampo();
   const voti = useVotiSocial();
   const vota = useVotaSocial();
   const { righe: squadra } = useGiocatoriSquadra();
-  const rosa = squadra.filter((g) => g.attivo);
+  const rosa = squadra.filter(inRosa);
   const [aperta, setAperta] = useState<string | null>(null);
 
   const tutti = voti.data ?? [];

src/components/crapp/ui-bits.tsx

@@ -1,9 +1,27 @@
-import { useId, useState, type ComponentPropsWithoutRef, type ReactNode } from "react";
+import {
+  useEffect,
+  useId,
+  useRef,
+  useState,
+  type ComponentPropsWithoutRef,
+  type ReactNode,
+} from "react";
 import { Link } from "@tanstack/react-router";
-import { ChevronDown } from "lucide-react";
+import { AnimatePresence, motion } from "motion/react";
+import { ChevronDown, X } from "lucide-react";
 import { cn } from "@/lib/utils";
-import { statoMeta, type Stato } from "@/lib/crapp-data";
-import { useIo } from "@/lib/rosa";
+import { inizialiDa, statoMeta, type Stato } from "@/lib/crapp-data";
+import { nomeCompleto } from "@/lib/giocatori-squadra";
+import { useGiocatoreBase } from "@/lib/user-store";
+import { useMotoRidotto } from "@/lib/motion";
+import { molla, proietta } from "@/lib/molla";
+import {
+  pallinoNotifiche,
+  useEliminaNotifica,
+  useNotificheMie,
+  useSegnaLette,
+  type NotificaUtente,
+} from "@/lib/notifiche-utente";
 import { Avatar } from "@/components/crapp/Avatar";
 import { Reveal } from "@/components/motion/Reveal";
 import { Numero } from "@/components/motion/Numero";
@@ -25,6 +43,7 @@ export function TeamLogo({
       alt="CRAP Volley"
       width={192}
       height={192}
+      decoding="async"
       className={cn("shrink-0 rounded-2xl object-cover shadow-pop", className)}
     />
   );
@@ -46,22 +65,174 @@ export function Card({
   return <Tag className={cn("premi rounded-3xl bg-card p-4 shadow-card", className)} {...props} />;
 }
 
+/** "or ora" / "tra 3 ore" / "2 giorni fa" — così basta guardare senza fare i conti. */
+function tempoRelativo(dataIso: string): string {
+  const rtf = new Intl.RelativeTimeFormat("it", { numeric: "auto" });
+  const minuti = Math.round((new Date(dataIso).getTime() - Date.now()) / 60_000);
+  if (Math.abs(minuti) < 60) return rtf.format(minuti, "minute");
+  const ore = Math.round(minuti / 60);
+  if (Math.abs(ore) < 24) return rtf.format(ore, "hour");
+  return rtf.format(Math.round(ore / 24), "day");
+}
+
+/**
+ * Una riga del pannello notifiche, eliminabile con uno swipe a sinistra o con la ×: non
+ * c'è pulizia automatica delle notifiche vecchie (M17), quindi è l'unico modo per un
+ * giocatore di togliersele di torno. Soglia e proiezione della velocità di rilascio come
+ * lo swipe del calendario (`src/routes/calendario.tsx`), ma qui in una sola direzione: non
+ * c'è "indietro", solo "via".
+ */
+function RigaNotifica({
+  notifica,
+  onElimina,
+}: {
+  notifica: NotificaUtente;
+  onElimina: (id: string) => void;
+}) {
+  const ridotto = useMotoRidotto();
+  return (
+    <motion.li
+      layout={!ridotto}
+      initial={false}
+      exit={{ opacity: 0, height: 0, marginTop: 0, marginBottom: 0 }}
+      transition={molla.ui}
+      className="relative overflow-hidden rounded-xl"
+    >
+      <motion.div
+        drag={ridotto ? false : "x"}
+        dragConstraints={{ left: -80, right: 0 }}
+        dragElastic={{ left: 0.2, right: 0 }}
+        dragMomentum={false}
+        onDragEnd={(_, info) => {
+          const arrivo = info.offset.x + proietta(info.velocity.x);
+          if (arrivo < -60) onElimina(notifica.id);
+        }}
+        className="touch-pan-y bg-card p-3 pr-8 text-sm"
+      >
+        <p className="font-semibold">{notifica.titolo}</p>
+        {notifica.corpo ? <p className="mt-0.5 text-muted-foreground">{notifica.corpo}</p> : null}
+        <p className="mt-1 text-xs text-muted-foreground">{tempoRelativo(notifica.creataIl)}</p>
+      </motion.div>
+      <button
+        type="button"
+        onClick={() => onElimina(notifica.id)}
+        aria-label="Rimuovi notifica"
+        className="absolute right-1 top-1 rounded-full p-1.5 text-muted-foreground active:scale-90"
+      >
+        <X className="h-3.5 w-3.5" />
+      </button>
+    </motion.li>
+  );
+}
+
 /**
  * Accesso al profilo in alto a destra: la BottomNav ha quattro voci e questa è
  * l'unica porta verso `/profilo`. Sulla pagina del profilo si passa `azione` a
- * `PageHeader` per rimetterci il logo — sarebbe un link a sé stessa.
+ * `PageHeader` con il logo che porta alla home.
+ *
+ * Usa `useGiocatoreBase` (sola anagrafica) e non `useIo`: qui serve solo id e
+ * iniziali, mentre `useIo` calcola l'intera rosa con statistiche (MVP, pagelle,
+ * cacche, palloni, infortuni). Essendo in un componente montato su quasi ogni
+ * pagina, quei moduli finirebbero nel bundle condiviso di tutte le rotte.
+ *
+ * Sopra l'avatar sta il pallino del centro notifiche (M17): il tap sull'avatar
+ * porta sempre al profilo, quello sul pallino apre il pannello.
  */
 export function LinkProfilo() {
-  const g = useIo();
-  if (!g) return <TeamLogo className="h-11 w-11" />;
+  const g = useGiocatoreBase();
+  if (!g) return <TeamLogo className="h-12 w-12" />;
   return (
-    <Link
-      to="/profilo"
-      aria-label="Il tuo profilo"
-      className="premi shrink-0 rounded-2xl ring-2 ring-primary-foreground/30"
-    >
-      <Avatar id={g.id} fallback={g.iniziali} className="h-11 w-11 text-lg" />
-    </Link>
+    <div className="relative shrink-0">
+      <Link
+        to="/profilo"
+        aria-label="Il tuo profilo"
+        className="premi block rounded-2xl ring-2 ring-primary-foreground/30"
+      >
+        <Avatar id={g.id} fallback={inizialiDa(nomeCompleto(g))} className="h-12 w-12 text-lg" />
+      </Link>
+      <PallinoNotifiche />
+    </div>
+  );
+}
+
+/**
+ * Pallino del centro notifiche (M17) sull'angolo dell'avatar (aspetto deciso da
+ * `pallinoNotifiche()`). Copre quattro sorgenti generate lato database (mai dal client):
+ * messaggi admin, promemoria automatici, turno palloni, sollecito presenze — vedi
+ * `src/lib/notifiche-utente.ts`.
+ *
+ * Nel progetto non c'è una libreria dropdown: il pannello è un `div` posizionato a mano,
+ * chiuso al click fuori o con Escape. Aprirlo segna tutte le notifiche come lette; per
+ * toglierle di mezzo per sempre serve lo swipe o la × di `RigaNotifica`.
+ */
+function PallinoNotifiche() {
+  const { notifiche, nonLette } = useNotificheMie();
+  const segnaLette = useSegnaLette();
+  const eliminaNotifica = useEliminaNotifica();
+  const [aperto, setAperto] = useState(false);
+  const riquadro = useRef<HTMLDivElement>(null);
+
+  useEffect(() => {
+    if (!aperto) return;
+    const chiudiSeFuori = (e: MouseEvent) => {
+      if (riquadro.current && !riquadro.current.contains(e.target as Node)) setAperto(false);
+    };
+    const chiudiConEsc = (e: KeyboardEvent) => {
+      if (e.key === "Escape") setAperto(false);
+    };
+    document.addEventListener("mousedown", chiudiSeFuori);
+    document.addEventListener("keydown", chiudiConEsc);
+    return () => {
+      document.removeEventListener("mousedown", chiudiSeFuori);
+      document.removeEventListener("keydown", chiudiConEsc);
+    };
+  }, [aperto]);
+
+  const pallino = pallinoNotifiche(notifiche.length, nonLette);
+  if (!pallino) return null;
+
+  function alClick() {
+    const stavaChiuso = !aperto;
+    setAperto(stavaChiuso);
+    if (stavaChiuso && nonLette > 0) segnaLette.mutate();
+  }
+
+  // Tolta l'ultima, il pallino sparisce: chiuso anche il pannello, così alla prossima
+  // notifica non si riapre da solo.
+  function elimina(id: string) {
+    if (notifiche.length === 1) setAperto(false);
+    eliminaNotifica.mutate(id);
+  }
+
+  return (
+    <div ref={riquadro}>
+      {/* `after:` allarga l'area di tocco oltre i 20px del pallino senza ingrandirlo. */}
+      <button
+        type="button"
+        onClick={alClick}
+        aria-label={nonLette > 0 ? `Notifiche, ${nonLette} da leggere` : "Notifiche"}
+        aria-expanded={aperto}
+        className={cn(
+          "absolute -right-1.5 -top-1.5 flex h-5 min-w-5 items-center justify-center rounded-full px-1 text-[11px] font-bold shadow-pop ring-2 ring-primary-foreground after:absolute after:-inset-3 active:scale-90",
+          pallino.daLeggere
+            ? "bg-accent-grad text-accent-foreground"
+            : "bg-muted text-muted-foreground",
+        )}
+      >
+        {pallino.testo}
+      </button>
+      {aperto ? (
+        <div className="absolute right-0 top-14 z-50 w-72 max-w-[calc(100vw-2.5rem)] rounded-2xl bg-card p-2 text-foreground shadow-card">
+          <ul className="max-h-80 overflow-y-auto">
+            <AnimatePresence initial={false}>
+              {notifiche.map((n) => (
+                <RigaNotifica key={n.id} notifica={n} onElimina={elimina} />
+              ))}
+            </AnimatePresence>
+          </ul>
+        </div>
+      ) : null}
+    </div>
   );
 }
 
@@ -96,17 +267,19 @@ export function Section({
   children,
   indice = 0,
 }: {
-  titolo: string;
+  titolo?: string;
   azione?: ReactNode;
   children: ReactNode;
   indice?: number;
 }) {
   return (
     <Reveal as="section" indice={indice} className="px-5 py-4">
-      <div className="mb-3 flex items-center justify-between gap-3">
-        <h2 className="font-display-sm text-lg uppercase">{titolo}</h2>
-        {azione}
-      </div>
+      {titolo || azione ? (
+        <div className="mb-3 flex items-center justify-between gap-3">
+          {titolo ? <h2 className="font-display-sm text-[20px] uppercase">{titolo}</h2> : <span />}
+          {azione}
+        </div>
+      ) : null}
       {children}
     </Reveal>
   );

src/components/motion/Reveal.tsx

@@ -37,7 +37,7 @@ export function Reveal({
       {...(style ? { style } : {})}
       initial={ridotto ? { opacity: 0 } : { opacity: 0, y: 10 }}
       whileInView={ridotto ? { opacity: 1 } : { opacity: 1, y: 0 }}
-      viewport={{ once: true, amount: 0.15, margin: "0px 0px -10% 0px" }}
+      viewport={{ once: true, amount: "some", margin: "0px 0px -10% 0px" }}
       transition={ridotto ? { duration: 0.2, delay: ritardo } : { ...molla.ui, delay: ritardo }}
     >
       {children}

src/integrations/lovable/index.ts

@@ -1,41 +0,0 @@
-// This file is auto-generated by Lovable. Do not modify it.
-
-import { createLovableAuth } from "@lovable.dev/cloud-auth-js";
-import { supabase } from "../supabase/client";
-const lovableAuth = createLovableAuth();
-
-type SignInOptions = {
-  redirect_uri?: string;
-  extraParams?: Record<string, string>;
-};
-
-export const lovable = {
-  auth: {
-    signInWithOAuth: async (
-      provider: "google" | "apple" | "microsoft" | "lovable",
-      opts?: SignInOptions,
-    ) => {
-      const result = await lovableAuth.signInWithOAuth(provider, {
-        redirect_uri: opts?.redirect_uri ?? window.location.origin,
-        extraParams: {
-          ...opts?.extraParams,
-        },
-      });
-
-      if (result.redirected) {
-        return result;
-      }
-
-      if (result.error) {
-        return result;
-      }
-
-      try {
-        await supabase.auth.setSession(result.tokens);
-      } catch (e) {
-        return { error: e instanceof Error ? e : new Error(String(e)) };
-      }
-      return result;
-    },
-  },
-};

src/integrations/supabase/types.ts

@@ -637,7 +637,7 @@ export type Database = {
       };
     };
     Enums: {
-      app_role: "admin" | "user";
+      app_role: "admin" | "user" | "allenatore";
     };
     CompositeTypes: {
       [_ in never]: never;
@@ -762,7 +762,7 @@ export const Constants = {
   },
   public: {
     Enums: {
-      app_role: ["admin", "user"],
+      app_role: ["admin", "user", "allenatore"],
     },
   },
 } as const;

src/lib/auth-route.server.ts

@@ -7,9 +7,9 @@
  * è un timestamp in base 36 e compare negli URL che la squadra si scambia — quindi non
  * può fare da credenziale.
  *
- * Tutte e tre le route che mandano notifiche partono da un pulsante riservato agli
- * amministratori, quindi il controllo è uno solo: `richiediAdmin` verifica il token della
- * sessione Supabase e poi il ruolo in `user_roles`. Torna `null` quando la richiesta può
+ * Le route che mandano notifiche partono da un pulsante riservato agli amministratori, e il
+ * sollecito presenze anche agli allenatori (DD-034): `richiediAdmin` e `richiediGestoreEventi`
+ * verificano il token della sessione Supabase e poi il ruolo in `user_roles`. Torna `null` quando la richiesta può
  * proseguire, altrimenti la `Response` di rifiuto già pronta.
  */
 
@@ -18,15 +18,20 @@ function tokenDaRichiesta(request: Request): string | null {
   const intestazione = request.headers.get("authorization");
   if (!intestazione?.startsWith("Bearer ")) return null;
   const token = intestazione.slice("Bearer ".length).trim();
-  // Un JWT ha tre segmenti: scartarlo qui evita una chiamata di rete per ogni rumore.
-  return token && token.split(".").length === 3 ? token : null;
+  // Un JWT ha tre segmenti non vuoti: scartarlo qui evita una chiamata di rete per ogni rumore.
+  const segmenti = token.split(".");
+  return segmenti.length === 3 && segmenti.every(Boolean) ? token : null;
 }
 
 /**
- * Lascia passare solo un amministratore autenticato. `401` se manca o non vale il token,
- * `403` se il token è buono ma l'utente non è admin.
+ * Lascia passare solo un utente autenticato con almeno uno dei `ruoli`. `401` se manca o non
+ * vale il token, `403` se il token è buono ma il ruolo no.
  */
-export async function richiediAdmin(request: Request): Promise<Response | null> {
+async function richiediRuolo(
+  request: Request,
+  ruoli: Array<"admin" | "allenatore">,
+  rifiuto: string,
+): Promise<Response | null> {
   const token = tokenDaRichiesta(request);
   if (!token) return new Response("Autenticazione richiesta", { status: 401 });
 
@@ -36,13 +41,22 @@ export async function richiediAdmin(request: Request): Promise<Response | null>
   if (error || !utente?.user) return new Response("Sessione non valida", { status: 401 });
 
   // Stessa fonte di `src/lib/ruoli.ts`: i permessi stanno solo in `user_roles` (DD-011).
-  const { data: ruolo } = await supabaseAdmin
+  const { data: righe } = await supabaseAdmin
     .from("user_roles")
     .select("role")
     .eq("user_id", utente.user.id)
-    .eq("role", "admin")
-    .maybeSingle();
+    .in("role", ruoli);
 
-  if (!ruolo) return new Response("Riservato agli amministratori", { status: 403 });
+  if (!righe?.length) return new Response(rifiuto, { status: 403 });
   return null;
 }
+
+/** Solo un amministratore: promemoria palloni, messaggi, sondaggio, notifiche attive. */
+export function richiediAdmin(request: Request): Promise<Response | null> {
+  return richiediRuolo(request, ["admin"], "Riservato agli amministratori");
+}
+
+/** Admin o allenatore: chi gestisce gli eventi può anche sollecitare le presenze (DD-034). */
+export function richiediGestoreEventi(request: Request): Promise<Response | null> {
+  return richiediRuolo(request, ["admin", "allenatore"], "Riservato a admin e allenatori");
+}

src/lib/avatar-store.ts

@@ -29,9 +29,13 @@ export function useAvatarEsiste(id: string | undefined) {
   });
 }
 
-export function useInvalidaAvatarEsiste() {
+/**
+ * Dopo un caricamento o una rimozione lo stato è noto: si scrive in cache invece di
+ * rileggere l'elenco del bucket (una richiesta in meno per ogni cambio foto).
+ */
+export function useImpostaAvatarEsiste() {
   const qc = useQueryClient();
-  return (id: string) => qc.invalidateQueries({ queryKey: chiaveEsiste(id) });
+  return (id: string, esiste: boolean) => qc.setQueryData(chiaveEsiste(id), esiste);
 }
 
 /** Ridimensiona e comprime l'immagine scelta in un quadrato JPEG. */

src/lib/badges.ts

@@ -58,6 +58,12 @@ export type BadgeDef = {
   notificaPush?: string;
 };
 
+/**
+ * Voti minimi perché la media pagelle conti per il badge Pagellone: sotto soglia una singola
+ * pagella potrebbe sbloccarlo (o farlo sparire) senza significatività statistica.
+ */
+export const VOTI_MINIMI_PAGELLA = 5;
+
 export const badgeDefs: BadgeDef[] = [
   {
     id: "mvp",
@@ -77,7 +83,7 @@ export const badgeDefs: BadgeDef[] = [
     unita: "di media voto",
     icon: ClipboardCheck,
     soglie: { bronzo: 6.5, argento: 7.5, oro: 8.5 },
-    valore: (g) => g.mediaVoto,
+    valore: (g) => (g.votiPagella >= VOTI_MINIMI_PAGELLA ? g.mediaVoto : 0),
   },
   {
     id: "palloni",
@@ -130,7 +136,9 @@ export const badgeSegreti: BadgeDef[] = [
     icon: Ghost,
     segreto: true,
     soglie: { bronzo: 1, argento: 1, oro: 1 },
-    valore: (g) => (g.mvp >= 2 && g.mediaVoto >= 8 ? 1 : 0),
+    // Stessa soglia minima di voti del badge Pagellone: sotto VOTI_MINIMI_PAGELLA la media
+    // non è statisticamente significativa, non deve poter sbloccare nemmeno questo segreto.
+    valore: (g) => (g.mvp >= 2 && g.votiPagella >= VOTI_MINIMI_PAGELLA && g.mediaVoto >= 8 ? 1 : 0),
     celebrazione: "Nei momenti caldi ci sei sempre.",
   },
   {
@@ -178,7 +186,7 @@ export const badgeSegreti: BadgeDef[] = [
     id: "s-cacche",
     nome: "Trono di ferro",
     descrizione:
-      "Almeno 3 partite di campionato affrontate con 3 o più cacche pre-gara. Il bagno del PalaCRAP porta il tuo nome 🚽😂",
+      "Almeno 3 partite affrontate con 3 o più cacche pre-gara (campionato o amichevole, qui non si fanno sconti). Il bagno del PalaCRAP porta il tuo nome 🚽😂",
     unita: "partite da record",
     icon: Toilet,
     segreto: true,

src/lib/cacche.ts

@@ -5,11 +5,40 @@ import { oggiISO } from "./palloni-core";
 /** Ora di apertura del sondaggio, il giorno stesso della partita. */
 export const ORA_APERTURA_SONDAGGIO = 8;
 
-/** Il sondaggio apre alle 8:00 del giorno della partita e da lì resta aperto. */
-export function sondaggioAperto(dataEvento: string, adesso = new Date()): boolean {
+/** Istante del fischio d'inizio: `oraEvento` mancante equivale a fine giornata (non chiude mai prima). */
+function inizioPartita(dataEvento: string, oraEvento: string): number {
+  return new Date(`${dataEvento}T${oraEvento || "23:59"}:00`).getTime();
+}
+
+/** Il sondaggio apre alle 8:00 del giorno della partita e chiude al fischio d'inizio. */
+export function sondaggioAperto(
+  dataEvento: string,
+  oraEvento: string,
+  adesso = new Date(),
+): boolean {
+  if (dataEvento !== oggiISO(adesso)) return false;
+  const apertura = new Date(`${dataEvento}T00:00:00`);
+  apertura.setHours(ORA_APERTURA_SONDAGGIO, 0, 0, 0);
+  return (
+    adesso.getTime() >= apertura.getTime() &&
+    adesso.getTime() < inizioPartita(dataEvento, oraEvento)
+  );
+}
+
+/**
+ * True se il fischio d'inizio è già passato (oggi o in un giorno precedente): serve a
+ * distinguere, nel messaggio mostrato quando il sondaggio è chiuso, "non ancora aperto"
+ * da "già chiuso" — altrimenti dopo la partita si continuerebbe a dire "apre alle 8:00".
+ */
+export function sondaggioTerminato(
+  dataEvento: string,
+  oraEvento: string,
+  adesso = new Date(),
+): boolean {
   const oggi = oggiISO(adesso);
-  if (dataEvento !== oggi) return dataEvento < oggi;
-  return adesso.getHours() >= ORA_APERTURA_SONDAGGIO;
+  if (dataEvento < oggi) return true;
+  if (dataEvento > oggi) return false;
+  return adesso.getTime() >= inizioPartita(dataEvento, oraEvento);
 }
 
 /** Sondaggio goliardico pre-partita: quante cacche prima del match di campionato. */

src/lib/calendario.ts

@@ -0,0 +1,63 @@
+import { useState } from "react";
+
+/** Etichette condivise tra `/calendario` (sola lettura) ed `/eventi` (griglia di gestione). */
+export const giorniIT = ["L", "M", "M", "G", "V", "S", "D"];
+
+export const mesiIT = [
+  "Gennaio",
+  "Febbraio",
+  "Marzo",
+  "Aprile",
+  "Maggio",
+  "Giugno",
+  "Luglio",
+  "Agosto",
+  "Settembre",
+  "Ottobre",
+  "Novembre",
+  "Dicembre",
+] as const;
+
+export function pad2(n: number) {
+  return String(n).padStart(2, "0");
+}
+
+/** Numero di giorni nel mese (0-indicizzato) e offset del primo giorno rispetto a lunedì. */
+export function giorniDelMese(anno: number, mese: number) {
+  const giorni = new Date(Date.UTC(anno, mese + 1, 0)).getUTCDate();
+  const primoGiorno = new Date(Date.UTC(anno, mese, 1)).getUTCDay();
+  const offsetLunedi = (primoGiorno + 6) % 7;
+  return { giorni, offsetLunedi };
+}
+
+/** Stato di navigazione mese per mese, condiviso dalle griglie calendario. */
+export function useMeseNav(initial?: { anno: number; mese: number }) {
+  const oggi = new Date();
+  const [anno, setAnno] = useState(initial?.anno ?? oggi.getFullYear());
+  const [mese, setMese] = useState(initial?.mese ?? oggi.getMonth());
+  // Serve a far entrare e uscire la griglia dallo stesso lato del gesto:
+  // se un mese esce a sinistra, il precedente deve rientrare da sinistra.
+  const [direzione, setDirezione] = useState(0);
+
+  const precedente = () => {
+    setDirezione(-1);
+    if (mese === 0) {
+      setMese(11);
+      setAnno((a) => a - 1);
+    } else {
+      setMese((m) => m - 1);
+    }
+  };
+
+  const successivo = () => {
+    setDirezione(1);
+    if (mese === 11) {
+      setMese(0);
+      setAnno((a) => a + 1);
+    } else {
+      setMese((m) => m + 1);
+    }
+  };
+
+  return { anno, mese, direzione, precedente, successivo };
+}

src/lib/crapp-data.ts

@@ -28,6 +28,8 @@ export type Giocatore = {
   nascita: string;
   presenze: number;
   totaliEventi: number;
+  /** Solo partite (non allenamenti) a cui era presente o in ritardo. */
+  partiteGiocate: number;
   streak: number;
   /** Serie consecutive per tipo: si azzerano in modo indipendente. */
   serieAllenamenti: number;
@@ -37,8 +39,12 @@ export type Giocatore = {
   mvp: number;
   /** Media delle pagelle ricevute dai compagni (1-10). */
   mediaVoto: number;
+  /** Quante pagelle ha ricevuto: sotto la soglia minima il badge Pagellone resta bloccato. */
+  votiPagella: number;
   /** Quante volte ha portato i palloni. */
   palloni: number;
+  /** Volte consecutive (fino a oggi) in cui ha portato i palloni. */
+  seriePalloni: number;
   /** Partite di campionato con almeno 3 cacche dichiarate. */
   cacche: number;
   /** Media di cacche dichiarate per partita. */
@@ -73,7 +79,8 @@ const rosaCSI: Rosa[] = [
   { nome: "Giada Valbonesi", nascita: "1994-05-20", ruolo: "Opposto", numero: 10 },
 ];
 
-function inizialiDa(nome: string) {
+/** Iniziali da un nome completo (max 2 lettere), es. per il fallback di `Avatar`. */
+export function inizialiDa(nome: string) {
   return nome
     .split(" ")
     .map((p) => p[0] ?? "")
@@ -98,28 +105,23 @@ export const giocatori: Giocatore[] = rosaCSI
     iniziali: inizialiDa(r.nome),
     presenze: 0,
     totaliEventi: 0,
+    partiteGiocate: 0,
     streak: 0,
     serieAllenamenti: 0,
     seriePartite: 0,
     serieConferme: 0,
     mvp: 0,
     mediaVoto: 0,
+    votiPagella: 0,
     infortuni: 0,
     ritardi: 0,
     palloni: 0,
+    seriePalloni: 0,
     cacche: 0,
     cacchePartita: 0,
   }))
   .sort((a, b) => dividiNome(a.nome).cognome.localeCompare(dividiNome(b.nome).cognome, "it"));
 
-/**
- * Fallback per la data di nascita: `giocatori_squadra` non ha ancora questa colonna
- * (DD-015 follow-up). Un giocatore aggiunto dopo la migrazione non ha nascita nota.
- */
-export const nascitaPerId: Record<string, string> = Object.fromEntries(
-  giocatori.map((g) => [g.id, g.nascita]),
-);
-
 export type RigaClassifica = {
   pos: number;
   squadra: string;

src/lib/csi-core.ts

@@ -10,21 +10,75 @@ import type { RigaClassifica } from "./crapp-data";
 export const CSI_BASE = "https://livescore.csibologna.it";
 /** Campionato Open Misto Eccellenza 2025/26. Cambia a ogni stagione. */
 export const CSI_PROJECT_ID = 767;
+/**
+ * Coppa CSI Misto Silver 2025/26. Stesso formato di tabella del campionato (girone
+ * all'italiana), solo con meno squadre: `parseClassifica()` funziona invariata. Cambia a
+ * ogni stagione come CSI_PROJECT_ID, vedi docs/modules/collegamento-csi.md.
+ */
+export const CSI_COPPA_PROJECT_ID = 848;
 /** C.R.A.P. Volley sul portale CSI. */
 export const CSI_TEAM_ID = 3359;
 export const CSI_GIRONE = "Girone B";
 export const CSI_NOME_SQUADRA = "C.R.A.P. Volley";
 
+/**
+ * Stagione sportiva di una data `YYYY-MM-DD`, nel formato "2025/26". Il portale CSI non
+ * espone il nome della stagione (né nella classifica né nel calendario della squadra):
+ * si ricava dalla data della gara, con l'anno che cambia ad agosto — le gare di
+ * settembre-dicembre aprono la stagione, quelle di gennaio-luglio la chiudono.
+ */
+export function stagioneDi(dataIso: string): string {
+  const anno = Number(dataIso.slice(0, 4));
+  const mese = Number(dataIso.slice(5, 7));
+  const inizio = mese >= 8 ? anno : anno - 1;
+  return `${inizio}/${String((inizio + 1) % 100).padStart(2, "0")}`;
+}
+
+/** Stagione del campionato letto dal CSI: quella della prima gara, null se non ce ne sono. */
+export function stagioneDaPartite(partite: ReadonlyArray<{ data: string }>): string | null {
+  const date = partite.map((p) => p.data).filter((d) => /^\d{4}-\d{2}/.test(d));
+  if (date.length === 0) return null;
+  return stagioneDi(date.reduce((a, b) => (a < b ? a : b)));
+}
+
+/**
+ * Storico partite diviso per stagione, nell'ordine in cui arrivano: le gare scoutate in
+ * locale possono essere di stagioni diverse, quelle CSI sono tutte dello stesso campionato.
+ */
+export function raggruppaPerStagione<T extends { data: string }>(
+  match: readonly T[],
+): Array<{ stagione: string; match: T[] }> {
+  const gruppi: Array<{ stagione: string; match: T[] }> = [];
+  for (const m of match) {
+    const stagione = stagioneDi(m.data);
+    const gruppo = gruppi.find((g) => g.stagione === stagione);
+    if (gruppo) gruppo.match.push(m);
+    else gruppi.push({ stagione, match: [m] });
+  }
+  return gruppi;
+}
+
 export const urlClassifica = (projectId = CSI_PROJECT_ID) =>
   `${CSI_BASE}/components/project-sheets.php?project_id=${projectId}`;
 export const urlPartite = (teamId = CSI_TEAM_ID) =>
   `${CSI_BASE}/assets/json/getEventsByTeamId.php?team_id=${teamId}`;
+/** Info generali della gara (giornata, pubblico ammesso). */
+export const urlPartitaInfo = (matchId: string) =>
+  `${CSI_BASE}/components/match-main.php?match_id=${matchId}`;
+/** Formazioni titolari/panchina/staff di entrambe le squadre. */
+export const urlPartitaFormazioni = (matchId: string) =>
+  `${CSI_BASE}/components/match-players.php?match_id=${matchId}`;
+/** Storico scontri diretti e probabilità di vittoria calcolata dal CSI. */
+export const urlPartitaPrecedenti = (matchId: string) =>
+  `${CSI_BASE}/components/match-stats.php?match_id=${matchId}`;
 
 export type PartitaCsi = {
   id: string;
   data: string;
   ora: string;
   avversario: string;
+  /** URL del logo avversario sul portale CSI, vuoto se non presente. */
+  logoAvversario: string;
   casa: boolean;
   /** null finché la gara non è stata giocata. */
   setNostri: number | null;
@@ -32,13 +86,60 @@ export type PartitaCsi = {
   parziali: Array<[number, number]>;
   campo: string;
   competizione: string;
+  /** Es. "Girone B". */
+  girone: string;
+  /** Es. "5/XEB". */
+  numeroGara: string;
+  arbitro: string;
+  /** Referto ufficiale su livescore.csibologna.it. */
+  link: string;
+};
+
+export type GiocatoreFormazione = { numero: string; nome: string; ruolo: string };
+export type StaffFormazione = { nome: string; ruolo: string };
+export type FormazioneSquadra = {
+  squadra: string;
+  titolari: GiocatoreFormazione[];
+  panchina: GiocatoreFormazione[];
+  staff: StaffFormazione[];
+};
+
+export type PrecedentiCsi = {
+  totale: number;
+  vinteNoi: number;
+  vinteAvversario: number;
+  casaNoi: number;
+  casaAvversario: number;
+  fuoriNoi: number;
+  fuoriAvversario: number;
+  /** Percentuale 0-100, null se il CSI non la pubblica (es. sport senza storico). */
+  probabilitaNoi: number | null;
+  probabilitaAvversario: number | null;
+};
+
+export type DettaglioPartitaCsi = {
+  /** Es. "2ª Giornata", vuoto se non trovata (fase a eliminazione, coppa...). */
+  giornata: string;
+  /**
+   * Testo libero del CSI sotto l'impianto: a volte "Pubblico non ammesso", a volte il nome
+   * della palestra o altro — non ha un formato fisso, va mostrato così com'è. Vuoto se assente.
+   */
+  nota: string;
+  /** null se il referto non ha ancora le formazioni (partita non ancora giocata/schierata). */
+  formazioni: { noi: FormazioneSquadra; avversario: FormazioneSquadra } | null;
+  /** null solo se il formato non è riconosciuto; con 0 precedenti i campi restano a 0. */
+  precedenti: PrecedentiCsi | null;
 };
 
 export type DatiCsi = {
   classifica: RigaClassifica[];
+  /** Classifica del girone di Coppa (project_id 848). Vuota se il parsing fallisce. */
+  classificaCoppa: RigaClassifica[];
   partite: PartitaCsi[];
   girone: string;
   aggiornato: string;
+  /** true se il formato delle partite sembra cambiato (vedi `partiteFormatoSospetto`). */
+  formatoSospetto: boolean;
 };
 
 /** "C.R.A.P. Volley" e "CRAP Volley" devono confrontarsi uguali. */
@@ -107,11 +208,17 @@ type EventoCsi = {
   id?: number | string;
   start?: string;
   team1?: string;
+  team1_logo?: string;
   team2?: string;
+  team2_logo?: string;
   result?: string;
   partials?: string;
   field?: string;
   project?: string;
+  group?: string;
+  match_number?: string;
+  referees?: string;
+  link?: string;
 };
 
 function punteggio(result: string | undefined): [number, number] | null {
@@ -146,12 +253,17 @@ export function partiteDaEventi(eventi: unknown): PartitaCsi[] {
       data: dataIso,
       ora: (oraIso ?? "").slice(0, 5),
       avversario: casa ? team2 : team1,
+      logoAvversario: (casa ? evento.team2_logo : evento.team1_logo)?.trim() ?? "",
       casa,
       setNostri: set ? (casa ? set[0] : set[1]) : null,
       setLoro: set ? (casa ? set[1] : set[0]) : null,
       parziali: casa ? tutti : tutti.map(([a, b]) => [b, a] as [number, number]),
       campo: testo(evento.field ?? ""),
       competizione: testo(evento.project ?? ""),
+      girone: testo(evento.group ?? ""),
+      numeroGara: testo(evento.match_number ?? ""),
+      arbitro: testo(evento.referees ?? ""),
+      link: evento.link?.trim() ?? "",
     });
   }
   return partite.sort((a, b) => b.data.localeCompare(a.data));
@@ -162,15 +274,165 @@ export function partiteGiocate(partite: PartitaCsi[]): PartitaCsi[] {
   return partite.filter((p) => p.setNostri !== null && p.setLoro !== null);
 }
 
+/**
+ * True se il formato di `getEventsByTeamId.php` sembra cambiato: `partiteDaEventi()` fallisce
+ * in modo silenzioso (nessun array o campi non riconosciuti), quindi un array vuoto da solo non
+ * distingue "il portale CSI ha cambiato formato" da "la squadra non ha ancora gare in
+ * programma". Qui invece si confronta con la risposta grezza: se contiene eventi ma nessuno è
+ * stato riconosciuto come nostra partita, è quasi certamente un problema di parsing, non una
+ * stagione senza gare. Usata da `/api/public/csi` per loggare il caso invece di lasciarlo
+ * silenzioso — vedi "Limiti noti" in docs/modules/collegamento-csi.md.
+ */
+export function partiteFormatoSospetto(eventiGrezzi: unknown, partite: PartitaCsi[]): boolean {
+  if (!Array.isArray(eventiGrezzi)) return true;
+  return eventiGrezzi.length > 0 && partite.length === 0;
+}
+
 /** Converte una gara CSI già giocata nella forma comune usata nelle liste risultati. */
 export function matchDaPartitaCsi(p: PartitaCsi) {
   return {
     id: p.id,
     data: p.data,
     avversario: p.avversario,
+    logoAvversario: p.logoAvversario,
     casa: p.casa,
     setNostri: p.setNostri ?? 0,
     setLoro: p.setLoro ?? 0,
     parziali: p.parziali,
+    campo: p.campo,
+    girone: p.girone,
+    numeroGara: p.numeroGara,
+    arbitro: p.arbitro,
+    link: p.link,
+  };
+}
+
+/** Estrae giornata e nota libera (pubblico ammesso, dettagli impianto...) da `match-main.php`. */
+export function parseInfoPartita(html: string): { giornata: string; nota: string } {
+  const giornataM = /(\d+)\s*<sup>a<\/sup>\s*Giornata/.exec(html);
+  const notaM = /<div class="text-start"><span>([^<]*)<\/span><\/div>/.exec(html);
+  return {
+    giornata: giornataM ? `${giornataM[1]}ª Giornata` : "",
+    nota: notaM ? testo(notaM[1] ?? "") : "",
+  };
+}
+
+/**
+ * Una squadra dentro `match-players.php`: una `<ul class="list-group">` di `<li>`, in
+ * ordine titolari → divisore "A DISPOSIZIONE" → panchina → divisore "STAFF" → staff. I
+ * membri dello staff hanno la stessa struttura dei giocatori ma senza numero di maglia.
+ */
+function parseBloccoSquadraFormazione(blocco: string): FormazioneSquadra | null {
+  const nomeM = /team_details\.php\?team_id=\d*"[^>]*>([^<]+)<\/a>/.exec(blocco);
+  const squadra = nomeM ? testo(nomeM[1] ?? "") : "";
+  if (!squadra) return null;
+
+  const titolari: GiocatoreFormazione[] = [];
+  const panchina: GiocatoreFormazione[] = [];
+  const staff: StaffFormazione[] = [];
+  let sezione: "titolari" | "panchina" | "staff" = "titolari";
+  for (const voce of blocco.match(/<li class="list-group-item[\s\S]*?<\/li>/gi) ?? []) {
+    if (/A DISPOSIZIONE/.test(voce)) {
+      sezione = "panchina";
+      continue;
+    }
+    if (/STAFF/.test(voce)) {
+      sezione = "staff";
+      continue;
+    }
+    const nomePersonaM = /person_details\.php\?id=\d+">([^<]+)<\/a>/.exec(voce);
+    if (!nomePersonaM) continue;
+    const nome = testo(nomePersonaM[1] ?? "");
+    const ruoloM = /<div class="small">([^<]*)<\/div>/.exec(voce);
+    const ruolo = ruoloM ? testo(ruoloM[1] ?? "") : "";
+    if (sezione === "staff") {
+      staff.push({ nome, ruolo });
+      continue;
+    }
+    const numeroM = /shrink-8"[^>]*>(\d+)</.exec(voce);
+    const giocatore = { numero: numeroM?.[1] ?? "", nome, ruolo };
+    (sezione === "titolari" ? titolari : panchina).push(giocatore);
+  }
+  return { squadra, titolari, panchina, staff };
+}
+
+/**
+ * Formazioni di entrambe le squadre da `match-players.php`. Il markup non distingue
+ * esplicitamente casa/ospite, ma le racchiude in due blocchi separati dal commento
+ * `<!-- SQUADRA OSPITE -->`; qui si riconosce la nostra tramite `isNostraSquadra()`
+ * invece di assumere un ordine fisso.
+ */
+export function parseFormazioni(
+  html: string,
+): { noi: FormazioneSquadra; avversario: FormazioneSquadra } | null {
+  const idx = html.indexOf("SQUADRA OSPITE");
+  if (idx === -1) return null;
+  const primo = parseBloccoSquadraFormazione(html.slice(0, idx));
+  const secondo = parseBloccoSquadraFormazione(html.slice(idx));
+  if (!primo || !secondo) return null;
+  const noi = isNostraSquadra(primo.squadra)
+    ? primo
+    : isNostraSquadra(secondo.squadra)
+      ? secondo
+      : null;
+  if (!noi) return null;
+  return { noi, avversario: noi === primo ? secondo : primo };
+}
+
+/**
+ * Storico scontri diretti e probabilità di vittoria da `match-stats.php`. Il blocco di
+ * riepilogo (non la lista partita-per-partita nel modal, meno affidabile da interpretare)
+ * riporta i numeri nell'ordine squadra-casa/squadra-ospite di *questa* gara: qui si
+ * riconosce quale delle due siamo noi tramite `isNostraSquadra()`, come in
+ * `parseFormazioni()`. Con "0 precedenti" il CSI omette del tutto le righe
+ * vittorie/in-casa/fuori (restano a 0) ma la probabilità resta comunque presente.
+ */
+export function parsePrecedenti(html: string): PrecedentiCsi | null {
+  const idxCasa = html.indexOf("Squadra casa");
+  const idxOspite = html.indexOf("Squadra ospite");
+  if (idxCasa === -1 || idxOspite === -1) return null;
+  const nomeCasaM = /team_details\.php\?team_id=\d+"[^>]*>([^<]+)<\/a>/.exec(
+    html.slice(idxCasa, idxOspite),
+  );
+  const nomeOspiteM = /team_details\.php\?team_id=\d+"[^>]*>([^<]+)<\/a>/.exec(
+    html.slice(idxOspite),
+  );
+  const nomeCasa = nomeCasaM ? testo(nomeCasaM[1] ?? "") : "";
+  const nomeOspite = nomeOspiteM ? testo(nomeOspiteM[1] ?? "") : "";
+  const noiECasa = isNostraSquadra(nomeCasa);
+  if (!noiECasa && !isNostraSquadra(nomeOspite)) return null;
+
+  const totaleM = /Precedenti:<\/span>\s*<b><a[^>]*>(\d+)<\/a><\/b>/.exec(html);
+  const vittorieM =
+    /<div><b>(\d+)<\/b><\/div>\s*<div[^>]*>vittorie<\/div>\s*<div><b>(\d+)<\/b><\/div>/.exec(html);
+  const inCasaM =
+    /<div><b>(\d+)<\/b><\/div>\s*<div>in casa<\/div>\s*<div><b>(\d+)<\/b><\/div>/.exec(html);
+  const fuoriM = /<div><b>(\d+)<\/b><\/div>\s*<div>fuori<\/div>\s*<div><b>(\d+)<\/b><\/div>/.exec(
+    html,
+  );
+  // Le due barre "progress-bar" appaiono nell'ordine casa/ospite: il colore (verde/rosso)
+  // segue chi è favorito, non la posizione, quindi qui si usa l'ordine nel markup e non la
+  // classe CSS per capire quale percentuale è "nostra".
+  const percentuali = [...html.matchAll(/progress-bar[\s\S]*?width:\s*([\d.]+)%/g)].map((m) =>
+    Number(m[1]),
+  );
+  const [probCasa, probOspite] = percentuali;
+
+  // I due gruppi di ogni regex sono nell'ordine squadra-casa/squadra-ospite di questa gara:
+  // `casaIndice`/`ospiteIndice` scelgono quale dei due è "noi" in base a `noiECasa`.
+  const casaIndice = noiECasa ? 1 : 2;
+  const ospiteIndice = noiECasa ? 2 : 1;
+  const numero = (m: RegExpExecArray | null, indice: 1 | 2) => (m ? Number(m[indice]) : 0);
+
+  return {
+    totale: totaleM ? Number(totaleM[1]) : 0,
+    vinteNoi: numero(vittorieM, casaIndice),
+    vinteAvversario: numero(vittorieM, ospiteIndice),
+    casaNoi: numero(inCasaM, casaIndice),
+    casaAvversario: numero(inCasaM, ospiteIndice),
+    fuoriNoi: numero(fuoriM, casaIndice),
+    fuoriAvversario: numero(fuoriM, ospiteIndice),
+    probabilitaNoi: (noiECasa ? probCasa : probOspite) ?? null,
+    probabilitaAvversario: (noiECasa ? probOspite : probCasa) ?? null,
   };
 }

src/lib/csi-partita.ts

@@ -0,0 +1,21 @@
+import { useQuery } from "@tanstack/react-query";
+import type { DettaglioPartitaCsi } from "./csi-core";
+
+/**
+ * Dettaglio di una singola gara CSI (formazioni, storico scontri diretti): una fetch in
+ * più per partita, cache server 6h come `useCsi()`. Va usato solo quando l'utente apre il
+ * dettaglio di una gara, mai in una lista: vedi docs/modules/collegamento-csi.md.
+ */
+export function useCsiPartita(matchId: string | undefined) {
+  return useQuery<DettaglioPartitaCsi>({
+    queryKey: ["csi-partita", matchId],
+    queryFn: async () => {
+      const res = await fetch(`/api/public/csi-partita/${matchId}`);
+      if (!res.ok) throw new Error("csi-partita non disponibile");
+      return res.json();
+    },
+    enabled: !!matchId,
+    staleTime: 6 * 60 * 60_000,
+    retry: 1,
+  });
+}

src/lib/eventi.ts

@@ -104,7 +104,7 @@ export function eventoVuoto(): Evento {
     id: nuovoIdEvento(),
     tipo: "allenamento",
     titolo: "",
-    luogo: "Palestra Comunale",
+    luogo: "",
     data: new Date().toISOString().slice(0, 10),
     ora: "20:30",
     note: "",
@@ -162,8 +162,18 @@ export function useEliminaEvento() {
   });
 }
 
-/** Compleanni della rosa, come eventi di calendario dell'anno indicato. */
-export function compleanniEventi(rosa: Giocatore[], anno = new Date().getFullYear()): Evento[] {
+/**
+ * Compleanni della rosa, come eventi di calendario dell'anno indicato.
+ *
+ * Prende solo i tre campi che usa (non l'intero `Giocatore`): il Calendario li
+ * legge da un'anagrafica leggera per non tirarsi dietro tutte le statistiche
+ * (MVP, pagelle, cacche, palloni, infortuni) di `useRosa` solo per le date di
+ * nascita.
+ */
+export function compleanniEventi(
+  rosa: Array<Pick<Giocatore, "id" | "nome" | "nascita">>,
+  anno = new Date().getFullYear(),
+): Evento[] {
   return rosa
     .filter((g) => g.nascita)
     .map((g) => {

src/lib/giocatori-squadra.ts

@@ -7,10 +7,14 @@ import { dividiNome, giocatori } from "./crapp-data";
  * truth per il collegamento account ↔ giocatore; `crapp-data.ts` resta il fallback finché
  * la migrazione non è completa (DD-016 regola 1).
  */
+/** Chi gioca e chi allena (DD-034): l'allenatore ha uno slot ma non è nella rosa di gioco. */
+export type TipoMembro = "giocatore" | "allenatore";
+
 export type GiocatoreSquadra = {
   id: string;
   nome: string;
   cognome: string;
+  /** 0 per l'allenatore, che non ha numero di maglia (a database è NULL). */
   numero: number;
   ruolo: string;
   authUserId: string | null;
@@ -18,19 +22,24 @@ export type GiocatoreSquadra = {
   email: string | null;
   numeroTessera: string | null;
   dataTessera: string | null;
+  /** Pubblica a tutta la rosa (M18): sincronizzata da `profili_giocatore.data_nascita`. */
+  nascita: string | null;
+  tipo: TipoMembro;
 };
 
 export type RigaGiocatoreSquadra = {
   id: string;
   nome: string;
   cognome: string;
-  numero: number;
+  numero: number | null;
   ruolo: string;
   auth_user_id: string | null;
   attivo: boolean;
   email: string | null;
   numero_tessera: string | null;
   data_tessera: string | null;
+  nascita: string | null;
+  tipo: TipoMembro;
 };
 
 /** Ruoli ammessi in campo (pallavolo): usati per il menu a tendina del profilo squadra. */
@@ -50,6 +59,8 @@ export function rosaFallback(): GiocatoreSquadra[] {
     email: null,
     numeroTessera: null,
     dataTessera: null,
+    nascita: g.nascita,
+    tipo: "giocatore" as const,
   }));
 }
 
@@ -57,6 +68,24 @@ export function nomeCompleto(g: GiocatoreSquadra): string {
   return `${g.nome} ${g.cognome}`.trim();
 }
 
+export function isAllenatore(g: Pick<GiocatoreSquadra, "tipo"> | null | undefined): boolean {
+  return g?.tipo === "allenatore";
+}
+
+/**
+ * Rosa di gioco: giocatori attivi, senza allenatori (DD-034). È il filtro di presenze,
+ * convocati, voti, palloni, classifiche e badge; gli allenatori compaiono solo dove la
+ * specifica lo dice (Rosa di Squadra, compleanni, promemoria evento).
+ */
+export function inRosa(g: Pick<GiocatoreSquadra, "attivo" | "tipo">): boolean {
+  return g.attivo && g.tipo === "giocatore";
+}
+
+/** Dove un giocatore ha il ruolo in campo, l'allenatore ha scritto «Allenatore». */
+export function ruoloVisibile(g: Pick<GiocatoreSquadra, "ruolo" | "tipo">): string {
+  return g.tipo === "allenatore" ? "Allenatore" : g.ruolo;
+}
+
 /** Lo slot già collegato a questo account, se esiste. */
 export function slotDi(
   righe: GiocatoreSquadra[],
@@ -77,7 +106,7 @@ export function slotPerEmail(
 }
 
 export const COLONNE_SQUADRA =
-  "id, nome, cognome, numero, ruolo, auth_user_id, attivo, email, numero_tessera, data_tessera";
+  "id, nome, cognome, numero, ruolo, auth_user_id, attivo, email, numero_tessera, data_tessera, nascita, tipo";
 
 /** Conversione riga database -> modello applicativo (riusabile anche lato server). */
 export function daRigaSquadra(r: RigaGiocatoreSquadra): GiocatoreSquadra {
@@ -85,13 +114,15 @@ export function daRigaSquadra(r: RigaGiocatoreSquadra): GiocatoreSquadra {
     id: r.id,
     nome: r.nome,
     cognome: r.cognome,
-    numero: r.numero,
+    numero: r.numero ?? 0,
     ruolo: r.ruolo,
     authUserId: r.auth_user_id,
     attivo: r.attivo,
     email: r.email,
     numeroTessera: r.numero_tessera,
     dataTessera: r.data_tessera,
+    nascita: r.nascita,
+    tipo: r.tipo === "allenatore" ? "allenatore" : "giocatore",
   };
 }
 
@@ -115,7 +146,10 @@ export function useGiocatoriSquadra() {
 
 /** Dati squadra: li gestisce solo un amministratore (DD-017). L'email è quella usata per
  * il collegamento automatico al primo accesso (DD-018), non il dato personale del profilo. */
-export type DatiSquadra = Pick<GiocatoreSquadra, "nome" | "cognome" | "numero" | "ruolo" | "email">;
+export type DatiSquadra = Pick<
+  GiocatoreSquadra,
+  "nome" | "cognome" | "numero" | "ruolo" | "email" | "tipo"
+>;
 
 /**
  * Controlli che rispecchiano i vincoli della tabella (`numero > 0`, campi obbligatori):
@@ -125,6 +159,11 @@ export type DatiSquadra = Pick<GiocatoreSquadra, "nome" | "cognome" | "numero" |
 export function validaDatiSquadra(dati: DatiSquadra): string | null {
   if (!dati.nome.trim()) return "Il nome non può essere vuoto.";
   if (!dati.cognome.trim()) return "Il cognome non può essere vuoto.";
+  // L'allenatore non ha numero di maglia né ruolo in campo (DD-034).
+  if (dati.tipo === "allenatore") {
+    if (dati.email?.trim() && !dati.email.includes("@")) return "L'email non è valida.";
+    return null;
+  }
   if (!Number.isInteger(dati.numero) || dati.numero <= 0)
     return "Il numero di maglia deve essere maggiore di zero.";
   if (!dati.ruolo.trim()) return "Il ruolo non può essere vuoto.";
@@ -147,7 +186,19 @@ export function numeroGiaUsato(
   giocatoreId: string,
   numero: number,
 ): boolean {
-  return righe.some((g) => g.id !== giocatoreId && g.attivo && g.numero === numero);
+  return righe.some((g) => g.id !== giocatoreId && inRosa(g) && g.numero === numero);
+}
+
+/** Riga da scrivere: all'allenatore numero NULL e ruolo vuoto, il tipo non cambia qui. */
+function rigaDatiSquadra(dati: DatiSquadra) {
+  const allenatore = dati.tipo === "allenatore";
+  return {
+    nome: dati.nome.trim(),
+    cognome: dati.cognome.trim(),
+    numero: allenatore ? null : dati.numero,
+    ruolo: allenatore ? "" : dati.ruolo.trim(),
+    email: dati.email?.trim() || null,
+  };
 }
 
 /** Modifica dei dati squadra. Solo un admin passa le policy di M1. */
@@ -155,19 +206,13 @@ export function useSalvaDatiSquadra() {
   const queryClient = useQueryClient();
   return useMutation({
     mutationFn: async (input: { giocatoreId: string; dati: DatiSquadra }) => {
-      const dati = {
-        nome: input.dati.nome.trim(),
-        cognome: input.dati.cognome.trim(),
-        numero: input.dati.numero,
-        ruolo: input.dati.ruolo.trim(),
-        email: input.dati.email?.trim() || null,
-      };
+      const riga = rigaDatiSquadra(input.dati);
       const { error } = await supabaseNuoveTabelle
         .from("giocatori_squadra")
-        .update(dati)
+        .update(riga)
         .eq("id", input.giocatoreId);
       if (error) throw error;
-      return { giocatoreId: input.giocatoreId, dati };
+      return { giocatoreId: input.giocatoreId, dati: { ...riga, numero: riga.numero ?? 0 } };
     },
     onSuccess: (input) => {
       queryClient.setQueryData<GiocatoreSquadra[]>(SQUADRA_KEY, (prec) =>
@@ -219,19 +264,55 @@ export function useSalvaTesseramento() {
 export function useAggiungiGiocatore() {
   const queryClient = useQueryClient();
   return useMutation({
-    mutationFn: async (input: { id: string; dati: DatiSquadra }) => {
-      const { error } = await supabaseNuoveTabelle.from("giocatori_squadra").insert({
-        id: input.id,
-        nome: input.dati.nome.trim(),
-        cognome: input.dati.cognome.trim(),
-        numero: input.dati.numero,
-        ruolo: input.dati.ruolo.trim(),
-        email: input.dati.email?.trim() || null,
-      });
+    mutationFn: async (input: { id: string; dati: DatiSquadra }): Promise<GiocatoreSquadra> => {
+      const riga = { id: input.id, tipo: input.dati.tipo, ...rigaDatiSquadra(input.dati) };
+      const { error } = await supabaseNuoveTabelle.from("giocatori_squadra").insert(riga);
       if (error) throw error;
+      // Le colonne non inviate hanno i default della tabella (M1): `attivo` true, il resto NULL.
+      return {
+        ...riga,
+        numero: riga.numero ?? 0,
+        authUserId: null,
+        attivo: true,
+        numeroTessera: null,
+        dataTessera: null,
+        nascita: null,
+      };
     },
-    onSuccess: () => {
-      queryClient.invalidateQueries({ queryKey: SQUADRA_KEY });
+    // Aggiornamento locale della cache: nessuna rilettura, stesso ordine della query
+    // (`.order("cognome").order("nome")`).
+    onSuccess: (nuovo) => {
+      queryClient.setQueryData<GiocatoreSquadra[]>(SQUADRA_KEY, (prec) =>
+        [...(prec ?? []), nuovo].sort(
+          (a, b) => a.cognome.localeCompare(b.cognome) || a.nome.localeCompare(b.nome),
+        ),
+      );
+    },
+  });
+}
+
+/**
+ * Nome e cognome scritti dall'allenatore sul proprio slot (DD-034): per un giocatore sono
+ * dati squadra dell'admin, e il trigger di M21 rifiuta la stessa scrittura.
+ */
+export function useSalvaNomeAllenatore() {
+  const queryClient = useQueryClient();
+  return useMutation({
+    mutationFn: async (input: { giocatoreId: string; nome: string; cognome: string }) => {
+      const dati = { nome: input.nome.trim(), cognome: input.cognome.trim() };
+      if (!dati.nome) throw new Error("Il nome non può essere vuoto.");
+      if (!dati.cognome) throw new Error("Il cognome non può essere vuoto.");
+      const { error } = await supabaseNuoveTabelle
+        .from("giocatori_squadra")
+        .update(dati)
+        .eq("id", input.giocatoreId);
+      if (error) throw error;
+      return { giocatoreId: input.giocatoreId, dati };
+    },
+    onSuccess: (input) => {
+      queryClient.setQueryData<GiocatoreSquadra[]>(SQUADRA_KEY, (prec) =>
+        (prec ?? []).map((g) => (g.id === input.giocatoreId ? { ...g, ...input.dati } : g)),
+      );
     },
   });
 }

src/lib/infortuni.ts

@@ -1,13 +1,31 @@
 import { useMemo } from "react";
 import type { Giocatore } from "./crapp-data";
+import type { Evento } from "./eventi";
+import { useEventi } from "./eventi";
+import { dataOggi } from "./scout-live";
 import { useRispostePresenze, type MappaPresenze } from "./presenze";
 
 /** giocatoreId -> numero di eventi (allenamenti + partite) con stato "infortunato". */
 export type ContoInfortuni = Record<string, number>;
 
-function contaStato(presenze: MappaPresenze, stato: string): ContoInfortuni {
+/**
+ * Un giocatore può segnarsi infortunato o in ritardo anche su un evento futuro
+ * (l'UI lo permette finché l'evento non è passato): finché quell'evento non è
+ * avvenuto davvero non deve contare per i badge, altrimenti si sbloccherebbero
+ * in anticipo. Un evento non più in `eventi` (es. cancellato) non viene contato:
+ * non potendo verificarne la data, si esclude per prudenza.
+ */
+function contaStato(
+  presenze: MappaPresenze,
+  stato: string,
+  eventi: Evento[],
+  oggi: string = dataOggi(),
+): ContoInfortuni {
+  const dataPerEvento = new Map(eventi.map((e) => [e.id, e.data]));
   const out: ContoInfortuni = {};
   for (const eventoId of Object.keys(presenze)) {
+    const dataEvento = dataPerEvento.get(eventoId);
+    if (dataEvento === undefined || dataEvento >= oggi) continue;
     const evento = presenze[eventoId] ?? {};
     for (const giocatoreId of Object.keys(evento)) {
       if (evento[giocatoreId] === stato) out[giocatoreId] = (out[giocatoreId] ?? 0) + 1;
@@ -16,14 +34,22 @@ function contaStato(presenze: MappaPresenze, stato: string): ContoInfortuni {
   return out;
 }
 
-/** Conta gli infortuni dalla mappa presenze già in cache: ogni evento vale una volta sola. */
-export function contaInfortuni(presenze: MappaPresenze): ContoInfortuni {
-  return contaStato(presenze, "infortunato");
+/** Conta gli infortuni dalla mappa presenze già in cache: ogni evento passato vale una volta sola. */
+export function contaInfortuni(
+  presenze: MappaPresenze,
+  eventi: Evento[],
+  oggi: string = dataOggi(),
+): ContoInfortuni {
+  return contaStato(presenze, "infortunato", eventi, oggi);
 }
 
-/** Conta i ritardi dalla stessa mappa presenze: ogni evento vale una volta sola. */
-export function contaRitardi(presenze: MappaPresenze): ContoInfortuni {
-  return contaStato(presenze, "ritardo");
+/** Conta i ritardi dalla stessa mappa presenze: ogni evento passato vale una volta sola. */
+export function contaRitardi(
+  presenze: MappaPresenze,
+  eventi: Evento[],
+  oggi: string = dataOggi(),
+): ContoInfortuni {
+  return contaStato(presenze, "ritardo", eventi, oggi);
 }
 
 export function conInfortuni<T extends Giocatore>(
@@ -38,23 +64,29 @@ export function conInfortuni<T extends Giocatore>(
   };
 }
 
-/** Nessuna query aggiuntiva: riusa la cache delle risposte presenze. */
+/** Nessuna query aggiuntiva: riusa le cache di risposte presenze ed eventi. */
 export function useInfortuni(): ContoInfortuni {
   const { presenze } = useRispostePresenze();
-  return useMemo(() => contaInfortuni(presenze), [presenze]);
+  const { eventi } = useEventi();
+  return useMemo(() => contaInfortuni(presenze, eventi), [presenze, eventi]);
 }
 
-/** Nessuna query aggiuntiva: riusa la cache delle risposte presenze. */
+/** Nessuna query aggiuntiva: riusa le cache di risposte presenze ed eventi. */
 export function useRitardi(): ContoInfortuni {
   const { presenze } = useRispostePresenze();
-  return useMemo(() => contaRitardi(presenze), [presenze]);
+  const { eventi } = useEventi();
+  return useMemo(() => contaRitardi(presenze, eventi), [presenze, eventi]);
 }
 
 /** Un solo hook per entrambi i conteggi: evita hook extra nei componenti. */
 export function useInfortuniERitardi(): { infortuni: ContoInfortuni; ritardi: ContoInfortuni } {
   const { presenze } = useRispostePresenze();
+  const { eventi } = useEventi();
   return useMemo(
-    () => ({ infortuni: contaInfortuni(presenze), ritardi: contaRitardi(presenze) }),
-    [presenze],
+    () => ({
+      infortuni: contaInfortuni(presenze, eventi),
+      ritardi: contaRitardi(presenze, eventi),
+    }),
+    [presenze, eventi],
   );
 }

src/lib/lovable-error-reporting.ts

@@ -1,58 +0,0 @@
-type LovableErrorOptions = {
-  mechanism?: "manual" | "onerror" | "unhandledrejection" | "react_error_boundary";
-  handled?: boolean;
-  severity?: "error" | "warning" | "info";
-};
-
-type LovableEvents = {
-  captureException?: (
-    error: unknown,
-    context?: Record<string, unknown>,
-    options?: LovableErrorOptions,
-  ) => void;
-};
-
-declare global {
-  interface Window {
-    __lovableEvents?: LovableEvents;
-    __lovableReportRuntimeError?: (payload: {
-      message: string;
-      stack?: string;
-      filename?: string;
-    }) => void;
-  }
-}
-
-export function reportLovableError(error: unknown, context: Record<string, unknown> = {}) {
-  if (typeof window === "undefined") return;
-  window.__lovableEvents?.captureException?.(
-    error,
-    {
-      source: "react_error_boundary",
-      route: window.location.pathname,
-      ...context,
-    },
-    {
-      mechanism: "react_error_boundary",
-      handled: false,
-      severity: "error",
-    },
-  );
-  // Prod React does not rethrow boundary-caught errors to window.onerror, so the
-  // editor's telemetry never sees them. Forward to lovable.js's reporting hook,
-  // which is present only inside the editor preview.
-  // Loaders and server fns commonly throw a raw Response; String(it) is the
-  // opaque "[object Response]", so pull out the status and URL instead.
-  const message =
-    error instanceof Response
-      ? `Response ${error.status}${error.url ? ` at ${error.url}` : ""}`
-      : error instanceof Error
-        ? error.message
-        : String(error);
-  const stack = error instanceof Error ? error.stack : undefined;
-  window.__lovableReportRuntimeError?.({
-    message,
-    ...(stack !== undefined && { stack }),
-    filename: window.location.pathname,
-  });
-}

src/lib/mvp-voti.ts

@@ -10,6 +10,16 @@ export type VotoMvp = {
 
 const CHIAVE = ["mvp-voti"] as const;
 
+/** Ore da aspettare dall'inizio della partita prima di poter votare l'MVP. */
+export const ORE_ATTESA_MVP = 2;
+
+/** Il voto MVP apre 2 ore dopo l'inizio della partita e da lì resta aperto. */
+export function votoMvpAperto(data: string, ora: string, adesso = new Date()): boolean {
+  const inizio = new Date(`${data}T${ora || "00:00"}:00`);
+  if (Number.isNaN(inizio.getTime())) return false;
+  return adesso.getTime() >= inizio.getTime() + ORE_ATTESA_MVP * 60 * 60_000;
+}
+
 /** Tutti i voti MVP della squadra (poche righe, si carica tutto).
  *  Nessun polling: la lista si aggiorna dopo il proprio voto o al rientro sull'app. */
 export function useVotiMvp() {
@@ -50,6 +60,9 @@ export function useVotaMvp() {
 
 export type ConteggioMvp = { id: string; nome: string; voti: number };
 
+/** Voti minimi in una partita perché l'MVP possa essere assegnato (un solo voto non decide). */
+export const VOTI_MINIMI_MVP = 2;
+
 /** Conteggio voti di una partita, dal più votato. */
 export function conteggioPartita(voti: VotoMvp[], matchId: string): ConteggioMvp[] {
   const map = new Map<string, ConteggioMvp>();
@@ -73,8 +86,13 @@ export function vincitoriMvp(voti: VotoMvp[]): Record<string, string> {
   const out: Record<string, string> = {};
   for (const [matchId] of perMatch) {
     const top = conteggioPartita(voti, matchId);
-    // In caso di parità nessun MVP assegnato finché il voto non si sblocca.
-    if (top.length > 0 && (top.length === 1 || top[0]!.voti > top[1]!.voti)) {
+    const totaleVoti = top.reduce((s, c) => s + c.voti, 0);
+    // In caso di parità, o sotto il quorum minimo, nessun MVP assegnato.
+    if (
+      totaleVoti >= VOTI_MINIMI_MVP &&
+      top.length > 0 &&
+      (top.length === 1 || top[0]!.voti > top[1]!.voti)
+    ) {
       out[matchId] = top[0]!.nome;
     }
   }
@@ -85,13 +103,22 @@ export function mioVoto(voti: VotoMvp[], matchId: string, votanteId: string) {
   return voti.find((v) => v.match_id === matchId && v.votante_id === votanteId) ?? null;
 }
 
-/** MVP vinti per giocatore, contando una vittoria per partita votata. */
+/**
+ * MVP vinti per giocatore, contando una vittoria per partita votata (una partita in pareggio
+ * al vertice, o sotto il quorum minimo di voti, non assegna vittorie a nessuno). Senza voti
+ * restituisce una mappa vuota.
+ */
 export function mvpVintiPerGiocatore(voti: VotoMvp[]): Record<string, number> {
   const out: Record<string, number> = {};
   const matchIds = new Set(voti.map((v) => v.match_id));
   for (const matchId of matchIds) {
     const top = conteggioPartita(voti, matchId);
-    if (top.length > 0 && (top.length === 1 || top[0]!.voti > top[1]!.voti)) {
+    const totaleVoti = top.reduce((s, c) => s + c.voti, 0);
+    if (
+      totaleVoti >= VOTI_MINIMI_MVP &&
+      top.length > 0 &&
+      (top.length === 1 || top[0]!.voti > top[1]!.voti)
+    ) {
       const id = top[0]!.id;
       out[id] = (out[id] ?? 0) + 1;
     }

src/lib/notifiche-admin.ts

@@ -0,0 +1,37 @@
+import { useMutation, useQuery } from "@tanstack/react-query";
+import { intestazioniAutenticate } from "./auth";
+
+const NOTIFICHE_ATTIVE_KEY = ["notifiche-attive"] as const;
+
+async function fetchNotificheAttive(): Promise<Set<string>> {
+  const res = await fetch("/api/public/notifiche-attive", {
+    headers: await intestazioniAutenticate(),
+  });
+  if (!res.ok) throw new Error("Impossibile leggere le notifiche attive");
+  const { giocatoreIds } = (await res.json()) as { giocatoreIds: string[] };
+  return new Set(giocatoreIds);
+}
+
+/** Insieme degli id giocatore con almeno un dispositivo iscritto alle notifiche push. */
+export function useNotificheAttive() {
+  return useQuery({
+    queryKey: NOTIFICHE_ATTIVE_KEY,
+    queryFn: fetchNotificheAttive,
+    staleTime: 5 * 60_000,
+  });
+}
+
+/** Invia un messaggio push libero a un giocatore, o a tutti se `giocatoreId` è omesso. */
+export function useInviaNotifica() {
+  return useMutation({
+    mutationFn: async ({ messaggio, giocatoreId }: { messaggio: string; giocatoreId?: string }) => {
+      const res = await fetch("/api/public/notifica-personalizzata", {
+        method: "POST",
+        headers: { "Content-Type": "application/json", ...(await intestazioniAutenticate()) },
+        body: JSON.stringify({ messaggio, giocatoreId }),
+      });
+      if (!res.ok) throw new Error("Impossibile inviare la notifica");
+      return (await res.json()) as { inviate: number; destinatari: number };
+    },
+  });
+}

src/lib/notifiche-attive.server.ts

@@ -0,0 +1,4 @@
+/** Id giocatore distinti tra le righe di `push_subscriptions` (una riga per dispositivo). */
+export function idsConNotificheAttive(righe: Array<{ giocatore_id: string }>): string[] {
+  return [...new Set(righe.map((r) => r.giocatore_id))];
+}

src/lib/notifiche-utente.ts

@@ -0,0 +1,145 @@
+import { useMutation, useQuery, useQueryClient } from "@tanstack/react-query";
+import { supabaseNuoveTabelle } from "@/integrations/supabase/client-nuove-tabelle";
+import { useGiocatoreId } from "./user-store";
+
+/**
+ * Centro notifiche in-app (M17): pallino sull'avatar del profilo, con il numero delle non
+ * lette. Quattro sorgenti riempiono `notifiche_utente` (lato database, mai dal client): un
+ * messaggio libero dell'admin, un promemoria automatico prima di un evento (24h e 3h), il
+ * turno palloni e il sollecito presenze (questi due avviati a mano da un admin, in
+ * parallelo alla push esistente). Qui si legge e si segna come letto, con
+ * `supabaseNuoveTabelle` perché `types.ts` non include ancora questa tabella (vedi
+ * client-nuove-tabelle.ts).
+ */
+export type TipoNotifica =
+  | "admin"
+  | "evento_promemoria_24h"
+  | "evento_promemoria_3h"
+  | "turno_palloni"
+  | "sollecita_presenze";
+
+export type NotificaUtente = {
+  id: string;
+  tipo: TipoNotifica;
+  titolo: string;
+  corpo: string;
+  eventoId: string | null;
+  letta: boolean;
+  creataIl: string;
+};
+
+export type RigaNotifica = {
+  id: string;
+  tipo: TipoNotifica;
+  titolo: string;
+  corpo: string;
+  evento_id: string | null;
+  letta: boolean;
+  creato_il: string;
+};
+
+const COLONNE = "id, tipo, titolo, corpo, evento_id, letta, creato_il";
+
+/** Conversione riga database -> modello applicativo. */
+export function daRiga(r: RigaNotifica): NotificaUtente {
+  return {
+    id: r.id,
+    tipo: r.tipo,
+    titolo: r.titolo,
+    corpo: r.corpo,
+    eventoId: r.evento_id,
+    letta: r.letta,
+    creataIl: r.creato_il,
+  };
+}
+
+function chiaveNotifiche(giocatoreId: string | null) {
+  return ["notifiche-utente", giocatoreId] as const;
+}
+
+/** Ultime notifiche del giocatore selezionato, più recenti per prime. */
+export function useNotificheMie() {
+  const giocatoreId = useGiocatoreId();
+  const query = useQuery({
+    queryKey: chiaveNotifiche(giocatoreId),
+    queryFn: async (): Promise<NotificaUtente[]> => {
+      const { data, error } = await supabaseNuoveTabelle
+        .from("notifiche_utente")
+        .select(COLONNE)
+        .eq("giocatore_id", giocatoreId)
+        .order("creato_il", { ascending: false })
+        .limit(30);
+      if (error) throw error;
+      return ((data ?? []) as RigaNotifica[]).map(daRiga);
+    },
+    enabled: !!giocatoreId,
+    staleTime: 30_000,
+    refetchInterval: 60_000,
+  });
+  const notifiche = query.data ?? [];
+  return { ...query, notifiche, nonLette: notifiche.filter((n) => !n.letta).length };
+}
+
+/** Segna come lette tutte le notifiche non lette del giocatore selezionato. */
+export function useSegnaLette() {
+  const giocatoreId = useGiocatoreId();
+  const qc = useQueryClient();
+  return useMutation({
+    mutationFn: async () => {
+      if (!giocatoreId) return;
+      const { error } = await supabaseNuoveTabelle
+        .from("notifiche_utente")
+        .update({ letta: true })
+        .eq("giocatore_id", giocatoreId)
+        .eq("letta", false);
+      if (error) throw error;
+    },
+    onSuccess: () => {
+      qc.setQueryData<NotificaUtente[]>(chiaveNotifiche(giocatoreId), (prec) =>
+        (prec ?? []).map((n) => ({ ...n, letta: true })),
+      );
+    },
+  });
+}
+
+/**
+ * Elimina una notifica del giocatore selezionato (swipe o pulsante nel pannello). A
+ * differenza di "segna come letta" qui la riga sparisce anche dal database, non solo
+ * dalla vista: non c'è pulizia automatica delle notifiche vecchie, quindi eliminarla è
+ * l'unico modo per un giocatore di toglierla di mezzo per sempre.
+ */
+export function useEliminaNotifica() {
+  const giocatoreId = useGiocatoreId();
+  const qc = useQueryClient();
+  return useMutation({
+    mutationFn: async (id: string) => {
+      const { error } = await supabaseNuoveTabelle.from("notifiche_utente").delete().eq("id", id);
+      if (error) throw error;
+      return id;
+    },
+    onSuccess: (id) => {
+      qc.setQueryData<NotificaUtente[]>(chiaveNotifiche(giocatoreId), (prec) =>
+        (prec ?? []).filter((n) => n.id !== id),
+      );
+    },
+  });
+}
+
+/** Testo del badge: il conteggio esatto fino a 9, poi "9+" per non farlo esplodere. */
+export function contatoreBadge(nonLette: number): string {
+  return nonLette > 9 ? "9+" : String(nonLette);
+}
+
+/**
+ * Pallino sull'avatar del profilo: rosso con il numero delle non lette; se sono tutte lette
+ * resta neutro con il totale, altrimenti le notifiche già lette non sarebbero più
+ * raggiungibili per eliminarle. Senza notifiche non c'è (`null`).
+ */
+export function pallinoNotifiche(
+  totale: number,
+  nonLette: number,
+): { testo: string; daLeggere: boolean } | null {
+  if (totale === 0) return null;
+  if (nonLette > 0) return { testo: contatoreBadge(nonLette), daLeggere: true };
+  return { testo: contatoreBadge(totale), daLeggere: false };
+}

src/lib/obiettivi.ts

@@ -26,11 +26,32 @@ export type ContestoObiettivi = {
 
 export const contestoVuoto: ContestoObiettivi = { eventi: [], presenze: {}, pagelle: [] };
 
-const MESE = "2026-08";
+/** Mese corrente in formato "YYYY-MM" (fuso Europe/Rome), per gli obiettivi che si azzerano ogni mese. */
+function meseCorrente(oggi: Date): string {
+  return new Intl.DateTimeFormat("en-CA", { timeZone: "Europe/Rome" }).format(oggi).slice(0, 7);
+}
 
-function percentualePresenzeMese(ctx: ContestoObiettivi, rosaSize: number) {
+/** "a settembre" / "ad agosto": preposizione con elisione davanti a vocale. */
+function aMese(oggi: Date): string {
+  const nome = new Intl.DateTimeFormat("it-IT", { timeZone: "Europe/Rome", month: "long" }).format(
+    oggi,
+  );
+  const preposizione = /^[aeiou]/i.test(nome) ? "ad" : "a";
+  return `${preposizione} ${nome}`;
+}
+
+/** Ultimo giorno del mese corrente, come "YYYY-MM-DD". */
+function fineMese(oggi: Date): string {
+  const mese = meseCorrente(oggi);
+  const anno = Number(mese.slice(0, 4));
+  const numeroMese = Number(mese.slice(5, 7));
+  const ultimoGiorno = new Date(Date.UTC(anno, numeroMese, 0)).getUTCDate();
+  return `${mese}-${String(ultimoGiorno).padStart(2, "0")}`;
+}
+
+function percentualePresenzeMese(ctx: ContestoObiettivi, rosaSize: number, mese: string) {
   const delMese = ctx.eventi.filter(
-    (e) => e.data.startsWith(MESE) && (e.tipo === "partita" || e.tipo === "allenamento"),
+    (e) => e.data.startsWith(mese) && (e.tipo === "partita" || e.tipo === "allenamento"),
   );
   if (delMese.length === 0 || rosaSize === 0) return 0;
   const posti = delMese.length * rosaSize;
@@ -56,19 +77,21 @@ function percentualeRisposte(ctx: ContestoObiettivi, rosaSize: number) {
 export function obiettiviSquadra(
   rosa: Giocatore[] = giocatori,
   ctx: ContestoObiettivi = contestoVuoto,
+  oggi: Date = new Date(),
 ): ObiettivoSquadra[] {
   const somma = (f: (g: Giocatore) => number) => rosa.reduce((s, g) => s + f(g), 0);
   const continui = rosa.filter((g) => g.serieAllenamenti >= 3).length;
   const vittorie = ctx.vittorie ?? 0;
+  const mese = meseCorrente(oggi);
   return [
     {
       id: "o1",
-      titolo: "90% di presenze ad agosto",
+      titolo: `90% di presenze ${aMese(oggi)}`,
       descrizione: "Media presenze su partite e allenamenti del mese",
-      valore: percentualePresenzeMese(ctx, rosa.length),
+      valore: percentualePresenzeMese(ctx, rosa.length, mese),
       target: 90,
       unita: "%",
-      scadenza: "2026-08-31",
+      scadenza: fineMese(oggi),
       emoji: "📣",
       impatto: "Ogni sì in più alza la media di tutta la squadra.",
     },
@@ -79,7 +102,7 @@ export function obiettiviSquadra(
       valore: percentualeRisposte(ctx, rosa.length),
       target: 90,
       unita: "%",
-      scadenza: "2026-09-30",
+      scadenza: fineMese(oggi),
       emoji: "⚡",
       impatto: "Bastano pochi tap per far quadrare i conti a chi organizza.",
     },
@@ -147,7 +170,7 @@ export function obiettiviSquadra(
       id: "o5",
       titolo: "10 vittorie in campionato",
       descrizione: "Obiettivo stagionale per il podio",
-      valore: vittorie,
+      valore: Math.min(vittorie, 10),
       target: 10,
       unita: "vittorie",
       emoji: "🏆",
@@ -157,7 +180,7 @@ export function obiettiviSquadra(
       id: "o6",
       titolo: "1 evento di squadra al mese",
       descrizione: "Pizzate, cene e uscite fuori dal campo",
-      valore: ctx.eventi.filter((e) => e.tipo === "evento" && e.data.startsWith(MESE)).length,
+      valore: ctx.eventi.filter((e) => e.tipo === "evento" && e.data.startsWith(mese)).length,
       target: 1,
       unita: "eventi",
       emoji: "🍕",
@@ -170,8 +193,8 @@ export function progressoObiettivo(o: ObiettivoSquadra) {
   return Math.min(100, Math.round((o.valore / o.target) * 100));
 }
 
-export function obiettiviOrdinati(rosa?: Giocatore[], ctx?: ContestoObiettivi) {
-  return obiettiviSquadra(rosa, ctx).sort((a, b) => {
+export function obiettiviOrdinati(rosa?: Giocatore[], ctx?: ContestoObiettivi, oggi?: Date) {
+  return obiettiviSquadra(rosa, ctx, oggi).sort((a, b) => {
     const pa = progressoObiettivo(a);
     const pb = progressoObiettivo(b);
     const ca = pa >= 100 ? 1 : 0;

src/lib/pagelle.ts

@@ -1,5 +1,6 @@
 import { useMutation, useQuery, useQueryClient } from "@tanstack/react-query";
 import { supabase } from "@/integrations/supabase/client";
+import { VOTI_MINIMI_PAGELLA } from "./badges";
 
 /** Voto anonimo da 1 a 10 dato a un compagno per una partita. */
 export type VotoPagella = {
@@ -60,7 +61,11 @@ function arrotonda(n: number) {
   return Math.round(n * 10) / 10;
 }
 
-/** Media stagionale di ciascun giocatore: giocatoreId -> media e numero di voti. */
+/**
+ * Media storica di ciascun giocatore su tutti i voti mai ricevuti (l'app non ha un concetto
+ * di stagione/reset): giocatoreId -> media e numero di voti. Chi non ha ancora ricevuto voti
+ * non compare nella mappa (nessuna divisione per zero): sta al chiamante gestire il fallback.
+ */
 export function mediePagelle(voti: VotoPagella[]): Record<string, MediaPagella> {
   const somma: Record<string, { tot: number; n: number }> = {};
   for (const v of voti) {
@@ -90,6 +95,15 @@ export function mieiVoti(voti: VotoPagella[], matchId: string, votanteId: string
   return out;
 }
 
+/**
+ * Media voto da mostrare nella StatTile home (sezione «Colpo d'occhio», DD-028): sotto
+ * `VOTI_MINIMI_PAGELLA` voti ricevuti, `—` invece della media grezza — stessa soglia del
+ * badge Pagellone, non applicata invece dalle StatTile di profilo e squadra.
+ */
+export function mediaVotoColpoDOcchio(g: { mediaVoto: number; votiPagella: number }): number | "—" {
+  return g.votiPagella >= VOTI_MINIMI_PAGELLA ? g.mediaVoto : "—";
+}
+
 /** Media pagelle di tutta la squadra su tutte le partite. */
 export function mediaSquadra(voti: VotoPagella[]) {
   if (voti.length === 0) return 0;

src/lib/palloni-core.ts

@@ -1,15 +1,17 @@
 import { formatData } from "./crapp-data";
 import type { Evento } from "./eventi";
+import { dataOggi } from "./scout-live";
+import { aggiornaSerie } from "./serie";
 
 export type Turno = { evento_id: string; giocatore_id: string; aggiornato_da: string | null };
 
 /** Candidato al turno palloni: solo id e nome bastano per assegnare e ordinare. */
 export type CandidatoTurno = { id: string; nome: string };
 
-/** Eventi che richiedono i palloni (allenamenti, partite, extra), in ordine di data. */
+/** Eventi che richiedono i palloni (solo allenamenti e partite), in ordine di data. */
 export function eventiPalloni(eventi: Evento[]): Evento[] {
   return eventi
-    .filter((e) => e.tipo !== "compleanno")
+    .filter((e) => e.tipo === "allenamento" || e.tipo === "partita")
     .slice()
     .sort((a, b) => a.data.localeCompare(b.data));
 }
@@ -19,7 +21,7 @@ export function eventiPalloni(eventi: Evento[]): Evento[] {
  * meno volte (a parità, chi non lo fa da più tempo).
  *
  * Gli **allenamenti** non vengono proposti: restano «da assegnare» finché qualcuno
- * non conferma un incaricato a mano. Su partite ed eventi extra la rotazione resta.
+ * non conferma un incaricato a mano. Sulle partite la rotazione resta.
  */
 export function completaTurni(
   turni: Record<string, string>,
@@ -60,13 +62,43 @@ export function completaTurni(
   return risultato;
 }
 
-/** Quante volte ciascun giocatore è incaricato dei palloni. */
-export function conteggioTurni(turni: Record<string, string>): Record<string, number> {
+/**
+ * Quante volte ciascun giocatore è incaricato dei palloni, solo per eventi già passati:
+ * un turno assegnato in anticipo per un allenamento futuro non è ancora "portato", quindi
+ * non deve contare finché quell'allenamento non è terminato (stesso criterio `e.data < oggi`
+ * usato per le presenze, così la conta non cambia da sola col passare della giornata).
+ */
+export function conteggioTurni(
+  turni: Record<string, string>,
+  eventi: Evento[],
+  oggi: string = dataOggi(),
+): Record<string, number> {
+  const passati = new Set(eventi.filter((e) => e.data < oggi).map((e) => e.id));
   const out: Record<string, number> = {};
-  for (const id of Object.values(turni)) out[id] = (out[id] ?? 0) + 1;
+  for (const [eventoId, giocatoreId] of Object.entries(turni)) {
+    if (!passati.has(eventoId)) continue;
+    out[giocatoreId] = (out[giocatoreId] ?? 0) + 1;
+  }
   return out;
 }
 
+/**
+ * Volte consecutive in cui il giocatore ha portato i palloni, contando solo eventi già
+ * passati (stesso criterio `e.data < oggi` di `conteggioTurni`): un evento passato senza
+ * turno confermato non spezza la serie di nessuno, perché non dice ancora chi ha portato
+ * i palloni quella volta.
+ */
+export function serieConsecutivaPalloni(
+  giocatoreId: string,
+  turni: Record<string, string>,
+  eventi: Evento[],
+  oggi: string = dataOggi(),
+): number {
+  return eventiPalloni(eventi)
+    .filter((e) => e.data < oggi && turni[e.id])
+    .reduce((serie, e) => aggiornaSerie(serie, turni[e.id] === giocatoreId), 0);
+}
+
 export function eventiDelGiorno(eventi: Evento[], isoData: string): Evento[] {
   return eventiPalloni(eventi).filter((e) => e.data === isoData);
 }
@@ -84,10 +116,9 @@ export function eventoSuccessivo(eventi: Evento[], eventoId: string): Evento | u
   return i >= 0 ? lista[i + 1] : undefined;
 }
 
+/** Alias di `dataOggi()`, nel fuso di Roma: qui per non toccare gli import esistenti. */
 export function oggiISO(d = new Date()): string {
-  const mm = String(d.getMonth() + 1).padStart(2, "0");
-  const dd = String(d.getDate()).padStart(2, "0");
-  return `${d.getFullYear()}-${mm}-${dd}`;
+  return dataOggi(d);
 }
 
 /** Chi deve ricevere l'avviso push, oggi: chi porta i palloni e chi li riprende. */

src/lib/palloni.ts

@@ -2,7 +2,7 @@ import { useMutation, useQuery, useQueryClient } from "@tanstack/react-query";
 import { supabase } from "@/integrations/supabase/client";
 import { completaTurni } from "./palloni-core";
 import { useEventi } from "./eventi";
-import { nomeCompleto, useGiocatoriSquadra } from "./giocatori-squadra";
+import { inRosa, nomeCompleto, useGiocatoriSquadra } from "./giocatori-squadra";
 
 export const TURNI_KEY = ["turni-palloni"] as const;
 
@@ -29,7 +29,7 @@ export function useTurniPalloni() {
   const { eventi } = useEventi();
   const { righe: squadra } = useGiocatoriSquadra();
   const salvati = query.data ?? {};
-  const rosa = squadra.filter((g) => g.attivo).map((g) => ({ id: g.id, nome: nomeCompleto(g) }));
+  const rosa = squadra.filter(inRosa).map((g) => ({ id: g.id, nome: nomeCompleto(g) }));
   return { ...query, salvati, turni: completaTurni(salvati, eventi, rosa) };
 }
 

src/lib/presenze-mese.ts

@@ -1,7 +1,7 @@
 import { useMemo } from "react";
 import { useEventi } from "./eventi";
 import { useRispostePresenze } from "./presenze";
-import { useGiocatoriSquadra } from "./giocatori-squadra";
+import { inRosa, useGiocatoriSquadra } from "./giocatori-squadra";
 import {
   presenzeUltimoMese,
   presenzeUltimoMeseTutti,
@@ -30,7 +30,7 @@ export function usePresenzeUltimoMeseTutti(): Record<string, StatistichePresenza
   const { righe: squadra } = useGiocatoriSquadra();
 
   return useMemo(() => {
-    const idRosa = squadra.filter((g) => g.attivo).map((g) => g.id);
+    const idRosa = squadra.filter(inRosa).map((g) => g.id);
     return presenzeUltimoMeseTutti(eventi, presenze, idRosa);
   }, [eventi, presenze, squadra]);
 }

src/lib/presenze.ts

@@ -1,7 +1,8 @@
 import { useMutation, useQuery, useQueryClient } from "@tanstack/react-query";
 import { supabase } from "@/integrations/supabase/client";
 import type { Stato } from "./crapp-data";
-import type { Evento } from "./eventi";
+import type { Evento, EventoTipo } from "./eventi";
+import { inRosa, type TipoMembro } from "./giocatori-squadra";
 import { aggiornaSerie } from "./serie";
 import { dataOggi } from "./scout-live";
 
@@ -14,49 +15,117 @@ export type MappaPresenze = Record<string, Record<string, Stato>>;
 export type MappaTempiRisposta = Record<string, Record<string, string>>;
 
 /** Allenamenti e partite CrAPP già passati, che contano per le statistiche di presenza. */
-function eventiContanoPresenze(eventi: Evento[], giocatoreId?: string) {
-  const oggi = dataOggi();
+function eventiContanoPresenze(
+  eventi: Evento[],
+  giocatoreId?: string,
+  oggi = dataOggi(),
+  tipo?: "partita" | "allenamento",
+) {
   return eventi.filter(
     (e) =>
       (e.tipo === "partita" || e.tipo === "allenamento") &&
+      (tipo === undefined || e.tipo === tipo) &&
       e.data < oggi &&
       (giocatoreId === undefined || e.convocati.length === 0 || e.convocati.includes(giocatoreId)),
   );
 }
 
-/** Presenze effettive (presente o in ritardo) su eventi CrAPP. */
+/**
+ * Presenze effettive (presente o in ritardo) su eventi CrAPP. Senza eventi rilevanti
+ * restituisce 0. `tipo` filtra a un solo tipo di evento (es. solo partite); di default
+ * conta partite e allenamenti insieme, come il resto delle statistiche di presenza.
+ */
 export function contaPresenzeGiocatore(
   giocatoreId: string,
   eventi: Evento[],
   presenze: MappaPresenze,
+  oggi: string = dataOggi(),
+  tipo?: "partita" | "allenamento",
 ): number {
-  return eventiContanoPresenze(eventi, giocatoreId).filter((e) => {
+  return eventiContanoPresenze(eventi, giocatoreId, oggi, tipo).filter((e) => {
     const stato = presenze[e.id]?.[giocatoreId];
     return stato === "presente" || stato === "ritardo";
   }).length;
 }
 
+/**
+ * Partite (non allenamenti) a cui il giocatore era presente o in ritardo: il dato giusto
+ * per contesti legati alle prestazioni in campo (es. MVP), a differenza di
+ * `totaliEventiGiocatore()` che è il denominatore delle presenze e include gli allenamenti.
+ */
+export function contaPartiteGiocate(
+  giocatoreId: string,
+  eventi: Evento[],
+  presenze: MappaPresenze,
+  oggi: string = dataOggi(),
+): number {
+  return contaPresenzeGiocatore(giocatoreId, eventi, presenze, oggi, "partita");
+}
+
 /** Eventi CrAPP rilevanti per il denominatore presenze di un giocatore. */
-export function totaliEventiGiocatore(giocatoreId: string, eventi: Evento[]): number {
-  return eventiContanoPresenze(eventi, giocatoreId).length;
+export function totaliEventiGiocatore(
+  giocatoreId: string,
+  eventi: Evento[],
+  oggi: string = dataOggi(),
+): number {
+  return eventiContanoPresenze(eventi, giocatoreId, oggi).length;
+}
+
+/**
+ * Se "infortunato" va offerto come risposta: sì per allenamenti e partite, no per gli
+ * eventi extra-campo (`"evento"`, es. cena di squadra), dove l'infortunio non è una
+ * risposta pertinente. Resta comunque visibile a chi ce l'ha già (dati storici, o un
+ * evento cambiato tipo dopo la risposta), così può ancora toglierla.
+ */
+export function includeInfortunato(tipo: EventoTipo, statoAttuale?: Stato | null): boolean {
+  return tipo !== "evento" || statoAttuale === "infortunato";
+}
+
+/**
+ * Chi va sollecitato per un evento: i giocatori attivi (non gli allenatori) che non hanno ancora risposto, più
+ * quelli che hanno risposto «forse». Funzione pura, come `avvisiPalloniEvento()` per i
+ * palloni: la route `/api/public/sollecita-presenze` la chiama con i dati che ha già letto.
+ */
+export function destinatariSollecito(
+  squadra: Array<{ id: string; attivo: boolean; tipo: TipoMembro }>,
+  risposte: Array<{ giocatore_id: string; stato: string }>,
+): string[] {
+  const stati = new Map(risposte.map((r) => [r.giocatore_id, r.stato]));
+  // L'allenatore non risponde alle presenze, quindi non va sollecitato (DD-034).
+  return squadra
+    .filter(inRosa)
+    .filter((g) => {
+      const stato = stati.get(g.id);
+      return stato === undefined || stato === "forse";
+    })
+    .map((g) => g.id);
 }
 
 /**
  * Serie di presenze consecutive su eventi già passati, in ordine di data:
  * ogni presenza (o ritardo) vale +1, qualsiasi altra risposta — o nessuna
  * risposta — azzera la serie. Senza `tipo` conta partite e allenamenti insieme.
+ *
+ * Chi risulta infortunato non ci ha rinunciato: quell'evento è saltato, non conta
+ * né come presenza né come assenza, e la serie resta congelata al valore di prima.
  */
 export function serieConsecutiva(
   giocatoreId: string,
   eventi: Evento[],
   presenze: MappaPresenze,
   tipo?: "partita" | "allenamento",
-  oggi: string = oggiIso(),
+  oggi: string = dataOggi(),
 ): number {
-  return serieSu(giocatoreId, eventi, oggi, tipo, (e) => {
-    const stato = presenze[e.id]?.[giocatoreId];
-    return stato === "presente" || stato === "ritardo";
-  });
+  return serieSu(
+    giocatoreId,
+    eventi.filter((e) => presenze[e.id]?.[giocatoreId] !== "infortunato"),
+    oggi,
+    tipo,
+    (e) => {
+      const stato = presenze[e.id]?.[giocatoreId];
+      return stato === "presente" || stato === "ritardo";
+    },
+  );
 }
 
 const ORE_24 = 24 * 60 * 60 * 1000;
@@ -70,7 +139,7 @@ export function serieConferme(
   giocatoreId: string,
   eventi: Evento[],
   tempi: MappaTempiRisposta,
-  oggi: string = oggiIso(),
+  oggi: string = dataOggi(),
 ): number {
   return serieSu(
     giocatoreId,
@@ -84,10 +153,6 @@ export function serieConferme(
   );
 }
 
-function oggiIso() {
-  return new Date().toISOString().slice(0, 10);
-}
-
 /** Scorre gli eventi già passati in ordine di data applicando la regola delle serie. */
 function serieSu(
   giocatoreId: string,
@@ -96,8 +161,8 @@ function serieSu(
   tipo: "partita" | "allenamento" | undefined,
   onorato: (e: Evento) => boolean,
 ): number {
-  return eventiContanoPresenze(eventi, giocatoreId)
-    .filter((e) => (tipo === undefined || e.tipo === tipo) && e.data <= oggi)
+  return eventiContanoPresenze(eventi, giocatoreId, oggi)
+    .filter((e) => tipo === undefined || e.tipo === tipo)
     .sort((a, b) => a.data.localeCompare(b.data))
     .reduce((serie, e) => aggiornaSerie(serie, onorato(e)), 0);
 }
@@ -129,6 +194,38 @@ export function usePresenzeEvento(eventoId: string) {
   return { ...resto, risposte: presenze[eventoId] ?? {} };
 }
 
+/**
+ * La cache delle presenze dopo una risposta salvata, senza rileggere il database.
+ *
+ * Due dettagli non sono cosmetici e non vanno persi (vedi `docs/modules/serie-presenze.md`):
+ *
+ * - l'istante si scrive **solo se manca** (`??=`), come fa il database, dove `risposto_il`
+ *   non viene inviato sull'upsert e un trigger lo congela: è la prima risposta, non l'ultima,
+ *   e un ripensamento non deve far ripartire il cronometro della serie "Conferme 24h";
+ * - cancellare la risposta (`stato: null`) elimina **anche** l'istante, così se il giocatore
+ *   risponde di nuovo il cronometro riparte davvero — ha ritirato la risposta.
+ */
+export function conRisposta(
+  prec: LetturaPresenze | undefined,
+  input: { eventoId: string; giocatoreId: string; stato: Stato | null },
+  adesso: string = new Date().toISOString(),
+): LetturaPresenze {
+  const presenze: MappaPresenze = { ...(prec?.presenze ?? {}) };
+  const tempi: MappaTempiRisposta = { ...(prec?.tempi ?? {}) };
+  const stati = { ...(presenze[input.eventoId] ?? {}) };
+  const istanti = { ...(tempi[input.eventoId] ?? {}) };
+  if (input.stato === null) {
+    delete stati[input.giocatoreId];
+    delete istanti[input.giocatoreId];
+  } else {
+    stati[input.giocatoreId] = input.stato;
+    istanti[input.giocatoreId] ??= adesso;
+  }
+  presenze[input.eventoId] = stati;
+  tempi[input.eventoId] = istanti;
+  return { presenze, tempi };
+}
+
 export function useSalvaPresenza() {
   const queryClient = useQueryClient();
   return useMutation({
@@ -156,23 +253,7 @@ export function useSalvaPresenza() {
     },
     // Scrittura unica + aggiornamento cache locale, nessuna rilettura.
     onSuccess: (input) => {
-      queryClient.setQueryData<LetturaPresenze>(PRESENZE_KEY, (prec) => {
-        const presenze: MappaPresenze = { ...(prec?.presenze ?? {}) };
-        const tempi: MappaTempiRisposta = { ...(prec?.tempi ?? {}) };
-        const stati = { ...(presenze[input.eventoId] ?? {}) };
-        const istanti = { ...(tempi[input.eventoId] ?? {}) };
-        if (input.stato === null) {
-          delete stati[input.giocatoreId];
-          delete istanti[input.giocatoreId];
-        } else {
-          stati[input.giocatoreId] = input.stato;
-          // Come a database: l'istante è quello della prima risposta, non dei ripensamenti.
-          istanti[input.giocatoreId] ??= new Date().toISOString();
-        }
-        presenze[input.eventoId] = stati;
-        tempi[input.eventoId] = istanti;
-        return { presenze, tempi };
-      });
+      queryClient.setQueryData<LetturaPresenze>(PRESENZE_KEY, (prec) => conRisposta(prec, input));
     },
   });
 }

src/lib/profili-core.ts

@@ -1,5 +1,5 @@
 import { rigaCsv } from "./scout-export";
-import { nomeCompleto, type GiocatoreSquadra } from "./giocatori-squadra";
+import { inRosa, nomeCompleto, type GiocatoreSquadra } from "./giocatori-squadra";
 
 /**
  * Profilo amministrativo di un giocatore (DD-016). I file veri stanno nel bucket privato
@@ -144,6 +144,18 @@ export function completamento(p: Profilo | null | undefined): number {
   );
 }
 
+/**
+ * L'allenatore compila solo i dati personali ridotti (DD-034): niente indirizzo, documento,
+ * certificato né foto tessera, che servono al tesseramento dei giocatori.
+ */
+export const CAMPI_ALLENATORE = ["dataNascita", "luogoNascita", "telefono", "email"] as const;
+
+/** Percentuale dei campi dell'allenatore compilati: 100 quando ci sono tutti. */
+export function completamentoAllenatore(p: Profilo | null | undefined): number {
+  const pieni = CAMPI_ALLENATORE.filter((c) => !!p?.[c]?.trim()).length;
+  return Math.round((pieni / CAMPI_ALLENATORE.length) * 100);
+}
+
 export type StatoScadenza = "mancante" | "scaduto" | "valido";
 
 /** Un certificato scaduto blocca il tesseramento: per l'admin non vale come presente. */
@@ -203,3 +215,73 @@ export function csvTesseramento(
 export function etichettaGiocatore(g: GiocatoreSquadra): string {
   return `#${g.numero} ${nomeCompleto(g)}`;
 }
+
+/** Soglia dell'avviso certificati in Home (DD-035). */
+export const GIORNI_AVVISO_CERTIFICATO = 7;
+
+/** Giorni di calendario tra due date `AAAA-MM-GG` (ora locale): negativo se `scadenza` è passata. */
+export function giorniAllaScadenza(scadenza: string, oggi: string): number {
+  const a = new Date(`${scadenza}T00:00:00`);
+  const b = new Date(`${oggi}T00:00:00`);
+  return Math.round((a.getTime() - b.getTime()) / 86_400_000);
+}
+
+/** Data in formato `GG/MM/AAAA`, per i testi dell'avviso certificati. */
+export function formatDataBreve(iso: string): string {
+  return new Date(`${iso}T00:00:00`).toLocaleDateString("it-IT", {
+    day: "2-digit",
+    month: "2-digit",
+    year: "numeric",
+  });
+}
+
+/** Riga dell'avviso certificati per un giocatore (DD-035). */
+export function testoScadenza(giorni: number): string {
+  if (giorni === 0) return "scade oggi";
+  if (giorni === 1) return "scade domani";
+  return `scade tra ${giorni} giorni`;
+}
+
+export type AvvisoCertificato = {
+  giocatoreId: string;
+  nome: string;
+  cognome: string;
+  scadenza: string;
+  giorni: number;
+};
+
+function confrontaAvvisi(a: AvvisoCertificato, b: AvvisoCertificato): number {
+  return a.giorni - b.giorni || a.cognome.localeCompare(b.cognome) || a.nome.localeCompare(b.nome);
+}
+
+/**
+ * Certificati in scadenza o scaduti nella rosa (DD-035): calcolato al volo da
+ * `certificato_scadenza`, niente stato salvato. Esclude chi non è in rosa e chi non ha
+ * ancora un certificato caricato (è un problema diverso, non un avviso di scadenza).
+ */
+export function avvisiCertificati(
+  rosa: GiocatoreSquadra[],
+  profili: Record<string, Profilo>,
+  oggi: string,
+): { scaduti: AvvisoCertificato[]; inScadenza: AvvisoCertificato[] } {
+  const scaduti: AvvisoCertificato[] = [];
+  const inScadenza: AvvisoCertificato[] = [];
+  for (const g of rosa) {
+    if (!inRosa(g)) continue;
+    const p = profili[g.id];
+    if (!p?.certificatoScadenza || !p.certificatoPath) continue;
+    const giorni = giorniAllaScadenza(p.certificatoScadenza, oggi);
+    if (giorni > GIORNI_AVVISO_CERTIFICATO) continue;
+    const avviso: AvvisoCertificato = {
+      giocatoreId: g.id,
+      nome: g.nome,
+      cognome: g.cognome,
+      scadenza: p.certificatoScadenza,
+      giorni,
+    };
+    (giorni < 0 ? scaduti : inScadenza).push(avviso);
+  }
+  scaduti.sort(confrontaAvvisi);
+  inScadenza.sort(confrontaAvvisi);
+  return { scaduti, inScadenza };
+}

src/lib/rosa.ts

@@ -1,15 +1,16 @@
 import { useMemo } from "react";
-import { nascitaPerId, type Giocatore } from "./crapp-data";
-import { nomeCompleto, useGiocatoriSquadra } from "./giocatori-squadra";
+import type { Giocatore } from "./crapp-data";
+import { inRosa, nomeCompleto, useGiocatoriSquadra } from "./giocatori-squadra";
 import { mvpVintiPerGiocatore, useVotiMvp } from "./mvp-voti";
 import { mediePagelle, usePagelle } from "./pagelle";
 import { statisticheCacche, useCacche } from "./cacche";
-import { conteggioTurni } from "./palloni-core";
+import { conteggioTurni, serieConsecutivaPalloni } from "./palloni-core";
 import { useTurniPalloni } from "./palloni";
 import { useInfortuniERitardi } from "./infortuni";
 import { useGiocatoreId } from "./user-store";
 import { useEventi } from "./eventi";
 import {
+  contaPartiteGiocate,
   contaPresenzeGiocatore,
   serieConferme,
   serieConsecutiva,
@@ -24,11 +25,39 @@ function iniziali(nome: string, cognome: string): string {
   return `${nome[0] ?? ""}${cognome[0] ?? ""}`.toUpperCase();
 }
 
+/**
+ * Solo anagrafica (id, nome, ruolo, numero, data di nascita) dei giocatori attivi — es.
+ * per le liste presenze o lo scout. A differenza di `useRosa` non legge MVP, pagelle,
+ * cacche, palloni né infortuni: evita di montare quei cinque hook e il relativo `useMemo`
+ * solo per l'anagrafica. Con `conAllenatori` include anche gli allenatori attivi, per chi
+ * elenca i membri della squadra e non solo chi gioca (compleanni in Calendario, DD-034).
+ */
+export function useAnagraficaRosa({
+  conAllenatori = false,
+}: { conAllenatori?: boolean } = {}): Array<
+  Pick<Giocatore, "id" | "nome" | "ruolo" | "numero" | "nascita">
+> {
+  const { righe: squadra } = useGiocatoriSquadra();
+  return useMemo(
+    () =>
+      squadra
+        .filter((g) => (conAllenatori ? g.attivo : inRosa(g)))
+        .map((g) => ({
+          id: g.id,
+          nome: nomeCompleto(g),
+          ruolo: g.ruolo,
+          numero: g.numero,
+          nascita: g.nascita ?? "",
+        })),
+    [squadra, conAllenatori],
+  );
+}
+
 /**
  * Rosa completa con tutte le statistiche personali (presenze, MVP, media voto,
  * palloni, infortuni, ritardi, cacche). Legge l'anagrafica da `giocatori_squadra`
  * (DD-015): solo i giocatori attivi, gli altri restano nel database ma spariscono
- * dagli elenchi correnti. Usa solo cache già in memoria: nessuna query aggiuntiva
+ * dagli elenchi correnti. Gli allenatori non ci sono (DD-034): non hanno statistiche. Usa solo cache già in memoria: nessuna query aggiuntiva
  * rispetto a quelle che l'app fa comunque.
  */
 export function useRosa(): Giocatore[] {
@@ -36,43 +65,107 @@ export function useRosa(): Giocatore[] {
   const voti = useVotiMvp();
   const { voti: pagelle } = usePagelle();
   const { righe: cacche } = useCacche();
-  const { turni } = useTurniPalloni();
+  const { salvati: turniSalvati } = useTurniPalloni();
   const { infortuni, ritardi } = useInfortuniERitardi();
   const { eventi } = useEventi();
   const { presenze: mappaPresenze, tempi } = useRispostePresenze();
 
-  const votiMvp = voti.data ?? [];
+  const votiMvp = voti.data;
 
   return useMemo(() => {
     const medie = mediePagelle(pagelle);
     const statCacche = statisticheCacche(cacche);
-    const palloni = conteggioTurni(turni);
-    const mvpVinti = mvpVintiPerGiocatore(votiMvp);
+    // Solo i turni confermati, non le proposte automatiche di completaTurni(): il badge deve
+    // premiare chi ha davvero portato i palloni, non chi l'algoritmo di rotazione ha
+    // scelto per un evento passato senza che nessuno confermasse nulla.
+    const palloni = conteggioTurni(turniSalvati, eventi);
+    const mvpVinti = mvpVintiPerGiocatore(votiMvp ?? []);
 
-    return squadra
-      .filter((g) => g.attivo)
-      .map((g) => ({
-        id: g.id,
-        nome: nomeCompleto(g),
-        numero: g.numero,
-        ruolo: g.ruolo,
-        nascita: nascitaPerId[g.id] ?? "",
-        iniziali: iniziali(g.nome, g.cognome),
-        presenze: contaPresenzeGiocatore(g.id, eventi, mappaPresenze),
-        totaliEventi: totaliEventiGiocatore(g.id, eventi),
-        streak: serieConsecutiva(g.id, eventi, mappaPresenze),
-        serieAllenamenti: serieConsecutiva(g.id, eventi, mappaPresenze, "allenamento"),
-        seriePartite: serieConsecutiva(g.id, eventi, mappaPresenze, "partita"),
-        serieConferme: serieConferme(g.id, eventi, tempi),
-        mvp: mvpVinti[g.id] ?? 0,
-        mediaVoto: medie[g.id]?.media ?? 0,
-        palloni: palloni[g.id] ?? 0,
-        cacche: statCacche[g.id]?.giornateTop ?? 0,
-        cacchePartita: statCacche[g.id]?.media ?? 0,
-        infortuni: infortuni[g.id] ?? 0,
-        ritardi: ritardi[g.id] ?? 0,
-      }));
-  }, [squadra, votiMvp, pagelle, cacche, turni, infortuni, ritardi, eventi, mappaPresenze, tempi]);
+    return squadra.filter(inRosa).map((g) => ({
+      id: g.id,
+      nome: nomeCompleto(g),
+      numero: g.numero,
+      ruolo: g.ruolo,
+      nascita: g.nascita ?? "",
+      iniziali: iniziali(g.nome, g.cognome),
+      presenze: contaPresenzeGiocatore(g.id, eventi, mappaPresenze),
+      totaliEventi: totaliEventiGiocatore(g.id, eventi),
+      partiteGiocate: contaPartiteGiocate(g.id, eventi, mappaPresenze),
+      streak: serieConsecutiva(g.id, eventi, mappaPresenze),
+      serieAllenamenti: serieConsecutiva(g.id, eventi, mappaPresenze, "allenamento"),
+      seriePartite: serieConsecutiva(g.id, eventi, mappaPresenze, "partita"),
+      serieConferme: serieConferme(g.id, eventi, tempi),
+      mvp: mvpVinti[g.id] ?? 0,
+      mediaVoto: medie[g.id]?.media ?? 0,
+      votiPagella: medie[g.id]?.voti ?? 0,
+      palloni: palloni[g.id] ?? 0,
+      seriePalloni: serieConsecutivaPalloni(g.id, turniSalvati, eventi),
+      cacche: statCacche[g.id]?.giornateTop ?? 0,
+      cacchePartita: statCacche[g.id]?.media ?? 0,
+      infortuni: infortuni[g.id] ?? 0,
+      ritardi: ritardi[g.id] ?? 0,
+    }));
+  }, [
+    squadra,
+    votiMvp,
+    pagelle,
+    cacche,
+    turniSalvati,
+    infortuni,
+    ritardi,
+    eventi,
+    mappaPresenze,
+    tempi,
+  ]);
+}
+
+/** Criteri di ordinamento della classifica interna di Squadra. */
+export type CriterioClassifica = "presenze" | "mediaVoto" | "mvp" | "palloni" | "cacchePartita";
+
+/**
+ * Dettaglio mostrato sotto il nome nella classifica interna, coerente col criterio
+ * selezionato: mostrare sempre le "presenze consecutive" aveva senso solo per Presenze,
+ * per gli altri criteri era un dato fuorviante perché scollegato dal valore in classifica.
+ */
+export function dettaglioClassifica(
+  g: {
+    streak: number;
+    votiPagella: number;
+    partiteGiocate: number;
+    cacche: number;
+    seriePalloni: number;
+  },
+  criterio: CriterioClassifica,
+): string {
+  switch (criterio) {
+    case "mediaVoto":
+      return `${g.votiPagella} voti pagella`;
+    case "mvp":
+      return `${g.partiteGiocate} partite giocate`;
+    case "cacchePartita":
+      return `${g.cacche} giornate top`;
+    case "palloni":
+      return `${g.seriePalloni} volte consecutive`;
+    default:
+      return `${g.streak} presenze consecutive`;
+  }
+}
+
+/**
+ * Posizione in classifica ("dense rank"): a parità di valore i giocatori condividono la
+ * stessa posizione e il numero successivo non salta (1, 1, 2 — non 1, 1, 3). `valori` deve
+ * essere già ordinato in modo decrescente, coerente con l'ordine visualizzato.
+ */
+export function classificaRank(valori: number[]): number[] {
+  const rank: number[] = [];
+  for (let i = 0; i < valori.length; i++) {
+    if (i > 0 && valori[i] === valori[i - 1]) {
+      rank.push(rank[i - 1] ?? 1);
+    } else {
+      rank.push((rank[i - 1] ?? 0) + 1);
+    }
+  }
+  return rank;
 }
 
 /** Il giocatore selezionato sul dispositivo, con le statistiche complete. */

src/lib/ruoli.ts

@@ -2,33 +2,57 @@ import { useQuery } from "@tanstack/react-query";
 import { supabase } from "@/integrations/supabase/client";
 import { useSessione } from "./auth";
 
-export const RUOLI_KEY = ["ruolo-admin"] as const;
+export const RUOLI_KEY = ["ruoli-utente"] as const;
+
+export type Ruolo = "admin" | "allenatore";
 
 /**
- * Permessi di amministrazione: unica fonte è `user_roles` nel database (DD-011).
- * Nessuna lista di nomi, altrimenti basterebbe scegliere il nome giusto per amministrare.
+ * Permessi: unica fonte è `user_roles` nel database (DD-011). Nessuna lista di nomi,
+ * altrimenti basterebbe scegliere il nome giusto per amministrare. Il ruolo `allenatore`
+ * lo scrive un trigger quando si collega uno slot di tipo allenatore (M21, DD-034).
  */
 
 /** `null` = nessuna sessione, quindi il database non ha una risposta da dare. */
-async function fetchRuoloAdmin(utenteId: string | null): Promise<boolean | null> {
+async function fetchRuoli(utenteId: string | null): Promise<Ruolo[] | null> {
   if (!utenteId) return null;
   const { data, error } = await supabase
     .from("user_roles")
     .select("role")
     .eq("user_id", utenteId)
-    .eq("role", "admin")
-    .maybeSingle();
+    .in("role", ["admin", "allenatore"]);
   if (error) throw error;
-  return !!data;
+  return (data ?? []).map((r) => r.role as Ruolo);
+}
+
+function useRuoliQuery() {
+  const { utenteId } = useSessione();
+  // Il ruolo cambia solo quando un admin lo assegna: una lettura per sessione basta.
+  return useQuery({
+    queryKey: [...RUOLI_KEY, utenteId],
+    queryFn: () => fetchRuoli(utenteId),
+    staleTime: 30 * 60_000,
+  });
+}
+
+function useRuoli(): Ruolo[] {
+  return useRuoliQuery().data ?? [];
+}
+
+/** L'avviso certificati (DD-035) aspetta i ruoli: niente flash dell'avviso sbagliato. */
+export function useRuoliPronti(): boolean {
+  return !useRuoliQuery().isPending;
 }
 
 export function useIsAdmin(): boolean {
-  const { utenteId } = useSessione();
-  // Il ruolo cambia solo quando un admin lo assegna: una lettura per sessione basta.
-  const query = useQuery({
-    queryKey: [...RUOLI_KEY, utenteId],
-    queryFn: () => fetchRuoloAdmin(utenteId),
-    staleTime: 30 * 60_000,
-  });
-  return query.data === true;
+  return useRuoli().includes("admin");
+}
+
+export function useIsAllenatore(): boolean {
+  return useRuoli().includes("allenatore");
+}
+
+/** Chi crea e modifica gli eventi e sollecita le presenze: admin o allenatore (DD-034). */
+export function usePuoGestireEventi(): boolean {
+  const ruoli = useRuoli();
+  return ruoli.includes("admin") || ruoli.includes("allenatore");
 }

src/lib/scout-live.ts

@@ -6,9 +6,15 @@ import { useEventi, type Evento } from "./eventi";
 /** Minuti dopo i quali una sessione scout inattiva viene considerata libera. */
 export const SCADENZA_MINUTI = 5;
 
-export function dataOggi(): string {
-  const d = new Date();
-  return `${d.getFullYear()}-${String(d.getMonth() + 1).padStart(2, "0")}-${String(d.getDate()).padStart(2, "0")}`;
+/**
+ * Data di oggi in Italia (`Europe/Rome`, con cambio ora legale/solare gestito dal database
+ * IANA dei fusi orari). Non i getter locali di `Date` — quelli seguono il fuso del processo
+ * che esegue il codice: sul client di chi è in Italia coincide, ma lato server (SSR, dev
+ * container) è spesso UTC, e `toISOString()` lo è sempre. Sbagliare qui sposta la mezzanotte:
+ * nella prima ora o due della giornata italiana, eventi già passati risulterebbero "di domani".
+ */
+export function dataOggi(adesso: Date = new Date()): string {
+  return new Intl.DateTimeFormat("en-CA", { timeZone: "Europe/Rome" }).format(adesso);
 }
 
 /** La partita in programma oggi, se c'è. */

src/lib/scout-store.ts

@@ -135,7 +135,12 @@ export function useSalvaScoutMatch() {
       if (error) throw error;
       return input.match;
     },
-    onSuccess: () => queryClient.invalidateQueries({ queryKey: SCOUT_MATCHES_KEY }),
+    // La query ordina per `creato_il` decrescente: la partita appena salvata è la più recente.
+    onSuccess: (match) =>
+      queryClient.setQueryData<ScoutMatch[]>(SCOUT_MATCHES_KEY, (prec) => [
+        match,
+        ...(prec ?? []).filter((m) => m.id !== match.id),
+      ]),
   });
 }
 
@@ -147,7 +152,10 @@ export function useEliminaScoutMatch() {
       if (error) throw error;
       return id;
     },
-    onSuccess: () => queryClient.invalidateQueries({ queryKey: SCOUT_MATCHES_KEY }),
+    onSuccess: (id) =>
+      queryClient.setQueryData<ScoutMatch[]>(SCOUT_MATCHES_KEY, (prec) =>
+        (prec ?? []).filter((m) => m.id !== id),
+      ),
   });
 }
 

src/lib/user-store.ts

@@ -1,6 +1,6 @@
 import { useSyncExternalStore } from "react";
 import type { Giocatore } from "./crapp-data";
-import { useGiocatoriSquadra, type GiocatoreSquadra } from "./giocatori-squadra";
+import { isAllenatore, useGiocatoriSquadra, type GiocatoreSquadra } from "./giocatori-squadra";
 import { useIo } from "./rosa";
 
 const KEY = "crapp-user-v1";
@@ -56,6 +56,23 @@ export function useGiocatoreBase(): GiocatoreSquadra | null {
   return id ? (righe.find((x) => x.id === id) ?? null) : null;
 }
 
+/**
+ * Chi usa l'app è un allenatore (DD-034): decide cosa si vede (niente badge, cacche,
+ * stagione, obiettivi). I permessi veri stanno in `user_roles` (`usePuoGestireEventi`).
+ */
+export function useSonoAllenatore(): boolean {
+  return isAllenatore(useGiocatoreBase());
+}
+
+/**
+ * Il proprio slot solo se è di un giocatore: per rispondere alle presenze, votare,
+ * dichiarare le cacche o portare i palloni. Per l'allenatore è `null`.
+ */
+export function useGiocatoreInCampo(): GiocatoreSquadra | null {
+  const g = useGiocatoreBase();
+  return g && !isAllenatore(g) ? g : null;
+}
+
 /** Giocatore corrente con statistiche calcolate da dati reali (presenze, MVP, badge, …). */
 export function useGiocatoreCorrente(): Giocatore | null {
   return useIo();

src/routeTree.gen.ts

@@ -19,13 +19,19 @@ import { Route as ProfiloRouteImport } from './routes/profilo'
 import { Route as ScoutRouteImport } from './routes/scout'
 import { Route as SquadraRouteImport } from './routes/squadra'
 import { Route as AllenamentoIdRouteImport } from './routes/allenamento.$id'
+import { Route as EventoIdRouteImport } from './routes/evento.$id'
+import { Route as PartitaCsiIdRouteImport } from './routes/partita-csi.$id'
 import { Route as PartitaIdRouteImport } from './routes/partita.$id'
 import { Route as ApiPublicApriSondaggioRouteImport } from './routes/api/public/apri-sondaggio'
 import { Route as ApiPublicCsiRouteImport } from './routes/api/public/csi'
+import { Route as ApiPublicKeepaliveRouteImport } from './routes/api/public/keepalive'
+import { Route as ApiPublicNotificaPersonalizzataRouteImport } from './routes/api/public/notifica-personalizzata'
+import { Route as ApiPublicNotificheAttiveRouteImport } from './routes/api/public/notifiche-attive'
 import { Route as ApiPublicPromemoriaPalloniRouteImport } from './routes/api/public/promemoria-palloni'
 import { Route as ApiPublicPushConfigRouteImport } from './routes/api/public/push-config'
 import { Route as ApiPublicPushSubscribeRouteImport } from './routes/api/public/push-subscribe'
 import { Route as ApiPublicSollecitaPresenzeRouteImport } from './routes/api/public/sollecita-presenze'
+import { Route as ApiPublicCsiPartitaIdRouteImport } from './routes/api/public/csi-partita.$id'
 
 const IndexRoute = IndexRouteImport.update({
   id: '/',
@@ -77,6 +83,16 @@ const AllenamentoIdRoute = AllenamentoIdRouteImport.update({
   path: '/allenamento/$id',
   getParentRoute: () => rootRouteImport,
 } as any)
+const EventoIdRoute = EventoIdRouteImport.update({
+  id: '/evento/$id',
+  path: '/evento/$id',
+  getParentRoute: () => rootRouteImport,
+} as any)
+const PartitaCsiIdRoute = PartitaCsiIdRouteImport.update({
+  id: '/partita-csi/$id',
+  path: '/partita-csi/$id',
+  getParentRoute: () => rootRouteImport,
+} as any)
 const PartitaIdRoute = PartitaIdRouteImport.update({
   id: '/partita/$id',
   path: '/partita/$id',
@@ -92,6 +108,23 @@ const ApiPublicCsiRoute = ApiPublicCsiRouteImport.update({
   path: '/api/public/csi',
   getParentRoute: () => rootRouteImport,
 } as any)
+const ApiPublicKeepaliveRoute = ApiPublicKeepaliveRouteImport.update({
+  id: '/api/public/keepalive',
+  path: '/api/public/keepalive',
+  getParentRoute: () => rootRouteImport,
+} as any)
+const ApiPublicNotificaPersonalizzataRoute =
+  ApiPublicNotificaPersonalizzataRouteImport.update({
+    id: '/api/public/notifica-personalizzata',
+    path: '/api/public/notifica-personalizzata',
+    getParentRoute: () => rootRouteImport,
+  } as any)
+const ApiPublicNotificheAttiveRoute =
+  ApiPublicNotificheAttiveRouteImport.update({
+    id: '/api/public/notifiche-attive',
+    path: '/api/public/notifiche-attive',
+    getParentRoute: () => rootRouteImport,
+  } as any)
 const ApiPublicPromemoriaPalloniRoute =
   ApiPublicPromemoriaPalloniRouteImport.update({
     id: '/api/public/promemoria-palloni',
@@ -114,6 +147,11 @@ const ApiPublicSollecitaPresenzeRoute =
     path: '/api/public/sollecita-presenze',
     getParentRoute: () => rootRouteImport,
   } as any)
+const ApiPublicCsiPartitaIdRoute = ApiPublicCsiPartitaIdRouteImport.update({
+  id: '/api/public/csi-partita/$id',
+  path: '/api/public/csi-partita/$id',
+  getParentRoute: () => rootRouteImport,
+} as any)
 
 export interface FileRoutesByFullPath {
   '/': typeof IndexRoute
@@ -126,13 +164,19 @@ export interface FileRoutesByFullPath {
   '/scout': typeof ScoutRoute
   '/squadra': typeof SquadraRoute
   '/allenamento/$id': typeof AllenamentoIdRoute
+  '/evento/$id': typeof EventoIdRoute
+  '/partita-csi/$id': typeof PartitaCsiIdRoute
   '/partita/$id': typeof PartitaIdRoute
   '/api/public/apri-sondaggio': typeof ApiPublicApriSondaggioRoute
   '/api/public/csi': typeof ApiPublicCsiRoute
+  '/api/public/keepalive': typeof ApiPublicKeepaliveRoute
+  '/api/public/notifica-personalizzata': typeof ApiPublicNotificaPersonalizzataRoute
+  '/api/public/notifiche-attive': typeof ApiPublicNotificheAttiveRoute
   '/api/public/promemoria-palloni': typeof ApiPublicPromemoriaPalloniRoute
   '/api/public/push-config': typeof ApiPublicPushConfigRoute
   '/api/public/push-subscribe': typeof ApiPublicPushSubscribeRoute
   '/api/public/sollecita-presenze': typeof ApiPublicSollecitaPresenzeRoute
+  '/api/public/csi-partita/$id': typeof ApiPublicCsiPartitaIdRoute
 }
 export interface FileRoutesByTo {
   '/': typeof IndexRoute
@@ -145,13 +189,19 @@ export interface FileRoutesByTo {
   '/scout': typeof ScoutRoute
   '/squadra': typeof SquadraRoute
   '/allenamento/$id': typeof AllenamentoIdRoute
+  '/evento/$id': typeof EventoIdRoute
+  '/partita-csi/$id': typeof PartitaCsiIdRoute
   '/partita/$id': typeof PartitaIdRoute
   '/api/public/apri-sondaggio': typeof ApiPublicApriSondaggioRoute
   '/api/public/csi': typeof ApiPublicCsiRoute
+  '/api/public/keepalive': typeof ApiPublicKeepaliveRoute
+  '/api/public/notifica-personalizzata': typeof ApiPublicNotificaPersonalizzataRoute
+  '/api/public/notifiche-attive': typeof ApiPublicNotificheAttiveRoute
   '/api/public/promemoria-palloni': typeof ApiPublicPromemoriaPalloniRoute
   '/api/public/push-config': typeof ApiPublicPushConfigRoute
   '/api/public/push-subscribe': typeof ApiPublicPushSubscribeRoute
   '/api/public/sollecita-presenze': typeof ApiPublicSollecitaPresenzeRoute
+  '/api/public/csi-partita/$id': typeof ApiPublicCsiPartitaIdRoute
 }
 export interface FileRoutesById {
   __root__: typeof rootRouteImport
@@ -165,13 +215,19 @@ export interface FileRoutesById {
   '/scout': typeof ScoutRoute
   '/squadra': typeof SquadraRoute
   '/allenamento/$id': typeof AllenamentoIdRoute
+  '/evento/$id': typeof EventoIdRoute
+  '/partita-csi/$id': typeof PartitaCsiIdRoute
   '/partita/$id': typeof PartitaIdRoute
   '/api/public/apri-sondaggio': typeof ApiPublicApriSondaggioRoute
   '/api/public/csi': typeof ApiPublicCsiRoute
+  '/api/public/keepalive': typeof ApiPublicKeepaliveRoute
+  '/api/public/notifica-personalizzata': typeof ApiPublicNotificaPersonalizzataRoute
+  '/api/public/notifiche-attive': typeof ApiPublicNotificheAttiveRoute
   '/api/public/promemoria-palloni': typeof ApiPublicPromemoriaPalloniRoute
   '/api/public/push-config': typeof ApiPublicPushConfigRoute
   '/api/public/push-subscribe': typeof ApiPublicPushSubscribeRoute
   '/api/public/sollecita-presenze': typeof ApiPublicSollecitaPresenzeRoute
+  '/api/public/csi-partita/$id': typeof ApiPublicCsiPartitaIdRoute
 }
 export interface FileRouteTypes {
   fileRoutesByFullPath: FileRoutesByFullPath
@@ -186,13 +242,19 @@ export interface FileRouteTypes {
     | '/scout'
     | '/squadra'
     | '/allenamento/$id'
+    | '/evento/$id'
+    | '/partita-csi/$id'
     | '/partita/$id'
     | '/api/public/apri-sondaggio'
     | '/api/public/csi'
+    | '/api/public/keepalive'
+    | '/api/public/notifica-personalizzata'
+    | '/api/public/notifiche-attive'
     | '/api/public/promemoria-palloni'
     | '/api/public/push-config'
     | '/api/public/push-subscribe'
     | '/api/public/sollecita-presenze'
+    | '/api/public/csi-partita/$id'
   fileRoutesByTo: FileRoutesByTo
   to:
     | '/'
@@ -205,13 +267,19 @@ export interface FileRouteTypes {
     | '/scout'
     | '/squadra'
     | '/allenamento/$id'
+    | '/evento/$id'
+    | '/partita-csi/$id'
     | '/partita/$id'
     | '/api/public/apri-sondaggio'
     | '/api/public/csi'
+    | '/api/public/keepalive'
+    | '/api/public/notifica-personalizzata'
+    | '/api/public/notifiche-attive'
     | '/api/public/promemoria-palloni'
     | '/api/public/push-config'
     | '/api/public/push-subscribe'
     | '/api/public/sollecita-presenze'
+    | '/api/public/csi-partita/$id'
   id:
     | '__root__'
     | '/'
@@ -224,13 +292,19 @@ export interface FileRouteTypes {
     | '/scout'
     | '/squadra'
     | '/allenamento/$id'
+    | '/evento/$id'
+    | '/partita-csi/$id'
     | '/partita/$id'
     | '/api/public/apri-sondaggio'
     | '/api/public/csi'
+    | '/api/public/keepalive'
+    | '/api/public/notifica-personalizzata'
+    | '/api/public/notifiche-attive'
     | '/api/public/promemoria-palloni'
     | '/api/public/push-config'
     | '/api/public/push-subscribe'
     | '/api/public/sollecita-presenze'
+    | '/api/public/csi-partita/$id'
   fileRoutesById: FileRoutesById
 }
 export interface RootRouteChildren {
@@ -244,13 +318,19 @@ export interface RootRouteChildren {
   ScoutRoute: typeof ScoutRoute
   SquadraRoute: typeof SquadraRoute
   AllenamentoIdRoute: typeof AllenamentoIdRoute
+  EventoIdRoute: typeof EventoIdRoute
+  PartitaCsiIdRoute: typeof PartitaCsiIdRoute
   PartitaIdRoute: typeof PartitaIdRoute
   ApiPublicApriSondaggioRoute: typeof ApiPublicApriSondaggioRoute
   ApiPublicCsiRoute: typeof ApiPublicCsiRoute
+  ApiPublicKeepaliveRoute: typeof ApiPublicKeepaliveRoute
+  ApiPublicNotificaPersonalizzataRoute: typeof ApiPublicNotificaPersonalizzataRoute
+  ApiPublicNotificheAttiveRoute: typeof ApiPublicNotificheAttiveRoute
   ApiPublicPromemoriaPalloniRoute: typeof ApiPublicPromemoriaPalloniRoute
   ApiPublicPushConfigRoute: typeof ApiPublicPushConfigRoute
   ApiPublicPushSubscribeRoute: typeof ApiPublicPushSubscribeRoute
   ApiPublicSollecitaPresenzeRoute: typeof ApiPublicSollecitaPresenzeRoute
+  ApiPublicCsiPartitaIdRoute: typeof ApiPublicCsiPartitaIdRoute
 }
 
 declare module '@tanstack/react-router' {
@@ -325,6 +405,20 @@ declare module '@tanstack/react-router' {
       preLoaderRoute: typeof AllenamentoIdRouteImport
       parentRoute: typeof rootRouteImport
     }
+    '/evento/$id': {
+      id: '/evento/$id'
+      path: '/evento/$id'
+      fullPath: '/evento/$id'
+      preLoaderRoute: typeof EventoIdRouteImport
+      parentRoute: typeof rootRouteImport
+    }
+    '/partita-csi/$id': {
+      id: '/partita-csi/$id'
+      path: '/partita-csi/$id'
+      fullPath: '/partita-csi/$id'
+      preLoaderRoute: typeof PartitaCsiIdRouteImport
+      parentRoute: typeof rootRouteImport
+    }
     '/partita/$id': {
       id: '/partita/$id'
       path: '/partita/$id'
@@ -346,6 +440,27 @@ declare module '@tanstack/react-router' {
       preLoaderRoute: typeof ApiPublicCsiRouteImport
       parentRoute: typeof rootRouteImport
     }
+    '/api/public/keepalive': {
+      id: '/api/public/keepalive'
+      path: '/api/public/keepalive'
+      fullPath: '/api/public/keepalive'
+      preLoaderRoute: typeof ApiPublicKeepaliveRouteImport
+      parentRoute: typeof rootRouteImport
+    }
+    '/api/public/notifica-personalizzata': {
+      id: '/api/public/notifica-personalizzata'
+      path: '/api/public/notifica-personalizzata'
+      fullPath: '/api/public/notifica-personalizzata'
+      preLoaderRoute: typeof ApiPublicNotificaPersonalizzataRouteImport
+      parentRoute: typeof rootRouteImport
+    }
+    '/api/public/notifiche-attive': {
+      id: '/api/public/notifiche-attive'
+      path: '/api/public/notifiche-attive'
+      fullPath: '/api/public/notifiche-attive'
+      preLoaderRoute: typeof ApiPublicNotificheAttiveRouteImport
+      parentRoute: typeof rootRouteImport
+    }
     '/api/public/promemoria-palloni': {
       id: '/api/public/promemoria-palloni'
       path: '/api/public/promemoria-palloni'
@@ -374,6 +489,13 @@ declare module '@tanstack/react-router' {
       preLoaderRoute: typeof ApiPublicSollecitaPresenzeRouteImport
       parentRoute: typeof rootRouteImport
     }
+    '/api/public/csi-partita/$id': {
+      id: '/api/public/csi-partita/$id'
+      path: '/api/public/csi-partita/$id'
+      fullPath: '/api/public/csi-partita/$id'
+      preLoaderRoute: typeof ApiPublicCsiPartitaIdRouteImport
+      parentRoute: typeof rootRouteImport
+    }
   }
 }
 
@@ -388,13 +510,19 @@ const rootRouteChildren: RootRouteChildren = {
   ScoutRoute: ScoutRoute,
   SquadraRoute: SquadraRoute,
   AllenamentoIdRoute: AllenamentoIdRoute,
+  EventoIdRoute: EventoIdRoute,
+  PartitaCsiIdRoute: PartitaCsiIdRoute,
   PartitaIdRoute: PartitaIdRoute,
   ApiPublicApriSondaggioRoute: ApiPublicApriSondaggioRoute,
   ApiPublicCsiRoute: ApiPublicCsiRoute,
+  ApiPublicKeepaliveRoute: ApiPublicKeepaliveRoute,
+  ApiPublicNotificaPersonalizzataRoute: ApiPublicNotificaPersonalizzataRoute,
+  ApiPublicNotificheAttiveRoute: ApiPublicNotificheAttiveRoute,
   ApiPublicPromemoriaPalloniRoute: ApiPublicPromemoriaPalloniRoute,
   ApiPublicPushConfigRoute: ApiPublicPushConfigRoute,
   ApiPublicPushSubscribeRoute: ApiPublicPushSubscribeRoute,
   ApiPublicSollecitaPresenzeRoute: ApiPublicSollecitaPresenzeRoute,
+  ApiPublicCsiPartitaIdRoute: ApiPublicCsiPartitaIdRoute,
 }
 export const routeTree = rootRouteImport
   ._addFileChildren(rootRouteChildren)

src/routes/__root.tsx

@@ -12,12 +12,12 @@ import {
 import { useEffect, useState, type ReactNode } from "react";
 
 import appCss from "../styles.css?url";
-import { reportLovableError } from "../lib/lovable-error-reporting";
 import { BottomNav } from "../components/crapp/BottomNav";
 import { CelebrazioneBadge } from "../components/crapp/CelebrazioneBadge";
 import { Toaster } from "../components/ui/sonner";
 import { TeamLogo } from "../components/crapp/ui-bits";
 import { useGiocatoreBase } from "../lib/user-store";
+import { useGiocatoriSquadra } from "../lib/giocatori-squadra";
 import { useSessione } from "../lib/auth";
 import { mantieniWorkerPushAggiornato } from "../lib/push-client";
 
@@ -46,9 +46,6 @@ function NotFoundComponent() {
 function ErrorComponent({ error, reset }: { error: Error; reset: () => void }) {
   console.error(error);
   const router = useRouter();
-  useEffect(() => {
-    reportLovableError(error, { boundary: "tanstack_root_error_component" });
-  }, [error]);
 
   return (
     <div className="flex min-h-dvh items-center justify-center bg-background px-4">
@@ -172,6 +169,7 @@ function AppShell() {
   const navigate = useNavigate();
   const location = useLocation();
   const giocatore = useGiocatoreBase();
+  const { isPending: squadraInCorso } = useGiocatoriSquadra();
   const { pronta, utenteId } = useSessione();
   const [mounted, setMounted] = useState(false);
   const isBenvenuto = location.pathname === "/benvenuto";
@@ -180,15 +178,18 @@ function AppShell() {
 
   // Senza sessione Google non si entra: l'identità la dà il login, non la scelta del nome
   // (DD-011). Si aspetta `pronta`, altrimenti il primo render sloggato rimbalzerebbe fuori
-  // chi ha già la sessione in localStorage.
+  // chi ha già la sessione in localStorage. Si aspetta anche `squadraInCorso`: finché la
+  // rosa non è arrivata, `giocatore` risulta nullo anche per chi è già collegato (la rosa
+  // di riserva usa id diversi da quelli veri), e rimbalzerebbe su /benvenuto chi stava solo
+  // ricaricando una pagina profonda come /eventi.
   useEffect(() => {
     setMounted(true);
-    if (pronta && (!giocatore || !utenteId) && !isBenvenuto) {
-      navigate({ to: "/benvenuto" });
+    if (pronta && !squadraInCorso && (!giocatore || !utenteId) && !isBenvenuto) {
+      navigate({ to: "/benvenuto", search: { next: location.pathname } });
     }
-  }, [giocatore, utenteId, pronta, isBenvenuto, navigate]);
+  }, [giocatore, utenteId, pronta, squadraInCorso, isBenvenuto, navigate, location.pathname]);
 
-  if (!mounted || !pronta) {
+  if (!mounted || !pronta || squadraInCorso) {
     return (
       <div className="grid min-h-dvh place-items-center bg-background">
         <TeamLogo className="h-16 w-16 animate-pulse" />

src/routes/admin.tsx

@@ -2,6 +2,8 @@ import { useState } from "react";
 import { createFileRoute } from "@tanstack/react-router";
 import {
   BadgeCheck,
+  Bell,
+  BellOff,
   ChevronDown,
   Download,
   FileText,
@@ -9,6 +11,7 @@ import {
   Image,
   Loader2,
   Lock,
+  Send,
   Unlink,
   UserCheck,
   UserPlus,
@@ -16,20 +19,17 @@ import {
 } from "lucide-react";
 import { toast } from "sonner";
 import { cn } from "@/lib/utils";
+import { Campo, classiInput, PageHeader, Select, StatTile } from "@/components/crapp/ui-bits";
+import { BarraSottosezioni } from "@/components/crapp/BarraSottosezioni";
+import { CampiAllenatore, CampiProfilo } from "@/components/crapp/ProfiloAmministrativo";
 import {
-  Campo,
-  classiInput,
-  PageHeader,
-  Section,
-  Select,
-  StatTile,
-} from "@/components/crapp/ui-bits";
-import { CampiProfilo } from "@/components/crapp/ProfiloAmministrativo";
-import {
+  inRosa,
+  isAllenatore,
   nomeCompleto,
   numeroGiaUsato,
   prossimoIdGiocatore,
   RUOLI,
+  ruoloVisibile,
   useAggiungiGiocatore,
   useGiocatoriSquadra,
   useImpostaAttivo,
@@ -44,6 +44,7 @@ import {
 import { scaricaFile, useProfili, useSalvaProfilo } from "@/lib/profili";
 import {
   completamento,
+  completamentoAllenatore,
   csvTesseramento,
   profiloVuoto,
   sezioniComplete,
@@ -54,7 +55,17 @@ import {
 import { oggiISO } from "@/lib/palloni-core";
 import { scaricaCsv } from "@/lib/scout-export";
 import { useIsAdmin } from "@/lib/ruoli";
+import { useInviaNotifica, useNotificheAttive } from "@/lib/notifiche-admin";
 import { Reveal } from "@/components/motion/Reveal";
+import {
+  Drawer,
+  DrawerClose,
+  DrawerContent,
+  DrawerDescription,
+  DrawerFooter,
+  DrawerHeader,
+  DrawerTitle,
+} from "@/components/ui/drawer";
 
 export const Route = createFileRoute("/admin")({
   head: () => ({
@@ -119,7 +130,10 @@ function ModificaGiocatore({ g, profilo }: { g: GiocatoreSquadra; profilo: Profi
     numero: g.numero,
     ruolo: g.ruolo,
     email: g.email,
+    tipo: g.tipo,
   };
+  // L'allenatore non ha numero, ruolo in campo né tesseramento (DD-034).
+  const allenatore = isAllenatore(g);
   const profiloCorrente = bozza ?? profilo ?? profiloVuoto(g.id);
 
   async function confermaSquadra() {
@@ -128,7 +142,7 @@ function ModificaGiocatore({ g, profilo }: { g: GiocatoreSquadra; profilo: Profi
       toast.error(errore);
       return;
     }
-    if (numeroGiaUsato(righe, g.id, squadraCorrente.numero)) {
+    if (!allenatore && numeroGiaUsato(righe, g.id, squadraCorrente.numero)) {
       toast.error(`Il numero ${squadraCorrente.numero} è già assegnato a un altro giocatore.`);
       return;
     }
@@ -209,30 +223,36 @@ function ModificaGiocatore({ g, profilo }: { g: GiocatoreSquadra; profilo: Profi
             className={classiInput}
           />
         </Campo>
-        <Campo label="Numero">
-          <input
-            type="number"
-            min={1}
-            value={squadraCorrente.numero}
-            onChange={(e) => setDatiSquadra({ ...squadraCorrente, numero: Number(e.target.value) })}
-            className={classiInput}
-          />
-        </Campo>
-        <Campo label="Ruolo">
-          <Select
-            value={squadraCorrente.ruolo}
-            onChange={(e) => setDatiSquadra({ ...squadraCorrente, ruolo: e.target.value })}
-          >
-            <option value="">—</option>
-            {RUOLI.map((r) => (
-              <option key={r} value={r}>
-                {r}
-              </option>
-            ))}
-          </Select>
-        </Campo>
+        {allenatore ? null : (
+          <>
+            <Campo label="Numero">
+              <input
+                type="number"
+                min={1}
+                value={squadraCorrente.numero}
+                onChange={(e) =>
+                  setDatiSquadra({ ...squadraCorrente, numero: Number(e.target.value) })
+                }
+                className={classiInput}
+              />
+            </Campo>
+            <Campo label="Ruolo">
+              <Select
+                value={squadraCorrente.ruolo}
+                onChange={(e) => setDatiSquadra({ ...squadraCorrente, ruolo: e.target.value })}
+              >
+                <option value="">—</option>
+                {RUOLI.map((r) => (
+                  <option key={r} value={r}>
+                    {r}
+                  </option>
+                ))}
+              </Select>
+            </Campo>
+          </>
+        )}
       </div>
-      <Campo label="Email (collegamento automatico al login, DD-018)">
+      <Campo label="Email">
         <input
           type="email"
           value={squadraCorrente.email ?? ""}
@@ -250,44 +270,61 @@ function ModificaGiocatore({ g, profilo }: { g: GiocatoreSquadra; profilo: Profi
         Salva dati squadra
       </button>
 
-      <h3 className="font-display text-sm uppercase tracking-wide">Tesseramento CSI</h3>
-      <div className="grid grid-cols-2 gap-3">
-        <Campo label="Numero tessera">
-          <input
-            value={tesseramentoCorrente.numeroTessera ?? ""}
-            maxLength={40}
-            placeholder="Non ancora tesserato"
-            onChange={(e) =>
-              setTesseramento({ ...tesseramentoCorrente, numeroTessera: e.target.value || null })
-            }
-            className={classiInput}
-          />
-        </Campo>
-        <Campo label="Data tessera">
-          <input
-            type="date"
-            value={tesseramentoCorrente.dataTessera ?? ""}
-            onChange={(e) =>
-              setTesseramento({ ...tesseramentoCorrente, dataTessera: e.target.value || null })
-            }
-            className={classiInput}
-          />
-        </Campo>
-      </div>
-      <button
-        type="button"
-        onClick={confermaTesseramento}
-        disabled={!tesseramento || salvaTesseramento.isPending}
-        className="premi w-full rounded-2xl bg-primary py-2.5 text-xs font-bold uppercase text-primary-foreground disabled:opacity-50"
-      >
-        Salva tesseramento
-      </button>
+      {allenatore ? null : (
+        <>
+          <h3 className="font-display text-sm uppercase tracking-wide">Tesseramento CSI</h3>
+          <div className="grid grid-cols-2 gap-3">
+            <Campo label="Numero tessera">
+              <input
+                value={tesseramentoCorrente.numeroTessera ?? ""}
+                maxLength={40}
+                placeholder="Non ancora tesserato"
+                onChange={(e) =>
+                  setTesseramento({
+                    ...tesseramentoCorrente,
+                    numeroTessera: e.target.value || null,
+                  })
+                }
+                className={classiInput}
+              />
+            </Campo>
+            <Campo label="Data tessera">
+              <input
+                type="date"
+                value={tesseramentoCorrente.dataTessera ?? ""}
+                onChange={(e) =>
+                  setTesseramento({ ...tesseramentoCorrente, dataTessera: e.target.value || null })
+                }
+                className={classiInput}
+              />
+            </Campo>
+          </div>
+          <button
+            type="button"
+            onClick={confermaTesseramento}
+            disabled={!tesseramento || salvaTesseramento.isPending}
+            className="premi w-full rounded-2xl bg-primary py-2.5 text-xs font-bold uppercase text-primary-foreground disabled:opacity-50"
+          >
+            Salva tesseramento
+          </button>
+        </>
+      )}
 
-      <CampiProfilo
-        corrente={profiloCorrente}
-        aggiorna={(patch) => setBozza({ ...profiloCorrente, ...patch })}
-        sezioni={sezioniComplete(profiloCorrente)}
-      />
+      {allenatore ? (
+        <>
+          <h3 className="font-display text-sm uppercase tracking-wide">Dati personali</h3>
+          <CampiAllenatore
+            corrente={profiloCorrente}
+            aggiorna={(patch) => setBozza({ ...profiloCorrente, ...patch })}
+          />
+        </>
+      ) : (
+        <CampiProfilo
+          corrente={profiloCorrente}
+          aggiorna={(patch) => setBozza({ ...profiloCorrente, ...patch })}
+          sezioni={sezioniComplete(profiloCorrente)}
+        />
+      )}
       <button
         type="button"
         onClick={confermaProfilo}
@@ -384,16 +421,20 @@ function SchedaGiocatore({
   profilo,
   oggi,
   indice,
+  aperta,
+  onToggle,
 }: {
   g: GiocatoreSquadra;
   profilo: Profilo | undefined;
   oggi: string;
   indice: number;
+  aperta: boolean;
+  onToggle: () => void;
 }) {
-  const [aperta, setAperta] = useState(false);
   const nome = nomeCompleto(g);
-  const { ruolo, numero } = g;
-  const perc = completamento(profilo);
+  const { numero } = g;
+  const allenatore = isAllenatore(g);
+  const perc = allenatore ? completamentoAllenatore(profilo) : completamento(profilo);
   const sezioni = sezioniComplete(profilo);
   const certificato = statoScadenza(profilo?.certificatoScadenza, profilo?.certificatoPath, oggi);
   const fronte = statoScadenza(profilo?.documentoScadenza, profilo?.documentoFrontePath, oggi);
@@ -401,18 +442,14 @@ function SchedaGiocatore({
 
   return (
     <Reveal indice={indice} className="rounded-2xl bg-card p-4 shadow-card">
-      <button
-        type="button"
-        onClick={() => setAperta((v) => !v)}
-        className="flex w-full items-center gap-3 text-left"
-      >
+      <button type="button" onClick={onToggle} className="flex w-full items-center gap-3 text-left">
         <div className="grid h-10 w-10 shrink-0 place-items-center rounded-xl bg-secondary font-display text-sm tabular-nums">
-          {numero}
+          {allenatore ? "All" : numero}
         </div>
         <div className="min-w-0 flex-1">
           <p className="truncate font-semibold leading-tight">{nome}</p>
           <p className="text-xs text-muted-foreground">
-            {ruolo} · profilo {perc}%
+            {ruoloVisibile(g)} · profilo {perc}%
           </p>
         </div>
         <ChevronDown
@@ -430,55 +467,65 @@ function SchedaGiocatore({
         />
       </div>
 
-      <div className="mt-3 flex flex-wrap gap-2">
-        <Documento
-          icona={<IdCard className="h-3.5 w-3.5" />}
-          label="Doc fronte"
-          stato={fronte}
-          path={profilo?.documentoFrontePath ?? null}
-        />
-        <Documento
-          icona={<IdCard className="h-3.5 w-3.5" />}
-          label="Doc retro"
-          stato={retro}
-          path={profilo?.documentoRetroPath ?? null}
-        />
-        <Documento
-          icona={<FileText className="h-3.5 w-3.5" />}
-          label="Certificato"
-          stato={certificato}
-          path={profilo?.certificatoPath ?? null}
-        />
-        <Documento
-          icona={<Image className="h-3.5 w-3.5" />}
-          label="Foto"
-          stato={sezioni.foto ? "presente" : "assente"}
-          path={profilo?.fotoPath ?? null}
-        />
-        <span
-          className={cn(
-            "flex items-center gap-1.5 rounded-full px-2.5 py-1 text-xs font-bold uppercase",
-            statoClasse[g.numeroTessera ? "presente" : "assente"],
-          )}
-        >
-          <BadgeCheck className="h-3.5 w-3.5" />
-          {g.numeroTessera ? "Tesserato" : "Da tesserare"}
-        </span>
-      </div>
+      {allenatore ? null : (
+        <div className="mt-3 flex flex-wrap gap-2">
+          <Documento
+            icona={<IdCard className="h-3.5 w-3.5" />}
+            label="Doc fronte"
+            stato={fronte}
+            path={profilo?.documentoFrontePath ?? null}
+          />
+          <Documento
+            icona={<IdCard className="h-3.5 w-3.5" />}
+            label="Doc retro"
+            stato={retro}
+            path={profilo?.documentoRetroPath ?? null}
+          />
+          <Documento
+            icona={<FileText className="h-3.5 w-3.5" />}
+            label="Certificato"
+            stato={certificato}
+            path={profilo?.certificatoPath ?? null}
+          />
+          <Documento
+            icona={<Image className="h-3.5 w-3.5" />}
+            label="Foto"
+            stato={sezioni.foto ? "presente" : "assente"}
+            path={profilo?.fotoPath ?? null}
+          />
+          <span
+            className={cn(
+              "flex items-center gap-1.5 rounded-full px-2.5 py-1 text-xs font-bold uppercase",
+              statoClasse[g.numeroTessera ? "presente" : "assente"],
+            )}
+          >
+            <BadgeCheck className="h-3.5 w-3.5" />
+            {g.numeroTessera ? "Tesserato" : "Da tesserare"}
+          </span>
+        </div>
+      )}
 
       {aperta ? <ModificaGiocatore g={g} profilo={profilo} /> : null}
     </Reveal>
   );
 }
 
-const datiVuoti: DatiSquadra = { nome: "", cognome: "", numero: 1, ruolo: "", email: null };
+const datiVuoti: DatiSquadra = {
+  nome: "",
+  cognome: "",
+  numero: 1,
+  ruolo: "",
+  email: null,
+  tipo: "giocatore",
+};
 
-/** Form per aggiungere un giocatore alla rosa (DD-017): l'id `g<N>` è calcolato in app,
- * il database non lo genera da solo. */
+/** Form per aggiungere un giocatore alla rosa (DD-017), o un allenatore (DD-034): l'id
+ * `g<N>` è calcolato in app, il database non lo genera da solo. */
 function AggiungiGiocatore({ righe }: { righe: GiocatoreSquadra[] }) {
   const [aperto, setAperto] = useState(false);
   const [dati, setDati] = useState<DatiSquadra>(datiVuoti);
   const aggiungi = useAggiungiGiocatore();
+  const allenatore = dati.tipo === "allenatore";
 
   async function conferma() {
     const errore = validaDatiSquadra(dati);
@@ -486,13 +533,17 @@ function AggiungiGiocatore({ righe }: { righe: GiocatoreSquadra[] }) {
       toast.error(errore);
       return;
     }
-    if (numeroGiaUsato(righe, "", dati.numero)) {
+    if (!allenatore && numeroGiaUsato(righe, "", dati.numero)) {
       toast.error(`Il numero ${dati.numero} è già assegnato a un altro giocatore.`);
       return;
     }
     try {
       await aggiungi.mutateAsync({ id: prossimoIdGiocatore(righe), dati });
-      toast.success(`${dati.nome} ${dati.cognome} aggiunto alla rosa`);
+      toast.success(
+        allenatore
+          ? `${dati.nome} ${dati.cognome} aggiunto come allenatore`
+          : `${dati.nome} ${dati.cognome} aggiunto alla rosa`,
+      );
       setDati(datiVuoti);
       setAperto(false);
     } catch (e) {
@@ -507,14 +558,27 @@ function AggiungiGiocatore({ righe }: { righe: GiocatoreSquadra[] }) {
         onClick={() => setAperto(true)}
         className="premi mt-3 flex w-full items-center justify-center gap-2 rounded-2xl bg-secondary py-3 text-sm font-bold uppercase"
       >
-        <UserPlus className="h-4 w-4" /> Aggiungi giocatore
+        <UserPlus className="h-4 w-4" /> Aggiungi giocatore o allenatore
       </button>
     );
   }
 
   return (
     <div className="mt-3 space-y-3 rounded-2xl bg-card p-4 shadow-card">
-      <h3 className="font-display text-sm uppercase tracking-wide">Nuovo giocatore</h3>
+      <h3 className="font-display text-sm uppercase tracking-wide">
+        {allenatore ? "Nuovo allenatore" : "Nuovo giocatore"}
+      </h3>
+      <Campo label="Tipo">
+        <Select
+          value={dati.tipo}
+          onChange={(e) =>
+            setDati({ ...dati, tipo: e.target.value === "allenatore" ? "allenatore" : "giocatore" })
+          }
+        >
+          <option value="giocatore">Giocatore</option>
+          <option value="allenatore">Allenatore</option>
+        </Select>
+      </Campo>
       <div className="grid grid-cols-2 gap-3">
         <Campo label="Nome">
           <input
@@ -532,27 +596,34 @@ function AggiungiGiocatore({ righe }: { righe: GiocatoreSquadra[] }) {
             className={classiInput}
           />
         </Campo>
-        <Campo label="Numero">
-          <input
-            type="number"
-            min={1}
-            value={dati.numero}
-            onChange={(e) => setDati({ ...dati, numero: Number(e.target.value) })}
-            className={classiInput}
-          />
-        </Campo>
-        <Campo label="Ruolo">
-          <Select value={dati.ruolo} onChange={(e) => setDati({ ...dati, ruolo: e.target.value })}>
-            <option value="">—</option>
-            {RUOLI.map((r) => (
-              <option key={r} value={r}>
-                {r}
-              </option>
-            ))}
-          </Select>
-        </Campo>
+        {allenatore ? null : (
+          <>
+            <Campo label="Numero">
+              <input
+                type="number"
+                min={1}
+                value={dati.numero}
+                onChange={(e) => setDati({ ...dati, numero: Number(e.target.value) })}
+                className={classiInput}
+              />
+            </Campo>
+            <Campo label="Ruolo">
+              <Select
+                value={dati.ruolo}
+                onChange={(e) => setDati({ ...dati, ruolo: e.target.value })}
+              >
+                <option value="">—</option>
+                {RUOLI.map((r) => (
+                  <option key={r} value={r}>
+                    {r}
+                  </option>
+                ))}
+              </Select>
+            </Campo>
+          </>
+        )}
       </div>
-      <Campo label="Email (collegamento automatico al login, opzionale)">
+      <Campo label="Email">
         <input
           type="email"
           value={dati.email ?? ""}
@@ -604,7 +675,7 @@ function GiocatoreDisattivato({ g }: { g: GiocatoreSquadra }) {
       <div className="min-w-0">
         <p className="truncate font-semibold leading-tight">{nomeCompleto(g)}</p>
         <p className="text-xs text-muted-foreground">
-          #{g.numero} · {g.ruolo}
+          {isAllenatore(g) ? ruoloVisibile(g) : `#${g.numero} · ${g.ruolo}`}
         </p>
       </div>
       <button
@@ -623,7 +694,35 @@ function Dashboard() {
   const admin = useIsAdmin();
   const { righe: squadra } = useGiocatoriSquadra();
   const { profili, isPending } = useProfili();
+  const { data: notificheAttive } = useNotificheAttive();
+  const [schedaAperta, setSchedaAperta] = useState<string | null>(null);
   const oggi = oggiISO();
+  const inviaNotifica = useInviaNotifica();
+  const [destinatarioMessaggio, setDestinatarioMessaggio] = useState<{
+    id?: string;
+    nome: string;
+  } | null>(null);
+  const [messaggio, setMessaggio] = useState("");
+
+  async function inviaMessaggio() {
+    if (!destinatarioMessaggio || !messaggio.trim()) return;
+    try {
+      const dati = await inviaNotifica.mutateAsync(
+        destinatarioMessaggio.id
+          ? { messaggio: messaggio.trim(), giocatoreId: destinatarioMessaggio.id }
+          : { messaggio: messaggio.trim() },
+      );
+      toast.success(
+        dati.inviate > 0
+          ? `Notifica inviata a ${dati.inviate} dispositivi`
+          : "Nessun dispositivo con notifiche attive per l'invio",
+      );
+      setDestinatarioMessaggio(null);
+      setMessaggio("");
+    } catch {
+      toast.error("Non sono riuscito a inviare la notifica");
+    }
+  }
 
   if (!admin) {
     return (
@@ -639,7 +738,11 @@ function Dashboard() {
     );
   }
 
-  const attivi = squadra.filter((g) => g.attivo);
+  // Conteggi, tesseramento ed export CSI riguardano solo chi gioca (DD-034).
+  const attivi = squadra.filter(inRosa);
+  const allenatori = squadra.filter((g) => g.attivo && isAllenatore(g));
+  // Le notifiche arrivano anche agli allenatori: nella tab Notifiche ci sono tutti.
+  const membri = [...attivi, ...allenatori];
   const disattivi = squadra.filter((g) => !g.attivo);
   const completi = attivi.filter((g) => completamento(profili[g.id]) === 100).length;
   const certificatiOk = attivi.filter(
@@ -649,56 +752,190 @@ function Dashboard() {
   ).length;
   const tesserati = attivi.filter((g) => g.numeroTessera).length;
 
+  const contenutoSquadra = (
+    <>
+      <div className="grid grid-cols-2 gap-2">
+        <StatTile valore={attivi.length} label="Giocatori" />
+        <StatTile valore={`${completi}/${attivi.length}`} label="Profili completi" />
+        <StatTile
+          valore={`${certificatiOk}/${attivi.length}`}
+          label="Certificati validi"
+          hint="non scaduti"
+        />
+        <StatTile valore={`${tesserati}/${attivi.length}`} label="Tesserati" hint="CSI" />
+      </div>
+      <button
+        type="button"
+        onClick={() => scaricaCsv(`tesseramento-csi-${oggi}.csv`, csvTesseramento(attivi, profili))}
+        className="premi mt-3 flex w-full items-center justify-center gap-2 rounded-2xl bg-accent-grad py-3 text-sm font-bold uppercase text-accent-foreground shadow-pop"
+      >
+        <Download className="h-4 w-4" /> Esporta CSV tesseramento
+      </button>
+      <AggiungiGiocatore righe={squadra} />
+    </>
+  );
+
+  const contenutoProfili = isPending ? (
+    <p className="rounded-2xl bg-card p-5 text-center text-sm text-muted-foreground shadow-card">
+      Caricamento…
+    </p>
+  ) : (
+    <div className="space-y-3">
+      {attivi.map((g, i) => (
+        <SchedaGiocatore
+          key={g.id}
+          g={g}
+          profilo={profili[g.id]}
+          oggi={oggi}
+          indice={i}
+          aperta={schedaAperta === g.id}
+          onToggle={() => setSchedaAperta((v) => (v === g.id ? null : g.id))}
+        />
+      ))}
+      {allenatori.length > 0 ? (
+        <h3 className="pt-2 font-display text-sm uppercase tracking-wide">Allenatori</h3>
+      ) : null}
+      {allenatori.map((g, i) => (
+        <SchedaGiocatore
+          key={g.id}
+          g={g}
+          profilo={profili[g.id]}
+          oggi={oggi}
+          indice={attivi.length + i}
+          aperta={schedaAperta === g.id}
+          onToggle={() => setSchedaAperta((v) => (v === g.id ? null : g.id))}
+        />
+      ))}
+    </div>
+  );
+
+  const contenutoDisattivati = (
+    <div className="space-y-2">
+      {disattivi.map((g) => (
+        <GiocatoreDisattivato key={g.id} g={g} />
+      ))}
+    </div>
+  );
+
+  const contenutoNotifiche = notificheAttive ? (
+    <>
+      <StatTile
+        valore={`${membri.filter((g) => notificheAttive.has(g.id)).length}/${membri.length}`}
+        label="Notifiche attive"
+      />
+      <button
+        type="button"
+        onClick={() => setDestinatarioMessaggio({ nome: "tutta la squadra" })}
+        className="premi mt-3 flex w-full items-center justify-center gap-2 rounded-2xl bg-accent-grad py-3 text-sm font-bold uppercase text-accent-foreground shadow-pop"
+      >
+        <Send className="h-4 w-4" /> Invia messaggio a tutti
+      </button>
+      <div className="mt-3 space-y-2">
+        {membri.map((g) => {
+          const attiva = notificheAttive.has(g.id);
+          return (
+            <div key={g.id} className="flex items-center gap-2 rounded-2xl bg-card p-3 shadow-card">
+              {attiva ? (
+                <Bell className="h-3.5 w-3.5 shrink-0 text-accent" />
+              ) : (
+                <BellOff className="h-3.5 w-3.5 shrink-0 text-muted-foreground" />
+              )}
+              <p
+                className={cn(
+                  "min-w-0 flex-1 truncate text-sm font-semibold leading-tight",
+                  !attiva && "text-muted-foreground",
+                )}
+              >
+                {nomeCompleto(g)}
+              </p>
+              <button
+                type="button"
+                onClick={() => setDestinatarioMessaggio({ id: g.id, nome: nomeCompleto(g) })}
+                className="grid h-9 w-9 shrink-0 place-items-center rounded-xl bg-secondary text-foreground active:scale-95"
+                aria-label={`Invia messaggio a ${nomeCompleto(g)}`}
+              >
+                <Send className="h-3.5 w-3.5" />
+              </button>
+            </div>
+          );
+        })}
+      </div>
+    </>
+  ) : (
+    <p className="rounded-2xl bg-card p-5 text-center text-sm text-muted-foreground shadow-card">
+      Caricamento…
+    </p>
+  );
+
   return (
     <>
       <PageHeader titolo="Dashboard" sottotitolo="Profili e tesseramento" />
 
-      <Section titolo="Squadra">
-        <div className="grid grid-cols-2 gap-2">
-          <StatTile valore={attivi.length} label="Giocatori" />
-          <StatTile valore={`${completi}/${attivi.length}`} label="Profili completi" />
-          <StatTile
-            valore={`${certificatiOk}/${attivi.length}`}
-            label="Certificati validi"
-            hint="non scaduti"
-          />
-          <StatTile valore={`${tesserati}/${attivi.length}`} label="Tesserati" hint="CSI" />
-        </div>
-        <button
-          type="button"
-          onClick={() =>
-            scaricaCsv(`tesseramento-csi-${oggi}.csv`, csvTesseramento(attivi, profili))
+      <BarraSottosezioni
+        defaultId="squadra"
+        variante="sottolineatura"
+        riempiLarghezza
+        voci={[
+          { id: "squadra", label: "Squadra", contenuto: contenutoSquadra },
+          { id: "profili", label: "Profili", contenuto: contenutoProfili },
+          ...(disattivi.length > 0
+            ? [{ id: "disattivati", label: "Disattivati", contenuto: contenutoDisattivati }]
+            : []),
+          { id: "notifiche", label: "Notifiche", contenuto: contenutoNotifiche },
+        ]}
+      />
+
+      <Drawer
+        open={!!destinatarioMessaggio}
+        onOpenChange={(aperto) => {
+          if (!aperto) {
+            setDestinatarioMessaggio(null);
+            setMessaggio("");
           }
-          className="premi mt-3 flex w-full items-center justify-center gap-2 rounded-2xl bg-accent-grad py-3 text-sm font-bold uppercase text-accent-foreground shadow-pop"
-        >
-          <Download className="h-4 w-4" /> Esporta CSV tesseramento
-        </button>
-        <AggiungiGiocatore righe={squadra} />
-      </Section>
-
-      <Section titolo="Profili" indice={1}>
-        {isPending ? (
-          <p className="rounded-2xl bg-card p-5 text-center text-sm text-muted-foreground shadow-card">
-            Caricamento…
-          </p>
-        ) : (
-          <div className="space-y-3">
-            {attivi.map((g, i) => (
-              <SchedaGiocatore key={g.id} g={g} profilo={profili[g.id]} oggi={oggi} indice={i} />
-            ))}
+        }}
+      >
+        <DrawerContent>
+          <DrawerHeader>
+            <DrawerTitle>Invia messaggio</DrawerTitle>
+            <DrawerDescription>
+              {destinatarioMessaggio ? `Destinatario: ${destinatarioMessaggio.nome}.` : ""}
+            </DrawerDescription>
+          </DrawerHeader>
+          <div className="px-4">
+            <textarea
+              value={messaggio}
+              maxLength={300}
+              rows={3}
+              onChange={(e) => setMessaggio(e.target.value)}
+              placeholder="Scrivi il messaggio da inviare come notifica push…"
+              className={cn(classiInput, "h-auto")}
+            />
           </div>
-        )}
-      </Section>
-
-      {disattivi.length > 0 ? (
-        <Section titolo="Giocatori disattivati" indice={2}>
-          <div className="space-y-2">
-            {disattivi.map((g) => (
-              <GiocatoreDisattivato key={g.id} g={g} />
-            ))}
-          </div>
-        </Section>
-      ) : null}
+          <DrawerFooter>
+            <button
+              type="button"
+              onClick={inviaMessaggio}
+              disabled={inviaNotifica.isPending || !messaggio.trim()}
+              className="flex w-full items-center justify-center gap-2 rounded-2xl bg-accent-grad py-3 text-sm font-bold uppercase text-accent-foreground shadow-pop disabled:opacity-50"
+            >
+              {inviaNotifica.isPending ? (
+                <Loader2 className="h-4 w-4 animate-spin" />
+              ) : (
+                <Send className="h-4 w-4" />
+              )}{" "}
+              Invia
+            </button>
+            <DrawerClose asChild>
+              <button
+                type="button"
+                className="w-full rounded-2xl bg-secondary py-3 text-sm font-bold uppercase text-foreground"
+              >
+                Annulla
+              </button>
+            </DrawerClose>
+          </DrawerFooter>
+        </DrawerContent>
+      </Drawer>
     </>
   );
 }

src/routes/allenamento.$id.tsx

@@ -91,7 +91,7 @@ function AllenamentoDetail() {
       </Section>
 
       <Section titolo="Rosa e presenze">
-        <RosaPresenze eventoId={evento.id} data={evento.data} />
+        <RosaPresenze eventoId={evento.id} data={evento.data} tipo={evento.tipo} />
       </Section>
     </>
   );

src/routes/api/public/apri-sondaggio.ts

@@ -3,6 +3,8 @@ import { z } from "zod";
 import { richiediAdmin } from "@/lib/auth-route.server";
 import { leggiEventi } from "@/lib/eventi.server";
 import { inviaPush } from "@/lib/webpush.server";
+import { isAllenatore } from "@/lib/giocatori-squadra";
+import { leggiGiocatoriSquadra } from "@/lib/giocatori-squadra.server";
 
 const schema = z.object({ eventoId: z.string().min(1).max(50) });
 
@@ -22,15 +24,20 @@ export const Route = createFileRoute("/api/public/apri-sondaggio")({
         if (!partita) return new Response("Evento non trovato", { status: 404 });
 
         const { supabaseAdmin } = await import("@/integrations/supabase/client.server");
-        const { data: iscrizioni } = await supabaseAdmin
+        const { data: tutte } = await supabaseAdmin
           .from("push_subscriptions")
-          .select("endpoint, p256dh, auth");
+          .select("endpoint, p256dh, auth, giocatore_id");
+        // Il sondaggio cacche non riguarda l'allenatore, che non le vede (DD-034).
+        const allenatori = new Set(
+          (await leggiGiocatoriSquadra()).filter(isAllenatore).map((g) => g.id),
+        );
+        const iscrizioni = (tutte ?? []).filter((i) => !allenatori.has(i.giocatore_id));
 
         const titolo = "💩 Sondaggio pre-partita aperto";
         const testo = `${partita.titolo} · ore ${partita.ora}. Quante cacche hai fatto? Rispondi prima del fischio d'inizio.`;
 
         let inviate = 0;
-        for (const iscrizione of iscrizioni ?? []) {
+        for (const iscrizione of iscrizioni) {
           try {
             const { stato } = await inviaPush(iscrizione, titolo, testo);
             if (stato === 404 || stato === 410) {
@@ -46,7 +53,7 @@ export const Route = createFileRoute("/api/public/apri-sondaggio")({
           }
         }
 
-        return Response.json({ inviate, destinatari: (iscrizioni ?? []).length });
+        return Response.json({ inviate, destinatari: iscrizioni.length });
       },
     },
   },

src/routes/api/public/csi-partita.$id.ts

@@ -0,0 +1,63 @@
+import { createFileRoute } from "@tanstack/react-router";
+import {
+  parseFormazioni,
+  parseInfoPartita,
+  parsePrecedenti,
+  urlPartitaFormazioni,
+  urlPartitaInfo,
+  urlPartitaPrecedenti,
+  type DettaglioPartitaCsi,
+} from "@/lib/csi-core";
+
+const SCADENZA_MS = 6 * 60 * 60 * 1000;
+
+// Una gara giocata non cambia più: la cache per-partita non ha bisogno di scadere mai
+// per i dati storici, ma teniamo la stessa finestra di /api/public/csi per semplicità e
+// per non tenere in memoria per sempre partite che nessuno riguarda più. Stessa cache in
+// memoria del processo, stesso limite (si perde ai cold start): vedi limite 3 in
+// docs/modules/collegamento-csi.md.
+const cache = new Map<string, { dati: DettaglioPartitaCsi; scadenza: number }>();
+
+async function scarica(url: string): Promise<string> {
+  const res = await fetch(url, {
+    headers: { "User-Agent": "CrAPP/1.0 (+https://crapvolley.it)" },
+    signal: AbortSignal.timeout(15_000),
+  });
+  if (!res.ok) throw new Error(`CSI ${res.status} su ${url}`);
+  return res.text();
+}
+
+async function leggiDettaglioPartita(matchId: string): Promise<DettaglioPartitaCsi> {
+  const [main, players, stats] = await Promise.all([
+    scarica(urlPartitaInfo(matchId)),
+    scarica(urlPartitaFormazioni(matchId)),
+    scarica(urlPartitaPrecedenti(matchId)),
+  ]);
+  return {
+    ...parseInfoPartita(main),
+    formazioni: parseFormazioni(players),
+    precedenti: parsePrecedenti(stats),
+  };
+}
+
+export const Route = createFileRoute("/api/public/csi-partita/$id")({
+  server: {
+    handlers: {
+      GET: async ({ params }) => {
+        const matchId = params.id;
+        const voce = cache.get(matchId);
+        if (voce && Date.now() < voce.scadenza) return Response.json(voce.dati);
+        try {
+          const dati = await leggiDettaglioPartita(matchId);
+          cache.set(matchId, { dati, scadenza: Date.now() + SCADENZA_MS });
+          return Response.json(dati);
+        } catch (error) {
+          console.error("csi-partita", matchId, error);
+          // Meglio un dato vecchio che nessun dato, come /api/public/csi.
+          if (voce) return Response.json(voce.dati);
+          return new Response("CSI non raggiungibile", { status: 503 });
+        }
+      },
+    },
+  },
+});

src/routes/api/public/csi.ts

@@ -1,8 +1,10 @@
 import { createFileRoute } from "@tanstack/react-router";
 import {
+  CSI_COPPA_PROJECT_ID,
   CSI_GIRONE,
   parseClassifica,
   partiteDaEventi,
+  partiteFormatoSospetto,
   urlClassifica,
   urlPartite,
   type DatiCsi,
@@ -27,13 +29,39 @@ async function scarica(url: string): Promise<string> {
 }
 
 async function leggiCsi(): Promise<DatiCsi> {
-  const [html, json] = await Promise.all([scarica(urlClassifica()), scarica(urlPartite())]);
+  const [html, htmlCoppa, json] = await Promise.all([
+    scarica(urlClassifica()),
+    // Non blocca la risposta se fallisce: la Coppa è un dato supplementare, non critico
+    // come classifica/partite del girone (vedi il controllo sotto).
+    scarica(urlClassifica(CSI_COPPA_PROJECT_ID)).catch(() => ""),
+    scarica(urlPartite()),
+  ]);
   const classifica = parseClassifica(html);
-  const partite = partiteDaEventi(JSON.parse(json));
+  const classificaCoppa = parseClassifica(htmlCoppa);
+  const eventiGrezzi = JSON.parse(json);
+  const partite = partiteDaEventi(eventiGrezzi);
   if (classifica.length === 0 && partite.length === 0) {
     throw new Error("CSI: risposta senza classifica né partite");
   }
-  return { classifica, partite, girone: CSI_GIRONE, aggiornato: new Date().toISOString() };
+  // La classifica basta a evitare l'errore sopra, ma se solo le partite si rompono (formato di
+  // getEventsByTeamId.php cambiato) la route tornerebbe comunque 200 senza che nessuno se ne
+  // accorga: le vittorie degli obiettivi di squadra resterebbero ferme a 0% in silenzio. Oltre
+  // al log server, il flag arriva fino a `/classifica` (badge discreto) perché qualcuno se ne
+  // accorga anche senza guardare i log.
+  const formatoSospetto = partiteFormatoSospetto(eventiGrezzi, partite);
+  if (formatoSospetto) {
+    console.error(
+      "csi: il formato di getEventsByTeamId.php sembra cambiato, nessuna partita riconosciuta",
+    );
+  }
+  return {
+    classifica,
+    classificaCoppa,
+    partite,
+    girone: CSI_GIRONE,
+    aggiornato: new Date().toISOString(),
+    formatoSospetto,
+  };
 }
 
 export const Route = createFileRoute("/api/public/csi")({

src/routes/api/public/keepalive.ts

@@ -0,0 +1,25 @@
+import { createFileRoute } from "@tanstack/react-router";
+
+/**
+ * Chiamata dal Vercel Cron Job (vedi vercel.json) per tenere attivo il progetto Supabase
+ * free tier, che va in pausa dopo 7 giorni senza richieste API. Una lettura minima basta:
+ * nessun dato sensibile, nessun effetto collaterale, quindi nessuna autenticazione richiesta.
+ */
+export const Route = createFileRoute("/api/public/keepalive")({
+  server: {
+    handlers: {
+      GET: async () => {
+        const { supabaseAdmin } = await import("@/integrations/supabase/client.server");
+        const { error } = await supabaseAdmin
+          .from("giocatori_squadra")
+          .select("id", { count: "exact", head: true })
+          .limit(1);
+        if (error) {
+          console.error("keepalive", error);
+          return new Response("Errore", { status: 500 });
+        }
+        return new Response("ok");
+      },
+    },
+  },
+});

src/routes/api/public/notifica-personalizzata.ts

@@ -0,0 +1,80 @@
+import { createFileRoute } from "@tanstack/react-router";
+import type { SupabaseClient } from "@supabase/supabase-js";
+import { z } from "zod";
+import { richiediAdmin } from "@/lib/auth-route.server";
+import { inviaPush } from "@/lib/webpush.server";
+
+const schema = z.object({
+  messaggio: z.string().min(1).max(300),
+  giocatoreId: z.string().min(1).max(50).optional(),
+});
+
+export const Route = createFileRoute("/api/public/notifica-personalizzata")({
+  server: {
+    handlers: {
+      POST: async ({ request }) => {
+        const negato = await richiediAdmin(request);
+        if (negato) return negato;
+
+        const parsed = schema.safeParse(await request.json());
+        if (!parsed.success) return new Response("Dati non validi", { status: 400 });
+
+        const { supabaseAdmin } = await import("@/integrations/supabase/client.server");
+        // `types.ts` non include ancora `notifiche_utente` (M17): stesso aggiramento di
+        // `giocatori-squadra.server.ts` finché non viene rigenerato.
+        const client = supabaseAdmin as unknown as SupabaseClient;
+
+        let query = supabaseAdmin.from("push_subscriptions").select("endpoint, p256dh, auth");
+        if (parsed.data.giocatoreId) {
+          query = query.eq("giocatore_id", parsed.data.giocatoreId);
+        }
+        const { data: iscrizioni } = await query;
+
+        const titolo = "Messaggio dallo staff";
+        const testo = parsed.data.messaggio.trim();
+
+        let inviate = 0;
+        for (const iscrizione of iscrizioni ?? []) {
+          try {
+            const { stato } = await inviaPush(iscrizione, titolo, testo);
+            if (stato === 404 || stato === 410) {
+              await supabaseAdmin
+                .from("push_subscriptions")
+                .delete()
+                .eq("endpoint", iscrizione.endpoint);
+            } else if (stato >= 200 && stato < 300) {
+              inviate += 1;
+            }
+          } catch (error) {
+            console.error("notifica-personalizzata", error);
+          }
+        }
+
+        // Storico in-app (M17): indipendente dall'esito della push, e non limitato a chi ha
+        // un dispositivo iscritto. Senza `giocatoreId` va a tutta la rosa attiva.
+        let destinatariNotifica: string[];
+        if (parsed.data.giocatoreId) {
+          destinatariNotifica = [parsed.data.giocatoreId];
+        } else {
+          const { data: rosa } = await client
+            .from("giocatori_squadra")
+            .select("id")
+            .eq("attivo", true);
+          destinatariNotifica = ((rosa ?? []) as Array<{ id: string }>).map((r) => r.id);
+        }
+        if (destinatariNotifica.length > 0) {
+          await client.from("notifiche_utente").insert(
+            destinatariNotifica.map((giocatoreId) => ({
+              giocatore_id: giocatoreId,
+              tipo: "admin",
+              titolo,
+              corpo: testo,
+            })),
+          );
+        }
+
+        return Response.json({ inviate, destinatari: iscrizioni?.length ?? 0 });
+      },
+    },
+  },
+});

src/routes/api/public/notifiche-attive.ts

@@ -0,0 +1,25 @@
+import { createFileRoute } from "@tanstack/react-router";
+import { richiediAdmin } from "@/lib/auth-route.server";
+import { idsConNotificheAttive } from "@/lib/notifiche-attive.server";
+
+export const Route = createFileRoute("/api/public/notifiche-attive")({
+  server: {
+    handlers: {
+      GET: async ({ request }) => {
+        const negato = await richiediAdmin(request);
+        if (negato) return negato;
+
+        const { supabaseAdmin } = await import("@/integrations/supabase/client.server");
+        const { data, error } = await supabaseAdmin
+          .from("push_subscriptions")
+          .select("giocatore_id");
+        if (error) {
+          console.error("notifiche-attive", error);
+          return new Response("Errore lettura", { status: 500 });
+        }
+
+        return Response.json({ giocatoreIds: idsConNotificheAttive(data ?? []) });
+      },
+    },
+  },
+});