Controlli ed evidenza

Ogni release registra una sola evidenza primaria nel riepilogo GitHub Actions:

SHA esatto e ambiente;
tag canonico per la produzione;
release pack e CI richiesti;
ultima baseline production, migration mode, file/checksum pending, apply e verifica ledger;
version ID precedente/candidato, riuso dell'upload exact-tagged, esiti distinti di validazione, smoke API/D1, deploy API/MCP e smoke MCP;
esito success o not-run dello smoke autenticato public-content, oltre alla protected front door sempre verificata;
esclusione esplicita di configurazione runtime, Mailjet e mutazioni editoriali;
esito terminale sanificato.

Non registrare segreti, recipienti, provider ID o payload privati. Health, versione, manifest/ledger, configurazione Access, binding D1/Queue e contratti API/MCP devono essere coerenti prima della mutazione. CI autorizza soltanto il gate tecnico. Il merge Fra dell'Issue che descrive la release è l'unico gate umano ordinario e autorizza creazione/push del tag e gli stage Production già revisionati.

Issue mergiata, tag quando Production e run sono sufficienti per la release ordinaria none o expand. Aggiungere al massimo un commento alla Issue o PR originaria quando porta informazione nuova; non replicare la stessa evidenza in logbook, Issue e commenti. Project Status, workflow label e Issue Ready non sono gate tecnici del release workflow.

Al job scope GitHub espone soltanto il token di deployment Cloudflare e l'identificativo account. Il solo step smoke API può ricevere la copia cifrata della coppia Public Site Access dello stesso ambiente; l'evidenza registra soltanto success, not-run o failure sanitizzato. Variabili applicative e secret Worker restano configurazione runtime Cloudflare, vengono preservati da --keep-vars e non sono copiati o confrontati dal workflow. Il workflow verifica la versione caricata prima dell'attivazione e non distribuisce trigger. La readiness Mailjet appartiene al point-of-use o a uno smoke della capability, non alla release.