La pulizia notturna che cancellava lavoro pronto

In breve. La notte del 10 ottobre 2026 la mia routine di pulizia automatica ha cancellato un posto di lavoro con 5 lavori finiti e verificati, perché dal suo punto di vista sembrava tutto già salvato. Non lo era: l'invio era stato rifiutato e le modifiche erano ancora lì, non salvate. In un giorno ne sono uscite due correzioni e due regole che ora valgono per ogni pulizia automatica che scrivo.

Cinque lavori finiti alle quattro e mezza, spariti alle sei

Fra le 02:09 e le 04:31 di quella notte un giro di lavoro aveva completato e verificato 5 lavori nel suo posto di lavoro: 4 articoli nuovi e un aggiornamento. I receipt di riprova dicevano "npm run verify PASS" su 189 pagine. Poi l'invio era stato rifiutato dalla sandbox, e i 5 lavori erano rimasti parcheggiati con le modifiche non salvate: finiti, verificati, e presenti solo in quella cartella.

Alle 05:56 è passata la pulizia notturna, la routine che tiene in ordine i posti di lavoro. La sua regola era semplice: se il ramo sembra già unito e la testa è uguale a quella principale, rimuovi il posto di lavoro con --force. Quel posto non aveva potuto salvare niente, quindi aveva zero commit, quindi sembrava perfettamente unito. Il giro ha rimosso 6 posti di lavoro, e quello era fra loro. Con lui, i 5 lavori verificati.

"Sembra unito" non vuol dire "è salvato"

La causa sta in una riga: la pulizia guardava lo stato del ramo invece di guardare la cartella. In un sistema dove il lavoro può restare non salvato, "unito" non vuol dire "salvato". Un posto che non può salvare ha zero commit per costruzione, e zero commit sembra sempre il segnale di "niente da perdere". Era il segnale opposto: c'era tutto da perdere, perché l'unica copia stava lì.

È lo stesso errore che avevo già visto altrove, con segni diversi: fidarsi dello stato dichiarato invece di controllare la cosa vera. Ne avevo scritto a proposito del supervisore che si fidava dell'orologio dell'agente, dove il dato del controllato passava per misura. Qui il ramo diceva "sono a posto" e nessuno aveva guardato la cartella. La lezione si scrive in generale: mai decidere una cancellazione leggendo un indicatore indiretto quando puoi leggere la cosa diretta.

Il --force ha fatto il resto. Senza, la rimozione avrebbe trovato le modifiche e si sarebbe fermata da sola. Con --force non c'è niente che si ferma: è un ordine di non controllare. Su una pulizia automatica, che gira di notte senza nessuno che guarda, è l'opzione sbagliata per definizione.

Due correzioni nello stesso giorno

La prima correzione è arrivata lo stesso 10 ottobre, a mano: la pulizia ora salta ogni posto di lavoro con modifiche, anche non tracciate, e niente più --force. La sera stessa, alle 21:40, ha saltato due posti di lavoro con modifiche, da 12 e 7 file. La pulizia era tornata a fare il suo lavoro senza cancellare quello degli altri.

La seconda correzione è quella stabile, entrata nel framework quello stesso giorno: prima di liberare un posto di lavoro con modifiche, il sistema lo salva in un ramo di salvataggio sul repository e ne lascia traccia nel diario. Il primo caso reale è arrivato la sera stessa, con il ramo caricato sul remoto. Da lì in poi la pulizia non decide più "tieni o butta": decide "salva e poi libera". La rete sta sotto la decisione, non sopra.

Di come converto ogni incidente in regola con test ho scritto nei marginal gains delle macchine: questo episodio è il caso da manuale, perché la regola uscita ("salva prima di liberare") ora gira da sola ogni notte. E il disegno generale, quello in cui la notte è un turno di lavoro con il suo diario, è la fabbrica che ripara il software mentre dormiamo.

Le due regole che mi tengo

Prima regola: una pulizia automatica guarda la cartella, non lo stato. Se ci sono modifiche, il posto di lavoro è vivo, punto. Qualunque indicatore dica il contrario è un bug dell'indicatore, non un permesso.

Seconda regola: niente cancellazioni senza rete. Prima di liberare qualcosa che contiene lavoro, il sistema ne fa una copia da qualche parte e lo dice nel diario. Costa poco e toglie di mezzo un'intera classe di incidenti: quelli in cui la macchina aveva ragione secondo i suoi dati e torto secondo la realtà.

Sul disegno del controllo ho scritto che l'autonomia nasce progettando il controllo: queste due regole sono quel principio applicato alla manutenzione. La pulizia non è meno autonoma di prima. Gira ogni notte da sola, come prima. Solo che ora la sua autonomia ha un pavimento: sotto una certa linea non può scendere, qualunque cosa dica lo stato.

Fatti e limiti

FACT. La notte del 10 ottobre 2026, fra le 02:09 e le 04:31, un giro di lavoro ha completato e verificato 5 lavori (4 articoli nuovi e un aggiornamento) con "npm run verify PASS" su 189 pagine; l'invio è stato rifiutato e le modifiche sono rimaste non salvate.

FACT. Alle 05:56 dello stesso giorno la routine di pulizia ha rimosso 6 posti di lavoro, fra cui quello con i 5 lavori, con la regola "ramo unito e testa uguale alla principale, rimuovi con --force"; un posto che non può salvare ha zero commit e sembra sempre unito.

FACT. Sempre il 10 ottobre 2026 lo script è stato corretto: salta i posti di lavoro con modifiche e non usa più --force; alle 21:40 ha saltato due posti con modifiche, da 12 e 7 file.

FACT. Lo stesso giorno è entrata nel framework la correzione stabile: prima di liberare un posto di lavoro con modifiche, il sistema lo salva in un ramo sul repository e ne lascia traccia nel diario; il primo caso reale è della sera stessa.

INTERPRETATION. La causa è fidarsi dello stato del ramo invece che della cartella: in un sistema dove il lavoro può restare non salvato, "unito" non vuol dire "salvato".

INTERPRETATION. Le modifiche perse erano piccole e rifacibili: il danno è stato tempo e fiducia, non dati irrecuperabili. Le due regole ("guarda la cartella", "salva prima di liberare") sono la mia lettura di cosa impedisce la prossima volta, non una garanzia.

Domande frequenti

Cosa aveva cancellato esattamente la pulizia?

Un posto di lavoro con 5 lavori finiti e verificati della notte del 10 ottobre 2026: 4 articoli nuovi e un aggiornamento. Le modifiche non erano salvate perché l'invio era stato rifiutato, quindi l'unica copia stava in quella cartella.

Perché il sistema pensava che fosse tutto salvato?

Perché guardava lo stato del ramo: zero commit sembra "niente da perdere". Ma quel posto non aveva potuto salvare per costruzione, quindi zero commit era il segnale opposto. Nessuno aveva guardato la cartella vera.

Cosa impedisce che succeda di nuovo?

Due cose, entrambe in produzione dal 10 ottobre 2026: la pulizia salta i posti di lavoro con modifiche e non usa più --force; e prima di liberare un posto con modifiche il sistema lo salva in un ramo sul repository con traccia nel diario.