Modificar el monorepositorio de una plataforma de trabajos distribuidos y probarlo con servicios reales

## Ejecutar comandos desde la raíz y elegir la comprobación según el tipo de paquete Ejecuta los comandos del espacio de trabajo desde la raíz del repositorio mediante el envoltorio fijado del gestor de paquetes. Compila las dependencias necesarias antes de iniciar una aplicación o herramienta de línea de comandos y usa filtros del espacio de trabajo para limitar el trabajo al grafo de paquetes afectado. Sigue exactamente la política del repositorio para instalar dependencias. Si exige editar las declaraciones de los paquetes antes de la instalación, hazlo en vez de invocar un comando de adición que eluda la elección revisable de versiones. Elige la verificación según la función del paquete: - Las aplicaciones y los paquetes privados usan comprobación estática de tipos cuando su compilación no demuestra la corrección. - Los paquetes publicados usan su compilación real de paquete para ejercitar las exportaciones y los artefactos generados. - Los cambios importantes, los archivos nuevos, el trabajo con esquemas y las refactorizaciones amplias reciben una verificación local de tipos o de compilación. - Las ediciones minúsculas pueden depender de comprobaciones específicas y de la integración continua cuando el proyecto lo permita explícitamente. No ejecutes una compilación amplia solo porque te resulte familiar. Usa la comprobación que pueda fallar realmente en la capa modificada. ## Probar colas y bases de datos con contenedores de servicios reales, no con mocks Ubica las pruebas junto al código fuente y usa el único ejecutor de pruebas admitido por el repositorio. Empieza por el paquete afectado o por un archivo de prueba, y compila primero sus dependencias solo cuando lo exija el espacio de trabajo. No reemplaces las bases de datos, las colas ni las cachés por simulaciones cuando el proyecto proporcione contenedores de servicios desechables. Usa auxiliares de prueba aislados que proporcionen opciones de conexión reales y un estado limpio para: - El comportamiento de colas y cachés. - Las transacciones relacionales y las migraciones. - Los flujos de trabajo combinados que crucen límites de almacenamiento. Reserva un límite unitario ligero para las funciones puras. Para el comportamiento de la infraestructura, prefiere un servicio real controlado que mantenga visibles la serialización, la temporización, los reintentos y la semántica de las transacciones. Ejecuta el formateo y las correcciones automáticas del analizador antes de la comprobación final de solo lectura. Prefiere las importaciones estáticas; usa carga dinámica únicamente para un ciclo inevitable, un beneficio medido de división del código o una condición auténtica del tiempo de ejecución. ## Registrar los cambios de paquetes publicados y fijar una sola versión para las dependencias compartidas Añade un registro de cambio versionado siempre que cambie un paquete publicado o una integración. Usa de forma predeterminada una versión de parche para correcciones y pequeños cambios compatibles, confirma una versión menor con los responsables de mantenimiento y nunca elijas una versión mayor sin aprobación explícita. Para el comportamiento exclusivo del servidor que no cambie ningún paquete publicado, usa el mecanismo de notas de cambio del servidor en vez de un registro de versión de paquete. Escribe las descripciones de la publicación para los usuarios: - Empieza por el comportamiento que cambió. - Usa una sola oración sencilla cuando sea posible. - Omite los nombres internos de herramientas, colas, almacenes y despliegues. - No describas la implementación como si fuera el beneficio. Mantén las dependencias compartidas deliberadamente en una única versión exacta en todo el espacio de trabajo cuando la identidad de los tipos en tiempo de ejecución dependa de ello. Antes de añadir una dependencia así, encuentra la versión fijada existente y haz que coincida exactamente; los intervalos o las versiones paralelas pueden volver incompatibles los esquemas de un paquete con quienes los consumen desde otro. ## Seguir la ruta de la solicitud antes de mover trabajo entre capas Comprende la ruta de la solicitud antes de editarla: 1. Una solicitud externa entra en la API y en la aplicación del panel. 2. Los servicios validan la intención y llaman al motor del ciclo de vida de las ejecuciones. 3. El motor persiste el estado y encola el trabajo. 4. Un supervisor reclama el trabajo y gestiona su ejecución aislada. 5. Los resultados vuelven a través del motor del ciclo de vida. 6. El estado transaccional y los eventos analíticos fluyen hacia sus almacenes separados. Mantén los SDK públicos, las herramientas de línea de comandos, los tipos compartidos, las extensiones de compilación, los enlaces del cliente, los procesos de las colas, las bases de datos, la analítica, la planificación y los motores de ejecución en los paquetes que tienen declarados. Importa los tipos públicos compartidos mediante subrutas admitidas y no desde raíces de paquete amplias cuando así lo exija el contrato de exportación. No traslades responsabilidades entre estas capas por conveniencia. Un cambio en la planificación, el encolado, la ejecución o la persistencia debe contemplar la transición de estado completa y la ruta de fallo. ## No reactivar el motor de ejecución retirado y rechazar a los clientes antiguos con un error limpio Cuando se haya retirado un motor antiguo, los nombres históricos de directorios o las enumeraciones de compatibilidad no demuestran que siga ejecutándose. Trata la documentación actual de la arquitectura y el grafo activo de paquetes como fuentes autorizadas. Nunca vuelvas a introducir la ruta retirada para satisfacer una rama o solicitud antigua. La gestión de compatibilidad puede reconocer una versión obsoleta solo para rechazarla o finalizarla correctamente con un error de cliente; no debe dirigir trabajo hacia código de ejecución inexistente ni convertir un rechazo esperado en un fallo del servidor. Antes de modificar el comportamiento de compatibilidad: - Sigue la selección del motor activo. - Confirma cómo se identifican los clientes obsoletos. - Conserva una semántica de errores clara. - Añade pruebas tanto para la ruta actual como para el rechazo de la versión retirada. Mantén las directrices versionadas del SDK y las reglas generadas para agentes en sus respectivas fases de mantenimiento específicas. No actualices los paquetes de instrucciones distribuidos a menos que la tarea los incluya explícitamente. ## Escribir tareas con el SDK público actual y actualizar la documentación cuando cambie Define las tareas duraderas mediante el punto de entrada actual del SDK público. No importes subrutas de versiones obsoletas ni reanimes una API de definición de trabajos desaconsejada. Una definición de tarea debe tener: - Un identificador estable. - Un contrato de entrada con tipos. - Una función de ejecución asíncrona. - Errores explícitos para entradas no válidas. - Un comportamiento idempotente o un límite de reintentos documentado para los efectos secundarios. Trata el código empaquetado en imágenes de ejecución de clientes como código público de tiempo de ejecución, incluso cuando proceda del paquete de línea de comandos. Verifica conjuntamente las exportaciones del paquete, las dependencias incluidas y el comportamiento del contenedor. Actualiza la documentación pública y los ejemplos cuando cambie el contrato del SDK. Mantén la documentación del producto en el sitio designado y sigue las reglas locales de formato y navegación de ese sitio. ## Ejecutar una tarea real de principio a fin con una build local Usa un proyecto de referencia mantenido para probar los cambios del SDK y de la plataforma frente a una compilación local. Enlaza el proyecto de referencia con los paquetes del espacio de trabajo en vez de probar por error un paquete publicado. Ejecuta el flujo en este orden: 1. Inicia los servicios necesarios de almacenamiento y colas. 2. Aplica las migraciones de la base de datos y carga datos iniciales para la organización y el proyecto de referencia. 3. Compila el SDK, la herramienta de línea de comandos y los paquetes afectados. 4. Inicia la aplicación de la API en segundo plano y verifica su punto de comprobación de estado. 5. Inicia el proceso local de tareas desde el proyecto de referencia enlazado. 6. Espera una señal explícita de que el proceso está listo. 7. Activa una tarea representativa mediante la interfaz de control admitida. 8. Consulta periódicamente las ejecuciones o enuméralas hasta que aparezca el estado terminal esperado. 9. Inspecciona el resultado devuelto y el estado persistido de la ejecución. No informes de un éxito integral basándote únicamente en la compilación. Conserva la salida de los comandos o los identificadores de ejecución como evidencia y detén los procesos en segundo plano cuando termine la verificación. ## Fijar imágenes de contenedor multiplataforma y quitar las marcas de depuración antes de fusionar Fija las imágenes de contenedor a resúmenes de índice multiplataforma, no a resúmenes de imagen específicos de una arquitectura. Selecciona el resumen desde la página de publicación independiente de la plataforma de la imagen para que el desarrollo y la integración continua resuelvan la arquitectura correcta. Usa rastros estructurados de depuración mientras desarrollas flujos distribuidos: - Añade marcadores en las transiciones de estado, los límites de las colas y las llamadas externas. - Usa únicamente espacios de nombres de aplicación registrados; no inventes uno nuevo sin aprobación. - Limpia las trazas existentes antes de reproducir un error. - Consulta con límites y paginación mediante cursor. - Mantén los marcadores temporales en la rama de desarrollo mientras la investigación esté activa. - Elimina los marcadores y las importaciones antes de fusionar. Los revisores no deben señalar instrumentación temporal reconocida solo porque exista en la rama. Deben verificar que no pueda llegar a producción y que el paso de eliminación forme parte de la finalización. ## Ejecutar solo las comprobaciones que encajan con el cambio e informar de lo omitido Antes de la entrega, inspecciona el conjunto completo de archivos modificados y ejecuta solo las verificaciones aplicables: - Formateador, corrección del analizador y análisis de solo lectura. - Comprobación de tipos para aplicaciones y paquetes privados. - Compilaciones reales para paquetes publicados. - Pruebas específicas con contenedores de servicios desechables. - Un registro de cambio de paquete o una nota del servidor en el límite correcto. - Versiones compartidas de dependencias fijadas con exactitud. - Pruebas del motor actual y de la versión retirada cuando haya cambiado el enrutamiento. - Un resumen de imagen multiplataforma cuando hayan cambiado las referencias a imágenes. - Una ejecución con el proyecto de referencia enlazado cuando haya cambiado el SDK o el comportamiento de ejecución. - Eliminación de la instrumentación temporal de depuración antes de fusionar. Informa de qué se ejecutó, qué se superó y qué verificación se omitió deliberadamente, junto con su motivo. No afirmes la corrección del tiempo de ejecución, el paquete o el contenedor a partir de una comprobación más débil que no pueda observarlos.