Skip to content
TCAFTask-Contract AI Development Framework
TCAF 0.4.0 · anteprima pubblica

Come funziona TCAF

Segui il workflow di delivery TCAF 0.4.0 dalle evidenze di progetto e pianificazione fino a esecuzione delimitata, sincronizzazione e accettazione del developer.

TCAF usa una regola semplice: l’AI riceve soltanto l’autorità necessaria per l’operazione corrente. Repository, evidenze di progetto e decisioni del developer definiscono il contesto; la memoria della chat no.

Il software appartiene al developer. TCAF definisce come l’assistenza AI entra nel lavoro senza acquisire un’autorità indipendente su di esso.

Le cinque operazioni principali

tcaf bootstrap --target <target> [--request <testo> | --input <materiale>]
tcaf adopt --target <target> [--request <testo> | --input <materiale>]
tcaf plan --target <target> (--request <feature> | --input <specifica>)
tcaf task --target <target> (--request <richiesta-delimitata> | --input <fonte-task>)
tcaf sync --target <target> [--request <nuova-informazione> | --input <materiale>]

Rispondono a cinque domande diverse:

  • bootstrap — quale stato di progetto serve per partire in sicurezza?
  • adopt — cosa esiste davvero oggi in questo repository?
  • plan — come va scomposta questa feature o questo risultato più ampio?
  • task — cosa è autorizzata a modificare l’AI adesso?
  • sync — cosa è cambiato fuori dall’esecuzione corrente e quale stato va riconciliato?

tcaf run <agent-id> resta disponibile per l’invocazione diretta di un agente registrato, ma è un’operazione avanzata e non il normale punto di partenza.

Il percorso di delivery

Un progetto normale non usa tutte e cinque le operazioni ogni volta.

  1. Avvia o adotta — usa bootstrap per un nuovo progetto oppure adopt per uno esistente.
  2. Pianifica quando serve — usa plan quando il risultato richiesto è troppo ampio per un singolo task delimitato.
  3. Esegui un task — usa task per creare il Task Contract, revisionarlo e poi lasciare che l’AI esegua il lavoro approvato dentro quel confine.
  4. Verifica — distingui controlli realmente eseguiti da verifiche ancora necessarie o manuali.
  5. Sincronizza quando cambia la realtà — usa sync dopo modifiche manuali del developer, nuove specifiche, cambi esterni o altri aggiornamenti fuori dall’esecuzione che influenzano stato o lavoro pianificato.

Questa è Software Delivery Governance applicata al lavoro assistito dall’AI, non proprietà autonoma del progetto.

Dentro un singolo task

Il ciclo del task resta volutamente breve:

richiesta → ispezione del repository → Task Contract → approvazione del developer → esecuzione delimitata → evidenze di verifica → accettazione del developer

Il Task Contract è il confine di autorizzazione. Se il lavoro richiede di uscire da quel confine, l’AI si ferma o richiede un amendment invece di ampliare silenziosamente lo scope.

Specifiche ed evidenze del repository

TCAF è spec-driven, ma “specifica” non significa un singolo formato TCAF obbligatorio.

La source evidence può già esistere come:

  • requisiti o analisi funzionale;
  • README e note architetturali;
  • piani e roadmap;
  • backlog o issue;
  • codice, test e configurazione;
  • richieste dirette del developer.

TCAF legge le evidenze pertinenti all’operazione corrente. Quando è utile uno stato canonico separato, può derivarlo da quel materiale senza riscrivere prima i documenti sorgente.

Esecuzione preservation-first

Quando si modifica software esistente, il risultato atteso è:

NEW BEHAVIOR = EXISTING VERIFIED BEHAVIOR + REQUESTED DELTA

L’AI dovrebbe riusare metodi, utility, servizi, guard, convenzioni e test locali quando appropriato. Una soluzione “più pulita” non autorizza una riscrittura estranea.

La verifica richiede evidenze

Il codice generato non dimostra che il task sia completo. TCAF separa:

  • controlli realmente eseguiti;
  • controlli che deve ancora eseguire il developer;
  • limitazioni o blocker;
  • decisione finale di accettazione.

Anche una validazione strutturale, da sola, non costituisce verità semantica.

Gli adapter cambiano il trasporto, non l’autorità

Codex, Cline e altri host possono trasportare lo stesso modello operativo in modi differenti. Un host più capace può eseguire direttamente una parte maggiore del lavoro approvato, ma non riceve uno scope più ampio.

La copertura corrente degli adapter è documentata separatamente in Copertura di validazione e Seleziona un adapter.

Continua da qui