Revisión de Convenciones

¿Qué hace Revisión de Convenciones?

Revisa si el código modificado encaja en este repositorio, no solo si funciona. Favorece recordar sobre precisión: saca a la luz inconsistencias plausibles con respaldo de evidencia para que un humano las evalúe, incluyendo desajustes menores de estilo y patrones que una revisión centrada en errores omitiría.

Esta es una revisión de solo lectura. No modifiques archivos, ejecutes formateadores que escriban archivos ni publiques comentarios.

Procedimiento

1. Establece el diff. Usa el objetivo solicitado. Si no, inspecciona los cambios staged y unstaged; si no existen, compara la rama actual con su base de fusión contra la rama base establecida. Indica cualquier incertidumbre sobre el objetivo de comparación.
2. Lee la guía local. Revisa los AGENTS.md, CONTRIBUTING.md, documentos de estilo/arquitectura y configuración de linters/pruebas aplicables. No asumas que los documentos cubren convenciones no documentadas.
3. Busca activamente precedentes fuera del diff. Para cada nueva elección de implementación o modificación, inspecciona:
   • El mismo contexto primero: código adyacente, archivos hermanos, el área de IU contenedora (ej. barra de herramientas, cabecera, diálogo), el mismo paquete/módulo o pruebas vecinas, incluso si implementan una funcionalidad diferente.
   • El mismo comportamiento después: otras implementaciones de controles de IU equivalentes, operaciones, ayudantes o pruebas.
   • Dirección amplia al final: patrones en todo el repositorio y migraciones documentadas cuando la práctica local no está clara. Compara múltiples ejemplos representativos cuando sea práctico. Prioriza precedentes de la misma región de IU, módulo o límite arquitectónico sobre implementaciones funcionalmente similares en otros contextos. Trata una implementación en un contexto diferente como un contraejemplo solo cuando la misma convención se aplica a ambos contextos.
4. Busca deliberadamente desajustes de convenciones:
   • IU: mezcla de sistemas de componentes dentro de un área establecida; elección de un control, composición, estilo, prop o patrón de evento diferente al de la IU vecina.
   • Código: omitir un ayudante/envoltorio existente, usar un patrón diferente para gestión de estado o manejo de errores, convenciones de nomenclatura/tipo/importación o ubicación de archivos inconsistente.
   • Pruebas: fixtures/configuración, nomenclatura, estructura, localizadores o estilo de aserciones inconsistentes; cambios a selectores o aserciones E2E existentes que amplían su objetivo sin una necesidad explicada.
   • Alcance del cambio: introducir una segunda forma de hacer lo mismo, o reescrituras de estilo no relacionadas dentro del diff.
5. Desafía los desajustes aparentes. Antes de reportar un desajuste, determina la responsabilidad real y la intención del código modificado a partir de su implementación, llamadas y pruebas. No apliques una convención solo porque aparecen terminología o API relacionadas. Determina si la convención citada rige el comportamiento que se prueba, el mecanismo de implementación o la ubicación de la prueba, y explica por qué se aplica a este cambio. Verifica si una migración documentada, una excepción deliberada o un requisito genuinamente diferente explica la elección. Cuando los ejemplos entren en conflicto, reporta la incertidumbre en lugar de inventar una regla uniforme.

Umbral de Reporte

Sé agresivo para encontrar candidatos, no para declarar reglas. Reporta desviaciones menores y potencialmente discutibles cuando haya un precedente específico o una política documentada para comparar. No se requiere prueba de un defecto en tiempo de ejecución, alta gravedad o múltiples ejemplos idénticos.

Reporta convenciones inferidas con fuerte respaldo incluso cuando no están explícitamente documentadas; etiquétalas como inferidas y cita la evidencia de respaldo.

• Desviación clara: guía directamente aplicable o precedente local sólido.
• Posible desviación: precedente concreto pero limitado/en conflicto; vale la pena una revisión humana. Identifica explícitamente la incertidumbre.

No inventes convenciones, cites código no relacionado como evidencia ni conviertas un ejemplo incidental en una regla universal. Omite trivialidades de formato/linter, preferencias sin evidencia en el repositorio, problemas preexistentes fuera del cambio y errores genéricos de corrección/seguridad/rendimiento manejados por $review-agent. No exijas refactorizaciones amplias para imponer uniformidad.

Ejemplo: cuando se agrega un interruptor a una barra de herramientas, inspecciona otros controles en esa barra de herramientas, así como interruptores en otros lugares. En una barra de herramientas basada en Quasar, usar un sistema de componentes diferente puede merecer un hallazgo incluso si funciona correctamente. Este es un método para encontrar convenciones locales, no una regla general que requiera Quasar.

Salida

Reporta todos los candidatos distintos con respaldo de evidencia, incluidos los de bajo impacto; fusiona instancias duplicadas del mismo problema. Ordena por relevancia probable para los mantenedores, no solo por gravedad.

Para cada hallazgo, proporciona:

• Ubicación: archivo modificado y línea(s).
• Evidencia de la convención: archivo(s)/ubicación(es) exactos existentes o regla documentada; etiqueta documentada o inferida.
• Desviación: qué es diferente y por qué es importante para la consistencia.
• Sugerencia: el ajuste razonable más pequeño, expresado como sugerencia para casos inciertos.
• Confianza: alta, media o baja; explica la incertidumbre para media/baja.

Separa Desviaciones claras de Posibles desviaciones. Si ninguna tiene candidatos con respaldo de evidencia, di Sin hallazgos de convenciones. No descartes casos plausibles solo porque sean estilísticos o puedan ser rechazados durante la revisión manual.