Files
CRAPP/docs/README.md
T
davideandClaude Sonnet 5.5 58eba642f7 Documenta l'installazione e la gestione del worker email
Nuovo docs/WORKER_EMAIL.md (password per app, installazione, gestione,
diagnosi, prova in locale, spostamento su un altro host); il modulo
notifiche-email.md resta la sola specifica funzionale. Allineati
DD-036, CHANGELOG, PROJECT_STATE, indice e portabilità: migration m22
e worker in produzione dal 29/09/2026.

Co-Authored-By: Claude Sonnet 5.5 <noreply@anthropic.com>
2026-09-29 12:22:46 +02:00

3.4 KiB

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 (backup/disaster recovery incluso)
EFFICIENZA_CLOUD.md Come tenere basso il consumo cloud: cache, query, push
WORKER_EMAIL.md Come si installa, si gestisce e si diagnostica il worker che invia le notifiche per email
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.md registra 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 in supabase/migrations/: una tabella nuova si documenta nella stessa modifica che la crea;
  • le motivazioni stanno solo in DESIGN_DECISIONS.md, in voci DD-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.