Evidenze di progetto
Comprendi come TCAF usa normale materiale di progetto ed evidenze del repository come contesto durevole tra strumenti e sessioni.
TCAF non dipende da una singola chat per ricordare come funziona un progetto. Rilegge repository e project evidence.
Le istruzioni del framework vivono nel runtime TCAF installato. La verità del progetto arriva dal progetto target e dalle sue evidenze.
Il normale materiale è source evidence valida
Un progetto può già contenere README, specifiche, note architetturali, ADR, piani, roadmap, backlog, issue, runbook e codice funzionante.
TCAF non richiede di convertire questo materiale in un formato speciale prima dell’uso. Il materiale autorevole esistente resta source evidence.
Questo vale sia per bootstrap sia per adopt.
Lo stato canonico viene derivato soltanto quando serve
Alcuni workflow beneficiano di uno stato di progetto compatto che mappa fatti importanti, per esempio:
- confini del progetto e root applicative;
- architettura e capability correnti;
- regole specifiche del progetto;
- fonti autorevoli dei task;
- comandi pertinenti di build, test o validazione;
- limitazioni note e domande aperte.
TCAF può derivare questo stato dalle evidenze disponibili. Non dovrebbe duplicare un documento autorevole esistente soltanto per farlo assomigliare a un documento TCAF.
Le evidenze devono descrivere la realtà
Un documento dettagliato non è automaticamente corretto. Verifica che percorsi e comandi esistano davvero, capability correnti e pianificate siano separate, le incognite restino visibili e l’architettura descriva il repository invece di una versione ideale inventata.
La validazione strutturale può controllare schema e coerenza. Non può dimostrare che ogni dichiarazione sia semanticamente vera.
Preserva materiale sorgente e storia
Documenti storici, modifiche del developer e source evidence esistenti non devono essere riscritti soltanto per uniformare la formattazione o adattarsi a un template.
Quando la realtà del progetto cambia fuori dall’esecuzione corrente, usa tcaf sync per rileggere il repository e proporre la più piccola riconciliazione necessaria. Una nuova specifica è evidenza da ispezionare, non verità di progetto automaticamente approvata.
Separa stato corrente e stato desiderato
Piani e specifiche descrivono spesso ciò che il team vuole ottenere, mentre il codice descrive ciò che esiste adesso. TCAF mantiene esplicite queste categorie per evitare di confondere lavoro pianificato e comportamento implementato.
Distinzioni utili comprendono stato corrente, stato desiderato, decisione confermata, proposta, domanda aperta e contesto storico.
Perché questo favorisce l’indipendenza dal modello
Evidenze di progetto durevoli possono essere ispezionate nuovamente da un altro modello o strumento. Questo riduce la dipendenza dalla memoria privata della chat, dal formato di regole di un singolo vendor o dal riepilogo di un agente precedente.
L’obiettivo non è produrre più documentazione. È mantenere continuità affidabile a partire da evidenze che appartengono al progetto.