Skip to content

Latest commit

 

History

History
190 lines (153 loc) · 17.1 KB

File metadata and controls

190 lines (153 loc) · 17.1 KB

Evolith Tracker: Alcance Funcional del Sistema (Suite SDLC)

Navegación Bilingüe: English · Español (este documento)

Estado del Documento: Borrador (refactorizado 2026-06-11 — de alcance por módulo a alcance del sistema) Tipo: Alcance Funcional · Artefacto de Fase 1 Satélite: Evolith Tracker · Upstream: Evolith Core

1. Visión General

Evolith Tracker es el Governance Control Plane del SDLC AI-Native: una suite que digitaliza, automatiza y audita el ciclo de vida completo del software a través de 5 Compuertas de Fase (Phase Gates) secuenciales, aplicando estrictamente las reglas arquitectónicas de Evolith Core. No es un gestor de tareas ni reemplaza herramientas especializadas: bajo el modelo de Governed Composition, el Tracker construye el núcleo irreducible de gobernanza (gates, trazabilidad, reglas Core, Grafo de Evidencias) y consume capacidades maduras de proveedores externos vía Puertos y Adaptadores.

El Core define. Los Proveedores ejecutan. Los Evaluadores asisten. Tracker decide y audita.

El Tracker es la única autoridad de transición de fase: ninguna iniciativa avanza sin superar formalmente su compuerta (BR-001..BR-003), y toda decisión queda auditada, atribuida e inmutable (BR-009).

2. Compuertas, Iteración y Baselines

El refinamiento es iterativo dentro de cada fase: iniciativas, backlogs, contratos e historias se versionan y desglosan libremente mientras la fase está abierta. Pero la superación de una compuerta congela el baseline de esa fase (scope freeze en el Business Sign-Off; contratos inmutables en el Design Baseline). Todo cambio posterior a un gate superado reingresa por gobernanza — solicitud de excepción (ExceptionRequest) o motor de contingencias (Re-Do Flow) — nunca por edición silenciosa. No existen artefactos "vivos" tras su gate: existe versionado gobernado.

3. Los 5 Módulos del Flujo de Valor

Workflow core estricto y no negociable de cada módulo; cada fase tiene su set de artefactos según el estándar SDLC de Evolith.

# Módulo Workflow core (no negociable) Compuerta de salida
1 Discovery & Ideation Hub Registro de iniciativas; compuerta de negocio con sustento del PO (ROI, Time to Market) y sustento técnico (estimación ballpark); generación de backlog o seguimiento solo-iniciativa al aprobar (según configuración del inquilino) Business Sign-Off — alcance congelado
2 Architecture Spec-Driven Contratos OpenAPI/AsyncAPI (REST única superficie API en Fase 1, T-009); ADRs conformes al Core; Technical Blueprint versionado Design Baseline aprobado
3 Construction Tracking Trazabilidad historia↔contrato; evidencias de SCM/CI externos vía puertos; detección de Architecture Drift en tiempo real (BR-004) Build exitoso — merge autorizado
4 Automated QA & Integration Recepción de resultados .harness; pruebas de contrato y regresión; veredicto de calidad Quality Gate — CFR < 2%
5 Dynamic Release Planner Calendario multi-entorno cruzado con scores de regresión; Re-Do Flow ante bloqueos; sign-off humano final Producción en vivo — monitoreo nominal

4. Capacidades Transversales del Sistema

  • Orquestación: el Tracker asigna trabajo, valida entregables contra criterios de gate y audita cada acción. Los agentes que ejecutan el trabajo pertenecen al framework de agentes configurado por el tenant (bmad por defecto, spec-kit, custom, etc.). BMAD es solo orquestación — los agentes no pueden auto-asignarse ni saltar compuertas.
  • Tres superficies equivalentes: Aplicación Web, CLI y Servidor MCP con paridad total de características (BR-008).
  • Multi-tenant parametrizable: cada tenant configura pasos opcionales, niveles de aprobación, modo de ejecución (manual/automatizado), modo de backlog ("generar" o "solo-iniciativa") y framework de agentes (bmad por defecto, spec-kit, custom, etc.) por fase, siempre respetando el workflow core no negociable; aislamiento absoluto de datos por TenantID (BR-006).
  • Uso standalone e interoperabilidad: cada módulo puede operar desacoplado. En importación, cualquier tarea externa puede integrarse y asociarse a la iniciativa de Evolith Tracker como punto de entrada. En exportación, los resultados pueden enviarse a cualquier sistema externo que necesite analizarlos (Jira, Trello, CSV, APIs, etc.), canalizados por el ACL de Integration.
  • Cerebro analítico: Grafo de Evidencias inmutable; métricas DORA y SPACE; Índice de Adherencia Arquitectónica con alertas tempranas de drift.
  • Identidad delegada: AuthN/AuthZ y roles RACI consumidos del SaaS UMS — el Tracker no gestiona usuarios.
  • Gobernanza heredada: las reglas de Evolith Core son inmutables a nivel del Tracker (BR-005); las mejoras se proponen upstream vía ADRs con evidencia operativa.

5. Fuera de Alcance

  • Creación de metodologías personalizadas por tenant (el Tracker impone el SDLC de Evolith). La selección del framework de agentes por tenant no constituye una metodología personalizada: el workflow core, los gates y los artefactos estándar son invariables.
  • Gestión de usuarios, autenticación o identidad (delegado a UMS).
  • Ejecución de código o integración IDE (el Servidor MCP cubre la integración de agentes).
  • Facturación y gestión de suscripciones.
  • GraphQL como superficie API (T-009) y extracción a servicios distribuidos — ambos Fase 2.

6. Catálogo de Artefactos Evolith Core por Fase SDLC

FASE 1: Discovery (Puerta 1) — Requeridos

Artefacto Formato Autor Fase Esquema Core / Plantilla
PRD — Documento de Requisitos de Producto Markdown Product Owner / PM 1 prd.schema.json
Discovery Canvas JSON/Markdown Solicitante / PM 1 discovery-canvas.schema.json
Caso de Negocio (ROI) JSON/YAML Product Owner 1 business-case-roi.schema.json
Estimación Ballpark JSON/Excel Arquitecto / Tech Lead 1 ballpark-estimation.schema.json
Historia de Usuario Evolith Markdown/JSON Agente IA / PM 1 evolith-user-story.schema.json
Backlog Ágil JSON/CSV Product Owner 1 agile-backlog.schema.json
Análisis de Impacto CLI Markdown Arquitecto 1 cli-impact-analysis.schema.json
Directivas Arquitectónicas Markdown Arquitecto 1 [Plantilla pendiente]
Taxonomía de Repositorio Markdown Arquitecto 1 [Plantilla pendiente]
Línea Base Agnóstica (Stack Tecnológico) Markdown Arquitecto 1 [Plantilla pendiente]
ADR-0047 — Selección de Monolito Modular Markdown Arquitecto 1 [Plantilla pendiente]
Manifiesto de Ingeniería Markdown Engineering Lead 1 [Plantilla pendiente]
Matriz de Priorización MoSCoW JSON/Markdown Product Owner 1 [Plantilla pendiente]

FASE 1: Discovery (Puerta 1) — Opcionales

Artefacto Formato Autor Fase Esquema Core / Plantilla
Hoja de Ruta Estratégica Evolutiva Markdown Product Owner 1 [Plantilla pendiente]
Evaluación de Madurez JSON/Markdown Arquitecto 1 [Plantilla pendiente]
Estrategia de Comunicación Arquitectónica Markdown Arquitecto 1 [Plantilla pendiente]
Modelo de Referencia UMS JSON/Markdown Arquitecto 1 [Plantilla pendiente]

FASE 2: Design (Puerta 2) — Requeridos

Artefacto Formato Autor Fase Esquema Core / Plantilla
Contratos API/Eventos YAML/JSON (OpenAPI/AsyncAPI) Arquitecto / Agente IA 2 [Esquema pendiente — GAP-020]
ADR (Registro de Decisión Arquitectónica) Markdown Arquitecto 2 adr.schema.json
Definición de Esquema de Datos SQL/DDL Arquitecto de Datos 2 [Esquema pendiente — GAP-020]
Blueprint Técnico JSON/ZIP Arquitecto Líder 2 [Esquema pendiente — GAP-020]
Blueprint de Referencia Markdown Arquitecto 2 [Plantilla pendiente]
Stack Tecnológico Autoritativo Markdown Arquitecto 2 [Plantilla pendiente]
Matriz de Decisiones ADR JSON/Markdown Arquitecto 2 [Plantilla pendiente]
ADR-0002 — Arquitectura Hexagonal Markdown Arquitecto 2 [Plantilla pendiente]
ADR-0018 — Pirámide de Pruebas Markdown Arquitecto 2 [Plantilla pendiente]
ADR-0031 — Schema por Contexto Markdown Arquitecto 2 [Plantilla pendiente]
ADR-0032 — Matriz de Selección de Protocolo Markdown Arquitecto 2 [Plantilla pendiente]
ADR-0056 — Convenciones de Nomenclatura y Diseño Markdown Arquitecto 2 [Plantilla pendiente]
Historia Funcional Markdown/JSON Product Owner / Agente IA 2 functional-story.schema.json
Estándar de Redacción de Historias Funcionales Markdown Arquitecto 2 [Plantilla pendiente]
Mejores Prácticas de Documentación SDLC Markdown Arquitecto 2 [Plantilla pendiente]
Lista de Verificación de Simplicidad (Fase 1) Markdown Arquitecto 2 [Plantilla pendiente]
Mapa de Contextos Acotados (C4) Diagrama/PNG Arquitecto 2 [Plantilla pendiente]

FASE 2: Design (Puerta 2) — Opcionales

Artefacto Formato Autor Fase Esquema Core / Plantilla
ADR-0010 — Multi-Tenencia Markdown Arquitecto 2 [Plantilla pendiente]
ADR-0045 — Criterios de Extracción Markdown Arquitecto 2 [Plantilla pendiente]
Especificación de Topología C4 Diagrama/PNG Arquitecto 2 [Plantilla pendiente]
Análisis Estratégico CAP Markdown Arquitecto 2 [Plantilla pendiente]
Flujo de Arquitectura de Observabilidad Markdown Arquitecto 2 [Plantilla pendiente]
Patrones Canónicos Markdown Arquitecto 2 [Plantilla pendiente]

FASE 3: Construction (Puerta 3) — Requeridos

Artefacto Formato Autor Fase Esquema Core / Plantilla
Historia Técnica Markdown/JSON SM / Dev 3 technical-story.schema.json
Informe de Deriva JSON/Markdown Agente BMAD 3 [Esquema pendiente — GAP-020]
Informe de Cobertura de Código JSON/HTML Pipeline CI 3 [Esquema pendiente — GAP-020]
Resumen de Revisión de Pares JSON/Markdown Dev / SM 3 [Esquema pendiente — GAP-020]
Lista de Verificación de Definición de Hecho Markdown/JSON SM / Dev 3 [Esquema pendiente — GAP-020]
Delta de Documentación (impulsado por PR) Markdown/JSON Dev 3 [Esquema pendiente — GAP-020]
Manifiesto de Ingeniería Markdown Engineering Lead 3 [Plantilla pendiente]
Framework SDLC (Construcción SS3-4) Markdown Engineering Lead 3 [Plantilla pendiente]
Compuertas de Calidad SDLC JSON/Markdown QA / Engineering Lead 3 [Plantilla pendiente]
ADR-0005 — Pipeline CI/CD Markdown DevOps 3 [Plantilla pendiente]
ADR-0018 — Pirámide de Pruebas Markdown Arquitecto 3 [Plantilla pendiente]
ADR-0049 — Semántica de Nomenclatura y Código Limpio Markdown Arquitecto 3 [Plantilla pendiente]
ADR-0050 — Estrategia de Branching GitFlow Markdown DevOps 3 [Plantilla pendiente]
Mejores Prácticas de Documentación SDLC Markdown Arquitecto 3 [Plantilla pendiente]
Patrones Canónicos Markdown Arquitecto 3 [Plantilla pendiente]
Evidencia de Pipeline CI JSON (externo) Pipeline CI 3 [Esquema pendiente — GAP-020]
Informe de Cobertura (externo) JSON/HTML Pipeline CI 3 [Esquema pendiente — GAP-020]

FASE 4: QA (Puerta 4) — Requeridos

Artefacto Formato Autor Fase Esquema Core / Plantilla
Informe Resumen de Pruebas Markdown/JSON QA 4 test-summary-report.schema.json
Compuertas de Calidad SDLC JSON/Markdown QA / Engineering 4 [Esquema pendiente — GAP-020]
ADR-0018 — Pirámide de Pruebas Markdown Arquitecto 4 [Plantilla pendiente]
ADR-0052 — Estrategia de Aislamiento de Pruebas Unitarias Markdown QA / Dev 4 [Esquema pendiente — GAP-020]
ADR-0053 — Estrategia de Pruebas de Integración/E2E Markdown QA / Dev 4 [Esquema pendiente — GAP-020]
Validación de Aceptación (Firma del PO) JSON/Markdown Product Owner 4 [Esquema pendiente — GAP-020]
Informe de Escaneo de Seguridad JSON/HTML Pipeline CI 4 [Esquema pendiente — GAP-020]
Evidencia de Distribución de Pirámide JSON Pipeline CI 4 [Esquema pendiente — GAP-020]

FASE 4: QA (Puerta 4) — Opcionales

Artefacto Formato Autor Fase Esquema Core / Plantilla
Guía de Pruebas de Contrato Markdown QA / Dev 4 [Esquema pendiente — GAP-020]
ADR-0037 — Verificación de Rendimiento/Caos Markdown QA 4 [Plantilla pendiente]
Evaluación de Riesgo de Proveedor JSON/Markdown Seguridad 4 [Esquema pendiente — GAP-020]
Flujo de Arquitectura de Observabilidad Markdown Arquitecto 4 [Plantilla pendiente]

FASE 5: Release (Puerta 5) — Requeridos

Artefacto Formato Autor Fase Esquema Core / Plantilla
Notas de Release Markdown Release Manager 5 release-notes.schema.json
Procedimiento de Rollback Markdown DevOps / Release 5 [Esquema pendiente — GAP-020]
Evidencia de Despliegue JSON (externo) Pipeline CD 5 [Esquema pendiente — GAP-020]
ADR-0007 — Observabilidad OTel y Loki Markdown DevOps 5 [Plantilla pendiente]
ADR-0013 — Topología Cloud y DR Markdown DevOps 5 [Plantilla pendiente]
ADR-0005 — Pipeline CI/CD Markdown DevOps 5 [Plantilla pendiente]
Hub de Operaciones Markdown DevOps 5 [Plantilla pendiente]
Hub de Infraestructura Markdown DevOps 5 [Plantilla pendiente]
Mejores Prácticas de Documentación SDLC Markdown Arquitecto 5 [Plantilla pendiente]
Validación de Observabilidad JSON Monitoreo 5 [Esquema pendiente — GAP-020]

Transversal — Siempre Requeridos

Artefacto Formato Autor Fase Esquema Core / Plantilla
Línea Base Agnóstica (Stack Tecnológico) Markdown Arquitecto All [Plantilla pendiente]
Blueprint de Referencia Arquitectónica Markdown Arquitecto All [Plantilla pendiente]
Manifiesto de Ingeniería Markdown Engineering Lead All [Plantilla pendiente]
Definición de Hecho (Framework SDLC) Markdown Engineering Lead All [Plantilla pendiente]
Taxonomía de Repositorio Markdown Arquitecto All [Plantilla pendiente]
Evidencia de Compuerta JSON BMAD / Sistema All gate-evidence.schema.json

(Los esquemas exactos y URLs de las plantillas deben publicarse desde Evolith Core — ver UPSTREAM_PROPOSALS Propuesta 3, GAP-020).

7. Integración con la Arquitectura (Fase 1)

  • Frontend: Shell Host (Module Federation, T-002) + un microfrontend React remote por módulo, con versión PWA móvil.
  • Backend: Monolito Progresivo con un Bounded Context por módulo; sin extracción de servicios en Fase 1.
  • Datos: un schema PostgreSQL por contexto bajo la convención tracker_<context> (T-008); referencias UUID entre schemas, sin FKs cross-schema.
  • Event Bus: las fases avanzan por eventos de dominio vía outbox transaccional (InitiativeApprovedEventDesignApprovedEventConstructionGatePassedEventQualityGatePassedEvent).