davideandClaude Sonnet 5
4fb05748c3
Nessun bug trovato: serieConsecutiva() gestisce correttamente buco (azzera) vs infortunio (congela senza azzerare), lo stesso filtro sui convocati della funzione pura protegge anche questo badge senza bisogno dell'estensione RLS di M13. Confermato che il limite noto "risposto_il non ricostruibile prima di m9" riguarda solo serie-conferme e il segreto s-mai-forfait, non questo badge: serieConsecutiva() guarda solo lo stato della risposta, non il suo istante. Aggiunti test unit sulle soglie (badges.test.ts) e un nuovo end-to-end (serie-allenamenti-badge.test.ts) che scrive allenamenti e risposte reali sul database locale e verifica l'intera pipeline fetchPresenze()/daRiga() -> serieConsecutiva() -> statoBadge() attraverso le tre soglie, incluso il caso "un buco azzera" e, separatamente, "un infortunio congela invece di azzerare". docs/modules/badge.md aggiornato con la pipeline, la copertura test e la descrizione corretta (l'infortunio non spezza la serie). Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
Documentazione CrAPP
Indice della documentazione ufficiale del progetto. Ogni file risponde a una domanda precisa: se l'informazione che cerchi non è nel file indicato, probabilmente non esiste ancora e va prima documentata (vedi DD-002).
Dove sta cosa
| Documento | Risponde a |
|---|---|
| ROADMAP.md | Cosa è fatto, cosa è previsto, cosa resta un'idea |
| ARCHITECTURE.md | Com'è fatta l'app: stack, struttura del codice, flusso di sviluppo |
| DATABASE.md | Quali tabelle esistono, a cosa servono, chi le usa |
| DESIGN_DECISIONS.md | Perché abbiamo scelto così, cosa abbiamo escluso e quando riaprire la scelta |
| PORTABILITA.md | Cosa lega l'app a un fornitore e cosa no, come spostarla su server proprio |
| EFFICIENZA_CLOUD.md | Come tenere basso il consumo cloud: cache, query, push |
| CHANGELOG.md | Cosa è cambiato e quando |
| modules/ | Specifica funzionale di ogni modulo, una per file |
Le regole vincolanti per gli assistenti AI stanno in AGENTS.md; lo stato corrente del lavoro in PROJECT_STATE.md.
Ordine di lettura
Prima di modificare il codice, nell'ordine: questo indice → ROADMAP.md → ARCHITECTURE.md
→ DATABASE.md → DESIGN_DECISIONS.md → il documento del modulo interessato in modules/.
Regole di manutenzione
Ogni informazione ha una sola casa, per evitare che le copie divergano:
- l'elenco delle funzionalità (fatte e previste) sta solo in
ROADMAP.md; CHANGELOG.mdregistra quando qualcosa è stato rilasciato, non ripete l'elenco: segue il formato Keep a Changelog, con il lavoro non ancora rilasciato sotto[Non rilasciato]e le voci divise per categoria (Aggiunto, Modificato, Sicurezza…);- il lavoro in corso sta solo in
PROJECT_STATE.md, che rimanda alla roadmap per il resto; - lo schema del database sta solo in
DATABASE.md, allineato alle migration insupabase/migrations/: una tabella nuova si documenta nella stessa modifica che la crea; - le motivazioni stanno solo in
DESIGN_DECISIONS.md, in vociDD-XXX; per aggiungerne una si copia _template-dd.md.
Convenzioni di scrittura: un solo titolo # per file (le sezioni interne partono da ##),
niente --- come riempitivo tra i paragrafi, tabelle al posto degli elenchi ripetitivi.