Révision des Conventions

Que fait Révision des Conventions ?

Révisez si le code modifié est adapté à ce dépôt, pas seulement s'il fonctionne. Favorisez le rappel plutôt que la précision : mettez en surface les incohérences plausibles et étayées par des preuves pour qu'un humain les trie, y compris les écarts mineurs de style et de modèle qu'une révision axée sur les défauts omettrait.

Il s'agit d'une révision en lecture seule. Ne modifiez pas les fichiers, n'exécutez pas de formateurs qui écrivent des fichiers et ne publiez pas de commentaires.

Procédure

1. Établir le diff. Utilisez la cible demandée. Sinon, inspectez les modifications staged et unstaged ; si aucune n'existe, comparez la branche actuelle avec sa base de fusion par rapport à la branche de base établie. Indiquez toute incertitude concernant la cible de comparaison.
2. Lire les directives locales. Vérifiez les fichiers AGENTS.md, CONTRIBUTING.md, les documents de style/architecture et la configuration de lint/test pertinente. Ne supposez pas que les documents couvrent les conventions non documentées.
3. Rechercher activement des précédents en dehors du diff. Pour chaque choix d'implémentation nouveau ou modifié, inspectez :
   • Même contexte d'abord : code adjacent, fichiers frères, la zone d'interface utilisateur conteneur (par exemple, barre d'outils, en-tête, boîte de dialogue), le même package/module, ou les tests voisins — même s'ils implémentent une fonctionnalité différente.
   • Même comportement ensuite : autres implémentations de contrôles d'interface utilisateur équivalents, opérations, assistants ou tests.
   • Direction plus large en dernier : modèles à l'échelle du dépôt et migrations documentées lorsque la pratique locale n'est pas claire. Comparez plusieurs exemples représentatifs lorsque c'est pratique. Priorisez les précédents de la même région d'interface utilisateur, du même module ou de la même limite architecturale par rapport à des implémentations fonctionnellement similaires ailleurs. Traitez une implémentation dans un contexte différent comme un contre-exemple uniquement lorsque la même convention s'applique aux deux contextes.
4. Rechercher délibérément des inadéquations de convention :
   • Interface utilisateur : mélange de systèmes de composants dans une zone établie ; choix d'un modèle de contrôle, de composition, de style, de prop ou d'événement différent de l'interface utilisateur voisine.
   • Code : contournement d'un assistant/enveloppe existant, utilisation d'un idiome de gestion d'état ou de gestion d'erreurs différent, conventions de nommage/type/import, ou placement de fichier incohérent.
   • Tests : fixture/configuration, nommage, structure, localisateur ou style d'assertion incohérent ; modifications des sélecteurs ou assertions E2E existants qui élargissent leur cible sans besoin expliqué.
   • Portée du changement : introduction d'une deuxième façon de faire la même chose, ou réécritures stylistiques sans rapport dans le diff.
5. Contester les inadéquations apparentes. Avant de signaler une inadéquation, établissez la responsabilité réelle et l'intention du code modifié à partir de son implémentation, de ses appelants et de ses tests. N'appliquez pas une convention uniquement parce que des termes ou API apparentés apparaissent. Déterminez si la convention citée régit le comportement testé, le mécanisme d'implémentation ou l'emplacement du test, et expliquez pourquoi elle s'applique à cette modification. Vérifiez si une migration documentée, une exception délibérée ou une exigence véritablement différente explique le choix. Lorsque des exemples sont en conflit, signalez l'incertitude plutôt que d'inventer une règle uniforme.

Seuil de signalement

Soyez agressif pour trouver des candidats, pas pour déclarer des règles. Signalez les écarts mineurs et potentiellement discutables lorsqu'il existe un précédent spécifique ou une politique documentée à comparer. N'exigez pas de preuve d'un défaut d'exécution, d'une gravité élevée ou d'exemples identiques multiples.

Signalez les conventions inférées fortement étayées même lorsqu'elles ne sont pas explicitement documentées ; étiquetez-les comme inférées et citez les preuves à l'appui.

• Inadéquation claire : directive directement applicable ou précédent local fort.
• Inadéquation possible : précédent concret mais limité/conflictuel ; mérite un examen humain. Identifiez explicitement l'incertitude.

N'inventez pas de conventions, ne citez pas de code sans rapport comme preuve, et ne transformez pas un exemple incident en règle universelle. Ignorez les broutilles pures de formatage/linting, les préférences sans preuve dans le dépôt, les problèmes préexistants en dehors du changement, et les bogues génériques de correction/sécurité/performance gérés par $review-agent. N'exigez pas de refontes approfondies pour imposer l'uniformité.

Exemple : Lorsqu'un bouton bascule est ajouté à une barre d'outils, inspectez les autres contrôles de cette barre d'outils ainsi que les boutons bascule ailleurs. Dans une barre d'outils basée sur Quasar, l'utilisation d'un système de composants différent peut mériter une constatation même s'il fonctionne correctement. Il s'agit d'une méthode pour trouver des conventions locales, pas d'une règle absolue exigeant Quasar.

Résultat

Signalez tous les candidats distincts et étayés par des preuves, y compris ceux à faible impact ; fusionnez les instances en double du même problème. Classez par pertinence probable pour les mainteneurs, pas seulement par gravité.

Pour chaque constatation, fournissez :

• Emplacement : fichier modifié et ligne(s).
• Preuve de la convention : fichier(s)/emplacement(s) exact(s) existant(s) ou règle documentée ; étiquetez documenté ou inféré.
• Inadéquation : ce qui diffère et pourquoi cela compte pour la cohérence.
• Suggestion : plus petit ajustement raisonnable, formulé comme une suggestion pour les cas incertains.
• Confiance : haute, moyenne ou faible ; expliquez l'incertitude pour moyenne/faible.

Séparez les Inadéquations claires des Inadéquations possibles. Si aucun des deux ne comporte de candidats étayés par des preuves, dites Aucune constatation de convention. N'écartez pas silencieusement des cas plausibles simplement parce qu'ils sont stylistiques ou peuvent être rejetés lors d'une révision manuelle.