Documentazione / Per iniziare / Versioni

Skill per assistenti AI

Tutte le versioni stabili di Skill per assistenti AI, dalla più recente.

0.17.1 · 2026-10-08

Corretto

La colonna della mod si riempie subito. Ogni sezione compare appena ha i suoi dati, invece di aspettare le altre. Mentre carica, la scritta è solo «Carico…». (CYSK-41)

0.17.0 · 2026-10-08

Aggiunto

Più CloseYourIt nella colonna della mod. Mostra gli ultimi rilasci, gli errori più recenti da far analizzare a Claude, la scheda del ticket agganciato con i pulsanti per revisione e commento, e le tue cose da fare. (CYSK-41)

0.16.0 · 2026-10-08

Aggiunto

CloseYourIt dentro Claude Code. Una nuova mod mostra in una colonna la produzione e i tuoi ticket aperti, aggancia un ticket alla sessione con /ticket e blocca la lettura dei segreti. Si installa dal marketplace closeyourit. (CYSK-41)

0.15.1 · 2026-10-07

Corretto

Due rilasci ravvicinati non si fermano più sul CHANGELOG. Le due nuove sezioni in cima restano entrambe, la più recente sopra, anche sulle macchine Linux con git meno recente. (CYAU-243, CYAU-246)
La consegna dell'agente non viene più scartata come illeggibile. Le istruzioni indicano il blocco di consegna, i file cambiati e la forma dei test che il server si aspetta. (CYAU-244, CYAU-245)

0.15.0 · 2026-10-07

Aggiunto

Il triage propone da 2 a 4 risposte e spiega quella consigliata. Chi risponde vede perché una risposta è la preferita e sceglie con un clic. (CYRA-1033)
I piani si leggono senza il codice davanti. Ogni campo è in parole semplici: niente identificatori né formule, frasi corte, numeri in cifre. Sui ticket di bug la scheda apre con «cosa succede oggi». (CYAU-221)

Corretto

Consegna e rilascio vanno solo dove devono. La consegna spinge soltanto su origin, il rilascio accetta solo main come base, e del manifesto del plugin porta in produzione solo il numero di versione. (CYSK-40)
Il ramo del ticket si allinea a main con una fusione vera. Prima copiava i file di main e staging vedeva le stesse righe due volte, rifiutando il rilascio. Ora unisce origin/main e in caso di conflitto si ferma elencando i file. (CYAU-241)
Il triage legge le risposte quando riprende. Non ripete più una domanda già chiusa e non scala dopo due giri a vuoto. (CYAU-239)
La consegna non si dichiara già fatta se la revisione precedente ha chiesto modifiche. (CYAU-236)
La prova di accettazione usa il nome giusto del criterio. L'agente copiava «id» dal piano invece di «criterion_id» e ogni consegna veniva scartata come illeggibile. (CYAU-233)
Staging chiede la stessa intestazione del CHANGELOG della produzione. Una sezione Unreleased piena non basta più: serve la riga ## X.Y.Z, così la produzione non si ferma. (CYAU-232)
Il rilascio in produzione passa --cwd come vuole il guardrail. Senza quel parametro ogni rilascio veniva rifiutato.
Il commit salta i file finti che la sandbox monta nel worktree. Su Linux git add si fermava e nessun lavoro diventava un commit.
I comandi del controllo qualità restano dentro la sandbox.

0.14.0 · 2026-10-01

Aggiunto

Ogni decisione si legge in cinque secondi. Piano e consegna portano una scheda breve: una frase su cosa si ottiene, fino a tre punti con etichette fisse e il livello di rischio sempre in vista. (CYRA-885)
Domande con risposte pronte. Quando il triage ha un dubbio propone due o tre risposte, una consigliata: chi risponde sceglie con un clic. (CYRA-887)

0.13.4 · 2026-09-29

Corretto

Il rilascio su staging elenca di nuovo i file che porta. L'elenco usciva sempre vuoto perché il confronto partiva dal ramo principale già aggiornato. (CYRA-877)

0.13.3 · 2026-09-29

Corretto

La forma di rischi e deviazioni sta nelle istruzioni principali. Il modello non sempre apre il riferimento con l'esempio: ora la regola è scritta dove la legge sempre. (CYRA-877)

0.13.2 · 2026-09-29

Corretto

La consegna non si perde più per una deviazione scritta male. Le istruzioni mostrano com'è fatto un rischio e una deviazione: il modello li scriveva come frasi e la macchina scartava tutto il lavoro. (CYRA-876)

0.13.1 · 2026-09-14

Corretto

I controlli automatici tornano a girare su ogni proposta di modifica. Le verifiche erano ferme e le modifiche passavano senza prova. Ora ogni proposta viene controllata prima di essere unita. (CITM-8)

0.13.0 · 2026-09-07

Modificato

Lo stato delle domande si legge in un posto solo (CYSK-36). Lo smistamento non rilegge più i vecchi messaggi nascosti nei commenti: lo chiede al sistema. Se non riesce a saperlo, aspetta e dice perché — non tira a indovinare.

0.12.2 · 2026-09-03

Corretto

Il rilascio di prova non cancella più le note già pubblicate. Portava nel rilascio il file delle novità com'era nella sua copia di lavoro, ferma a quando il lavoro è cominciato: tutto ciò che era stato pubblicato dopo spariva. Ora i due testi vengono uniti, e se hanno scritto sulle stesse righe il rilascio si ferma e dice come uscirne, invece di scegliere da solo cosa perdere.

0.12.1 · 2026-09-02

Corretto

Le sezioni fidate del dispacciamento si trovano (CYSK-34): piano approvato e numero di versione arrivano alla skill insieme al codice del ticket, ma le istruzioni li presentavano come «un codice ticket» e il modello dichiarava che mancavano. Ora stanno in un blocco proprio, con la regola di cercarli lì prima di fermarsi.

0.12.0 · 2026-09-02

Corretto

Il rilascio di prova si chiude anche al secondo giro (CYSK-34): la skill aspettava la CI dentro la sessione e finiva a vuoto; al riprovo controllava una proposta già unita, la leggeva come «non lo so» e si fermava; e tagliava un secondo numero di prova per lo stesso lavoro. Ora release.sh decide per primo, una proposta unita è un esito riconosciuto, il numero già uscito si ritrova anche sui commit successivi, e nessuna fase aspetta la CI.
L'autopilot conosce tutti i valori ammessi (CYSK-34): le istruzioni elencano ogni categoria di blocco e ogni stato di prova e di criterio, con l'alternativa da usare quando nessuno calza; una prova rende rosso il bundle se un valore del contratto manca dal prompt o un esempio usa una chiave che il contratto non ha.

Corretto

Le skill leggono il contratto invece di ricopiarlo (CYSK-33): gli stati finali e le regole dei chiarimenti erano copie a mano, e una era rimasta indietro — una risposta con uno stato che il contratto non ammette valeva «si può lavorare». Ora il contratto è copiato con il suo sigillo e le prove lo leggono: se cambia, la CI lo dice.

Sicurezza

I passi automatici della CI sono bloccati al contenuto esatto (CYSK-32): erano richiamati per nome di versione, che chi pubblica l'azione può spostare quando vuole. Ora ognuno è agganciato alla sua impronta, e una prova rende rosso qualunque passo aggiunto senza.

Corretto

Il numero di versione dentro il pacchetto non può più restare indietro (CYSK-31): era fermo a 0.9.0 mentre uscivano 0.10.0 e 0.11.0, quindi la pubblicazione si fermava e le macchine usavano skill vecchie. Ora il rilascio scrive il numero anche dentro il pacchetto, e si ferma prima di pubblicare se non corrisponde. I due tag restano non pubblicati.

0.11.0 · 2026-09-01

Aggiunto

deadcode-sweep (CYSK-30): la passata periodica che tiene aggiornata la mappa del codice morto. Timer systemd utente (lunedì 03:00, disegno CYSK-22), strato A deterministico (fetch + scanner + estratto copertura) e strato B agente (claude headless che segue la skill dead-code e apre ticket deduplicati). Heartbeat su cron monitor SOLO a giro completo; un repo non scansionato si dichiara. tools/deadcode-sweep/ con installer idempotente.

0.10.0 · 2026-09-01

Aggiunto

plan (CYRA-702): il decision packet accetta decision_brief al top level — 3-6 frasi in italiano semplice per chi approva dalla coda, senza path né gergo. Opzionale: i planner non aggiornati consegnano senza. Regole ed esempio in skills/plan/references/plan-quality.md.

0.9.0 · 2026-08-31

Aggiunto

dead-code (CYSK-28): la skill che mappa il codice che nessuno chiama in un repository Rails. Scanner senza dipendenze (skills/dead-code/scripts/dead_code_inventory.mjs): censimento token su tutti i file tracciati (.erb compresi), famiglia convenzionale SOPPRESSA e contata (mai declassata), copertura con le tre condizioni di utilizzabilità e i rami mai presi discriminati dagli hit della condizione padre. Non decide, non scrive, non cancella. Vive nel plugin nuovo closeyourit-analysis (.claude-plugin/marketplace.json elenca i due plugin): il flusso ticket non paga i suoi token.

0.8.0 · 2026-08-28

Aggiunto

Prima di pianificare si guarda se è già fatto. Chi scrive il piano cerca nel codice l'esito che il ticket chiede: se lo trova già presente non pianifica, consegna i file che lo provano e il ticket si chiude. Fatto a metà resta un piano normale, e nel dubbio si pianifica.

0.7.0 · 2026-08-25

Modificato

Piani e consegne sono scritti per chi deve decidere. Le procedure separano interventi, motivazioni, rischi, file, test e prove per criterio. Gli scenari diventano frasi leggibili e un blocco dichiara sempre causa, possibilità di riprovare e azione richiesta.

0.6.0 · 2026-08-24

Aggiunto

Le prove di questo bundle girano anche sulle proposte, non solo al momento della pubblicazione. Prima l'unico controllo partiva al tag, a lavoro già unito: una prova rotta usciva senza che niente fosse rosso, e chi rilascia leggeva quel silenzio come «qui i controlli non ci sono».

Modificato

Lo stato di una domanda in attesa si chiede al sistema, non alla discussione. Il cancello del triage leggeva un marcatore nascosto in fondo ai commenti e provava a indovinare: bastava che fosse il sistema stesso a scriverci una riga qualsiasi perché venisse scambiata per una risposta e il ticket ripartisse senza che nessuno avesse risposto. Adesso lo chiede a chi lo sa. La lettura dei commenti resta come ripiego e scatta solo se il comando non esiste; se lo stato non si riesce a leggere il cancello risponde «aspetta», mai «si può lavorare».

Modificato

Il numero della versione si riceve, non si sceglie. Le istruzioni dicevano di guardare l'ultimo numero uscito e decidere quale cifra cambiare: due lavorazioni dello stesso progetto potevano scegliere lo stesso nome, e la seconda lo scopriva solo pubblicando. Adesso il numero arriva insieme al lavoro, già completo del contatore per la versione di prova e del punto di codice per quella definitiva, e se non arriva la sessione si ferma invece di inventarne uno.

Corretto

La pubblicazione manda fuori esattamente il punto che le viene consegnato, e non se lo sceglie più da sola. L'ultimo passo — quello che mette una versione in mano alle persone — decideva da solo due cose che nessuno controllava. La prima: quale punto del lavoro pubblicare. Se non glielo si diceva prendeva «quello che c'è adesso in cima al lavoro condiviso»; ma fra la fine della prova in ambiente di collaudo e l'inizio della pubblicazione passano minuti o ore, e in mezzo può essere entrato il lavoro di altri ticket. Quel lavoro usciva in produzione senza che nessuno l'avesse provato né visto. La seconda: se il collaudo fosse andato bene. Bastava che la macchina lo scrivesse — non era un controllo, era una frase, e chi pubblicava non guardava niente. Ora la macchina non decide più niente qui: riceve il punto esatto sigillato quando la versione è stata chiusa e il numero di versione, e pubblica quello e solo quello. Se non li riceve non pubblica: si ferma, dice cosa manca e non finge di aver fatto. La frase «il collaudo è verde» non esiste più come permesso; al suo posto restano i controlli che girano davvero sulla versione pubblicata e che senza verde non fanno partire il rilascio. Prima di taggare verifica l'unica cosa verificabile sul posto — che il punto ricevuto faccia già parte del lavoro condiviso — e si ferma prima della parte irreversibile se non è così. Non pretende invece che ci sia sopra una versione di prova: su sei progetti su otto non ne viene mai tagliata una, e pretenderla vorrebbe dire che lì la produzione non parte più. Per chi usa il prodotto: una versione contiene esattamente quello che era stato sigillato, senza passeggeri arrivati all'ultimo minuto, e il lavoro arrivato tardi scivola nella versione successiva invece di uscire mezzo provato.
Quando il lavoro di un ticket è già uscito, la scheda porta il numero e il punto di QUEL lavoro. Capita spesso che un ticket venga ripreso quando il suo codice è già entrato nella linea principale — una lavorazione riavviata, un rilascio rifatto. In quel caso non c'è niente da unire e la macchina deve solo dire due cose: con quale numero quel lavoro è uscito, e in che punto è entrato. Sbagliava tutte e due. Il numero lo cercava come «l'ultima etichetta di prova da quel punto in avanti»: se dopo il tuo ticket ne era uscito un altro, restituiva il numero DELL'ALTRO — e quel numero finiva scritto sulla scheda e veniva poi passato al rilascio vero, che portava a tutti il lavoro di un ticket sotto il nome di un altro. Il punto era la punta del ramo di lavoro, che dentro la linea principale non esiste: chi leggeva la scheda non poteva andarlo a ricontrollare da nessuna parte. E il controllo «è già uscito?» veniva fatto sul ramo, non sul codice che avevi approvato, quindi rispondeva su qualcosa che poteva essersi mosso dopo. Ora la domanda è posta sul codice approvato; il punto riportato è quello in cui quel codice è entrato davvero nella linea principale, che si può aprire e guardare; il numero è quello che sta esattamente su quel punto, mai uno raccolto più avanti nella storia. Se un numero lì non c'è ancora e su quel prodotto un canale di prova esiste, viene creato — sul punto d'ingresso, mai sulla punta del ramo — partendo dal numero dichiarato per questo lavoro; dove un canale di prova non esiste non se ne inventa nessuno. In più l'anteprima ora si aggiorna prima di rispondere: prima decideva su una copia vecchia del progetto, quindi poteva dirti una cosa e l'esecuzione vera farne un'altra.

Modificato

Si rilascia esattamente il codice che hai approvato, o non si rilascia niente. Quando approvi il lavoro di un ticket guardi una versione precisa del codice. Da lì al rilascio possono passare minuti o ore — il ticket resta in coda finché una macchina libera non prende la fase — e in quella finestra il ramo di lavoro può muoversi: una sessione ripresa, una correzione fatta a mano, una riga corretta dal revisore direttamente sul sito. Niente lo impediva e niente lo segnalava. La macchina che unisce non chiedeva «qual è il codice approvato»: chiedeva «qual è il ramo» e univa quello che ci trovava sopra in quel momento, poi pubblicava e scriveva sul ticket che era fatto. Tutti i controlli restavano verdi, perché nessuno di essi confrontava il codice unito con quello approvato: sulla linea principale, e da lì in produzione, poteva entrare codice che nessuno aveva guardato. C'era anche il modo opposto di sbagliare: la macchina chiedeva al sito se il lavoro era a posto e poi univa la copia sul proprio disco, che non viene mai riallineata — così una correzione fatta dal revisore sul sito faceva arrivare il via libera e poi non veniva pubblicata, e la proposta restava aperta per sempre. Ora la macchina riceve la versione esatta approvata e senza quella non parte; prima di unire la confronta con la punta del ramo così come la vede il sito, non con la copia sul disco; se coincidono unisce quella versione, non «il ramo»; se non coincidono non unisce, non pubblica e non scrive niente, e mostra le due versioni perché la decisione torni a te. Se non riesce a leggere lo stato del progetto non si dichiara bloccata e non ti chiama: resta dov'è e riprova. Lo stesso controllo vale per l'anteprima, così si ferma prima ancora di cominciare. Nel caso normale, quando il ramo è fermo dove l'hai approvato, per te non cambia niente.
L'etichetta di prova si mette solo dove un canale di prova esiste davvero, e «provato» non si dichiara più: si guarda. Per provare un lavoro prima di darlo a tutti, la macchina gli attaccava un'etichetta di prova, e la procedura diceva che quell'etichetta apre ovunque un canale riservato alle prove. Non era vero quasi mai. Su un prodotto solo l'etichetta faceva davvero quello che prometteva, e su un secondo apriva un canale beta. Su tutti gli altri faceva altro: sui pacchetti per JavaScript pubblicava a chiunque, come una versione normale; su quelli per Ruby e Flutter pubblicava il numero scritto dentro il progetto invece di quello dell'etichetta — di nuovo una pubblicazione a tutti; su Python non faceva assolutamente niente e non falliva, quindi sembrava riuscito; sul programma che gira sui server di controllo spostava il segnalibro «ultima versione», quello che tutte le macchine seguono, così un lavoro non ancora provato diventava la versione che tutti scaricano; sul contenitore delle istruzioni falliva e basta. E in ognuno di questi casi veniva poi scritto «rilasciato in prova», senza che nessuno avesse provato niente. Ora l'etichetta si mette solo sui due prodotti dove un canale di prova c'è: altrove il lavoro viene unito al ramo principale e nient'altro. E la macchina non dichiara più: va a guardare il controllo automatico partito su quel codice e riporta cosa ha visto, con quattro esiti distinti scritti sulla scheda. Se il controllo è finito bene e ha davvero eseguito qualcosa, si va avanti ed è scritto quale controllo è stato guardato. Se è finito male, oppure è finito senza fare niente, la lavorazione si ferma e chiede a te — un controllo che non ha eseguito nulla è verde per costruzione, e prenderlo per buono è il modo più silenzioso di dichiarare provato ciò che nessuno ha provato. Se su quel prodotto un controllo non esiste, si va avanti ma è scritto a chiare lettere che una prova non c'era. Se la macchina non è riuscita a guardare perché il servizio non risponde, la lavorazione resta dov'è, lo dice, riprova da sola, e alla voce «cosa serve da te» scrive «niente»: non ti disturba per un guasto di rete. Per chi usa l'applicazione web non cambia nulla, lì la prova già funzionava. Cambia per chi installa i pacchetti, che smette di ricevere versioni non provate da nessuno; e cambia per chi approva, perché quando la scheda dice «provato» dietro c'è un controllo con un numero, che si può riaprire e guardare.

0.5.0 · 2026-08-21

Aggiunto

Chi lavora un ticket dichiara sempre cosa ha trovato di sospetto, anche quando non ha trovato niente. Se durante il lavoro la macchina si accorge di qualcosa di storto — uno script che va a leggere le password salvate sul computer, una chiave d'accesso scritta dentro un indirizzo — chi deve approvare lo vede in un riquadro rosso in cima al ticket, prima di tutto il resto. Le istruzioni non lo chiedevano da nessuna parte, quindi il riquadro non è mai comparso e l'anomalia, quando c'era, tornava dove stava prima: una frase in mezzo a duecentocinquanta parole, dentro una scheda che nessuno apre. Ora la dichiarazione è obbligatoria nelle istruzioni e compare dentro gli esempi che la macchina copia — che è la parte che conta davvero, perché fra una regola scritta a parole e un esempio che non la contiene vince l'esempio. Se non ha trovato niente lo dice lo stesso, con un elenco vuoto: «ho guardato e non ho trovato niente» è una risposta, e fino a ieri era indistinguibile dal non aver guardato. Non le si chiede di andare a cercare: solo di riferire quello che le è passato davanti.

Modificato

Le procedure di rilascio dicono con precisione cos'è la sigla del codice rilasciato. Il campo c'era già negli esempi, ma non era definito: «il commit» da solo lascia passare la punta del ramo, che al momento del rilascio può essere già un'altra cosa. Ora è scritto: è il commit su cui l'etichetta è stata creata, 40 caratteri esadecimali minuscoli, copiato dal blocco delle prove che la procedura stampa. Ed è scritto anche il contrario, che conta altrettanto: un rilascio che si è fermato NON deve portare quella sigla — non ha taggato niente, e pretenderla farebbe perdere l'unica cosa che conta lì, il motivo per cui si è fermato.

0.4.0 · 2026-08-21

Modificato

Le proposte dell’Autopilot restano bozze finché i controlli non sono davvero verdi. La procedura apre una PR draft — o riporta in draft quella già aperta — e verifica che punti al branch e al commit appena inviati. Non aspetta e non interpreta da sola la CI: passa l’indirizzo all’Automator, che attesta i check remoti e la rilettura indipendente prima di rendere la proposta pronta per una persona.

Corretto

Nessuna fase finisce più in un discorso. Quando una macchina finiva il proprio pezzo di lavoro, poteva chiudere scrivendo una frase invece di dichiarare come era andata. Il sistema quella frase non sa leggerla: la lavorazione restava scritta come in corso, non tornava in coda, non compariva fra quelle che aspettano una persona, e l'unica uscita era annullarla a mano. Ora tutte e cinque le procedure dichiarano sempre lo stato di uscita, e chi legge la lavagna vede il vero punto in cui si trova il lavoro.
Quando il rilascio di prova non riesce a leggere i controlli, il sistema riprova invece di chiamarti. «Non sono riuscito a guardare» non è «serve una persona»: se il servizio esterno non risponde, la cosa giusta è riprovare, e chiamare qualcuno per un servizio che tornerà su da solo lo abitua a ignorare le chiamate. La procedura lo diceva già, ma lo diceva con parole che il sistema non conosce — un nome di campo per un altro, e un valore che non esiste. Il messaggio veniva ignorato in silenzio, e un messaggio assente vale «serve una persona»: cioè esattamente il contrario. Ora le due parti usano le stesse parole, e c'è un controllo che se ne accorge se tornano a divergere.
La voce di changelog si chiede al progetto, sul codice che si sta per rilasciare, e prima che parta qualcosa di irreversibile. Per decidere se controllare che il diario delle modifiche avesse la riga della versione, la macchina guardava la cosa sbagliata: il tipo di progetto, non il progetto. Da lì nascevano due guasti, tutti e due veri. Un servizio interno del gruppo il diario non ce l'ha proprio: la macchina glielo chiedeva lo stesso e si fermava, quindi quel servizio non riusciva a uscire in produzione — mai — per una riga che nessuno gli ha mai chiesto. I siti, al contrario, il diario ce l'hanno ma alla macchina non risultavano del tipo giusto: non chiedeva niente, andava avanti e metteva il segno della versione. Quel segno non si toglie più. Subito dopo il controllo automatico leggeva il diario, la riga non c'era, e si fermava: in produzione non arrivava niente, ma la lavorazione aveva già detto «rilasciato». C'era anche il momento sbagliato: la domanda arrivava in fondo, quando l'unica cosa ancora possibile era chiamare una persona. Ora la macchina chiede la riga al progetto stesso, guardando il codice esatto che sta per rilasciare: se quel codice porta un diario la riga è obbligatoria, se non lo porta non chiede niente e lo scrive nel resoconto. E si ferma prima di fare qualsiasi cosa che non si possa disfare — nessun segno di versione, niente spinto sul ramo principale — dicendo quale riga manca, su quale codice, e con che parole scriverla. Nella fase di prova, dove la riga si può ancora scrivere da sola, la domanda arriva lì: così il rimedio non ha più bisogno di una persona. Cambia questo, per chi usa il prodotto: una versione o esce davvero, o si ferma prima con scritto cosa manca. Sparisce il caso peggiore, quello in cui il sistema dice «rilasciato» e in produzione non è arrivato niente.
La forma cercata è ora esattamente quella che il controllo automatico pretende. La macchina accettava anche un titolo scritto con qualche spazio di troppo, che il controllo automatico invece rifiuta: bastava quello per far passare un rilascio che poi si fermava a segno già messo. Ora la forma è la stessa, e nel dubbio è la macchina a essere più severa — al massimo ci si ferma prima, che è il verso giusto in cui sbagliare.
Quando un rilascio si ferma, la spiegazione si legge. I messaggi scritti su più righe uscivano schiacciati su una sola, con i segni di a capo stampati come lettere. Erano proprio i messaggi che devono dire cosa manca e come rimediare.
La procedura di consegna non sposta più lo stato del ticket. Quando la macchina finiva di scrivere il codice, era la procedura che segue a spostare il ticket su «Da revisionare», di sua iniziativa e prima che il sistema centrale avesse registrato niente. Un attimo dopo il sistema centrale spostava lo stesso ticket nello stesso punto: due padroni per la stessa casella. Il guaio si vedeva quando la consegna non arrivava a destinazione — se il resoconto finale della macchina veniva scartato, e capita, il ticket era già stato spostato: aprivi l'elenco di quello che c'è da revisionare, trovavi il ticket, e non c'era niente da guardare. Nessuna consegna registrata, nessun lavoro da approvare, un ticket che sembra pronto per te ed è fermo. C'era un secondo guaio, più raro e più caro: per spostare il ticket la procedura doveva prima capire da sola quale fosse lo stato «da revisionare» dell'organizzazione, e ne pretendeva esattamente uno; con due si fermava con un errore, e si fermava a codice già scritto e proposta di modifica già aperta — la consegna risultava fallita e tutto il lavoro veniva rifatto da capo. Ora la procedura fa solo il suo mestiere: manda il codice, apre la proposta, scrive la riga sul ticket. Lo stato lo decide un posto solo. Per chi usa il prodotto cambia questo: un ticket compare fra quelli «Da revisionare» soltanto quando c'è davvero qualcosa da revisionare, e non si perde più una lavorazione intera per il conto degli stati. Subito dopo arriva il divieto di spostare lo stato dai canali automatici: finché la procedura continuava a spostarlo per conto suo, quel divieto avrebbe rifiutato ogni consegna e fermato la coda su ogni ticket.
Il controllo che protegge le skill non si fermava più al primo ostacolo. Fra le skill era stata aggiunta una cartella di risorse condivise, che skill non è. Il controllo che verifica il contratto di ogni skill le passava in rassegna una per una, arrivava a quella cartella, cercava un documento che lì non c'è e si interrompeva — prima di aver verificato alcunché. Ora si guardano solo le cartelle che portano davvero il documento di una skill. Se a una skill vera quel documento sparisse, il controllo diventa rosso invece di ignorarla in silenzio.
Il via libera al rilascio di prova non si dà più per approvazione, per silenzio o per assenza di controlli. Prima di mandare una modifica sull'ambiente di prova, la macchina guarda se è sana. Diceva «sana» in tre casi in cui non lo sapeva. Primo: se una persona aveva cliccato «approvo», rilasciava senza nemmeno guardare i controlli automatici — e se erano rossi, il codice rotto andava in prova lo stesso. Approvare vuol dire «voglio questo lavoro», non «i controlli sono passati»: sono due cose diverse. Secondo: se GitHub non rispondeva per un minuto, non sapendo distinguere «non sono riuscito a guardare» da «ho guardato ed è rosso», la lavorazione si fermava e finiva fra le cose che aspettano una tua decisione — che non c'era, era un buco di rete. Terzo, il peggiore: si contavano i controlli andati male, e zero valeva verde. Ma zero è anche il numero dei controlli quando nessuno è partito, e quando su quel progetto controlli non esistono. «Nessuno ha guardato» diventava «hanno guardato tutti ed è a posto». Ora verde vuol dire verde: almeno un controllo dev'essere partito davvero ed essere riuscito. «Non sono riuscito a guardare» è una risposta a sé, e non chiede niente a nessuno: si riprova. E dove i controlli non esistono per davvero il rilascio parte lo stesso — bloccarlo fermerebbe progetti interi — ma il resoconto lo scrive: nessun controllo ha verificato questo codice.

0.3.5 · 2026-08-09

Corretto

Il controllo che decide se una versione può andare in produzione bocciava proprio i casi buoni: se la voce di changelog c'era, il controllo falliva; se non c'era, falliva lo stesso. Il rilascio si fermava quindi sempre, con la spiegazione sbagliata — sembrava che la copia locale del progetto fosse indietro, mentre era il controllo a rispondere male. Più lungo il changelog, più l'errore era certo.
Un rilascio in produzione già avvenuto non riusciva più a essere riconosciuto. Se il resoconto veniva scartato più a valle, il passo ripartiva e si fermava perché la versione esisteva già: un rilascio riuscito risultava fallito per sempre. Ora viene riconosciuto, il numero di versione non viene mai spostato, e se punta a un contenuto diverso lo dice invece di aggiustare da sé.

Modificato

Anche il resoconto del rilascio in produzione porta ora le prove di quello che dichiara: quale commit, quale versione, quali file.

0.3.4 · 2026-08-08

Corretto

Quando la voce di changelog arrivava in ritardo, su una lavorazione gia' rilasciata, il rilascio restava spaccato in due: il tag che staging aveva verificato puntava a un commit, la voce che la produzione pretende stava su un altro. Ora l'artefatto che porta la voce riceve il numero successivo della stessa versione e viene verificato in staging prima di essere promosso. I tag esistenti non vengono mai spostati.

0.3.3 · 2026-08-08

Corretto

Una lavorazione già rilasciata in staging non riusciva più a ripartire. Se il resoconto veniva scartato più a valle, il rilascio ripartiva da capo e si fermava dicendo che il lavoro "non è rilasciabile" — perché nel frattempo era stato unito davvero, e una richiesta di unione già chiusa risulta non più unibile. Un rilascio riuscito sembrava così un fallimento, per sempre. Ora la domanda la si fa al repository: se il lavoro è già dentro al ramo principale, il rilascio lo dice e si chiude in pace.
La voce di changelog richiesta per andare in produzione non arrivava mai a destinazione. L'assistente doveva scriverla, ma non ha modo di consegnarla: gli strumenti per farlo gli sono preclusi, quindi la scriveva e restava lì. Due passi dopo la produzione si fermava su un controllo che a quel punto nessuno poteva più soddisfare. Ora è il rilascio a raccoglierla e portarla dentro, anche quando arriva in ritardo su una lavorazione già rilasciata.

Modificato

Il resoconto dei due passi di rilascio ora porta le prove di quello che dichiara: quale commit, quali file rispetto al ramo principale, quale tag e come stavano i controlli. La revisione li bocciava, e a ragione: dicevano solo l'esito, e un rilascio è proprio il punto in cui un'affermazione deve poter essere verificata.

0.3.2 · 2026-08-08

Corretto

Il rilascio in staging si fermava dicendo che mancava l'identità con cui firmare il commit di unione, anche su una macchina che quell'identità ce l'ha configurata e leggibile: dentro la cassaforte in cui girano gli assistenti git non riesce a risolverla. Ora è il rilascio stesso a dichiarare chi sta firmando — è l'automazione a creare quel commit, quindi si presenta con il proprio nome invece di prendere in prestito quello di chi possiede la macchina. Se chi lo avvia fornisce già un'identità, resta quella.

0.3.1 · 2026-08-08

Corretto

Il rilascio in staging non riusciva su nessun progetto Rails. Per unire il lavoro approvato al ramo principale, il closer riportava prima l'area di lavoro allo stato del ramo principale; ma la cassaforte in cui girano gli assistenti protegge in sola lettura tutto ciò che si chiama "config" — nasce per i file di configurazione di git e combacia per nome, quindi prendeva anche la cartella config/ dell'applicazione. L'aggiornamento passava su tutti i file tranne quelli, si fermava a metà e lasciava l'area di lavoro in uno stato che non corrispondeva a nessun ramo, da cui l'assistente non poteva più uscire da solo. Ora l'unione viene costruita direttamente nell'archivio del repository, senza toccare nessun file su disco: niente da aggiornare, niente da proteggere, nessuna cartella lasciata a metà.
Se sulla macchina manca l'identità con cui firmare i commit, il rilascio lo dice subito e con parole chiare, invece di fallire più avanti con un messaggio di git che sembra parlare d'altro.

0.2.0 · 2026-08-07

Corretto

Riaprendo un ticket che aveva già completato e pubblicato in un giro precedente, l'assistente non aveva modo di dirlo: il suo resoconto non rientrava in nessuna forma prevista e veniva scartato, così la lavorazione risultava non consegnata e il ticket tornava in coda per essere rifatto da capo. Ora quel caso ha una risposta propria, che per essere accettata deve mostrare il lavoro già pubblicato — non è una scorciatoia per non lavorare.
L'assistente che scrive il codice cercava il piano approvato dentro il ticket, dove non c'è mai stato: il piano vive altrove e nessun comando disponibile lo restituisce. Non trovandolo si fermava dichiarando che non era stato approvato — su ogni ticket, anche quando l'approvazione c'era. Ora il piano gli arriva insieme all'incarico, con le condizioni di completamento, e non gli viene più chiesto di verificare un'approvazione che la fase stessa implica.
La pubblicazione del ramo terminava in errore anche quando riusciva, e il lavoro finito veniva buttato via con il codice già pubblicato. Chiedeva di annotare il ramo di riferimento in una cartella che l'assistente non può scrivere.

Aggiunto

I testi lunghi che gli assistenti scrivono su un ticket seguono sempre le stesse etichette, così chi apre il ticket capisce in pochi secondi cosa è successo senza doverlo leggere tutto. Prima arrivavano come muri di testo: le analisi riempivano sempre lo spazio fino all'ultimo carattere disponibile, i resoconti erano lunghi il triplo del necessario.
Fra le etichette c'è "Consigli", dove finisce ciò che si è notato ma non riguarda quel ticket: sono le righe che diventeranno ticket nuovi, e per questo ognuna deve leggersi da sola.
Un controllo automatico esamina un testo prima che venga scritto sul ticket e segnala cosa non va: etichette mancanti, periodi troppo lunghi, testo oltre la misura consigliata. Avvisa soltanto, non impedisce nulla.

0.1.1 · 2026-07-30

Corretto

Le istruzioni che gli assistenti seguono ora possono essere eseguite davvero. Erano scritte in una forma che la rete di sicurezza rifiuta, quindi quasi nessun passo veniva compiuto e la lavorazione finiva senza consegnare nulla.
Le domande di chiarimento arrivano sul ticket: prima le scriveva l'assistente con un comando che non poteva essere eseguito, e restavano solo nel registro interno.
L'assistente che implementa un ticket ora riesce a salvare il proprio lavoro: creare un commit era fra le operazioni rifiutate.
I file di appoggio della sessione non finiscono più dentro il lavoro consegnato.

Modificato

Il risultato di ogni passo viene consegnato come ultimo messaggio della sessione, invece che tramite un comando.