> ## 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. # Fluxo e Regras de Aprovação > Como uma mudança vai de submetida a aprovada e a executada — tanto para mudanças comuns quanto para patches de atualização — e como governar quem deve aprovar o quê. import { CardGroup, Card, Note, Tip, Warning, Steps, Step } from '@mintlify/components'; A aprovação é o coração da Gestão de Mudanças. Qualquer coisa que vá alterar um sistema passa por um **gate humano** antes de ser executada — seja uma mudança comum redigida à mão ou um lote de patches de sistema operacional. Esta página cobre esse gate de ponta a ponta e como governá-lo com **regras de aprovação**. ## O Gate, Passo a Passo O autor termina o rascunho e **submete**. A mudança vai para *Submetida* e a [regra de aprovação](#regras-de-aprovacao) correspondente determina quem deve aprovar e quantas aprovações são necessárias. Os aprovadores abrem a mudança, revisam a justificativa, o risco, a janela e o plano, e **Aprovam** ou **Recusam**. O painel de **Aprovações** acompanha o progresso ao vivo — por exemplo *2 de 3* — e mostra qual regra está em vigor. Uma vez alcançado o número exigido de aprovações, a mudança se torna *Aprovada* e está pronta para rodar. Uma **mudança comum** é iniciada explicitamente com **Execute** (Aprovada → Em execução), e os agentes rodam os passos. Um **patch de atualização** não precisa de gatilho manual — ele **instala automaticamente dentro da sua janela de manutenção agendada**. A mudança termina como *Concluída* (ou *Parcial* / *Falhou*), e toda a trilha de decisões é registrada no seu histórico. ### Aprovando e recusando * **Aprovar** registra sua decisão sob o seu usuário. Quando a mudança atinge o número exigido de aprovações, ela avança automaticamente. * **Recusar** encerra o fluxo de aprovação — a mudança vai para *Recusada*. Você pode anexar um **motivo** para que o autor saiba o que corrigir; ele pode então editar a mudança (o que a devolve para *Rascunho*) e submeter novamente. Toda aprovação e recusa é atribuída ao usuário que a fez, com um timestamp, e aparece no histórico de **Atividade** da mudança — para que o registro responda "quem aprovou isso, e quando?" por si só. ## Os Dois Caminhos de Execução O gate de aprovação é idêntico para os dois tipos de mudança; só o que acontece *depois da aprovação* difere. Após a aprovação, uma pessoa clica em **Execute** para iniciar a mudança. Isso mantém um humano no controle de *quando* o trabalho começa, mesmo depois da aprovação. Os agentes então rodam os passos de implementação a partir do Workspace, e o plano de rollback fica disponível se for necessário. Aprovar um grupo de patches **autoriza o agente a instalá-lo na próxima janela de manutenção**. Não há Execute manual — a implantação começa quando a janela abre e progride item por item. A aprovação fica registrada sob o seu usuário. Para patches, aprovar é o compromisso. A confirmação é explícita: *"Isso autoriza o agente a instalar as atualizações deste grupo na próxima janela de manutenção."* Até lá, a visão de patches pendentes é somente leitura e não instala nada. ## Regras de Aprovação Por padrão, uma mudança precisa de **uma aprovação, e o solicitante pode aprovar a própria mudança**. Isso funciona para um time pequeno, mas a maioria das organizações quer uma governança mais forte. **Regras de aprovação** permitem definir, por [contexto](/pt/documentation/get-started/concepts#how-your-account-is-organized), exatamente quem deve aprovar quais mudanças — uma política avaliada automaticamente sempre que uma mudança é submetida. Uma regra é composta por: | Configuração | O que faz | | ------------------------ | ---------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | | **Nome** | Um rótulo para a regra. | | **Tipo de mudança** | A quais mudanças a regra se aplica — **standard**, **normal** ou **emergency**. Deixe vazio para aplicar a **todas as mudanças**. | | **Mínimo de aprovações** | Quantas aprovações são exigidas antes que a mudança possa avançar. | | **Aprovadores nomeados** | Uma lista explícita de usuários que podem aprovar — apenas eles contam para o mínimo. Vazio significa **qualquer aprovador**: qualquer pessoa autorizada a aprovar nesse contexto. | | **Ativa** | Uma regra pode ser ligada ou desligada sem ser excluída. | Quando uma mudança é submetida, o Myrmex encontra a regra correspondente (pelo tipo da mudança, preferindo uma regra nomeada para aquele tipo em vez de uma abrangente) e a aplica. O painel de **Aprovações** então mostra a regra em vigor e o progresso rumo ao seu mínimo — por exemplo, *mín. 2*. Regras são uma camada de política, não um gargalo: se nenhuma regra corresponde a uma mudança, o **padrão** se aplica — 1 aprovação, e o solicitante pode aprovar. Remover uma regra simplesmente devolve suas mudanças a esse padrão. ### Gerenciando regras Abra a visão de **Regras de aprovação** a partir da Gestão de Mudanças para criar, editar, ativar/desativar ou excluir regras. Gerenciar regras é uma ação de governança, separada de aprovar mudanças individuais — é gated pela permissão `gmuds.admin`. Excluir uma regra não bloqueia nada — mudanças no seu escopo voltam à política padrão (1 aprovação, o solicitante pode aprovar). Se você precisar de controle mais rígido, desative uma regra em vez de deixar uma lacuna, ou substitua-a antes de removê-la. ## Quem Pode Fazer o Quê A Gestão de Mudanças é governada por um conjunto dedicado de permissões, para que você possa separar quem *escreve* as mudanças, quem as *aprova* e quem *governa as regras*: | Permissão | Concede | | --------------- | ------------------------------------------------------------ | | `gmuds.read` | Visualizar mudanças, seus passos e as regras de aprovação. | | `gmuds.create` | Criar novas solicitações de mudança. | | `gmuds.update` | Editar mudanças, submeter para aprovação e gerenciar passos. | | `gmuds.approve` | **Aprovar ou recusar** mudanças submetidas. | | `gmuds.delete` | Excluir mudanças. | | `gmuds.admin` | **Administrar as regras de aprovação** (governança). | Conceda `gmuds.create` / `gmuds.update` aos engenheiros que planejam mudanças, reserve `gmuds.approve` para donos de mudança ou um comitê, e mantenha `gmuds.admin` com o time de governança. Combinado com **aprovadores nomeados** em uma regra, isso lhe dá segregação de funções limpa. Veja [Controle de acesso](/pt/documentation/management/access-control). ## Relacionado O módulo, os dois tipos de mudança e o ciclo de vida completo. Consulte as atualizações pendentes e aprove os cronogramas de patch que a IA propõe.