Formatta la documentazione con prettier

Solo whitespace: tabelle allineate, enfasi normalizzata (* -> _), a capo
coerenti. Nessuna modifica di contenuto.

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

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

@@ -7,22 +7,29 @@ Al momento c'è un solo "obiettivo di squadra" ed è hardcoded nella home (`src/
 ## 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.
+- 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.
+- Nuova sezione con la lista completa degli obiettivi: barra di progresso, percentuale, stato (in corso / completato).
-  - Nessuna nuova rotta e nessuna modifica al bottom nav.
+- 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).
+- 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.
+- 90% di presenze ad agosto (collegato agli eventi di agosto).
-  - Prima vittoria del campionato (collegato allo storico match).
+- 70% di risposte entro 24h nel prossimo mese.
-  - 5 vittorie in campionato (collegato allo storico match).
+- Prima vittoria del campionato (collegato allo storico match).
-  - 10 vittorie in campionato (collegato allo storico match).
+- 5 vittorie in campionato (collegato allo storico match).
-  - 1 evento di squadra al mese (pizzata, ecc.).
+- 10 vittorie in campionato (collegato allo storico match).
+- 1 evento di squadra al mese (pizzata, ecc.).
 
 ## Cosa non cambia
 

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

@@ -1,6 +1,7 @@
 # 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
@@ -19,5 +20,6 @@ Rendere i badge accanto al nome del giocatore nella lista squadra più compatti
    - 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,11 +1,14 @@
 # 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/turno-palloni-nel-calendario-promemoria-2026-07-31.md

@@ -16,6 +16,7 @@ Aggiungere a ogni allenamento/partita un incaricato dei palloni, condiviso tra t
 ## 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.
@@ -23,11 +24,13 @@ Aggiungere a ogni allenamento/partita un incaricato dei palloni, condiviso tra t
 - 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).

AGENTS.md

@@ -447,4 +447,3 @@ Migliora l'esperienza dei giocatori?
 Riduce oppure aumenta la complessità futura?
 
 Se almeno una risposta è negativa, rivalutare la soluzione proposta.
-

PROJECT_STATE.md

@@ -73,12 +73,12 @@ va fatto prima di mandare questa versione in produzione.
 
 Passaggi in ordine, nessuno dei quali è reversibile a metà:
 
-1. **Provider Google in Supabase** — Google Cloud Console: consent screen *External* (scope
+1. **Provider Google in Supabase** — Google Cloud Console: consent screen _External_ (scope
-   `email` e `profile`, non sensibili: nessuna verifica richiesta, e la modalità *Testing*
+   `email` e `profile`, non sensibili: nessuna verifica richiesta, e la modalità _Testing_
    regge fino a 100 utenti, più che sufficiente per la squadra), credenziale
-   *Web application* con redirect URI
+   _Web application_ con redirect URI
    `https://kfkcldwncxqaixetsjes.supabase.co/auth/v1/callback`. Client ID e
-   secret in *Authentication → Providers → Google*. In *URL Configuration*: Site URL di
+   secret in _Authentication → Providers → Google_. In _URL Configuration_: Site URL di
    produzione, più `localhost:8080` e il wildcard delle preview Vercel tra i Redirect URLs.
    Per provare sullo stack locale invece che sul cloud servono anche `enabled = true` in
    `[auth.external.google]` di `supabase/config.toml`, le due variabili

docs/ARCHITECTURE.md

@@ -6,7 +6,7 @@ riferimento tecnico — `CLAUDE.md` non ripete questi contenuti, li richiama.
 ## Stack
 
 | Livello       | Tecnologie                                                                            |
-|---|---|
+| ------------- | ------------------------------------------------------------------------------------- |
 | Frontend      | React 19, TypeScript, TanStack Start (SSR), Vite 8, Tailwind CSS 4, Radix UI / shadcn |
 | Backend       | Supabase (PostgreSQL, Auth, Storage)                                                  |
 | Hosting       | Vercel                                                                                |

docs/DATABASE.md

@@ -8,7 +8,7 @@ non in questo file.
 ## 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`, già popolata (17 giocatori) ma **non ancora letta dal codice**: la rosa arriva tuttora da `src/lib/crapp-data.ts`, che resta il fallback anche dopo il passaggio. Destinata a diventare la source of truth. Vedi DD-015 e DD-016. La colonna `email` (migration `m5_email_giocatori_squadra`) è la chiave del collegamento automatico account↔giocatore al primo accesso (DD-018): NULL finché non nota, oggi impostata solo per 2 dei 17 giocatori. |
 | `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.                                                                                                                                                                                                                                                                         |
@@ -19,13 +19,13 @@ non in questo file.
 ## Storage
 
 | Bucket              | Scopo                                                                                                                  | Note                                                                                                                                                                                                                                                                                              |
-|---|---|---|
+| ------------------- | ---------------------------------------------------------------------------------------------------------------------- | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- |
 | `profili-giocatore` | Documento d'identità, certificato medico e foto tessera, in cartelle per giocatore (`<giocatore_id>/<sezione>.<est>`). | **Privato** e destinato a restare tale: contiene documenti e dati sanitari, che non devono mai avere URL pubblici (DD-016 regola 4). Il giocatore gestisce solo la propria cartella, l'admin può scaricare tutto tramite signed URL a scadenza breve. Creato dalla migration `m3_bucket_profili`. |
 
 ## Eventi e presenze
 
 | Tabella             | Scopo                                                            | Note                                                                        |
-|---|---|---|
+| ------------------- | ---------------------------------------------------------------- | --------------------------------------------------------------------------- |
 | `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.                                          |
 | `eventi`            | Calendario generale: allenamenti, partite, eventi della squadra. | Modello "nuovo" con autenticazione e vincoli, non ancora adottato (DD-014). |
@@ -34,14 +34,14 @@ non in questo file.
 ## Scout
 
 | Tabella          | Scopo                                                           | Note                                                                                                                                                                                      |
-|---|---|---|
+| ---------------- | --------------------------------------------------------------- | ----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- |
 | `scout_sessioni` | Sessioni di Scout Live: una sessione corrisponde a una partita. | **Non ancora usata dal codice**: oggi lo stato della sessione vive in `localStorage` (`src/lib/scout-live.ts`, `scout-store.ts`) e sul database finiscono solo le azioni in `scout_live`. |
 | `scout_live`     | Eventi registrati durante lo Scout Live.                        | Serve esclusivamente per statistiche di squadra, mai per classifiche individuali (DD-008).                                                                                                |
 
 ## 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.             |                          |
@@ -49,7 +49,7 @@ non in questo file.
 ## Turni e notifiche
 
 | Tabella              | Scopo                                         | Note |
-|---|---|---|
+| -------------------- | --------------------------------------------- | ---- |
 | `turni_palloni`      | Gestione dei turni palloni.                   |      |
 | `push_subscriptions` | Dispositivi registrati per le notifiche Push. |      |
 | `promemoria_push`    | Storico dei promemoria inviati.               |      |
@@ -57,7 +57,7 @@ non in questo file.
 ## Funzioni speciali
 
 | Tabella          | Scopo                 | Note                                   |
-|---|---|---|
+| ---------------- | --------------------- | -------------------------------------- |
 | `cacche_partita` | Sondaggio prepartita. | Usato per statistiche e badge segreti. |
 
 ## Badge

docs/DESIGN_DECISIONS.md

@@ -2,13 +2,13 @@
 
 Questo documento raccoglie le **decisioni importanti** prese nel corso della vita di CrAPP: scelte che hanno influito sulla direzione del prodotto, sull’organizzazione del lavoro o su come l’app si evolve nel tempo.
 
-Non descrive *come* è fatto il codice. Per quello esistono `ARCHITECTURE.md` e `DATABASE.md`.
+Non descrive _come_ è fatto il codice. Per quello esistono `ARCHITECTURE.md` e `DATABASE.md`.
 
 Serve a rispondere a domande del tipo:
 
-- *Perché abbiamo scelto così?*
+- _Perché abbiamo scelto così?_
-- *Cosa avevamo escluso e perché?*
+- _Cosa avevamo escluso e perché?_
-- *Quando conviene riaprire una decisione?*
+- _Quando conviene riaprire una decisione?_
 
 ---
 
@@ -17,7 +17,7 @@ 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-003](#dd-003--due-branch-main-stabile-develop-per-il-lavoro)                  | Branch main / develop                 |
@@ -38,7 +38,7 @@ Serve a rispondere a domande del tipo:
 **In valutazione**
 
 | ID                                                                | Titolo                 |
-|---|---|
+| ----------------------------------------------------------------- | ---------------------- |
 | [DD-014](#dd-014--convergenza-schema-database-eventi-e-presenze)  | Convergenza schema DB  |
 | [DD-015](#dd-015--rosa-anagrafica-da-codice-hardcoded-a-database) | Rosa da hardcoded a DB |
 
@@ -49,7 +49,7 @@ Serve a rispondere a domande del tipo:
 Ogni decisione segue lo stesso schema:
 
 | Campo                    | Significato                                            |
-|---|---|
+| ------------------------ | ------------------------------------------------------ |
 | **Data**                 | Quando la decisione è stata presa o confermata         |
 | **Stato**                | Accettata · In valutazione · Sostituita · Obsoleta     |
 | **Contesto**             | Quale problema o opportunità avevamo di fronte         |
@@ -94,10 +94,12 @@ Il progetto nasce come prototipo su Lovable Cloud. Per crescere serve controllo
 Spostare lo sviluppo su repository GitHub indipendente, con deploy su Vercel e database Supabase gestito dal team.
 
 **Alternative scartate**
+
 - Restare su Lovable come unica piattaforma → troppa dipendenza da un servizio esterno.
 - Riscrivere tutto da zero → costo e rischio inutili; il prototipo funzionava già.
 
 **Conseguenze**
+
 - Maggiore libertà e responsabilità per il team.
 - Restano tracce del passaggio (dipendenze, meta tag): vanno eliminate gradualmente, non in blocco.
 - L’app deve poter girare anche fuori dall’ecosistema Lovable (vedi `PORTABILITA.md`).
@@ -119,10 +121,12 @@ Con più persone (e assistenti AI) che lavorano sul codice, serviva un modo per
 Ogni nuova funzionalità significativa viene prima **progettata e documentata** in `docs/modules/`, poi implementata. Il flusso ufficiale è: idea → progettazione → documentazione → database → codice → test → release.
 
 **Alternative scartate**
+
 - Documentare solo a posteriori → troppo spesso incompleto o assente.
 - Affidarsi solo al codice come documentazione → illeggibile per chi non programma.
 
 **Conseguenze**
+
 - Rallenta leggermente l’avvio di nuove feature, ma riduce rework e discussioni infinite.
 - I moduli v1.0 vanno retro-documentati quando possibile.
 - Nessuna feature non documentata entra in produzione.
@@ -141,14 +145,17 @@ Se il team diventa molto piccolo e la documentazione smette di essere consultata
 Serve separare ciò che i giocatori usano ogni giorno da ciò che è ancora in prova.
 
 **Decisione**
+
 - `main` → produzione, sempre funzionante, deploy automatico.
 - `develop` → sviluppo e preview, merge su `main` solo dopo test.
 
 **Alternative scartate**
+
 - Sviluppare direttamente su `main` → rischio di rotture in produzione.
 - Branch per ogni feature → eccessivo per la dimensione attuale del team.
 
 **Conseguenze**
+
 - Gli utenti in produzione non vedono lavori incompleti.
 - Ogni release su `main` deve includere verifica delle funzionalità esistenti.
 
@@ -169,9 +176,11 @@ CrAPP v1.0 è già usata dalla squadra per presenze, calendario, scout, badge e
 Le nuove versioni **introducono** funzionalità. Non si riscrive un modulo già operativo salvo richiesta esplicita e pianificata.
 
 **Alternative scartate**
+
 - Refactoring ampio “per pulire” insieme a ogni release → alto rischio, poco valore immediato per gli utenti.
 
 **Conseguenze**
+
 - Coesistono temporaneamente soluzioni vecchie e nuove (es. dati hardcoded accanto a tabelle database).
 - Il debito tecnico va gestito con migration dedicate, non di nascosto.
 
@@ -192,10 +201,12 @@ I giocatori usano l’app soprattutto da smartphone, spesso in spogliatoio o in
 Interfaccia semplice, veloce, ottimizzata per telefono. Navigazione ridotta (barra inferiore). Ogni schermata deve avere uno scopo chiaro.
 
 **Alternative scartate**
+
 - Layout da desktop con menu complessi → scomodo in mobilità.
 - App nativa iOS/Android → costi e tempi di pubblicazione non giustificati per una squadra amatoriale.
 
 **Conseguenze**
+
 - Funzionalità amministrative complesse vanno semplificate o suddivise con cura.
 - La PWA è la forma giusta per questo pubblico.
 
@@ -216,11 +227,13 @@ L’AI è attraente ma può complicare l’app, aumentare i costi e creare aspet
 Usare l’AI solo quando riduce lavoro agli admin o migliora concretamente l’esperienza dei giocatori. Non introdurla “perché si può”.
 
 **Alternative scartate**
+
 - AI ovunque (chatbot, suggerimenti automatici, analisi predittive) → fuori focus per una squadra amatoriale.
 
 **Conseguenze**
+
 - “AI Allenamenti” è in roadmap v1.2, non v1.1.
-- Ogni proposta AI va valutata con la domanda: *chi risparmia tempo e quanto?*
+- Ogni proposta AI va valutata con la domanda: _chi risparmia tempo e quanto?_
 
 **Riesame**  
 Quando l’AI diventa economica e affidabile per casi d’uso chiari (es. generazione allenamenti).
@@ -239,9 +252,11 @@ I badge dipendono da statistiche già disponibili (presenze, MVP, cacche, ecc.).
 I badge vengono **calcolati al volo** dall’applicazione in base ai dati esistenti. Non esiste una tabella badge dedicata.
 
 **Alternative scartate**
+
 - Tabella `badge_sbloccati` con storico → utile in futuro per notifiche retroattive o audit, ma non necessaria ora.
 
 **Conseguenze**
+
 - Meno migration e meno sincronizzazione.
 - Lo “sblocco” celebrativo usa cache locale per non ripetere animazioni.
 - Un eventuale storico badge richiederà una nuova decisione.
@@ -263,9 +278,11 @@ In pallavolo i ruoli hanno statistiche diverse (un libero non segna punti d’at
 Le statistiche **personali** in profilo e squadra devono essere **eque per tutti i ruoli**. Dati tecnici di reparto (punti, ace, muri) restano nello Scout Live come informazione di squadra, non come leva competitiva individuale.
 
 **Alternative scartate**
+
 - Classifiche individuali basate su punti → penalizza libero, palleggiatore, centrale.
 
 **Conseguenze**
+
 - Badge e obiettivi usano presenze, MVP, pagelle, serie, cacche — metriche accessibili a tutti.
 - Lo scout resta strumento tecnico, non gioco.
 
@@ -283,13 +300,16 @@ Se la squadra chiede esplicitamente classifiche tecniche per ruolo.
 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.
 
 **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).
 
 **Alternative scartate**
+
 - Integrazione CSI già in v1.1 → 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.
 
@@ -310,9 +330,11 @@ Il certificato medico va aggiornato ogni stagione. Tenere lo storico di tutte le
 In v1 il giocatore può **sovrascrivere** certificato e data di scadenza. Lo storico delle versioni precedenti non viene conservato.
 
 **Alternative scartate**
+
 - Archivio certificati → utile per audit, rinviato a versioni future.
 
 **Conseguenze**
+
 - Implementazione più semplice e veloce.
 - Gli admin vedono solo il certificato attuale.
 - Va comunicato chiaramente ai giocatori che sostituire il file elimina quello precedente.
@@ -328,16 +350,18 @@ Se il CSI o il regolamento interno richiedono conservazione storica.
 **Stato:** Accettata
 
 **Contesto**  
-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.
+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.
 
 **Alternative scartate**
+
 - Continuare solo con selezione da lista → inaccettabile per dati sensibili.
 - Lovable Auth → crea dipendenza da piattaforma che stiamo abbandonando.
 
 **Conseguenze**
+
 - Tutti dovranno fare login almeno una volta.
 - Gli admin useranno ruoli veri (`user_roles`), non una lista di nomi hardcoded.
 - È prerequisito per dashboard admin e export CSI.
@@ -359,9 +383,11 @@ L’app usa identificativi semplici (`g1`, `g2`, …) collegati a presenze, voti
 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.
 
 **Alternative scartate**
+
 - Migrare tutto a UUID in v1.1 → rischio alto di rompere presenze, voti, scout e notifiche.
 
 **Conseguenze**
+
 - Coesistono due modelli anagrafici fino a migration dedicata.
 - `DATABASE.md` va tenuto aggiornato su cosa è “attivo” e cosa è “futuro”.
 
@@ -382,9 +408,11 @@ La squadra potrebbe voler cambiare hosting, database o fornitore auth in futuro.
 CrAPP deve poter girare su **Node.js + PostgreSQL standard**. Niente funzionalità bloccate su servizi proprietari. I dati si accedono solo tramite moduli in `src/lib/`, non direttamente dai componenti.
 
 **Alternative scartate**
+
 - Accettare lock-in per velocità → contrario alla lunga vita del progetto.
 
 **Conseguenze**
+
 - Supabase va bene perché è PostgreSQL e self-hostable.
 - Le API push e i job restano endpoint HTTP richiamabili da qualsiasi scheduler.
 
@@ -417,6 +445,7 @@ Regole vincolanti:
 6. La tabella `giocatori` (UUID) resta **invariata e non usata** dal modulo profilo in v1.1.
 
 **Alternative scartate**
+
 - Estendere la tabella `giocatori` UUID → conflitto con ID operativi del codice e rischio di regressioni.
 - 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à.
@@ -424,6 +453,7 @@ Regole vincolanti:
 - Modificare tabelle v1.0 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` dovrà leggere prima dal database e ricadere su `crapp-data.ts` in caso di errore o assenza dati.
 - Il completamento profilo (30/30/30/10) si calcola in app, non si persiste nel database.
@@ -432,6 +462,7 @@ Regole vincolanti:
 - 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).
 - Se il CSI o il regolamento richiedono conservazione storica documenti o consensi privacy dedicati.
@@ -459,19 +490,22 @@ Restano fuori, e non cambiano:
 - il **giocatore**, che continua a non poter toccare i propri dati squadra.
 
 **Alternative scartate**
+
 - Lasciare tutto al giocatore → l'export CSI resta incompleto e il lavoro amministrativo torna in chat, contro la missione del progetto.
 - Dare all'admin anche l'upload dei file → confonde chi ha fornito un documento, su dati sanitari e d'identità dove serve il contrario.
 - Un ruolo intermedio (segreteria) per i soli dati personali → un ruolo in più per una squadra sola, con gli stessi tre amministratori di adesso.
 
 **Conseguenze**
+
 - Il modello dei permessi non è più "ognuno i suoi": è "ognuno i suoi, più l'admin su tutti, tranne i file". Le policy RLS di M1 e M2 lo consentivano già, quindi non servono migration.
 - Un admin può correggere un errore di battitura in un numero di documento senza inseguire il giocatore.
 - Un admin vede e scrive dati personali altrui: è un potere reale, dato a tre persone su diciassette. Va assegnato con la stessa cura di prima (una riga in `user_roles`, nessuna auto-promozione).
-- Il completamento del profilo smette di essere un indicatore di *chi ha risposto* e diventa un indicatore di *quali dati mancano*, chiunque li abbia inseriti.
+- Il completamento del profilo smette di essere un indicatore di _chi ha risposto_ e diventa un indicatore di _quali dati mancano_, chiunque li abbia inseriti.
 
 **Riesame**
+
 - Se la squadra cresce al punto da rendere sensato un ruolo di sola segreteria.
-- Se serve tracciare *chi* ha modificato un dato: oggi non c'è audit, e con la scrittura condivisa la domanda prima o poi arriva.
+- Se serve tracciare _chi_ ha modificato un dato: oggi non c'è audit, e con la scrittura condivisa la domanda prima o poi arriva.
 
 ---
 
@@ -487,15 +521,18 @@ DD-016 regola 2 prevedeva che, al primo accesso, il giocatore scegliesse manualm
 Al primo accesso, `giocatori_squadra` viene interrogata per email (case-insensitive, tramite la nuova colonna `email`) invece di mostrare un elenco di slot liberi. Se l'email dell'account Google corrisponde a una riga libera, il collegamento avviene automaticamente. Se non corrisponde a nessuna riga (email non ancora nota, o nessun profilo per quella persona), l'utente vede solo un messaggio d'errore che invita a contattare un amministratore, con un pulsante per uscire e riprovare con un altro account — nessuna selezione manuale di ripiego. Le email sono popolate via migration (`m5_email_giocatori_squadra`), non tramite un'interfaccia amministrativa in questa iterazione. Il trigger `enforce_giocatori_squadra_update` (DD-016) viene esteso per richiedere anche la corrispondenza email, non solo lo slot libero: il vincolo resta nel database, non solo nella UI.
 
 **Alternative scartate**
+
 - Mantenere la selezione manuale come ripiego quando l'email non trova corrispondenza → scartata: vanificherebbe la garanzia "ognuno collega solo il proprio profilo" e reintrodurrebbe il rischio di scelta errata che questa decisione vuole eliminare.
 - Un'interfaccia admin per scrivere l'email dei giocatori → rimandata: non necessaria finché le email arrivano da migration; si può aggiungere in futuro senza toccare questa decisione.
 
 **Conseguenze**
+
 - Le righe senza email nota restano bloccate — nessuno può collegarle, nemmeno per errore — finché una migration futura non la imposta. Oggi solo 2 dei 17 giocatori hanno l'email registrata.
 - `slotLiberi` (funzione ed elenco "slot liberi" in `/benvenuto`) è stato rimosso: non aveva più chiamanti in produzione dopo il cambio.
 - Un utente che accede con l'account Google sbagliato resta bloccato su `/benvenuto` finché non esce e riprova con l'account giusto.
 
 **Riesame**
+
 - Quando tutte le 17 email saranno note e verificate.
 - Se in futuro serve un'assistenza admin diretta dal flusso di login invece che da `/admin`.
 

docs/PORTABILITA.md

@@ -6,7 +6,7 @@ senza dipendere da servizi esclusivi di Lovable Cloud.
 ## Stato attuale
 
 | Componente                                        | Portabile? | Note                                                                                                         |
-|---|---|---|
+| ------------------------------------------------- | ---------- | ------------------------------------------------------------------------------------------------------------ |
 | Frontend (React + TanStack Start/Router)          | Sì         | Build Vite standard, deploy su qualsiasi host Node.                                                          |
 | Server functions / route API (`src/routes/api/*`) | Sì         | API HTTP standard, nessuna edge function proprietaria.                                                       |
 | Database                                          | Sì         | PostgreSQL puro; lo schema sta nelle migrazioni SQL.                                                         |

docs/README.md

@@ -7,7 +7,7 @@ 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           |
@@ -33,7 +33,7 @@ modulo interessato in `modules/`.
 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;
+- `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;
 - 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;

docs/ROADMAP.md

@@ -1,7 +1,7 @@
 # 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
+il _cosa_: `CHANGELOG.md` registra _quando_ una voce è stata rilasciata, `TODO.md` cosa si
 sta facendo adesso.
 
 ## Versione 1.0 — rilasciata

docs/_template-dd.md

@@ -10,6 +10,7 @@
 [Cosa abbiamo scelto?]
 
 **Alternative scartate**
+
 - [Alternativa 1] → [perché no]
 - [Alternativa 2] → [perché no]
 

docs/modules/collegamento-csi.md

@@ -22,7 +22,7 @@ che il sito chiama internamente via ajax: sono raggiungibili senza autenticazion
 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 |
 
@@ -33,7 +33,7 @@ gare del campionato), `project-chart-rankings.php` (solo punti), `project-next_m
 ### 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)        |

docs/modules/profilo-giocatore.md

@@ -41,9 +41,9 @@ responsabilità del giocatore che li fornisce.
 
 ### Primo accesso
 
-1. Login tramite Google oppure Email. *Implementato con il solo Google: la squadra ha tutti
+1. Login tramite Google oppure Email. _Implementato con il solo Google: la squadra ha tutti
    un account Google, e un secondo metodo è additivo (un bottone in più sulla stessa
-   schermata) il giorno che serve.*
+   schermata) il giorno che serve._
 2. Collegamento automatico al proprio giocatore, confrontando l'email dell'account Google
    con l'email registrata in `giocatori_squadra` (DD-018). Nessuna scelta manuale: se
    l'email non corrisponde a nessun profilo, l'accesso si ferma con un messaggio che invita
@@ -58,7 +58,7 @@ Il giocatore visualizza un widget dedicato.
 
 ### Completa il tuo profilo
 
-Viene mostrata una barra di avanzamento (esempio: *Profilo completato — 85%*), composta dalle seguenti sezioni.
+Viene mostrata una barra di avanzamento (esempio: _Profilo completato — 85%_), composta dalle seguenti sezioni.
 
 - Dati personali
 - Documento di identità
@@ -194,7 +194,7 @@ Campi esportati.
 Ogni sezione contribuisce alla percentuale di completamento.
 
 | Sezione               | Peso |
-|---|---|
+| --------------------- | ---- |
 | Dati personali        | 30%  |
 | Documento di identità | 30%  |
 | Certificato medico    | 30%  |

src/routes/README.md

@@ -8,7 +8,7 @@ is `src/routes/__root.tsx`.
 ## Conventions
 
 | File                     | URL                                                     |
-| --- | --- |
+| ------------------------ | ------------------------------------------------------- |
 | `index.tsx`              | `/`                                                     |
 | `about.tsx`              | `/about`                                                |
 | `users/index.tsx`        | `/users`                                                |

test/README.md

@@ -18,7 +18,7 @@ non può inquinare gli altri.
 ## Struttura
 
 | Cartella       | Cosa verifica                                                                                                                                                                            | Serve rete? |
-|---|---|---|
+| -------------- | ---------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | ----------- |
 | `unit/`        | Logica di dominio pura: badge, serie, palloni, pagelle, MVP, cacche, scout, obiettivi, notifiche, parsing CSI, dati della rosa                                                           | No          |
 | `integration/` | Le route `/api/public/*` sul server di sviluppo: risposte, cache, validazione degli input. Più schema e permessi del Profilo Giocatore (`schema-profili`) contro il database configurato | Sì          |
 | `e2e/`         | Percorsi completi sull'app servita: schermate, dati CSI fino alla pagina, file PWA, 404                                                                                                  | Sì          |
@@ -28,7 +28,7 @@ non può inquinare gli altri.
 
 - **Nessun test scrive sul database.** Integration ed e2e fanno solo letture e
   verifiche di validazione: si possono lanciare anche contro l'ambiente reale.
-  L'unica eccezione apparente è `schema-profili`, che *tenta* scritture da utente
+  L'unica eccezione apparente è `schema-profili`, che _tenta_ scritture da utente
   anonimo proprio per dimostrare che la RLS le respinge, e poi rilegge la riga per
   verificare che non sia cambiata: su un UPDATE a zero righe PostgREST risponde 2xx,
   quindi lo stato conta più del codice di risposta.