Usa GitHub Issues
Usa una GitHub Issue come fonte del task preservando proprietà, discussione e confini di accettazione.
Una GitHub Issue può essere una fonte autorevole del task quando il repository usa le Issues per descrivere lavoro, criteri di accettazione e discussione.
Passa l’issue al workflow
Usa l’adapter host connesso quando può leggere direttamente l’issue. Altrimenti esportane il contenuto in un file locale e passalo come input:
tcaf task --target <progetto> --input <export-issue>Il materiale fornito dovrebbe includere numero, titolo, descrizione, commenti pertinenti e collegamenti alle evidenze di progetto richiamate.
Tratta l’issue come fonte
L’issue non sostituisce l’ispezione pertinente del repository. Prima di produrre il Task Contract, l’agente deve verificare:
- se percorsi e comportamento descritti corrispondono ancora al repository corrente;
- se i commenti hanno modificato o chiarito la richiesta;
- se dipendenze o blocchi sono ancora aperti;
- se i criteri di accettazione sono sufficienti ad autorizzare l’implementazione;
- se l’issue contiene più task indipendenti da mantenere separati.
Preserva la storia dell’issue
Non riscrivere il significato dell’issue, non chiuderla, non cambiare label, assegnazioni o commenti senza autorizzazione esplicita.
Quando issue e repository sono in contraddizione, segnala il problema invece di scegliere silenziosamente una versione.
Completamento
Il successo dell’implementazione non chiude automaticamente l’issue. Dopo review e accettazione, riconcilia separatamente lo stato e aggiungi le evidenze o il riferimento al commit ritenuti appropriati dal team.
Push, pull request e aggiornamenti dell’issue restano operazioni GitHub separate.