Come AITM integra in dev il lavoro concluso, corregge in avanti i fallimenti dei test post-merge invece di annullare, e verifica che un Task abbia toccato solo ciò che doveva.

Merge, correzioni post-merge & Scope Gate

Come funziona il merge

Ogni Task viene eseguito nel proprio branch/Worktree git. Quando la Pipeline termina (implementazione, review e test tutti verdi), il Task entra nella Merge queue di AITM — una coda serializzata, in modo che Task concorrenti non confluiscano mai in dev nello stesso momento e non si sovrascrivano a vicenda le modifiche.

• Avvio automatico del merge. Un Task con autoMergeDev abilitato viene integrato in dev automaticamente al termine della Pipeline — senza alcun passo di approvazione manuale, così il lavoro concluso arriva in modo continuo invece di accumularsi in attesa che qualcuno faccia clic su merge.
• Controllo di build pre-merge. Il branch del Task viene prima aggiornato rispetto all'attuale dev, poi viene eseguita la build e il type-check del risultato così come apparirà dopo il merge. Se il controllo è rosso, un Agent di correzione ha un numero limitato di tentativi; gli errori già presenti su dev non vengono attribuiti al Task. Se il controllo resta rosso, il Task non viene integrato e termina in conflict con l'output della build allegato.
• Gestione dei conflitti. Se il branch di un Task è in conflitto con ciò che è già confluito in dev, AITM ritenta il merge con strategie diverse e poi affida i file in conflitto a un risolutore di conflitti AI, che combina entrambe le modifiche e riesegue il controllo di build. Un Task in attesa in conflict viene ricontrollato automaticamente; se nel frattempo la causa è scomparsa, si auto-ripara e prosegue verso il merge.
• Merge controllato in dev. I merge avvengono uno alla volta dalla coda, quindi dev non si trova mai in uno stato di merge a metà. Il merge non è un passo della Pipeline: il Task mostra finished con un indicatore Finalizing… e diventa archived quando il merge è avvenuto. Finché un Task resta in conflict, gli altri Task in coda nella stessa scheda attendono dietro di esso — vale quindi la pena risolverlo presto.

Rilevamento e correzione degli errori post-merge

Dopo che il branch di un Task è stato integrato in dev, AITM riesegue i test interessati sul nuovo stato di dev. Se ora falliscono, la risposta predefinita è non annullare il merge.

Esempio: un Task aggiunge un nuovo campo a un modello condiviso. Il merge avviene senza problemi e i suoi test passano. Ma un altro Task, già in corso su un branch diverso, dipendeva dalla vecchia forma di quel modello — dopo l'arrivo di entrambi, un test di integrazione condiviso inizia a fallire. Invece di annullare uno dei due merge (il che scarterebbe anche la metà funzionante e non correlata di ciascuna modifica), AITM:

1. Isola quali file/test stanno effettivamente fallendo e la modifica di quale Task ne è responsabile.
2. Corregge in avanti su un branch — viene creato un Task correttivo che interviene solo sull'area che fallisce, partendo dallo stato attuale di dev (non dal diff di nessuno dei due Task originali).
3. Ritesta la correzione in isolamento prima che possa avvicinarsi di nuovo a dev.
4. Integra la correzione attraverso la stessa coda di qualsiasi altro Task.

Questa filosofia del "fix forward" evita i danni a cascata: annullare un merge dopo che altro lavoro si è già basato su di esso imporrebbe una catena di ulteriori annullamenti. Correggere il guasto reale sul posto, sul proprio branch, mantiene il raggio d'azione limitato all'unico problema individuato.

Valutazione dello Scope del Task (Business Scope Gate)

Ogni Task dichiara in anticipo quali file intende toccare. Quando il Task termina, il Business Scope Gate confronta i file che ha effettivamente modificato con tale dichiarazione.

• Fuori Scope significa che un file modificato non era mai stato dichiarato e non ha alcun collegamento plausibile con l'obiettivo dichiarato del Task — ad esempio, un Task sulla pagina di checkout che modifica anche un file di impostazioni di amministrazione non correlato.
• Modifiche di Scope (scope amendments). A volte toccare un file non dichiarato è legittimo — un tipo condiviso doveva cambiare, o una costante si trova in un file vicino. In tal caso il Task registra una breve e chiara motivazione per il file aggiuntivo (uno "scope amendment") invece di uscire silenziosamente dai limiti. Una modifica motivata viene accettata; un file aggiuntivo non spiegato no.
• Violazioni bloccanti e consultive. Non ogni file non dichiarato viene trattato allo stesso modo:
  • Bloccante — il file modificato è davvero estraneo al Task (area funzionale diversa, nessuna dipendenza condivisa, nessuna motivazione fornita). Ciò ferma il merge finché non viene risolto.
  • Consultiva — il file modificato si trova nella stessa directory/nello stesso modulo dello Scope dichiarato ed è plausibilmente correlato (ad es. un file fratello nella stessa cartella di funzionalità). Viene segnalato per la review ma di per sé non blocca il merge.

Cosa diventa un bug e cosa un nuovo Task

Quando un passo di review trova qualcosa che va oltre il diff immediato, AITM decide tra due esiti:

• Diventa un bug quando il rilievo è una violazione di Scope bloccante, oppure un difetto reale non correlato a ciò che il Task doveva fare — qualcosa che è già rotto e richiede un proprio ciclo di correzione, indipendente dall'esito del Task corrente.
• Diventa un nuovo Task (di follow-up) quando il rilievo è un affinamento, un miglioramento opzionale o un'idea legittima ma fuori Scope emersa mentre si lavorava a altro — entra in coda per conto proprio invece di ampliare lo Scope del Task corrente.

Questa suddivisione mantiene il diff di ciascun Task concentrato su ciò che gli era stato richiesto, pur catturando tutto ciò che chi esegue la review nota lungo il percorso — nulla di quanto osservato durante la review viene scartato in silenzio, ma non viene nemmeno infilato di nascosto in una modifica non correlata.

Quando un Task fallisce e richiede l'intervento umano

Non ogni fallimento è recuperabile automaticamente. Il Watchdog e i meccanismi di auto-riparazione di AITM gestiscono da soli i disguidi di infrastruttura e i normali fallimenti di compilazione/test, ma alcuni errori sono terminali — richiedono una decisione umana, non un altro tentativo. Un Task termina nello stato terminale failed quando:

• La configurazione è errata. Chiavi API non valide, impostazioni errate, JSON malformato — nulla nel codice può riparare un ambiente guasto.
• All'AI mancano dati. Il prompt del Task è incompleto o ambiguo, il contesto necessario non è stato fornito, o i requisiti sono poco specificati.
• Esiste un blocco fondamentale che solo un utente può risolvere. L'architettura richiede chiarimenti, lo Scope è contestato, o un servizio di terze parti è fuori uso in un modo che richiede un riconoscimento esplicito prima di poter proseguire.

Esempio: si supponga che un Task fallisca perché i requisiti sono in conflitto con l'architettura esistente. AITM non può indovinare quale design sia corretto — serve un chiarimento umano. A questo punto:

1. Il Task viene contrassegnato come failed.
2. L'utente (e Claude) discutono la causa radice in Chat o Brainstorm.
3. L'utente decide: rimettere in coda con uno Scope più chiaro? Aprire prima un Task separato di progettazione dell'architettura? Modificare l'approccio?
4. Quindi si crea un nuovo Task con la comprensione affinata, oppure si rimette in coda con un prompt aggiornato.

Non tutti i fallimenti sono bug — molti sono legittimamente irrisolvibili senza input umano. Fallito non significa lavoro sprecato — la diagnostica e i log di un'esecuzione fallita indicano comunque con precisione dove le cose sono andate storte. E quando un Task fallisce, è un punto di dialogo tra l'utente e AITM, non un vicolo cieco.

Modello dei branch

Ogni progetto gestito da AITM segue lo stesso modello di release a due branch.

• dev è il branch predefinito / di integrazione. Ogni Task della Pipeline confluisce in dev — è qui che il lavoro concluso e testato arriva in modo continuo (vedere la Merge queue sopra).
• main è il branch stabile di release. Viene aggiornato solo da un merge dev → main al momento della release, non dai singoli Task.
• Non esiste un branch master. AITM non ne crea né ne prevede alcuno.
• I progetti importati possono mantenere il proprio branch di integrazione. Se un progetto di cui si esegue l'onboarding usa già un nome diverso per il proprio branch di integrazione, lo si imposta con l'opzione Integration branch (defaultBranch) nelle impostazioni del progetto e si usa il controllo Verify remote per confermare che venga risolto rispetto al remote git effettivo.
• Il Gitea incluso nella release Docker crea repository dimostrativi con dev come branch predefinito, in linea con questo stesso modello fin da subito.

Se il progetto di un Task non ha un remote git utilizzabile, il Task si ferma con un messaggio operativo che rimanda a Project settings → Verify remote invece di mostrare un errore git grezzo.