03 — Diferenciador

Muchos se paran en la documentación. Nosotros seguimos hasta el código validado.

La mayoría de enfoques terminan en el markdown y los JSON de niveles: una foto muy detallada del legacy, pero todavía sin línea de código nueva. Nosotros continuamos el pipeline: convertimos esa documentación en spec formal, generamos código en el lenguaje destino y ejecutamos validación automática antes de tocar producción.

◇ Pipeline

El pipeline extendido

01

Código legacy

.4gm, .ec, .h, .ecpp, .4gl

02

Knowledge MD

Reglas de negocio y tablas por funcionalidad

03

JSON niveles 0-3

Bloques con profundidad decidida bloque a bloque

04

Spec formal

Contratos ejecutables, tipos, invariantes

05

Código nuevo

Python, TypeScript, Go — lo que decida negocio

06

Shadow validation

Diff engine hasta equivalencia funcional

Ellos paran aquí ↑ (en el paso 03: JSON de niveles). Nosotros seguimos con spec formal → código nuevo → validación en shadow mode.
◆ Ontología

Ontología del lenguaje: el arreglo silencioso

Antes de generar una sola línea de código nuevo, resolvemos los conflictos que impiden migrar en primer lugar.

01

Detección de homónimos divergentes

Firmas idénticas, comportamientos distintos. Se separan explícitamente antes de la spec.

Antes
calc_prima(id) → en CONCLIQOS3
Después
calc_prima(id) → en LIQBASE (¡otro cálculo!)
02

Unificación de sinónimos

Nombres distintos, misma regla de negocio. Se consolidan en una única función canónica.

Antes
resolver_folio() · get_folio_data() · lookup_folio()
Después
folio.resolve() (una sola implementación)
03

Desduplicación de capas

Misma lógica ejecutándose en batch, cursor y frontend. Se centraliza en un servicio con contrato explícito.

Antes
3 implementaciones inconsistentes
Después
1 servicio + 3 consumidores