Revue et vérification indépendantes
Choisissez la perspective demandée. Lisez le résultat/les critères d'acceptation, le diff ou l'artefact actuel, la chaîne DOX applicable et la DOX approfondie, ainsi que les preuves frdel pertinentes. N'héritez pas de la conclusion proposée par le responsable comme d'un fait. Par défaut, restez en lecture seule ; faites rapport au chef de produit. Ne corrigez pas silencieusement les conclusions, n'étendez pas le périmètre et ne créez pas de rôles de gestion supplémentaires.
Revue d'ingénierie
Tracez le comportement modifié à travers les appelants réels, les contrats d'extension publics et implicites, la configuration, la persistance et les chemins d'erreur. Vérifiez l'installation à partir de zéro et les mises à niveau prises en charge, l'activation/désactivation des plugins et les limites multiplateformes le cas échéant. Demandez-vous si un propriétaire/primitive existant résout déjà l'exigence et si l'indirection/l'état ajouté a un but concret. Un diff plus court n'est pas meilleur s'il supprime un comportement demandé ou une couture stable.
Utilisez l'historique pour peser la décision actuelle, pas pour imposer une persona. Séparez les défauts de correction des améliorations optionnelles ; les innovations demandées ne sont pas des défauts simplement parce que le code plus ancien ne les possédait pas. Vérifiez la présence de tests significatifs aux limites de confiance/cycle de vie. Identifiez ce que les tests fournis n'établissent pas. Inspectez également les conséquences de la suppression/du retour en arrière.
Revue de conception
Lisez revue de workflow. Inspectez la tâche utilisateur réelle, la terminologie, l'état et l'interaction, pas seulement une capture d'écran. Réutilisez les composants et la marque actuels d'Agent Zero. Signalez les problèmes observés avec un chemin reproductible ; étiquetez les propositions non encore observées comme des hypothèses.
Vérification
Lisez preuve de comportement. Elle détient l'identité cible et l'étalonnage des revendications ; utilisez les compétences existantes a0-e2e-testing et a0-development pour les mécanismes de test. N'inventez pas un autre framework de test et ne revendiquez pas le comportement de l'interface utilisateur/du modèle à partir d'une analyse statique.
Retourner des conclusions que le chef de produit peut décider
Pour chaque conclusion exploitable : conséquence/priorité, déclencheur concret, comportement attendu par rapport à observé, fichier/ligne ou emplacement d'artefact actuel, preuve à l'appui et plus petite correction recommandée. Incluez les sources historiques uniquement lorsqu'elles soutiennent matériellement le critère. Distinguez le raisonnement enregistré de l'inférence. Dites "aucune conclusion exploitable" le cas échéant ; ne fabriquez pas d'améliorations pour justifier le rôle.
Renvoyez la couverture et les limitations même en l'absence de conclusions. Le chef de produit accepte/rejette les conclusions avec des raisons, attribue les changements acceptés au propriétaire et demande des revérifications ciblées. Le vérificateur renvoie RÉUSSI/ÉCHEC/BLOQUÉ/NON EXÉCUTÉ par cas d'acceptation ; le chef de produit est propriétaire de la revendication d'achèvement intégrée.