Ferma o finita? Una domanda all'owner fermava tutta la fabbrica

In breve. Per quasi un giorno la mia factory è rimasta ferma su una domanda che solo io potevo chiudere, pubblicare due post, mentre altro lavoro aspettava. Archiviata la voce, il verdetto si è rovesciato: niente da fare da sola. In mezzo, una terza condizione: lavoro in pausa su condizioni che nessuno avrebbe soddisfatto. Bloccata, finita e finta fine sono tre stati diversi, e il cockpit li mostrava tutti come "Ferma". Pubblicato l'11 ottobre 2026.

Bloccata: una domanda vera fermava anche il resto

Dal 9 ottobre 2026 alle 20:20Z al 10 ottobre alle 15:00Z la watch ha registrato 101 giri con decisione HUMAN_BLOCKER, più due CONTINUE_REQUIRED alle 00:00Z e alle 08:00Z. In tutta la finestra la voce attiva era una sola, "almeno 2 canali attivati": la domanda chiedeva all'owner di pubblicare un post LinkedIn e uno DevTo, cosa che la fabbrica non poteva fare. Intanto 5 lavori pronti restavano esclusi dal recupero perché parcheggiati all'invio.

Qui sta la differenza rispetto ai falsi gate owner: lì le domande all'owner erano scelte tecniche travestite, e il difetto era chiedere. Qui la domanda era vera, pubblicare toccava davvero a me, e il difetto era un altro: una domanda locale, relativa a una voce sola, fermava anche il lavoro che non la riguardava. Il confine parcheggiato era uno; il fermo era di tutta la fabbrica.

Il 10 ottobre alle 15:02:20Z ho archiviato la voce, decidendo niente LinkedIn e niente DevTo. Al giro dopo, alle 15:20Z, il verdetto si è rovesciato: NO_ACTIONABLE_WORK. In coda c'erano 94 piani di prova in attesa di una data, 37 voci in attesa di una prova, 19 in attesa di verifica, 5 con i tentativi esauriti e 1 decisione di costo. Nessuna voce lavorabile.

Finita: niente da fare da sola, e dirlo chiaro

"Finita" è uno stato legittimo: tutto è in attesa di dati, di una verifica indipendente o dell'owner, e non c'è niente che la fabbrica possa fare da sola. Il problema non era lo stato. Fino a un giro prima la stessa luce diceva la stessa cosa per il motivo opposto, una domanda in attesa di risposta; e il giorno stesso l'aveva detta per un terzo motivo ancora, un run al lavoro.

Quel giorno il cockpit diceva "Ferma" mentre un run stava lavorando. La luce considerava la fabbrica al lavoro solo se l'ultima ricevuta aveva al massimo 20 minuti, e un run che scrive un articolo resta più a lungo senza ricevute. La correzione è arrivata con la PR #462 del framework (merge ab75387, 10 ottobre 2026 alle 19:19:14Z): luci e frase leggono lo stato del run, e da ferma la fabbrica dice in una riga perché. La stessa lezione del Governor che aveva letto male un blocco globale: un'informazione che governa deve portare la sua scala in un campo che una macchina sa leggere; qui, quale fermo è.

Finta fine: in pausa su una condizione che nessuno avrebbe soddisfatto

Il terzo stato è quello che somiglia di più a "finito" e lo è di meno. L'hub loops era in pausa dal 6 ottobre 2026 alle 00:26Z su un piano di prova con condizione "Altro run pubblica il pillar madre e definisce il cluster (solo contesto)", vera quel giorno. Il pillar madre ha passato la verifica sul sito live l'8 ottobre alle 19:35Z, ma il piano non si è riletto prima della sua scadenza, il 13 ottobre. I 6 articoli del cluster aspettavano a loro volta "Altro run pubblica hub loops (solo contesto)".

Il 10 ottobre alle 16:19Z ho riaperto hub e articoli. Fra le 16:43 e le 16:47Z la fabbrica ha rimesso in pausa tutti e 6 gli articoli sulla stessa condizione, con scadenza al 17 ottobre. L'hub era arrivato pronto con i controlli verdi, ma alle 16:41Z chiedeva: "non riesco a salvarlo per un blocco dei permessi. Come procedo?".

Nessuno avrebbe soddisfatto la condizione che teneva fermo tutto: era segnata come solo contesto, e il mondo era già cambiato sotto di essa senza che il piano se ne accorgesse. La finta fine non si scioglie da sola: si scioglie rileggendo il piano quando il mondo cambia, non quando scade il calendario.

La sera stessa la storia si è chiusa dal lato opposto: la PR #464 del framework (merge 25c0e8d, 10 ottobre alle 19:55:13Z) ha aggiunto l'opt-out per pack della sandbox, che ho attivato sul sito alle 19:57Z. Dopo un retry registrato alle 20:13:44Z, la fabbrica ha scritto la correzione dell'hub alle 20:20Z dal branch factory/run-5dd5cfe6; la PR #101 del sito è stata mergiata alle 20:25:59Z; merge e rilascio sono nel diario alle 20:26Z; la verifica indipendente è passata alle 20:59Z. Nessun passo manuale di pubblicazione o registrazione. L'11 ottobre alle 06:28Z, con l'hub online, ho riaperto i 6 articoli.

Cosa serve perché la fabbrica dica "ho finito"

Tre stati, tre reazioni diverse. Bloccata: isolare la domanda, così il resto procede. Una voce parcheggiata non deve fermare il recupero delle altre. Finita: mostrare la coda onestamente, con i conteggi di cosa aspetta cosa. Finta fine: rileggere i piani quando il mondo cambia, perché una condizione soddisfatta e mai riletta è indistinguibile dal lavoro vero in attesa.

Il filo comune con gli altri due pezzi è il controllo progettato invece che eliminato: i falsi gate insegnano a non chiedere all'owner ciò che si può decidere da soli, il Governor insegna a scrivere la scala di ogni informazione, e qui la lezione è scrivere lo stato: bloccata su cosa, finita perché, in pausa fino a quando. Una fabbrica che sa dire in che stato è può anche uscirne da sola; una che dice solo "ferma" aspetta sempre qualcuno.

Fatti e limiti

FACT: dal 2026-10-09 20:20Z al 2026-10-10 15:00Z, 101 giri HUMAN_BLOCKER più 2 CONTINUE_REQUIRED (00:00Z e 08:00Z), voce attiva "almeno 2 canali attivati", 5 lavori esclusi dal recupero.

FACT: 2026-10-10 15:02:20Z archiviazione owner della voce; 15:20Z NO_ACTIONABLE_WORK con 94 piani in attesa di data, 37 voci in attesa di prova, 19 in attesa di verifica, 5 con tentativi esauriti, 1 decisione di costo.

FACT: cockpit "Ferma" durante un run al lavoro per la regola dei 20 minuti; corretto da agentic-factory PR #462 (merge ab75387, 2026-10-10 19:19:14Z).

FACT: hub loops in pausa dal 2026-10-06 00:26Z; pillar verificato live 2026-10-08 19:35Z; piano non riletto prima della scadenza 2026-10-13; 6 articoli in attesa dell'hub.

FACT: 2026-10-10 16:19Z riapertura owner; 16:41Z domanda dell'hub sul blocco dei permessi; 16:43-16:47Z nuova pausa dei 6 articoli con scadenza 2026-10-17.

FACT: agentic-factory PR #464 (merge 25c0e8d, 2026-10-10 19:55:13Z), opt-out attivo 19:57Z, retry 20:13:44Z, fix hub 20:20Z, sito PR #101 mergiata 20:25:59Z, diario 20:26Z, verifica 20:59Z; riapertura articoli 2026-10-11 06:28Z.

INTERPRETATION: "ferma" copriva tre stati, bloccata, finita e finta fine, più un run al lavoro letto come fermo; ognuno chiede una reazione diversa.

INTERPRETATION: la finta fine si previene rileggendo i piani al cambiamento del mondo, non alla scadenza; e una domanda owner vera va isolata perché non fermi il lavoro che non la riguarda. Due giorni di episodi non fanno una statistica: sono la prova che la distinzione esiste e ha già pagato una volta.

Domande frequenti

Come si distingue bloccata da finita?

Dalla coda: bloccata significa che una domanda aspetta una risposta e intanto trattiene altro lavoro; finita significa che ogni voce aspetta dati, verifica o owner e non c'è niente da fare da soli. Il 10 ottobre alle 15:20Z la coda diceva la seconda cosa con numeri precisi, 94, 37, 19, 5 e 1. Fino a un giro prima la stessa luce copriva la prima.

Perché la pausa non si è sciolta quando il pillar è passato?

Perché il piano si rilegge alla scadenza: il pillar è passato l'8 ottobre, la scadenza era il 13, e la condizione, segnata "solo contesto", non sarebbe stata soddisfatta da nessuno. La rilettura va agganciata agli eventi che la rendono possibile.

Cosa ha cambiato la PR #462 nel cockpit?

Prima la luce "al lavoro" dipendeva dall'età dell'ultima ricevuta, con soglia 20 minuti: un run che scriveva un articolo risultava fermo. Ora luci e frase leggono lo stato del run, e quando la fabbrica è ferma dice in una riga perché: quale dei fermi è.