davideandClaude Sonnet 5
7ef7eef963
serieConsecutiva()/serieConferme() calcolavano oggi con new Date().toISOString() (sempre UTC), mentre contaPresenzeGiocatore() usava dataOggi() con i getter locali di Date (corretti solo se il processo gira già in fuso italiano — falso su un server SSR in UTC). Le due statistiche potevano non essere d'accordo su cosa fosse "oggi" nelle prime ore della giornata italiana. dataOggi() ora usa Intl.DateTimeFormat con timeZone: "Europe/Rome": il cambio ora legale/solare lo gestisce il database IANA dei fusi, non un offset scritto a mano. Le funzioni di serie in presenze.ts usano lo stesso dataOggi() invece di un oggiIso() locale, così tutte le statistiche restano coerenti fra loro. Aggiunti test che dimostrano il fix con istanti reali a cavallo di mezzanotte sia in CET che in CEST, per provare che lo scarto segue davvero il fuso e non un offset fisso. Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
Documentazione CrAPP
Indice della documentazione ufficiale del progetto. Ogni file risponde a una domanda precisa: se l'informazione che cerchi non è nel file indicato, probabilmente non esiste ancora e va prima documentata (vedi DD-002).
Dove sta cosa
| Documento | Risponde a |
|---|---|
| ROADMAP.md | Cosa è fatto, cosa è previsto, cosa resta un'idea |
| ARCHITECTURE.md | Com'è fatta l'app: stack, struttura del codice, flusso di sviluppo |
| DATABASE.md | Quali tabelle esistono, a cosa servono, chi le usa |
| DESIGN_DECISIONS.md | Perché abbiamo scelto così, cosa abbiamo escluso e quando riaprire la scelta |
| PORTABILITA.md | Cosa lega l'app a un fornitore e cosa no, come spostarla su server proprio |
| EFFICIENZA_CLOUD.md | Come tenere basso il consumo cloud: cache, query, push |
| CHANGELOG.md | Cosa è cambiato e quando |
| modules/ | Specifica funzionale di ogni modulo, una per file |
Le regole vincolanti per gli assistenti AI stanno in AGENTS.md; lo stato corrente del lavoro in PROJECT_STATE.md.
Ordine di lettura
Prima di modificare il codice, nell'ordine: questo indice → ROADMAP.md → ARCHITECTURE.md
→ DATABASE.md → DESIGN_DECISIONS.md → il documento del modulo interessato in modules/.
Regole di manutenzione
Ogni informazione ha una sola casa, per evitare che le copie divergano:
- l'elenco delle funzionalità (fatte e previste) sta solo in
ROADMAP.md; CHANGELOG.mdregistra quando qualcosa è stato rilasciato, non ripete l'elenco: segue il formato Keep a Changelog, con il lavoro non ancora rilasciato sotto[Non rilasciato]e le voci divise per categoria (Aggiunto, Modificato, Sicurezza…);- il lavoro in corso sta solo in
PROJECT_STATE.md, che rimanda alla roadmap per il resto; - lo schema del database sta solo in
DATABASE.md, allineato alle migration insupabase/migrations/: una tabella nuova si documenta nella stessa modifica che la crea; - le motivazioni stanno solo in
DESIGN_DECISIONS.md, in vociDD-XXX; per aggiungerne una si copia _template-dd.md.
Convenzioni di scrittura: un solo titolo # per file (le sezioni interne partono da ##),
niente --- come riempitivo tra i paragrafi, tabelle al posto degli elenchi ripetitivi.