Navegación Bilingüe: English
↑ Visión General del Producto Evolith E2E · MD3 — clic para ampliar
Evolith Core no es un corpus de documentación. Es un framework de gobernanza ejecutable —
un estándar técnico agnóstico a topologías y neutral respecto al runtime que dicta cómo se construye el software,
distribuido mediante interfaces CLI, MCP y Service CORE API, y aplicado por rulesets verificables.
Arquitectura Progresiva: la capacidad del framework para escalar sistemas mutando entre topologías según el ciclo de vida del negocio, previniendo el sobre-diseño y garantizando la coherencia arquitectónica mediante ejecución automática.
Evolith Core existe para convertirse en el sistema operativo definitivo de grado enterprise para la gobernanza de arquitectura de software: global, agnóstico al stack, consciente de topologías y ejecutable por humanos, plataformas de delivery y agentes IA. Define la constitución técnica que todo producto, repositorio satélite y sistema de orquestación puede heredar sin acoplarse a un lenguaje, proveedor cloud, runtime, motor de base de datos o modelo comercial específico de producto.
Su misión es convertir la gobernanza arquitectónica en una capacidad operativa. ADRs, rulesets, políticas, contratos, implementaciones de referencia e instrucciones IA no son documentos pasivos; son artefactos técnicos autoritativos expuestos mediante canales obligatorios de ejecución para que los equipos puedan validar, consultar, generar estructuras base y hacer cumplir la arquitectura seleccionada antes de que el código llegue a producción.
Evolith Core es un corpus de referencia multi-topología y un framework de gobernanza ejecutable para organizaciones modernas de ingeniería B2B. Ya no gobierna únicamente el camino desde monolitos simples hacia microservicios. Gobierna la mutación deliberada de sistemas entre monolitos modulares, servicios distribuidos, Cloud-Native Serverless, Event-Driven, Data Mesh, Edge Computing y Agentic / AI-First Architectures cuando la madurez del producto, la complejidad operativa y la economía de plataforma justifican el cambio.
En Evolith, "progresivo" significa la capacidad del framework para escalar sistemas mutando entre topologías según el ciclo de vida del negocio, previniendo el sobre-diseño y preservando la coherencia arquitectónica mediante ejecución automática. El framework define el Qué y el Cómo técnico; tiempos de negocio, ownership, financiamiento, ROI y priorización permanecen fuera del Core y son gobernados por Evolith Tracker mediante su ACL y Funnel 0.
Evolith Core gobierna a través de un corpus de referencia multi-topología. Cada topología es un contexto delimitado completamente aislado con sus propios ADRs, políticas OPA, rulesets IA y contratos UMS. El repositorio fluye desde la superficie más general hasta el artefacto más específico, a través de tres dominios:
| Nivel | Superficie | Úsala para |
|---|---|---|
| 1. Portal | Este README | Elegir un dominio o una ruta de inicio |
| 2. Hubs de dominio | Evolith Core · Evolith SDLC · Evolith Products | Entender la meta, los objetivos y los límites de cada dominio |
| 3. Hubs de área | Arquitectura, ADRs, Estándares, Fases SDLC, Diseños de producto, Topologías | Localizar la familia de artefactos de una preocupación |
| 4. Documentos detalle | ADRs, plantillas, estándares, rulesets, guías, políticas OPA, contratos UMS | Aplicar un artefacto específico y autoritativo |
Cuando ya sabes qué artefacto necesitas, sáltate el descenso y abre el Índice Maestro Global.
Evolith Core gobierna y proporciona artefactos de referencia para las siguientes topologías de arquitectura, cada una residiendo en un subdirectorio /topologies/ aislado con sus propios ADRs, políticas OPA, rulesets IA y contratos UMS:
| Topología | Descripción |
|---|---|
| Monolito Modular | Topología fundamental para sistemas que comienzan simples y maduran sin distribución prematura |
| Cloud-Native Serverless | Arquitecturas event-driven, auto-escalables y de pago-por-ejecución sobre FaaS y servicios gestionados |
| Event-Driven | Sistemas async-first con brokers de mensajes, event sourcing y CQRS |
| Data Mesh | Plataformas de datos orientadas a dominio, autoservicio y con gobernanza federada |
| Edge Computing | Cómputo distribuido en el borde de la red con restricciones de offline-first y baja latencia |
| Agentic / AI-First | Arquitecturas diseñadas para agentes IA como actores de primera clase con integración MCP (Model Context Protocol) |
Evolith Core expone tres canales de acceso obligatorios para que cualquier equipo de ingeniería interactúe programáticamente con el framework de gobernanza:
| Interfaz | Propósito |
|---|---|
| CLI | Los desarrolladores validan código localmente contra los rulesets de su topología elegida. smart-cli validate, smart-cli adr create, etc. |
| MCP (Model Context Protocol) | La API fundamental para inyectar "Contexto Arquitectónico" directamente en agentes IA (Copilot, Cursor, etc.), permitiendo que el agente entienda las reglas de gobernanza antes de escribir código |
| Service CORE API | Interfaz programática para que sistemas de orquestación (ej. Evolith Tracker) consulten patrones, contratos UMS y políticas OPA de forma remota |
El árbol /topologies/ es el límite modular estricto para la gobernanza arquitectónica ejecutable. Cada topología soportada debe estar aislada como un contexto delimitado completo y debe exponer las mismas familias de artefactos:
/topologies/
/agentic-ai/
/adrs/
/opa-policies/
/ai-rulesets/
/ums-contracts/
/serverless/
/adrs/
/opa-policies/
/ai-rulesets/
/ums-contracts/
Ninguna topología puede filtrar reglas, contratos o supuestos de runtime hacia otra topología. Las preocupaciones compartidas deben promoverse a estándares de nivel Core solo cuando hayan demostrado ser reutilizables entre contextos delimitados.
Regla crítica: los artefactos de la Fase 1 (ideación técnica) dentro de Core deben permanecer 100% desacoplados de cualquier dato de negocio — presupuestos, ROI, costos, recursos. Core expone solo el Qué y el Cómo (técnico). El Tracker (vía su ACL y Funnel 0) es el único componente autorizado para gestionar el Cuándo y el Quién (negocio).
Meta: orientar a cualquier lector — ejecutivo, arquitecto, ingeniero o agente IA — en menos de cinco minutos.
Objetivos: explicar qué es Evolith, dirigir a cada rol a su ruta de lectura más corta y exponer el índice de navegación completo para acceso directo.
Puntos de entrada principales
| Enlace (URL) | Descripción (breve explicación) | Meta / Objetivo | Tipificación (categoría o tipo) |
|---|---|---|---|
| Resumen Ejecutivo | Explicación de cinco minutos sobre Evolith, UMS y la propuesta de valor | Comunicar valor estratégico rápidamente | Resumen ejecutivo |
| Primeros Pasos por Rol | Rutas de lectura recomendadas para ejecutivos, arquitectos, ingenieros, QA, SRE, producto y contribuidores IA | Acelerar onboarding por rol | Guía de incorporación |
| Vision del Producto | Dirección estratégica, hoja de ruta y modelo de madurez | Alinear equipos a objetivos a largo plazo | Visión y estrategia |
| Centro de Gobernanza SDLC | Fases, gates, artefactos y modelo de trazabilidad autoritativos | Gobernar el ciclo de vida completo | Hub de gobernanza |
| Indice Maestro Global | Navegación completa del repositorio cuando ya sabes qué artefacto necesitas | Localizar cualquier artefacto rápidamente | Índice de navegación |
| Integration & Messaging Hub | Estrategias de mensajería asíncrona, topologías de integración y gobernanza de patrones | Estandarizar mensajería de microservicios | Hub de arquitectura |
| Application Architecture Hub | Patrones de aplicación core (PoEAA) para desacoplar datos y lógica | Estandarizar estructuras de apps | Hub de arquitectura |
| Domain-Driven Design Hub | Patrones DDD estratégicos y tácticos para microservicios y contextos delimitados | Alinear software con dominios de negocio | Hub de arquitectura |
Primeros Pasos por Rol
Propósito: Onboarding autoguiado — cada perfil encuentra su primera lectura según su responsabilidad.
| Rol | ¿Qué busca? | Comenzar por | Luego revisar |
|---|---|---|---|
| Arquitecto | Estándares, ADRs, blueprints | Hub de Arquitectura | Matriz de ADRs |
| Desarrollador | Cómo implementar siguiendo el SDLC | Estándares de Ingeniería | Modelo de Referencia UMS |
| QA / SRE | Gates, calidad, métricas, ops | Hub Operativo | Quality Gates SDLC |
| Producto / PM | PRD, trazabilidad, roadmap | Centro de Gobernanza SDLC | Visión del Producto |
| Agente IA (BMAD) | Reglas, skills, flujo asistido | AGENTS.md — reglas de agentes | Flujo Asistido IA |
Meta: definir la constitución de arquitectura neutral respecto de proveedores que todo producto y repositorio satélite hereda.
Objetivos: centralizar directivas arquitectónicas y blueprints, preservar el histórico de decisiones mediante ADRs, alinear equipos en estándares y gobernanza, y automatizar el cumplimiento con rulesets.
Hub de dominio: Evolith Core — qué es Core, qué no es, sus dominios y su regla de dependencia.
Arquitectura y Blueprints
| Enlace (URL) | Descripción (breve explicación) | Meta / Objetivo | Tipificación (categoría o tipo) |
|---|---|---|---|
| Directivas Arquitectonicas y Hub | Único punto de acceso a directivas, blueprints, stack base y topologías | Guiar el diseño corporativo | Hub de arquitectura |
Decisiones de Arquitectura (ADRs)
| Enlace (URL) | Descripción (breve explicación) | Meta / Objetivo | Tipificación (categoría o tipo) |
|---|---|---|---|
| Registro General de ADRs | Punto central que agrupa la matriz de decisiones y todos los ADRs por ecosistema | Mantener histórico y gobernanza | Hub de decisiones |
Estandares y Gobernanza
| Enlace (URL) | Descripción (breve explicación) | Meta / Objetivo | Tipificación (categoría o tipo) |
|---|---|---|---|
| Centro de Estandares y Gobernanza | Directorio principal de manifiestos, taxonomías, directivas técnicas y observabilidad | Alinear equipos a políticas unificadas | Hub de gobernanza |
| Hub de Infraestructura y Operaciones | Punto de acceso consolidado a despliegues, guías SRE e infraestructura | Normar despliegues y operación | Hub operativo |
Rulesets y Validacion
| Enlace (URL) | Descripción (breve explicación) | Meta / Objetivo | Tipificación (categoría o tipo) |
|---|---|---|---|
| Hub General de Rulesets | Centraliza todas las reglas automatizadas de arquitectura, schemas y CI | Validar cumplimiento automatizado | Hub de reglas |
Meta: gobernar el ciclo de vida de desarrollo completo mediante cinco fases con gates explícitos y evidencia verificable.
Objetivos: mapear cada fase a sus artefactos obligatorios y opcionales, estandarizar plantillas, hacer cumplir quality gates y trazabilidad, y validar el cumplimiento automáticamente en CI.
Hub de dominio: Centro de Gobernanza SDLC — fases, gates, artefactos, roles y el modelo de trazabilidad.
Las cinco fases siguientes van de la concepción a las operaciones; cada sección lista los artefactos de esa fase con su nivel de requisito.
Referencias Generales del SDLC
| Enlace (URL) | Descripción (breve explicación) | Meta / Objetivo | Tipificación (categoría o tipo) |
|---|---|---|---|
| Mapeo de Artefactos SDLC | Mapeo de artefactos | Vincular fases y entregables | Estandares y guia |
Fase 01 - Concepcion y Descubrimiento
| Enlace (URL) | Descripción (breve explicación) | Meta / Objetivo | Tipificación (categoría o tipo) | Requisito |
|---|---|---|---|---|
| Discovery Canvas | Lienzo de descubrimiento | Definir visión y viabilidad | Documentos y plantillas | Obligatorio |
| Technical Feasibility Canvas | Factibilidad técnica | Especificar NFRs y restricciones | Documentos y plantillas | Opcional |
| Ballpark Estimation | Estimación a gran escala | Proyectar costos y tiempos | Documentos y plantillas | Opcional |
| PRD - Documento de Requerimientos de Producto | Documento de requerimientos | Especificar necesidades funcionales | Documentos y plantillas | Obligatorio |
| Evolith User Story | Plantilla de historia de usuario | Estandarizar historias ágiles | Documentos y plantillas | Obligatorio |
| Agile Backlog | Plantilla de backlog | Organizar entregables | Documentos y plantillas | Obligatorio |
| CLI Impact Analysis | Análisis de impacto CLI | Evaluar cambios cross-repo | Documentos y plantillas | Opcional |
| Validation Schemas & Rules (Fase 1) | Schemas de validación para Canvas, PRD, Backlog y reglas de Gates | Validar cumplimiento en CI | Reglas y schemas | Obligatorio |
Fase 02 - Diseno y Arquitectura
| Enlace (URL) | Descripción (breve explicación) | Meta / Objetivo | Tipificación (categoría o tipo) | Requisito |
|---|---|---|---|---|
| Plantilla ADR | Plantilla de ADR | Documentar decisiones clave | Documentos y plantillas | Opcional |
| Plantilla de Historia Funcional | Plantilla de historia funcional | Detallar comportamiento | Documentos y plantillas | Obligatorio |
| Plantilla de Modelo DDD | Plantilla de modelo DDD | Modelar dominios del sistema | Documentos y plantillas | Opcional |
| Estandar de Escritura de Historias Funcionales | Estándar de historias funcionales | Asegurar calidad de specs | Estandares y guia | Obligatorio |
| Buenas Practicas de Documentacion SDLC | Prácticas de documentación | Mejorar calidad documental | Estandares y guia | Obligatorio |
| Validation Schemas & Rules (Fase 2) | Schemas de validación para ADRs y Funcionales | Validar cumplimiento en CI | Reglas y schemas | Obligatorio |
Fase 03 - Construccion
| Enlace (URL) | Descripción (breve explicación) | Meta / Objetivo | Tipificación (categoría o tipo) | Requisito |
|---|---|---|---|---|
| Hub de Plantillas de Artefactos | Hub de plantillas | Centralizar formatos SDLC | Documentos y plantillas | Obligatorio |
| Plantilla de Historia Tecnica | Plantilla de historia técnica | Estructurar tareas técnicas | Documentos y plantillas | Obligatorio |
| Framework SDLC Enfocado en Construccion | Framework de construcción y Definition of Done (DoD) | Normar ejecución técnica | Estandares y guia | Obligatorio |
| Quality Gates SDLC | Gates de calidad | Establecer umbrales de aprobación | Estandares y guia | Obligatorio |
| Validation Schemas & Rules (Fase 3) | Schemas para Historias Técnicas, reglas DoD, Thresholds y Dependency Pinning | Validar cumplimiento en CI | Reglas y schemas | Obligatorio |
Fase 04 - Validacion y QA
| Enlace (URL) | Descripción (breve explicación) | Meta / Objetivo | Tipificación (categoría o tipo) | Requisito |
|---|---|---|---|---|
| Plantilla de Test Summary Report | Reporte de pruebas | Consolidar resultados de QA | Documentos y plantillas | Obligatorio |
| Modelo de Trazabilidad SDLC | Modelo de trazabilidad | Vincular requerimientos y pruebas | Estandares y guia | Obligatorio |
| Validation Schemas & Rules (Fase 4) | Esquema de validación del Test Summary Report | Validar cumplimiento en CI | Reglas y schemas | Obligatorio |
Fase 05 - Entrega y Operaciones
| Enlace (URL) | Descripción (breve explicación) | Meta / Objetivo | Tipificación (categoría o tipo) | Requisito |
|---|---|---|---|---|
| Plantilla de Release Notes | Plantilla de notas de versión | Comunicar cambios de release | Documentos y plantillas | Obligatorio |
| Validation Schemas & Rules (Fase 5) | Esquema de validación de Release Notes, reglas de CI/CD (ADR-0005) y GitFlow (ADR-0050) | Validar cumplimiento en CI | Reglas y schemas | Obligatorio |
Meta: entregar la constitución Core como productos funcionales y demostrarla con referencias aplicadas.
Objetivos: dirigir el portafolio mediante la Product Suite, documentar el diseño interno de cada producto, demostrar adopción real mediante UMS y casos de adopción, y dotar de herramientas el flujo con la Smart CLI.
Hubs de dominio: Product Suite (visión y estrategia del portafolio) · Diseños de Producto (internos por producto)
Seguimiento de la Suite — pendientes, auditoría y madurez
Las dos superficies canónicas de seguimiento de la suite — todo lo pendiente, auditado o medido vive en una de estas:
| Enlace (URL) | Descripción (breve explicación) | Meta / Objetivo | Tipificación (categoría o tipo) |
|---|---|---|---|
| Tablero de Gaps | Tabla compacta única para todos los gaps, ordenada por criticidad, estado y complejidad; cada ID abre su referencia detallada | Ver al instante qué falta y abrir la explicación solo cuando sea necesaria | Tablero de seguimiento |
| Evaluación de Madurez | Evaluación de madurez única: matriz TOGAF ACMM, revisión WAF, auditoría de patrones/anti-patrones y alineación con la visión | Medir qué tan madura está la suite y dónde invertir | Matriz de madurez y auditoría |
| Reporte de Cobertura Documental | Estado de cobertura de la documentación bilingüe | Auditar la completitud documental | Reporte de cobertura |
Evolith Product Suite
| Enlace (URL) | Descripción (breve explicación) | Meta / Objetivo | Tipificación (categoría o tipo) |
|---|---|---|---|
| Hub de Product Suite | Único punto de acceso a la visión, estrategia y posicionamiento del portfolio | Dirección del ecosistema | Referencia de producto |
| Arquitectura Evolith Core | Diseño completo del ecosistema C4 y visión conceptual de la plataforma | Blueprint maestro de arquitectura | Blueprint de arquitectura |
Evolith Tracker
| Enlace (URL) | Descripción (breve explicación) | Meta / Objetivo | Tipificación (categoría o tipo) |
|---|---|---|---|
| Evolith Tracker Hub | Punto central que agrupa la arquitectura e interfaces técnicas del producto Tracker | Producto de gobernanza | Referencia de producto |
UMS (Referencia Aplicada)
| Enlace (URL) | Descripción (breve explicación) | Meta / Objetivo | Tipificación (categoría o tipo) |
|---|---|---|---|
| Hub de Referencia UMS | Punto de acceso consolidado a modelos, comparativas y portal de arquitectura UMS | Demostrar implementación real | Referencia aplicada |
Smart CLI
# Inicializar nuevo repositorio satélite
npx @evolith/smart-cli init
# Validar contra estándares Evolith
smart-cli validate
# Gestionar ADRs
smart-cli adr create
smart-cli adr list
# Servidor MCP para asistentes IA
smart-cli mcp serve| Enlace (URL) | Descripción (breve explicación) | Meta / Objetivo | Tipificación (categoría o tipo) |
|---|---|---|---|
| Smart CLI Hub | Acceso central a documentación, arquitectura, visión y análisis de estado de la CLI | Entender la herramienta | Referencia de producto |
Casos de Adopcion y Herramientas
| Enlace (URL) | Descripción (breve explicación) | Meta / Objetivo | Tipificación (categoría o tipo) |
|---|---|---|---|
| Casos de Adopcion | Casos de adopción | Mostrar éxito y aprendizaje | Referencia aplicada |
- validate-docs.mjs - validacion de links, anchors, encoding y Mermaid.
- check-bilingual-parity.mjs - validacion de paridad estructural EN/ES.
- impact-analysis-synchronizer.mjs - sincronizacion de impacto cross-repo.
Meta: hacer que cada documento sea localizable en dos clics o menos, en ambos idiomas.
Objetivos: mantener el índice maestro como superficie de navegación completa, auditar la paridad EN/ES y registrar los releases documentales.
| Enlace (URL) | Descripción (breve explicación) | Meta / Objetivo | Tipificación (categoría o tipo) |
|---|---|---|---|
| Índice Maestro Global | La única superficie de navegación completa: por intención, por rol, por fase SDLC (todos los artefactos de cada fase) y con el Core agnóstico separado de lo específico por plataforma | Localizar cualquier artefacto rápidamente | Índice de navegación |
| Índice Bilingüe | Estado autogenerado del emparejamiento EN/ES del corpus de referencia | Auditar cobertura bilingüe | Índice de navegación |
| Acceso Rápido por Stack | Camino más corto a los estándares de React, .NET y Node.js | Reducir fricción de navegación | Índice de navegación |
| Taxonomía Documental | Qué tipo de documento pertenece a cada lugar | Mantener el corpus organizado | Referencia de gobernanza |
Antes de contribuir, lee:
- Guía de Contribución Open Source — Cómo contribuir como miembro de la comunidad usando el método BMAD
- AGENTS.md — Reglas y convenciones de agentes
- Taxonomia del Repositorio — Que va donde
- Guia de Herencia — Como los productos heredan
Publicado bajo la Licencia MIT.