Haz cambios pequeños en una biblioteca de interfaz con estado sin romper a quienes la usan

## Encuentra al dueño del estado y cámbialo solo donde la biblioteca lo permite Empieza por localizar al propietario del estado, el límite de actualización y el contrato público afectados por la solicitud. En un modelo de estado inmutable, lee desde una instantánea coherente y modifica el estado únicamente dentro del contexto de actualización autorizado por la biblioteca. Trata los identificadores de nodos o entidades como referencias versionadas; no mantengas suposiciones de mutabilidad entre límites de actualización. Mantén el registro de funcionalidades, los comandos, las transformaciones y los listeners dentro de su ciclo de vida documentado. Para el trabajo nuevo, prefiere el mecanismo actual de extensión o composición, pero conserva cualquier ruta de integración heredada que siga siendo compatible. Asegúrate de que cada registro tenga una vía clara de limpieza y conserva los formatos de serialización que los consumidores existentes todavía puedan cargar. ## Busca con herramientas que entienden la sintaxis y mantén el cambio pequeño Utiliza búsquedas y reescrituras sensibles a la sintaxis cuando un cambio afecte a imports, lugares de llamada, anotaciones de tipo o código estructurado. Las expresiones regulares orientadas a líneas pueden omitir formas multilínea y coincidir con identificadores no relacionados. Confirma las coincidencias candidatas en el árbol sintáctico antes de aplicar una reescritura amplia. Mantén el cambio centrado en el comportamiento y limitado a su ámbito. Usa nombres específicos del dominio, cláusulas de guarda para estados no válidos o ya gestionados y una ruta de éxito visible. Extrae funciones auxiliares solo cuando den nombre a una responsabilidad o simplifiquen al llamador. No mezcles refactorizaciones oportunistas, registros de depuración, nombres temporales ni ajustes de formato no relacionados en el parche final. Cuando se cree una factoría sin efectos secundarios en el ámbito del módulo, conserva la convención del proyecto para las anotaciones de tree shaking y actualiza la regla que la aplica si la propia familia de factorías se amplía. ## Mantén compatibles las API públicas y usa el document y window del propio elemento Da por hecho que el código externo depende de los nombres públicos, las firmas, el comportamiento y los datos serializados existentes. Prefiere las API aditivas y los parámetros opcionales. Cuando un cambio incompatible sea inevitable, conserva y marca como obsoleta la ruta anterior antes de retirarla, y verifica tanto la ruta actual como la de compatibilidad. Mantén todos los sistemas de tipos compatibles y todas las superficies de declaraciones generadas que la API afecte. El código destinado al navegador debe obtener el document y el window propietarios a partir de la raíz o del elemento correspondiente, en vez de depender de objetos globales del entorno. Usa funciones auxiliares que tengan en cuenta el contexto para la selección, el foco, el objetivo de eventos y el recorrido de elementos padre, de modo que las raíces de sombra y los documentos incrustados no lean silenciosamente del entorno equivocado. En cambios relacionados con serialización, gestión de solicitudes, URL, salida HTML o de scripts, rutas del sistema de archivos, autenticación o dependencias, identifica la entrada no confiable y la validación más cercana que la protege. Prefiere un comportamiento que deniegue por defecto ante fallos, mantén los secretos fuera de los registros y artefactos, y verifica tanto el lado escritor como el lector de cualquier protocolo. ## Escribe primero una prueba que falle y elige entre prueba unitaria o en navegador real Para un cambio de comportamiento o una corrección de errores, define primero el invariante observable. Añade o actualiza la prueba enfocada más cercana, ejecútala antes de la implementación cuando sea viable y confirma que falla por el motivo esperado. Realiza el cambio mínimo que la satisfaga, vuelve a ejecutar la prueba enfocada y amplía después únicamente a la verificación exigida por la superficie afectada. Usa pruebas unitarias con un entorno simulado para la lógica que no dependa del diseño real ni del comportamiento de selección. Usa pruebas en un navegador real para el diseño, la selección, el foco, las raíces de sombra o el comportamiento entre documentos. Reserva las pruebas de extremo a extremo para la navegación, la integración completa de la aplicación o los protocolos que requieran un sistema en ejecución. Compila el artefacto específico que consume la prueba antes de confiar en su resultado. No sustituyas sin motivo una prueba enfocada por un comando amplio para todo el repositorio. Que pase un conjunto de pruebas no relacionado no demuestra el límite modificado. ## Revisa la diferencia y añade la nota de publicación antes de terminar Antes de terminar, revisa la diferencia como lo haría una persona que acaba de incorporarse al proyecto. Confirma que los nombres expresan el significado del dominio, los casos límite usan guardas explícitas, la ruta principal es legible, la limpieza está completa y ningún contrato público ha cambiado por accidente. Ejecuta el formateador, el linter, el comprobador de tipos o la tarea de instantáneas de API que exija el paquete afectado. Añade la nota de publicación o el registro de cambios establecido por el repositorio cuando cambie un comportamiento publicado. Describe la corrección o la función orientada al usuario, no los detalles de implementación. Mantén fuera del texto de commits y solicitudes de cambios los enlaces de sesiones privadas, las credenciales y las referencias exclusivamente internas, y registra las pruebas enfocadas que respaldan el cambio.