Onboarding di un servizio legacy

Una procedura illustrativa della prima cosa che fa la maggior parte dei team: prendere un repository esistente e poco documentato e renderlo pilotabile dagli agenti — senza disturbare ciò che già funziona.

01 Analizzare
02 Ragionare
03 Integrare
04 Verificare

riconciliare, mai sovrascrivere

L'onboarding del codice legacy ragiona sulla codebase reale e riconcilia invece di sovrascrivere — poi verifica la conformità.

L’obiettivo

«Rendi AI-first questo servizio di cinque anni.» Ha già un README parziale, alcuni docs sparsi e nessun AGENTS.md.

L’esecuzione

Lo sviluppatore consegna al proprio agente una sola riga — leggi e segui /init.md — e il flusso di onboarding:

Ricognizione. Rileva il linguaggio reale, il package manager (dal lockfile esistente) e i comandi reali di build, test e lint — leggendo il repo, non assumendo.
Propone un piano e chiede. Poiché esistono già degli artefatti, è non distruttivo: elenca cosa creerà rispetto a cosa riconcilierà e attende l’approvazione prima di toccare il README parziale o i docs sparsi.
Genera la harness. Un AGENTS.md ragionato con i Quick Commands reali del servizio, un albero docs/ categorizzato che assorbe le note esistenti anziché duplicarle, README per modulo, il kit .agents/ e una .dwp/ esclusa da git.
Verifica. /dwp-verify restituisce un report oggettivo di esito positivo/negativo rispetto ai criteri di conformità.

Risultato

Il servizio legacy diventa AI-first senza distruggere nulla: il lavoro esistente viene unito, non sovrascritto, e il risultato è verificabile anziché dichiarato. Da qui il team pianifica ed esegue lavoro reale con /dwp-create e /dwp-execute.