Da GitHub Spark a .NET Aspire con un Copilot Agent: script deterministici + skills

GitHub Spark abbatte il tempo di prototipazione a zero: in pochi minuti si ha un'app React con storage KV, autenticazione e deploy su cloud, senza una riga di infrastruttura. Ma ogni POC di successo incontra prima o poi la stessa ripida parete: "ora la portiamo in produzione". Osservabilità, autenticazione enterprise, CI/CD, database relazionale, multi-tenancy, SLA. Tutto quello che Spark non dà, e che un sistema di produzione giustamente richiede. In questa sessione mostrerò come abbiamo costruito "spark-to-aspire": un Copilot Agent con 5 skill che guida lo sviluppatore attraverso lo switch completo da un progetto Spark verso un'architettura .NET 10 + Aspire 13 + React/Vite. Non una riscrittura manuale: un processo semi-automatizzato dove l'AI conosce la differenza tra cosa può fare deterministicamente (uno script shell è più affidabile di un LLM per npm uninstall) e cosa richiede ragionamento semantico (riscrivere useKV in hook React Query che parlano con la nuova API REST). La sessione esplora il pattern architetturale alla base dell'agent: Fase 1 – Audit: grep deterministico dei pattern Spark, stima del lavoro Fase 2 – Scaffold: CLI dotnet/aspire + template con placeholder; zero "allucinazioni" sulla struttura del progetto Fase 3 – Strip: rimozione dipendenze via npm, riscrittura semantica useKV → React Query Fase 4 – Restructure: file system + aggiornamento riferimenti cross-progetto Fase 5 – Validate: build .NET, build Vite, grep residui Spark — exit code come contratto. C'è un beneficio di Aspire, inoltre, che raramente viene citato nei talk tecnici, ma che chi usa Copilot ogni giorno percepisce immediatamente. In un progetto .NET Aspire, tutta l'architettura di sistema è dichiarata in un singolo file: l'AppHost. Servizi, database, frontend, variabili di ambiente, dipendenze tra componenti — tutto è lì, leggibile, tipizzato, senza ambiguità. Questo non è solo ergonomia per lo sviluppatore. È contesto esplicito, strutturato e compatto che un LLM può consumare in pochi token per capire come funziona l'intera applicazione. Niente più "ma il frontend parla direttamente con il DB o passa dall'API?" — la risposta è nel file.