Passa al contenuto principale

Politica di Evoluzione: I Pilastri Immutabili

"I Tre Pilastri non evolvono. Proteggono le cose che evolvono."

La Politica di Evoluzione di Zenzic governa come il progetto cambia. Il suo primo principio è che non tutto può cambiare — e i Tre Pilastri sono le cose che non possono.

1. Il Contratto di Immutabilità​

I Tre Pilastri non sono preferenze. Sono i requisiti strutturali del Exclusion Zone. Un Zenzic senza il Pilastro II (Zero Sottoprocessi) non è un Zenzic più veloce — è uno strumento diverso che ha abbandonato il suo modello di fiducia.

Cosa Significa "Immutabile"​

PilastroPuò essere allentato?Conseguenza della violazione
I — Analizza la Sorgente, Non il Build❌ NoRompe la garanzia di analisi pre-build
II — Zero Sottoprocessi❌ NoRompe il modello di esecuzione Zero-Trust
III — Pure Functions First❌ NoRompe la riproducibilità e l'auditabilità

Una modifica che viola il Pilastro II o il Pilastro III — anche temporaneamente, anche per un motivo valido — richiede:

  1. Un incremento della versione Major
  2. Un ADR formale aggiunto all'ADR Vault
  3. Uno stress-test strutturale dell'architettura sostitutiva proposta

Questo garantisce che il modello di fiducia non venga abbandonato alla leggera o per errore.

2. Cosa Può Evolvere (Procedura Semplificata)​

Standard Operativi — soglie dei gate di qualità, floor di copertura, target di benchmark, messaggi dei codici di trovato (non la semantica) — evolvono semplicemente documentando la motivazione in un commit e aggiornando la sezione [POLICIES] o [ARCHITECTURE] del Ledger.

3. Template RFC (per Proposte a Livello di Pilastro)​

Qualsiasi proposta di modifica di un invariante dei Tre Pilastri deve includere:

  1. Testo Attuale: Il testo esatto dell'[INVARIANT] contestato.
  2. Testo Proposto: La formulazione sostitutiva, se presente.
  3. Motivazione: Perché il testo attuale è architetturalmente insufficiente o dannoso.
  4. Costo: Cosa si rompe? Quali utenti devono migrare? Quali ADR vengono invalidati?
  5. Analisi delle Alternative: Quali alternative sono state considerate?

Una proposta senza una sezione Costo e Analisi delle Alternative non entrerà in dibattito.

4. Il Divieto di "Comodità"​

"Non accettiamo scorciatoie per comodità."

I seguenti non sono motivazioni valide per una modifica ai Pilastri:

  • "È fastidioso scrivere pure functions per questa regola."
  • "Dobbiamo spedire questa chiamata a subprocess ora."
  • "L'AI ha proposto un'architettura più ridotta che bypassa il Pilastro II."
  • "Questa è un'eccezione temporanea."

5. Eccezioni per Sicurezza​

In caso di Vulnerabilità di Sicurezza Critica che richieda una deviazione di emergenza da un Pilastro, è possibile fare un'eccezione temporanea. Deve essere tracciata con un ADR dedicato che descriva la motivazione di sicurezza, e la violazione architetturale deve essere risolta non appena la vulnerabilità è mitigata. Questa eccezione non può essere invocata per comodità o per mascherare debito tecnico.