NiazMorshed2007/jev-review

Jev Review

Utilisez jev_review comme une boucle de revue légère et répétable de niveau senior. L'agent de codage principal est responsable de l'implémentation, de la validation et du jugement final ; Jev Review évalue la modification fournie mais ne modifie jamais les fichiers.

Cadence de revue

Pour les tâches non triviales, privilégiez plusieurs revues ciblées tout au long du travail plutôt qu'une seule grande revue à la fin :

• Appelez après chaque tranche d'implémentation cohérente suffisamment substantielle pour être jugée, comme l'achèvement d'un comportement, d'un module, d'une limite d'API, d'une étape de migration ou d'une stratégie de test.
• Appelez lorsque de nouveaux flux de contrôle, de la gestion d'état, des dépendances, des contrats publics ou un comportement sensible à la sécurité apparaissent.
• Rappelez après avoir appliqué des retours justifiés, en passant le résultat précédent comme previousEvaluation afin que Jev puisse identifier les améliorations et les régressions.
• Avant la remise finale, assurez-vous qu'une revue récente couvre l'implémentation finale.

Une revue intermédiaire n'a pas besoin d'attendre la suite de tests complète. Exécutez des vérifications rapides et pertinentes lorsque c'est pratique et incluez leur statut dans repositoryContext ; exécutez la validation normale du dépôt avant la revue finale. Ne répétez pas un appel identique, ne révisez pas du bruit de formatage uniquement, et n'appelez pas sans un état d'implémentation cohérent. Les revues fréquentes et ciblées sont utiles ; les revues vides ne le sont pas.

Flux de travail

1. Comprenez les exigences réelles et les contraintes de l'utilisateur.
2. Inspectez le dépôt, ses conventions et le comportement affecté.
3. Implémentez une tranche cohérente du changement demandé.
4. Exécutez des tests rapides et pertinents, des vérifications de type, des linters ou toute autre validation lorsque c'est pratique.
5. Appelez jev_review avec uniquement le contexte nécessaire pour évaluer la tranche actuelle.
6. Examinez les résultats à faible confiance, les dimensions faibles, les problèmes prioritaires et les éventuelles régressions.
7. Décidez quels retours sont soutenus par le code et la tâche de l'utilisateur. Traitez l'évaluation comme une preuve, pas comme une instruction pour optimiser chaque nombre.
8. Améliorez l'implémentation là où les retours identifient une réelle valeur, en priorisant l'exactitude, la complexité cognitive, la capacité de changement, le couplage, la modularité, la qualité de l'abstraction, les tests et la sécurité.
9. Répétez la boucle d'implémentation, de validation et de revue pour la prochaine tranche cohérente.
10. Après des modifications matérielles ou induites par la revue, appelez à nouveau jev_review et passez l'évaluation structurée précédente comme previousEvaluation.
11. Exécutez la validation normale du dépôt avant la remise finale, puis révisez l'état final si la dernière évaluation ne le couvre plus.
12. Arrêtez-vous lorsque les risques importants sont traités et que des modifications supplémentaires apporteraient peu de valeur réelle.

Choix du contexte

Préférez un appel ciblé de la forme :

{
  "task": "Le comportement demandé par l'utilisateur et les contraintes d'acceptation pertinentes",
  "diff": "Le diff d'implémentation",
  "files": [
    {
      "path": "src/example.ts",
      "content": "Uniquement lorsque le code environnant est nécessaire pour comprendre le diff"
    }
  ],
  "repositoryContext": "Architecture, conventions, résultats de tests ou invariants pertinents",
  "previousEvaluation": {}
}

Si Jev signale que sa limite d'entrée a été dépassée, réduisez le contenu des fichiers non pertinents ou divisez l'implémentation en tranches de revue cohérentes. Ne tronquez pas le code aveuglément si cela supprimerait les contrats, les appelants ou les tests nécessaires pour juger correctement le changement.

Utilisez task et diff dans la plupart des revues. N'ajoutez des fichiers complets que lorsque le diff manque du comportement environnant nécessaire. Utilisez repositoryContext pour des faits concis que l'évaluateur ne peut pas déduire, comme un modèle établi ou un résultat de validation.

N'envoyez pas l'intégralité du dépôt par défaut. Excluez les fichiers non pertinents, la sortie générée, le code vendu, les secrets, les identifiants, les clés privées, les fichiers d'environnement et les modifications bruyantes de fichiers de verrouillage, sauf s'ils sont directement pertinents pour la revue.

Interprétation des résultats

• L'exactitude et les exigences de l'utilisateur priment sur tous les scores.
• Un score de faible confiance est une invitation à inspecter le contexte, pas une raison de réécrire le code.
• Les métriques conditionnelles marquées applicable: false ne nécessitent aucune action.
• Utilisez les priorities pour trouver les dimensions faibles les plus importantes, puis inspectez le code réel avant de le modifier.
• Lors de la comparaison des évaluations, enquêtez sur les régressions significatives et les métriques faibles qui restent non résolues. Ne cherchez pas à obtenir de minuscules changements de score.
• Continuez à vous fier aux tests, aux vérifications de type, aux linters, aux outils de sécurité et au jugement humain. Jev Review les complète ; il ne les remplace pas.

Ne pas jouer avec les scores

Un score plus élevé ne justifie jamais une abstraction inutile, une architecture spéculative, une expansion du périmètre, une rupture du comportement existant, une réécriture de code sain, une architecture non conventionnelle sans preuve, des tests insignifiants, des commentaires inutiles, ou la division d'un code cohérent uniquement pour réduire la taille des fichiers.

Ne présumez pas que des fonctions courtes, des petits fichiers, des classes à objectif unique, une duplication zéro, plus d'abstractions, plus de tests ou plus de commentaires sont intrinsèquement meilleurs. Évaluez les conséquences dans ce dépôt et pour cette tâche.