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/CHANGELOG.md

@@ -38,6 +38,9 @@ Prima versione, pre-release.
   della partita, e può usarlo chiunque sia autenticato: uno per volta, grazie al lock.
 - Votazione MVP legata all'evento CrAPP e non al referto CSI o allo Scout: si apre due ore
   dopo `data`+`ora` della partita, anche senza risultato caricato — [modules/mvp.md](modules/mvp.md).
+- Badge Pagellone: la media pagelle conta per il badge solo con almeno `VOTI_MINIMI_PAGELLA`
+  (5) voti ricevuti — prima un singolo voto poteva sbloccarlo o farlo sparire senza nessuna
+  significatività statistica — [modules/badge.md](modules/badge.md).
 - Sondaggio pre-partita aperto dalle 8:00 del giorno della partita fino al fischio d'inizio
   (poi resta chiuso, anche nei giorni successivi) e pulsante «Avvisa tutti del sondaggio» per
   gli amministratori (`POST /api/public/apri-sondaggio`); nessun cron, l'invio è manuale.
@@ -79,6 +82,10 @@ Prima versione, pre-release.
   `pagelle_voti`.
 - Al voto MVP partecipano solo i presenti (o in ritardo) di quell'evento; il filtro è
   applicativo, non RLS ([modules/mvp.md](modules/mvp.md)).
+- Migration `m13_convocati_e_pagelle_chiuse` (DD-027): la policy di M11 su `pagelle_voti`,
+  `mvp_voti` e `badge_social_voti` verifica ora anche che votante e votato siano tra i
+  convocati dell'evento, e per le sole pagelle che `pagelle_chiuse` sia falso — prima erano
+  filtri solo applicativi, aggirabili scrivendo direttamente su PostgREST.
 - La suite copre i rifiuti `401` di `richiediAdmin` (DD-024), i permessi di
   `badge_social_voti` e le deroghe admin di M11, e verifica che un ripensamento non riscriva
   `risposto_il` (trigger di `m9`).

docs/DATABASE.md

@@ -15,7 +15,7 @@ nessuna di esse da M4 (DD-011).
 | ---------------------------------------------------------------- | ------------------------------------------------------------------- |
 | `eventi_app`                                                     | solo admin (nell'app li gestisce la rotta `/eventi`, già riservata) |
 | `risposte_presenze`, `cacche_partita`                            | il giocatore sulla propria riga (`giocatore_id`), più gli admin     |
-| `pagelle_voti`, `mvp_voti`, `badge_social_voti`                  | il votante sui propri voti (`votante_id`), più gli admin            |
+| `pagelle_voti`, `mvp_voti`, `badge_social_voti`                  | il votante sui propri voti (`votante_id`), se votante e votato sono convocati all'evento (`m13`); solo per le pagelle anche `pagelle_chiuse = false`; gli admin senza questi vincoli |
 | `turni_palloni`, `scout_sessioni`, `scout_live`, `scout_partite` | qualsiasi autenticato: nell'interfaccia non hanno gate              |
 | `profili_giocatore`                                              | il giocatore sul proprio profilo, admin su tutti (DD-016, DD-017)   |
 | `giocatori_squadra`                                              | admin; il giocatore può solo reclamare uno slot libero (DD-016)     |
@@ -63,9 +63,9 @@ La tabella è verificata da `test/integration/permessi.test.ts` contro il databa
 
 | Tabella             | Scopo                                | Note                                                                                                               |
 | ------------------- | ------------------------------------ | ------------------------------------------------------------------------------------------------------------------ |
-| `mvp_voti`          | Voti MVP assegnati a fine partita.   | Un voto per votante e partita; auto-voto rifiutato (`mvp_no_autovoto`, migration `m12_niente_autovoto`).           |
-| `pagelle_voti`      | Voti anonimi assegnati ai giocatori. | Usati per il voto medio. Voto 1-10 e auto-voto rifiutato dai vincoli della v1.0.                                   |
-| `badge_social_voti` | Voti social per i badge.             | Un voto per categoria, votante e partita; auto-voto rifiutato (`badge_social_no_autovoto`, `m12_niente_autovoto`). |
+| `mvp_voti`          | Voti MVP assegnati a fine partita.   | Un voto per votante e partita; auto-voto rifiutato (`mvp_no_autovoto`, migration `m12_niente_autovoto`); votante e votato devono essere convocati all'evento (RLS, `m13_convocati_e_pagelle_chiuse`).           |
+| `pagelle_voti`      | Voti anonimi assegnati ai giocatori. | Usati per il voto medio. Voto 1-10 e auto-voto rifiutato dai vincoli della v1.0; votante/votato convocati e `pagelle_chiuse = false` richiesti dalla RLS di `m13_convocati_e_pagelle_chiuse`.                                   |
+| `badge_social_voti` | Voti social per i badge.             | Un voto per categoria, votante e partita; auto-voto rifiutato (`badge_social_no_autovoto`, `m12_niente_autovoto`); votante e votato devono essere convocati all'evento (RLS, `m13_convocati_e_pagelle_chiuse`). |
 
 ## Turni e notifiche
 

docs/DESIGN_DECISIONS.md

@@ -42,6 +42,7 @@ Serve a rispondere a domande del tipo:
 | [DD-024](#dd-024--le-route-che-avvisano-la-squadra-chiedono-le-credenziali)       | Route di notifica autenticate         |
 | [DD-025](#dd-025--il-promemoria-palloni-lo-manda-ladmin-per-un-evento)            | Promemoria palloni manuale            |
 | [DD-026](#dd-026--il-testo-della-notifica-viaggia-dentro-la-push)                 | Payload push cifrato                  |
+| [DD-027](#dd-027--chi-vota-deve-essere-convocato-non-solo-autenticato-come-sé-stesso) | Voto limitato ai convocati            |
 
 **In valutazione**
 
@@ -970,3 +971,56 @@ prima di inviare.
 **Riesame**  
 Se servisse mandare payload più grandi del limite del protocollo, o se un servizio push
 smettesse di accettare corpi cifrati (nessuno lo fa: è lo standard).
+
+### DD-027 — Chi vota deve essere convocato, non solo autenticato come sé stesso
+
+**Stato:** accettata · **Data:** 8 settembre 2026
+
+**Contesto**  
+Un audit del modulo Badge (`docs/modules/badge.md`) ha trovato due filtri rimasti solo
+applicativi dopo DD-023: la policy di M11 garantisce che `votante_id` sia lo slot collegato
+all'account di chi scrive, ma non controlla che **votante e votato fossero convocati**
+all'evento — un utente che scrive direttamente su PostgREST (bypassando l'interfaccia) poteva
+votare o essere votato in una partita a cui non aveva partecipato, gonfiando `mediaVoto`,
+`mvp` o un badge social a piacere. Allo stesso modo, `eventi_app.pagelle_chiuse` nascondeva
+solo i bottoni in UI: un voto pagella "fuori tempo" restava tecnicamente possibile.
+
+**Decisione**  
+La policy "Ognuno gestisce i propri voti ..." di `pagelle_voti`, `mvp_voti` e
+`badge_social_voti` (M11) guadagna un controllo aggiuntivo tramite la funzione
+`evento_permette_voto()` (migration `m13_convocati_e_pagelle_chiuse`): verifica che sia
+`votante_id` sia `votato_id` compaiano in `eventi_app.convocati` per quel `match_id`
+(`convocati` vuoto = tutta la rosa, la stessa convenzione di `convocatiEvento()` in
+`eventi.ts`), e — solo per le pagelle — che `pagelle_chiuse` sia falso. Le policy admin
+restano invariate e permissive: un amministratore deve poter correggere un voto anche fuori
+convocazione o dopo la chiusura.
+
+Il controllo si ferma alla **convocazione**, non alla **presenza reale**: per l'MVP, ad
+esempio, l'interfaccia limita già il voto ai soli presenti/in ritardo
+(`usePresenzeEvento`), un filtro più stretto che resta solo applicativo — un convocato ma
+assente passa ancora a livello database. Stringere fino a quel punto avrebbe richiesto
+leggere `risposte_presenze` dentro la policy, un salto di complessità non giustificato
+dall'audit che ha originato questa decisione.
+
+**Alternative scartate**
+
+- Un trigger `BEFORE INSERT/UPDATE` invece di RLS → si applicherebbe anche alla service key
+  e agli admin, bloccando correzioni legittime fuori convocazione; la RLS, applicata solo
+  alla policy non-admin, li esclude naturalmente.
+- Controllare anche la presenza reale (`risposte_presenze`), non solo la convocazione →
+  scope maggiore del gap trovato in audit, e specifico dell'MVP (pagelle e badge social non
+  hanno un concetto di "presente" distinto da "convocato" nell'interfaccia attuale).
+
+**Conseguenze**
+
+- Un evento senza `convocati` esplicito (lista vuota, il caso più comune oggi) non cambia
+  comportamento: tutta la rosa resta votabile, come prima.
+- I test di `test/integration/permessi.test.ts` sono la definizione eseguibile anche di
+  questa parte della tabella dei permessi (voti non convocati rifiutati, `pagelle_chiuse`
+  rifiutata a database, controlli positivi che provano che un voto legittimo passa ancora).
+- Resta un gap conosciuto e documentato (non quello risolto qui): che il votante fosse
+  davvero presente, non solo convocato, per MVP/pagelle/badge social.
+
+**Riesame**  
+Se un giorno servisse bloccare anche il voto di un convocato-ma-assente a livello database,
+non solo in UI.

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.