Crea y actualiza una biblioteca de componentes de UI que siga las reglas de diseño

## Lee la especificación que rige cada tarea y sigue el código si la documentación no coincide Clasifica la tarea antes de editar y lee la fuente que la rige. - Para el comportamiento o las API de los componentes, lee la guía de la API pública, la implementación y un componente aprobado cercano. - Para los estilos, lee la especificación detallada de estilos, el archivo de tokens de tiempo de compilación, el archivo de tema de tiempo de ejecución y los estilos con ámbito adyacentes. - Para los cambios de compilación, lee la configuración de compilación y el contrato de cada plugin personalizado antes de modificar la canalización. - Para las pruebas, lee la configuración específica de pruebas y las pruebas cercanas; para la documentación, lee la matriz de sincronización. - Resuelve los conflictos en este orden: código fuente y configuración activa, reglas del repositorio, documentación especializada y, por último, experiencia general. - Cuando el código fuente y la documentación difieran, sigue el código fuente y corrige la documentación obsoleta dentro del mismo ámbito aprobado. - Trata las tablas de referencia rápida como indicaciones hacia las secciones autorizadas, no como copias independientes de las reglas. - Nunca inventes una API ni dependas de la memoria para comportamientos sensibles a la versión; verifica la versión instalada y la documentación incluida con ella. Antes de implementar, enumera las exportaciones, los estilos, las pruebas, los registros de demostraciones, los documentos y las invariantes de compilación afectados. ## Da a cada componente su propia carpeta con código, estilos y pruebas Asigna a cada componente una carpeta propia que contenga su implementación, su archivo de estilos con ámbito, su punto de entrada de exportación y su prueba unitaria ubicada junto al código. Añade por separado las exportaciones públicas de valores y de tipos, y registra cualquier superficie de demostración necesaria. - Usa componentes de función tipados, define los valores predeterminados mediante desestructuración de parámetros y establece un nombre de visualización estable. - Extiende los atributos del elemento nativo apropiado y omite únicamente los campos que entren en conflicto. - Mantén los nombres de componentes y tipos con el uso de mayúsculas y minúsculas canónico del repositorio, los archivos de estilo con el formato de nombre configurado y los nombres de clase con ámbito según la convención de clases configurada. - Conserva la comprobación estricta de null y las reglas de módulos aislados; evita vías de escape sin tipado y usa exportaciones explícitas solo de tipos. - Mantén los import al principio, usa los alias de proyecto configurados y no coloques selectores globales en estilos de componentes con ámbito. - Compón las clases mediante el mapa de estilos con ámbito o el auxiliar de clases aprobado, en lugar de escribir de forma fija los nombres de clase generados. - Mantén los auxiliares reutilizables centrados en una tarea y colócalos donde lo exija la convención del repositorio. No cambies la interfaz pública de un componente sin actualizar a la vez sus exportaciones, pruebas, ejemplos y documentación de la API. ## Usa valores de diseño comunes para colores y esquinas en lugar de valores sueltos Mantén capas de tokens separadas para funciones distintas: las variables de tiempo de compilación permiten cálculos y mixins, mientras que las propiedades personalizadas de CSS en tiempo de ejecución permiten que quienes consumen la biblioteca sobrescriban los temas. No trates ambas capas como intercambiables. - Mantén coherentes entre las configuraciones de compilación y de pruebas tanto la nomenclatura de CSS Modules como la inyección de tokens. - Prioriza los tokens semánticos de tiempo de ejecución en los estilos de los componentes; usa variables de tiempo de compilación solo cuando sea necesario el preprocesamiento. - Expresa el color, el foco, el radio, la elevación, la tipografía, el grosor y el movimiento mediante los roles semánticos del sistema, no mediante valores brutos aislados. - Evita los extremos puros y los valores predeterminados fríos y genéricos cuando el lenguaje de diseño defina superficies matizadas, texto cálido o estados de foco propios de la marca. - Conserva las siluetas deliberadas de los componentes, los tratamientos de estado y las reglas de sombra, en lugar de aplanarlos en un único patrón genérico. - Mantén las fuentes globales, las variables de tema y los restablecimientos detrás de un único punto de entrada de estilos globales. - Respeta las preferencias de movimiento reducido y conserva un foco visible, el uso mediante teclado, un contraste legible y los roles de accesibilidad documentados. Obtén los valores exactos y las excepciones específicas de cada componente de la especificación de diseño autorizada y del código fuente actual, nunca de la memoria. ## Prueba el teclado y la accesibilidad de cada componente Usa la configuración específica de pruebas del repositorio con el entorno DOM, los archivos de preparación, los comparadores, los alias y el procesamiento de CSS Modules que declare. No traslades la configuración de pruebas a una configuración de compilación que el ejecutor de pruebas activo ignore. - Ubica las pruebas junto a los componentes y utiliza las herramientas aprobadas de renderizado, consulta e interacción del usuario. - Cubre el renderizado, las clases controladas por props, las devoluciones de llamada, el comportamiento deshabilitado, los cambios de estado y los roles de accesibilidad pertinentes. - Ejercita el comportamiento del teclado con las teclas requeridas por el patrón del componente, incluidos el movimiento del foco, la activación, el cierre y el control direccional. - Comprueba las clases con ámbito mediante el mapa de estilos importado, no mediante literales de cadena generados. - Prueba las API imperativas invocándolas dentro del límite de estado del framework de pruebas y esperando su resultado montado; no renderices como JSX una API que no sea un componente. - Centraliza las herramientas de prueba compartidas y utiliza interacciones de usuario realistas en lugar de atajos de eventos de bajo nivel. - Cumple los umbrales de cobertura configurados y documenta cualquier exclusión intencional, en vez de inflar la cobertura con casos de poco valor. Para un defecto, ejecuta primero una prueba enfocada que falle; después, el conjunto afectado y, por último, todo el conjunto obligatorio antes de finalizar. ## Mantén la compilación modular para que solo se carguen los componentes usados Trata los plugins de compilación personalizados, las exportaciones de paquetes y las reglas de recursos como contratos con quienes consumen la biblioteca. - Conserva salidas separadas para ES-module y CommonJS, con los límites de módulo intactos, para que los componentes no utilizados sigan siendo eliminables mediante tree shaking. - Mantén como external el framework y los paquetes auxiliares aprobados cuando sean peer dependencies; no añadas runtime dependencies sin un requisito explícito. - Conserva la división de código CSS y el mecanismo que asocia los estilos de cada componente a su punto de entrada de JavaScript. - Mantén completo el punto de entrada de la hoja de estilos global e impide a la vez que los recursos de componentes no utilizados entren en los bundles de los consumidores. - Sigue la política del repositorio para copiar e integrar recursos, incluidos los requisitos de formato de fuente y public path. - Mantén los mapas de exportación del paquete, los archivos publicados y las declaraciones de efectos secundarios alineados con la estructura generada. - Modifica la lógica de compilación únicamente después de leer los contratos de los plugins personalizados y verifica después tanto los import a nivel de componente como el punto de entrada de estilos globales. Los directorios generados de distribución, compilación de demostraciones y cobertura son resultados, no superficies de edición, y no deben incluirse en un commit salvo que la política del repositorio lo exija de forma explícita. ## Actualiza la documentación y las demostraciones cada vez que cambie un componente Actualiza todas las superficies autorizadas afectadas por un cambio de componente. - Los cambios de API o de props actualizan el manual de la API a partir del código fuente; los cambios de estilo actualizan la especificación detallada de estilos. - Los cambios del lenguaje visual actualizan el resumen de diseño, y los componentes nuevos actualizan el prompt orientado al usuario o la especificación del catálogo. - Los cambios en el número de componentes o en la cobertura actualizan todos los readme duplicados mediante el generador aprobado. - El registro de demostraciones puede estar repartido entre los metadatos de rutas, un mapa de renderizadores y un catálogo de la página principal; actualiza cada registro independiente. - Deriva los recuentos legibles por máquinas de los metadatos autorizados, en lugar de duplicarlos manualmente. - Ejecuta el comprobador de sincronización de documentación y entiende qué superficies de demostración o generadas no inspecciona. - Regenera los artefactos sometidos a control de versiones mediante el comando aprobado, en lugar de editar directamente el resultado generado. Después de cambiar los registros, comprueba que seleccionar la ruta de demostración renderice la página prevista; un menú resaltado con el área principal vacía suele indicar que falta una entrada de registro. ## Evita fallos conocidos como reemplazos masivos y páginas de demostración en blanco Usa operaciones acotadas y verificables para los cambios que puedan corromper muchos archivos sin dar señales evidentes. - Para reemplazos mediante scripts, verifica de inmediato cada objetivo, ten en cuenta que las operaciones sobre cadenas son inmutables y evita patrones que fallen al atravesar marcado entre comillas. - Cuando una herramienta de pruebas escriba un resultado estructurado, proporciona la ruta de destino requerida en vez de suponer que existe un archivo predeterminado. - Para capturas de DOM a imagen, integra las declaraciones de fuentes necesarias en la raíz de captura cuando el motor de renderizado no pueda leer el registro de fuentes del documento. - No refactorices dependencias internas deliberadas de los componentes solo para mejorar una métrica superficial de tree shaking. - Optimiza el tamaño del paquete conservando los import bajo demanda e impidiendo que recursos grandes, fuentes y componentes no utilizados entren en los bundles de los consumidores. - Diagnostica las páginas de demostración en blanco comprobando cada registro de página independiente antes de cambiar la implementación del componente. Convierte cada fallo recurrente confirmado en una comprobación automatizada y enfocada cuando el repositorio proporcione un lugar estable para ella. ## Pasa todas las comprobaciones de CI antes de entregar el cambio Ejecuta la comprobación documentada del formateador, lint, las pruebas unitarias y la compilación de la biblioteca en el orden exigido por el repositorio. Ejecuta el comando completo de CI antes de proponer una contribución. Confirma que: - todos los componentes, las exportaciones, las pruebas, la documentación y los registros de demostraciones modificados estén sincronizados; - las insignias de cobertura o número de componentes se hayan regenerado cuando hayan cambiado sus datos de entrada; - ninguna runtime dependency ni resultado generado sin aprobar haya entrado en el cambio; - los contratos de salida modular, división de CSS y carga de recursos sigan vigentes; - el cambio visual coincida con las especificaciones actuales de tokens y componentes; - la diferencia final contenga únicamente los cambios previstos en el código fuente y la documentación. Si falla cualquier comprobación obligatoria, corrige el fallo y vuelve a ejecutar el control correspondiente antes de presentar la diferencia. Usa el formato de contribución del repositorio y ejecuta los flujos de lanzamiento o publicación solo cuando la tarea los incluya explícitamente. Informa de las comprobaciones exactas ejecutadas y de cualquier comprobación más amplia que se haya dejado fuera del alcance de manera intencional.