davideandClaude Opus 5
822180bffc
I riferimenti ai documenti in AGENTS.md erano rotti: una venticinquina di link nella forma docs/[README.md](http://README.md), che spezzavano il nome del file a meta e puntavano a domini inesistenti. Ora sono percorsi relativi verificati, con CHANGELOG.md e DESIGN_DECISIONS.md sotto docs/ e PROJECT_STATE.md in root. Tolte da AGENTS.md le sezioni Architettura, Documentazione e Struttura della documentazione: duplicavano ARCHITECTURE.md e docs/README.md con uno stack ormai parziale, contro la regola "ogni informazione ha una sola casa" che docs/README.md stesso impone. Aggiunti invece i comandi, bun e la guardia minimumReleaseAge: Codex e Cursor leggono solo AGENTS.md e non avevano modo di sapere come si verifica una modifica. Scritta la checklist "Fine lavoro" che CLAUDE.md citava senza che esistesse. Nuova regola: chi aggiunge o modifica una funzione scrive o aggiorna il test nello stesso lavoro, i test devono essere verdi e la doc del modulo va aggiornata se il comportamento cambia (DD-020). Serve perche con main come branch di lavoro non c'e piu un ambiente di prova tra il codice e i giocatori. Il flusso git documentato non descriveva piu la realta: main e arrivato a 43 commit di vantaggio su develop, rimasto fermo. DD-003 e ora sostituita da DD-019: il branch dei commit lo decide l'utente, l'assistente al massimo consiglia un branch dedicato e non committa, non pusha e non apre PR di propria iniziativa. Allineati di conseguenza ARCHITECTURE.md (sezione branch), README.md (flusso, install con bun, comandi di test e lint), ROADMAP.md e TODO.md (le voci spuntate sono in produzione, non su develop) e PROJECT_STATE.md (auth e profilo giocatore in produzione, 20 migration fino a M9, passaggi 1-3 e 5 fatti). Corretti poi sei disallineamenti tra documentazione e codice, ognuno verificato sul sorgente: - badge.md e obiettivi-squadra.md dicevano che le serie sono inerti e che serieAllenamenti e sempre 0, quindi badge e obiettivo "Continuita di squadra" non sbloccabili. Falso da7237e8f: presenze.ts:48 le calcola e rosa.ts:64-67 le attacca al Giocatore. Il limite che resta e un altro, ora scritto: risposto_il non e ricostruibile prima di m9, quindi sulle risposte vecchie serieConferme e un'approssimazione. - TODO.md e PROJECT_STATE.md davano il tracciamento tesseramento CSI come da fare, mentre ROADMAP, CHANGELOG e DATABASE lo davano per fatto. Lo e: admin.tsx:264-278 registra numero e data, :472 mostra Tesserato/Da tesserare, :676 il contatore. - collegamento-csi.md indicava il check di parsing in src/lib/csi-core.test.ts; sta in test/unit/csi-core.test.ts, in src/lib non esiste nessun .test.ts. - profilo-giocatore.md annunciava cinque aree del profilo e ne elencava sette. - "Segnala un bug" e "Suggerisci una nuova funzionalita" (profilo.tsx:259-276, commit72a9864) non erano documentati da nessuna parte, contro DD-002: ora stanno in profilo-giocatore.md e nel CHANGELOG. npm run test: 28/28 file ok. npm run lint: 12 problemi, identici a prima di questa modifica e tutti in src/, non toccato qui. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
78 lines
3.5 KiB
Markdown
78 lines
3.5 KiB
Markdown
# Modulo — Badge
|
|
|
|
**Stato:** implementato (v1.0), coerente con DD-007 e DD-008
|
|
**File principali:** `src/lib/badges.ts`, `src/lib/badge-social.ts`,
|
|
`src/components/crapp/CollezioneBadge.tsx`, `src/components/crapp/BadgeDrawer.tsx`,
|
|
`src/components/crapp/CelebrazioneBadge.tsx`, `src/components/crapp/VotoSocial.tsx`
|
|
|
|
---
|
|
|
|
## Obiettivo
|
|
|
|
Gamification: sbloccare badge (gradi bronzo/argento/oro, più badge "segreti") in base a
|
|
statistiche personali reali del giocatore, per motivare la partecipazione senza penalizzare i
|
|
ruoli con meno statistiche "spettacolari" (DD-008).
|
|
|
|
---
|
|
|
|
## Dati
|
|
|
|
Nessuna tabella dedicata ai badge sbloccati: **calcolati interamente a runtime**
|
|
dall'oggetto `Giocatore` (DD-007). L'unica tabella coinvolta è `badge_social_voti`, per i
|
|
badge assegnati per voto dai compagni.
|
|
|
|
---
|
|
|
|
## Implementazione
|
|
|
|
- `badgeDefs`/`badgeSegreti` (`badges.ts`) definiscono ogni badge con una funzione
|
|
`valore(g)` e soglie bronzo/argento/oro. Le fonti dato sono solo statistiche indipendenti
|
|
dal ruolo in campo: MVP, media pagelle, turni palloni, presenze, serie, infortuni,
|
|
ritardi, cacche — **mai** punti/ace/muri dello Scout Live, coerentemente con DD-008.
|
|
- I badge segreti restano nascosti (icona lucchetto) finché non sbloccati.
|
|
- **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
|
|
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
|
|
badge segreti ancora da scoprire; `BadgeDrawer.tsx` il dettaglio di un singolo badge;
|
|
`CelebrazioneBadge.tsx` l'overlay celebrativo alla prima visualizzazione di un badge nuovo.
|
|
- Il rilevamento "nuovo" (`notifiche-smart.ts`) confronta id deterministici con quelli già
|
|
visti, salvati in `localStorage` — quindi **locale al dispositivo**, non sincronizzato tra
|
|
dispositivi dello stesso giocatore.
|
|
|
|
---
|
|
|
|
## Regole rispettate
|
|
|
|
- **DD-007**: nessuna tabella `badge_sbloccati`, tutto calcolato a runtime dai dati
|
|
esistenti.
|
|
- **DD-008**: nessun `BadgeDef` usa dati di reparto (punti/ace/muri); solo statistiche
|
|
raggiungibili da qualunque ruolo.
|
|
|
|
---
|
|
|
|
## Limiti noti
|
|
|
|
- **Dipendenza dal modulo [Serie](serie-presenze.md)**: i badge "Sempre in palestra",
|
|
"Risposta lampo" e il segreto "Mai un forfait" si muovono solo se cambiano le serie. Le
|
|
serie sono calcolate sui dati reali dalla migration `m9` in avanti, ma "Risposta lampo" e
|
|
"Mai un forfait" dipendono da `serieConferme`, e `risposto_il` non è ricostruibile per le
|
|
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.
|
|
- Notifiche "nuovo badge" solo locali al dispositivo (localStorage), si ripetono cambiando
|
|
browser o dispositivo.
|
|
|
|
---
|
|
|
|
## Evoluzioni possibili
|
|
|
|
- Sincronizzare lo stato "visto" su Supabase invece che solo in localStorage.
|
|
- Verificare sui dati di stagione che i tre badge legati alle serie si sblocchino davvero,
|
|
ora che le serie sono calcolate.
|