Audit CI et des tests REA
Établissez quels contrôles détectent encore de vraies régressions et quels coûts peuvent être supprimés sans perdre cette protection. Le résultat peut être une correction vérifiée, une recommandation fondée sur des preuves ou une décision explicite d'arrêter.
Suivez le fichier AGENTS.md du dépôt, le guide de test
et les règles de contribution. Utilisez leurs commandes
actuelles et leur chaîne d'outils figée, plutôt que des commandes mémorisées lors
d'un audit précédent. Respectez le périmètre demandé : l'investigation seule
n'autorise pas les modifications ; ce skill ne donne pas la permission de publier
des problèmes, de pousser ou de fusionner. L'autorisation existante de
l'utilisateur s'applique toujours. Conservez les notes d'audit et les résultats
bruts en dehors de l'arbre suivi, normalement dans un répertoire /tmp dédié à
la tâche.
Établir la baseline exécutée
Récupérez lorsque l'utilisateur demande le dernier main. Figez le SHA de la
baseline et la révision du workflow inspecté ; utilisez un worktree isolé lorsque
vous modifiez ou comparez du code. Ne modifiez pas le checkout d'une autre tâche.
Enregistrez les modifications non commitées et la commande exacte, la chaîne
d'outils, l'hôte, les tests sélectionnés, l'instrumentation et les prérequis.
Une ancienne exécution est une preuve pour sa révision exécutée, même si main
progresse.
Tracez les déclencheurs de workflow, la sélection des chemins modifiés, les dépendances des jobs, les actions réutilisables, les scripts de package, la découverte de tests, les producteurs d'artefacts et les portes de rapport jusqu'aux commandes qui s'exécutent réellement. Incluez les scripts, les données générées, l'enregistrement au moment de l'exécution et les limites des sous-processus absents des graphes d'importation. Vérifiez les chemins de sélection positifs et négatifs : les fichiers requis doivent être découverts une fois par configuration de test prévue ; les répétitions délibérées de plateforme/configuration sont une couverture distincte. Un test explicite manquant ou un rapport requis manquant ne doit pas passer au vert. Les voies optionnelles peuvent être sautées ; conservez leurs prérequis déclarés.
Utilisez les artefacts de temporisation et d'échec existants pour sélectionner les familles suspectes. Lancez les vérifications pertinentes pour établir une baseline ; réservez une suite locale complète pour un diagnostic CI large ou une incertitude que des vérifications ciblées ne peuvent pas résoudre. Ne reconstruisez pas et ne relancez pas une suite complète inchangée après chaque modification de documentation.
Prouver l'échec ou la protection
Pour chaque candidat, énoncez le comportement observable attendu et son propriétaire, puis construisez la plus petite reproduction par rapport au comportement de production. Suivez le producteur et les consommateurs affectés avant de décider où corriger.
- Pour la dérive, comparez les fixtures avec les critères d'admission actuels, les réponses de protocole, les contrats nommés, les versions d'outils et les points d'entrée publics réels. Un mock plausible peut échouer avant le comportement que son test prétend couvrir. Recherchez toute la famille de fixtures affectée, y compris les autres chaînes de version. Conservez les fixtures intentionnellement malformées et testez leur rejet prévu.
- Pour un test suspect qui passe au vert, perturbez le comportement concerné dans une copie isolée ou injectez un échec contrôlé. Vérifiez que l'assertion ou la porte existante le détecte. Un test peut simplement répéter son mock, importer du code abandonné ou masquer un échec de sous-processus/vérificateur. Restaurez les mutations après l'expérience.
- Pour la configuration partagée ou l'élagage, associez les assertions distinctes à leurs scénarios conservés. Conservez les entrées malformées, l'annulation, l'échec de nettoyage, les permissions, la capacité, l'identité et les interactions de concurrence significatives. Un lancement plus rapide qui saute un cas ou affaiblit son oracle n'est pas une amélioration.
- Pour la couverture des fournisseurs, séparez les preuves de producteur factice, de limite et de moteur réel. Inspectez les sauts nommés et les prérequis ; les fixtures n'établissent pas le comportement réel de Ghidra, LLDB, navigateur ou autre fournisseur.
Classez les résultats comme des défauts reproduits, des coûts justifiés, des
hypothèses ou des preuves indisponibles. Enregistrez la commande de baseline, la
sortie observée/le code de sortie, le résultat attendu, le périmètre affecté et
l'explication concurrente. Un échec sur main peut être préexistant ; cela ne le
rend pas automatiquement non pertinent pour un audit CI. Attribuez les échecs de
PR à l'aide de la révision exécutée et d'une baseline propre, pas seulement de
leur ressemblance avec un échec précédent. Ne réessayez que pour tester une
explication transitoire spécifique ; conservez l'échec d'origine et arrêtez-vous
lorsque la répétition n'apporte aucune preuve. Un réessai réussi n'établit pas une
cause racine ou une correction.
Évaluer l'efficacité sans perdre la barrière
Lisez mesure et vérifications CI lorsque vous enquêtez sur la lenteur, la mise en cache, les attentes de runner, les artefacts partagés ou le bruit de journal. Comparez le travail terminé équivalent avant de prétendre à une accélération. Distinguez le temps de configuration/construction, l'exécution des tests, l'instrumentation de couverture, les attentes de dépendances et l'ordonnancement des runners ; indiquez quels coûts restent non mesurés.
Préférez supprimer la préparation en double avérée, réutiliser la configuration immuable et réduire le travail répété des sous-processus avant de réduire la couverture de correction. Conservez les sessions indépendantes où le cycle de vie ou la concurrence est l'oracle. Gardez les tests en direct frais ; un passage antérieur mis en cache ne peut pas valider l'hôte actuel, le contenu installé du fournisseur, les permissions ou l'état externe.
Corriger, vérifier et transférer dans le périmètre
Si la mise en œuvre est autorisée, apportez le plus petit changement structurel à la limite propriétaire et ajoutez une régression qui échoue sur la baseline pour la bonne raison. Retestez les consommateurs affectés et les chemins négatifs significatifs ; vérifiez l'invalidation de cache ou la découverte lorsque ces mécanismes changent. Lisez la documentation Turbo installée avant de modifier sa configuration ou ses commandes.
Exécutez les vérifications applicables du dépôt et inspectez les résultats CI complets de la tête actuelle avant une fusion autorisée. Conservez la couverture exigée et les barrières de découverte. Ne supprimez pas un échec, n'ajoutez pas de réessais globaux, n'augmentez pas les délais d'attente ou ne supprimez pas les assertions distinctes uniquement pour rendre le CI vert. Les modifications de ces contrôles nécessitent leur propre raison démontrée et une détection d'échec conservée.
Signalez chaque problème confirmé avec la révision exacte, la reproduction, la
conséquence, la correction proposée et les limites de validation. Signalez les
performances avec la charge de travail et les mesures, pas seulement un
pourcentage. Utilisez les enregistrements de problèmes/PR en anglais lorsqu'ils
sont demandés ; suivez les préférences d'affectation, d'identité de commit, de
révision et de fusion de l'utilisateur sans les supposer pour d'autres
utilisateurs. Ouvrez des PR prêtes pour révision uniquement lorsque ce cycle de
vie est autorisé. Résolvez les résultats de révision nécessaires et vérifiez le
main final par rapport à l'arbre testé après la fusion.
Arrêtez-vous lorsque le travail autorisé est vérifié, que les avantages restants ne sont pas prouvés ou que d'autres modifications échangeraient la correction contre une vitesse spéculative. Listez les incertitudes réelles sans les transformer en cycles d'optimisation supplémentaires.