Modificar un código base con varios paquetes sin romper lo que ya funciona

## Antes de editar, averiguar qué paquete se encarga del cambio y sus reglas Antes de editar, identifica la raíz del repositorio, el paquete o subsistema responsable del comportamiento y las instrucciones aplicables para colaboradores más cercanas al área afectada. - Dirige el trabajo al ámbito correcto más reducido. - Lee las referencias locales de arquitectura, convenciones, compilación y pruebas necesarias para ese ámbito. - Usa una búsqueda dirigida para un solo símbolo y un gráfico de dependencias disponible para buscar llamadores entre archivos, imports, el impacto de un cambio de nombre o un radio de cambio amplio. - Confirma las versiones del entorno de ejecución y del gestor de paquetes, las definiciones del espacio de trabajo y los requisitos previos de compilación a partir de la configuración registrada en el control de versiones. - Trata los archivos de instrucciones enlazados o generados como vistas de la fuente que declaran como canónica; edita únicamente el archivo fuente. Si las instrucciones entran en conflicto o la responsabilidad no está clara, detente antes de escribir e indica el conflicto exacto. No modifiques paquetes no relacionados durante la investigación. ## Mantener el comportamiento y los nombres públicos actuales y respetar la arquitectura Evita perjudicar a los usuarios existentes. No cambies un valor predeterminado ni retires un nombre público a menos que el cambio aprobado lo exija expresamente. Mantén operativos los nombres heredados y acompaña la obsolescencia con una transición documentada y pruebas del comportamiento anterior. Respeta la arquitectura ya establecida por el repositorio: - mantén el comportamiento dentro de su capa propietaria o límite de extensión; - conserva la equivalencia entre adaptadores oficiales cuando cambie el contrato central; - preserva la configuración en cascada y los contratos públicos de personalización; - desinfecta el contenido controlado por el usuario y evita contaminar el espacio de nombres global; - admite los requisitos declarados de internacionalización y accesibilidad; y - prefiere las utilidades existentes y un mínimo de dependencias antes que mecanismos paralelos. Si un cambio incompatible es inevitable, indícalo de forma destacada, explica el contrato afectado y ofrece una ruta de migración. ## Hacer el cambio más pequeño posible, con pruebas y documentación Realiza el cambio coherente más pequeño que satisfaga el requisito. Sigue el estilo de código, comentarios y documentación establecido por el paquete. Para los cambios de comportamiento: 1. Añade o actualiza pruebas unitarias enfocadas. 2. Añade las pruebas de integración, navegador o extremo a extremo adecuadas cuando el comportamiento cruce un límite. 3. Ejecuta las compilaciones previas necesarias antes de probar los paquetes dependientes. 4. Ejecuta los comandos específicos de análisis de código, tipos, estilo y pruebas para el ámbito afectado. 5. Actualiza las guías públicas, las referencias de API, los ejemplos, las notas de migración o las entradas del registro de cambios cuando el usuario pueda percibir la modificación. 6. Actualiza las instrucciones para colaboradores del ámbito solo cuando el cambio cree una convención, ubicación, restricción o dificultad recurrente y duradera. No afirmes que el trabajo está completo si faltan las pruebas necesarias o la documentación dirigida al usuario. Registra cualquier prueba que no haya podido ejecutarse y el motivo concreto. ## Pedir aprobación antes de añadir dependencias y comprobar antes de publicar Obtén la aprobación de la persona responsable del mantenimiento antes de añadir una dependencia de terceros. Comprueba las licencias directas y transitivas, el estado de mantenimiento, las implicaciones de seguridad, el coste de empaquetado o ejecución y si el repositorio ya ofrece esa capacidad. Sigue las convenciones del repositorio para ramas, solicitudes de cambio, revisiones y registro de cambios. Mantén el historial de cambios fácil de revisar, evita reescribir el historial compartido y separa el trabajo no relacionado. Para trabajos de varios días, conserva un punto de control visible mediante el método de colaboración aprobado por el repositorio. Antes de publicar, confirma que las pruebas de compatibilidad cubren el comportamiento nuevo y el anterior, que la documentación necesaria está presente, que los artefactos generados están actualizados y que se han probado las variantes del paquete o los adaptadores previstos. ## Informar qué pruebas se ejecutaron y qué riesgos quedan Devuelve un informe de verificación conciso que enumere: - el comportamiento modificado y su ámbito; - los archivos o componentes afectados; - las pruebas, compilaciones y comprobaciones de código y tipos ejecutadas, con sus resultados; - las consideraciones de compatibilidad y seguridad; - las actualizaciones de documentación o del registro de cambios; y - cualquier elemento no ejecutado, el riesgo restante y la siguiente acción necesaria. Separa los resultados verificados de las suposiciones. Destaca cualquier cambio incompatible o comprobación obligatoria incompleta antes que los detalles secundarios.