Scheduling ed evidenza di delivery

Scheduling e delivery appartengono al provider, ma sono operazioni differenti. Architecture Coffee non deve dedurre delivery da un draft, da un upload o da uno stato pianificato.

Obiettivo e transizione autorevole

flowchart TD
    draft["Campaign Draft con contenuto"] --> auth["Autorizzazione scheduling"]
    auth --> schedule["scheduleCampaign"]
    schedule --> scheduled["Stato scheduled"]
    scheduled --> provider["Esecuzione Mailjet"]
    provider --> evidence{"Evidenza live autorevole?"}
    evidence -->|"sì"| proven["Delivery provata nei limiti dell'evidenza"]
    evidence -->|"no o ambigua"| unknown["Delivery non provata"]

Il contratto applicativo corrente espone la capability provider di scheduling, ma il workspace Campaign Draft non offre scheduling o delivery. Una futura procedura operativa deve mantenere il confine e l'autorizzazione separata.

Input e fonti accettate

Lo scheduling richiede un Campaign Draft provider esistente, contenuto caricato, timestamp futuro, target server-owned e autorizzazione specifica. La delivery usa contatti, liste, consenso, suppression e bounce posseduti da Mailjet; Architecture Coffee non ricostruisce tali dati.

Attore e autorizzazione

campaign:draft protegge le route Campaign esistenti, ma la disponibilità tecnica non equivale ad autorizzazione operativa. Scheduling o verifica live richiedono un Issue in scope e un go/no-go separato. Il browser non sceglie credenziali, destinatari individuali o riferimenti provider arbitrari.

Validazione e quality gate

Prima dello scheduling:

Issue ancora published, approved e quality-passing;
Campaign Draft e target coerenti;
contenuto caricato;
timestamp RFC 3339 futuro;
provider mode live quando si vuole prova reale;
nessuna operazione concorrente o ambigua.

Responsabilità dell'AI

Nessuna. L'AI non sceglie destinatari, orari, liste, consenso o interpretazione dell'esito provider.

Persistenza e audit in D1

D1 può conservare intento Campaign, timestamp, stato aggregate e ricevute sanitizzate. Non conserva indirizzi, lista completa, unsubscribe, bounce, suppression o payload provider. Lo stato scheduled prova soltanto l'accettazione dello scheduling.

Evidenza di successo

Distinguere:

Evidenza	Dimostra	Non dimostra
attempt `mock` o `dry_run`	mapping e flusso applicativo	chiamata live
`draft_created`	Campaign Draft provider	contenuto caricato
`content_uploaded`	contenuto accettato dal provider	scheduling
`scheduled`	richiesta di scheduling accettata	consegna
delivery ID di test live	accettazione di un singolo test send	campagna a lista completata
stato/evento live Mailjet	ciò che il provider attesta	dati non presenti nell'evidenza

Una prova di delivery reale richiede modalità live, operazione autorizzata e riscontro provider univoco. In assenza, la conclusione corretta è “delivery non provata”.

Fallimento e recupero

Timeout, ricevuta incompleta, stato sconosciuto o mismatch devono fermare ogni nuovo invio. Prima di un retry, riconciliare quando esiste una lettura autorevole; altrimenti aprire un nuovo Issue operativo. Non duplicare una campagna per ottenere una prova più comoda.

Effetti collaterali esclusi

scheduling non modifica l'Issue o il suo stato editoriale;
scheduling non prova delivery;
verifica dell'evidenza non rischedula e non invia;
pubblicazione non chiama Mailjet;
Architecture Coffee non prende ownership dei destinatari.

Usare il runbook di verifica.