Vision · 2026-07-14
Minimum Complete Architecture: perché "MVP" non basta per un sistema operativo
Un MVP è una feature ridotta all'osso. Un kernel non aspetta che un utente lo chieda per fare scheduling dei processi. La differenza è il concetto che guida ogni decisione di cosa costruire prima degli utenti.
Il pensiero MVP classico dice: costruisci solo quello che un utente reale ha esplicitamente chiesto, nient'altro. È un principio corretto per una feature. È un principio pericoloso per un sistema operativo, perché alcune capacità non sono feature -- sono architettura, e un'architettura incompleta si comporta bene finché non viene messa sotto pressione, poi fallisce in modo silenzioso.
Un kernel non aspetta che un processo chieda "per favore fammi scheduling equo" -- lo scheduler esiste prima che qualunque processo giri. Git non aspetta che un utente chieda il branching -- è nel modello dati dal primo commit. Kubernetes non aspetta un guasto per decidere se avere self-healing -- lo ha, sempre, anche se non è mai stato usato in un dato cluster.
Questa distinzione ha guidato scelte concrete in questo sistema: continuità operativa (cosa succede se l'agente che sta eseguendo un task si ferma a metà), un registro degli agenti disponibili con lifecycle reale, un log di miglioramento continuo che collega problema ed evidenza a proposta. Nessuna di queste è mai stata "richiesta" da un utente -- sarebbe stato impossibile, perché nessun utente reale ha ancora usato il sistema abbastanza a lungo da scoprirne l'assenza. Ma la loro assenza sarebbe stata un bug architetturale scoperto nel modo peggiore: in produzione, con un founder reale nel mezzo.
La distinzione pratica che usiamo: se il gap verrebbe scoperto solo da un incidente reale (un agente che si blocca, un cambiamento silenzioso non tracciato), è Minimum Complete Architecture, si costruisce prima. Se il gap è "sarebbe bello avere anche X", è una feature, aspetta un segnale reale da un utente.