Scegli il percorso

TCAF usa un solo modello operativo, ma l’operazione iniziale corretta dipende da ciò che esiste già e dal risultato che devi ottenere.

Scegli il percorso partendo dallo stato corrente del progetto, non dallo strumento che intendi usare. Codex, Cline e gli altri adapter trasportano il workflow; non lo determinano.

Stai avviando un nuovo progetto

Usa bootstrap quando il target non dispone ancora delle evidenze canoniche richieste da TCAF e vuoi impostare un nuovo prodotto o una nuova codebase.

tcaf bootstrap --target <target> --request <richiesta-iniziale>

Il bootstrap può partire da:

• un’idea di prodotto;
• un’analisi funzionale completa o parziale;
• un repository inizializzato o uno scaffold;
• una roadmap esistente;
• un solo primo task aperto;
• un backlog proposto da sottoporre alla review del developer.

Il target non deve essere già un repository Git maturo prima dell’operazione. Il developer continua comunque a revisionare architettura, assunzioni di pianificazione e documenti di progetto proposti prima di procedere con l’implementazione.

Continua con Avvia un nuovo progetto.

Hai un progetto esistente che non ha ancora adottato TCAF

Usa adopt quando il software esiste già ma TCAF non dispone ancora di evidenze canoniche affidabili su architettura, capacità, regole e workflow.

tcaf adopt --target <percorso-progetto>

L’adozione è inspect-first. Deve osservare il repository, identificare percorsi e capacità reali, creare o riconciliare i documenti canonici e fermarsi al review gate del developer.

L’operazione di adozione non deve modificare silenziosamente:

• codice applicativo;
• aree funzionanti tramite refactoring;
• dipendenze;
• lavoro presente nel backlog;
• commit o stato remoto.

Continua con Adotta un progetto esistente.

Il progetto è già pronto e devi eseguire un task delimitato

Usa task quando le evidenze di progetto sono disponibili e la prossima unità di lavoro è conosciuta.

tcaf task --target <percorso-progetto> --request <richiesta-delimitata>

La richiesta può provenire da:

• backlog del repository;
• GitHub Issue;
• richiesta aperta del developer;
• analisi funzionale o tecnica;
• segnalazione di un bug;
• discrepanza documentale o di stato.

TCAF esegue l’analisi pertinente, produce un Task Contract e ritorna alla review del developer prima di ampliare l’autorità di implementazione.

Continua con Esegui un task di sviluppo.

Il task è attivo e la richiesta cambia

Non ampliare automaticamente il task corrente.

Classifica prima la nuova informazione come una delle seguenti:

• chiarimento — spiega il requisito esistente senza modificarne il risultato autorizzato;
• correzione — riporta il lavoro in conformità con il contratto corrente;
• adattamento tecnico locale — cambia il dettaglio implementativo senza cambiare perimetro o accettazione;
• amendment — modifica il task autorizzato e richiede approvazione esplicita del developer;
• task separato — rappresenta lavoro utile ma indipendente;
• blocker o contraddizione — impedisce una continuazione sicura;
• modifica del developer — cambia lo stato corrente del progetto e deve essere riletta e preservata.

Continua con Modifiche durante un task attivo.

Il codice e lo stato registrato del progetto non coincidono

Usa il workflow di riconciliazione quando implementazione, backlog, stato delle issue o documentazione di progetto non descrivono più la stessa realtà.

La riconciliazione deve determinare cosa è realmente implementato, cosa resta aperto e quali registrazioni devono essere aggiornate. Non deve dedurre il completamento di una feature dalle sole etichette o assumere che timestamp recenti dimostrino il comportamento corrente.

Continua con Riconcilia lo stato del progetto.

Il lavoro è stato revisionato e accettato

Il commit è un’operazione separata e autorizzata dal developer. Un’implementazione o una verifica riuscita non concede automaticamente il permesso di:

• aggiungere file allo staging;
• aggiornare elementi del backlog;
• chiudere issue;
• creare un commit;
• creare tag;
• eseguire push verso il remoto.

Continua con Registra il lavoro accettato con un commit.

Scegli l’adapter soltanto dopo aver scelto il workflow

L’adapter determina come la Run Envelope raggiunge il modello:

• usa codex per l’integrazione nativa Codex verificata;
• usa cline per la procedura manual-envelope verificata;
• usa generic-cli quando un host da riga di comando può ricevere l’envelope ma non modificare direttamente;
• usa generic-chat soltanto quando l’host può mantenere disponibile il framework e associare il target in modo affidabile.

Leggi Seleziona un adapter prima della prima esecuzione.

Quando non sei sicuro

Preferisci il percorso più ristretto:

• adotta il progetto prima di presumere che sia pronto;
• ispeziona prima di scrivere;
• crea un solo task delimitato prima di generare un piano implementativo ampio;
• fermati per la review invece di trasformare silenziosamente l’incertezza in nuovo perimetro.

TCAF è progettato per rendere esplicita la prossima decisione sicura. Non è progettato per massimizzare l’attività autonoma.