> ## Documentation Index > Fetch the complete documentation index at: https://docs.myrmex.ai/llms.txt > Use this file to discover all available pages before exploring further. # Gestione delle Modifiche (GMUD) > Pianifica, approva ed esegui le modifiche al tuo ambiente attraverso un flusso governato — modifiche standard e patch di aggiornamento, ognuna con una traccia di audit completa. import { CardGroup, Card, Note, Tip, Warning, Steps, Step } from '@mintlify/components'; La **Gestione delle Modifiche** è il luogo in cui ogni modifica al tuo ambiente viene pianificata, revisionata, approvata ed eseguita sotto controllo. Ogni modifica è registrata come una **GMUD** (*Gestão de Mudança* — un record di modifica), e nulla che tocchi un sistema viene eseguito prima che le persone giuste abbiano approvato. È lo stesso principio del resto di Myrmex — **l'IA propone, tu approvi** — applicato al momento in cui una modifica atterra davvero. Una **GMUD** è una singola richiesta di modifica: cosa cambierà, perché, su quali sistemi, quando, come verrà annullata e chi ha firmato. Porta la modifica da una bozza fino a un'esecuzione completata e sottoposta ad audit. ## Due Tipi di Modifica La Gestione delle Modifiche gestisce due tipi di modifica, e la differenza sta principalmente in *come ciascuno viene eseguito*: Una modifica che tu (o l'IA) pianifichi — una modifica di configurazione, una variazione di regola di firewall, un'attività di manutenzione. Ha un **piano di implementazione** e un **piano di rollback**, e una volta approvata la avvii esplicitamente con **Execute**. Gli agenti eseguono poi i passaggi. Un rollout di patch di sistema operativo che nasce nell'area [Updates](/it/documentation/agent-endpoint-security/patch-management). L'IA pianifica le patch in sospeso in una **finestra di manutenzione**; una volta approvata, l'agente **le installa automaticamente in quella finestra** — nessun Execute manuale. Entrambi i tipi condividono lo stesso ciclo di vita, lo stesso gate di approvazione, la stessa finestra di modifica e la stessa traccia di audit. Differiscono solo al momento dell'esecuzione: una modifica standard viene attivata su richiesta, una patch gira all'interno della sua finestra pianificata. Il [flusso di approvazione](/it/documentation/change-management/approvals) copre entrambi. ## Il Ciclo di Vita di una Modifica Una GMUD attraversa un insieme fisso di stati. Il percorso ideale ha sei fasi; alcuni stati di eccezione chiudono una modifica che non si è conclusa normalmente. La modifica è in fase di stesura — identificazione, giustificazione, rischio, finestra e passaggi di implementazione/rollback. Completamente modificabile. Inviata per approvazione. Ora attende gli approvatori secondo la [regola di approvazione](/it/documentation/change-management/approvals#regole-di-approvazione) corrispondente. Sono state registrate abbastanza approvazioni. Una modifica standard è ora pronta per **Execute**; una patch è pronta per girare nella sua finestra. La modifica è in coda per la sua **finestra di modifica**. Mentre è pianificata, il record si aggiorna automaticamente ogni 60 secondi. Gli agenti stanno eseguendo i passaggi. Per una patch, i pacchetti si stanno installando sugli host di destinazione. Ogni passaggio è terminato con successo. La modifica è chiusa e completamente sottoposta ad audit. Al di fuori del percorso ideale, una modifica può anche terminare come: | Stato | Significato | | --------------------- | ----------------------------------------------------------------------------------------------------- | | **Rifiutata** | Un approvatore l'ha rifiutata durante il gate di approvazione — il flusso finisce. | | **Annullata** | Interrotta prima dell'esecuzione (consentito mentre è in bozza, sottoposta, approvata o pianificata). | | **Parziale** | L'esecuzione è terminata ma solo alcuni passaggi/elementi sono riusciti. | | **Fallita** | L'esecuzione non è riuscita. | | **Interrotta** | L'esecuzione è stata fermata in corso. | | **Rollback eseguito** | Il piano di rollback è stato applicato per annullare la modifica. | **Modificare una modifica dopo che è stata sottoposta la reimposta.** Modificare una modifica che è sottoposta, approvata o pianificata annulla qualsiasi esecuzione dispatchata e la riporta a **Bozza** — dovrà essere sottoposta e approvata di nuovo. È intenzionale: una modifica approvata è approvata *così com'è scritta*. ## Anatomia di una Modifica Ogni GMUD è un documento strutturato. Quando ne apri una, è organizzata nelle sezioni che un change-advisory board si aspetterebbe: Titolo, stato, **tipo di modifica**, **categoria** tecnica e **kind** (modifica standard o patch). Il problema o la motivazione, l'obiettivo e il risultato atteso, e cosa è esplicitamente **nell'ambito** e **fuori ambito**. Probabilità, impatto e il **livello di rischio finale**; servizi e utenti impattati, downtime atteso, rischi di sicurezza/compliance e dipendenze. I dispositivi e le integrazioni che la modifica tocca, ognuno collegato come **coinvolto** o **dipendente** — così il raggio d'azione è esplicito. Inizio e fine della finestra di manutenzione, più la comunicazione agli stakeholder. Il record mostra quando la finestra si apre e si chiude. I **passaggi** ordinati per effettuare la modifica e i passaggi per annullarla — vedi sotto. ### Passaggi di implementazione e rollback Il piano è un elenco di **passaggi** ordinati, ognuno etichettato **Implementazione** o **Rollback**. Un passaggio registra l'attività, il suo ordine, un responsabile, una durata attesa e — opzionalmente — un **target** (un dispositivo o un'integrazione specifica) e un'azione da eseguirvi. Durante l'esecuzione, ogni passaggio mostra il proprio stato, così puoi vedere esattamente fin dove è arrivata la modifica e cosa resta se qualcosa deve essere annullato. Un solido piano di rollback è ciò che rende una modifica sicura da approvare. Chiedi all'IA di redigerlo per te — *"aggiungi un piano di rollback che ripristini questa modifica alla regola del firewall."* ## Come Arrivarci Apri **Gestione delle Modifiche** dal **Directory** a sinistra della console. Elenca le tue modifiche per il [contesto](/it/documentation/get-started/concepts#how-your-account-is-organized) selezionato — modifiche standard e modifiche di patch sono mostrate con icone distinte — e ognuna si apre come una tab nel Workspace. Vederla richiede il permesso `gmuds.read`. Puoi anche portare una modifica dentro una conversazione: **`@`-menziona** una modifica (o una patch) come [entità di contesto](/it/documentation/multi-agent-system/overview) e chiedi all'IA a riguardo, o chiedile di redigerne o modificarne una. ## Dove Si Inserisce l'IA La Gestione delle Modifiche è profondamente legata agli agenti: * **Redazione** — chiedi a [Centurion](/it/documentation/multi-agent-system/agent-orchestrator) di preparare una modifica e riempirà l'identificazione, il rischio, la finestra e un primo piano di implementazione/rollback per la tua revisione. * **Proposte di patch** — l'IA revisiona gli aggiornamenti in sospeso e propone una modifica patch (una GMUD di tipo patch) con una finestra di manutenzione (vedi [Gestione di patch e aggiornamenti](/it/documentation/agent-endpoint-security/patch-management)). * **Esecuzione** — una volta approvata (e, per una modifica standard, cliccato **Execute**), gli agenti eseguono i passaggi, guidati dal Workspace. Per tutto il percorso, **tu tieni il gate**: nessuna modifica lascia la fase di approvazione senza una decisione umana, e ogni azione — umana, dell'agente o del sistema — è scritta nella cronologia della modifica. ## Traccia di Attività ed Esportazione Ogni GMUD porta una timeline di **Attività**: quando è stata creata e da chi, ogni approvazione o rifiuto (con la motivazione data), ogni passaggio mentre è stato eseguito, e l'ultimo aggiornamento. Risponde *"chi ha fatto cosa e quando?"* sul record stesso. Puoi anche **esportare la modifica in PDF** — per un change-advisory board o un auditor — direttamente dal record. ## Prossimo Come funziona submit → approve → execute, e come governare chi deve approvare cosa. Revisiona gli aggiornamenti OS in sospeso e approva le pianificazioni di patch proposte dall'IA.