Escribe reglas de análisis estático con correcciones automáticas que no cambian cómo se ejecuta el código

## Apunta a los patrones comunes y deja fuera los casos raros Mantén cada regla conceptualmente sencilla. Céntrate en patrones recurrentes y de gran valor, y deja sin soporte los casos límite poco frecuentes cuando cubrirlos pueda oscurecer la regla o hacer arriesgadas las correcciones. Define un contrato de regla estable con una función de creación y metadatos. En un adaptador basado en eventos, registra los escuchadores de entrada y salida mediante los enlaces proporcionados en vez de devolver un mapa de visitantes convencional. Los escuchadores deben devolver o producir objetos de problema; deja que el adaptador se encargue de informar. Cada problema debe identificar el nodo y el mensaje pertinentes, y añadir datos, una corrección o sugerencias solo cuando sea necesario. Si la API del corrector ofrece un mecanismo de cancelación, úsalo siempre que no pueda demostrarse que una edición es segura. Coloca los valores predeterminados de las opciones en los metadatos para que el framework pueda combinarlos de forma coherente, en lugar de duplicar la lógica de combinación en la regla. ## Decide en qué preajuste va la regla y haz que los nombres de las opciones empiecen por check Trata la ubicación en los preajustes como una decisión de producto: - Incluye las reglas que no generan controversia en el preajuste más seguro y en todos los preajustes más amplios. - Incluye los valores predeterminados útiles pero prescriptivos solo en el preajuste recomendado y en las colecciones más amplias. - Mantén fuera de los preajustes predeterminados los comportamientos especializados o que requieran activación explícita. No confundas «neutral» con «excesivamente prescriptivo». En caso de duda, indica el nivel propuesto y pide a la persona responsable del mantenimiento que decida. Asigna nombres positivos con la forma `check*` a las opciones booleanas públicas, para que `true` active siempre el comportamiento. Las listas de patrones ignorados pueden conservar nombres convencionales como `ignore`. Declara explícitamente todos los idiomas compatibles. Si la lógica depende únicamente de nombres de archivo, texto sin procesar, comentarios o directivas, admite varios idiomas cuando sea práctico y usa funciones auxiliares de raíz y comentarios que abstraigan los tipos de nodo específicos de cada idioma. ## Nombra los helpers según lo que devuelven y reutiliza las utilidades existentes Nombra las funciones auxiliares privadas según su contrato observable. `is*`, `has*`, `should*`, `can*` y `needs*` deben devolver valores booleanos, preferiblemente un `false` explícito en lugar de un valor undefined accidental. Usa `get*Problem` para un problema opcional y `get*Problems` para varios problemas. Reserva `report*` para las funciones auxiliares que informan directamente. No combines la generación de informes o el uso de yield con el resultado de un predicado. Construye el problema por separado y toma la decisión booleana en el punto de llamada. Antes de añadir una función auxiliar, inspecciona los módulos de AST, utilidades generales, corrección y reglas compartidas del repositorio; después, revisa las utilidades de confianza del ecosistema. Reutiliza las exportaciones agregadas y las funciones auxiliares establecidas para la evaluación estática, la búsqueda de variables, la detección de efectos secundarios, las pruebas de tokens, la resolución de referencias, los paréntesis, los puntos y coma y la construcción de correcciones. Promueve una función auxiliar solo cuando sea claramente reutilizable; conserva de forma local la lógica pequeña y específica de una regla. ## Usa el análisis de flujo de control solo para saber si el código siempre sale Usa el análisis de flujo de control del framework cuando una regla deba determinar si una rama o función termina siempre mediante estructuras como return, throw, break, continue, una selección exhaustiva o un bucle infinito. Recorrer manualmente el AST suele ser menos preciso al tratar la gestión de excepciones, las etiquetas, el anidamiento y los segmentos inalcanzables. Para analizar ramas, registra el rastreador de salida de ramas del repositorio y consúltalo después de salir del condicional contenedor. Para analizar funciones, mantén un conjunto de segmentos por cada ruta de código para que las funciones anidadas no contaminen a sus funciones superiores. Registra el estado de accesibilidad al salir del nodo AST correspondiente; no esperes al final de la ruta de código si el framework ya ha limpiado los segmentos actuales. Usa comprobaciones sintácticas más sencillas cuando solo necesites saber si la última instrucción tiene un tipo concreto, dónde aparecen los return o si un corrector local termina en return o throw. No introduzcas mecanismos de flujo de control sin una necesidad real de analizar la accesibilidad. ## Regenera los índices y encabezados de documentación generados en vez de editarlos a mano Identifica los archivos y las regiones generados antes de editar. Nunca edites manualmente índices, tablas ni encabezados de documentación generados. Ejecuta el generador responsable después de añadir, retirar o cambiar el nombre de reglas fuente. Al resolver conflictos, conserva las entradas que actúan como fuente de verdad y vuelve a generar los resultados deterministas en lugar de reconstruirlos manualmente. Mantén la documentación redactada por personas debajo de cualquier límite de encabezado generado. Usa la sintaxis de configuración preferida por el repositorio en los ejemplos; no cambies a ejemplos similares a JSON con comillas, salvo que el ejemplo sea explícitamente JSON. Cuando también existan patrones de reglas compartidas en un repositorio o paquete relacionado, considera si debe trasladarse el mismo cambio. Trátalo como una decisión explícita de compatibilidad, no como una edición automática entre proyectos. ## Ejecuta solo las pruebas de la regla mientras programas y la suite completa al final Escribe pruebas específicas antes de la implementación o en paralelo con ella. Da prioridad a las pruebas basadas en instantáneas cuando el entorno de pruebas pueda capturar juntos diagnósticos, correcciones y sugerencias, y usa modos de analizador especializados solo en los casos que los necesiten. Durante el desarrollo, ejecuta únicamente la prueba de la regla correspondiente. Actualiza las instantáneas de forma intencionada y retira los marcadores temporales de pruebas focalizadas antes de terminar. No ejecutes pruebas de integración lentas como parte del ciclo de edición habitual. Ejecuta pruebas internas sobre el propio proyecto después de implementar una regla nueva y de nuevo después de cada corrección de lógica, porque las correcciones suelen revelar infracciones en otros lugares. Al final, ejecuta el linter real del repositorio, las pruebas específicas, las pruebas internas y, después, el conjunto completo de pruebas una sola vez. No sustituyas el linter por otra herramienta de lint únicamente porque esta informe de resultados limpios. ## Prueba las correcciones con comentarios y sintaxis delicada Prueba el comportamiento, las no coincidencias, las correcciones y las sugerencias sin duplicar la cobertura. Incluye los casos pertinentes de estas familias: - sintaxis tipada, aserciones de tipos, genéricos y encadenamiento opcional; - JSX, comentarios, paréntesis adicionales y expresiones anidadas y encadenadas; - propiedades calculadas, plantillas, expansión y desestructuración; - valores de retorno utilizados frente a no utilizados; - análisis solo sintáctico frente a información completa de tipos cuando la regla depende de los tipos. Prueba los casos que una regla ignora intencionadamente para que el límite quede documentado. Verifica las correcciones cuando haya comentarios y riesgos de inserción automática de puntos y coma. Si un caso necesita un analizador diferente, configúralo en el ámbito de prueba más pequeño que exprese el requisito. ## Ofrece corrección automática solo si no cambia cómo se ejecuta el código y conserva los comentarios Proporciona una corrección automática solo cuando no pueda cambiar el comportamiento en tiempo de ejecución. Cuando el comportamiento pueda cambiar, da prioridad a una sugerencia. Considera obligatoria la conservación de los comentarios: si un reemplazo o una retirada contiene comentarios, cancela la corrección o usa una edición consciente del rango que los mantenga en su lugar. Antes de emitir una corrección, comprueba si un reemplazo necesita paréntesis, si un corchete o paréntesis inicial requiere un punto y coma y si los tokens adyacentes necesitan separación. Usa correcciones de generador para las operaciones con varias ediciones. Conserva el comportamiento del encadenamiento opcional y evita ediciones inseguras cuando un valor se consuma de forma distinta a una expresión independiente. No hagas que las correcciones sean desproporcionadamente complejas solo para conservar elementos integrados ocultos por otras declaraciones, efectos secundarios de accesores o proxies, o huecos de matrices dispersas, salvo que el repositorio ya disponga de una protección local sencilla. Informa del problema sin corregirlo cuando no pueda establecerse la seguridad. ## Nombra la regla, créala con el andamiaje y llévala de las pruebas al commit Elige nombres que describan la estructura y la intención: usa prefijos como `no-`, `prefer-`, `require-` o `consistent-` cuando aclaren el comportamiento. Nombra el objetivo, no el reemplazo propuesto, y evita nombres imprecisos. Usa el andamiaje del repositorio para crear la implementación, la prueba, la documentación y las entradas de índice generadas. Después, sigue esta secuencia: 1. Añade pruebas que fallen o sean representativas. 2. Implementa la lógica de regla mínima que las satisfaga. 3. Documenta el comportamiento y las exclusiones intencionadas. 4. Ejecuta las pruebas específicas y el comando de lint autorizado. 5. Ejecuta las pruebas internas y, al final, el conjunto completo. 6. Confirma que los archivos generados estén actualizados y que no queden archivos temporales. Usa la convención de mensajes de commit del proyecto, incluida la puntuación obligatoria alrededor de los nombres de reglas y opciones. La entrega solo está completa cuando coinciden el código fuente, las pruebas, la documentación, las superficies generadas y los resultados de validación.