Cambia un gran monorepo de plataforma y mantén sincronizados todos los clientes afectados

## Lee las reglas de la raíz y luego las instrucciones de cada carpeta Utiliza la raíz del repositorio como punto de coordinación y el archivo local de instrucciones más cercano como autoridad específica de la tarea. Aplica primero las reglas de la raíz y después añade las que mantiene cada directorio afectado, en lugar de suponer que las convenciones de un módulo rigen todo el cambio. En las áreas que no dispongan de un archivo local de instrucciones, utiliza como siguientes fuentes de verdad la guía de desarrollo mantenida más cercana, el `README` del módulo y el flujo de integración continua. Lee todas las guías aplicables antes de editar un cambio transversal. ## Averigua qué módulo se encarga de cada parte antes de editar Identifica qué módulos son propietarios del plano de control, los componentes de ejecución, las especificaciones públicas, las bibliotecas cliente, los recursos de despliegue, la interfaz de línea de comandos, las pruebas integrales, la documentación, los ejemplos y las propuestas de arquitectura. Remite el comportamiento del ciclo de vida y la configuración al propietario del plano de control; el comportamiento de los procesos de ejecución, a la guía de componentes más cercana; los cambios en esquemas públicos, al propietario de la especificación; la generación de clientes, al propietario de la biblioteca; el comportamiento de despliegue, a su operador o al propietario del empaquetado; y el comportamiento de los comandos, al propietario de la `CLI`. Cuando un cambio abarque un contrato, la implementación y los clientes, empieza por la especificación pública y carga después las guías de todos los consumidores afectados. Mantén las `API` de los componentes, las suposiciones de las pruebas y la integración del despliegue alineadas con el mismo contrato. ## Confirma el objetivo y cambia solo las líneas necesarias Declara las suposiciones, expón las ambigüedades y pide orientación cuando la solicitud admita interpretaciones contradictorias. Convierte el trabajo no trivial en criterios de éxito observables antes de implementarlo y detente cuando sea necesaria una decisión. Elige la solución más pequeña que satisfaga la solicitud. Evita las funciones especulativas, las abstracciones de un solo uso, la configurabilidad innecesaria, la refactorización no relacionada y la eliminación de trabajo preexistente. Modifica únicamente los archivos y las líneas que requiera la tarea, respeta el estilo local, añade o actualiza pruebas específicas cuando cambie el comportamiento e itera hasta que las comprobaciones pasen o quede explícito el obstáculo restante. ## Actualiza clientes y documentación cuando cambie la especificación pública Trata las especificaciones públicas como fuentes canónicas del contrato. Cuando cambie el comportamiento visible para el usuario, mantén sincronizados la especificación, la implementación, las bibliotecas cliente, la documentación, los ejemplos, la configuración, el comportamiento de los comandos y los artefactos de la versión. Cuando cambien las `API` de despliegue o los recursos del orquestador, actualiza o verifica también los manifiestos generados, los paquetes de despliegue, el comportamiento del controlador, la integración del servidor y la documentación operativa. No permitas que un contrato se aparte intencionadamente de una implementación sin aprobación explícita. Actualiza la documentación para usuarios y operaciones antes de la implementación o junto con ella, de modo que el comportamiento documentado siga siendo la promesa pública que rige. ## Corrige la fuente y vuelve a generar los archivos generados Nunca edites un resultado generado como única solución. Localiza y modifica el esquema canónico, la plantilla, la configuración o la entrada del generador y, después, regenera mediante el flujo admitido todos los clientes, manifiestos, materiales de referencia, ejemplos y artefactos empaquetados afectados. Revisa las diferencias generadas para detectar cambios inesperados y verifica los consumidores posteriores con el contrato regenerado. Mantén los adaptadores escritos a mano separados del código generado y conserva entre ambos el límite de propiedad definido por el repositorio. Si la regeneración está bloqueada, informa de la herramienta o el entorno que faltan y deja la fuente y los resultados derivados en un estado incompleto claramente identificado, en lugar de presentarlos como sincronizados. ## Pregunta antes de hacer cambios públicos incompatibles Da preferencia a los cambios aditivos y retrocompatibles para las `API` públicas, las interfaces de cliente, la configuración, los protocolos, el comportamiento de los comandos, los recursos de despliegue, las anotaciones, las etiquetas y los valores de los paquetes. Pregunta antes de introducir un cambio público incompatible, provocar una desviación intencionada del contrato o modificar un comportamiento visible sin una ruta de migración clara. Describe los consumidores afectados, el impacto en la compatibilidad, los requisitos de migración y las consecuencias para la versión antes de solicitar aprobación. Nunca ocultes un cambio incompatible tras una diferencia generada ni mezcles trabajo no relacionado de otros componentes en el mismo cambio. Mantén explícita la decisión de compatibilidad aprobada en la implementación, la documentación, las pruebas y las notas de la versión. ## Comprueba primero el alcance más pequeño y luego amplía Ejecuta, con alcance de archivo o paquete, formateadores, analizadores estáticos, pruebas unitarias, comprobaciones de contratos y aserciones sobre la salida de comandos antes de ampliar la validación. Extiéndela a compilaciones de integración, multilenguaje, despliegue o documentación cuando el cambio atraviese esos límites. Verifica la ayuda y la salida de los comandos junto con las pruebas de la `CLI`, los ejemplos de contratos junto con las comprobaciones de esquemas, el comportamiento de los clientes en todos los idiomas admitidos y la salida del despliegue en la plataforma afectada. Actualiza las pruebas específicas siempre que cambie el comportamiento o se corrija un fallo. Menciona en el traspaso final cada comprobación no ejecutada o bloqueada. No afirmes que el trabajo está completo mientras falle una comprobación obligatoria o mientras un consumidor afectado siga sin verificarse y no exista una limitación explícita. ## Guarda cada documento en un solo lugar y enlaza en vez de copiar Conserva las guías detalladas para usuarios y operaciones en el árbol de documentación designado. Reserva el `README` raíz como punto de entrada al repositorio y los `README` de paquetes publicables para la instalación, los inicios rápidos y los puntos de entrada a los paquetes. Mantén al mínimo los `README` de componentes internos cuando exista una página de documentación mantenida. Guarda los ejemplos ejecutables en el árbol de ejemplos y sus páginas explicativas en el árbol de documentación; utiliza los documentos de propuestas como autoridad y las páginas de la comunidad solo como índices cuando esa sea la convención del repositorio. Enlaza las políticas comunitarias y de desarrollo en lugar de duplicarlas. Da preferencia a los enlaces relativos a la versión desde los archivos del repositorio para que la documentación siga la rama o etiqueta actualmente seleccionada, y no utilices un sitio web público como única fuente desde el código versionado. ## Sigue las reglas de páginas del sitio de documentación y compila sin errores Utiliza el motor de documentación y la configuración del sitio estático establecidos, sin introducir generación durante la compilación que no esté documentada. Coloca las imágenes en el directorio público de recursos designado y haz referencia a ellas mediante la convención de rutas aprobada del sitio. Proporciona a cada página publicada los metadatos requeridos, usa el estilo configurado para enlaces internos y emplea enlaces completos al código fuente cuando enlaces fuera del árbol de documentación. Aplica de forma coherente las llamadas de atención, los grupos de código y las convenciones de navegación aprobados. Excluye del sitio publicado las instrucciones destinadas únicamente a colaboradores. Añade copias localizadas solo donde lo permita la política de localización y ejecuta la compilación de la documentación sin errores antes de considerar completos los cambios listos para publicar. ## Revisa los cambios incompatibles e informa de los riesgos pendientes Prioriza la revisión de cambios incompatibles en especificaciones públicas, interfaces de cliente, configuración, comportamiento de comandos, recursos de despliegue y protocolos. Señala los cambios innecesarios, incoherentes internamente, difíciles de implementar para los consumidores o que carezcan de una ruta de migración creíble. Comprueba si hay límites rotos de la fuente de verdad, vulneraciones de la arquitectura por capas, resultados generados obsoletos, pruebas ausentes, comportamiento no documentado o regresiones de compatibilidad. Separa los defectos confirmados de los riesgos no verificados y cita el contrato o consumidor afectado. Finaliza con un informe basado en pruebas que abarque las áreas modificadas, los consumidores sincronizados, las comprobaciones ejecutadas, la verificación bloqueada, las decisiones de compatibilidad y los riesgos restantes.