Quando un Task termina l'esecuzione, si vuole sapere cosa è realmente successo — cosa è cambiato, se ha funzionato e, in caso di problemi, come proseguire.
Lettura dei risultati & Archive
Apertura del risultato di un Task concluso
Facendo clic su una qualsiasi scheda di Task — in esecuzione, concluso o archiviato — si apre la sua vista dei risultati, che mostra:
- Un riepilogo di cosa è stato fatto e perché
- L'elenco completo dei file modificati
- I risultati dei passi della Pipeline (superato/fallito per ogni passo)
- Eventuali screenshot acquisiti durante l'esecuzione, se il passo facoltativo Snapshot era abilitato
- Metadati: tempi, quale provider/modello AI se n'è occupato e un collegamento al commit Git
Comprendere i verdetti
Due tipi di controlli automatici producono un verdetto. Il verdetto dei test unitari è un semplice superato o fallito, basato sulla suite di test esistente del progetto. Il verdetto end-to-end (E2E) ha alcuni esiti possibili in più, dato che i test E2E mettono alla prova l'app reale in esecuzione:
| Verdetto | Significato |
|---|---|
PASS | Tutti gli scenari end-to-end sono stati superati |
FEATURE_BUG | Il test E2E ha trovato un vero bug nella funzionalità implementata |
ENHANCEMENT_REQUEST | I test hanno rivelato che la funzionalità opera ma manca qualcosa che vale la pena aggiungere in seguito |
DATA_ISSUE | Il fallimento è stato causato dai dati di test o dallo stato dell'ambiente, non dal codice in sé |
ENVIRONMENT_ERROR | L'ambiente di test stesso ha avuto un problema (ad es. un servizio non in esecuzione) — non riflette lo stato del codice |
UNKNOWN | Il risultato non ha potuto essere classificato automaticamente e richiede un'occhiata umana |
Gestione di un Task fallito
Lo stato failed significa che la Pipeline ha incontrato qualcosa che non è riuscita a risolvere da sola entro il proprio budget di tentativi. Aprendo il Task si vede quale passo è fallito e il motivo registrato, oltre alla diagnosi del Watchdog se ha tentato prima un ripristino automatico. Da lì, di solito si può riprendere il Task dal passo fallito (o da uno precedente, se la correzione deve ripartire da più indietro) invece di ricominciare da zero — AITM conserva tutto ciò che era già riuscito.
Gestione di un conflitto
Lo stato conflict significa che il merge Git automatico di AITM ha incontrato un conflitto reale — due modifiche che toccano le stesse righe in modo incompatibile — che il tentativo di risoluzione assistito dall'AI non è riuscito a risolvere in sicurezza da solo. In tal caso AITM mostra esattamente quali file sono in conflitto in modo da poterlo risolvere; non tenterà mai di indovinare né sceglierà silenziosamente un lato quando entrambe le modifiche sembrano intenzionali.
L'Archive
Quando un Task termina e la sua modifica è stata integrata in dev, viene archiviato nell'Archive — un registro consultabile di ogni Task completato, dal più recente, con titolo, progetto, data di completamento e stato finale. È la traccia di audit permanente.
Nell'Archive si possono cercare e filtrare i Task (per progetto, data o stato) e aprire il record completo di ciascuno: il prompt originale, i passi della Pipeline, il verdetto della review, i risultati dei test e un riepilogo in linguaggio semplice di cosa è cambiato, scritto dal passo Docs. Un Task archiviato non è bloccato — Restore lo rimette in coda. Per una variazione di un lavoro precedente, di solito è più pulito un nuovo Task che riutilizza il prompt archiviato come punto di partenza.
Suggerimenti
- Se un Task fallisce, riprenderlo dal passo fallito invece di ricominciare da capo — tutto ciò che era già riuscito viene conservato.
- Se l'AI si blocca a metà di un Task, il Watchdog lo riprende automaticamente fino a un numero limitato di tentativi prima di contrassegnarlo come
failed. - Poiché ogni Task lascia un record completo nell'Archive, questo funge anche da documentazione del perché il progetto è fatto com'è.