Simon Willison ha riscontrato errori CI con Ruff v0.16.0. Le impostazioni predefinite erano cambiate

Simon Willison ha visto fallire diversi job CI dopo che Ruff v0.16.0 ha ampliato le sue regole di lint predefinite da 59 a 413. La dipendenza di sviluppo Ruff non vincolata ha introdotto silenziosamente la nuova release in progetti Python esistenti.

Astral ha rilasciato la versione il 23 luglio 2026. Due giorni dopo, Willison ha descritto come l'aggiornamento fosse arrivato nelle sue build senza un upgrade intenzionale. I fallimenti hanno trasformato una release di un linter in un avvertimento concreto sulla gestione delle dipendenze.

Il conflitto centrale non riguarda un linting più rigoroso contro codice meno rigoroso. Riguarda la maggiore sicurezza senza configurazione di Ruff rispetto alla stabilità che gli sviluppatori si aspettano da repository invariati. Questa tensione è rilevante ovunque la CI installi a ogni esecuzione gli strumenti di sviluppo più recenti disponibili.

Ruff v0.16.0 ha cambiato il significato di “predefinito”

Il cambiamento più significativo di Ruff v0.16.0 non è un nuovo comando. È una definizione molto più ampia di ciò che i progetti non configurati dovrebbero considerare un errore.

Ruff è un linter e formatter Python scritto in Rust. Un linter analizza il codice sorgente alla ricerca di errori, pattern sospetti e problemi di stile selezionati, senza eseguire il programma.

Prima di questa release, Ruff abilitava 59 regole quando un progetto non forniva una selezione di lint esplicita. La versione 0.16.0 abilita 413 regole nelle stesse condizioni, secondo la guida alla migrazione di Astral.

Si tratta di un aumento di 354 controlli attivi. Significa inoltre che un'installazione predefinita di Ruff ora valuta quasi sette volte più regole rispetto a prima.

Anche il catalogo complessivo è cresciuto. Ruff supportava 708 regole quando le impostazioni predefinite sono cambiate l'ultima volta, nella versione 0.1.0. Astral afferma che la raccolta attuale contiene 968 regole.

Le vecchie impostazioni predefinite selezionavano principalmente parti di Pyflakes e pycodestyle. I progetti potevano adottare Ruff senza dover fare subito scelte dettagliate sulle sue numerose famiglie di regole integrate.

Questa base prudente ha aiutato Ruff a integrarsi nei repository esistenti. Ha però anche creato un divario crescente tra ciò che lo strumento sapeva e ciò che segnalava automaticamente.

Astral ha colmato gran parte di quel divario nella versione 0.16.0. Le nuove impostazioni predefinite attingono da famiglie aggiuntive, tra cui flake8-bugbear, pyupgrade e la categoria RUF di Ruff.

Flake8-bugbear si concentra su probabili bug e pattern di progettazione discutibili. Pyupgrade identifica pattern di sintassi e della libreria standard che possono essere modernizzati per la versione Python supportata da un progetto.

L'elenco delle regole predefinite ora include controlli in grado di evidenziare problemi di sintassi ed errori immediati a runtime. Non si tratta soltanto di preferenze su spaziatura o convenzioni di denominazione.

Questa distinzione spiega perché i fallimenti della CI causati da Ruff possano meritare attenzione. Alcune nuove segnalazioni rivelano difetti che prima passavano solo perché Ruff non abilitava automaticamente il rilevatore pertinente.

Altre segnalazioni riguarderanno manutenibilità, modernizzazione o pattern che un team accetta intenzionalmente. Un insieme predefinito più ampio non può conoscere i requisiti di compatibilità o le convenzioni progettuali di ogni repository.

Ruff v0.16.0 cambia quindi due aspetti contemporaneamente. Aumenta il rilevamento automatico dei difetti e sposta più decisioni di policy nel primo upgrade successivo al 23 luglio.

La release rende inoltre predefinita la formattazione di blocchi di codice Python all'interno di file Markdown. I blocchi delimitati supportati includono python, py, python3, py3, pyi e pycon.

Questo comportamento è rilevante per repository che contengono documentazione, tutorial o notebook Quarto. Un controllo di formattazione può ora individuare modifiche al di fuori dei convenzionali file .py.

Le note di rilascio di Ruff descrivono inoltre nuovi commenti di soppressione e output diagnostici più ricchi. Questi miglioramenti aiutano gli sviluppatori a gestire le ulteriori segnalazioni una volta che compaiono.

Il cambiamento di portata resta l'evento principale della migrazione. Un comando che si comportava in modo prevedibile la scorsa settimana può oggi restituire un codice di uscita diverso da zero sullo stesso identico codice sorgente.

Perché i fallimenti CI di Simon Willison sono importanti

L'esperienza di Simon Willison mostra come un aggiornamento di uno strumento per sviluppatori possa modificare la policy effettiva di un repository senza modificare il repository stesso.

Willison è uno sviluppatore e autore indipendente noto per progetti che coinvolgono Python, strumenti per i dati e IA generativa. All'inizio della sua carriera ha anche co-creato il framework web Django.

Il 25 luglio, Willison ha scritto che i suoi “vari job CI” avevano iniziato a fallire. Ha ricondotto i fallimenti alle nuove impostazioni predefinite di Ruff e a una dipendenza di sviluppo "ruff" non vincolata.

Il suo resoconto su Ruff offre alla release una prospettiva concreta da utente. Il codice del repository non era necessariamente peggiorato, ma il suo ambiente di convalida era cambiato sotto di esso.

Un job CI, o job di integrazione continua, esegue controlli automatici ogni volta che gli sviluppatori propongono o uniscono modifiche. I team dipendono da risultati coerenti per decidere se il codice è sicuro da accettare.

Se un job installa ruff senza un vincolo di versione, il risolutore di pacchetti può selezionare la release più recente disponibile. La build successiva potrebbe quindi applicare un comportamento che nessun maintainer ha esaminato esplicitamente.

È facile liquidare questa modalità di errore perché Ruff è solitamente una dipendenza di sviluppo. Normalmente non viene distribuito all'interno dell'applicazione che serve gli utenti.

Tuttavia, le dipendenze di sviluppo controllano se il software può attraversare la sua pipeline di distribuzione. Un nuovo codice di uscita del linter può bloccare una pull request, fermare una release o richiedere ore di indagine.

L'incidente rivela anche una distinzione fuorviante tra dipendenze runtime e strumenti. I pacchetti runtime influenzano ciò che fa il software distribuito, mentre gli strumenti influenzano la possibilità stessa degli sviluppatori di distribuirlo.

Entrambi possono introdurre cambiamenti operativi. Agiscono semplicemente in momenti diversi del sistema.

L'esperienza di Willison è particolarmente utile perché le regole ampliate di Ruff funzionavano come previsto dalla release. I fallimenti non richiedevano un pacchetto corrotto, un registry compromesso o un installer difettoso.

Lo strumento si è installato correttamente. Ha ispezionato correttamente il progetto secondo la sua nuova policy. La CI è fallita perché quella policy differiva da quella su cui il repository aveva implicitamente fatto affidamento.

Questo ne fa un problema di riproducibilità. Una build o un controllo riproducibile dovrebbe produrre risultati equivalenti a partire dallo stesso codice sorgente e dagli stessi input dichiarati.

“L'ultima versione di Ruff” non è un input stabile. È una richiesta in movimento il cui significato dipende dal momento in cui un gestore di pacchetti la risolve.

I lockfile e i vincoli esatti possono rendere esplicito quell'input. I servizi di aggiornamento possono quindi proporre upgrade controllati, consentendo ai maintainer di esaminare le nuove diagnostiche prima di unire il cambio di versione.

La lezione va oltre Ruff. Formatter, controllori di tipo, test runner, generatori di documentazione e scanner di sicurezza possono tutti rivedere le impostazioni predefinite tra una release e l'altra.

Un repository con librerie applicative bloccate ma strumenti di sviluppo fluttuanti resta solo parzialmente riproducibile. Il suo comportamento in produzione può rimanere fisso mentre cambia il suo percorso verso la produzione.

Questa preoccupazione è particolarmente rilevante per i sistemi di programmazione automatizzati. Gli agenti eseguono spesso i controlli del repository, ne interpretano l'output e modificano il codice finché ogni controllo non viene superato.

Se gli strumenti dietro quei controlli cambiano inaspettatamente, l'agente si trova davanti a un obiettivo mobile. Potrebbe generare modifiche non necessarie o sopprimere segnalazioni senza capire perché siano apparse.

I team che costruiscono una base di conoscenza ingegneristica ricercabile possono conservare le decisioni sugli upgrade insieme alla configurazione e alla cronologia della CI. Questo contesto aiuta i futuri maintainer a distinguere la policy intenzionale dalla deriva accidentale.

Simon Willison ha evidenziato il nuovo compromesso di Ruff

Le impostazioni predefinite più ampie di Ruff migliorano la copertura al primo utilizzo, ma trasferiscono il lavoro di migrazione ai progetti che consideravano una configurazione omessa un contratto stabile.

La posizione di Astral è semplice. Ruff ha accumulato centinaia di controlli mentre la selezione predefinita rimaneva congelata, lasciando inattive diagnostiche rilevanti per gli utenti non configurati.

La vecchia selezione risaliva a Ruff v0.1.0. Da allora, il catalogo delle regole è cresciuto di 260, passando da 708 a 968.

Mantenere abilitati solo 59 controlli significava che l'esperienza senza configurazione di Ruff rappresentava una porzione sempre più piccola delle sue capacità. I nuovi utenti potevano presumere che l'impostazione predefinita fosse più completa di quanto non fosse realmente.

La release affronta questa discrepanza. Gli sviluppatori possono ora scoprire errori di sintassi, rischi a runtime, opportunità di modernizzazione e costrutti sospetti senza dover prima studiare centinaia di codici di regola.

Questo è prezioso per i piccoli progetti. Avvantaggia anche i nuovi repository che desiderano una copertura sensata prima che i maintainer sviluppino una policy di linting dettagliata.

L'aspettativa opposta è altrettanto ragionevole. Le impostazioni predefinite sono spesso considerate comportamento del prodotto, soprattutto quando la documentazione presenta uno strumento come utilizzabile senza configurazione.

Gli sviluppatori che omettono lint.select possono credere di scegliere la base mantenuta da Ruff. Prima della versione 0.16.0, dipendevano anche dal fatto che quella base rimanesse stabile tra gli upgrade.

Astral ha cambiato la base perché lasciarla invariata comportava un costo proprio. I progetti potevano superare Ruff pur contenendo errori che il binario installato sapeva già rilevare.

Il compromesso non è quindi sicurezza contro convenienza. È una protezione automatica più ampia contro la prevedibilità degli upgrade.

Un'impostazione predefinita più ristretta riduce le sorprese durante gli upgrade, ma nasconde più segnalazioni ai nuovi utenti. Un'impostazione predefinita più ampia rivela più difetti, ma può interrompere pipeline consolidate.

Ruff v0.16.0 sceglie una protezione più forte per la prossima esecuzione. I progetti che vogliono il contratto precedente devono ora registrare esplicitamente tale preferenza.

Astral fornisce una configurazione di compatibilità diretta:

La tabella esatta può variare quando la configurazione risiede in un ruff.toml autonomo. La decisione importante è la selezione esplicita delle regole, non il nome del file.

Questa impostazione ripristina le precedenti famiglie di regole predefinite. Offre ai team margine di manovra senza costringerli a bloccare la versione 0.15 a tempo indeterminato.

Tuttavia, ripristinare il vecchio comportamento dovrebbe essere un passaggio di migrazione, non un rifiuto automatico di ogni nuovo controllo. Alcuni fallimenti possono identificare bug che vale la pena correggere immediatamente.

Un upgrade accurato inizia acquisendo l'output diagnostico completo. I maintainer possono quindi raggruppare le segnalazioni per codice di regola, gravità, sicurezza della correzione e impatto sulla compatibilità.

Le regole che espongono problemi certi di sintassi o runtime meritano priorità. Le segnalazioni di modernizzazione meccanica possono essere esaminate separatamente, preferibilmente in commit mirati.

I controlli orientati alla policy richiedono il giudizio del team. Un pattern potrebbe essere valido per file generati, convenzioni di framework, moduli di compatibilità o API pubbliche che non possono cambiare con leggerezza.

Ruff supporta ignore per file e soppressioni mirate per questi casi. La versione 0.16.0 aggiunge i commenti ruff: ignore e ruff: file-ignore insieme al comportamento noqa esistente.

La soppressione mirata è di solito più facile da verificare rispetto a un'esclusione generale. Registra dove una regola non si adatta e può includere una motivazione per i futuri maintainer.

Tuttavia, le soppressioni possono diventare disordinate quando compaiono contemporaneamente centinaia di violazioni esistenti. Una selezione di regole valida per l'intero progetto può essere più onesta finché i maintainer non pianificano una pulizia deliberata.

La risposta corretta dipende dalla maturità del repository. Un nuovo progetto può accettare subito la base più ampia, mentre una grande codebase legacy potrebbe aver bisogno di un'adozione graduale.

Ecco perché i cambiamenti alle impostazioni predefinite hanno un peso insolito. Applicano un giudizio a livello di prodotto a progetti con storie e vincoli radicalmente diversi.

I Nuovi Valori Predefiniti Sono Solo Una Parte della Migrazione

I team che risolvono la prima ondata di diagnostica devono comunque rivedere la formattazione Markdown, l’output leggibile dalle macchine e il comportamento delle soppressioni.

Ruff v0.16.0 rende i blocchi di codice Python in Markdown parte dell’ambito normale del suo formattatore. Questo può modificare README, pagine di documentazione e file di pubblicazione simili a notebook.

Il formattatore riconosce le comuni stringhe informative Python associate ai blocchi di codice delimitati. Gestisce pyi come codice stub e pycon come sessione Python interattiva.

Gli utenti di Quarto possono anche formattare blocchi contrassegnati con forme come {python}. I progetti che usano file .qmd potrebbero aver bisogno di una mappatura delle estensioni prima che Ruff li includa.

Questa funzionalità allinea gli esempi nella documentazione al formattatore del codice sorgente. Riduce la possibilità che gli esempi copiati usino una formattazione obsoleta o incoerente.

Può però anche generare errori CI inattesi quando ruff format --check in precedenza esaminava solo file sorgente convenzionali. I responsabili della documentazione potrebbero incontrare per la prima volta le policy di Ruff.

Se necessario, i progetti possono escludere Markdown con extend-exclude. Possono inoltre usare commenti di soppressione della formattazione attorno a regioni selezionate.

La decisione dovrebbe riflettere se gli esempi di codice costituiscono istruzioni eseguibili o materiale esplicativo disposto con cura. La formattazione automatizzata aiuta la prima categoria in modo più coerente della seconda.

Anche la resa della diagnostica è cambiata. Ruff ora mostra le diff suggerite nel normale output di check e format --check.

In precedenza, gli sviluppatori potevano richiedere una diff separatamente. Il nuovo output completo mantiene insieme diagnostica e modifiche proposte, rendendo più semplice interpretare un controllo non riuscito.

Per i provider CI, format --check ora supporta formati di output usati per le annotazioni di GitHub e GitLab. Un problema di formattazione può comparire direttamente sulla riga interessata durante la revisione del codice.

I consumatori automatici richiedono maggiore attenzione. Diversi campi dell’output JSON di Ruff ora possono essere null invece di contenere posizioni segnaposto.

I campi interessati includono filename, location, end_location e le posizioni corrispondenti all’interno delle modifiche di fix. I consumatori che presumono che ogni posizione sia un oggetto o una stringa potrebbero fallire.

Per la maggior parte degli utenti si tratta di una piccola modifica incompatibile. È più rilevante per i team che analizzano l’output di Ruff in dashboard, bot di revisione o sistemi di qualità personalizzati.

Dopo l’aggiornamento, una pipeline può quindi fallire su tre livelli. Ruff può trovare una nuova violazione, la formattazione può estendersi a un nuovo tipo di file oppure un parser dell’output può rifiutare campi annullabili.

Trattare ogni errore come “più regole di lint” rischia di far perdere la causa effettiva. I manutentori dovrebbero identificare quale livello è cambiato prima di modificare il codice applicativo.

Anche il nuovo formato di soppressione merita una revisione delle policy. Un ruff: ignore[F401] alla fine della riga si comporta come un noqa mirato per quella diagnostica.

Un commento precedente può sopprimere le segnalazioni sulla riga logica successiva. È utile per intestazioni di funzioni su più righe, quando il problema segnalato non si adatta ordinatamente accanto al token pertinente.

La soppressione a livello di file è disponibile tramite ruff: file-ignore. Può includere una motivazione, offrendo ai revisori più informazioni di un’esclusione generale non spiegata.

La nuova opzione --add-ignore può inserire automaticamente una soppressione. Questa comodità non dovrebbe sostituire la revisione volta a stabilire se la diagnostica sottostante rappresenti un difetto reale.

L’automazione può rendere rapidamente verde la CI aggiungendo commenti. Non può decidere se un progetto debba mantenere quell’eccezione per anni.

Ruff separa i fix considerati sicuri da quelli che richiedono un’opzione per fix non sicuri. Anche una classificazione come sicura dovrebbe essere rivista nel contesto di codice generato, API pubbliche e comportamenti runtime insoliti.

Il comportamento dinamico di Python limita ciò che l’analisi statica può garantire. La stessa guida ai fix di Ruff chiede agli utenti di segnalare i casi in cui un fix sicuro danneggia il codice.

Questa limitazione non indebolisce la validità del linting. Rafforza la necessità di distinguere tra rilevamento, modifica automatizzata e approvazione umana.

Gli Strumenti di Sviluppo Non Bloccati Sono Ora il Punto Critico

La pressione immediata ricade sui repository che installano Ruff dinamicamente lasciando implicita la selezione delle regole.

Una versione di Ruff completamente bloccata, con un elenco select esplicito, offre due controlli stabili. Uno fissa l’implementazione dello strumento, mentre l’altro fissa la policy di lint scelta dal progetto.

Una versione variabile con regole esplicite offre stabilità parziale. Le nuove release di Ruff possono comunque modificare il comportamento di singole regole, il parsing, l’output, la formattazione o la semantica della configurazione.

Anche una versione bloccata senza regole esplicite offre stabilità parziale. La CI resta coerente finché i manutentori non aggiornano Ruff, momento in cui la migrazione dei valori predefiniti arriva tutta insieme.

Una versione non bloccata senza regole esplicite non offre nessuno dei due controlli. Questa combinazione ha creato le condizioni alla base dei fallimenti CI di Ruff per Simon Willison.

Bloccare una versione non significa congelare lo strumento indefinitamente. Separa la scoperta di un aggiornamento dalla sua adozione.

Una pull request di aggiornamento delle dipendenze crea un confine di revisione visibile. La CI può mostrare le nuove segnalazioni mentre il branch principale esistente rimane riproducibile.

I manutentori possono quindi scegliere tra diverse risposte:

• Correggere difetti evidenti individuati dai nuovi valori predefiniti.

• Accettare modifiche meccaniche sicure in commit isolati.

• Configurare eccezioni intenzionali per pattern specifici del repository.

• Ripristinare la selezione precedente e pianificare l’adozione graduale delle regole.

• Aggiornare parser che non riescono a gestire posizioni JSON annullabili.

• Escludere file di documentazione che devono preservare una formattazione manuale.

Queste azioni non dovrebbero essere mescolate indiscriminatamente. Un singolo grande commit di autofix può nascondere modifiche comportamentali tra migliaia di interventi di formattazione.

Raggruppare il lavoro per famiglia di regole produce revisioni più chiare. Rende inoltre più semplice il rollback se una regola entra in conflitto con le versioni di Python supportate dal progetto.

La configurazione della versione target è importante quando sono attive le regole pyupgrade. La sintassi moderna può essere corretta per una baseline di interprete e inutilizzabile per un’altra.

I team dovrebbero verificare che il target Python configurato in Ruff corrisponda alla realtà del deployment. Altrimenti, i suggerimenti di modernizzazione possono andare oltre il supporto in produzione.

Anche il codice generato richiede un trattamento separato. Riformattare o sottoporre a lint file generati spesso crea modifiche che scompaiono alla successiva esecuzione del generatore.

Escludere i percorsi generati può essere più accurato che riempirli di commenti di soppressione. La sorgente o il template del generatore è di solito il luogo appropriato per applicare la qualità.

I monorepository affrontano un’ulteriore complicazione. Pacchetti diversi possono supportare versioni Python diverse o mantenere policy di lint distinte.

Un valore predefinito a livello root può semplificare le operazioni, ma può anche imporre un unico calendario di migrazione a componenti non correlati. Una configurazione per pacchetto può riflettere meglio la proprietà.

La principale domanda scettica è se 413 regole costituiscano una baseline ampiamente accettabile. Astral ha documentato la selezione, ma l’adozione nel mondo reale ne testerà il tasso di falsi positivi e il peso in termini di compatibilità.

I fallimenti di Willison forniscono un primo segnale, non un’indagine rappresentativa. Mostrano che l’interruzione è possibile, non che la maggior parte degli utenti di Ruff la sperimenterà.

I progetti che usano già un select o extend-select esplicito possono reagire diversamente. Il loro insieme effettivo di regole dipende da come tale configurazione interagisce con la nuova baseline.

Astral afferma che la modifica può comunque far emergere regole utili per gli utenti configurati. Ogni team dovrebbe ispezionare la selezione risolta invece di presumere che la configurazione renda irrilevante la release.

Esiste anche il rischio di correggere eccessivamente. Bloccare Ruff lasciando variabili tutti gli altri strumenti per sviluppatori risolve solo un caso visibile di un problema più ampio.

I team dovrebbero inventariare formattatori, type checker, strumenti di test, hook pre-commit e generatori di documentazione. Ognuno di essi può trasformare una build pulita in un fallimento.

La policy duratura è semplice: versionare l’ambiente che decide se il codice può essere rilasciato. Questa policy include gli strumenti che gli sviluppatori tradizionalmente classificano come facoltativi.

Cosa Dovrebbero Osservare Simon Willison e gli Utenti di Ruff

I prossimi tre segnali mostreranno se la baseline più ampia di Ruff diventerà una policy accettata o una fonte ricorrente di attrito nella CI.

Il primo segnale è l’attività delle patch release di Astral nelle settimane successive alla versione 0.16.0. Rapidi aggiustamenti alle regole predefinite indicherebbero che repository reali hanno scoperto problemi di compatibilità significativi.

Correzioni specifiche per regola non invaliderebbero la baseline ampliata. Mostrerebbero che una selezione molto più ampia richiede calibrazione con carichi di lavoro di produzione.

Al contrario, un’attività di rollback limitata rafforzerebbe la posizione di Astral secondo cui la maggior parte delle nuove diagnostiche è azionabile. Incoraggerebbe inoltre più progetti ad accettare i valori predefiniti anziché ripristinare il set precedente.

Il secondo segnale è il comportamento della configurazione nei repository Python pubblici. I manutentori riveleranno il loro giudizio attraverso i commit, anche senza sondaggi formali.

Un’ondata di selezioni esplicite dei vecchi valori predefiniti suggerirebbe che i team attribuiscono più valore al controllo della migrazione che alla copertura immediata. Correzioni diffuse e valori predefiniti mantenuti indicherebbero un’adozione riuscita.

I repository più informativi documenteranno il proprio ragionamento. Un semplice elenco di ignore mostra cosa è cambiato, mentre una nota di migrazione spiega perché un team ha accettato o rifiutato ciascuna famiglia di regole.

Il terzo segnale è se i template di pacchetto e gli esempi CI inizieranno a bloccare Ruff. I generatori di nuovi progetti spesso modellano le abitudini in modo più efficace degli avvertimenti retrospettivi.

Se i template adotteranno vincoli di versione e flussi di aggiornamento automatizzati, l’esperienza di Willison avrà influenzato le pratiche oltre questa singola release.

Se gli esempi continueranno a installare un ruff senza vincoli, future modifiche ai valori predefiniti o al formattatore potranno ripetere la stessa sorpresa. Il numero specifico di regole sarà diverso, ma il problema della riproducibilità resterà.

Gli sviluppatori non devono attendere questi segnali prima di agire. Possono eseguire la nuova versione su un branch, conservare l’output e decidere quali segnalazioni migliorano il loro codice.

Un comando di test utile è:

Specificare la versione rende ripetibile l’esperimento. Eseguire ruff format --check . separatamente aiuta a distinguere gli errori di lint dalle modifiche alla formattazione Markdown o del codice sorgente.

Non iniziate aggiungendo ignore globali. Individuate prima quali regole hanno trovato bug certi, quali suggeriscono modernizzazione e quali codificano una policy discutibile.

Poi registrate la decisione nella configurazione e nel controllo di versione. Un badge CI verde ha meno valore quando nessuno sa quale contratto di qualità lo ha prodotto.

Ruff v0.16.0 dimostra il vantaggio e il costo di valori predefiniti attivi. Lo strumento rileva di più senza configurazione, ma l’assenza di configurazione non significa più comportamento invariato.

L’esperienza di Simon Willison trasforma questo compromesso astratto in una domanda ingegneristica immediata: il vostro repository dichiara gli strumenti e le policy che controllano le sue release?

Eseguite la versione bloccata su un branch, ispezionate ogni nuova famiglia di regole e rendete esplicita la baseline. La prossima build pulita dovrebbe riflettere una decisione revisionata, non la data in cui la CI ha installato Ruff.