Il Task Contract
Comprendi il confine di autorizzazione esplicito che trasforma una richiesta in lavoro delimitato e revisionabile.
Un Task Contract è il confine operativo approvato per una singola unità di lavoro. Non è soltanto un riepilogo della richiesta e non è un enorme prompt che prova a controllare ogni riga di codice.
Rende esplicite le parti importanti prima dell’implementazione:
- risultato richiesto;
- evidenze di progetto che sostengono il task;
- cosa può modificare l’AI;
- cosa deve restare invariato;
- criteri di accettazione;
- controlli pertinenti;
- condizioni di arresto.
Generare un Task Contract non autorizza l’implementazione. Prima viene revisionato e approvato dal developer.
Task Contract e Task-Contract Development
Il Task-Contract Development è l’approccio più ampio implementato da TCAF. Integra pianificazione spec-driven, esecuzione agentica/harness e governance della delivery in unità di cambiamento esplicite, delimitate e verificabili.
Il Task Contract è il meccanismo che rende concreto questo approccio per una singola unità di lavoro. Collega il risultato atteso ad autorità di esecuzione, requisiti di preservazione, verifica e controllo umano.
Perché una richiesta non basta
Una richiesta come “aggiungi l’esportazione CSV” può descrivere bene il risultato e lasciare comunque impliciti scope, file coinvolti, pattern esistenti e verifica. Un modello AI può riempire questi spazi con assunzioni.
Il Task Contract espone le assunzioni prima che diventino codice.
Cosa contiene un contratto utile
Fonte del task
Da dove arriva il lavoro: richiesta del developer, backlog, issue, specifica, bug report o un’altra fonte dichiarata.
Obiettivo
Il risultato osservabile che deve diventare vero dopo il task.
Evidenze pertinenti
Soltanto i fatti del repository necessari al task: comportamento corrente, architettura rilevante, metodi o servizi esistenti, vincoli e incertezze sostanziali.
Superficie di modifica consentita
File, moduli o aree comportamentali che possono dover cambiare. Deve essere abbastanza ampia per un’implementazione coerente e abbastanza stretta da lasciare fuori il lavoro non correlato.
Aree da preservare
Comportamenti, file, interfacce, validazioni, dipendenze o altre aree che devono restare invariate.
Accettazione e verifica
Criteri osservabili di completamento più i controlli automatici o manuali minimi pertinenti. I controlli eseguiti e quelli DEVELOPER_RUN devono restare distinguibili.
Condizioni di arresto
Condizioni che richiedono all’AI di fermarsi invece di improvvisare: evidenze contraddittorie, espansione dello scope, dipendenza mancante, decisione architetturale non approvata o operazione distruttiva.
Review prima dell’approvazione
Prima di approvare verifica che l’obiettivo corrisponda alla richiesta reale, le assunzioni siano sostenute da evidenze, la superficie di modifica sia proporzionata, comportamento esistente e modifiche del developer siano protetti e i controlli siano realistici.
Se emerge una nuova decisione sostanziale, modifica il contratto oppure crea un task separato invece di ampliare silenziosamente quello corrente.
Approvazione ed esecuzione
Dopo l’approvazione, l’AI può eseguire il lavoro approvato dentro quel confine, rispettando lo stato corrente del repository.
Il developer resta libero di modificare codice, sostituire un approccio, fermare l’esecuzione o svolgere manualmente parte del lavoro. Queste modifiche diventano stato corrente del progetto e devono essere rilette prima che l’AI continui.
Relazione con preservation-first
Il Task Contract definisce cosa può cambiare. Preservation-first definisce come quella modifica deve integrarsi nel software esistente.
Insieme rendono esplicito il delta richiesto senza bloccare decisioni ingegneristiche legittime e senza autorizzare riscritture estranee.