Riorganizza la documentazione per l'uso con assistenti AI

- Spezza il registro delle decisioni in docs/decisions/DD-XXX.md, con indice
- Ripulisce DATABASE.md dalla storia delle migration e aggiunge la sezione Lettura
- Riduce PROJECT_STATE.md a una pagina; la procedura di allestimento passa in OPERATIONS.md
- Aggiunge OPERATIONS.md, GLOSSARIO.md, trappole note e checklist in ARCHITECTURE.md
- Sintetizza la copertura test di badge.md e documenta docs/archive
- Allinea AGENTS.md, README.md e la regola Cursor (tolto l'obbligo di develop, in contrasto con DD-019)

Co-Authored-By: Claude Sonnet 5.5 <noreply@anthropic.com>

docs/decisions/DD-037.md

@@ -0,0 +1,55 @@
+# DD-037 — I promemoria evento ricordano di essere già stati generati
+
+**Data:** 29 settembre 2026  
+**Stato:** Accettata
+
+**Contesto**  
+I promemoria a 24 e a 3 ore (M17, DD-030) evitavano i doppioni con `ON CONFLICT DO NOTHING` sul
+vincolo `UNIQUE (giocatore_id, evento_id, tipo)` di `notifiche_utente`: la riga della notifica
+era l'unica traccia che il promemoria fosse già stato generato. Il giocatore però può eliminarla
+(swipe o ×, DD-030). Senza più la riga, al giro successivo del job (ogni ora per il promemoria a
+24 ore, ogni 15 minuti per quello a 3 ore, finché l'evento non inizia) il promemoria veniva
+rigenerato come non letto. Con il canale email (DD-036) ogni rigenerazione accodava anche una
+mail nuova: un giocatore che eliminava un promemoria ne riceveva una ogni ora fino all'inizio
+dell'evento. Il difetto è stato trovato controllando la logica il 29/09/2026, il giorno in cui il
+worker email è entrato in produzione, e riprodotto sul database locale.
+
+**Decisione**  
+Un registro separato, `promemoria_eventi_generati` (migration `m23_promemoria_gia_generati`), con
+una riga per `(giocatore_id, evento_id, tipo)` scritta dalla funzione `genera_promemoria_eventi()`.
+La notifica in-app si crea solo per le righe **appena registrate**, quindi eliminarla non fa
+ripartire nulla. Il registro è indipendente da `notifiche_utente`, senza policy per i client, e
+sparisce con l'evento o con il giocatore (`ON DELETE CASCADE`). I promemoria già presenti al
+momento della migration sono stati registrati come generati, altrimenti la prima notifica
+eliminata dopo la migration sarebbe tornata come prima. Il vincolo `UNIQUE` di `notifiche_utente`
+resta come seconda difesa. Cron, criteri di selezione, testi e destinatari sono invariati.
+
+**Alternative scartate**
+
+- Non eliminare davvero la notifica (nasconderla con un flag) → scartata: cambia il significato
+  dell'eliminazione per tutte le sorgenti, tocca la RLS e le query del client, e la tabella
+  crescerebbe di righe che il giocatore non vede più.
+- Togliere l'eliminazione dai soli promemoria, lasciando «segna come letta» → scartata: a un
+  giocatore che vuole ripulire l'elenco resterebbero notifiche non eliminabili, incoerenti con
+  le altre.
+- Un flag «già generato» sulla riga dell'evento → scartata: il promemoria è per giocatore, e chi
+  viene aggiunto ai convocati dopo deve comunque riceverlo.
+- Confrontare `creato_il` o lo stato «letta» per capire se ricrearlo → scartata: non distingue
+  una notifica mai generata da una eliminata.
+
+**Conseguenze**
+
+- Eliminare un promemoria lo fa sparire per sempre, e non parte nessuna mail in più. Il numero
+  massimo di mail automatiche per giocatore ed evento resta due (24 e 3 ore).
+- Una tabella in più, che cresce di una riga per giocatore, evento e tipo e si svuota con
+  l'evento.
+- Se un evento viene spostato dopo che il promemoria è partito, non ne parte uno nuovo per la
+  data nuova: è lo stesso comportamento di prima, ora esplicito.
+- `test/integration/promemoria-eventi.test.ts` è la definizione eseguibile: il promemoria
+  eliminato non ricompare, non riaccoda mail, i due tipi sono indipendenti, un convocato aggiunto
+  dopo lo riceve comunque, il registro non è leggibile né scrivibile da un client e sparisce con
+  l'evento. Sul database con la funzione vecchia il test fallisce.
+
+**Riesame**  
+Se gli eventi potessero essere spostati con frequenza e servisse un nuovo promemoria per la data
+nuova, il registro va agganciato anche alla data di inizio, oltre a giocatore, evento e tipo.