Saltar al contenido principal
El Policy Engine define la política de revisión predeterminada para el workspace. Controla qué tipos de revisión están activos, qué instrucciones adicionales deben orientar el análisis y qué autores deben incluirse o bloquearse. Usa Consola > Policy Engine para configurar el valor predeterminado del workspace. Usa la configuración del repositorio solo para excepciones.

Quién puede acceder

El Policy Engine requiere un admin de workspace (los admins de plataforma también tienen acceso). Los roles son conjuntos de capacidades fijos definidos por Acrity, por lo que este acceso no es configurable por organización.

Cuándo usar

Usa esta pantalla para:
  • activar o desactivar tiers de revisión en el workspace;
  • agregar instrucciones generales de revisión;
  • definir bots que pueden ser revisados;
  • bloquear autores que no deben generar revisión;
  • consultar o rotar la configuración de webhook cuando la pantalla muestre esa opción;
  • alinear la política predeterminada antes de conectar muchos repositorios.

Tiers de revisión

TierUso típico
FastRevisión más directa para cambios comunes, con foco en respuesta rápida.
DeepRevisión más completa para cambios que requieren un análisis más cuidadoso.
El workspace debe mantener al menos un tier activo. Si ambos están activos, Acrity puede aplicar la política configurada según el contexto de la revisión y las opciones del producto.
No uses tiers como sustituto de reglas de branch. Las branch rules deben quedar en Consola > Repositorios.

Instrucciones adicionales

Las instrucciones adicionales permiten adaptar la revisión a los estándares de la organización. Úsalas para registrar directrices como:
  • patrones de arquitectura esperados;
  • criterios de calidad relevantes para la organización;
  • cuidados con pruebas, seguridad o compatibilidad;
  • lenguaje esperado en los comentarios;
  • decisiones de producto que deben considerarse.
Evita incluir:
  • secretos;
  • tokens;
  • información confidencial de clientes;
  • reglas internas que no deberían aparecer en las salidas de revisión;
  • instrucciones demasiado específicas para un único repositorio.
Para reglas específicas de un repositorio, usa Consola > Repositorios > Detalle > Revisión.

Overrides de prompt de revisores

Cada rol de revisor tiene su propio campo de override de prompt, para que puedas ajustar con precisión cómo un revisor específico analiza los cambios en todo el workspace.
RevisorOrienta
ArchitectEstructura, diseño y cómo un cambio encaja en el sistema en general.
Spec ValidatorAlineación entre el cambio y los requisitos declarados.
QA EngineerCobertura de pruebas, casos límite y calidad general.
Cada campo:
  • acepta hasta 2.000 caracteres;
  • muestra si el texto actual es un override del workspace o el predeterminado global;
  • ofrece una acción Revertir al global que descarta el override del workspace y restaura el predeterminado global.
Cuando un campo muestra el predeterminado global, ese revisor usa la guía integrada de Acrity. Cuando guardas texto en un campo, se convierte en un override del workspace que aplica a las revisiones en todo el workspace, reemplazando el predeterminado global para ese revisor.
Usa los overrides de prompt de revisor con precaución. Cambian el comportamiento del revisor en todo el workspace, y es fácil olvidar que hay un override activo. Para una guía duradera y de larga vida, es preferible confirmar un archivo ARCHITECTURE.md en el repositorio para que la guía viva junto al código y quede versionada junto a él.

Política de autores

La política de autores ayuda a controlar qué cambios deben revisarse.
CampoPara qué sirve
Bots permitidosIdentifica cuentas automatizadas cuyos PRs/MRs pueden revisarse.
Autores bloqueadosImpide revisiones para autores específicos.
Usa bots permitidos cuando las automatizaciones crean cambios que deben recibir revisión, como actualizaciones de dependencias. Usa autores bloqueados para reducir el ruido operacional o excluir cuentas que no deben generar análisis.

Clave o URL de webhook

Algunos workspaces pueden mostrar la configuración de webhook vinculada al flujo de revisión. Cuando la pantalla muestre esta opción:
  • copia la URL solo al proveedor correcto;
  • trata la clave como un secreto;
  • rota la clave si se sospecha una exposición;
  • actualiza el proveedor después de rotar;
  • valida el webhook desde la Consola o el proveedor.
No compartas claves de webhook en chats, tickets públicos, comentarios de PR/MR ni documentación interna amplia.

Configurar política predeterminada

1

Abrir Policy Engine

Ve a Consola > Policy Engine.
2

Revisar tiers

Activa Fast, Deep o ambos, según la política del workspace.
3

Agregar instrucciones

Completa instrucciones adicionales generales que apliquen a la mayoría de los repositorios.
4

Ajustar prompts de revisores (opcional)

Define un override del workspace para el revisor Architect, Spec Validator o QA Engineer solo cuando sea necesario, y revierte al predeterminado global cuando ya no se requiera.
5

Configurar autores

Agrega bots permitidos y autores bloqueados cuando sea necesario.
6

Guardar

Guarda y confirma los mensajes de validación.
7

Probar en un repositorio

Elige un repositorio representativo y da seguimiento a la siguiente revisión en el panel de Ops para validar el comportamiento esperado.

Relación con la configuración del repositorio

NivelMejor uso
WorkspacePolítica predeterminada para la mayoría de los repositorios.
RepositorioExcepciones para proyectos con necesidades específicas.
Mantén la política del workspace simple y estable. Esto reduce la divergencia entre equipos y facilita la auditoría.

Buenas prácticas

  • Escribe instrucciones cortas, claras y verificables.
  • Evita duplicar documentación larga dentro del campo de instrucciones.
  • No incluyas secretos ni datos confidenciales.
  • Revisa la política después de cambios importantes de proceso.
  • Usa las excepciones por repositorio con moderación.
  • Revierte los overrides de prompt de revisor al predeterminado global una vez que ya no se necesiten, y mantén la guía duradera en el ARCHITECTURE.md del repositorio.
  • Combina la política de autores con las branch rules para reducir el ruido.

Problemas comunes

SíntomaQué verificar
No puedo guardarConfirma que al menos un tier esté activo y que los campos pasen la validación de la pantalla.
Un repositorio no sigue el predeterminadoVerifica si tiene su propia configuración en la pestaña Revisión.
Las revisiones tienen mucho ruidoRevisa las instrucciones adicionales, la política de autores y las branch rules de los repositorios.
Un revisor se comporta de forma inesperada en todas partesVerifica si hay un override de prompt del workspace configurado para ese revisor y usa Revertir al global si es necesario.
El bot esperado no fue revisadoConfirma que la cuenta esté en bots permitidos y que el evento cumpla las reglas del repositorio.
El autor sigue generando revisiónVerifica la grafía, el identificador del proveedor y la configuración del repositorio.