# NEXUS-24 — Prueba de razonamiento espacial, temporal y alg...

Prompt

# NEXUS-24 — Prueba de razonamiento espacial, temporal y algorítmico ## 1. Tu misión Construye una aplicación visual interactiva llamada **NEXUS-24**, que represente un sistema futurista de coordinación de tres robots autónomos dentro de una instalación científica. Los robots deben atravesar una cuadrícula con obstáculos, puertas de acceso que se abren y cierran periódicamente, destinos intermedios obligatorios y conflictos potenciales entre sus trayectorias. **Tu objetivo no es simplemente dibujar una simulación: debes calcular una solución válida, demostrar que cumple todas las restricciones y representarla visualmente.** La entrega debe ser un único archivo HTML autocontenido, con CSS, JavaScript y gráficos SVG integrados. No puedes utilizar librerías externas, frameworks, CDN, imágenes ni servicios remotos. Tu solución debe ejecutarse directamente en un navegador moderno. --- ## 2. Definición matemática del entorno El entorno consiste en una cuadrícula de 9 × 9 celdas. Las coordenadas son `(x,y)`, con `x,y ∈ {0,...,8}`. El origen `(0,0)` está en la esquina superior izquierda; el eje Y aumenta hacia abajo. Un robot puede ocupar una celda si está dentro del tablero, no pertenece al conjunto de obstáculos y, cuando corresponda, satisface la condición temporal de su puerta. ### 2.1. Obstáculos Construye el conjunto de obstáculos a partir de estas dos reglas: - Muro vertical: todas las celdas `(4,y)`, excepto cuando `y = 2` o `y = 6`. - Muro horizontal: todas las celdas `(x,4)`, excepto cuando `x = 2` o `x = 6`. La celda `(4,4)` es un obstáculo. Las cuatro aberturas resultantes contienen puertas temporizadas. El resto de las celdas no bloqueadas son transitables. ### 2.2. Puertas temporizadas Una puerta únicamente puede estar ocupada por un robot en un instante entero `t` si cumple su regla de apertura. | Puerta | Coordenada | Condición de apertura | |---|---|---| | G-N | `(4,2)` | `t mod 6 ∈ {0,1,2}` | | G-S | `(4,6)` | `t mod 6 ∈ {3,4,5}` | | G-O | `(2,4)` | `t mod 4 ∈ {0,1}` | | G-E | `(6,4)` | `t mod 4 ∈ {2,3}` | Las puertas tienen capacidad para un solo robot, como cualquier otra celda. Una puerta puede atravesarse en cualquier dirección. No se permite ocupar una puerta cerrada, ni siquiera permaneciendo inmóvil sobre ella. La condición de apertura se evalúa en cada instante entero de ocupación, incluido el instante de llegada. ### 2.3. Robots y misiones Existen tres robots: | Robot | Posición inicial | Punto intermedio obligatorio | Destino final | |---|---|---|---| | A | `(1,1)` | `(7,1)` | `(7,7)` | | B | `(7,1)` | `(1,1)` | `(1,7)` | | C | `(1,7)` | `(7,7)` | `(7,1)` | Cada robot debe alcanzar primero su punto intermedio y posteriormente su destino final. Una vez completada su misión, permanece inmóvil en el destino final hasta que termine la simulación. Los tres robots comienzan simultáneamente en `t = 0`. --- ## 3. Reglas estrictas de movimiento En cada transición de `t` a `t+1`, cada robot debe realizar exactamente una de estas acciones: - Avanzar una celda hacia arriba. - Avanzar una celda hacia abajo. - Avanzar una celda hacia la izquierda. - Avanzar una celda hacia la derecha. - Permanecer inmóvil. Están prohibidos los movimientos diagonales y los saltos. ### Restricciones de seguridad **R1.** Dos robots nunca pueden ocupar la misma celda durante el mismo instante entero. **R2.** Dos robots no pueden intercambiar directamente sus posiciones durante una misma transición. Si A pasa de `p` a `q`, B no puede pasar simultáneamente de `q` a `p`. **R3.** Ningún robot puede atravesar ni ocupar obstáculos. **R4.** Ningún robot puede ocupar una puerta mientras esté cerrada. **R5.** Todos los puntos intermedios deben visitarse antes de completar sus respectivos destinos. **R6.** La secuencia de posiciones debe cumplir la regla de movimiento en absolutamente todas sus transiciones. **R7.** Los tres robots deben haber completado sus misiones en un horizonte global `T ≤ 24`. El valor `T` es el último instante entero del plan, no el número de posiciones almacenadas. Por tanto, un plan de `T = 24` contiene 25 estados, desde `t = 0` hasta `t = 24`. ### Objetivo de optimización Primero encuentra un plan factible que satisfaga R1–R7. Después intenta minimizar, por orden: 1. El horizonte global `T` (makespan). 2. El número total de acciones de espera anteriores a la finalización individual de cada robot. La optimización es secundaria a la corrección. Nunca declares una solución óptima sin evidencia que lo justifique. --- ## 4. Razonamiento algorítmico obligatorio Implementa un planificador real en JavaScript. Puedes utilizar búsqueda A*, búsqueda en espacio-tiempo, planificación conjunta, backtracking, planificación por prioridades con retroceso o cualquier enfoque técnicamente fundamentado. Sin embargo: - **Está prohibido introducir manualmente secuencias de rutas precalculadas.** - Las trayectorias deben calcularse en tiempo de ejecución a partir de los datos del problema. - El algoritmo debe considerar explícitamente el tiempo, las aperturas de puertas, la ocupación simultánea y los intercambios prohibidos. - Si un intento de planificación fracasa, debes comunicarlo o intentar alternativas; nunca presentar una ruta inválida como correcta. - El planificador debe producir una trayectoria indexada temporalmente para cada robot, con posiciones definidas para todos los instantes `0...T`. El resultado computado será la única fuente de datos tanto para la visualización como para la reproducción. No se aceptan animaciones decorativas que no representen las trayectorias calculadas. --- ## 5. Sistema de visualización SVG Diseña una interfaz de calidad profesional, inspirada en paneles de control aeroespaciales y sistemas avanzados de supervisión industrial. La estética será oscura, técnica y sofisticada: grafito, negro obsidiana, líneas de precisión, iluminación sutil y tipografía legible. ### A. Tablero espacial El SVG principal debe representar: - Las 81 celdas de la cuadrícula. - Los muros y sus discontinuidades. - Las cuatro puertas temporizadas y sus estados actuales. - Los tres robots, identificados inequívocamente. - Sus puntos intermedios y destinos finales. - Sus trayectorias, con diferenciación visual entre desplazamiento y espera. Utiliza estos colores de identificación: - Robot A: cian. - Robot B: magenta. - Robot C: ámbar. Diferencia los robots mediante su geometría o iconografía, no únicamente mediante colores. ### B. Animación física coherente Los robots deben desplazarse suavemente entre las coordenadas de los estados enteros mediante interpolación visual. Sin embargo, **la interpolación no modifica la lógica discreta**: las reglas de colisión y puertas se verifican en los instantes enteros definidos. No inventes estados intermedios de la planificación ni elimines pasos de espera para mejorar artificialmente la animación. El color y el estado visual de cada puerta deben corresponder al instante entero actualmente seleccionado. ### C. Línea temporal Debajo del tablero, incluye una línea temporal sincronizada con la simulación. Debe visualizar: - El horizonte total. - El instante actual. - La actividad individual de los robots. - Los periodos de desplazamiento y espera. - La llegada a los puntos intermedios. - La finalización de cada misión. El usuario debe poder seleccionar un instante y observar el estado exacto del sistema en ese momento. ### D. Panel de telemetría Muestra valores reales derivados de las trayectorias: - Horizonte `T`. - Movimientos totales. - Esperas totales antes de completar misiones. - Estado de cada robot. - Estado de las cuatro puertas. - Número de infracciones detectadas por el validador. No presentes métricas ficticias ni números decorativos. --- ## 6. Interactividad obligatoria Implementa controles funcionales para: 1. Iniciar y pausar la reproducción. 2. Avanzar y retroceder exactamente un instante entero. 3. Reiniciar la simulación. 4. Cambiar la velocidad entre 0.5×, 1× y 2×. 5. Seleccionar cualquier instante mediante la línea temporal. 6. Cambiar entre el escenario BASE y el escenario ALTERADO. Todos los controles deben conservar la sincronización entre SVG, trayectoria, puertas, telemetría y línea temporal. ### Escenario ALTERADO: replanificación real Introduce una segunda configuración que modifica exclusivamente la puerta G-E, situada en `(6,4)`. Su nueva condición de apertura será: `t mod 4 ∈ {0,3}` Todas las demás reglas y objetivos permanecen inalterados. **Cuando el usuario cambie de escenario, el sistema debe volver a ejecutar el planificador.** No puedes reutilizar ciegamente las rutas del escenario BASE. Ambos escenarios deben intentar satisfacer las mismas restricciones, incluido `T ≤ 24`. --- ## 7. Verificador independiente Este es uno de los requisitos más importantes. Implementa una función de verificación separada del planificador que examine las trayectorias finales desde cero. No debe confiar en que el algoritmo de planificación haya aplicado correctamente las reglas. El verificador debe comprobar: - Posiciones iniciales. - Visita ordenada a los puntos intermedios y finales. - Movimientos válidos entre estados consecutivos. - Permanencia dentro del tablero. - Ausencia de ocupación de obstáculos. - Estados correctos de las puertas. - Ausencia de colisiones entre robots. - Ausencia de intercambios de posiciones prohibidos. - Permanencia de los robots en su destino después de finalizar. - Cumplimiento del horizonte máximo. Si encuentra una infracción, debe comunicar **qué regla falló, qué robot o robots están implicados y en qué instante ocurrió**. El indicador global de éxito solo puede mostrarse cuando el verificador independiente devuelve cero infracciones y todas las misiones se han completado dentro del horizonte permitido. Nunca ocultes un fallo del planificador ni sustituyas una solución imposible por una animación aparentemente válida. --- ## 8. Requisitos de ingeniería - Todo debe existir en un único documento HTML. - Utiliza SVG nativo para el tablero y los elementos visuales principales. - El código debe funcionar sin acceso a Internet. - Separa claramente los datos del escenario, la planificación, la validación, la gestión del estado y la representación visual. - Evita variables globales innecesarias y duplicaciones de lógica. - Implementa una gestión explícita del fracaso de planificación. - Los controles deben funcionar sin recargar la página. - La reproducción debe mantener coherencia temporal aunque el navegador experimente retrasos de renderizado. - Evita fugas de estado o reproducciones simultáneas cuando se cambie de escenario. - La interfaz debe adaptarse a diferentes tamaños de ventana. --- ## 9. Criterios de aceptación Tu implementación será considerada satisfactoria únicamente si: 1. Encuentra al menos una solución válida para el escenario BASE dentro de 24 pasos. 2. Encuentra al menos una solución válida para el escenario ALTERADO dentro de 24 pasos. 3. Un verificador independiente confirma todas las restricciones. 4. La representación SVG coincide con las trayectorias calculadas. 5. Los controles modifican correctamente la simulación. 6. No existen rutas precalculadas introducidas como respuesta fija al problema. Una entrega visualmente impresionante pero matemáticamente inválida no supera la prueba. Una entrega que afirma haber encontrado una solución pero que no implementa realmente el planificador tampoco la supera. --- ## 10. Formato de entrega Devuelve **exclusivamente un bloque de código HTML completo**, que comience con `<!DOCTYPE html>`. No incluyas explicaciones, pseudocódigo, instrucciones de instalación, dependencias externas ni promesas de funcionalidades futuras. Resuelve el problema e implementa el sistema completo. **Prioriza la corrección algorítmica sobre la complejidad decorativa, pero aspira a una visualización profesional.**

A system prompt was added to support web rendering