Preservation-first
Integra le modifiche richieste nel software esistente senza riscritture opportunistiche o perdita di comportamento funzionante.
Preservation-first è la regola predefinita di TCAF quando si modifica software già esistente:
NEW BEHAVIOR = EXISTING VERIFIED BEHAVIOR + REQUESTED DELTA
L’AI deve comprendere ed estendere l’implementazione funzionante invece di sostituirla con la soluzione che avrebbe scelto lavorando in isolamento.
Riusa il vocabolario locale del progetto
Prima di modificare un’area implementata, cerca gli elementi esistenti che risolvono già problemi simili:
- funzioni, metodi e confini dei servizi;
- utility condivise e helper;
- validazioni, guard e controlli dei permessi;
- convenzioni di error handling e logging;
- pattern di stato, dependency injection e accesso ai dati;
- convenzioni di naming, tipizzazione e cartelle;
- test e comandi di verifica;
- interfacce pubbliche usate da altro codice.
Riusa o componi questi elementi quando sono adatti al task.
Non mescolare miglioramenti estranei al task
Una API più recente o un’architettura teoricamente più pulita può essere utile quando viene richiesta dal developer. Non costituisce un permesso automatico a sostituire un approccio locale funzionante.
Una normale feature o bug fix non autorizza rinominazioni, modernizzazioni, cambi di dipendenza, spostamenti di cartelle, sostituzioni di helper o refactoring estesi non correlati.
Preserva le modifiche del developer
Le modifiche manuali del developer sono stato corrente del repository. L’AI deve rileggere il file prima di modificarlo e integrarsi con ciò che esiste adesso.
Quando l’origine di una modifica è incerta, va preservata salvo autorizzazione esplicita del developer a un’azione distruttiva.
Preserva il comportamento, non il bug da correggere
Preservation-first non significa conservare il difetto che il task deve modificare. La baseline da preservare è il comportamento verificato e i vincoli fuori dal delta richiesto.
Minimo significa coerente, non meno righe
A volte un comportamento richiesto necessita modifiche coordinate su UI, servizio, API e test. Può comunque essere preservation-first.
La superficie corretta è la più piccola superficie coerente che soddisfa il Task Contract proteggendo il comportamento non correlato.
Il refactoring resta possibile
TCAF non vieta il refactoring. Rende esplicita la modifica più ampia. Un refactoring è appropriato quando è l’obiettivo del task, è necessario alla modifica approvata, viene approvato separatamente oppure viene accettato come amendment per risolvere un blocker.
Quando un progetto greenfield ha stabilito architettura e pattern funzionanti, i task successivi trattano quella baseline nello stesso modo.