Files
CRAPP/docs/modules/obiettivi-squadra.md
T
davideandClaude Opus 5 822180bffc Riscrive AGENTS.md e riallinea la documentazione allo stato reale.
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 da 7237e8f: 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,
  commit 72a9864) 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>
2026-09-04 23:24:22 +02:00

3.3 KiB

Modulo — Obiettivi di squadra

Stato: implementato (v1.0), con costanti stagionali da aggiornare a mano File principali: src/lib/obiettivi.ts, src/lib/rosa.ts (useObiettivi())


Obiettivo

Mostrare traguardi collettivi (non individuali) che avanzano con il contributo di tutta la rosa — presenze, risposte alle convocazioni, pagelle, risultati di campionato — per motivare comportamenti di squadra oltre alla singola prestazione.


Dati

Nessuna tabella dedicata: ogni obiettivo è una funzione pura in obiettivi.ts che legge dati già aggregati altrove (risposte_presenze, pagelle_voti, i risultati ufficiali CSI, le serie).


Obiettivi definiti

Obiettivo Calcolo Target Fonte
90% presenze ad agosto risposte presente/ritardo sugli eventi del mese 90% risposte_presenze
Tutti rispondono alle convocazioni risposte totali / eventi possibili 90% risposte_presenze
250 presenze complessive somma presenze di tutta la rosa 250 aggregato da useRosa()
Media pagelle da 7.5 media di squadra 7.5 pagelle_voti
200 pagelle compilate conteggio voti 200 pagelle_voti
Continuità di squadra giocatori con ≥3 allenamenti consecutivi 12 serieAllenamenti
1 / 5 / 10 vittorie in campionato partite vinte da dati CSI ufficiali 1/5/10 modulo Collegamento CSI
1 evento di squadra al mese eventi di tipo "evento" nel mese 1 eventi_app

Mostrati in squadra.tsx (elenco completo con barra di progresso) e in index.tsx (home: il primo obiettivo non completato). Un obiettivo che supera il 90% genera anche una notifica smart (notifiche-smart.ts).


Limiti noti

  • "Continuità di squadra" dipende da serieAllenamenti (vedi Serie di presenze), calcolato sui dati reali: un evento passato senza risposta vale come assenza e azzera la serie, quindi l'obiettivo misura anche quanto la squadra risponde alle convocazioni, non solo la presenza.
  • Il mese di riferimento è una costante fissa nel codice (agosto 2026): gli obiettivi legati al mese corrente vanno aggiornati manualmente a ogni cambio di mese o stagione, oggi sono "congelati" su un mese già passato.
  • Le vittorie di campionato dipendono dal parsing HTML del portale CSI: se quel parsing si rompe, questi tre obiettivi restano a 0% anche a fronte di vittorie reali.
  • I target (250 presenze, 200 pagelle, ecc.) sono costanti fisse, da rivedere manualmente a ogni stagione.

Evoluzioni possibili

  • Calcolare il mese di riferimento dinamicamente invece di una costante hardcoded.