Introduzione

TCAF è un framework governance-first e spec-driven per una delivery software con AI controllata. Implementa il Task-Contract Development: un approccio che integra pianificazione spec-driven, esecuzione agentica/harness e governance della delivery in unità di cambiamento esplicite, delimitate e verificabili.

TCAF limita l’esecuzione dell’AI, non l’autorità del developer.

L’idea in un minuto

TCAF mantiene esplicite poche cose importanti:

specifiche ed evidenze del repository descrivono cosa esiste e cosa deve cambiare;
il lavoro più ampio può essere pianificato prima di dividerlo in task eseguibili;
ogni task sostanziale riceve un Task Contract con obiettivo, confini, controlli e condizioni di arresto;
l’AI può eseguire il lavoro approvato dentro quel confine;
modifiche del developer e stato del repository restano autorevoli;
le evidenze di verifica vengono separate dalle dichiarazioni;
lo stato del progetto può essere sincronizzato dopo modifiche manuali, esterne o avvenute fuori dall’esecuzione corrente.

Il developer continua a possedere architettura, decisioni tecniche, code review, verifica e accettazione finale.

Task-Contract Development

TCAF usa il termine Task-Contract Development per l’approccio operativo che riunisce tre discipline complementari in un unico modello di delivery:

Spec-Driven Development — specifiche ed evidenze definiscono cosa deve essere costruito;
Agentic / Harness Engineering — runtime, adapter, contesto e regole rendono l’esecuzione AI ripetibile tra strumenti diversi;
Software Delivery Governance — pianificazione, confini di autorizzazione, sincronizzazione, verifica e approvazione mantengono controllata la delivery.

Il Task Contract è il punto in cui questi elementi diventano operativi per una singola unità di cambiamento: intento, autorità di esecuzione, preservazione, controlli e condizioni di arresto vengono resi espliciti prima che inizi un’implementazione sostanziale.

Non devi conoscere questi termini prima di usare TCAF. Spiegano il design; la CLI resta piccola.

Cinque operazioni

tcaf bootstrap   # avvia un nuovo progetto dal materiale che possiedi già
tcaf adopt       # ispeziona e adotta un progetto esistente
tcaf plan        # scompone una feature o un risultato più ampio
tcaf task        # prepara un singolo Task Contract delimitato
tcaf sync        # rilegge il progetto e riconcilia aggiornamenti approvati

Usa soltanto l’operazione che corrisponde alla prossima decisione da prendere.

Perché esiste TCAF

I tool AI per il coding sono veloci, ma un prompt aperto può lasciare troppe cose implicite. Un modello può dedurre requisiti mancanti, ampliare lo scope, rifattorizzare codice funzionante, ignorare convenzioni locali o dichiarare controlli mai eseguiti.

TCAF sostituisce questa libertà implicita con evidenze esplicite, una superficie di autorizzazione delimitata e la review del developer.

L’obiettivo non è aggiungere processo. È rendere l’assistenza AI più semplice da verificare, revisionare e continuare tra strumenti e sessioni differenti.

Repository-grounded, non dipendente dalla memoria della chat

Il normale materiale di progetto può essere usato come source evidence: README, specifiche, note architetturali, piani, roadmap, codice esistente e altri documenti del repository. TCAF non richiede di riscriverli prima in un formato speciale.

Quando è utile uno stato canonico separato del progetto, TCAF può derivarlo da quelle evidenze. Non è un formato di input obbligatorio.

Questo mantiene il workflow model-agnostic e riduce la dipendenza dalla storia di una singola chat.

Cosa non è TCAF

TCAF non è un project manager autonomo, un sostituto del giudizio ingegneristico o una forma più strutturata di vibe coding. L’AI non possiede architettura, scope o accettazione.

Esegue lavoro delegato. Il software resta nelle mani del developer o del team.

Perimetro della validazione

TCAF 0.4.0 dispone di evidenze di accettazione semantic BLACK_BOX per gli scenari core coperti, compreso l’uso di normale materiale di progetto senza preprocessing manuale esperto. È una dichiarazione circoscritta: non significa che siano stati testati tutti i modelli, adapter, host, tipi di repository o configurazioni.

Consulta Copertura di validazione per il confine attuale esatto.