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-012.md

@@ -0,0 +1,22 @@
+# DD-012 — Rimandare la migrazione degli ID giocatore
+
+**Data:** agosto 2026  
+**Stato:** Accettata
+
+**Contesto**  
+L’app usa identificativi semplici (`g1`, `g2`, …) collegati a presenze, voti, palloni e altre funzioni già in uso. Nel database esiste anche una tabella `giocatori` con UUID, non collegata al codice attuale.
+
+**Decisione**  
+Per ora **non** unificare gli ID. I nuovi dati del profilo si agganciano agli identificativi già in uso. La migrazione verso UUID resta un lavoro separato, pianificato e testato.
+
+**Alternative scartate**
+
+- Migrare subito tutto a UUID → rischio alto di rompere presenze, voti, scout e notifiche.
+
+**Conseguenze**
+
+- Coesistono due modelli anagrafici fino a migration dedicata.
+- `DATABASE.md` va tenuto aggiornato su cosa è “attivo” e cosa è “futuro”.
+
+**Riesame**  
+Quando il modulo Profilo Giocatore è stabile e c’è tempo per una migration con checklist regressioni completa.