Minimum Complete Architecture: perché "MVP" non basta per un sistema operativo

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.

Il rischio opposto è altrettanto reale, e va detto con la stessa onestà: chiamare "architettura fondamentale" qualunque cosa un ingegnere vuole costruire è come chiamare "sicurezza" qualunque burocrazia un'organizzazione vuole aggiungere -- l'etichetta giusta usata come scusa smette di essere un criterio e diventa una licenza per costruire senza disciplina. Il test che separa i due casi non è "sembra importante" -- è "il sistema si comporta in modo osservabilmente diverso, e peggio, se questo manca, indipendentemente da quale utente lo sta usando in quel momento". Uno scheduler di processi supera questo test: senza di lui, due processi che girano insieme si comportano diversamente a seconda di quale ha avuto la fortuna di partire per primo. Un tema grafico personalizzabile non lo supera: senza di lui, il sistema fa esattamente lo stesso lavoro, solo con un colore diverso.

Un esempio concreto emerso in questo stesso sistema, non ipotetico: la differenza tra un processo che rimane vivo con un heartbeat regolare e un processo che sta producendo lavoro reale. I due sembrano identici da fuori -- entrambi rispondono, entrambi sembrano "in esecuzione" -- ma solo un audit esplicito della differenza rivela quando il primo diventa un problema camuffato da normalità. Questo non è un gap che un utente avrebbe mai potuto segnalare, perché dal suo punto di vista il sistema sembrava funzionare; è esattamente il tipo di gap che la Minimum Complete Architecture esiste per anticipare prima che diventi un incidente in produzione.

Il prezzo di questo approccio è che alcune capacità vengono costruite prima che qualcuno le chieda esplicitamente, e quindi prima che ci sia una prova di domanda immediata. È un prezzo accettato consapevolmente: costruire uno scheduler dopo il primo deadlock costa molto più caro, in fiducia oltre che in ingegneria, che costruirlo prima che il primo deadlock sia mai potuto accadere.