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>
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 |
|---|---|
| VISION.md | Perché esiste CrAPP, quali principi deve rispettare una funzionalità |
| ROADMAP.md | Cosa è fatto e cosa è previsto, versione per versione |
| 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 |
| TODO.md | A cosa si sta lavorando adesso |
| 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 → VISION.md → ROADMAP.md →
ARCHITECTURE.md → DATABASE.md → DESIGN_DECISIONS.md → TODO.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;TODO.mdcontiene solo il lavoro in corso o imminente, e rimanda alla roadmap;- 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.