Desarrolla un framework de flujos de datos en Rust para robótica e IA eligiendo las pruebas según el cambio

## Organiza el espacio de trabajo de Rust y reparte el entorno de ejecución en cuatro roles Organiza el sistema como un espacio de trabajo de Rust con bindings para Python, C y C++. Mantén en la raíz del espacio de trabajo la versión mínima de la cadena de herramientas y los metadatos compartidos de los paquetes, pero permite que los crates o ejemplos documentados explícitamente fijen versiones independientes. Utiliza cuatro funciones de ejecución con responsabilidades claras: - Un cliente de línea de comandos compila, inicia, detiene e inspecciona los flujos de datos. - Un coordinador administra el ciclo de vida distribuido entre máquinas. - Un daemon por máquina crea nodos y administra las comunicaciones locales y remotas. - Los nodos ejecutan el código del usuario como procesos, mientras que los operadores se ejecutan dentro del proceso cuando se necesita reducir la sobrecarga. Mantén las definiciones de mensajes y protocolos en una biblioteca compartida, el análisis de descriptores y las utilidades de compilación en una biblioteca central, y las API de cada lenguaje en paquetes separados. No permitas que los requisitos de compilación de los bindings contaminen las compilaciones normales exclusivas de Rust. ## Compila los bindings de lenguaje aparte del espacio de trabajo de Rust Compila el espacio de trabajo de Rust excluyendo los paquetes de bindings que requieran una herramienta de empaquetado independiente. Compila esos paquetes con su cadena de herramientas nativa de bindings en lugar de forzarlos a pasar por el comando normal del espacio de trabajo. Admite tres niveles de iteración: el espacio de trabajo completo, un paquete y un objetivo de prueba. Ejecuta comprobaciones, pruebas, lint y formato mediante los comandos canónicos del espacio de trabajo, e instala las herramientas locales de línea de comandos con las dependencias bloqueadas. Compila antes de ejecutar lint, pruebas, instantáneas de integración o comprobaciones de documentación. Los objetivos de ejemplo necesitan una comprobación explícita porque una comprobación general del espacio de trabajo podría no compilarlos. Conserva las pruebas rápidas de paquetes para iterar, pero vuelve al espacio de trabajo afectado completo antes de publicar. Si se añade un flujo de datos de ejemplo, ejecuta la suite de pruebas de humo de ejemplos en el modo de lenguaje compatible. ## Deja claros los tres patrones de comunicación y la regla de memoria compartida Define los flujos de datos de forma declarativa. Los nodos se suscriben a salidas con nombre y declaran sus propias salidas. Proporciona fuentes de temporización y mantén explícitas su frecuencia o intervalo en el descriptor. Conserva tres patrones de comunicación diferentes de cara al usuario: - Topic es el flujo predeterminado de publicación y suscripción. - Service es un patrón de solicitud y respuesta que correlaciona los mensajes mediante `request_id`. - Action representa objetivo, progreso, resultado y cancelación mediante `goal_id` y `goal_status`. Utiliza canales acotados con múltiples productores para enrutar eventos internos y un entorno de ejecución asíncrono para la coordinación. Utiliza un transporte distribuido de publicación y suscripción entre máquinas y un reloj lógico híbrido para el orden causal. Para el tráfico entre nodos locales, envía los mensajes de más de 4 KB mediante memoria compartida de copia cero y los mensajes más pequeños mediante TCP. Haz explícitos el umbral, la propiedad y el comportamiento alternativo; nunca combines la semántica de la memoria compartida local y la red remota en una única ruta sin documentar. ## Revisa y simplifica cada commit antes de pasar las pruebas Cada commit debe completar estos controles antes de publicarse: 1. Revisa el diff para detectar defectos estructurales, de seguridad y de lógica. 2. Simplifica la complejidad, duplicación e ineficiencia innecesarias. 3. Verifica el formato, ejecuta lint tratando las advertencias como errores, ejecuta al menos las pruebas del paquete afectado y ejecuta las pruebas del espacio de trabajo completo antes de publicar. 4. Compila los objetivos de ejemplo para que las roturas de firmas de API no queden ocultas fuera del grafo normal del espacio de trabajo. Utiliza un control local rápido antes de cada commit que incluya formato, lint, auditoría de dependencias, presupuesto de atajos inseguros y revisión tipográfica. Después ejecuta el comando completo de pruebas requerido antes de publicar. No omitas un control que haya fallado ni confíes en que la CI remota, más lenta, detecte el problema. Corrige el fallo y vuelve a ejecutar el control afectado. Conserva el orden: la revisión y la simplificación permiten corregir defectos de diseño a menor coste antes de las pruebas amplias. ## Elige las pruebas profundas según el riesgo en lugar de ejecutarlas en cada commit No ejecutes todas las suites profundas en cada commit ni las añadas todas a la CI de los pull requests. Selecciónalas según el alcance del cambio: - Utiliza la suite local completa, incluida la cobertura, antes de una publicación importante cuando se necesite más confianza. - Utiliza validación profunda con análisis de mutaciones y compatibilidad para cambios de alto riesgo o de Tier 1. - Utiliza una validación equivalente a la nocturna, de varias horas, para la cobertura multiplataforma, de propiedades, intérpretes, pruebas formales y extremo a extremo. - Utiliza el control de lanzamiento antes de la distribución; conserva la revisión de seguridad independiente, las pruebas de uso real y la validación de migraciones como controles separados dirigidos por personas. - Utiliza una auditoría de mutaciones completa solo para evaluar pruebas con calidad de lanzamiento o para una investigación específica, ya que puede tardar de 10 a 18 horas. - Ejecuta los flujos de datos de ejemplo de extremo a extremo después de cambiar las API de nodos, el comportamiento de comandos o los descriptores. - Ejecuta pruebas formales al modificar módulos sujetos a ellas y realiza la optimización guiada por perfiles en el sistema operativo y la arquitectura de destino, porque los perfiles no son transferibles. Trata la cobertura, las mutaciones, la compatibilidad, los ejemplos, la verificación formal y el perfilado de rendimiento como pruebas complementarias, no como sustitutos intercambiables. ## Mantén rápida la CI de las pull requests y deja los trabajos largos para la noche Mantén la CI de los pull requests lo bastante ligera como para ofrecer rápidamente resultados bloqueantes. Debe cubrir formato, lint con advertencias tratadas como errores, pruebas centrales, rutas de fallo extremo a extremo, contratos semánticos, regresiones de benchmarks, erratas, comprobaciones de la cadena de suministro, presupuestos de atajos inseguros y licencias. No amplíes la canalización bloqueante con tareas de varias horas. Programa por separado la validación amplia: - Ejecuta pruebas de plataforma en Linux, macOS y Windows. - Ejercita ejemplos, plantillas de línea de comandos, nodos de lenguajes dinámicos, benchmarks y compilación cruzada. - Cubre el ciclo de vida distribuido, la grabación y reproducción, la reconexión, la reconstrucción de estado, la afinidad de CPU, los backends de almacenamiento y los adaptadores puente. - Verifica el compilador mínimo compatible y cualquier harness de pruebas formales. Los fallos nocturnos deben generar una señal de regresión rastreable, pero no tienen por qué bloquear un pull request no relacionado. Antes de fusionar, ejecuta localmente las comprobaciones de plataformas no predeterminadas o de ejemplos cuando el cambio dependa de esas rutas. ## Escribe primero una prueba que falle y luego solo el código para que pase Todas las funciones nuevas y correcciones de errores siguen RED-GREEN-IMPROVE: 1. RED: escribe la prueba mínima que defina el comportamiento esperado y verifica que falla por la razón prevista. 2. GREEN: implementa solo el código necesario para que esa prueba pase. 3. IMPROVE: refactoriza manteniendo en verde las pruebas específicas y las del paquete afectado. Elige el primer nivel de prueba según el comportamiento. Empieza las funciones de biblioteca con pruebas unitarias, el comportamiento del coordinador o daemon con pruebas de integración, los cambios de comandos con pruebas de humo en red, las funciones de flujo de datos con pruebas de humo tanto en red como locales, y las correcciones de errores con la prueba de regresión más limitada que reproduzca el defecto. Cuando pase la prueba específica, ejecuta las pruebas del paquete afectado, lint tratando las advertencias como errores y las comprobaciones de formato. Si el cambio afecta al cliente de comandos, al coordinador o al daemon, ejecuta también las pruebas de humo en serie donde sea necesario aislar puertos o procesos compartidos. ## Pasa los ejemplos de flujos de datos por las pruebas de humo en red y en local Proporciona dos modos de pruebas de humo: - El modo en red inicia el entorno de ejecución distribuido, lanza un flujo de datos desacoplado, consulta hasta que termine y después detiene y desmonta el entorno. - El modo local ejecuta el flujo de datos en un solo proceso con un plazo de detención explícito. Los nuevos flujos de datos de ejemplo deben superar ambos modos. Comparte la costosa preparación de compilación mediante una protección de ejecución única en lugar de recompilar para cada prueba. Mantén las pruebas extremo a extremo del transporte de comandos y la tolerancia a fallos separadas de las pruebas unitarias normales. Las suites de humo deben limpiar procesos y puertos tanto al completarse correctamente como al fallar, para no contaminar pruebas posteriores. Excluye del conjunto de humo predeterminado los ejemplos que requieran hardware no disponible, entrada interactiva, una configuración de varias máquinas o cadenas de herramientas nativas no compatibles; documenta el límite de exclusión y proporciona una forma específica de ejecutarlos. ## Mantén los cambios acotados e informa exactamente qué controles se ejecutaron Aplica el formateador predeterminado del repositorio antes de enviar cambios. Debate los cambios de diseño no triviales mediante el canal de decisión del proyecto antes de implementarlos. No corrijas advertencias no relacionadas ni refactorices código ajeno al cambio. Mantén el parche acotado para que los fallos, la revisión y la reversión sigan siendo atribuibles. Trata los paquetes de lenguajes y los binarios de línea de comandos como superficies de distribución diferentes. Verifica para cada uno las comprobaciones adecuadas de paquete, bindings, compatibilidad y lanzamiento. Utiliza un perfil de lanzamiento optimizado solo después de superar los controles de corrección. El trabajo de rendimiento debe indicar la plataforma de destino y comparar una base reproducible con la compilación optimizada. Antes de la entrega, informa qué controles rápidos, completos, profundos, nocturnos, de ejemplos, de pruebas formales o de rendimiento se ejecutaron realmente y cuáles siguen sin verificar. Nunca insinúes que un nivel en verde demuestra que otro nivel también se superó.