Toglie TODO.md e VISION.md dalla documentazione.

Erano due file che nessuno teneva più allineati: `TODO.md` ripeteva lo stato di
`PROJECT_STATE.md` e il backlog della roadmap, `VISION.md` la missione già
riassunta in apertura di `AGENTS.md`. La manutenzione stagionale del
collegamento CSI, unica voce senza altra casa, è già tra i limiti noti del
modulo `collegamento-csi.md`.

Aggiornati i sei rimandi: indice, ordine di lettura e regole di manutenzione in
docs/README.md, la missione e l'elenco dei documenti di tracciabilità in
AGENTS.md, la nota sul _cosa_ in ROADMAP.md — che ora punta a PROJECT_STATE.md.

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

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
+squadra e usare l'AI solo quando porta un beneficio reale. Deve restare semplice, veloce e
-[docs/VISION.md](docs/VISION.md).
+usabile dallo smartphone anche da chi non è pratico.
 
 ## Prima di modificare il codice
 
@@ -83,8 +83,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/ROADMAP.md](docs/ROADMAP.md), [docs/DATABASE.md](docs/DATABASE.md) (se cambia lo schema).
-[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

docs/README.md

@@ -8,14 +8,12 @@ ancora e va **prima documentata** (vedi [DD-002](DESIGN_DECISIONS.md#dd-002--svi
 
 | 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                            |
 
@@ -24,9 +22,8 @@ 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` →
+Prima di modificare il codice, nell'ordine: questo indice → `ROADMAP.md` → `ARCHITECTURE.md`
-`ARCHITECTURE.md` → `DATABASE.md` → `DESIGN_DECISIONS.md` → `TODO.md` → il documento del
+→ `DATABASE.md` → `DESIGN_DECISIONS.md` → il documento del modulo interessato in `modules/`.
-modulo interessato in `modules/`.
 
 ## Regole di manutenzione
 
@@ -34,7 +31,7 @@ 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;
+- 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,8 +1,8 @@
 # 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,
-sta facendo adesso.
+[PROJECT_STATE.md](../PROJECT_STATE.md) cosa si sta facendo adesso.
 
 ## Versione 1.0 — rilasciata
 

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.