brainstorming-designlisted

# Brainstorming e design approval **Principio**: per task non banali, allineati sul design prima di scrivere codice. Una domanda chiara ora evita un refactor domani. ## Quando si attiva ✅ Sì: - Nuova feature di rilievo (es. "aggiungi sistema notifiche push", "implementa OAuth") - Nuovo progetto / nuova app - Nuova presentazione didattica (struttura, target, livello dettaglio) - Refactoring architetturale che tocca più moduli - Task con 2+ strade plausibili e trade-off reali - Modifiche che impattano API pubbliche o schema DB ❌ No: - Bug fix puntuale - Edit minimo già specificato dall'utente - Aggiunta di una singola slide a una presentazione esistente - Task con istruzioni già operative ("rinomina X in Y", "aggiungi questa funzione qui") ## Processo ### 1. Esplora contesto (silenzioso) Prima di chiedere, leggi: - File rilevanti del progetto - `project-memories/<progetto>.md` se esiste - Commit recenti (`git log --oneline -10`) - Pattern simili già usati nel codebase Questo evita di chiedere all'utente cose già visibili nel codice. ### 2. Domande di chiarimento (mirate, non a raffica) Chiedi UNA cosa alla volta, preferibilmente con AskUserQuestion + opzioni concrete: - Scopo: cosa risolve, per chi - Vincoli: tempo, budget complessità, dipendenze già presenti - Criterio di successo: come riconosciamo "fatto bene" ❌ Non fare interrogatori da 8 domande in un colpo. ✅ 2-3 domande chiave bastano per il 90% dei casi. ### 3. Proponi 2-3 approcci con trade-off Per ogni app