diff --git a/.lovable/plan/obiettivi-di-squadra-sezione-in-squadra-widget-in-home-2026-08-03.md b/.lovable/plan/obiettivi-di-squadra-sezione-in-squadra-widget-in-home-2026-08-03.md index 67b4fe6..14ceb02 100644 --- a/.lovable/plan/obiettivi-di-squadra-sezione-in-squadra-widget-in-home-2026-08-03.md +++ b/.lovable/plan/obiettivi-di-squadra-sezione-in-squadra-widget-in-home-2026-08-03.md @@ -7,25 +7,32 @@ 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. - - Nessuna nuova rotta e nessuna modifica al bottom nav. + +- 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). + +- 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.). + +- 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. \ No newline at end of file +- Bottom nav e rotte invariate. diff --git a/.lovable/plan/ridimensionamento-badge-nella-lista-squadra-2026-07-31.md b/.lovable/plan/ridimensionamento-badge-nella-lista-squadra-2026-07-31.md index 8a6dc99..55b9912 100644 --- a/.lovable/plan/ridimensionamento-badge-nella-lista-squadra-2026-07-31.md +++ b/.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. diff --git a/.lovable/plan/rimuovere-placeholder-livello-7-dal-profilo-2026-08-05.md b/.lovable/plan/rimuovere-placeholder-livello-7-dal-profilo-2026-08-05.md index 57eb97d..98e93be 100644 --- a/.lovable/plan/rimuovere-placeholder-livello-7-dal-profilo-2026-08-05.md +++ b/.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 `

Livello 7

` (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. diff --git a/.lovable/plan/turno-palloni-nel-calendario-promemoria-2026-07-31.md b/.lovable/plan/turno-palloni-nel-calendario-promemoria-2026-07-31.md index 24d635b..2852c72 100644 --- a/.lovable/plan/turno-palloni-nel-calendario-promemoria-2026-07-31.md +++ b/.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). diff --git a/AGENTS.md b/AGENTS.md index 45a6116..9d95662 100644 --- a/AGENTS.md +++ b/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. - diff --git a/PROJECT_STATE.md b/PROJECT_STATE.md index 9252334..7ee694f 100644 --- a/PROJECT_STATE.md +++ b/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 - `email` e `profile`, non sensibili: nessuna verifica richiesta, e la modalità *Testing* +1. **Provider Google in Supabase** — Google Cloud Console: consent screen _External_ (scope + `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 diff --git a/README.md b/README.md index 1d1cc9a..7fe66f9 100644 --- a/README.md +++ b/README.md @@ -92,4 +92,4 @@ Test Merge su main ↓ Deploy automatico Vercel -``` \ No newline at end of file +``` diff --git a/docs/ARCHITECTURE.md b/docs/ARCHITECTURE.md index ac21a45..f7ff3a6 100644 --- a/docs/ARCHITECTURE.md +++ b/docs/ARCHITECTURE.md @@ -5,12 +5,12 @@ 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 | -| Versionamento | Git, GitHub | +| Livello | Tecnologie | +| ------------- | ------------------------------------------------------------------------------------- | +| Frontend | React 19, TypeScript, TanStack Start (SSR), Vite 8, Tailwind CSS 4, Radix UI / shadcn | +| Backend | Supabase (PostgreSQL, Auth, Storage) | +| Hosting | Vercel | +| Versionamento | Git, GitHub | Le dipendenze sono installate con **bun** (`bun.lock`, `bunfig.toml`). `bunfig.toml` impone `minimumReleaseAge = 24h` come guardia supply-chain: aggiungere un pacchetto a diff --git a/docs/DATABASE.md b/docs/DATABASE.md index 228054c..97b398a 100644 --- a/docs/DATABASE.md +++ b/docs/DATABASE.md @@ -7,57 +7,57 @@ non in questo file. ## Anagrafica e utenti -| Tabella | Scopo | Note | -|---|---|---| +| 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. | -| `user_roles` | Ruoli applicativi (es. amministratore, giocatore). | Fonte dei permessi di amministrazione, letta da `src/lib/ruoli.ts` (DD-011). Il primo admin va inserito a mano; vedi [PROJECT_STATE.md](../PROJECT_STATE.md). | +| `giocatori` | 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). | `giocatori_squadra` / `giocatori` sono usate da: Squadra, Profili, Presenze, Scout, Badge, Pagelle. ## Storage -| Bucket | Scopo | Note | -|---|---|---| +| Bucket | Scopo | Note | +| ------------------- | ---------------------------------------------------------------------------------------------------------------------- | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | | `profili-giocatore` | Documento d'identità, certificato medico e foto tessera, in cartelle per giocatore (`/.`). | **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). | -| `presenze` | Presenze agli eventi. | Come sopra (DD-014). | +| 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). | +| `presenze` | Presenze agli eventi. | Come sopra (DD-014). | ## Scout -| Tabella | Scopo | Note | -|---|---|---| +| 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). | +| `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. | | +| 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. | | ## 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. | | +| Tabella | Scopo | Note | +| -------------------- | --------------------------------------------- | ---- | +| `turni_palloni` | Gestione dei turni palloni. | | +| `push_subscriptions` | Dispositivi registrati per le notifiche Push. | | +| `promemoria_push` | Storico dei promemoria inviati. | | ## Funzioni speciali -| Tabella | Scopo | Note | -|---|---|---| +| Tabella | Scopo | Note | +| ---------------- | --------------------- | -------------------------------------- | | `cacche_partita` | Sondaggio prepartita. | Usato per statistiche e badge segreti. | ## Badge diff --git a/docs/DESIGN_DECISIONS.md b/docs/DESIGN_DECISIONS.md index bcb2783..7c50183 100644 --- a/docs/DESIGN_DECISIONS.md +++ b/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ì?* -- *Cosa avevamo escluso e perché?* -- *Quando conviene riaprire una decisione?* +- _Perché abbiamo scelto così?_ +- _Cosa avevamo escluso e perché?_ +- _Quando conviene riaprire una decisione?_ --- @@ -16,30 +16,30 @@ 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 | -| [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-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 | +| 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 | +| [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-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 | **In valutazione** -| ID | Titolo | -|---|---| -| [DD-014](#dd-014--convergenza-schema-database-eventi-e-presenze) | Convergenza schema DB | +| 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 | --- @@ -48,15 +48,15 @@ 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 | -| **Decisione** | Cosa abbiamo scelto di fare | -| **Alternative scartate** | Cosa non abbiamo fatto e perché | -| **Conseguenze** | Cosa comporta nel quotidiano (utenti, admin, sviluppo) | -| **Riesame** | Quando ha senso riconsiderarla | +| Campo | Significato | +| ------------------------ | ------------------------------------------------------ | +| **Data** | Quando la decisione è stata presa o confermata | +| **Stato** | Accettata · In valutazione · Sostituita · Obsoleta | +| **Contesto** | Quale problema o opportunità avevamo di fronte | +| **Decisione** | Cosa abbiamo scelto di fare | +| **Alternative scartate** | Cosa non abbiamo fatto e perché | +| **Conseguenze** | Cosa comporta nel quotidiano (utenti, admin, sviluppo) | +| **Riesame** | Quando ha senso riconsiderarla | **Quando aggiungere una voce** @@ -93,13 +93,15 @@ Il progetto nasce come prototipo su Lovable Cloud. Per crescere serve controllo **Decisione** 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. +**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. +**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`). **Riesame** @@ -118,13 +120,15 @@ Con più persone (e assistenti AI) che lavorano sul codice, serviva un modo per **Decisione** 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. +**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. +**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. **Riesame** @@ -140,16 +144,19 @@ Se il team diventa molto piccolo e la documentazione smette di essere consultata **Contesto** Serve separare ciò che i giocatori usano ogni giorno da ciò che è ancora in prova. -**Decisione** -- `main` → produzione, sempre funzionante, deploy automatico. +**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. +**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. +**Conseguenze** + +- Gli utenti in produzione non vedono lavori incompleti. - Ogni release su `main` deve includere verifica delle funzionalità esistenti. **Riesame** @@ -168,11 +175,13 @@ CrAPP v1.0 è già usata dalla squadra per presenze, calendario, scout, badge e **Decisione** Le nuove versioni **introducono** funzionalità. Non si riscrive un modulo già operativo salvo richiesta esplicita e pianificata. -**Alternative scartate** +**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). +**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. **Riesame** @@ -191,12 +200,14 @@ I giocatori usano l’app soprattutto da smartphone, spesso in spogliatoio o in **Decisione** 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à. +**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. +**Conseguenze** + +- Funzionalità amministrative complesse vanno semplificate o suddivise con cura. - La PWA è la forma giusta per questo pubblico. **Riesame** @@ -215,12 +226,14 @@ L’AI è attraente ma può complicare l’app, aumentare i costi e creare aspet **Decisione** Usare l’AI solo quando riduce lavoro agli admin o migliora concretamente l’esperienza dei giocatori. Non introdurla “perché si può”. -**Alternative scartate** +**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?* +**Conseguenze** + +- “AI Allenamenti” è in roadmap v1.2, non v1.1. +- 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). @@ -238,12 +251,14 @@ I badge dipendono da statistiche già disponibili (presenze, MVP, cacche, ecc.). **Decisione** I badge vengono **calcolati al volo** dall’applicazione in base ai dati esistenti. Non esiste una tabella badge dedicata. -**Alternative scartate** +**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. +**Conseguenze** + +- Meno migration e meno sincronizzazione. +- Lo “sblocco” celebrativo usa cache locale per non ripetere animazioni. - Un eventuale storico badge richiederà una nuova decisione. **Riesame** @@ -262,11 +277,13 @@ In pallavolo i ruoli hanno statistiche diverse (un libero non segna punti d’at **Decisione** 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** +**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. +**Conseguenze** + +- Badge e obiettivi usano presenze, MVP, pagelle, serie, cacche — metriche accessibili a tutti. - Lo scout resta strumento tecnico, non gioco. **Riesame** @@ -282,15 +299,18 @@ Se la squadra chiede esplicitamente classifiche tecniche per ruolo. **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. -**Decisione** -- **v1.1:** profilo completo, dashboard admin, download documenti, export CSV con i campi richiesti dal CSI. +**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** +**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). +**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. **Riesame** @@ -309,12 +329,14 @@ Il certificato medico va aggiornato ogni stagione. Tenere lo storico di tutte le **Decisione** In v1 il giocatore può **sovrascrivere** certificato e data di scadenza. Lo storico delle versioni precedenti non viene conservato. -**Alternative scartate** +**Alternative scartate** + - Archivio certificati → utile per audit, rinviato a versioni future. -**Conseguenze** -- Implementazione più semplice e veloce. -- Gli admin vedono solo il certificato attuale. +**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. **Riesame** @@ -328,18 +350,20 @@ 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. +**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. +**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. **Riesame** @@ -358,11 +382,13 @@ L’app usa identificativi semplici (`g1`, `g2`, …) collegati a presenze, voti **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. -**Alternative scartate** +**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. +**Conseguenze** + +- Coesistono due modelli anagrafici fino a migration dedicata. - `DATABASE.md` va tenuto aggiornato su cosa è “attivo” e cosa è “futuro”. **Riesame** @@ -381,11 +407,13 @@ La squadra potrebbe voler cambiare hosting, database o fornitore auth in futuro. **Decisione** 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** +**Alternative scartate** + - Accettare lock-in per velocità → contrario alla lunga vita del progetto. -**Conseguenze** -- Supabase va bene perché è PostgreSQL e self-hostable. +**Conseguenze** + +- Supabase va bene perché è PostgreSQL e self-hostable. - Le API push e i job restano endpoint HTTP richiamabili da qualsiasi scheduler. **Riesame** @@ -416,24 +444,27 @@ Regole vincolanti: 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. -**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à. -- Permettere al giocatore di cambiare `auth_user_id` liberamente → rischio di impersonazione e race condition. +**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à. +- 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. -**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. -- Lo storico certificati non viene conservato in v1 (coerente con DD-010). -- Le migration M1–M3 (tabelle, RLS, bucket) restano **additive**: solo `CREATE`, nessun `ALTER`/`DROP` su schema esistente. +**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. +- Lo storico certificati non viene conservato in v1 (coerente con DD-010). +- Le migration M1–M3 (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). +**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. --- @@ -458,20 +489,23 @@ Restano fuori, e non cambiano: - i **file** (documento, certificato, foto): l'admin li scarica ma non li carica né li sostituisce. Un documento d'identità lo produce il suo titolare, e la catena di responsabilità deve restare leggibile; - 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. +**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. +**Conseguenze** -**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. +- 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. + +**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. --- @@ -486,17 +520,20 @@ DD-016 regola 2 prevedeva che, al primo accesso, il giocatore scegliesse manualm **Decisione** 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. +**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. +**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. +**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`. --- diff --git a/docs/PORTABILITA.md b/docs/PORTABILITA.md index 961e5d2..731ae14 100644 --- a/docs/PORTABILITA.md +++ b/docs/PORTABILITA.md @@ -5,16 +5,16 @@ 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. | -| 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. | +| 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. | +| 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 diff --git a/docs/README.md b/docs/README.md index d5dbd10..7b8242d 100644 --- a/docs/README.md +++ b/docs/README.md @@ -6,18 +6,18 @@ 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 | +| 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 | +| [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 | 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). @@ -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; diff --git a/docs/ROADMAP.md b/docs/ROADMAP.md index 230a602..3e38358 100644 --- a/docs/ROADMAP.md +++ b/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 diff --git a/docs/VISION.md b/docs/VISION.md index bfe6a71..f87b716 100644 --- a/docs/VISION.md +++ b/docs/VISION.md @@ -29,4 +29,4 @@ CrAPP deve essere: ## Obiettivo finale -Diventare il punto di riferimento per la gestione quotidiana della squadra, sostituendo chat, fogli Excel e strumenti separati con un'unica applicazione. \ No newline at end of file +Diventare il punto di riferimento per la gestione quotidiana della squadra, sostituendo chat, fogli Excel e strumenti separati con un'unica applicazione. diff --git a/docs/_template-dd.md b/docs/_template-dd.md index 7a2d48c..d62b890 100644 --- a/docs/_template-dd.md +++ b/docs/_template-dd.md @@ -9,8 +9,9 @@ **Decisione** [Cosa abbiamo scelto?] -**Alternative scartate** -- [Alternativa 1] → [perché no] +**Alternative scartate** + +- [Alternativa 1] → [perché no] - [Alternativa 2] → [perché no] **Conseguenze** diff --git a/docs/modules/collegamento-csi.md b/docs/modules/collegamento-csi.md index 7e3bf65..bdbadef 100644 --- a/docs/modules/collegamento-csi.md +++ b/docs/modules/collegamento-csi.md @@ -21,10 +21,10 @@ 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 | +| 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`, @@ -32,13 +32,13 @@ 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) | -| `team_id` | `3359` | -| Girone | B | +| 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 | Gli identificativi sono costanti in `src/lib/csi-core.ts`. diff --git a/docs/modules/profilo-giocatore.md b/docs/modules/profilo-giocatore.md index 2bbf1fb..d43544b 100644 --- a/docs/modules/profilo-giocatore.md +++ b/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à @@ -193,12 +193,12 @@ Campi esportati. Ogni sezione contribuisce alla percentuale di completamento. -| Sezione | Peso | -|---|---| -| Dati personali | 30% | -| Documento di identità | 30% | -| Certificato medico | 30% | -| Foto tessera | 10% | +| Sezione | Peso | +| --------------------- | ---- | +| Dati personali | 30% | +| Documento di identità | 30% | +| Certificato medico | 30% | +| Foto tessera | 10% | Quando tutte le sezioni risultano complete il profilo raggiunge il 100%. diff --git a/src/routes/README.md b/src/routes/README.md index 441a4e8..0990d2f 100644 --- a/src/routes/README.md +++ b/src/routes/README.md @@ -7,15 +7,15 @@ is `src/routes/__root.tsx`. ## Conventions -| File | URL | -| --- | --- | -| `index.tsx` | `/` | -| `about.tsx` | `/about` | -| `users/index.tsx` | `/users` | -| `users/$id.tsx` | `/users/:id` (dynamic — bare `$`, no curly braces) | -| `posts/{-$category}.tsx` | `/posts/:category?` (optional segment) | -| `files/$.tsx` | `/files/*` (splat — read via `_splat` param, never `*`) | -| `_layout.tsx` | layout route (renders children via ``) | -| `__root.tsx` | app shell — wraps every page; preserve `` | +| File | URL | +| ------------------------ | ------------------------------------------------------- | +| `index.tsx` | `/` | +| `about.tsx` | `/about` | +| `users/index.tsx` | `/users` | +| `users/$id.tsx` | `/users/:id` (dynamic — bare `$`, no curly braces) | +| `posts/{-$category}.tsx` | `/posts/:category?` (optional segment) | +| `files/$.tsx` | `/files/*` (splat — read via `_splat` param, never `*`) | +| `_layout.tsx` | layout route (renders children via ``) | +| `__root.tsx` | app shell — wraps every page; preserve `` | `routeTree.gen.ts` is auto-generated. Don't edit it by hand. diff --git a/test/README.md b/test/README.md index 6f2cffa..0c1899e 100644 --- a/test/README.md +++ b/test/README.md @@ -17,18 +17,18 @@ 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ì | -| `helpers/` | Avvio del server di test e mini-harness condiviso | — | +| 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ì | +| `helpers/` | Avvio del server di test e mini-harness condiviso | — | ## Convenzioni - **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.