Valider les résultats

Critères de rejet

Un résultat est un faux positif — supprimez-le — si L'UN des éléments suivants est vrai :

Préexistant — le code existait avant cette PR et n'a pas été modifié par ce changement
N'est pas réellement bugué — semble incorrect mais est correct (par exemple, la variable EST définie, la logique PRODUIT les bons résultats)
Critique pointilleux — un ingénieur senior ne signalerait pas ceci dans une vraie revue
Détectable par linter — un linter ou vérificateur de type le détectera ; ne dupliquez pas leur travail
Préoccupation générique — « manque de couverture de tests », « problème de sécurité général » sans problème spécifique et traçable
Explicitement supprimé — commentaires d'ignorance lint, suppressions pragma, ou exceptions documentées
Traité ailleurs — error boundaries, middleware, validateurs, ou garanties du framework rendent le problème sans objet

Pour chaque résultat qui passe les critères de rejet, vérifiez LES TROIS :

Pouvez-vous tracer le chemin d'exécution montrant le comportement incorrect ?
Est-ce traité ailleurs (error boundaries, middleware, validateurs) ?
Êtes-vous certain du comportement du framework, des contrats API et de la sémantique du langage ?

Si vous ne pouvez pas répondre avec confiance aux trois, supprimez le résultat.

Simplicité intentionnelle - Toute fonction n'a pas besoin de gestion d'erreurs si l'appelant la gère
Conventions du framework - Les hooks React, l'injection de dépendances, les patterns ORM ont des règles spécifiques
Code de test - Des normes différentes s'appliquent (valeurs codées en dur, pas de gestion d'erreurs souvent OK)
Code généré - Migrations, clients API, fichiers proto (ne vérifiez que si modifiés manuellement)
Motifs copiés - Si le code correspond aux motifs existants dans la codebase, la cohérence > approche « meilleure »
Mises à jour de dépendances automatisées - Les mises à jour minor/patch de Renovate/Dependabot vers les dépendances existantes avec CI qui passe sont une surveillance Stage 5 courante
Régénération de lock file - Un seul changement de manifeste peut produire des milliers de lignes de diff de lock file ; c'est normal et ne constitue pas une préoccupation de revue

Quand vous êtes incertain à propos d'un motif, cherchez des exemples similaires dans la codebase avant de flagger.

Vérifiez les motifs existants - Comment cette codebase gère-t-elle des cas similaires ?
Respectez les conventions établies - Même si non-standard, la cohérence > la perfection
Ne flaggez pas les violations de convention sauf si elles causent des bugs ou des problèmes de sécurité

Exemples :

La codebase utilise extensivement les types any → Ne flaggez pas les usages individuels
La codebase n'a pas de gestion d'erreurs dans les services → Ne flaggez pas un try-catch manquant
La cohérence importe plus que les améliorations isolées

NE flaggez PAS quand traité ailleurs ou garanti par le framework :

Vérifications null : Le langage/framework garantit la non-nullité, ou validation antérieure effectuée
Gestion d'erreurs : Error boundaries existent, fonction conçue pour lancer, ou l'appelant gère
Conditions de course : Framework synchronise (état React, transactions DB), ou opérations idempotentes
Performance : Données bornées (<100 items), s'exécute une fois au démarrage, pas de preuve de profilage
Sécurité : Framework assainit (requêtes paramétrées, échappement JSX), ou la couche API valide
Churn de lock file : Les larges diffs de lock file d'un seul changement de manifeste sont un comportement attendu, pas une préoccupation de revue

Quand vous êtes incertain, supposez que le développeur sait quelque chose que vous ne savez pas.