Il badge Pagellone si sblocca ora solo con almeno 5 pagelle ricevute
(VOTI_MINIMI_PAGELLA): un voto solo poteva sbloccarlo o farlo sparire senza
significatività statistica. Aggiunto Giocatore.votiPagella per farlo funzionare.
La migration m13 (DD-027) estende le policy RLS di M11 su pagelle_voti, mvp_voti e
badge_social_voti: votante e votato devono essere convocati all'evento (prima solo
un filtro applicativo), e per le pagelle anche pagelle_chiuse=false. Le policy
admin restano permissive di proposito. Applicata anche al progetto cloud.
Copertura test completa: unit sulla soglia minima, integration sulle nuove policy
RLS (permessi.test.ts) e un end-to-end reale (pagella-badge.test.ts) sul modello
di mvp-badge.test.ts.
Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
Il bullet MVP ripeteva per intero il meccanismo di voto già documentato in mvp.md
(e con un'imprecisione: l'RLS di m11 non è una barriera contro l'autovoto, impedisce
solo di votare a nome di un altro). Ora rimanda a mvp.md e tiene solo ciò che serve
a capire il badge. Tolto anche il bullet iniziale sui segreti, che ripeteva parola
per parola l'intro della sezione "Elenco badge".
Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
Aggiunge il caso positivo RLS mancante per mvp_voti in permessi.test.ts e un nuovo
test end-to-end (mvp-badge.test.ts) che verifica l'intera pipeline voti reali ->
mvpVintiPerGiocatore() -> statoBadge(). docs/modules/badge.md ora elenca tutti e 16
i badge con come funzionano, la copertura test badge per badge e i due problemi
minori trovati in audit (badgeSbloccati() morta, categoria senza vincolo DB).
Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
Rende la doc autosufficiente: tabella completa dei 10 obiettivi con id, calcolo
e target; sezione dedicata alla dipendenza dal JSON CSI per le vittorie (o3/o4/o5)
con il limite del parsing silenzioso e i passi per fixarlo se il portale cambia
formato; tabella di copertura test per ogni obiettivo con i file esatti.
Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
o5 non aveva il Math.min(vittorie, 10) dei fratelli o3/o4: il progresso
mostrato non cambiava (già cappato al 100%), ma il valore grezzo sì, mostrato
senza cap in squadra.tsx/index.tsx (es. "15/10 vittorie" invece di "10/10").
Nessuno dei tre obiettivi aveva test. Le vittorie non toccano Supabase -
arrivano dal portale CSI via /api/public/csi - quindi l'integration test
estende test/integration/api.test.ts (che già chiama quella route dal vivo)
invece di test/integration/obiettivi.test.ts, verificando o3/o4/o5 sui dati
CSI reali del giorno.
Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
Le vittorie in campionato dipendono dal JSON delle partite (non dalla
classifica HTML, come erroneamente documentato prima). Se quel formato cambia,
il parsing fallisce in silenzio: nessun errore, nessuna notifica, le vittorie
restano ferme a 0% finché qualcuno non se ne accorge per caso.
Aggiunta partiteFormatoSospetto() in csi-core.ts: confronta gli eventi grezzi
con il risultato del parsing per distinguere un vero "formato cambiato" da un
legittimo "nessuna gara ancora in programma". La route logga l'errore server e
il flag arriva fino a /classifica, dove sostituisce la riga "Dati CSI
aggiornati alle..." con un badge discreto color warning - visibile a chi apre
la pagina, senza notifiche invasive.
Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
Il target 12 non è un valore arbitrario da scalare con la rosa come gli altri
target fissi: è il minimo di giocatori per schierare due sestetti (6vs6) in
allenamento, confermato intenzionale. Documentato in
docs/modules/obiettivi-squadra.md.
Non aveva alcun test. Aggiunti unit test (rosa vuota, confine >= 3, target
fisso) e un integration test end-to-end che scrive tre allenamenti e presenze
reali sul database locale, calcola serieConsecutiva() (la stessa funzione pura
usata da useRosa() in produzione) sui dati riletti, e verifica il conteggio.
Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
C'era una sola asserzione (2 pagelle -> 2), nessun caso vuoto esplicito e
nessun integration test. Aggiunti il caso vuoto, il conteggio aggregato su
più match_id, e l'assert su o13 nell'integration test già scritto per la
media pagelle (stessi voti reali scritti su pagelle_voti, zero setup extra).
Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
o1 e o2 avevano solo test con un evento singolo per volta: mancavano rosa vuota
(divisione per zero), verifica che le partite contino come gli allenamenti con
eventi sociali/compleanni esclusi, e l'aggregazione su più eventi dello stesso
mese. Aggiunti unit e integration test per entrambi.
"Media pagelle da 7.5" aveva solo il caso vuoto e un caso che faceva già media
esatta: aggiunti test sull'arrotondamento a una cifra decimale e
sull'aggregazione di voti da più partite, più un integration test che scrive
voti veri su pagelle_voti rispettando i vincoli reali della tabella.
Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
C'era solo un confronto circolare (la stessa formula ricalcolata sugli stessi
dati reali) più il caso rosa vuota. Aggiunto un unit test con roster piccolo e
valori noti (5 + 10 + 15 = 30), e un integration test end-to-end che scrive
eventi/risposte veri sul database locale, calcola contaPresenzeGiocatore() (la
stessa funzione pura usata da useRosa() in produzione) sui dati riletti, e
verifica che obiettiviSquadra() sommi correttamente il risultato.
Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
La scadenza era una data fissa (2026-09-30), stesso problema già risolto per
"presenze del mese" e "evento di squadra al mese": ora segue l'ultimo giorno
del mese corrente. Aggiunti unit test e integration test end-to-end contro il
database locale (isolando gli eventi di test, perché questo obiettivo aggrega
su tutti gli eventi indipendentemente dal mese).
Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
"Presenze del mese" e "evento di squadra al mese" erano ancorati a una costante
MESE = "2026-08": passato agosto restavano congelati sul mese scorso invece di
azzerarsi a ogni cambio mese. Ora il mese di riferimento (e per il primo anche
titolo e scadenza) segue la data corrente, con un parametro `oggi` iniettabile
per test deterministici. Aggiunti unit test e un integration test end-to-end
contro il database locale.
Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
Nessuna rotta aveva preload configurato: il chunk JS di una pagina iniziava a
scaricarsi solo a tap completato, mai prima. Con 4 tab piccole (8-12KB l'una) e
sempre visibili, non c'e' motivo di aspettare il tap per iniziare.
preload="intent" sui 4 Link: parte al touchstart, prima che il tap sia completo.
Precarica solo il codice, non i dati (nessuna rotta usa loader), quindi nessun
costo aggiuntivo di letture verso Supabase.
Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
EventoCard monta un hook per ogni card mostrata: usava useGiocatoreCorrente
(= useIo = useRosa, le 6 statistiche pesanti) solo per leggere il proprio id.
Il Calendario ne rende diverse insieme (prossimi eventi, compleanni, drawer del
giorno), quindi ogni apertura moltiplicava il ricalcolo dell'intera rosa.
Audit di tutti gli altri usi di useGiocatoreCorrente: 12 su 13 leggevano solo
id/nome/verita', mai una statistica. Corretti allo stesso modo (-> useGiocatoreBase):
benvenuto.tsx, VotazioneMvp, SondaggioCacche, VotoSocial, eventi.tsx,
PromemoriaPalloni (Home), TurnoPalloni, ScoutEntry, Pagelle.
partita.$id.tsx: `io` era dichiarato e mai piu' usato, rimosso.
Stesso pattern trovato anche su useRosa (non solo useGiocatoreCorrente) in
scout.tsx e RosaPresenze.tsx (montata su partita e allenamento): entrambi
passati al nuovo useAnagraficaRosa, esteso con ruolo e numero.
Unica eccezione: CelebrazioneBadge.tsx usa davvero le statistiche complete
(badge, MVP, serie) ed e' montato globalmente in __root.tsx - non downgradabile,
resta il costo di base piu' alto rimasto in giro.
Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
LinkProfilo (header di ogni pagina) e il Calendario (compleanni del mese) usavano
useIo/useRosa, che calcola MVP, pagelle, cacche, palloni e infortuni per l'intera
squadra tramite 6 hook e un useMemo pesante - anche se a entrambi serviva solo
id/nome/nascita/iniziali. Il Calendario in particolare pagava questo costo ad ogni
apertura solo per i compleanni del mese.
- crapp-data.ts: esporta inizialiDa, già usata internamente per il fallback avatar.
- ui-bits.tsx: LinkProfilo usa useGiocatoreBase (sola anagrafica) invece di useIo.
- rosa.ts: nuovo hook useAnagraficaRosa (id, nome, nascita) senza gli altri 5 hook
statistici ne' il useMemo su tutta la rosa.
- eventi.ts: compleanniEventi accetta solo i tre campi che usa, non l'intero
Giocatore.
- calendario.tsx: usa useAnagraficaRosa al posto di useRosa.
Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
- squadra.tsx e classifica.tsx: il contenuto di ogni tab di BarraSottosezioni è ora
memoizzato con useMemo, cosi' uno stato locale o un refetch in background non
ricalcolano piu' anche le sezioni nascoste.
- BottomNav, BarraSottosezioni, calendario: useMotoRidotto (RAM bassa o
prefers-reduced-motion) disattiva sui device deboli la catena di filtri SVG piu'
pesante di .vetro, il backdrop-blur della barra tab e il drag orizzontale;
su iOS e device performanti resta tutto invariato.
- styles.css: rimossa l'utility .materiale, orfana da quando BottomNav e' passata
a .vetro.
- ui-bits.tsx: decoding="async" su TeamLogo.
- todo.md: traccia le cause individuate e lo stato di applicazione di ciascuna.
Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
sondaggioAperto() restava aperto per sempre una volta passate le 8:00 del
giorno della partita, anche nei giorni successivi. Ora chiude esattamente
all'ora di inizio (partita alle 21:00 → aperto fino alle 20:59, poi chiuso
anche nei giorni seguenti), richiedendo anche l'ora dell'evento oltre alla
data.
Aggiunta sondaggioTerminato() per distinguere nel messaggio "non ancora
aperto" da "già chiuso": altrimenti dopo la partita l'utente avrebbe
continuato a leggere "apre alle 8:00".
Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
contaInfortuni()/contaRitardi() leggevano tutta la mappa presenze senza
guardare la data dell'evento: un giocatore può segnarsi infortunato o in
ritardo anche su un evento non ancora avvenuto (l'UI lo permette finché
l'evento non è passato), e quel conteggio arrivava subito ai badge segreti
"Infermeria" e "Ritardi". Ora filtrano su data < oggi, come già fa
eventiContanoPresenze() per le statistiche di presenza: con l'avanzare
della data reale l'evento prima futuro entra da solo nel conteggio.
Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
La select nativa e il bottone-drawer cambiavano lo stesso criterio in due modi
contemporaneamente, effetto ridondante e poco curato. Ora un'unica riga
tappabile mostra il criterio attivo e apre il drawer di scelta.
Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
La sola sottolineatura era troppo minimale sulla tab attiva. Ora è uno sfondo
pieno arrotondato come le pillole del Profilo, ma le tab restano giustificate
su tutta la larghezza dello schermo senza scroll orizzontale.
Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
L'elenco si basava solo sull'ordine cronologico dei prossimi eventi,
ignorando la risposta di presenza già data dall'utente.
Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
Card cliccabile con icone presenza compatte, senza barra percentuale; avatar home leggermente più grande.
Co-authored-by: Cursor <cursoragent@cursor.com>
conteggioTurni() contava ogni turno presente nella mappa, incluse le
assegnazioni anticipate per eventi futuri: un allenamento di lunedì con
turno già assegnato oggi (venerdì) veniva già sommato al badge "Sherpa dei
palloni" prima ancora di essersi svolto. Ora filtra su e.data < oggi, lo
stesso criterio già usato per presenze e serie — il turno resta assegnabile/
modificabile in anticipo, semplicemente non conta finché il giorno non arriva.
oggiISO() (palloni-core.ts) diventa un alias di dataOggi(): stessa correzione
di fuso della commit precedente, qui serviva anche per admin.tsx (scadenza
documenti/certificati) e cacche.ts (statistiche giornaliere), che la usano.
Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
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>
Coerente con lo stile dell'app (stesso componente Drawer usato per i badge)
invece del popup del browser: mostra il titolo dell'evento e richiede un
tocco esplicito su "Elimina" prima di procedere.
Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
Il redirect verso /benvenuto scattava se la rosa non era ancora arrivata dalla
rete, anche con sessione e profilo validi: caricare /eventi a freddo (refresh,
link diretto, riapertura della PWA) ti riportava sempre in Home. Ora si aspetta
il caricamento della rosa e si torna alla pagina di destinazione originale.
In Reveal, la soglia del 15% dell'altezza dell'elemento per attivare l'animazione
era irraggiungibile per una lista lunga (75 eventi = oltre 5700px): la sezione
restava invisibile per sempre, a qualunque scroll. La soglia ora è "some" (basta
un pixel visibile).
Aggiunta anche la gestione dell'errore sul caricamento eventi, che prima falliva
in silenzio mostrando una pagina vuota senza alcun messaggio.
Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
Il changelog aveva sezioni narrative sotto «Versione attuale», che non diceva
quale versione, e una «Versione 1.0 — luglio 2026» data per rilasciata mentre il
pacchetto è alla 0.9.0 ancora da distribuire. Ora la testa è
`[Non rilasciato] — 0.9.0` in formato Keep a Changelog: essendo la prima
versione tutto è Aggiunto, con la sola Sicurezza a parte — niente Modificato,
Rimosso o Corretto, che presuppongono qualcosa già uscito.
La roadmap perde i numeri di versione (1.0, 1.1, 1.2, 2.0) e diventa
Fatto / Prossimo / Idee future: numerava per traguardo funzionale mentre il
changelog numera i rilasci, e tenere allineate due numerazioni diverse per lo
stesso progetto è lavoro che nessuno farà. Le versioni ora stanno solo nel
changelog. Nessuna voce persa.
Aggiornati i rimandi rimasti indietro: la regola di manutenzione e l'indice in
docs/README.md, la citazione «CHANGELOG v1.0.6» e la nota su AI Allenamenti in
DESIGN_DECISIONS.md, «la v1.1 è completa» in PROJECT_STATE.md.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
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>
La votazione non dipendeva dal tempo ma dal risultato: compariva solo con un
referto CSI o uno scout salvato, e chiunque avesse un profilo poteva votare.
Ora `votoMvpAperto()` la apre due ore dopo `data`+`ora` dell'evento, il pannello
sta in una sezione sua e votano — e sono votabili — solo i presenti (o in
ritardo) di quell'evento.
I voti passano dall'id scout/CSI a quello dell'evento CrAPP: home e classifica
leggono il vincitore tramite la mappa data → evento che avevano già. Le regole
sono applicative, non RLS: chi scrive su PostgREST le aggira, come già annotato
tra i limiti noti del modulo.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Il nome era ancora `tanstack_start_ts`, quello dello starter da cui è nato il
progetto. Non lo vede nessun utente — il pacchetto è privato, e il nome che
leggono i giocatori sta in public/manifest.webmanifest e in __root.tsx — ma
è la prima riga che si apre guardando il repository.
Aggiornata anche la riga corrispondente in bun.lock, così il prossimo
`bun install` non ha niente da riscrivere. Nessuna dipendenza si risolve per
nome del workspace root: lint, test e build passano.
`package-lock.json` resta indietro di proposito: è fermo a fine agosto e il
progetto installa con bun.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Chiude i tre buchi di copertura rimasti dalla rilettura della documentazione:
comportamenti che la doc descrive come regole ma che nessun test verificava.
- conRisposta() esce da useSalvaPresenza e diventa una funzione pura in presenze.ts.
La mutation non rilegge dopo la scrittura, quindi la cache deve imitare il database:
l'istante si scrive solo se manca (??=) e il ritiro della risposta lo cancella. Erano
due dettagli che serie-presenze.md chiede di preservare e che un refactor poteva
perdere in silenzio, falsando la serie "Conferme 24h" fino al refresh successivo.
- permessi.test.ts copre ora anche il terzo gruppo di DD-023, le tabelle lasciate
aperte di proposito: scout_sessioni, scout_live, scout_partite e push_subscriptions.
Non dicono che sono sicure, dicono che sono aperte per scelta: se una prende un gate
nell'interfaccia, le policy devono seguirlo e questi casi vanno cambiati con loro.
- lettori-server.test.ts esegue leggiEventi() e leggiGiocatoriSquadra() sul database
locale, mettendo le credenziali in process.env prima della prima chiamata perché
supabaseAdmin nasce pigramente. Nessuna delle due controlla l'errore di PostgREST:
una colonna rinominata darebbe zero righe, zero destinatari e nessuna push, senza
che niente segnali il problema. Scrivendolo è emerso che eventi_app.note è NOT NULL,
mentre RigaEvento lo dichiara nullable.
PROJECT_STATE: m12_niente_autovoto è applicata in produzione dal 06/09/2026,
verificata con `npx supabase migration list` (23 migration, local = remote).
Co-Authored-By: Claude Opus 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>
Confrontando le funzioni esportate di src/lib/ con i riferimenti in test/,
le uniche funzioni pure ancora scoperte erano i conteggi presenze, tre
funzioni del calendario, i titoli MVP e i rifiuti della guardia notifiche.
- unit: contaPresenzeGiocatore e totaliEventiGiocatore, compleanniEventi,
convocatiEvento, eventoVuoto, mvpVintiPerGiocatore, e il nuovo
auth-route.test.ts sui 401 di richiediAdmin (DD-024);
- integration/permessi: badge_social_voti, che mancava tra le tabelle di M11,
e le deroghe "Gli admin gestiscono tutti/e ...", mai verificate finora.
Due modifiche al codice servivano per poter scrivere i test:
- presenze.ts: i conteggi leggevano la data da dataOggi() e non erano
verificabili; ora accettano oggi come parametro opzionale, come già
facevano serieConsecutiva e serieConferme. Toglie anche la dipendenza
dall'orologio che avrebbe cambiato i risultati dei test delle serie dal
10 settembre in poi;
- auth-route.server.ts: "Bearer .." passava il pre-check con tre segmenti
vuoti e arrivava fino alla chiamata di rete; ora i segmenti devono essere
non vuoti.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Era impalcatura per diagnosticare "le push non arrivano": ha fatto il suo
lavoro, la causa e' documentata nei limiti noti. Lasciare il pulsante avrebbe
tenuto in piedi anche la route push-prova e notificaDiProva, senza piu' nessuno
che le usa.
Via il pulsante, la funzione client, la route e i test che la coprivano. Resta
in git se dovesse servire di nuovo.
inviaPush continua a tornare { stato, corpo } e a loggare i rifiuti: serve alle
tre route che mandano notifiche, non solo alla prova.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Su Android non riceve la webapp installata: riceve Chrome, tramite Google Play
Services. Il WebAPK e' solo l'identita' con cui la notifica viene mostrata. Se
il sistema non puo' avviare Chrome, il messaggio resta in coda e compare tutto
insieme al lancio successivo — "arriva solo quando riapro l'app".
Verificato sul campo su Motorola: con Chrome vivo in secondo piano la push
arriva ad app chiusa e schermo bloccato, WebAPK compreso. Quindi server,
cifratura, service worker, permesso notifiche e canale erano gia' corretti e
l'unica condizione che fallisce e' Chrome non in esecuzione. Mettere "Senza
restrizioni" solo su CrAPP non basta e depista.
Documentato anche come misurarlo con chrome://gcm-internals, incluso il
tranello: tenere quella scheda aperta tiene Chrome vivo e falsa la prova.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Il pulsante si preme con l'app aperta, quindi la push arrivava sempre in primo
piano: l'unico caso che non serve provare. Ora la route aspetta `ritardoMs`
(10s di default, 25 al massimo) prima di inviare, e il toast dice di chiudere
l'app subito.
L'attesa tiene aperta la funzione, quindi il tetto e' la durata massima
concessa dall'hosting: annotato come ponytail nel codice.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
davideandClaude Sonnet 5