Escribe reglas en un repositorio de reglas de frontend y compruébalas antes de publicar

## Antes de cambiar una regla, distingue los archivos fuente editables de los generados Trata un repositorio de reglas de frontend como un producto compuesto por contenido fuente, esquemas, API, herramientas de revisión, páginas renderizadas e índices generados. Antes de modificarlo, identifica qué capa es responsable del comportamiento e inspecciona tanto esa capa como sus consumidores directos. - Traza el paquete de contenido, los tipos y esquemas compartidos, las superficies de la aplicación, el servidor de herramientas y los resultados generados. - Cuando estén disponibles, utiliza las herramientas de revisión y búsqueda de reglas del repositorio en vez de inventar directrices de memoria. - Revisa el código inspeccionado antes de recomendar correcciones y busca en el conjunto de reglas antes de afirmar algo sobre accesibilidad, rendimiento, SEO, seguridad, privacidad, internacionalización o pruebas. - Realiza auditorías amplias únicamente cuando la tarea requiera una auditoría amplia. - Distingue las fuentes editables de los artefactos generados y de las proyecciones renderizadas. Deriva las directrices de compatibilidad de la política de navegadores declarada y de datos respaldados por paquetes. No dependas de tablas de compatibilidad recordadas ni trates en silencio una vista generada como fuente canónica. ## Define los metadatos que toda regla debe tener Cada regla necesita un contrato estable de metadatos que permita analizar, buscar, puntuar, revisar y renderizar. Mantén el conjunto obligatorio lo bastante pequeño para aplicarlo de forma coherente. Los metadatos obligatorios deben incluir: - un título legible por personas entre comillas y una descripción de una sola oración; - una categoría, una prioridad y una dificultad permitidas; - una estimación entera del esfuerzo con una unidad declarada; - instrucciones prácticas para comprobar, corregir y explicar la regla. Entre los metadatos opcionales útiles se incluyen la subcategoría, conclusiones breves, impacto en usuarios o en el negocio, fuentes de evidencia, recursos complementarios, reglas relacionadas, herramientas, etiquetas, una instrucción para revisar código y contexto para la revisión automatizada. Valida las categorías y enumeraciones con las listas canónicas de valores permitidos. Pon entre comillas los valores que contengan puntuación con significado sintáctico. No añadas campos solo porque parezcan útiles; añádelos únicamente cuando los consuma el analizador, la interfaz, la capa de búsqueda o el generador. Las instrucciones deben nombrar el objeto que se inspeccionará y la corrección esperada. Rechaza marcadores de posición como «comprueba esta regla» que no aporten una estrategia de revisión ejecutable. ## Separa las evidencias, las lecturas extra y los enlaces a reglas relacionadas Mantén las evidencias autorizadas en metadatos estructurados de fuentes. Mantén las lecturas y herramientas opcionales en metadatos de recursos, y la navegación entre reglas en metadatos de reglas relacionadas. No sustituyas una función por otra. - Proporciona para cada regla al menos 2 fuentes pertinentes con 2 funciones de fuente distintas y al menos 1 autoridad primaria. - Utiliza identificadores estables para las evidencias cuando la canalización lo permita. - Mantén fuera del cuerpo las líneas genéricas «Véase también» y «Referencia». - Enlaza una herramienta con nombre en su primera mención significativa cuando aporte ayuda material y ya aparezca en los metadatos de recursos o herramientas. Los enlaces en línea deben respaldar una afirmación o una decisión de implementación concreta. Un valor predeterminado útil es de 2 a 5 enlaces por regla, con 0 o 1 en la introducción y de 1 a 3 en el cuerpo principal de las directrices. Mantén los enlaces a reglas internas entre 0 y 1 en la mayoría de los casos, y utiliza 2 solo para temas excepcionalmente interconectados. Prefiere textos de enlace descriptivos a etiquetas como «leer más». Permite que las herramientas de compilación infieran los campos que puedan derivar de forma segura, pero nunca uses la inferencia para justificar evidencias débiles o irrelevantes. ## En cada regla, pon los ejemplos de código antes de las razones y la verificación al final Escribe cada regla en un orden estable para que personas, agentes y validadores encuentren la misma información: 1. una introducción breve y en lenguaje claro; 2. un ejemplo de código realista o un conjunto de ejemplos; 3. una explicación de por qué importa la regla; 4. las directrices de implementación necesarias; 5. una sección final de verificación. Coloca los ejemplos antes de la justificación y mantén la verificación como última sección de nivel superior. Sitúa entre ambas las secciones opcionales, como mejores prácticas, errores comunes, ejemplos de frameworks, herramientas, umbrales, excepciones, compatibilidad con navegadores, normas y notas de implementación. Añade excepciones solo cuando existan salvedades válidas o falsos positivos. Separa la verificación en comprobaciones automatizadas y manuales únicamente cuando ambas tengan sentido. Añade una nota visible sobre normas o compatibilidad cuando estas cambien la decisión de implementación. Prefiere instrucciones con criterios de aprobado o suspenso a consejos genéricos. Indica cómo puede un ingeniero verificar la regla, qué evidencias cuentan y qué condición hace que la comprobación falle. ## Da a las reglas de frontend umbrales medibles de aprobado o suspenso Utiliza umbrales medibles siempre que una regla pueda comprobarse: - presupuestos de rendimiento como `LCP <= 2.5s`, `CLS <= 0.1` o límites de tamaño de recursos; - criterios de accesibilidad como relaciones de contraste, tamaños de objetivos, comportamiento del teclado, ampliación y redistribución; - estados de SEO como indexabilidad, códigos de estado y comportamiento de la URL canónica; - requisitos de seguridad como condiciones del transporte y de las cabeceras de respuesta. Asigna la prioridad según las consecuencias: reserva el nivel más alto para fallos que inutilicen el sitio, de seguridad o legales; utiliza niveles inferiores para experiencias degradadas, mejores prácticas y mejoras opcionales. Los ejemplos deben ser lo bastante realistas para revelar el modo de fallo. Incluye excepciones importantes y restricciones de compatibilidad, pero no añadas todas las secciones opcionales a cada regla. Trata la verificación como parte de la regla, no como una tarea editorial posterior. Una recomendación sin una comprobación reproducible está incompleta. ## Guarda los componentes de UI compartidos en el sistema de diseño, no en cada página Sitúa la tipografía, los iconos, los colores semánticos, los componentes reutilizables y otros aspectos transversales a las aplicaciones en un sistema de diseño compartido. Las aplicaciones deben conectar la integración específica de su framework mientras consumen el contrato compartido. - Reutiliza los componentes existentes antes de crear variantes específicas de una página. - Aplica una función compartida a todas las superficies pertinentes, no solo a la primera página que la solicitó. - Mantén operativos los controles secundarios cuando utilices patrones de tarjeta con enlace extendido. - Centraliza los iconos de marca y las exportaciones de iconos de frameworks; los consumidores no deben eludir el límite del sistema de diseño. - Prefiere variables semánticas de tema con todo el contraste previsto a modificadores arbitrarios de opacidad. - Restaura explícitamente los marcadores de lista cuando un reinicio de CSS los elimine del texto enriquecido. No suprimas las advertencias de hidratación entre servidor y cliente para ocultar una discrepancia. Corrige el límite del estado, por ejemplo, aplazando el estado exclusivo del cliente hasta después del montaje. Mantén la protección originada en el navegador en las mutaciones y formularios del navegador. No apliques comprobaciones antibots del cliente a puntos finales programáticos de API que no puedan completar un desafío de navegador. ## Conecta una herramienta nueva por completo, desde la definición hasta las pruebas Una herramienta nueva o una función entre paquetes solo está completa cuando coinciden su definición, exportación, registro, despacho, implementación, pruebas y documentación. Para una herramienta invocable: 1. define un nombre, una descripción y un esquema de entrada específicos; 2. expórtala en el límite del paquete; 3. regístrala en el catálogo de herramientas del servidor; 4. conéctala a la ruta de despacho; 5. comprueba el descubrimiento, la validación, el enrutamiento y el comportamiento. Utiliza módulos de reexportación únicamente en los límites de los paquetes; los internos añaden saltos de navegación y ocultan la propiedad. Centraliza las versiones de dependencias compartidas cuando varios paquetes las consuman y organiza los scripts por finalidad con un índice mantenido. Respeta los contratos de biblioteca específicos de cada versión. Por ejemplo, usa la estructura de errores actual del validador instalado, crea clientes de consulta con estado mediante la fábrica aprobada por el repositorio y conserva los envoltorios de configuración asíncrona en un orden que preserve todas las propiedades devueltas. Reinicia los servicios después de cambiar la configuración cargada durante el arranque. Una edición correcta no constituye evidencia hasta que el proceso en ejecución la haya cargado. ## Ejecuta todas las comprobaciones antes de publicar, sin saltarte ninguna Ejecuta la cadena canónica de calidad del repositorio después de cambiar una regla o su infraestructura: - valida los metadatos obligatorios, los valores de categoría, la calidad de las fuentes y la estructura de la regla; - puntúa las instrucciones prácticas, las evidencias, los ejemplos, la profundidad del cuerpo, la verificación, los umbrales y las secciones condicionales aplicables; - ejecuta el formateo, el análisis estático, las comprobaciones de tipos y paquetes, las pruebas específicas y la compilación completa que requiera la superficie modificada; - regenera índices o habilidades y confirma que el resultado generado esté sincronizado. No eludas las comprobaciones previas al commit. Corrige los fallos de documentación, conversiones de tipo inseguras, complejidad, límites de importación, código sin usar y cobertura, en lugar de emplear una ruta que omita la verificación. Trata la puntuación automatizada como un control de calidad, no como prueba de corrección semántica. Revisa tanto el resultado renderizado y el orientado a herramientas como el archivo fuente. Antes de publicar, confirma que las instrucciones obligatorias sean ejecutables, que las evidencias sean autorizadas, que los ejemplos coincidan con la recomendación, que la verificación aparezca al final y que no queden diferencias generadas. Publica únicamente después de que pase la cadena completa.