Sistema i buchi del badge Pagellone: soglia minima voti e voto limitato ai convocati

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>

docs/modules/badge.md

@@ -31,8 +31,16 @@ badge assegnati per voto dai compagni.
   inclusive, vince l'ultima raggiunta o superata. Per la maggior parte dei badge il valore è
   già pronto: `Giocatore` arriva da `useRosa()` con presenze, palloni, serie, infortuni,
   ritardi, cacche e media pagelle già calcolati da altri moduli — `badges.ts` si limita a
-  confrontarli con le soglie. Fanno eccezione, con logica propria descritta sotto, l'MVP e i
-  badge social.
+  confrontarli con le soglie. Fanno eccezione, con logica propria descritta sotto, il
+  Pagellone, l'MVP e i badge social.
+- **Badge Pagellone** (`pagella`, in `badgeDefs`): a differenza degli altri badge da
+  contatore, richiede un numero minimo di voti (`VOTI_MINIMI_PAGELLA = 5`, `badges.ts`) prima
+  che `g.mediaVoto` conti — sotto soglia `valore(g)` è forzato a `0` (badge bloccato), anche
+  con una media altissima. Aggiunto perché senza minimo un singolo voto poteva
+  sbloccare/far sparire il badge senza nessuna significatività statistica (vedi
+  [pagelle.md](pagelle.md) per la pipeline voto → media, qui non ripetuta). Il numero di voti
+  ricevuti arriva in `Giocatore.votiPagella` (`rosa.ts`), popolato insieme a `mediaVoto` dalla
+  stessa `mediePagelle()`.
 - **Badge social** (`badge-social.ts`, tabella `badge_social_voti`): 5 categorie fisse per
   partita ("Compagno affidabile", "Miglior spirito di squadra", "Fair play", "Meme della
   partita", "Cuore del gruppo"), votabili una volta a testa per categoria/partita
@@ -72,7 +80,7 @@ soglia raggiunta o superata (soglie inclusive), oltre l'oro resta oro.
 | id | nome | come si guadagna | soglie B/A/O |
 | --- | --- | --- | --- |
 | `mvp` | MVP | partite vinte nettamente al voto MVP dei compagni (`g.mvp`, vedi pipeline sopra) | 1 / 3 / 5 |
-| `pagella` | Pagellone | media dei voti pagella ricevuti dai compagni a fine partita (`g.mediaVoto`) | 6.5 / 7.5 / 8.5 |
+| `pagella` | Pagellone | media dei voti pagella ricevuti dai compagni a fine partita (`g.mediaVoto`), solo se ne ha ricevuti almeno `VOTI_MINIMI_PAGELLA` (5) | 6.5 / 7.5 / 8.5 |
 | `palloni` | Sherpa dei palloni | quante volte ti sei incaricato di portare la sacca palloni (`g.palloni`) | 3 / 6 / 10 |
 | `presenze` | Presenza fissa | totale presenze a eventi/partite in stagione (`g.presenze`) | 5 / 15 / 30 |
 | `serie-allenamenti` | Sempre in palestra | allenamenti consecutivi presenti, senza saltarne uno (`g.serieAllenamenti`) | 3 / 6 / 10 |
@@ -126,18 +134,17 @@ categoria): nessun bug trovato nella logica di calcolo di nessuno dei 16 badge.
 **Badge normali** — `badges.ts` testa la propria funzione pura (soglia → grado,
 `badges.test.ts`) sull'output di altri moduli:
 - `mvp`: soglie inclusive verificate (1→bronzo, 3→argento, 99→resta oro,
-  `badges.test.ts:44-48`), progresso a metà (`:52-56`). **Unico badge normale con integration
-  dedicato** (vedi sotto) perché la sua fonte, a differenza degli altri 5, passa da un'altra
-  tabella di voto (`mvp_voti`) invece che da un contatore già calcolato altrove.
+  `badges.test.ts:44-48`), progresso a metà (`:52-56`).
 - `pagella`: caso critico delle soglie decimali senza arrotondamento per eccesso — 6.4 →
   nessun grado, 6.5 → bronzo (`badges.test.ts:65-67`); un vero 6.49 non diventa "quasi
-  bronzo".
+  bronzo". Più la soglia minima di voti (vedi sotto).
 - `palloni`, `presenze`, `serie-allenamenti`, `serie-conferme`: stessa funzione di soglia già
   testata a fondo su `mvp`/`pagella`, coperti dagli invarianti generali
   (`badges.test.ts:154-159`: soglie crescenti, testi presenti, id unici) e da
   `collezioneBadge`/`prossimoTraguardo` con valori al massimo (`:119-144`).
-- Nessun integration dedicato per questi 5: non toccano il database, le statistiche sorgente
+- Nessun integration dedicato per questi 4: non toccano il database, le statistiche sorgente
   (`presenze.test.ts`, `palloni-core.test.ts`, ecc.) sono già coperte nei rispettivi moduli.
+  `mvp` e `pagella` fanno eccezione (sotto) perché la loro fonte passa da una tabella di voto.
 
 **Badge segreti** — ognuno testato con la propria condizione esatta e il confine appena sotto
 (`badges.test.ts:77-109`): `s-tiebreak` (mediaVoto 7.9 non basta, serve 8), `s-mai-forfait`
@@ -154,12 +161,29 @@ copertura di questo badge):
     partita/votante, l'ultimo sostituisce) e rifiuto dell'autovoto a database
     (`mvp_no_autovoto`).
   - `permessi.test.ts` — RLS di `m11`: il proprio voto MVP si registra (caso positivo), non
-    si può votare a nome di un altro (caso negativo).
+    si può votare a nome di un altro (caso negativo); RLS di `m13` (sotto): un votante o un
+    votato non convocati vengono rifiutati.
   - `mvp-badge.test.ts` — end-to-end reale: scrive voti su `mvp_voti`, rilegge via REST come
     fa `useVotiMvp()`, calcola `mvpVintiPerGiocatore()` e verifica che `statoBadge()` assegni
     il grado corretto (bronzo a 1-2 vittorie nette, argento a 3), incluso un pareggio che non
     deve contare come vittoria.
 
+**Badge Pagellone — pipeline end-to-end e soglia minima di voti** (stessa sessione di sopra,
+dopo l'analisi che ha trovato il gap "un voto solo sblocca il badge"):
+- Unit: `badges.test.ts:69-88` — sotto `VOTI_MINIMI_PAGELLA` (5) il badge resta bloccato anche
+  con `mediaVoto: 10`; esattamente a 5 la media torna a contare; sopra soglia valgono le
+  normali soglie di grado (`mediaVoto: 6.5` con 5 voti → bronzo, non oro).
+- Integration (`npx supabase start` richiesto):
+  - `scritture.test.ts` — semantica dell'`upsert` di `pagelle_voti` e rifiuto dell'autovoto
+    (`pagelle_no_autovoto`), già presente prima di questa sessione.
+  - `permessi.test.ts` — RLS di `m13`: un votante o un votato non convocati vengono rifiutati
+    (per tutte e tre le tabelle di voto, non solo le pagelle), e un voto pagella dopo
+    `pagelle_chiuse` viene rifiutato anche a database, non solo nascosto in UI.
+  - `pagella-badge.test.ts` (nuovo) — end-to-end reale: scrive voti su `pagelle_voti`, rilegge
+    via REST come fa `usePagelle()`, calcola `mediePagelle()` e verifica che `statoBadge()`
+    tenga il badge bloccato sotto soglia, lo sblocchi al voto minimo con il grado giusto, e
+    applichi le soglie normali sopra soglia.
+
 **Badge social** — nessuna delle 5 categorie ha logica *propria* nel codice: l'id è solo una
 chiave di raggruppamento, `conteggioCategoria`/`vincitoreCategoria`/`badgeSocialVinti` sono
 identici per tutte (`badge-social.ts:107-158`). Testare a fondo 2-3 categorie copre l'intero
@@ -176,7 +200,7 @@ meccanismo:
 | # | id | tipo | test unit | test integration |
 | - | --- | --- | --- | --- |
 | 1 | `mvp` | normale | ✅ | ✅ (`scritture`, `permessi`, `mvp-badge`) |
-| 2 | `pagella` | normale | ✅ | non necessario |
+| 2 | `pagella` | normale | ✅ (incl. soglia minima voti) | ✅ (`scritture`, `permessi`, `pagella-badge`) |
 | 3 | `palloni` | normale | ✅ | non necessario |
 | 4 | `presenze` | normale | ✅ | non necessario |
 | 5 | `serie-allenamenti` | normale | ✅ (limite noto sotto) | non necessario |
@@ -219,12 +243,19 @@ Trovati in audit, nessuno bloccante (nessun bug nella logica di calcolo):
   risposte precedenti a `m9`: su quelle righe la serie è un'approssimazione.
 - Nessuno storico dei badge sbloccati: se cambiano le soglie o i dati sorgente, un badge già
   "ottenuto" può sparire o apparire retroattivamente.
-- La policy di M11 garantisce che il voto sia firmato con il proprio `votante_id`, ma non
-  che il votato sia un giocatore convocato per quella partita: quello resta un filtro solo
-  applicativo (vale per MVP, pagelle e badge social).
 - Notifiche "nuovo badge" solo locali al dispositivo (localStorage), si ripetono cambiando
   browser o dispositivo.
 
+**Risolto (M13, `20260908120000_m13_convocati_e_pagelle_chiuse.sql`)**: prima la policy di M11
+garantiva solo che il voto fosse firmato con il proprio `votante_id`, non che il votato (né il
+votante) fossero convocati per quella partita — filtro solo applicativo, aggirabile scrivendo
+direttamente su PostgREST. Ora `evento_permette_voto()` lo verifica anche a database per
+`pagelle_voti`, `mvp_voti` e `badge_social_voti` (convocati vuoto = tutta la rosa, stessa
+convenzione di `convocatiEvento()`), e per le sole pagelle verifica anche che
+`eventi_app.pagelle_chiuse` sia falso — prima un voto "fuori tempo" restava tecnicamente
+possibile bypassando l'interfaccia. Le policy admin restano permissive: un amministratore può
+ancora correggere un voto anche fuori convocazione o dopo la chiusura.
+
 ---
 
 ## Evoluzioni possibili

docs/modules/mvp.md

@@ -48,9 +48,15 @@ restano nel database ma non vengono più letti da nessuna schermata).
 - Nessuna scadenza o chiusura della votazione: una volta aperta resta aperta indefinitamente.
 - Il voto è legato a chi lo scrive: da `m11_scritture_per_ruolo` la policy impone che
   `votante_id` sia lo slot collegato all'account (DD-023). Su chi viene votato l'unico
-  vincolo è che non sia il votante stesso (`mvp_no_autovoto`): che votante e votato fossero
-  presenti a quella partita, e che siano passate due ore dall'inizio, restano filtri solo
-  applicativi — chi scrive su PostgREST li aggira.
+  vincolo diretto è che non sia il votante stesso (`mvp_no_autovoto`).
+  Da `m13_convocati_e_pagelle_chiuse` la stessa policy verifica anche che **sia il votante sia
+  il votato** siano tra i **convocati** dell'evento (`evento_permette_voto()`, convocati vuoto
+  = tutta la rosa): prima era un filtro solo applicativo, ora un giocatore non convocato non
+  può più votare né essere votato scrivendo direttamente su PostgREST. Restano invece solo
+  applicativi, non controllati da nessuna policy: che votante e votato fossero **presenti**
+  (non solo convocati: `presente`/`ritardo` in `usePresenzeEvento`, un controllo più stretto
+  della sola convocazione) a quella partita, e le due ore d'attesa dall'inizio evento
+  (`votoMvpAperto()`) — un amministratore, o chiunque scriva su PostgREST, passa comunque.
 - In caso di parità, nessun MVP viene assegnato per quella partita.
 
 ---

docs/modules/pagelle.md

@@ -29,9 +29,13 @@ UI), `UNIQUE (match_id, votante_id, votato_id)`.
 - `useVotaPagella()` fa un upsert su `(match_id, votante_id, votato_id)`: si può votare più
   volte, l'ultimo voto sovrascrive il precedente.
 - `mediePagelle()` calcola la media aritmetica (arrotondata a un decimale) per giocatore su
-  tutti i voti della stagione; `pagellePartita()` la calcola per singola partita;
-  `mediaSquadra()` su tutti i voti di tutti — mostrata come StatTile in `squadra.tsx`.
-- `useRosa()` inietta la media stagionale nel campo `mediaVoto` di ogni giocatore.
+  **tutti i voti mai ricevuti** — l'app non ha un concetto di stagione/reset, quindi non è
+  "la media di questa stagione" ma lo storico completo; `pagellePartita()` la calcola per
+  singola partita; `mediaSquadra()` su tutti i voti di tutti — mostrata come StatTile in
+  `squadra.tsx`.
+- `useRosa()` inietta questa media storica nel campo `mediaVoto` di ogni giocatore, insieme al
+  numero di voti ricevuti (`votiPagella`) — usato dal badge Pagellone (vedi
+  [badge.md](badge.md)) per richiedere un minimo di voti prima che la media conti.
 
 ---
 
@@ -39,25 +43,27 @@ UI), `UNIQUE (match_id, votante_id, votato_id)`.
 
 - Anti auto-voto imposto anche a livello database (constraint, non solo filtro UI).
 - L'admin può marcare un evento come `pagelleChiuse` (`eventi.ts`), che nasconde i bottoni di
-  voto in UI.
+  voto in UI **e**, da M13, rifiuta anche a database un voto scritto dopo la chiusura (RLS
+  `evento_permette_voto()`, `pagelle_voti`).
+- Da M13 anche il votante e il votato devono essere convocati all'evento: verificato a
+  database, non solo in UI (stessa RLS di sopra).
 
 ---
 
 ## Limiti noti
 
-- **`pagelleChiuse` è solo un flag UI**: nessuna policy RLS lo controlla, quindi un voto
-  "fuori tempo" resta tecnicamente possibile bypassando l'interfaccia.
 - **L'anonimato è solo applicativo, non tecnico**: la riga salvata contiene sia `votante_id`
   sia `votato_id`, leggibili da chiunque sia autenticato (policy SELECT aperta). La UI non
   mostra mai il votante, ma il dato non è né aggregato né mascherato lato server.
-- Nessun controllo a livello database che il votante sia realmente un convocato della
-  partita: solo filtro applicativo.
-- La media non richiede un numero minimo di voti: con un solo voto ricevuto, la media
-  coincide con quel voto.
+- La media mostrata nel profilo non richiede un numero minimo di voti: con un solo voto
+  ricevuto, la media coincide con quel voto. Il badge Pagellone (`badge.md`) applica invece un
+  minimo di voti prima di considerarla — la StatTile del profilo no.
+- Le due regole di M13 (convocazione, `pagelle_chiuse`) valgono solo per la policy "Ognuno
+  gestisce i propri voti pagella": un amministratore può ancora correggere un voto fuori
+  convocazione o dopo la chiusura, di proposito (deve poter sistemare un errore).
 
 ---
 
 ## Evoluzioni possibili
 
 - Una RPC o vista che nasconda `votante_id` per un anonimato garantito anche lato dati.
-- Far rispettare `pagelleChiuse` anche via RLS.