VALIDATION PIPELINE - Arquitectura del Motor de Validación

🎯 Pipeline de 5 Fases

Phase 1: Parse & Load

Objetivo: Cargar módulos y construir grafo de dependencias

Algoritmo: - Leer metadata de todos los módulos - Construir DependencyGraph (adjacency list + reverse adjacency) - Indexar módulos por nivel

Output: Grafo completo de dependencias

---

Phase 2: Rule Checking

Objetivo: Aplicar todas las composition rules

Algoritmo: - Para cada módulo: - Ejecutar RuleEngine.check_all() - Recolectar violaciones - Clasificar por severidad (ERROR/WARNING)

Output: Lista de violaciones

---

Phase 3: Cycle Detection

Objetivo: Detectar dependencias circulares

Algoritmo: DFS-based

State: {0=unvisited, 1=visiting, 2=visited}

function DFS(node):
    state[node] = 1  // visiting
    for each neighbor:
        if state[neighbor] == 0:
            DFS(neighbor)
        else if state[neighbor] == 1:
            // Back edge detected - CYCLE!
            extract_cycle()
    state[node] = 2  // visited

Complejidad: O(V + E) donde V=módulos, E=dependencias

Output: Lista de ciclos detectados

---

Phase 4: Transitive Validation

Objetivo: Validar jerarquía transitiva

Algoritmo: Floyd-Warshall Closure

// Compute transitive closure
for k in modules:
    for i in modules:
        if i can reach k:
            i can reach all(k can reach)

// Validate hierarchy
for module in modules:
    for trans_dep in transitive_deps[module]:
        assert level(trans_dep) < level(module)

Complejidad: O(V³) para closure, O(V²) para validación

Output: Violaciones de jerarquía transitiva

---

Phase 5: Report Generation

Objetivo: Generar reporte comprensivo

Formatos: - TEXT: Human-readable - JSON: Machine-readable - HTML: Web-friendly con CSS

Contenido: - Timestamp - Overall pass/fail - Resultados por fase - Todas las violaciones - Ciclos detectados - Estadísticas

---

📊 Ejemplo de Flujo

Modules: {A, B, C, D}
Dependencies: A→B, B→C, C→D

Phase 1: Parse & Load
  ✓ Graph built: 4 nodes, 3 edges

Phase 2: Rule Checking
  ✓ A (L2) → B (L1): Valid
  ✓ B (L1) → C (L0): Valid
  ✓ C (L0) → D (?): D not in catalog (external dep)
  → 0 violations

Phase 3: Cycle Detection
  ✓ DFS from A, B, C, D
  → 0 cycles found

Phase 4: Transitive Validation
  ✓ A can reach {B, C, D}
  ✓ Hierarchy preserved: level(D) < level(C) < level(B) < level(A)
  → 0 violations

Phase 5: Report Generation
  ✓ JSON exported
  ✓ Total duration: 15.3ms

RESULT: ✅ PASSED

---

🚨 Ejemplo con Violaciones

Modules: {X, Y, Z}
Dependencies: X→Y, Y→Z, Z→X

Phase 1: Parse & Load
  ✓ Graph built

Phase 2: Rule Checking
  ✓ Direct rules passed

Phase 3: Cycle Detection
  ❌ CYCLE: X → Y → Z → X
  → 1 cycle found

Phase 4: Transitive Validation
  ⚠️  Skipped (cycles present)

Phase 5: Report Generation
  ✓ Report generated

RESULT: ❌ FAILED (1 cycle)

---

⚙️ Optimizaciones

Caching

• Cache grafo entre ejecuciones
• Invalidar solo si módulos cambian

Incremental Validation

• Solo validar módulos modificados
• Recalcular closure solo si deps cambian

Paralelización

• Phase 2 puede ejecutarse en paralelo (rule checking por módulo)
• Phase 3 puede buscar ciclos en componentes conexas separadas

---

📈 Performance Targets

Métrica	Target	Actual (500 módulos)
Phase 1	<1s	~0.2s
Phase 2	<20s	~5s
Phase 3	<5s	~1s
Phase 4	<10s	~3s
Phase 5	<1s	~0.1s
Total	<30s	~10s

---

🔧 Configuración

ValidationEngine engine;

// Deshabilitar fases (para debugging)
engine.enable_phase(3, false);  // Skip cycle detection

// Usar rule engine custom
RuleEngine custom_engine;
engine.set_rule_engine(&custom_engine);

// Validación rápida (solo errores)
bool valid = engine.quick_validate(modules);

---

Última actualización: 2025-10-10 Versión: 1.0.0