Runbook: approvare e pubblicare come azioni separate

Quando usarlo

Usare questo runbook per portare un draft validato dalla review umana alla visibilità pubblica, mantenendo due decisioni e due permessi distinti.

Prerequisiti

• Issue draft e revisione corrente;
• quality report verde;
• reviewer umano attivo con issue:review;
• identità con issue:publish per la fase successiva;
• nessuna modifica non riletta;
• consapevolezza che il Frontend statico richiede deployment separato.

Procedura

1. Aprire l'Issue nel workspace review.
2. Rileggere contenuto, stato, revisione, quality e note.
3. Eseguire approve.
4. Rileggere e richiedere editorialStatus: approved.
5. Fermarsi per distinguere la decisione di pubblicazione.
6. Eseguire publish.
7. Rileggere status: published e publishedAt.
8. Verificare la proiezione pubblica API.
9. Registrare che nessun deployment o Mailjet è partito.
10. Se serve aggiornare il sito statico, usare un Issue operativo separato.

Verifiche attese

• approvazione attribuita al reviewer umano;
• qualità ancora verde;
• pubblicazione successiva e distinta;
• contenuto pubblico derivato dal JSON canonico;
• nessun Campaign Draft, scheduling, delivery o deployment implicito.

Condizioni di stop

Fermarsi se il contenuto cambia dopo l'approvazione, quality fallisce, il reviewer non è autorevole, l'Issue è già published o il readback non conferma una delle due transizioni.

Rollback o recupero

Se il contenuto pubblicato è errato, eseguire unpublish con motivo, correggere il draft, ottenere nuova review e pubblicare di nuovo. Non cancellare l'Issue o riscrivere publishedAt.

Evidenza da conservare

• Issue e revisione;
• quality report;
• reviewer e decisione;
• publishedAt o unpublishedAt;
• risultato della lettura pubblica;
• conferma di zero operazioni Mailjet e zero deployment.