Vai al contenuto

Review, approvazione e pubblicazione

Lo stato editoriale e la visibilità pubblica rispondono a domande diverse e sono memorizzati separatamente.

Obiettivo e transizione autorevole

Stato editoriale

stateDiagram-v2
    [*] --> pending_review
    pending_review --> approved: approve umano
    pending_review --> rejected: reject umano
    approved --> pending_review: contenuto modificato
    rejected --> pending_review: contenuto modificato

Stato di pubblicazione

stateDiagram-v2
    [*] --> draft
    draft --> published: publish esplicito
    published --> draft: unpublish esplicito

Un salvataggio che modifica contenuto già approvato riporta editorialStatus a pending_review e rimuove l'attribuzione della decisione precedente. Un no-op conserva l'approvazione. Finché l'Issue è draft, una nuova decisione umana può anche sostituire direttamente approved con rejected o viceversa. archived resta uno stato separato, fuori dalle azioni esplicite publish e unpublish mostrate nel diagramma.

Input e fonti accettate

Il reviewer legge Issue Content canonico, stato, revisione, quality report, assignment, note interne e feedback insight. Le preview HTML sono rendering; non sono una seconda fonte di contenuto.

Attore e autorizzazione

  • issue:review: assegnazione, approve e reject;
  • issue:publish: publish e unpublish;
  • editorial:write: modifica del draft;
  • admin:read: letture della coda e delle evidenze.

Approvazione e rifiuto richiedono un reviewer umano autenticato e attivo. Le service identity non ricevono issue:review.

Validazione e quality gate

L'approvazione è consentita solo per Issue draft e riesegue i quality gate. La pubblicazione richiede:

  1. editorialStatus: approved;
  2. quality gate ancora verdi;
  3. azione /publish esplicita;
  4. readback status: published.

L'endpoint generico di stato non può sostituire publish o unpublish.

Responsabilità dell'AI

L'AI non assegna reviewer, non approva, non rifiuta, non pubblica e non decide se un feedback richieda una correzione. Può aver prodotto il draft originario, ma la decisione resta umana.

Persistenza e audit in D1

D1 conserva stato editoriale, note, reviewer, assignment e timestamp, oltre a publishedAt, unpublishedAt e motivo opzionale di unpublish. La cronologia del draft conserva le modifiche canoniche; l'unpublish non cancella il contenuto o la review.

Evidenza di successo

  • review: stato approved o rejected con reviewer e timestamp;
  • pubblicazione: status: published, publishedAt e lettura pubblica;
  • unpublish: ritorno a draft, unpublishedAt e contenuto non più pubblico.

La notifica UI non sostituisce il readback autorevole.

Fallimento e recupero

Su quality failure, revisione stantia o permesso assente, fermarsi e correggere il draft o l'identità. Su pubblicazione riuscita ma Frontend statico non aggiornato, aprire una separata operazione di deployment: non ripubblicare. Su contenuto pubblico errato, usare unpublish con motivo e poi modificare il draft.

Effetti collaterali esclusi

  • approvare non pubblica;
  • pubblicare non distribuisce il Frontend;
  • pubblicare non prepara Campaign Draft;
  • pubblicare non schedula, invia o chiama Mailjet;
  • unpublish non cancella review, revisioni o feedback.

Usare il runbook approvazione e pubblicazione.

Riferimenti canonici