Decisione editoriale e pubblicazione
Lo stato editoriale e la visibilità pubblica rispondono a domande diverse e restano memorizzati separatamente.
Obiettivo e transizione autorevole
stateDiagram-v2
[*] --> pending_review
pending_review --> approved: approve esplicito
pending_review --> rejected: reject esplicito
approved --> pending_review: contenuto modificato
rejected --> pending_review: contenuto modificato
stateDiagram-v2
[*] --> draft
draft --> published: publish esplicito
published --> draft: unpublish esplicito
Una modifica reale del draft riporta editorialStatus a pending_review e
rimuove l'attribuzione precedente; un no-op la conserva.
Input e fonti accettate
L'operatore legge Issue Content canonico, stato, revisione, quality report, note interne e feedback insight. Le preview sono rendering, non una seconda fonte di contenuto.
Attore e autorizzazione
Cloudflare Access autentica un'unica identità operativa umana o service. Le capability applicative, non ruoli o assignment, autorizzano le operazioni:
admin:read: fonti, coda ed evidenze;issue:draft: modifica del draft;issue:review:approveereject;issue:publish: solopublish;issue:unpublish: solounpublish;campaign:draft: operazioni Campaign Draft separate.
GET /admin/auth/me restituisce soltanto tipo di identità, provider
normalizzato, riferimento deterministico
<provider>/<kind>/sha256:<digest> e permessi effettivi. Non espone subject,
assertion o credenziali Access.
Validazione e quality gate
L'approvazione è consentita solo per Issue draft e riesegue i quality gate.
La pubblicazione richiede:
editorialStatus: approved;- quality gate ancora verdi;
- azione
/publishesplicita; - readback
status: published.
L'endpoint generico di stato non sostituisce publish o unpublish.
Responsabilità dell'AI
L'AI può produrre un draft candidato, ma non approva, rifiuta, pubblica o autorizza operazioni successive.
Persistenza e audit in D1
D1 conserva editorialDecisionNote, editorialDecidedAt,
editorialDecidedBy, stato editoriale, cronologia del draft e metadati di
pubblicazione. publishedAt rappresenta la prima pubblicazione e resta come
evidenza storica dopo unpublish; status governa la visibilità corrente e
resta l'unico gate del lifecycle corrente, mentre unpublishedAt prova il
ritiro esplicito. I timestamp storici non impediscono la modifica di un record
con status: draft: un draft mai pubblicato ha entrambi i timestamp null,
mentre un draft ritirato conserva entrambi i timestamp. Non esistono registry o
assignment dell'operatore.
Evidenza di successo
- decisione: stato
approvedorejected, riferimento operatore e timestamp; - pubblicazione:
status: published,publishedAte readback pubblico; - unpublish: ritorno a
draft,publishedAtstorico invariato,unpublishedAtvalorizzato e contenuto non pubblico.
Fallimento e recupero
Su quality failure, revisione stantia o permesso assente, fermarsi e correggere
input o autorizzazione. Su contenuto errato, usare unpublish, correggere il
draft e ottenere una nuova decisione.
Effetti collaterali esclusi
- approvare non pubblica;
- pubblicare non prepara né invia email;
- pubblicare non prepara, schedula o invia Campaign Draft;
- pubblicare non chiama Mailjet;
- unpublish non cancella decisioni, revisioni o feedback.
La risposta di comando non sostituisce il readback autorevole. Se il readback deve essere aggiornato, serve una separata operazione protetta.
Usare il runbook approvazione e pubblicazione.