davideandClaude Opus 5
2b8ba340a6
Provando il promemoria palloni in produzione la notifica risultava inviata ma non arrivava. La causa non era il codice: l'iscrizione di destinazione era scaduta, FCM l'ha accettata con 2xx e ha buttato via il messaggio, e un minuto dopo il dispositivo si è re-iscritto con un endpoint nuovo. Un 2xx dal server push non significa consegnato, e non manda il 404/410 che farebbe pulire push_subscriptions: è annotato fra i limiti noti, perché dal server non è distinguibile. Il difetto vero l'ha fatto emergere quella caccia. promemoria_push si svuota solo quando il dispositivo legge il messaggio, quindi se la push non arriva mai la riga resta per sempre — e push-messaggio serve la coda con priorità sul testo calcolato. In produzione ce n'erano dieci, la più vecchia del 2 settembre: alla notifica successiva, di qualunque tipo, quel telefono avrebbe mostrato un sollecito presenze per un evento già passato. Ora un promemoria vale 12 ore. La riga si cancella comunque alla prima lettura, scaduta o no: cancellare solo le fresche lascerebbe le vecchie in coda a dirottare ogni notifica futura, cioè il bug. Così la coda si smaltisce da sola e le righe orfane già in produzione non vanno ripulite a mano. Il messaggio del pulsante distingue infine i due casi che prima confondeva: nessuna iscrizione fra gli incaricati, oppure iscrizioni presenti e invio non riuscito. Il primo è informativo, il secondo è un errore — dirlo sbagliato manda a cercare il problema dalla parte opposta. 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.