Ciclo di vita del task

Il ciclo di vita TCAF separa decisione, implementazione, verifica e amministrazione del progetto. Questo evita che un modello interpreti una singola richiesta come autorizzazione ad analizzare, riscrivere, validare, aggiornare lo stato, creare commit e pubblicare senza review intermedie.

Il lifecycle ordinario è:

Fonte del task
→ analisi pertinente
→ Task Contract
→ review e approvazione del developer
→ implementazione preservation-first
→ controlli ed evidenze
→ risposta outcome-first
→ review del developer
→ eventuale riconciliazione
→ eventuale commit o altra operazione finale

Non ogni task richiede tutte le azioni finali opzionali, ma i passaggi sostanziali restano espliciti.

1. Identificare la fonte del task

Si parte dalla fonte dichiarata del lavoro: richiesta diretta, backlog, issue, analisi o altra fonte autorevole.

La fonte stabilisce l’intento. Non definisce automaticamente il confine implementativo.

2. Eseguire l’analisi pertinente

Si ispeziona soltanto ciò che serve a comprendere il comportamento corrente e autorizzare il task in sicurezza.

L’analisi pertinente può includere:

• file rilevanti e implementazione vicina;
• architettura e regole di progetto;
• capability correnti e limitazioni;
• test e comandi di verifica;
• documentazione canonica;
• modifiche del developer già presenti;
• contraddizioni o evidenze mancanti.

L’agente non dovrebbe eseguire un audit illimitato del repository per ogni piccola richiesta. Non dovrebbe nemmeno saltare l’ispezione e affidarsi ad assunzioni.

3. Produrre il Task Contract

L’intento e le evidenze vengono convertiti in un contratto esplicito con obiettivo, confini, aree da preservare, criteri di accettazione, controlli e condizioni di arresto.

Il contratto deve esporre l’incertezza invece di nasconderla dietro un linguaggio sicuro.

4. Review e approvazione del developer

Il developer verifica che il contratto descriva il lavoro corretto.

Le decisioni possibili comprendono:

• approvare;
• richiedere una correzione mirata;
• restringere o ampliare la superficie proposta;
• dividere il task;
• risolvere una contraddizione;
• rifiutare il task;
• eseguire manualmente una parte del lavoro.

Nessuna implementazione sostanziale dovrebbe iniziare soltanto perché il contratto è stato generato.

5. Implementazione preservation-first

Dopo l’approvazione, l’agente implementa soltanto il comportamento autorizzato.

Dovrebbe:

• rileggere i file prima di modificarli;
• integrarsi con lo stato corrente del repository;
• riusare metodi, utility, guard e pattern locali;
• preservare i comportamenti non coinvolti;
• evitare refactoring opportunistici;
• fermarsi quando nuove evidenze invalidano il contratto.

Il developer resta libero di modificare direttamente qualsiasi area. Queste modifiche diventano stato corrente per la successiva azione dell’agente.

6. Gestire le modifiche durante il task

Le nuove informazioni devono essere classificate invece di essere assorbite silenziosamente.

Una modifica può essere:

• chiarimento;
• correzione di non conformità al contratto;
• adattamento tecnico locale;
• emendamento;
• task separato;
• blocker o contraddizione;
• problema collaterale da registrare per dopo.

Un chiarimento può richiedere soltanto una nota. Un emendamento richiede nuova approvazione. Un nuovo obiettivo normalmente diventa un task separato.

7. Eseguire o riportare i controlli

La verifica dovrebbe usare il più piccolo insieme significativo di controlli, normalmente da uno a tre.

I controlli possono comprendere:

• test automatici mirati;
• typecheck;
• lint o compilazione quando pertinenti;
• verifica manuale UI o di integrazione mirata;
• validazione strutturale come tcaf validate.

La risposta deve distinguere:

• controlli realmente eseguiti dall’agente;
• controlli indicati al developer;
• controlli non disponibili per limiti dello strumento;
• controlli falliti o incompleti.

8. Restituire una risposta outcome-first

La prima riga dovrebbe dichiarare l’esito corrente, per esempio PASS, READY FOR CHECK, PARTIAL, BLOCKED o FAIL.

La risposta riporta poi soltanto ciò che serve al developer per decidere il passo successivo:

• risultato ottenuto;
• file o aree modificati;
• controlli eseguiti ed esiti;
• verifiche manuali ancora necessarie;
• deviazioni o limitazioni;
• azione precisa richiesta al developer.

Il successo ordinario dovrebbe restare compatto. Blocker, deviazioni, emendamenti e decisioni irrisolte richiedono spiegazioni maggiori.

9. Review del risultato da parte del developer

Il developer revisiona implementazione ed evidenze reali, non soltanto il riepilogo dell’agente.

Può:

• accettare il lavoro;
• eseguire verifiche manuali;
• richiedere una correzione;
• modificare direttamente il codice;
• emendare il task;
• rifiutare parte dell’implementazione;
• decidere che un follow-up appartiene a un task separato.

Un PASS dichiarato dall’agente non elimina il review gate umano.

10. Riconciliazione opzionale

Backlog, documentazione di progetto, stato delle capability o issue esterne possono richiedere un aggiornamento dopo l’accettazione del lavoro.

La riconciliazione è separata perché il risultato implementato e lo stato registrato del progetto possono divergere. L’aggiornamento deve riflettere evidenze accettate, non soltanto il piano originale.

Non segnare come completati elementi estranei e non riscrivere opportunisticamente documentazione storica.

11. Commit e pubblicazione opzionali

Commit, tag, push, merge, release e deploy sono operazioni autorizzate separatamente.

Un’implementazione completata non le autorizza automaticamente. È il developer a decidere quando il lavoro è accettato e quale operazione sul repository deve seguire.

Gli stati del lifecycle non sono stati della conversazione

Il task non diventa approvato perché la conversazione è proseguita e non diventa completato perché l’agente ha smesso di scrivere.

Gli stati espliciti contano:

• contratto proposto;
• contratto approvato;
• implementazione in corso;
• pronto per controllo manuale;
• bloccato;
• accettato;
• riconciliato;
• committato.

Mantenere distinti questi stati rende il workflow portabile tra strumenti e sessioni differenti.

Riprendere dopo un’interruzione

Quando uno strumento o una sessione falliscono, si riparte dalle evidenze di progetto e dal contratto approvato, non dalla memoria del modello.

Prima di continuare:

1. ispeziona lo stato corrente del repository;
2. identifica modifiche del developer o dello strumento già applicate;
3. conferma contratto attivo e stato di approvazione;
4. determina lavoro completato e restante;
5. ripeti i controlli influenzati dall’interruzione.

È così che TCAF mantiene continuità senza dipendere dalla memoria di una singola conversazione.