Runbook: preparare un Campaign Draft

Quando usarlo

Usare questo runbook per creare un Campaign Draft provider e caricare separatamente HTML e testo canonici, senza scheduling o delivery.

Prerequisiti

• Issue published, approved e quality-passing;
• identità con campaign:draft;
• target presente nel catalogo server-owned;
• provider mode noto;
• nessun Campaign Draft attivo duplicato;
• autorizzazione esplicita per le operazioni live, se applicabile.

Procedura

1. Selezionare l'Issue dalla coda degli Issue pubblicati.
2. Leggere history, aggregate, attempt e availableActions.
3. Se prepare è disponibile, scegliere il target e i metadati temporali richiesti.
4. Confermare che la preparazione non schedula o invia.
5. Eseguire prepare una volta.
6. Rileggere aggregate e attempt.
7. Se content_upload è disponibile, confermare l'upload separato.
8. Eseguire content_upload una volta.
9. Rileggere stato ed evidenza sanitizzata.
10. Terminare senza usare scheduling, test send o delivery.

Verifiche attese

• attempt distinti per prepare e content_upload;
• provider mode corretto;
• provider draft presente solo quando autorevole;
• aggregate content_uploaded dopo l'upload;
• target esposto solo come alias e riferimento mascherato;
• nessun scheduling o send.

Condizioni di stop

Fermarsi su Issue non eleggibile, target assente, duplicate active campaign, azione non proiettata, attempt unknown, provider mode inatteso o evidenza incompleta.

Rollback o recupero

Non cancellare o riscrivere un attempt terminale. Se il server proietta un retry, creare un nuovo attempt collegato. Su ambiguità usare diagnostica provider.

Evidenza da conservare

• Issue e target sicuro;
• aggregate e attempt;
• provider mode;
• stato terminale e codice sanitizzato;
• parent del retry eventuale;
• conferma che scheduling, delivery e destinatari sono rimasti fuori scope.