Skip to content
TCAFTask-Contract AI Development Framework
TCAF 0.3.3

Come funziona TCAF

Segui il percorso operativo completo di TCAF da una richiesta del developer all’implementazione delimitata, alle evidenze e alla review.

Contenuto: completeWorkflow: —

TCAF fornisce una sola disciplina operativa per modelli AI, strumenti, stati di progetto e fonti dei task differenti. Non chiede al developer di consegnare lo sviluppo software a un agente autonomo. Assegna all’AI un incarico preciso e temporaneo, mentre il developer o il team resta libero di lavorare direttamente su qualsiasi parte della codebase.

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

Le operazioni pubbliche

Il runtime espone un insieme ristretto di operazioni pubbliche:

tcaf bootstrap --target <target> [--request <testo> | --input <percorso>]
tcaf adopt --target <target>
tcaf task --target <target> --request <richiesta-delimitata>
tcaf run <agent-id> --target <target>

Coprono quattro esigenze distinte:

  • bootstrap imposta un nuovo progetto partendo da un’idea, un’analisi, uno scaffold, una roadmap o un primo task;
  • adopt ispeziona un progetto esistente e crea le evidenze canoniche richieste da TCAF;
  • task prepara un task di sviluppo delimitato a partire da una richiesta esplicita;
  • run invoca direttamente un agente pubblico registrato quando quell’agente rappresenta già l’operazione desiderata.

Il developer sceglie l’operazione e il target. Il runtime risolve i moduli interni del framework.

La pipeline operativa

Ogni operazione segue lo stesso percorso generale:

  1. Selezione dell’operazione — il developer sceglie quale tipo di lavoro richiedere.
  2. Risoluzione del registro — TCAF risolve l’operazione pubblica o l’agent ID.
  3. Caricamento del manifest dell’agente — il manifest dichiara moduli esatti, politica del target e output atteso.
  4. Caricamento del contesto pertinente — vengono caricate soltanto le istruzioni del framework e le evidenze di progetto rilevanti per l’operazione.
  5. Associazione a un singolo target — l’esecuzione è vincolata a un solo progetto o percorso target.
  6. Selezione dell’adapter — lo stesso comportamento fondamentale viene trasportato attraverso Codex, Cline, una CLI generica o un altro host supportato.
  7. Generazione della Run Envelope — il modello riceve operazione, target, vincoli, requisiti di evidenza e review gate.
  8. Review del developer — il developer revisiona contratto, output o file proposto prima del passaggio sostanziale successivo.

Il framework installato resta fuori dal progetto target. Le evidenze di progetto e le istruzioni del framework vengono mantenute deliberatamente separate.

Dalla richiesta al Task Contract

Una richiesta non equivale automaticamente al permesso di modificare tutto ciò che potrebbe aiutare a raggiungere l’obiettivo.

Prima dell’implementazione, TCAF trasforma la richiesta e lo stato pertinente del progetto in un Task Contract. In base al task, il contratto identifica:

  • obiettivo e differenza comportamentale richiesta;
  • superficie di modifica consentita;
  • file, comportamenti o sistemi che devono restare invariati;
  • funzioni, metodi, utility o pattern esistenti da riusare;
  • refactoring, cambi di dipendenza o lavoro collaterale vietati;
  • criteri di accettazione;
  • da uno a tre controlli pertinenti o procedure da eseguire manualmente;
  • condizioni di arresto, blocker e aspettative di review.

Il contratto è un confine di autorizzazione, non un semplice riepilogo della richiesta.

L’implementazione resta nelle mani del developer

TCAF non riduce il developer a un approvatore che accetta o rifiuta soltanto l’output dell’AI.

Il developer o il team può in qualsiasi momento:

  • ispezionare o modificare direttamente il codice;
  • progettare l’architettura;
  • sostituire una decisione implementativa;
  • aggiungere test o diagnostica;
  • interrompere l’esecuzione dell’AI;
  • modificare, rifiutare o sostituire il Task Contract;
  • svolgere manualmente una parte del task e lasciare che l’AI continui dal nuovo stato.

Le modifiche manuali del developer diventano stato autorevole del progetto. L’AI deve rileggerle e integrarsi con esse, invece di ripristinare uno snapshot precedente o trattarle come interferenze.

Implementazione preservation-first

Quando modifica software già implementato, l’agente dovrebbe estendere il linguaggio locale dell’implementazione invece di sostituirlo con la soluzione che preferisce.

Questo significa riusare gli elementi pertinenti già presenti:

  • metodi e confini dei servizi;
  • utility condivise e moduli helper;
  • validazioni, guard e controlli dei permessi;
  • convenzioni di gestione degli errori e logging;
  • pattern di stato, dependency injection e accesso ai dati;
  • convenzioni di naming, tipizzazione e cartelle;
  • interfacce pubbliche, test e comandi di verifica.

Un’alternativa teoricamente più pulita non autorizza una riscrittura. Il refactoring resta possibile, ma deve essere richiesto dal task, dichiarato nel contratto o approvato separatamente.

Leggi il principio completo preservation-first.

Verifica ed evidenze

L’agente deve distinguere il lavoro prodotto dal lavoro verificato.

Un task normale utilizza il più piccolo insieme di verifiche pertinenti, di solito da uno a tre controlli. In base allo strumento, l’agente può eseguirli oppure riportare comandi DEVELOPER_RUN e procedure manuali esatte.

L’esito finale dovrebbe rendere chiaro:

  • cosa è cambiato;
  • cosa è stato realmente controllato;
  • cosa non è stato possibile controllare;
  • se il risultato è pronto per la review del developer;
  • se resta un blocker, un risultato parziale o un fallimento;
  • quale azione deve svolgere successivamente il developer.

Un output plausibile non viene trattato come evidenza.

L’adapter cambia il trasporto, non l’autorità

Strumenti differenti richiedono modalità di interazione differenti:

  • Codex supporta attualmente un’invocazione nativa verificata;
  • Cline usa attualmente una procedura manual-envelope verificata con step espliciti INSPECT, WRITE e VALIDATE;
  • CLI e chat generiche hanno vincoli di accesso differenti.

L’adapter può cambiare il modo in cui le istruzioni raggiungono il modello, ma non deve ampliare target, perimetro del task o permessi definiti dall’operazione fondamentale.

Perché non è vibe coding

Il vibe coding parte spesso da un’intenzione e lascia al modello il compito di dedurre architettura, perimetro e scelte implementative, mentre l’utente reagisce al risultato.

TCAF parte da un modello di proprietà opposto:

  • repository e decisioni esistenti sono evidenze;
  • il developer resta l’ingegnere attivo;
  • l’AI riceve lavoro delimitato;
  • le modifiche vengono integrate invece di generare riscritture opportunistiche;
  • la verifica viene riportata separatamente dalla generazione;
  • ogni passaggio sostanziale ritorna alla review umana.

Lo scopo non è rallentare lo sviluppo. È rendere l’accelerazione fornita dall’AI compatibile con una responsabilità ingegneristica reale e con una codebase che deve restare comprensibile anche dopo la fine della sessione corrente.

Continua da qui