> ## 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.

# Gestão de Mudanças (GMUD)

> Planeje, aprove e execute mudanças no seu ambiente por meio de um fluxo governado — mudanças comuns e patches de atualização, cada um com uma trilha de auditoria completa.

import { CardGroup, Card, Note, Tip, Warning, Steps, Step } from '@mintlify/components';

**Gestão de Mudanças** é onde toda mudança no seu ambiente é planejada, revisada, aprovada e executada sob controle. Cada mudança é registrada como uma **GMUD** (*Gestão de Mudança*), e nada que altere um sistema é executado antes que as pessoas certas tenham aprovado. É o mesmo princípio do restante do Myrmex — **a IA propõe, você aprova** — aplicado ao momento em que uma mudança realmente acontece.

<Note>
  Uma **GMUD** é uma única solicitação de mudança: o que será alterado, por quê, em
  quais sistemas, quando, como será revertida e quem aprovou. Ela carrega a mudança
  do rascunho até a execução concluída e auditada.
</Note>

## Dois Tipos de Mudança

A Gestão de Mudanças lida com dois tipos de mudança, e a diferença está principalmente em *como cada um é executado*:

<CardGroup cols={2}>
  <Card title="Mudança comum" icon="clipboard-check">
    Uma mudança que você (ou a IA) planeja — uma edição de configuração, uma
    alteração de regra de firewall, uma tarefa de manutenção. Ela tem um **plano
    de implementação** e um **plano de rollback**, e uma vez aprovada você a
    inicia explicitamente com **Execute**. Os agentes então executam os passos.
  </Card>

  <Card title="Patch de atualização" icon="download">
    Uma implantação de patch de sistema operacional que se origina na área de
    [Updates](/pt/documentation/agent-endpoint-security/patch-management). A IA agenda
    os patches pendentes em uma **janela de manutenção**; uma vez aprovada, o
    agente **instala automaticamente na janela** — sem Execute manual.
  </Card>
</CardGroup>

Ambos os tipos compartilham o mesmo ciclo de vida, o mesmo gate de aprovação, a mesma janela de mudança e a mesma trilha de auditoria. Diferem apenas no momento da execução: uma mudança comum é disparada sob demanda, um patch roda dentro da sua janela agendada. O [fluxo de aprovação](/pt/documentation/change-management/approvals) cobre ambos.

## O Ciclo de Vida de uma Mudança

Uma GMUD percorre um conjunto fixo de estados. O caminho feliz tem seis etapas; alguns estados de exceção encerram uma mudança que não terminou normalmente.

<Steps>
  <Step title="Rascunho">
    A mudança está sendo redigida — identificação, justificativa, risco, janela e
    passos de implementação/rollback. Totalmente editável.
  </Step>

  <Step title="Submetida">
    Enviada para aprovação. Agora aguarda os aprovadores conforme a
    [regra de aprovação](/pt/documentation/change-management/approvals#regras-de-aprovacao) correspondente.
  </Step>

  <Step title="Aprovada">
    Aprovações suficientes foram registradas. Uma mudança comum está pronta para
    **Execute**; um patch está pronto para rodar na sua janela.
  </Step>

  <Step title="Agendada">
    A mudança está na fila para sua **janela de mudança**. Enquanto agendada, o
    registro se atualiza automaticamente a cada 60 segundos.
  </Step>

  <Step title="Em execução">
    Os agentes estão rodando os passos. Para um patch, os pacotes estão sendo
    instalados nos hosts alvo.
  </Step>

  <Step title="Concluída">
    Todos os passos foram concluídos com sucesso. A mudança é encerrada e
    totalmente auditada.
  </Step>
</Steps>

Fora do caminho feliz, uma mudança também pode terminar como:

| Estado        | Significado                                                                           |
| ------------- | ------------------------------------------------------------------------------------- |
| **Recusada**  | Um aprovador negou durante o gate de aprovação — o fluxo se encerra.                  |
| **Cancelada** | Encerrada antes da execução (permitido em rascunho, submetida, aprovada ou agendada). |
| **Parcial**   | A execução terminou mas apenas alguns passos/itens foram bem-sucedidos.               |
| **Falhou**    | A execução não foi bem-sucedida.                                                      |
| **Abortada**  | A execução foi interrompida em andamento.                                             |
| **Revertida** | O plano de rollback foi aplicado para desfazer a mudança.                             |

<Warning>
  **Editar uma mudança após ela ser submetida a reinicia.** Editar uma mudança
  submetida, aprovada ou agendada cancela qualquer execução despachada e a
  devolve para **Rascunho** — ela precisa ser submetida e aprovada novamente. Isso
  é intencional: uma mudança aprovada é aprovada *como foi escrita*.
</Warning>

## Anatomia de uma Mudança

Toda GMUD é um documento estruturado. Ao abrir uma, ela é organizada nas seções que um comitê de aprovação de mudanças esperaria:

<CardGroup cols={2}>
  <Card title="Identificação da Mudança" icon="tag">
    Título, status, **tipo de mudança**, **categoria** técnica e **kind** (mudança
    comum ou patch).
  </Card>

  <Card title="Contexto e Justificativa" icon="circle-info">
    O problema ou motivação, o objetivo e o resultado esperado, e o que está
    explicitamente **dentro do escopo** e **fora do escopo**.
  </Card>

  <Card title="Avaliação de Risco e Impacto" icon="triangle-exclamation">
    Probabilidade, impacto e o **nível de risco final**; serviços e usuários
    impactados, indisponibilidade esperada, riscos de segurança/compliance e
    dependências.
  </Card>

  <Card title="Sistemas afetados (CIs)" icon="server">
    Os dispositivos e integrações que a mudança toca, cada um vinculado como
    **afetado** ou **dependente** — assim o raio de impacto fica explícito.
  </Card>

  <Card title="Janela de Mudança" icon="calendar-days">
    Início e fim da janela de manutenção, mais comunicação aos stakeholders. O
    registro mostra quando a janela abre e fecha.
  </Card>

  <Card title="Planos de Implementação e Rollback" icon="list-ol">
    Os **passos** ordenados para fazer a mudança e os passos para desfazê-la — veja
    abaixo.
  </Card>
</CardGroup>

### Passos de implementação e rollback

O plano é uma lista de **passos** ordenados, cada um marcado como **Implementação** ou **Rollback**. Um passo registra a atividade, sua ordem, um responsável, uma duração esperada e — opcionalmente — um **alvo** (um dispositivo ou integração específica) e uma ação a ser executada nele. Durante a execução, cada passo mostra seu próprio status, para você ver exatamente até onde a mudança chegou e o que resta caso algo precise ser desfeito.

<Tip>
  Um plano de rollback sólido é o que torna uma mudança segura de aprovar. Peça à
  IA para preparar um para você — *"adicione um plano de rollback que reverta esta
  alteração de regra de firewall."*
</Tip>

## Como Chegar Lá

Abra **Gestão de Mudanças** no **Directory** à esquerda do console. Ela lista suas mudanças para o [contexto](/pt/documentation/get-started/concepts#how-your-account-is-organized) que você tem selecionado — mudanças comuns e mudanças de patch são mostradas com ícones distintos — e cada uma abre como uma aba no Workspace. Visualizá-la exige a permissão `gmuds.read`.

Você também pode trazer uma mudança para dentro de uma conversa: **`@`-mencione** uma mudança (ou um patch) como uma [entidade de contexto](/pt/documentation/multi-agent-system/overview) e peça à IA sobre ela, ou peça para redigir ou ajustar uma.

## Onde a IA se Encaixa

A Gestão de Mudanças é profundamente ligada aos agentes:

* **Redação** — peça ao [Centurion](/pt/documentation/multi-agent-system/agent-orchestrator) para preparar uma mudança e ele preenche a identificação, o risco, a janela e um primeiro plano de implementação/rollback para você revisar.
* **Propondo patches** — a IA revisa as atualizações pendentes e propõe uma mudança de patch (uma GMUD do tipo patch) com uma janela de manutenção (veja [Gerenciamento de Patches e Atualizações](/pt/documentation/agent-endpoint-security/patch-management)).
* **Execução** — uma vez que você aprova (e, para uma mudança comum, clica em **Execute**), os agentes executam os passos, conduzidos a partir do Workspace.

Em todo o percurso, **você mantém o gate**: nenhuma mudança sai do estágio de aprovação sem uma decisão humana, e cada ação — humana, do agente ou do sistema — é gravada no histórico da mudança.

## Trilha de Atividade e Exportação

Toda GMUD carrega uma linha do tempo de **Atividade**: quando foi criada e por quem, cada aprovação ou recusa (com o motivo dado), cada passo conforme foi executado e a última atualização. Ela responde *"quem fez o quê, e quando?"* no próprio registro. Você também pode **exportar a mudança em PDF** — para um comitê de aprovação de mudanças ou um auditor — direto do registro.

## Próximo

<CardGroup cols={2}>
  <Card title="Fluxo e regras de aprovação" icon="user-check" href="/pt/documentation/change-management/approvals">
    Como submit → approve → execute funciona, e como governar quem deve aprovar o quê.
  </Card>

  <Card title="Gerenciamento de Patches e Atualizações" icon="download" href="/pt/documentation/agent-endpoint-security/patch-management">
    Revise as atualizações do SO pendentes e aprove os cronogramas de patch que a IA propõe.
  </Card>
</CardGroup>