NiazMorshed2007/jev-review

Jev Review

Usa jev_review como un bucle de revisión ligero y repetible de ingeniería senior. El agente de codificación principal es responsable de la implementación, validación y juicio final; Jev Review evalúa el cambio proporcionado pero nunca edita archivos.

Cadencia de revisión

Para tareas no triviales, prefiere varias revisiones enfocadas durante el trabajo en lugar de una sola revisión grande al final:

• Llama después de cada segmento de implementación coherente que sea lo suficientemente sustancial para juzgar, como completar un comportamiento, módulo, límite de API, paso de migración o estrategia de prueba.
• Llama cuando aparezcan nuevo flujo de control, manejo de estado, dependencias, contratos públicos o comportamiento sensible a la seguridad.
• Vuelve a llamar después de aplicar retroalimentación justificada, pasando el resultado anterior como previousEvaluation para que Jev pueda identificar mejoras y regresiones.
• Antes de la entrega final, asegúrate de que una revisión reciente cubra la implementación final.

Una revisión intermedia no necesita esperar a la suite de pruebas completa. Ejecuta verificaciones rápidas y relevantes cuando sea práctico e incluye su estado en repositoryContext; ejecuta la validación normal del repositorio antes de la revisión final. No repitas una llamada idéntica, revises solo ruido de formato ni llames sin un estado de implementación coherente. Las revisiones enfocadas frecuentes son útiles; las revisiones vacías no.

Flujo de trabajo

1. Comprende los requisitos reales y las restricciones del usuario.
2. Inspecciona el repositorio, sus convenciones y el comportamiento afectado.
3. Implementa un segmento coherente del cambio solicitado.
4. Ejecuta pruebas rápidas y relevantes, comprobaciones de tipos, linters u otra validación cuando sea práctico.
5. Llama a jev_review solo con el contexto necesario para evaluar el segmento actual.
6. Examina los resultados de baja confianza, dimensiones débiles, problemas prioritarios y cualquier regresión.
7. Decide qué retroalimentación está respaldada por el código y la tarea del usuario. Trata la evaluación como evidencia, no como una instrucción para optimizar cada número.
8. Mejora la implementación donde la retroalimentación identifique valor real, priorizando corrección, complejidad cognitiva, capacidad de cambio, acoplamiento, modularidad, calidad de abstracción, pruebas y seguridad.
9. Repite el bucle de implementar, validar y revisar para el siguiente segmento coherente.
10. Después de cambios impulsados por la revisión u otros cambios materiales, vuelve a llamar a jev_review y pasa la evaluación estructurada anterior como previousEvaluation.
11. Ejecuta la validación normal del repositorio antes de la entrega final, luego revisa el estado final si la última evaluación ya no lo cubre.
12. Detente cuando los riesgos importantes estén abordados y cambios adicionales aporten poco valor real.

Elegir contexto

Prefiere una llamada enfocada con la siguiente forma:

{
  "task": "El comportamiento solicitado por el usuario y las restricciones de aceptación relevantes",
  "diff": "El diff de la implementación",
  "files": [
    {
      "path": "src/example.ts",
      "content": "Solo cuando se necesita código circundante para entender el diff"
    }
  ],
  "repositoryContext": "Arquitectura relevante, convenciones, resultados de pruebas o invariantes",
  "previousEvaluation": {}
}

Si Jev informa que se excedió su límite de entrada, reduce contenido de archivos no relacionados o divide la implementación en segmentos de revisión coherentes. No trunques código a ciegas cuando eso eliminaría los contratos, llamantes o pruebas necesarios para juzgar correctamente el cambio.

Usa task y diff en la mayoría de las revisiones. Agrega archivos completos solo cuando el diff carezca del comportamiento circundante necesario. Usa repositoryContext para hechos concisos que el evaluador no pueda inferir, como un patrón establecido o un resultado de validación.

No envíes todo el repositorio por defecto. Excluye archivos no relacionados, salida generada, código empaquetado, secretos, credenciales, claves privadas, archivos de entorno y cambios ruidosos de archivos de bloqueo a menos que sean directamente relevantes para la revisión.

Interpretar resultados

• La corrección y los requisitos del usuario están por encima de cualquier puntuación.
• Una puntuación de baja confianza es un aviso para inspeccionar el contexto, no una razón para reescribir código.
• Las métricas condicionales marcadas con applicable: false no requieren acción.
• Usa priorities para encontrar las dimensiones débiles más importantes, luego inspecciona el código real antes de cambiarlo.
• Al comparar evaluaciones, investiga las regresiones significativas y las métricas débiles que permanecen sin resolver. No persigas cambios mínimos en las puntuaciones.
• Continúa confiando en pruebas, comprobaciones de tipos, linters, herramientas de seguridad y el juicio humano. Jev Review los complementa; no los reemplaza.

No persigas puntuaciones

Una puntuación más alta nunca justifica abstracción innecesaria, arquitectura especulativa, expansión del alcance, romper comportamiento existente, reescribir código sólido, arquitectura no convencional sin evidencia, pruebas sin sentido, comentarios innecesarios o dividir código cohesivo simplemente para achicar archivos.

No asumas que las funciones cortas, los archivos pequeños, las clases de propósito único, la duplicación cero, más abstracciones, más pruebas o más comentarios son inherentemente mejores. Evalúa las consecuencias en este repositorio y para esta tarea.