Utilisez le registre des conclusions du projet, ou context/CLAIMS.md dans le modèle de démarrage. Nommez la déclaration, le statut, la révision d'entrée exacte, les chemins et commandes de preuves, l'auteur, le vérificateur (si applicable), la date et les limites de portée. Le propriétaire de l'intégration le maintient ; les autres proposent des modifications fondées sur des preuves.
Statuts :
- VERIFIED : les critères d'acceptation sont remplis et une personne indépendante, un agent ou un contrôle automatisé suffisamment indépendant a reproduit le résultat pertinent. Nommez le vérificateur et la méthode.
- PROVISIONAL : des preuves à l'appui existent, mais un contrôle nommé ou une dépendance reste ouverte.
- NOT SHOWN : le test spécifié n'a pas établi la déclaration. Conservez le résultat observé et le compte rendu de l'échec.
- VOID : les preuves ou hypothèses ont été invalidées ou remplacées. Conservez la raison et la référence de remplacement.
Distinguer « les tests ont réussi » de « sûr en production », et « plus rapide sur la charge de travail X » d'une accélération universelle. Énoncez la conclusion la plus étroite soutenue. Une deuxième exécution par l'auteur renforce les preuves, mais ne constitue pas une vérification indépendante.
Mettez à jour les entrées en même temps que les preuves lorsque cela est pratique. N'écrasez pas silencieusement une conclusion après de nouveaux résultats ; enregistrez la transition et la raison. Les rapports peuvent inclure de nouveaux travaux en dehors du registre s'ils sont clairement identifiés comme non vérifiés. Aucune modification n'est nécessaire lorsque les preuves soutiennent encore la déclaration existante.