I falsi gate owner: quando la factory chiede all'umano ciò che può decidere da sola

In breve. La mia factory si fermava per chiedere all'owner cose che nessun owner doveva decidere: code di CI, meccaniche del loop, strati del selettore. Ogni fermata sembrava prudenza, ed era un difetto di affidabilità: escalation eccessiva quanto autonomia eccessiva. L'hanno sistemato due PR del framework, la #294 e la #309, e i loro corpi contengono tutti i numeri di questo pezzo. Pubblicato il 5 ottobre 2026.

Una voce uscita dal blocco senza che nessuno rispondesse

La prova che il problema era reale sta in una riga di diario: la voce backlog:3484c931ffc2 è uscita da HUMAN_BLOCKER senza che nessun owner abbia mai risposto. Il corpo della PR #294 la cita come prova, e aggiunge il secondo sintomo: la PR 287 rimasta aperta invece di forzare un merge rosso. Due fatti, stesso diagnóstico: il sistema chiedeva un permesso che non serviva e, non ricevendolo, restava fermo o veniva aggirato.

Il meccanismo era questo. Il worker incontrava una scelta tecnica — come riconciliare decisioni parcheggiate, come gestire una coda CI, come riprendere un loop — e invece di deciderla dentro i guardrail la confezionava da "decisione per l'owner". La Owner View mostrava domanda, opzioni e raccomandazione su cose tipo permessi di sandbox o wiring interno. L'owner, giustamente, non rispondeva a domande che non richiedevano nessun giudizio suo. Il confine restava parcheggiato. Prudenza apparente, fermo reale.

Cosa ha cambiato la PR #294

La #294, "False owner gates", ha fatto tre cose, tutte riportate nel suo corpo. Primo: il comando reconcile-decisions copre DESIGN e OPS_OR_COST con un classificatore fail-closed, e i pattern owner-delivery e owner-action sono stati aggiunti dopo che due falsi positivi erano stati presi in dry-run — cioè il classificatore ha sbagliato prima in prova, ed è stato corretto prima di decidere davvero. Secondo: le righe di verifica dicono cosa è fallito, e i fallimenti di infrastruttura o ambiente non fanno mai ricorrere il confine. Terzo: la verifica mirata è tsc pulito più 83 test verdi.

Il punto che mi interessa è il secondo: la riga che dice cosa è fallito. Un gate che non distingue un test rotto da un runner spento tratta ogni rosso come un verdetto sul codice, e chiede all'umano di decidere su un'informazione che non ha. Scrivere il motivo del fallimento nella riga è quello che permette al giro dopo di decidere da solo.

Cosa ha chiuso la PR #309

La #309, "Mint-side technical stakes", ha spostato il controllo al momento del conio: il contenuto tecnico — meccaniche del loop, strati del selettore, dispatch dell'esecuzione — non può proprio coniare decisioni che richiedono l'owner. Classificatore più rifiuto al conio più 6 golden test, con tsc pulito e suite delegation e mint verdi.

È la differenza fra chiudere un buco e togliere la possibilità del buco. La #294 riconcilia le righe parcheggiate male; la #309 impedisce di parcheggiarne di nuove. Insieme dicono una regola sola: l'owner gate scatta solo con un impatto reale per chi usa il prodotto, tutto il resto si decide dentro l'autonomia e si registra come fatto, non come domanda.

La regola che ne ho ricavata

Escalation eccessiva e autonomia eccessiva sono lo stesso difetto visto da due lati: in un caso il sistema chiede permessi che non servono e si ferma, nell'altro agisce dove dovrebbe chiedere e rompe. La discriminante non è il coraggio, è l'impatto: se la scelta cambia qualcosa per l'utente — vede, paga, deve fare qualcosa — la domanda all'owner è dovuta; se riguarda scaffali di implementazione, è il worker che deve decidere, con i guardrail e la provenance scritta.

Da quando applico questa regola, le mie mattine hanno meno parcheggi e più lavoro: ne ho scritto qui, sul controllo progettato invece che eliminato, e qui, sul singolo posto di guida. Questo pezzo è il corollario scomodo: anche chiedere troppo è un modo di sbagliare, e si misura allo stesso modo — dai confini che restano fermi senza motivo, come quel backlog che non diceva quali problemi fossero veri.

Domande frequenti

Ma chiedere all'umano non è sempre più sicuro?

No: è più sicuro solo quando l'umano ha un giudizio che al sistema manca. Su una coda CI o un wiring interno l'owner non aggiunge informazione, aggiunge solo attesa. La sicurezza sta nel decidere dove l'informazione è, non nel chiedere sempre.

Come si capisce se un gate è falso?

Dal diario, a posteriori: se il confine è uscito dal blocco senza risposta owner — come quella voce citata nella PR #294 — il gate non serviva. A priori, dalla domanda: se non sai dire cosa cambia per l'utente finale, non è una decisione owner.

Perché il classificatore è fail-closed?

Perché l'errore costoso è far passare una vera decisione owner come tecnica, non il contrario. I pattern dell'owner vincono sempre sui pattern tecnici: meglio una domanda di troppo, che resta visibile, che un'autorizzazione data in silenzio.