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>
CrAPP 🏐
CrAPP è una Progressive Web App sviluppata per digitalizzare completamente la gestione di una squadra di pallavolo.
Funzionalità principali
- Gestione squadra
- Gestione presenze
- Calendario allenamenti e partite
- Scout Live
- Badge e gamification
- Statistiche
- Notifiche intelligenti
- Gestione amministrativa
- AI per la pianificazione degli allenamenti (in sviluppo)
Stack tecnologico
React 19, TypeScript, TanStack Start (SSR), Vite 8, Tailwind CSS 4, motion, vaul, Supabase (PostgreSQL, Auth, Storage), Vercel, GitHub. Dettagli in docs/ARCHITECTURE.md.
Avvio locale
Le dipendenze si installano con bun (bun.lock):
bun install
npm run dev # http://localhost:8080
Comandi
npm run build # build di produzione
npm run lint # eslint (include prettier)
npm run test # test unit; npm run test:all per la suite completa
Chi aggiunge o modifica una funzione scrive anche il test e lo lascia verde (test/README.md).
Deploy
Deploy automatico su Vercel a ogni push su main, che è anche il branch di lavoro corrente.
develop pubblica un Preview Deployment, ma oggi è indietro rispetto a main. Su quale branch
committare lo decide chi sviluppa (DD-019).
Variabili d'ambiente
Il progetto richiede le seguenti variabili:
SUPABASE_URLSUPABASE_PUBLISHABLE_KEYVITE_SUPABASE_URLVITE_SUPABASE_PUBLISHABLE_KEY
Documentazione
Indice in docs/README.md. Le regole per gli assistenti AI stanno in AGENTS.md, lo stato corrente del lavoro in PROJECT_STATE.md.