Stato dei workflow
Comprendi gli stati indipendenti di contenuto e workflow usati nella documentazione TCAF.
TCAF separa quanto è completa una pagina di documentazione da quanto il workflow sottostante è stato implementato e verificato.
Le due dimensioni sono indipendenti. In questo modo un testo ben rifinito non viene scambiato per una prova operativa e una procedura verificata non scompare soltanto perché la spiegazione pubblica è ancora in espansione.
Stato del contenuto
complete
La pagina dispone di una spiegazione bilingue completa per il proprio perimetro editoriale corrente. Può comunque evolvere con nuovi esempi, evidenze o versioni successive di TCAF.
complete non significa che ogni workflow descritto sia stato verificato con qualsiasi strumento, modello o configurazione di progetto.
draft
La pagina contiene materiale utile, ma uno o più elementi editoriali sono ancora incompleti. Le cause tipiche comprendono:
- esempi ancora da revisionare;
- una sezione intenzionalmente più breve rispetto alla versione finale;
- fonti o riferimenti di evidenza ancora in fase di riconciliazione;
- testi italiano e inglese sufficienti per la pubblicazione ma non ancora considerati definitivi.
placeholder
La route esiste nella struttura documentale pubblicata, ma la spiegazione bilingue completa non è ancora stata scritta.
Il placeholder è esplicito. TCAF non mostra silenziosamente contenuto inglese su una route italiana o contenuto italiano su una route inglese.
Stato del workflow
verified
Il workflow o la capacità è stato eseguito con successo in un percorso di test rappresentativo o in un progetto reale e il comportamento atteso dispone di evidenze di supporto.
La verifica è circoscritta. Non implica che sia stata testata ogni combinazione di modello, sistema operativo, adapter e tipologia di progetto.
verified-with-limitations
Il workflow fondamentale è stato eseguito con successo, ma rimane una limitazione conosciuta di strumento, trasporto o copertura.
Il workflow manual-envelope di Cline è un esempio: la procedura delimitata è verificata, mentre l’invocazione nativa runner-to-Cline resta non verificata e il comportamento della UI di approvazione può richiedere gestione manuale.
framework-aligned
Il workflow è definito in modo coerente con l’architettura e i principi operativi approvati di TCAF, ma non ha ancora superato test di accettazione dedicati sufficienti per essere dichiarato verificato.
La documentazione può essere comunque completa. Lo stato informa il lettore che completezza progettuale e validazione empirica non sono la stessa cosa.
documentation-in-progress
Il workflow esiste o dispone di evidenze, ma la documentazione pubblica è in fase di riconciliazione e non dovrebbe ancora essere trattata come riferimento stabile.
Questo stato può essere usato in una fase di transizione quando fonte operativa e spiegazione pubblica sono temporaneamente disallineate.
planned
La capacità è inclusa intenzionalmente nella roadmap ma non è ancora disponibile o validata come workflow operativo.
Una pagina pianificata può spiegare il confine previsto e la limitazione corrente, evitando che il lettore deduca un supporto inesistente.
not-supported
TCAF non esegue deliberatamente l’operazione come azione autonoma del framework.
Per esempio, staging Git, commit, tagging e push restano operazioni separate autorizzate dal developer. La documentazione può spiegarne la collocazione sicura nel processo senza presentarli come permessi automatici dell’agente.
Nessuno stato del workflow
Pagine informative, pagine di navigazione e panoramiche concettuali possono non avere uno stato del workflow perché non rappresentano una singola procedura eseguibile.
Come leggere l’intestazione di una pagina
Una pagina può essere correttamente:
content: completeeworkflow: framework-aligned;content: drafteworkflow: verified;content: placeholdereworkflow: planned;content: completesenza stato del workflow.
I due badge devono essere interpretati insieme.
La verifica è evidenza, non garanzia universale
TCAF è attualmente pre-1.0. Le verifiche esistenti dimostrano che percorsi specifici si sono comportati come previsto nelle condizioni documentate. Non garantiscono un comportamento identico per ogni futuro modello, integrazione host o repository.
Per questo il framework usa:
- stato esplicito degli adapter;
- evidenze circoscritte;
- review gate del developer;
- etichette degli esiti come
PASS,PARTIAL,BLOCKEDeFAIL; - limitazioni visibili invece di deduzioni ottimistiche.
Quando modificare uno stato
Uno stato dovrebbe cambiare soltanto quando cambiano le evidenze sottostanti:
- test di accettazione riusciti possono promuovere
framework-alignedaverified; - una nuova limitazione può modificare
verifiedinverified-with-limitations; - la rimozione di un’implementazione può richiedere
plannedonot-supported; - il completamento di entrambe le lingue può promuovere il contenuto da
draftoplaceholderacomplete.
Le modifiche di stato sono lavoro di documentazione e riconciliazione del progetto. Devono essere revisionate, non dedotte automaticamente dal successo di una modifica al codice.