From 7e65df1d21c8f77a280a1afa6bf0b5c81a5ab0cb Mon Sep 17 00:00:00 2001 From: Davide Grilli Date: Sun, 6 Sep 2026 22:17:44 +0200 Subject: [PATCH] Toglie TODO.md e VISION.md dalla documentazione. MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit 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 --- AGENTS.md | 7 +++---- docs/README.md | 9 +++------ docs/ROADMAP.md | 4 ++-- docs/TODO.md | 40 ---------------------------------------- docs/VISION.md | 32 -------------------------------- 5 files changed, 8 insertions(+), 84 deletions(-) delete mode 100644 docs/TODO.md delete mode 100644 docs/VISION.md diff --git a/AGENTS.md b/AGENTS.md index bc4d845..b5111c9 100644 --- a/AGENTS.md +++ b/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 @@ -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/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 diff --git a/docs/README.md b/docs/README.md index 7b8242d..e497e96 100644 --- a/docs/README.md +++ b/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` → -`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 @@ -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 diff --git a/docs/ROADMAP.md b/docs/ROADMAP.md index 113b080..22971b6 100644 --- a/docs/ROADMAP.md +++ b/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 -sta facendo adesso. +il _cosa_: `CHANGELOG.md` registra _quando_ una voce è stata rilasciata, +[PROJECT_STATE.md](../PROJECT_STATE.md) cosa si sta facendo adesso. ## Versione 1.0 — rilasciata diff --git a/docs/TODO.md b/docs/TODO.md deleted file mode 100644 index 767ce33..0000000 --- a/docs/TODO.md +++ /dev/null @@ -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). diff --git a/docs/VISION.md b/docs/VISION.md deleted file mode 100644 index f87b716..0000000 --- a/docs/VISION.md +++ /dev/null @@ -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.