Skip to content
TCAFTask-Contract AI Development Framework
TCAF 0.3.3

Adotta un progetto esistente

Stabilisci evidenze affidabili sul progetto prima di delegare attività di sviluppo in un repository già esistente.

Contenuto: completeWorkflow: verified

L’adozione collega TCAF a un repository che contiene già codice, decisioni e comportamenti funzionanti. Serve a stabilire evidenze affidabili sul progetto prima di autorizzare qualsiasi task di sviluppo.

L’adozione osserva il progetto. Non lo migliora, modernizza o riscrive.

Esegui il workflow di adozione

Da qualsiasi directory indica esplicitamente il repository target:

tcaf adopt --target <progetto-esistente>

Il comando produce una Run Envelope per l’adapter selezionato. Passala allo strumento host e controlla il perimetro proposto prima di consentire la scrittura dei documenti.

Cosa ispeziona l’agente di adozione

L’agente deve leggere soltanto le evidenze necessarie a descrivere correttamente il progetto, tra cui quando pertinenti:

  • struttura del repository e confini applicativi;
  • manifest di package e dipendenze;
  • capacità di build, test, lint e validazione realmente presenti;
  • framework, linguaggi, gestione dello stato e persistenza;
  • configurazione CI e prove di deployment;
  • documentazione esistente, backlog e fonti dei task;
  • convenzioni implementative locali e limitazioni note.

Anche l’assenza è un’evidenza. L’agente non deve inventare test framework, architetture, database, livelli di validazione o processi di delivery che il progetto non possiede.

Documenti di progetto attesi

L’adozione crea o riconcilia normalmente i documenti canonici richiesti dal profilo del progetto, per esempio:

  • manifest del progetto;
  • capability baseline;
  • baseline architetturale o tecnica;
  • backlog e mappatura delle fonti dei task;
  • registri di stima o decisione quando pertinenti;
  • note di stato e validazione.

L’insieme esatto dipende dal progetto. I documenti devono descrivere il repository trovato, non una sua versione futura idealizzata.

Confine dell’adozione

Senza un task separato autorizzato dal developer, l’adozione non deve:

  • modificare codice applicativo;
  • rifattorizzare aree funzionanti;
  • aggiungere o aggiornare dipendenze;
  • riformattare file non pertinenti;
  • introdurre test o infrastruttura non già disponibili;
  • presentare informazioni incerte come fatti;
  • eseguire commit, tag, push o aprire pull request.

Verifica il risultato

Prima di accettare l’adozione controlla che:

  1. i percorsi riportati nei documenti corrispondano al repository;
  2. le capacità implementate siano separate da quelle pianificate;
  3. limitazioni e incognite restino visibili;
  4. le fonti del backlog siano mappate senza sostituzioni silenziose;
  5. nessun file applicativo sia stato modificato;
  6. il target superi la validazione.

Esegui:

tcaf validate --target <progetto-esistente>

Una validazione positiva conferma la coerenza strutturale. Non dimostra che ogni affermazione architetturale sia corretta: le evidenze devono comunque essere revisionate dal developer.

Dopo l’adozione

Una volta accettati, i documenti canonici diventano il contesto iniziale dei task di sviluppo delimitati. Non sostituiscono l’ispezione dell’implementazione locale pertinente a ciascun task.

Continua con Esegui un task di sviluppo oppure scegli una fonte specifica, come un backlog esistente o una GitHub Issue.