Vieta l'autovoto, allinea la doc al codice e toglie tre riletture.

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>

docs/modules/badge.md

@@ -33,7 +33,8 @@ badge assegnati per voto dai compagni.
 - **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
-  (modificabile), con **auto-voto escluso sia in UI sia in logica** (`VotoSocial.tsx`). A
+  (modificabile), con **auto-voto escluso in interfaccia** (`VotoSocial.tsx`) e rifiutato dal
+  database (vincolo `badge_social_no_autovoto`, migration `m12_niente_autovoto`). A
   differenza delle [Pagelle](pagelle.md), qui non c'è alcun tentativo di anonimato:
   `votante_id`/`votato_id` sono entrambi visibili.
 - `CollezioneBadge.tsx` mostra sbloccati, in progresso, badge social vinti e un contatore di
@@ -63,8 +64,9 @@ badge assegnati per voto dai compagni.
   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.
-- RLS permissiva su `badge_social_voti` (stesso schema di `mvp_voti`): nessun controllo
-  server-side che `votante_id` coincida con l'utente autenticato.
+- 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.
 - Notifiche "nuovo badge" solo locali al dispositivo (localStorage), si ripetono cambiando
   browser o dispositivo.
 

docs/modules/mvp.md

@@ -25,6 +25,9 @@ partita, sovrascrivibile.
   per la partita, altrimenti mostra "la partita non è ancora stata disputata".
 - `useVotaMvp()` fa upsert `onConflict: match_id, votante_id`: il voto è modificabile senza
   limiti, senza storico.
+- Nessuno vota sé stesso: `VotazioneMvp.tsx` toglie il votante dall'elenco e il vincolo
+  `mvp_no_autovoto` (migration `m12_niente_autovoto`) rifiuta la riga anche a chi scrive
+  direttamente su PostgREST, come già faceva `pagelle_no_autovoto` per le pagelle.
 - `conteggioPartita()`/`vincitoriMvp()` richiedono un margine netto: in caso di parità,
   nessun vincitore viene assegnato per quella partita finché non arrivano altri voti.
 - `mvpVintiPerGiocatore()` conta una vittoria per ogni partita "vinta" con margine netto; il
@@ -35,18 +38,15 @@ partita, sovrascrivibile.
 
 ## Limiti noti
 
-- **Nessun controllo che impedisca di votare se stessi** — a differenza dei
-  [Badge social](badge.md), che escludono esplicitamente l'auto-voto. È una lacuna, non un
-  limite di design dichiarato altrove.
 - Nessuna scadenza o chiusura della votazione: resta aperta indefinitamente.
-- RLS permissiva: `votante_id`/`votato_id` sono testo libero inviato dal client (l'id
-  giocatore proviene da `localStorage`, non da un claim di sessione verificato server-side);
-  nessun trigger lega il voto all'utente autenticato.
+- 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 sia un convocato di
+  quella partita resta un filtro solo applicativo.
 - In caso di parità, nessun MVP viene assegnato per quella partita.
 
 ---
 
 ## Evoluzioni possibili
 
-- Impedire l'auto-voto come già avviene nei Badge social.
 - Introdurre una scadenza (es. la votazione si chiude N giorni dopo la partita).

docs/modules/presenze.md

@@ -53,7 +53,8 @@ Bottone "Sollecita" (RosaPresenze.tsx) → POST /api/public/sollecita-presenze
       ↓
 src/routes/api/public/sollecita-presenze.ts
       ├─ legge l'evento (eventi_app) e le risposte già date
-      ├─ calcola i destinatari: giocatori attivi senza risposta o con "forse"
+      ├─ destinatariSollecito()  → src/lib/presenze.ts
+      │  (attivi senza risposta o con "forse"; funzione pura, testata in unit)
       ├─ per ciascuno invia una push col testo cifrato nel payload
       │  (src/lib/webpush.server.ts)
       └─ elimina le iscrizioni push scadute (404/410)
@@ -70,24 +71,25 @@ vale per tutta la rosa) — `eventiContanoPresenze()` in `presenze.ts`.
 - Aggiornamento ottimistico della cache locale dopo ogni salvataggio: nessuna rilettura dal
   server, la UI risponde subito.
 - Il sollecito è **manuale**: nessun cron nel repository lo richiama automaticamente, parte
-  solo dal bottone admin.
+  solo dal bottone admin, e la route verifica il ruolo lato server con `richiediAdmin`
+  (DD-024).
+- Ognuno risponde **solo per sé**, e non è più una regola della sola interfaccia: dalla
+  migration `m11_scritture_per_ruolo` la policy di `risposte_presenze` lega la riga allo slot
+  `giocatori_squadra` collegato all'account, con gli amministratori come sola deroga
+  (DD-023). Verificato da `test/integration/permessi.test.ts`.
 
 ---
 
 ## Limiti noti
 
 - Nessuna finestra temporale per rispondere: si può cambiare risposta anche a evento passato.
-- Il controllo "solo il giocatore risponde per sé" è solo lato UI: le policy RLS di
-  `risposte_presenze` permettono a qualunque utente autenticato di scrivere qualunque riga
-  (`USING(true) WITH CHECK(true)`).
+- La risposta di un evento passato resta modificabile: `risposte_presenze` non ha una
+  finestra di chiusura, né in UI né in RLS.
 - `useRispostePresenze()` legge sempre l'intera tabella, non filtrata per evento: adeguato per
   una singola squadra, da rivedere se il volume cresce molto.
-- La route `/api/public/sollecita-presenze` non verifica lato server che il chiamante sia
-  admin: la protezione è solo nell'interfaccia (bottone visibile solo se `useIsAdmin()`).
 
 ---
 
 ## Evoluzioni possibili
 
-- Restringere anche lato RLS/route chi può scrivere una risposta o chiamare il sollecito.
 - Filtrare la lettura delle presenze per evento invece di caricare tutta la tabella.

docs/modules/serie-presenze.md

@@ -4,7 +4,8 @@
 **File principali:** `src/lib/serie.ts`, `src/lib/presenze.ts`, `src/lib/rosa.ts`,
 `src/components/crapp/SerieCard.tsx`
 **Migration collegata:** `m9_risposte_presenze_risposto_il`
-**Test:** `test/unit/serie.test.ts`, `test/unit/presenze.test.ts`
+**Test:** `test/unit/serie.test.ts`, `test/unit/presenze.test.ts`,
+`test/integration/scritture.test.ts` (il trigger che congela `risposto_il`)
 
 ---
 
@@ -58,6 +59,18 @@ UPDATE: senza, un giocatore che risponde subito e cambia idea una settimana dopo
 lento. `aggiornato_il` continua a registrare l'ultima modifica ed è un'altra cosa: non usarlo
 per le conferme.
 
+Le due colonne si confondono facilmente, e sbagliarle non rompe niente di visibile: la serie
+comincia solo a raccontare il falso. Per questo il confine è verificato in
+`test/integration/scritture.test.ts` («la risposta di presenza si aggiorna senza far ripartire
+il cronometro»), che riscrive la risposta provando a riscrivere anche `risposto_il` e controlla
+che il database abbia tenuto la prima: se qualcuno togliesse il trigger, quel test diventa
+rosso. Il test precedente guardava `aggiornato_il` e passava anche senza trigger.
+
+| Colonna         | Cosa registra         | Chi la usa              |
+| --------------- | --------------------- | ----------------------- |
+| `risposto_il`   | la **prima** risposta | la serie "Conferme 24h" |
+| `aggiornato_il` | l'**ultima** modifica | nessuna statistica      |
+
 Cancellare la risposta (`stato: null` → DELETE) elimina anche `risposto_il`: se il giocatore
 risponde di nuovo, riparte il cronometro. È voluto — ha ritirato la risposta.
 
@@ -102,8 +115,11 @@ ordine:
    - solo eventi a cui il giocatore era convocato. **`convocati` vuoto significa "tutta la
      rosa"**, non "nessuno": chi non è nell'elenco di una convocazione ristretta non vede
      quell'evento e la sua serie non si spezza.
-2. **Scarta il futuro** (`e.data <= oggi`). Gli eventi di oggi contano già: se serve un
-   confronto diverso, il parametro `oggi` è iniettabile (i test lo fissano a una data).
+2. **Tiene solo gli eventi già passati** (`e.data < oggi`, dentro `eventiContanoPresenze()`).
+   Il confronto è **stretto**: l'evento di oggi non conta ancora, perché nessuno ha potuto
+   presentarsi e conterebbe come assenza, azzerando la serie di tutta la squadra la mattina
+   della partita. Entra in gioco dal giorno dopo. Il parametro `oggi` è iniettabile — di
+   default `dataOggi()` — e i test lo fissano a una data per non dipendere dall'orologio.
 3. **Ordina per data crescente** (`localeCompare` su `YYYY-MM-DD`).
 4. **Riduce** applicando `aggiornaSerie(serie, onorato(e))` a ogni evento: `+1` se onorato,
    `0` altrimenti. La serie finale è quella che risulta **dopo l'ultimo evento passato**.