Fonti dei task

TCAF non obbliga ogni progetto a gestire il lavoro tramite lo stesso tracker o file di backlog. Un task può nascere da fonti differenti, purché la fonte sia esplicita, autorevole per quel progetto e sufficiente a creare un Task Contract delimitato.

La fonte del task risponde a una domanda semplice:

Quale richiesta, issue, analisi o decisione autorizza questa unità di lavoro?

Tipi di fonte supportati

Le fonti tipiche comprendono:

una richiesta diretta del developer;
un elemento del backlog nel repository;
una GitHub Issue o un elemento di un altro tracker esterno;
un’analisi funzionale o tecnica;
un bug report con evidenze di riproduzione;
una roadmap o un documento di pianificazione;
un singolo task aperto dichiarato durante il bootstrap;
un follow-up creato da un task precedente accettato.

Il framework può rappresentare altre fonti quando il project manifest le identifica chiaramente.

È il progetto a decidere cosa è canonico

TCAF non dovrebbe creare un backlog concorrente quando il progetto dispone già di una fonte autorevole.

Esempi:

Se GitHub Issues è il backlog ufficiale, la documentazione di progetto dovrebbe farvi riferimento invece di creare silenziosamente una seconda lista.
Se un file backlog nel repository è autorevole, i tracker esterni possono restare contesto di supporto.
Se il developer formula una richiesta diretta e delimitata, non serve creare un elemento di backlog soltanto per soddisfare il framework.
Se un’analisi descrive un corpo di lavoro ampio, il Task Contract corrente deve comunque autorizzare una sola unità revisionabile.

Il project manifest registra dove si trovano le informazioni autorevoli sui task.

Preservare l’identità della fonte

Quando la fonte possiede un identificativo, conservalo nel contratto e nel risultato finale.

Esempi:

GitHub Issue: #42
Elemento backlog: B-016
Sezione analisi: Autenticazione / Recupero password
Richiesta diretta: istruzione del developer del 31-07-2026

Questo collegamento consente di risalire dall’implementazione alla sua origine senza copiare l’intera fonte in ogni documento.

La fonte non è automaticamente il contratto

Un elemento di backlog o una issue possono essere incompleti, obsoleti o troppo ampi per l’implementazione diretta. TCAF legge la fonte, ispeziona le evidenze di progetto pertinenti e crea un Task Contract che rende visibile l’interpretazione operativa.

Il contratto può chiarire:

comportamento esatto da implementare ora;
assunzioni sostenute dal repository;
decisioni non ancora risolte;
aree coinvolte e da preservare;
criteri di accettazione;
controlli;
esclusioni.

La fonte resta autorevole per l’intento, mentre il Task Contract approvato diventa autorevole per il confine implementativo corrente.

Fonti in conflitto

Quando le fonti si contraddicono, l’agente non deve scegliere silenziosamente.

Esempi:

una issue richiede un comportamento contrario alla documentazione canonica corrente;
un elemento di backlog descrive una feature già implementata in modo differente;
un’analisi presume un’API che il repository non contiene;
una richiesta diretta entra in conflitto con un vincolo architetturale accettato.

L’esito corretto consiste nell’esporre la contraddizione, identificare la decisione coinvolta e fermarsi in attesa dell’indicazione del developer. Il developer può correggere la fonte, sostituirla esplicitamente, emendare la documentazione di progetto o definire un task separato.

Attualità della fonte

Un file modificato di recente non è automaticamente l’autorità più aggiornata e un documento vecchio non è automaticamente obsoleto. L’attualità va determinata dal contenuto, dalle regole del progetto e dai ruoli canonici dichiarati.

Durante l’analisi pertinente verifica:

se la fonte descrive comportamento corrente o pianificato;
se il suo stato è aperto, completato, sostituito o storico;
se le evidenze del repository soddisfano già parte della richiesta;
se un altro documento è dichiarato canonico per la stessa decisione;
se il developer ha fornito un’istruzione successiva.

Non dedurre completamento o priorità soltanto dai nomi dei file.

Richieste dirette del developer

Una richiesta diretta è una fonte valida quando è già sufficientemente delimitata oppure può essere convertita in un contratto revisionabile.

Il framework non dovrebbe costringere il developer a creare artefatti amministrativi prima di ogni piccolo task. Il contratto deve comunque contenere informazioni sufficienti a evitare espansioni nascoste del perimetro.

Per una richiesta molto piccola, il riferimento alla fonte può restare compatto:

Fonte: richiesta diretta del developer
Obiettivo: correggere il messaggio di validazione per il campo email vuoto

Analisi e roadmap ampie

Un’analisi o una roadmap possono autorizzare la pianificazione, ma non autorizzano automaticamente l’implementazione di tutte le capability descritte.

L’agente dovrebbe separare:

stato corrente del progetto;
stato futuro desiderato;
decisioni confermate;
proposte;
domande aperte;
singola unità selezionata per l’implementazione corrente.

Questo impedisce che i documenti di pianificazione diventino un mandato illimitato.

Modifiche durante un task attivo

Una nuova istruzione ricevuta dopo l’approvazione deve essere classificata rispetto al contratto corrente.

Può essere:

un chiarimento;
una correzione di una non conformità al contratto;
un adattamento tecnico locale;
un emendamento;
un nuovo task separato;
un blocker o una contraddizione.

Il fatto che il developer l’abbia espressa nella stessa conversazione non la rende automaticamente parte del confine già approvato.

Cosa dovrebbe richiamare la risposta finale

Il risultato dovrebbe identificare la fonte quando ciò migliora la tracciabilità, soprattutto per backlog e issue. Dovrebbe inoltre distinguere:

intento della fonte;
contratto approvato;
implementazione effettiva;
evidenze di verifica;
lavoro restante della fonte non incluso nel task corrente.

Questo mantiene onesta la chiusura del task senza trasformare la fonte stessa in un log implementativo.