Cambiar una biblioteca de componentes de interfaz y comprobar que nada se rompa

## Ejecutar los comandos desde la raíz con el gestor de paquetes del repositorio Utiliza únicamente el gestor de paquetes y el estilo de comandos del espacio de trabajo que declara el repositorio. Ejecuta las operaciones limitadas a un paquete mediante el filtro de espacios de trabajo del gestor desde la raíz, en lugar de entrar en los directorios de paquetes e invocar otra herramienta. Instala dependencias solo cuando sea necesario. Durante la iteración, da preferencia al comando de compilación, prueba, análisis estático o comprobación de tipos con el menor alcance de paquete posible, y reserva las compilaciones de todo el repositorio para la verificación de integración o publicación. Mantén como flujos de trabajo distintos el desarrollo de la documentación, las compilaciones de paquetes, las compilaciones de documentación, las pruebas unitarias, las pruebas de navegador, las pruebas integrales, las pruebas de regresión visual, el formateo, el análisis estático y la comprobación de tipos. ## Poner los componentes nuevos en la zona experimental y no exponer los paquetes internos Divide la biblioteca en sus componentes principales, sistema de estilos, componentes experimentales, iconos o recursos, utilidades compartidas, abstracción del motor de estilos y paquetes internos no publicados. Respeta qué paquetes son públicos y cuáles existen únicamente para dar soporte al espacio de trabajo. Introduce los componentes nuevos o inestables en el área experimental designada antes de ascenderlos al paquete estable. Mantén los estilos compartidos y el comportamiento de los temas en la capa de estilos, en lugar de duplicarlos entre componentes. No expongas paquetes internos mediante puntos de entrada públicos ni eludas la abstracción configurada del motor de estilos con suposiciones específicas de la implementación. ## Ordenar los archivos de cada componente e importar solo lo necesario Sigue la disposición de archivos de componentes del repositorio para la implementación, las declaraciones, las pruebas, las clases de estilo y las exportaciones públicas. Mantén cada responsabilidad en su archivo propietario para que la documentación de la `API`, las pruebas y la eliminación de código no utilizado sigan siendo previsibles. Utiliza la forma de declaración exigida por el repositorio para las propiedades públicas de los componentes y exporta desde el módulo del componente una interfaz de propiedades con un nombre coherente. Conserva los alias de rutas y las convenciones de exportación pública. Utiliza importaciones de paquetes específicas y de un solo nivel dentro del espacio de trabajo cuando las importaciones generales desde archivos índice incluyan un paquete entero en el archivo agrupado. Trata la forma de importación como un contrato de rendimiento y empaquetado, no como una preferencia de estilo. ## Escribir errores que digan qué pasó y cómo arreglarlo Cada error lanzado desde un paquete público debe indicar qué ocurrió, por qué importa y qué puede hacer quien lo invoca para corregirlo. Utiliza el prefijo obligatorio de la biblioteca, una construcción legible del mensaje y un enlace a la documentación cuando exista una guía mantenida. Aplica el marcador de minificación de errores del repositorio a los constructores de errores compatibles, de modo que los paquetes de producción puedan sustituir los mensajes largos por códigos estables y el desarrollo siga siendo comprensible. Después de añadir o cambiar un error público, regenera el catálogo de códigos de error. Si la semántica y el número de argumentos no han cambiado, actualiza la entrada existente del catálogo en lugar de crear un código nuevo para el mismo contrato de error. ## Probar los componentes como un usuario que hace clic y escribe Utiliza el renderizador y las utilidades de aserción compartidos del repositorio para que las pruebas de componentes coincidan con el entorno compatible. Da preferencia a las consultas accesibles y las interacciones completas del usuario frente al envío de eventos de bajo nivel o la modificación directa de propiedades. Prueba el comportamiento observable, las transiciones de estado, las advertencias y los errores con los comparadores configurados. Mantén enfocadas las pruebas unitarias y utiliza filtros de nombres durante la iteración, sin confundir el resultado satisfactorio de una ejecución filtrada con una cobertura completa. Cuando una prueba requiera disposición, `API` del navegador o un comportamiento de representación que no esté disponible en un `DOM` simulado, limítala al entorno compatible de navegador real y documenta el motivo en la condición de la prueba. ## Desactivar las capturas de pantalla sin desactivar las comprobaciones de accesibilidad Ejecuta el análisis de accesibilidad dentro del ciclo de regresión de navegador establecido cuando el repositorio comparta esa sesión. Trata las capturas de pantalla y las aserciones de accesibilidad como controles independientes: una demostración puede desactivar uno sin desactivar implícitamente el otro. Mantén explícita la cobertura de las reglas de accesibilidad. Registra los resultados satisfactorios, fallidos e incompletos por demostración y regla, incluye las etiquetas aplicables del estándar de accesibilidad y conserva las aserciones obligatorias salvo que se configure una excepción de alcance limitado y debidamente justificada. No inicies un flujo de trabajo de navegador separado cuando el sistema integrado de regresión ya se encargue de la navegación, la representación, las capturas de pantalla y el análisis de accesibilidad. ## Ordenar las reglas de excepción para que omitir una demo no omita otras Compara la configuración de regresión con identificadores estables de demostración. Cuando las reglas utilicen precedencia de última coincidencia sin herencia, coloca las anulaciones de alcance limitado después de las reglas generales y vuelve a declarar todos los campos que la anulación deba conservar. Utiliza patrones específicos para demostraciones individuales y patrones más amplios únicamente para un grupo completo de componentes. Una regla que desactive una sola demostración no debe desactivar por accidente las demás ni heredar campos de excepción obsoletos. Regenera los resultados estructurados de accesibilidad y visuales después de cambiar las reglas. La integración continua debe rechazar los informes generados obsoletos en lugar de aceptar silenciosamente una configuración que nunca se haya ejercitado. ## Probar solo lo afectado mientras trabajas y ejecutar todas las pruebas antes de subir Limita las ejecuciones locales de regresión mediante el filtro de nombres del ejecutor de pruebas, para que las pruebas que no coincidan no naveguen por el navegador ni reescriban resultados no relacionados. Confirma que el filtro coincida con la ruta o el identificador de demostración incorporado en el nombre de la prueba. Ten en cuenta que una ejecución filtrada solo actualiza los informes de los componentes coincidentes. Antes de enviar los cambios, ejecuta el comando de regresión sin filtrar para que todos los informes, capturas de pantalla y resultados de accesibilidad estén actualizados. Mantén el servidor de regresión y el ejecutor como procesos separados cuando el flujo de trabajo del repositorio lo exija, y conserva la sintaxis documentada del gestor de paquetes para reenviar argumentos. ## Regenerar la documentación de la API y las demos al cambiar un componente Después de cambiar las propiedades de los componentes o las declaraciones de tipos, ejecuta los generadores de extracción de propiedades y documentación de la `API`. Revisa la diferencia resultante de la `API` pública junto con el cambio en el código fuente. Crea la demostración tipada designada como fuente de verdad y genera variantes en otros lenguajes mediante el formateador o convertidor compatible. No edites manualmente una variante de demostración generada como única solución. Cuando cambien las demostraciones o `Markdown`, ejecuta las comprobaciones correspondientes de generación de demostraciones, compilación de documentación, estilo de prosa y gramática. Conserva las guías especializadas de integración en módulos locales de instrucciones autónomos y carga el pertinente para trabajos de estilos, temas, representación o integración con marcos de trabajo. ## Hacer las comprobaciones que pide el cambio e informar de las que faltan Antes de la revisión, formatea los archivos modificados, ejecuta el análisis estático y la comprobación de tipos, realiza pruebas unitarias específicas y amplía a comprobaciones de navegador real, integrales, visuales, de accesibilidad, de documentación de la `API` o de prosa según el comportamiento afectado. Verifica los códigos de error generados, las referencias de la `API`, las variantes de demostración, las capturas de pantalla y los informes de accesibilidad cuando cambien sus fuentes. Informa de cualquier barrera bloqueada o no ejecutada en lugar de presentar una verificación parcial como completa. Mantén la revisión centrada en el componente y utiliza el formato de título de cambio exigido por el repositorio: un ámbito estable del componente o la documentación seguido de una descripción en imperativo.