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>
L'evento in cui il giocatore risulta infortunato viene ora escluso a monte dal
calcolo di serieConsecutiva() (come già succede per gli eventi senza creatoIl
in serieConferme()): non conta né come presenza né come buco, la serie resta
al valore precedente. contaPresenzeGiocatore() non cambia: infortunato continua
a non contare come presenza nelle statistiche.
Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
Rilettura completa della documentazione confrontata con il codice. Dove la doc
diceva il falso l'ho corretta; dove aveva ragione lei ho corretto il codice.
Autovoto (la doc aveva ragione)
- migration m12_niente_autovoto: vincoli mvp_no_autovoto e badge_social_no_autovoto,
gli stessi che pagelle_voti ha dalla v1.0. Le righe che li violano vengono
cancellate prima dell'ALTER, altrimenti fallisce; in locale non ce n'erano.
M11 garantisce solo che il voto sia firmato con il proprio votante_id, non che il
votato sia un altro: eleggersi MVP restava a un POST di distanza.
- VotazioneMvp non mostra più il votante nell'elenco, come già faceva VotoSocial.
Test che guardavano la colonna sbagliata
- scritture.test.ts verificava che aggiornato_il si muovesse, chiamandolo "quello che
alimenta la serie di conferme". È l'opposto: la serie usa risposto_il, che il trigger
di M9 deve tenere fermo. Ora il test prova a riscriverlo e controlla che il database
abbia tenuto la prima risposta; prima passava anche senza trigger.
- destinatariSollecito() esce dalla route sollecita-presenze e diventa una funzione pura
in presenze.ts, con i suoi test — stesso trattamento di avvisiPalloniEvento.
Tre riletture in meno
- giocatori-squadra, scout-store e avatar-store usavano invalidateQueries dove il dato
scritto era già noto: ora setQueryData, come il resto dell'app. Resta scout-live, dove
il lock può averlo vinto un altro dispositivo.
Documentazione riallineata
- presenze.md, badge.md, mvp.md: i limiti su RLS aperta e route non autenticata erano
superati da M11 e DD-024;
- serie-presenze.md: il filtro è e.data < oggi, non <=, e l'evento di oggi non conta
(conterebbe come assenza per tutti); aggiunta la tabella risposto_il/aggiornato_il;
- ARCHITECTURE.md ed EFFICIENZA_CLOUD.md: una sola eccezione a setQueryData;
- DATABASE.md: i vincoli delle tre tabelle di voto;
- PROJECT_STATE.md: fermo a M9, ora arriva a M12.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
I tre contatori (serieAllenamenti, seriePartite, serieConferme) e streak erano
zero fisso in useRosa(): la sezione Serie di presenze del profilo mostrava sempre
progresso nullo, i badge legati alla costanza erano impossibili da sbloccare e
l'obiettivo Continuita di squadra restava a 0/12.
serieConsecutiva() e serieConferme() (src/lib/presenze.ts) derivano le serie dagli
eventi passati e da risposte_presenze gia in cache, senza query aggiuntive.
Migration m9: nuova colonna risposto_il con l'istante della prima risposta, resa
immutabile da un trigger, confrontata con eventi_app.creato_il per le conferme
entro 24 ore. Serviva perche aggiornato_il registra l'ultima modifica, quindi chi
rispondeva subito e cambiava idea dopo risultava lento.
Corregge anche la barra di progresso, che misurava valore/prossimo e tornava
indietro a ogni traguardo raggiunto (2/3 = 67%, poi 3/6 = 50%).
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Presenze, Serie di presenze, Scout Live, Pagelle, MVP, Badge, Palloni,
Obiettivi di squadra, Infortuni, Notifiche: chiudono il debito di
documentazione tracciato in TODO.md (DD-002). Le sei route API
pubbliche vengono descritte dentro il modulo a cui appartengono.
davideandClaude Sonnet 5