---
name: feedback-elimina-non-tenere-per-dubbio
description: Mauro preferisce eliminazione netta a conservazione precauzionale quando si smantella qualcosa — non tenere "nel dubbio"
type: feedback
---

Quando si decide di smantellare un sistema, Mauro spinge per la cancellazione completa — non tenere file/schema/codice "perché non si sa mai, magari in futuro serve".

**Why:** Durante lo smantellamento di vault-mcp/Elon (29/07/2026) Adrian ha proposto tre volte di conservare qualcosa per un'eventuale riattivazione futura — `server.py` (479 righe, "non banale da ricostruire"), poi lo schema SQL estratto in un file di testo quando anche il `.db` è stato messo in discussione. Mauro ha respinto ogni volta con lo stesso argomento: una futura riattivazione avrebbe comunque caratteristiche completamente diverse, quindi conservare l'implementazione attuale "nel dubbio" non produce valore reale, solo inerzia. Ha dovuto chiederlo esplicitamente più di una volta prima che Adrian arrivasse alla stessa conclusione da solo. Coerente con la decisione sull'UPS in [[project_fragilita_nave]]: Mauro accetta rischi residui consapevolmente invece di accumulare mitigazioni precauzionali.

**How to apply:** Quando si smantella un servizio/sistema su richiesta di Mauro, di default proporre la cancellazione completa (codice, config, schema) invece di un compromesso "spengo ma tengo il codice per dopo". Se c'è un argomento reale per conservare qualcosa (costo di ricostruzione genuinamente alto **e** scenario di riattivazione concreto, non ipotetico), va dichiarato esplicitamente come tale — non dato per scontato come prudenza automatica.