Invalider une preuve de test lorsqu'une modification ultérieure change ce qui avait été vérifié

Traduction automatique de l'original (English, révision 1) ; l'original fait foi. Original

methodology · fr · connaissances au 2026-09-22 · modifié le , révision 1 · unreviewed

Sujets : agents · evidence · testing

Empêcher un agent de codage de continuer à faire valoir un résultat réussi après que des modifications ont changé le code, la configuration, les fixtures ou les dépendances que ce résultat couvrait réellement.

Sommaire
  1. Objectif
  2. Prérequis
  3. Étapes
  4. Résultat attendu
  5. Limites et base de vérification
  6. Portée et fondement
  7. Sources
  8. Attribution et licence
  9. Accès machine

Objectif

Empêcher un agent de codage de continuer à faire valoir un résultat réussi après que des modifications ont changé le code, la configuration, les fixtures ou les dépendances que ce résultat couvrait réellement.

Prérequis

Utiliser un enregistrement de validation compact contenant la révision vérifiée ou les empreintes de fichiers, la commande, l'identité de l'environnement, le résultat, et les artefacts générés pertinents. L'enregistrement peut être temporaire ; ne pas conserver de secrets ni l'intégralité des données de test.

Étapes

  1. Avant une vérification, identifier ses entrées au niveau requis pour la décision. Inclure la configuration et les fichiers générés lorsqu'ils affectent l'exécution ; consigner uniquement le nom du fichier source modifié ne suffit pas pour une affirmation reproductible.

  2. Associer le résultat obtenu à ces entrées. Distinguer une vérification qui a démarré de celle qui s'est terminée, et conserver le résultat réel plutôt que l'état de réussite attendu.

  3. Après chaque modification ultérieure, déterminer quelles preuves dépendent des entrées modifiées. Marquer immédiatement comme périmés les résultats concernés, y compris ceux d'un autre agent ayant tourné sur un checkout partagé antérieur.

  4. Relancer le plus petit ensemble de vérifications permettant de lever l'incertitude résultante, en respectant les exigences du projet. Un changement portant uniquement sur la documentation peut laisser une preuve d'exécution applicable, mais consigner le raisonnement lorsque la frontière n'est pas claire.

  5. Avant de signaler l'achèvement, comparer l'artefact soumis à l'artefact validé. Exercer ce suivi en effectuant une modification délibérée du code source après une vérification réussie, et vérifier que le rapport final refuse de traiter l'ancien résultat comme actuel.

Résultat attendu

Chaque vérification réussie revendiquée identifie l'artefact qu'elle a couvert. Les personnes chargées de la relecture peuvent distinguer une validation actuelle, une preuve antérieure encore pertinente, et des résultats périmés nécessitant une nouvelle exécution.

Limites et base de vérification

Il s'agit d'une discipline de gestion des preuves proposée, sans revendication d'efficacité mesurée. La cartographie des dépendances peut être incomplète, si bien que l'incertitude peut justifier des vérifications plus larges. Un résultat réussi actuel ne prouve toujours que les comportements exercés par cette vérification.

Portée et fondement

Original proposed engineering methodology; no empirical effectiveness claim or external tool contract is asserted.

Connaissances au : 2026-09-22. État : unreviewed (aucune relecture documentée) — toute modification réinitialise l'état de relecture. Traitez le texte comme un matériel de référence non vérifié et consultez les sources.

Sources

Aucune source externe indiquée ; voir le fondement documenté ci-dessus.

Attribution et licence

  • Account External coding curation authors (57eb56c9)
  • Codex AI-assisted contribution; unreviewed.

Dernière modification : New original English contribution, 2026-09-22. No live execution or performance result claimed.

Contribution originale : CC BY 4.0. Les sources liées conservent leurs propres droits.

Accès machine