davideandClaude Opus 5
ee9f3f1b8c
La route era disegnata per un cron quotidiano: calcolava chi è di turno oggi e gli mandava una push. Ma nel repository nessun cron esiste, e palloni.md lo annotava già come "da verificare lato hosting": nei fatti quel promemoria non è mai partito. Il segreto condiviso introdotto ieri proteggeva una porta che nessuno apriva, al prezzo di una variabile d'ambiente da configurare ovunque. Ora la fa partire un amministratore dal pulsante "Avvisa chi è di turno", dentro il riquadro palloni dell'evento. La route accetta un eventoId e avvisa i destinatari di quell'evento invece della giornata corrente: chi deve prendere i palloni e chi deve riportarli, con un testo diverso per ciascuno. Stesso precedente di apri-sondaggio, manuale fin dalla v1.0.6. Il testo va in coda su promemoria_push prima dell'invio. Serve: la push parte vuota e il service worker chiede a push-messaggio cosa mostrare, ma quella route sa raccontare solo la giornata corrente, quindi un avviso mandato il martedì per il sabato arriverebbe con il testo generico. avvisiPalloniEvento() è la nuova funzione pura, con i suoi test: due destinatari con testi diversi, un avviso solo quando sono la stessa persona, niente avvisi per un evento inesistente o senza turni. Un'asserzione verifica che il testo non dica mai "oggi", perché può arrivare giorni prima. richiediSegreto e CRON_SEGRETO spariscono: tutte e tre le route di notifica usano ora richiediAdmin, e non resta nessuna variabile da configurare. destinatariPromemoriaPalloni() resta in palloni-core.ts con i suoi test perché push-messaggio continua a usarla per il testo calcolato al volo. 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.