Flusso editoriale degli agenti

In Agents → Models il flusso editoriale ha una policy globale separata dalle route dei modelli. In Executions → Catene editoriali l'amministratore segue le esecuzioni e la loro diagnostica. Le operazioni sulle fonti e sui contenuti del Blog restano nel relativo workspace editoriale.

Percorsi e prerequisiti

Per i limiti: Amministrazione → Impostazioni globali → Agents → Models → Modifica limiti del flusso (/agents?tab=models). Per la diagnosi: nello stesso workspace apri Executions, seleziona Catene editoriali e premi Dettagli sulla catena. Entrambi i percorsi qui descritti richiedono l'amministratore di piattaforma.

Per cambiare i limiti serve una policy corrente caricata e verificabile. Per diagnosticare una lavorazione servono almeno ID catena/run o articolo/revisione da ricondurre alla catena; i dati di una vecchia esecuzione possono non avere tutti i record introdotti dalle versioni successive.

Scenario	Scelta	Effetto e limite
Cambiare quanti cicli primari possono tentare le nuove catene	Massimo cicli di correzione primaria	Cambia il massimale, non il modello né le catene già avviate.
Fermare nuovi cicli di un ruolo	Impostare a zero il relativo massimale	Disabilita quei cicli senza approvare automaticamente gli articoli.
Cambiare modello o ragionamento	Route dell'attività in Models	Intervento distinto dalla policy dei massimali.
Catena esistente ferma per capacità/budget	Leggere piano e azione amministrativa proposta	Aumentare i due contatori selettivi non risolve necessariamente il blocco del piano.
Chiamata AI con esito sconosciuto	Riconciliare risposta/tentativo	Evita un nuovo invio prima di determinare l'esito già prodotto.
Articolo generato ma non pubblicato	Controllare decisione applicata e gate editoriali	La generazione o il raggiungimento dei massimali non autorizza il rilascio.

Sequenza di elaborazione

1. Acquisizione e rilevanza: parsing strutturato, analisi delle parti irrisolte e della copertura; la rilevanza usa la route di revisione.
2. Originale italiano: generazione e revisione del canonico IT. La revisione iniziale ammette fino a tre valutazioni e due patch circoscritte, separate dai cicli selettivi.
3. Traduzione inglese: titolo, sommario, corpo e testi dei tag derivano dal canonico italiano valido. Identificatori tecnici, nomi ufficiali e citazioni originali vengono preservati.
4. Controlli e gate: la revisione editoriale resta sul canonico italiano. Completezza della traduzione, mapping dei tag, IOC, CVE e riferimenti sono soggetti a controlli deterministici prima dei gate di rilascio.

L'inglese non esegue una seconda revisione semantica editoriale equivalente a quella italiana. Un articolo generato o tradotto non è automaticamente approvato o pubblicato.

Limiti delle correzioni automatiche

Campo	Range / default	Significato
Massimo cicli di correzione primaria (maxLunaSelectiveCorrectionCycles)	Intero 0–5; default 2	Numero massimo di cicli selettivi primari per catena articolo.
Massimo cicli di escalation (maxTerraSelectiveCorrectionCycles)	Intero 0–5; default 2	Numero massimo di cicli di escalation per la stessa catena.

I nomi tecnici dei campi identificano ruoli del flusso; il modello effettivo è quello della route configurata. Un ciclo può comprendere passaggi IT ed EN. Le unità sono cicli per catena, non chiamate AI e non tentativi di coda.

Zero disabilita i nuovi cicli del ruolo indicato. Esaurire i cicli primari non attiva necessariamente l'escalation: questa dipende dai propri gate e può intervenire anche prima dell'esaurimento. Esaurire i due massimali non autorizza approvazione o pubblicazione.

Generazione iniziale, revisione e patch canonica, traduzione EN, retry tecnici e retry per output troncato non vengono conteggiati come cicli selettivi. La revisione può aumentare il proprio budget di output 4k/8k/12k: non convertire questi contatori in una stima economica senza la contabilità effettiva.

Modificare la policy

1. Apri Modifica limiti del flusso e leggi versione, data e digest correnti.
2. Imposta i due massimali con numeri interi da 0 a 5. Se vuoi modificare un solo ruolo, conserva il valore dell'altro.
3. Controlla il riepilogo prima/dopo e premi Salva limiti.
4. Attendi la rilettura verificata di versione e digest. Se la UI segnala una verifica incompleta, usa Riprova verifica senza ripetere il salvataggio.
5. Controlla la policy attiva in Models. Nelle catene avviate successivamente, confronta la versione acquisita e i massimali mostrati nel dettaglio.

La versione è acquisita alla prima generazione della catena e propagata ai suoi step: la modifica vale per le nuove catene, quelle già avviate conservano la policy acquisita. Una vecchia catena con i precedenti massimali non dimostra un salvataggio fallito.

Il salvataggio verifica la versione attesa e rilegge versione/digest. Un conflitto conserva la bozza e permette di caricare/confrontare il valore remoto. Se la modifica è stata inviata ma non verificata, ripeti soltanto la lettura. Se nel frattempo esiste una versione più nuova, la UI segnala che il tuo salvataggio è stato superato: confronta i valori correnti prima di un'altra modifica.

Elenco e dettaglio delle catene

La tabella mostra catena, revisione corrente, stato osservato, cicli primari/escalation usati e massimi. Carica altre continua la paginazione; Aggiorna rilegge i dati. Il filtro stato generale e il periodo del riepilogo non si applicano a questa vista.

Il dettaglio distingue:

Dato	Uso
Chain ID / Run ID / revisione	Collega la catena alle esecuzioni e al contenuto effettivo.
Ultimo stato e passaggio osservati	Fotografia dell'ultima osservazione, con data; non dedurre aggiornamenti successivi.
Categoria errore	Classifica la causa del blocco.
Stato traduzione EN	Disponibilità della traduzione per la revisione osservata.
Policy acquisita e digest	Limiti realmente usati dalla catena.
Cicli usati / rimanenti / massimi	Contatori distinti per primario ed escalation.
Plafond episodio	Limite economico registrato, visualizzato in USD.
Speso / prenotato / incerto / disponibile	Contabilità distinta: un tentativo di costo incerto non è gratuito né definitivamente contabilizzato.
Token input/output	Consumi riportati per i tentativi; dato assente non equivale a zero.

Diagnosticare una catena bloccata

1. Apri Executions → Catene editoriali, individua la catena e premi Dettagli.
2. Premi Aggiorna e annota revisione corrente, ultimo stato/passaggio, data osservazione e categoria errore.
3. Leggi prima gli eventuali fermi tecnici e il piano canonico: indicano se l'invio al provider è avvenuto, quale budget è prenotato e quale azione è ammessa.
4. Controlla poi la decisione applicata e i rilievi. Distingui errore operativo, valutazione inconcludente, correzione fattuale e suggerimento non bloccante.
5. Verifica la traduzione EN rispetto alla revisione corrente. Un originale IT disponibile non garantisce che l'artefatto EN della stessa revisione sia pronto.
6. Segui l'azione proposta nel workspace competente e rileggi la stessa catena. La verifica finale è un nuovo stato coerente e osservato, non la sparizione di un filtro o la creazione di una run duplicata.

Diagnostica della rilevanza e della generazione

Il pannello mostra titolo, origine del titolo (bozza esaminata, bozza iniziale o output salvato), fonti del bundle e valutazione di rilevanza. Le decisioni sono:

• publish: selezionato per la generazione, non già pubblicato;
• context_only: usato soltanto come contesto;
• defer_until_advisory: in attesa di un advisory;
• reject: escluso dal filtro di rilevanza.

Motivazione, confidenza e segnali spiegano la valutazione registrata. Un elenco marcato parziale mostra le prime 20 fonti; non rappresenta necessariamente tutto il bundle.

Piano di revisione canonica

Indicatore / blocco	Significato e azione
Sezioni esaminate / totali; unità rimanenti	Avanzamento del piano, non numero di articoli.
Invio al provider tentato	No conferma che quella chiamata di revisione non è stata inviata; sconosciuto non equivale a no.
Tentativi effettivi / esito ignoto	Distingue tentativi attestati da esiti ancora da riconciliare.
Costo prenotato / massimo / consumato noto	Budget del piano; i valori interni in micro-USD sono mostrati come USD.
capacity_blocked	Capacità del piano insufficiente. Seguire l'azione amministrativa proposta.
budget_blocked	Budget insufficiente: non rilanciare assumendo che il tentativo precedente non abbia avuto costo.
pricing_or_capability_unknown	Prezzi, tokenizer o capacità della route non qualificati; completare la qualifica prima della nuova ammissione.

Il piano può richiedere configurazione della route, anteprima di recupero selettivo o riconciliazione di un esito ignoto. Digest, fase e misura/limite permettono di identificare esattamente il piano bloccato.

Decisione editoriale applicata

La decisione applicata dal server è distinta dal verdetto originale del modello.

Esito	Significato
accepted	Valutazione accettata.
accepted_with_advisories	Accettata con suggerimenti non bloccanti.
review_required	Necessaria correzione fattuale.
inconclusive	Evidenza insufficiente a una decisione conclusiva.
operational_failure	Errore operativo nella valutazione.

Il controllo può essersi fermato al preflight deterministico, alla proiezione degli IOC oppure essere arrivato alla revisione fattuale AI. La proiezione può rimuovere menzioni IOC non autorizzate e riverificarle prima di avviare la revisione AI.

Ogni rilievo conserva disposizione (blocking, advisory, inconclusive), risoluzione (open, resolved, dismissed_false_positive), gravità originale, codice, campo/lingua, citazione contestata, proposizione, decisione server, regola e riferimenti alle evidenze. I dettagli distinguono motivazioni di revisione globale e di sezione. Se l'elenco è troncato, mostra i primi 20 elementi.

I contatori iniziali — operazioni semantiche, tentativi provider, retry di output, retry tecnici, cache hit, massimi patch/arbitraggi — restano separati dai cicli selettivi. Digest di contenuto, policy ed evidenze collegano la decisione al materiale esaminato. Un'esecuzione storica senza questo record non attesta retroattivamente la nuova policy.

Fermi tecnici

Azione indicata	Procedura corretta
retry_checkpoint	Riprendere il checkpoint dopo il ripristino DB riusando le risposte salvate.
reconcile_commit	Verificare se la scrittura è avvenuta prima di riprendere; non rigenerare il testo alla cieca.
reconcile_provider_response	Recuperare l'esito della chiamata AI prima di autorizzare un nuovo invio.
inspect_response_contract	Esaminare la risposta e il contratto non rispettato.

La UI espone checkpoint e contatore di riprese DB, fino a 3, quando disponibili. Errori prima della revisione o nella traduzione richiedono recupero limitato o intervento amministrativo; non producono un'approvazione implicita.

Verifica sorgente: policy editoriale agenti, elenco catene, diagnostica, piano e decisione applicata; snapshot del 10 novembre 2026.