Validación

​

Visión general

Cada vez que cambias un modelo, ProDex ejecuta una pasada de Validación que verifica el modelo contra un conjunto completo de reglas de corrección. El resultado es el botón de reproducir en la parte inferior del lienzo: verde significa que el modelo es válido y está listo para ejecutarse; rojo significa que hay algo que bloquea la simulación. La validación ocurre continuamente mientras construyes, lo que significa que detectas problemas a medida que los introduces en lugar de descubrirlos horas después cuando una simulación falla.

​

El botón rojo de reproducir

Cuando el botón de reproducir en la parte inferior del lienzo está verde, al pasar el cursor se muestra el tooltip “Run simulation.” Haz clic y la simulación se ejecuta. Cuando está rojo, al pasar el cursor se abre un popover con:

• Un encabezado contando los problemas (por ejemplo, “1 validation error” o “6 validation errors”).
• El texto de error literal del validador, nombrando el componente ofensivo y qué le pasa.
• Un botón Fix with Assistant (con un icono de estrellas) que entrega el error a Dexter.

Un ejemplo real de lo que verás en el popover:

“Component ‘Halo Repress Halo Queue’ (type: BufferDefinition) must have exactly one outgoing standard connection, but has 2.”

Hacer clic en Fix with Assistant suelta ese error exacto en una conversación con Dexter y le pide que proponga un cambio correctivo. Dexter lee el error, ubica el componente en el lienzo y sugiere la edición — usualmente eliminando la conexión extra o dividiendo el downstream del búfer (Buffer) en un Enrutador (Router). Tú revisas el cambio propuesto antes de que se aplique. Si prefieres arreglarlo tú mismo, el mensaje de error es lo suficientemente específico para apuntarte al campo, componente o expresión a editar. El popover se descarta al quitar el cursor, así que vuelve a abrirlo si necesitas releerlo.

​

Qué se valida

El validador ejecuta unas diecisiete categorías de reglas distintas. La lista a continuación cubre las más importantes — las que bloquean modelos reales día a día.

​

Configuración

Campos obligatorios de nivel superior, corrección del formato de archivo, presencia del calendario (cuando se requiere). Un modelo sin un metadata.json o con JSON malformado falla antes de que se ejecute cualquier regla debajo.

​

Nombres e identificadores

• Los ids de componente deben ser únicos en todos los recursos, estaciones y componentes del modelo
• :: está reservado como separador de ruta — ningún id de componente individual puede contenerlo
• Los nombres de variables de estado no deben chocar con componentes, entidades, constantes, tablas de búsqueda ni identificadores reservados del DSL
• Los nombres de tema deben ser únicos
• Los nombres de atributos de entidad deben ser únicos por tipo de entidad

Una colisión falla rápidamente con un error específico nombrando ambos extremos del conflicto.

​

Topología de conexiones

La validación impone cardinalidad estricta en las conexiones:

• Source — 0 entrantes, exactamente 1 saliente
• Sink — 0 salientes
• Router, ModelNode — al menos 1 saliente
• Process, Buffer, Combiner, Separator, Transformer — exactamente 1 conexión estándar saliente
• No puedes dibujar una conexión hacia o desde una Estación (Station). Las estaciones contienen componentes; las conexiones cablean componentes, no contenedores.

Los componentes desconectados — huérfanos, callejones sin salida, componentes con el número equivocado de aristas salientes — se detectan aquí.

​

Consistencia del flujo de entidades

Cada componente declara qué tipos de entidad acepta y emite. La validación verifica que:

• Los tipos de entrada esperados de cada componente se producen en algún lugar upstream
• Ningún componente recibe un tipo que no puede manejar (el flujo no lleva un raw_material a un proceso que espera painted_part)
• Las expectativas de tipo del Combinador (Combiner) y Separador (Separator) coinciden con el flujo circundante

Así es como los desajustes de tipo silenciosos se detectan antes de que corrompan una ejecución (Run).

​

Entidades

Nombres de atributo únicos por tipo de entidad; arreglos choices válidos para tipos de lista; lower_bound ≤ upper_bound en atributos Number; length no negativo en Text.

​

Componentes y estaciones

Campos obligatorios por tipo de componente (por ejemplo, station_id en Process, Combiner, Separator y Transformer — aunque el esquema lo establece por defecto en null, el validador rechaza modelos que lo dejen sin establecer). Las claves capacity de Station deben coincidir con tipos de entidad que entran a la estación; incluir un tipo de salida creado internamente falla.

​

Recursos

Cada recurso definido debe ser referenciado por al menos un componente; cada referencia de componente debe apuntar a un recurso real.

​

Enrutadores

Las rutas probabilísticas tienen pesos no negativos; las rutas condicionales tienen listas de reglas no vacías; las rutas basadas en tipo cubren los tipos de entrada esperados.

​

Transformadores

Los tipos de entidad de salida declarados en el Transformador (Transformer) coinciden con los tipos realmente emitidos.

​

Asignación de atributos del generador de entidades

El conjunto más estricto de restricciones de tipo de atributo:

• dsl_expr no es válido para atributos text_list o number_list
• round_robin y random_choice son válidos solo para boolean, text_list y number_list
• random (muestreo de distribución de probabilidad) es válido solo para number
• fixed y weighted son válidos para cualquier tipo

Los desajustes fallan en la validación con un error específico apuntando a la asignación ofensiva. Ver Entidades para la matriz de compatibilidad completa.

​

Expresiones del DSL

El DSL está tipado estáticamente. Cada expresión se verifica en tiempo de validación, no en tiempo de ejecución:

• Los campos booleanos (condiciones, compuertas (Gate)) deben producir booleanos
• Los campos numéricos deben producir números
• Una función de agregación (SUM, MAX, ANY, etc.) fuera de un contexto multi-entidad falla
• Un identificador no disponible en el contexto de la expresión (por ejemplo, un atributo de entidad en un contexto sin-entidad) falla
• Una constante, tabla de búsqueda o variable de estado referenciada que no existe en la lista de opt-in del modelo falla

Ver El lenguaje de expresiones — la sección Expression Contexts es el punto de partida correcto cuando el popover dice que un identificador no está disponible.

​

Variables de estado

Cada variable de estado tiene un type (uno de number, text, boolean) y un initial_value obligatorio que coincida con ese tipo. Los tipos desajustados fallan.

​

Temas

Nombres de tema únicos; el grafo de disparadores de tema (las aristas del tema A al tema B existen cuando un oyente de A emite B) debe ser acíclico. Los ciclos de tema se detectan aquí antes de que puedan causar comportamiento descontrolado en tiempo de simulación.

​

Event Hooks y Listeners

Los hooks referencian eventos de ciclo de vida válidos para su tipo de componente anfitrión — process started en un Process está bien, process started en un Resource falla. Los campos topic de los Listeners referencian temas declarados. Se imponen las restricciones de acción por componente (ver Sistema de Eventos). Dos bucles directos propios específicos están prohibidos: el hook on_entity_created de una Source ejecutando una acción release, y el hook on_entity_exited de un Buffer ejecutando una acción release — ambos fallan la validación.

​

Constantes y tablas de búsqueda

Las tablas de búsqueda con múltiples claves requieren que todas las llamadas a LOOKUP() pasen el número correcto de claves con tipos coincidentes. Las listas de permitidos possible_keys de las claves (cuando se declaran) se imponen. Los arreglos de opt-in constants[] / lookup_tables[] de cada modelo deben referenciar slugs reales a nivel de fábrica.

​

Calendario

• Todos los campos de fecha y hora (Start Time, End Time, release_time) deben ser fechas ISO con zona horaria consciente. Las fechas ingenuas fallan la validación inmediatamente — sin respaldo implícito de zona horaria.
• Cada marca de tiempo de evento debe caer entre Start Time y End Time (o Start Time + Duration del modelo si End Time no está establecido)
• Las referencias element_id deben resolverse a componentes reales (incluyendo rutas jerárquicas parent::child)
• Las liberaciones de material apuntan a Fuentes o Búferes; las liberaciones a otros tipos de componente fallan
• Las acciones programadas están restringidas a assign y emit — las acciones vinculadas a componente (pause, resume, set capacity, release) no son válidas en calendarios. Usa un emit programado a un tema y deja que un Event Listener maneje el efecto secundario.

​

Modelos anidados (Nodos de modelo)

La validación se recurre en cada modelo anidado referenciado por un ModelNode. Los errores dentro de un submodelo burbujean con un prefijo de ruta — "Nested model 'cell_a' (used by model node 'fab_cell'): {error}". El nested_model_id del ModelNode debe aparecer en la lista imported_models[] del padre. Los campos de mapeo (input_mappings, output_mappings, resource_mappings, topic_mappings, state_variable_mappings) todos se resuelven contra objetivos reales.

​

Duración de la simulación

La duración máxima de simulación es 365 días. El esquema no lo impone — es una regla a nivel de capa de validación. Los modelos con duraciones más largas fallan la captura aunque el JSON en sí esté bien formado.

​

Fuentes sin lógica de llegada

Una Source no requiere tener un campo arrival_logic. Tres modos de llegada independientes pueden coexistir en la misma Source: llegadas estocásticas de arrival_logic, liberaciones programadas desde el material_releases[] de un calendario, y liberaciones dirigidas por eventos desde acciones release en Event Hooks o Listeners. Una Source sin arrival_logic, sin liberaciones de material del calendario y sin acciones release no tiene forma de producir entidades — eso es un modelo sin operación, no un error de validación. El validador lo permite porque es un estado intermedio legítimo durante la autoría.

​

Lo que la validación NO detecta

La validación detecta corrección estructural y a nivel de tipo. Algunas clases de problemas se filtran:

• Corrección semántica. Un modelo que compila y se ejecuta aún puede codificar suposiciones equivocadas sobre tu operación. La validación no puede decirte que un proceso de 30 segundos debería ser realmente de 30 minutos.
• Patrones de inanición de recursos. Un modelo donde un recurso crítico está retenido para siempre por una entidad atascada valida bien pero produce resultados sin sentido. Lee los resultados de la ejecución para detectar estos.
• Diseño sensato de Monte Carlo / experimento. La validación se ejecuta en un solo modelo; no razona sobre si tu barrido de instantáneas es estadísticamente informativo.
• Rendimiento. Un modelo válido aún puede tomar mucho tiempo para ejecutarse. Usa Instantáneas (Snapshot) y Duraciones cortas para iterar rápido.

El validador es una puerta de corrección estructural, no una prueba de corrección.

​

La validación y Dexter

La validación se aplica también a los cambios que Dexter hace. Cuando Dexter modifica tu modelo, se ejecutan las mismas reglas. Si Dexter intenta configurar un componente que fallaría la validación, la plataforma rechaza el cambio y Dexter tiene que reintentar o pedirte que aclares. Este es uno de los mecanismos que evita que Dexter corrompa silenciosamente un modelo en funcionamiento. Si Dexter está fallando repetidamente al aplicar un cambio, verifica los errores de validación tú mismo — a menudo la corrección es una pequeña corrección que Dexter no pudo inferir (una constante faltante, un nombre de atributo que no existe en el tipo de entidad) y decirle a Dexter el hecho específico lo desbloquea. El botón Fix with Assistant es el mismo canal a la inversa: le da a Dexter el texto exacto del error para que no tenga que adivinar.

​

Consejos

• Arregla primero los errores estructurales. Los errores de componentes desconectados a menudo ocultan errores de expresión que no pueden ejecutarse hasta que la estructura sea sólida.
• Los mensajes de error son específicos. Si un error es confuso, busca el texto del mensaje en los documentos — la mayoría de los errores de validación se mapean directamente a conceptos cubiertos en la referencia.
• La validación es rápida. Puedes hacer ediciones radicales y dejar que la validación las verifique — no necesitas ser quirúrgico.
• El botón rojo de reproducir es tu amigo. Es una función forzosa que te impide perder tiempo en una simulación que iba a fallar. Trata cada estado rojo como información, no como un obstáculo.