Etichette degli esiti

Le risposte TCAF iniziano con un’etichetta di esito, così il developer comprende lo stato corrente prima di leggere i dettagli.

L’etichetta descrive evidenze e livello di completamento. Non è un punteggio di fiducia e non è un’affermazione promozionale.

PASS

Usa PASS quando:

• l’implementazione autorizzata è completa;
• i controlli richiesti che determinano il completamento sono passati;
• non restano verifiche manuali obbligatorie;
• nessuna deviazione irrisolta impedisce l’accettazione.

Esempio:

PASS — Il comportamento di validazione richiesto è implementato.

Modificati: email-validator.ts, email-validator.test.ts
Controlli: test mirato PASS; typecheck PASS
Deviazioni: nessuna
Prossimo passo: revisionare il diff e decidere l’eventuale commit.

PASS non significa che il developer abbia già accettato o committato il lavoro. Significa che l’agente ha soddisfatto il contratto con le evidenze dichiarate.

READY FOR CHECK

Usa READY FOR CHECK quando l’implementazione è completa ma resta una verifica manuale o esterna richiesta.

Motivi tipici:

• è necessaria un’interazione nel browser;
• servono credenziali o un servizio reale;
• lo strumento corrente non consente all’agente di eseguire comandi;
• una valutazione visuale o di usabilità spetta al developer;
• è richiesto un controllo specifico dell’hardware o dell’ambiente.

Esempio:

READY FOR CHECK — Implementazione completata.

Controlli automatici: typecheck PASS
Controllo manuale: inviare il form non valido e verificare l’errore inline
Prossimo passo: eseguire il controllo manuale e comunicare l’esito.

Non usare PASS soltanto perché il codice sembra corretto.

PARTIAL

Usa PARTIAL quando è stata completata soltanto una parte del contratto approvato.

La risposta deve specificare:

• criteri completati;
• criteri incompleti;
• motivo del mancato completamento;
• se il lavoro già svolto può essere conservato in sicurezza;
• decisione o azione successiva.

Esempio:

PARTIAL — Validazione API completata; integrazione UI non implementata.

Completati: AC-1, AC-2
Restante: AC-3
Motivo: il componente form indicato non è presente nel branch target
Prossimo passo: confermare il componente corretto o separare il lavoro UI in un nuovo task.

PARTIAL non è una versione più morbida del successo. Indica che il contratto non è completamente soddisfatto.

BLOCKED

Usa BLOCKED quando il lavoro non può proseguire in sicurezza senza una decisione del developer, un prerequisito mancante o una condizione esterna.

Esempi:

• due fonti canoniche si contraddicono;
• un’API o dipendenza richiesta non esiste;
• credenziali o accesso all’ambiente non sono disponibili;
• il task richiede un’operazione distruttiva non autorizzata;
• nuove evidenze rendono invalido il perimetro approvato;
• serve una decisione di prodotto o architetturale.

Una buona risposta bloccata identifica la decisione precisa invece di descrivere un problema vago.

BLOCKED — Il contratto presume un endpoint non presente.

Evidenza: nessun endpoint di recupero password è presente nell’API o nella roadmap documentata
Decisione richiesta: aggiungere l’endpoint al task, scegliere un’altra integrazione o rinviare la feature
Modifiche non autorizzate: nessuna

FAIL

Usa FAIL quando un controllo richiesto fallisce o l’implementazione non soddisfa il contratto.

Esempi:

• test mirato fallito;
• typecheck fallito a causa della modifica;
• scenario manuale di accettazione con comportamento errato;
• implementazione che viola un’esclusione o un’interfaccia da preservare;
• validazione strutturale con errori.

La risposta dovrebbe includere:

• controllo o criterio fallito;
• evidenza sintetica del fallimento;
• file o comportamento coinvolti;
• se le modifiche sono state ripristinate o restano presenti;
• azione successiva.

Non nascondere un fallimento dietro READY FOR CHECK o PARTIAL quando le evidenze dimostrano già che il risultato è errato.

Esito e stato del workflow sono differenti

Le etichette descrivono il risultato di una singola esecuzione. Lo stato del workflow descrive quanto una procedura documentata è stata validata nell’uso di TCAF.

Per esempio:

• un workflow framework-aligned può produrre PASS in un test specifico;
• un workflow verificato può produrre BLOCKED in un particolare progetto;
• un adapter verificato con limitazioni può comunque completare con successo un task.

Mantieni separate queste dimensioni.

Scrivere prima l’etichetta

La prima riga dovrebbe essere comprensibile senza scorrere. Seguono soltanto le informazioni necessarie alla decisione successiva.

Un successo ordinario può essere sintetico. La risposta deve invece espandersi in presenza di:

• fallimento;
• blocker;
• completamento parziale;
• deviazioni;
• emendamenti;
• evidenze ambigue;
• operazioni distruttive;
• decisioni con alternative significative.

Non migliorare l’esito per presentazione

Una risposta ben scritta non migliora il risultato sottostante.

Non bisogna:

• dichiarare riuscito un comando non eseguito;
• omettere un controllo manuale richiesto per poter dichiarare PASS;
• nascondere criteri incompleti;
• trasformare un controllo fallito in avviso senza autorizzazione;
• trattare file generati come accettati soltanto perché esistono.

Il valore dell’etichetta sta nella sua affidabilità. Un READY FOR CHECK o BLOCKED veritiero è più utile di un PASS ingiustificato.