Punti emersi leggendo a fondo la specifica: alcuni sono buchi da chiudere prima di costruire, altri sono migliorie che ti fanno risparmiare lavoro o problemi. Li mettiamo sul tavolo per deciderli insieme.
È il buco più importante. Gli errori email li intercettiamo dai bounce di Resend (blocco 5). Ma una condivisione Drive verso un indirizzo sbagliato o non-Google non genera nessun segnale: resta un invito in sospeso, la persona non riceve l'accesso e nulla ce lo dice. Tutta la consegna passa da Drive, e il blocco 5 copre solo le email. Serve un controllo esplicito (verificare che l'indirizzo sia un'identità Google reale, o rilevare la mancata accettazione).
Stripe ripete i webhook, Tally può inviare due volte, l'agente può richiamare. Senza una tabella centrale degli eventi già processati, si ottengono esattamente i doppi PDF / doppie email / doppie righe che hai chiesto di evitare. Si costruisce in Fase 0 ed è il motivo per cui Supabase (vincoli di unicità) batte Notion su questo.
Si raccolgono foto del documento (fronte/retro, più angolazioni) di residenti UE: dati di categoria particolare. Dove vengono salvati gli upload, per quanto tempo, cosa succede alla cancellazione/rimborso, e in che giurisdizione. Mettere la Fase 2 sul form nativo n8n self-hosted (vedi Architettura) risolve gran parte del problema: i documenti non escono dalla vostra infrastruttura. Resta da definire una policy di retention.
I due PDF devono partire nella stessa email, ma la Tasa arriva da un endpoint esterno potenzialmente lento. Va costruito come "attendi entrambi con timeout → se uno fallisce, alert Discord e trattieni l'email", mai "mando l'EX-18 ora e la Tasa dopo".
Il token nella URL del form è manipolabile dal client. Oltre al monouso (che hai già previsto) va aggiunta una scadenza, il legame alla singola pratica e un limite di tentativi, con validazione sempre lato server contro il DB.
La regola "contatti raccolti = persone paganti → parte la Fase 2, altrimenti abbandonato" lascia a piedi chi ha compilato. Meglio: aprire subito le pratiche di chi ha inviato e sollecitare solo i mancanti. Un acquirente di 4 non deve bloccare 3 persone pronte perché il quarto è lento.
Hai messo il rimborso come "manuale", ma richiede revoca-tutti-i-Drive + segna-rimborsato + ferma-agente + archivia. Un piccolo trigger interno che fa tutto in un colpo evita che "manuale" significhi dimenticare un passaggio e lasciare accessi aperti.
Il blocco 6 dice rimozione per cambio stato, mai a timer. Note precedenti chiedevano però un fallback automatico a 1 mese. Si conciliano: cambio stato come regola primaria più un cron di sicurezza per le pratiche che non cambiano mai stato. Da confermare quale vuoi.
L'endpoint che l'agente interroga per numero WhatsApp restituisce tier, flag, stato, ordine: se l'auth dell'agente è debole, è un endpoint che espone dati personali. Va protetto bene.
"Robusto al lancio" non è solo alert: serve poter rigiocare un evento fallito, non solo esserne avvisati. Una piccola coda di dead-letter.
Le implicazioni di queste scelte su accessi e infrastruttura sono nel documento Dipendenze & Contratti.