> ## 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. # Flujo y reglas de aprobación > Cómo un cambio pasa de enviado a aprobado y a ejecutado — tanto para cambios estándar como para parches de actualización — y cómo gobernar quién debe aprobar qué. import { CardGroup, Card, Note, Tip, Warning, Steps, Step } from '@mintlify/components'; La aprobación es el corazón de la Gestión de Cambios. Todo lo que vaya a alterar un sistema pasa por una **puerta humana** antes de ejecutarse — ya sea un cambio estándar escrito a mano o un lote de parches del sistema operativo. Esta página cubre esa puerta de principio a fin y cómo gobernarla con **reglas de aprobación**. ## La puerta, paso a paso El autor termina el borrador y lo envía con **Submit**. El cambio pasa a *Enviado* y la [regla de aprobación](#approval-rules) correspondiente determina quién debe dar el visto bueno y cuántas aprobaciones se necesitan. Los aprobadores abren el cambio, revisan la justificación, el riesgo, la ventana y el plan, y eligen **Approve** o **Reject**. El panel de **Aprobaciones** rastrea el progreso en vivo — por ejemplo *2 de 3* — y muestra qué regla está en vigor. Una vez alcanzado el número requerido de aprobaciones, el cambio pasa a *Aprobado* y está listo para ejecutarse. Un **cambio estándar** se inicia explícitamente con **Execute** (Aprobado → Ejecutando), y los agentes ejecutan los pasos. Un **parche de actualización** no necesita disparo manual — se **instala automáticamente dentro de su ventana de mantenimiento programada**. El cambio finaliza como *Completado* (o *Parcial* / *Fallido*), y toda la traza de decisiones queda registrada en su historial. ### Aprobar y rechazar * **Approve** registra tu decisión a nombre de tu usuario. Cuando el cambio alcanza el número requerido de aprobaciones, avanza automáticamente. * **Reject** finaliza el flujo de aprobación — el cambio pasa a *Rechazado*. Puedes adjuntar un **motivo** para que el autor sepa qué corregir; luego puede editar el cambio (lo que lo devuelve a *Borrador*) y volver a enviarlo. Cada aprobación y rechazo se atribuye al usuario que la realizó, con una marca de tiempo, y aparece en el historial de **Actividad** del cambio — de modo que el registro responde por sí solo "¿quién aprobó esto, y cuándo?". ## Los dos caminos de ejecución La puerta de aprobación es idéntica para ambos tipos de cambio; solo difiere lo que sucede *después de la aprobación*. Tras la aprobación, una persona hace clic en **Execute** para iniciar el cambio. Esto mantiene a un humano en control de *cuándo* comienza el trabajo, incluso después del visto bueno. Los agentes entonces ejecutan los pasos de implementación desde el Workspace, y el plan de reversión está a mano por si se necesita. Aprobar un grupo de parches **autoriza al agente a instalarlo en la próxima ventana de mantenimiento**. No hay **Execute** manual — el despliegue comienza cuando se abre la ventana y avanza elemento por elemento. La aprobación queda registrada a nombre de tu usuario. Para los parches, aprobar es el compromiso. La confirmación es explícita: *"Esto autoriza al agente a instalar las actualizaciones de este grupo en la próxima ventana de mantenimiento."* Hasta entonces, la vista de parches pendientes es de solo lectura y no instala nada. ## Reglas de aprobación Por defecto, un cambio necesita **una aprobación, y el solicitante puede aprobar su propio cambio**. Eso está bien para un equipo pequeño, pero la mayoría de las organizaciones quieren una gobernanza más fuerte. Las **reglas de aprobación** te permiten definir, por [contexto](/es/documentation/get-started/concepts#how-your-account-is-organized), exactamente quién debe aprobar qué cambios — una política que se evalúa automáticamente cada vez que se envía un cambio. Una regla se compone de: | Ajuste | Qué hace | | ------------------------- | --------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | | **Nombre** | Una etiqueta para la regla. | | **Tipo de cambio** | A qué cambios se aplica la regla — **estándar**, **normal** o **emergencia**. Déjalo vacío para aplicar a **todos los cambios**. | | **Aprobaciones mínimas** | Cuántas aprobaciones se requieren antes de que el cambio pueda avanzar. | | **Aprobadores nombrados** | Una lista explícita de usuarios que pueden aprobar — solo ellos cuentan para el mínimo. Vacío significa **cualquier aprobador**: cualquiera autorizado a aprobar en ese contexto. | | **Activo** | Una regla se puede activar o desactivar sin eliminarla. | Cuando se envía un cambio, Myrmex encuentra la regla correspondiente (por el tipo del cambio, prefiriendo una regla nombrada para ese tipo sobre una general) y la aplica. El panel de **Aprobaciones** muestra entonces la regla en vigor y el progreso hacia su mínimo — por ejemplo, *mín. 2*. Las reglas son una capa de política, no un cuello de botella: si ninguna regla coincide con un cambio, se aplica el **valor por defecto** — 1 aprobación, y el solicitante puede aprobar. Eliminar una regla simplemente hace que sus cambios vuelvan a ese valor por defecto. ### Gestionar las reglas Abre la vista de **Reglas de aprobación** desde la Gestión de Cambios para crear, editar, activar/desactivar o eliminar reglas. Gestionar las reglas es una acción de gobernanza, separada de aprobar cambios individuales — está protegida por el permiso `gmuds.admin`. Eliminar una regla no bloquea nada — los cambios en su alcance vuelven a la política por defecto (1 aprobación, el solicitante puede aprobar). Si necesitas un control más estricto, desactiva una regla en lugar de dejar un vacío, o reemplázala antes de eliminarla. ## Quién puede hacer qué La Gestión de Cambios se rige por un conjunto dedicado de permisos, para que puedas separar a las personas que *redactan* los cambios de las que los *aprueban* y las que *gobiernan las reglas*: | Permiso | Otorga | | --------------- | --------------------------------------------------------- | | `gmuds.read` | Ver cambios, sus pasos y las reglas de aprobación. | | `gmuds.create` | Crear nuevas solicitudes de cambio. | | `gmuds.update` | Editar cambios, enviar para aprobación y gestionar pasos. | | `gmuds.approve` | **Aprobar o rechazar** cambios enviados. | | `gmuds.delete` | Eliminar cambios. | | `gmuds.admin` | **Administrar las reglas de aprobación** (gobernanza). | Otorga `gmuds.create` / `gmuds.update` a los ingenieros que planifican los cambios, reserva `gmuds.approve` para los responsables del cambio o un comité asesor de cambios, y mantén `gmuds.admin` con tu equipo de gobernanza. Junto con los **aprobadores nombrados** en una regla, esto te da una separación de funciones limpia. Consulta [Control de acceso](/es/documentation/management/access-control). ## Relacionado El módulo, los dos tipos de cambio y el ciclo de vida completo. Consulta las actualizaciones pendientes y aprueba los cronogramas de parches que propone la IA.