Un solo prompt diventa una modifica rivista, testata, documentata e unita — mentre si fa altro. La Pipeline ha 12 step e si occupa di tutti.

La Pipeline

Cosa si ottiene

• Ogni Task lavora sul proprio branch isolato, quindi i Task paralleli non entrano mai in collisione e il codice principale resta al sicuro.
• Una review AI e correzioni automatiche avvengono prima che si veda il risultato.
• Gli unit test e i test end-to-end vengono eseguiti automaticamente.
• Il risultato viene verificato rispetto ai criteri di accettazione forniti.
• La documentazione e i Behavioral Contracts vengono mantenuti aggiornati automaticamente.
• I merge vengono messi in coda e la build deve passare prima che una modifica venga integrata.
• Quando qualcosa fallisce, AITM si riprende da solo ed è possibile riprendere da qualsiasi step.
• Ogni Task lascia un riepilogo del risultato leggibile e una cronologia.

I 12 step

1. Branch — il Task riceve un proprio spazio di lavoro sicuro che non può entrare in collisione con altri Task. Si ottiene: il codice principale resta intatto finché il lavoro non è pronto.
2. Architect — l'AI legge il prompt e il codice rilevante e pianifica la soluzione. Si ottiene: un piano ponderato delle parti del progetto che cambiano.
3. Code — il piano diventa modifiche reali ai file. Si ottiene: l'implementazione completa.
4. Compliance-check — confronta in modo indipendente il diff con i requisiti per i Task complessi. Salta i Task più semplici e passa eventuali rilievi a Review. Si ottiene: un avviso tempestivo sui requisiti non soddisfatti.
5. Review — l'AI controlla il lavoro come farebbe un collega ed esprime un verdetto. Si ottiene: un secondo paio di occhi senza attendere una persona.
6. Fix — risolve quanto segnalato da Review; può alternarsi con Review alcune volte. Si ottiene: un risultato ripulito.
7. Test — esegue gli unit test automatici del progetto. Si ottiene: la certezza che la modifica non abbia rotto il comportamento esistente.
8. E2E — esegue test che pilotano l'applicazione come un utente reale. Viene eseguito solo se il progetto dispone di test end-to-end, in parallelo con Test. Si ottiene: l'intero percorso dell'utente verificato.
9. Verify — confronta il risultato con i criteri di accettazione del Task; ciascuno si conclude come passed, failed o unverifiable. Si ottiene: una risposta chiara sul fatto che il Task faccia ciò che è stato richiesto.
10. Snapshot — step facoltativo che cattura screenshot dell'interfaccia. Si ottiene: una documentazione visiva della modifica.
11. Docs — aggiorna la documentazione e i Behavioral Contracts per riflettere ciò che è cambiato. Viene sempre eseguito. Si ottiene: una documentazione che non diventa obsoleta.
12. Chain-audit — agisce solo sull'ultimo Task di una catena di Task dipendenti, ricontrollando i criteri di ogni Task precedente. Si ottiene: la garanzia che l'intera catena sia coerente.

Il merge non è uno step della Pipeline — dopo l'ultimo step il Task entra nella Merge queue, che lo unisce nel branch dev. Fino ad allora un Task completato mostra un indicatore Finalizing…. Per i dettagli vedere Merging, Post-Merge Fixes & Scope Gate.

Dove si interviene

• Si rivede il risultato del Task — vedere Lettura dei risultati e Archive.
• Si modifica il prompt se il risultato non corrisponde all'intento.
• Si riprende da uno step o si rimette in coda il Task quando una Pipeline si è fermata.

Quando uno step fallisce

Uno step bloccato viene ritentato automaticamente; il numero di tentativi si imposta in Settings → Pipeline. Se la build è rossa dopo la sincronizzazione con dev, viene effettuato un tentativo di riparazione, e i conflitti di merge vengono prima affrontati con una risoluzione assistita dall'AI. Se non basta, il Task resta segnalato e ne viene mostrato il motivo. La scheda di un Task fallito o in conflitto offre quindi un pulsante con un suggerimento di recupero.