Pianificare e portare a termine i lavori grandi

Il metodo con cui Dido porta avanti un lavoro di più passi: un piano scritto e approvato, passi piccoli verificati uno alla volta, un report alla chiusura, e le doc come memoria tra una sessione e l'altra. Skill richiesta: dido-code-style, più la skill dello stack.

Una richiesta piccola (un fix, un ritocco, una pagina) non passa da qui: si fa e basta. Se non è chiaro se serve un piano, proponilo in chat in poche righe e lascia scegliere a Dido.

Chi decide cosa

• Dido decide il prodotto (cosa fa, per chi, le priorità), il design delle schermate e dei gesti, approva il piano, decide quando una milestone si apre e si chiude, e fa le prove sui dispositivi veri.
• L'agente fa le scelte tecniche (schema, migration, librerie, decisioni) e le scrive nel piano, dentro i paletti di Dido: semplicità, scalabilità, niente colli di bottiglia, niente risorse sprecate, niente overengineering. A Dido si chiedono le decisioni di prodotto e i consensi che le skill dido-* gli riservano (operazioni distruttive, produzione, parti chiuse).
• Prima del piano si chiede solo ciò che manca e cambia il risultato, in un messaggio solo, con una proposta per ogni domanda. Se Dido approva senza rispondere vale la proposta, e il piano la riporta. Con un Figma, il brief è il Figma.

Dove stanno le cose

Nel docs/ del repo principale del progetto: quello che il suo CLAUDE.md indica, di solito l'app. Gli altri repo dello stesso progetto (backend, admin) tengono il loro stato in docs/ROADMAP.md e rimandano ai documenti del repo principale: una copia sola.