davideandClaude Opus 5 f687322c3f 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>
2026-09-06 19:30:49 +02:00
2026-09-03 14:23:56 +02:00

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_URL
  • SUPABASE_PUBLISHABLE_KEY
  • VITE_SUPABASE_URL
  • VITE_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.

S
Description
App del CRAP, ottimizzazione di sporteasy adattata alle esigenze della squadra, campionato e extra
https://crapp-iv11.vercel.app
Readme
2.3 MiB
Languages
TypeScript 94.4%
PLpgSQL 3.5%
CSS 1.8%
JavaScript 0.3%