Define reglas de arquitectura deterministas que validan los cambios de codigo contra tu modelo C4, decisiones tecnologicas y estandares de codificacion — sin IA involucrada

Reglas de conformidad (Guardrails)

Las reglas de conformidad son verificaciones deterministas que validan los cambios de codigo contra tus decisiones arquitectonicas. Imponen convenciones de nomenclatura, restricciones tecnologicas, limites entre capas y patrones de seguridad — sin ninguna IA involucrada.

Navega a Agent Hub en la barra lateral para gestionar tus reglas de conformidad.

Por que reglas de conformidad?

Cuando los agentes de codificacion IA (Claude Code, Cursor, Copilot) generan codigo, no conocen tus decisiones arquitectonicas. Las reglas de conformidad codifican esas decisiones como restricciones ejecutables:

El agente no puede usar MongoDB si tu radar tecnologico indica PostgreSQL
El agente no puede colocar llamadas a la base de datos en handlers HTTP si tu arquitectura requiere una capa de servicio
El agente no puede agregar fmt.Println si tu equipo usa logging estructurado

Las reglas se evaluan de manera determinista — sin LLM, sin salida probabilistica. El mismo codigo siempre produce el mismo resultado.

Tipos de reglas

Archyl soporta siete tipos de reglas de conformidad:

Patron requerido

Verificar patrones que deben existir o no deben existir en tu codigo.

Caso de uso	Ejemplo
Prohibir logging de debug	Prohibir `fmt.Println`, `console.log`, `print()`
Prohibir riesgos de seguridad	Prohibir `eval()`, `innerHTML`, contrasenas en el codigo
Requerir manejo de errores	Requerir `set -euo pipefail` en scripts de shell
Imponer estandares	Prohibir `SELECT *` en consultas SQL

Configuracion:

File glob — Solo verificar archivos que coincidan con un patron (ej. *.go, *.ts)
Patrones prohibidos — Patrones regex que generan una violacion cuando se encuentran
Patrones requeridos — Patrones regex que generan una violacion cuando estan ausentes

Convencion de nomenclatura

Validar patrones de nomenclatura de archivos, tipos y funciones.

Alcance	Ejemplo
Archivo	Los archivos Go deben ser `snake_case.go`
Tipo	Los tipos exportados deben ser `PascalCase`
Funcion	Las funciones deben comenzar con un verbo (`Get`, `Create`, `Delete`)

Configuracion:

Patrones — Lista de alcance (archivo/tipo/funcion) + regex + descripcion

Restriccion tecnologica

Restringir que lenguajes y bibliotecas estan permitidos en un contenedor.

Caso de uso	Ejemplo
Bloqueo de lenguaje	El backend debe ser solo Go
Prohibicion de dependencia	No lodash (usar JS nativo)
Imposicion de migracion	No moment.js (usar date-fns)

Configuracion:

Lenguajes permitidos — Lista separada por comas (ej. go, typescript)
Imports prohibidos — Un import por linea

Limite de capa

Imponer reglas de importacion de Clean Architecture, Arquitectura Hexagonal o DDD.

Capa	Puede importar desde
Domain	Nada (logica de negocio pura)
Service	Solo Domain
Adapter	Domain, Service
Infrastructure	Solo Domain

Configuracion:

Capas — Definir cada capa con un nombre, patron de ruta (glob) y fuentes de importacion permitidas
Haz clic en los nombres de las capas para alternar los permisos de importacion

Conformidad de contrato

Validar que los endpoints del codigo coincidan con tus contratos de API almacenados en Archyl.

Configuracion:

Tipo de contrato — HTTP (OpenAPI), gRPC, GraphQL o AsyncAPI
Patrones de archivos de endpoints — Globs para archivos que contienen definiciones de endpoints
Modo estricto — Cuando esta habilitado, cualquier endpoint que no este en el contrato genera una violacion

Regla de dependencia

Asegurar que las dependencias entre componentes coincidan con el modelo de relaciones C4.

Configuracion:

Alcance — Nivel de contenedor o componente
Requerir existencia de relacion — Cada import en el codigo debe tener una relacion C4 correspondiente
Pares prohibidos — Pares de elementos especificos que nunca deben depender entre si

Conformidad de canales de eventos

Validar que los productores/consumidores de eventos en el codigo coincidan con los EventChannels declarados.

Configuracion:

Patrones de productores — Patrones regex que identifican codigo de produccion de eventos
Patrones de consumidores — Patrones regex que identifican codigo de consumo de eventos
Regex de topic — Patron para extraer nombres de topics del codigo

Packs de reglas

Los packs son colecciones curadas de reglas que puedes instalar con un clic. En lugar de agregar reglas una por una, instala un pack y obtiene un conjunto completo de reglas para tu stack.

Haz clic en Packs en la barra de herramientas para explorar los packs disponibles.

Packs de arquitectura

Pack	Reglas	Que impone
Clean Architecture	5	Limites de capa domain/service/adapter/infra, aislamiento de modulos
Hexagonal Architecture	4	Patron ports & adapters, aislamiento del nucleo
Domain-Driven Design	3	Capas DDD, separacion CQRS comando/consulta

Packs de lenguaje

Pack	Reglas	Que cubre
Go Backend	26	Wrapping de errores, seguridad de goroutines, propagacion de contexto, nomenclatura, sin panic, sin init()
React Frontend	23	Estrictez TypeScript, patrones de componentes, fetching de datos, sin manipulacion DOM
Next.js Full-Stack	20	Reglas React + seguridad SSR, guards de window, hooks de localStorage
Python Backend	16	Manejo de excepciones, patrones async, type hints, sin estado global
Java Backend	11	Patrones DI Spring, manejo de excepciones, sin System.exit
Rust Backend	8	Sin unwrap/unsafe, tipos de error correctos, sin todo!()
Kotlin / Android	5	Seguridad null, inmutabilidad, sin println
Vue Frontend	10	Sin v-html, estrictez TypeScript, sin innerHTML
.NET / C# Backend	5	Patrones async, manejo de excepciones, ILogger
Swift / iOS	3	Seguridad de optionals, sin force unwrap

Packs de dominio

Pack	Reglas	Que cubre
Security Essentials	17	Secretos hardcoded, inyeccion, criptografia rota, TLS, CORS
DevOps & Infrastructure	24	Docker, Kubernetes, Terraform, GitHub Actions, scripts shell
API Best Practices	9	Codigos de estado, seguridad SQL, docs de contrato, sin URLs hardcoded
Testing & Reliability	5	Sin tests ignorados, sin .only(), sin sleep, sin TODO
Event-Driven Architecture	3	Nomenclatura de topics Kafka/RabbitMQ, sin topics hardcoded

Catalogo de reglas

Archyl incluye un catalogo de 170+ reglas preconstruidas en 24 tecnologias. Explora el catalogo haciendo clic en Catalog en el Agent Hub.

Tecnologias cubiertas

Go, TypeScript, JavaScript, Python, Java, Kotlin, Rust, C#, C/C++, Ruby, PHP, Swift, React, Vue, Angular, Next.js, Docker, Kubernetes, Terraform, SQL, Shell, YAML, GitHub Actions

Categorias

Categoria	Ejemplos
Architecture & Design	Clean Architecture, Hexagonal, DDD, MVC, handler-service-repository
Seguridad	Sin secretos en el codigo, sin eval(), sin inyeccion SQL, sin TLS deshabilitado, sin CORS wildcard
Calidad de codigo	Sin logging de debug, sin catch vacios, sin bare except, sin tipo `any`, sin `unwrap()`
Infrastructure & DevOps	Fijar versiones de Docker, limites de recursos K8s, sin contenedores privilegiados, tags de Terraform
Convenciones de nomenclatura	snake_case, PascalCase, camelCase segun el lenguaje
Pruebas y fiabilidad	Sin tests ignorados, sin `.only()`, sin TODO/FIXME
Rendimiento	Sin sleep sincrono, sin consultas N+1, sin await en bucles
API y datos	Sin SQL crudo, codigos de estado HTTP correctos, validar cuerpos de peticion

Haz clic en cualquier regla del catalogo para agregarla — el formulario de configuracion se completa automaticamente.

Niveles de severidad

Cada regla tiene una severidad que determina su impacto:

Severidad	Significado	Ejemplo
Critical	Debe corregirse antes del merge	Sin secretos en el codigo, sin eval(), violaciones de limites de capas
High	Deberia corregirse antes del merge	Sin logging de debug, fijar versiones de Docker, sin panic en Go
Medium	Corregir cuando sea conveniente	Convenciones de nomenclatura, sin tipo `any`, sin `var` en JS
Low	Informativo	Sin TODO/FIXME, sin estilos inline en React

Gestion de reglas

Crear reglas

Haz clic en Packs para instalar un conjunto de reglas curado para tu stack, o
Haz clic en Catalog para explorar y agregar de las 170+ reglas preconstruidas, o
Haz clic en Custom para crear una nueva manualmente

Habilitar/Deshabilitar reglas

Alterna el interruptor junto a cualquier regla para habilitarla o deshabilitarla. Las reglas deshabilitadas no se evaluan.

Editar reglas

Haz clic en el icono de edicion (lapiz) en cualquier regla para modificar su nombre, descripcion, severidad o configuracion.

Eliminar reglas

Haz clic en el icono de eliminacion (papelera), luego confirma. Esta accion no se puede deshacer.

Filtrar reglas

Buscar — Filtrar por nombre o descripcion de la regla
Filtro por tipo — Haz clic en las pastillas de tipo para mostrar solo reglas de un tipo especifico

Integracion CI/CD

Las reglas de conformidad pueden ejecutarse automaticamente en cada pull request. Consulta Integracion con GitHub Actions para instrucciones de configuracion.

Como funciona

Se abre o actualiza un PR en GitHub
La GitHub Action de Archyl obtiene los archivos modificados
Los archivos se envian a la API de Archyl para evaluacion
Los resultados aparecen como comentario de PR y estado de commit
El workflow falla si se encuentran violaciones criticas o altas

Comentario de PR

Cuando se encuentran violaciones, Archyl publica un comentario detallado en el PR:

Tabla resumen con conteo de violaciones por severidad
Violaciones por archivo con descripciones y sugerencias
El comentario se actualiza (no se duplica) en pushes posteriores

Integracion MCP

Las reglas de conformidad son accesibles para los agentes IA a traves del servidor MCP:

Herramientas MCP disponibles

Herramienta	Descripcion
`list_conformance_rules`	Listar todas las reglas con filtro opcional por proyecto
`create_conformance_rule`	Crear una nueva regla
`update_conformance_rule`	Actualizar configuracion, severidad o estado de activacion de una regla
`delete_conformance_rule`	Eliminar una regla
`get_agent_context`	Obtener el contexto arquitectonico completo incluyendo los guardrails activos

Contexto del agente

La herramienta MCP get_agent_context devuelve todas las reglas de conformidad activas como parte del briefing arquitectonico. Los agentes IA que llamen a esta herramienta antes de comenzar a trabajar sabran que guardrails respetar.

El contexto tambien incluye:

Modelo C4 (sistemas, contenedores, componentes, relaciones)
ADR activos con su justificacion
Stack tecnologico
Contratos de API
Canales de eventos

REST API

Las reglas de conformidad tambien estan disponibles a traves de la REST API:

GET    /api/v1/conformance/rules              # Listar reglas
POST   /api/v1/conformance/rules              # Crear regla
POST   /api/v1/conformance/rules/bulk         # Crear multiples reglas (usado por packs)
GET    /api/v1/conformance/rules/:id          # Obtener regla
PUT    /api/v1/conformance/rules/:id          # Actualizar regla
DELETE /api/v1/conformance/rules/:id          # Eliminar regla
POST   /api/v1/conformance/rules/:id/toggle   # Habilitar/deshabilitar
POST   /api/v1/projects/:id/conformance/check # Ejecutar verificacion con archivos modificados
GET    /api/v1/projects/:id/conformance/checks # Listar historial de verificaciones
GET    /api/v1/conformance/checks/:id/report  # Obtener reporte de verificacion
GET    /api/v1/projects/:id/conformance/stats  # Obtener estadisticas del proyecto

Todos los endpoints requieren autenticacion (JWT o clave API con scope de escritura para mutaciones).

Reglas de conformidad (Guardrails) - Archyl Docs

Reglas de conformidad (Guardrails)

Por que reglas de conformidad?

Tipos de reglas

Patron requerido

Convencion de nomenclatura

Restriccion tecnologica

Limite de capa

Conformidad de contrato

Regla de dependencia

Conformidad de canales de eventos

Packs de reglas

Packs de arquitectura

Packs de lenguaje

Packs de dominio

Catalogo de reglas

Tecnologias cubiertas

Categorias

Niveles de severidad

Gestion de reglas

Crear reglas

Habilitar/Deshabilitar reglas

Editar reglas

Eliminar reglas

Filtrar reglas

Integracion CI/CD

Como funciona

Comentario de PR

Integracion MCP

Herramientas MCP disponibles

Contexto del agente

REST API